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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
