Re: [Pan-users] Build fail during configure FreeBSD 9.3

[Duncan]

Dave posted on Sat, 23 Apr 2016 02:12:25 +0100 as excerpted:

> Pan fails during the configure stage when building from ports on FreeBSD
> 9.3
> 
> It's checking for zlib and fails to find zlib.pc
> 
> zlib.pc exists on a 10.3 box but not on 9.3.
> 
> Am I missing zlib.pc and if so how to find/install it?  Or is it a
> FreeBSD 10 thing and I have to either upgrade from 9.3 or somehow fix
> the Pan Makefile/patch files to find zlib some other way? ( I doubt I
> could manage that on my own!)
> 
> It's not a huge problem for as I will be upgrading my main PC to 10.3
> eventually, but I do prefer to build the port rather than install the
> package because I increase the limits on news server threads.

I know little about the bsds so will leave that angle for others, but the 
news server threads limit is something I know a reasonable amount about.

As you probably know, that limit is due to GNKSA compliance.  But there's 
both some history there and a (GNKSA compliant) workaround that you 
likely will /not/ know unless you have been following this list 
reasonably closely for some time.

As for GNKSA, "Good Netkeeping Seal of Approval", even its original 
authors aren't so strict on compliance any longer.  However, it turns out 
that pan's users, at least the ones on this list who thus were able to 
post their thoughts when the discussion came up, are a somewhat 
conservative bunch, and while there may be individual bits (like the four 
threads per server, in this day when many pay for access and providers 
offer 20 or 50 connections...) of GNKSA that people may indeed be fine 
with changing if they stood alone, the general feeling seems to be that 
full GNKSA compliance is part of what gives pan its distinctive feel and 
character, and there's a real fear that should we accept compromise in 
one area, the line will have been crossed, and there won't be that much 
keeping pan from compromising in other GNKSA areas (discouraging top 
posting and contentless replies, strongly discouraging HTML posts, etc), 
most of which most users appear to support strongly enough that they're 
unwilling to compromise in even the one area, threads per server, where 
it arguably makes sense to compromise, these days.

It should be noted, however, that very possibly one of the reasons the 
vote ended up going that way, is that it turns out there's a bit of a 
loophole in the GNKSA regarding the four connections per server cap, and 
pan has taken advantage of that, so it's not such an insurmountable 
obstacle after all, and thus not worth crossing the GNKSA line for and 
with that line cross risking everything else GNKSA, pan, and its users 
have stood for over the years.

The GNKSA loophole is this -- GNKSA is primarily concerned about and 
written to describe the GUI.  In particular, the GNKSA wording on the 
connections per server clause says the GUI must limit the user to 
configuring only four connections per server.

But there's _nothing_ saying the user can't _manually_ configure more 
than four connections per server, or that the GNKSA-compliant news client 
must enforce the four connections per server limit even if a user has 
manually configured more.

So it is that pan is coded in compliance with GNKSA -- its GUI won't let 
you set more than four connections per server.  However, if you manually 
edit the servers.xml file yourself, you can set whatever connections per 
server you like, and pan will go ahead and limit itself according to 
/that/ configuration, even if the GUI still says four per server max.

Of course there's a minor caveat in that if you make changes via GUI to 
your server config, it's likely to reset the connections per server to a 
max of four, but in practice, most people don't make changes to their 
server config that often once setup, and if they do and notice a drop in 
number of connections, they can just as easily edit the servers.xml file 
again as they did the first time.


As it happens, there's a number of other text-config-only settings 
available as well, tho most of them are simply to avoid the GUI becoming 
too complex (for some reason gnome has this thing against real complex 
config GUIs that I as a kde using gentooer who routinely builds things 
from sources in ordered to get the extra configurability that affords, 
have never really understood), while still allowing the power user the 
flexibility to configure as desired even if it doesn't fit in the more 
limited GUI config.  So the connections-per-server GUI config limitation 
is the only GNKSA-related GUI limitation, but there are other such 
limitations, just not GNKSA related.

These are the other "advanced" config options I know of, mostly but not 
all in servers.xml:

1) Pan will place its files in the directory pointed to by the PAN_HOME 
environmental variable if it is set, instead of using the default ~/.pan2 
dir.  In addition to simply letting you locate your pan dir where you 
want, it's possible to use this fact along with pan wrapper scripts to 
keep multiple independent pan instances.

Here, I actually have three, a text instance for my technical groups like 
this one (viewed as a newsgroup using pan, via the gmane.org list2news 
service), a binary instance for my binary groups, and a test instance 
that I use for just browsing groups that I may or may not ultimately 
subscribe to in one of the other two instances.  This third instance is 
also handy when people post problem reports pointing at posts in other 
newsgroups, so I can go look at them without having to worry about 
messing up the tracking in the groups I'm normally subscribed to in my 
other instances.

I believe other users with kids have their normal on-the-menu pan 
instance with kid-safe stuff, and their pan instance that they only run 
from a terminal window after setting the environmental variable 
appropriately, for their "adult" groups.

I believe others use this feature to separate their mp3 groups from their 
video groups from...

The point is that it's a flexible feature you can use as you wish, and 
people can and do use it in different ways.

2) Expiry.  This setting is also found in servers.xml.  While the GUI 
only has a few selected settings, the value in servers.xml is in days, 
and you can set it as you like.

3) Server rank.  While the GUI only has two server priorities, primary 
and backup, in servers.xml the value is an integer, and if you have 
enough servers to warrant it, you can have fallbacks to your backups of 
your backups of your backups of your primary. =:^)

4) Confused by multiple numbered newsrc files and want to know on sight 
which one belongs to which server?  Change the names in the newsrc 
entries in servers.xml and rename the files to match. =:^)

5) Want to reset pan's idea of what has been read?  Try looking for the 
appropriate group in the newsrc files and editing that line.

6) Directly editing the score file, if you're comfortable with regex and 
are comfortable that you can edit the file without breaking its format, 
can seriously optimize it, and once you're comfortable direct-editing the 
scorefile you'll find the GUI a bit limiting.

Here's a link to a post of mine on scorefile editing including a sample 
from my own scorefile, complete with comments linking the slrn 
documentation (pan uses the same format, minus fancy stuff like includes, 
and case insensitive by default):

http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/8689


Seven is really what prompted this post and was thus discussed out of the 
numbered points above, but I'll relist it here as a numbered point for 
completeness...

7) Connection limit per server.  In servers.xml you can set this as high 
as you like, and pan will honor it.  Just don't make changes to the 
server in the GUI after that, or pan might reset it to four connections 
max and you'll have to adjust it manually again.


Of course all these edits should be done with pan not running, so it will 
read them in correctly when it starts up.  Tho for scores you can edit 
the scorefile with pan running, and then simply use pan's edit article's 
score dialog to reload the scorefile and rescore.


So back to the original subject, if you're only rebuilding pan to get the 
GUI to do more connections, perhaps with the connections-per-server 
manual config information, you won't find that necessary any longer.  And 
if you didn't know that, then it's likely you were unaware of some of the 
other manual editing possibilities and possible you'll find them useful 
as well. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman