Bug#327049: wwwoffle: Restores removed conffile
On Wed 07 Sep 2005, Frank Küster wrote: > > /etc/cron.d/wwwoffle contains: > > # If you want to disable this, comment out the line > # below (don't simply remove this file). Note also that your subject is incorrect, it is *not* marked a conffile. It's not even shipped with the package. > and indeed the postinst scripts recreates the file if it has been > deleted. However, the policy says clearly: > > , > | 10.7.3 Behavior > | > | Configuration file handling must conform to the following behavior: > | > | * local changes must be preserved during a package upgrade, and > | * configuration files must be preserved when the package is > | removed, and only deleted when the package is purged. > ` > > Local modifications also include file deletion. You can't override this > rule by simply saying "don't do that". That same paragraph also states: ,--- | If the existence of a file is required for the package to be sensibly | configured it is the responsibility of the package maintainer to | provide maintainer scripts which correctly create, update and maintain | the file and remove it on purge. `--- If you enter a value via the debconf dialog that indicates that wwwoffle should regularly fetch its list, then why remove the cron.d entry... If I left that file alone when someone removed it, I'd get critical bug reports that the functionality is broken because even after repeated dpkg-reconfigure attempts at entering a fetch frequency, it doesn't fetch anything. Please tell me how I should resolve this dilemma. Please don't just say "if it's removed, don't recreate it"; give me some pseudo-code on how to handle the different situations. I find it difficult to distinguish the following two situations: - wwwoffle is freshly installed, there is and has never been a /etc/cron.d/wwwoffle file, and the user runs dpkg-reconfigure and enters a fetch frequency. - wwwoffle was already installed, there was a fetch frequency defined, but now the user has removed the /etc/cron.d/wwwoffle file and now re-runs dpkg-reconfigure. Thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
Paul Slootman <[EMAIL PROTECTED]> wrote: > On Wed 07 Sep 2005, Frank Küster wrote: >> >> /etc/cron.d/wwwoffle contains: >> >> # If you want to disable this, comment out the line >> # below (don't simply remove this file). > > Note also that your subject is incorrect, it is *not* marked a conffile. > It's not even shipped with the package. Sorry, you are right, the subject should have "configuration file". But that doesn't make the bug any less severe. > That same paragraph also states: > > ,--- > | If the existence of a file is required for the package to be sensibly > | configured it is the responsibility of the package maintainer to > | provide maintainer scripts which correctly create, update and maintain > | the file and remove it on purge. > `--- And if this conflicts with the "preserve local changes" requirement, the usual, policy-compliant way to solve this is to let the postinst script fail with a clear, understandable error message, ideally via debconf, so that it can be translated easily. However, this doesn't apply here, since the existence of the cron job is not required to use wwwoffle. Which is written in the file itself: It already assumes that people might want to disable it. > If you enter a value via the debconf dialog that indicates that wwwoffle > should regularly fetch its list, then why remove the cron.d entry... Because debconf is not a registry. It's a frontend for maintainer scripts to interact with local admins, but the actuall *settings* are stored in /etc/. > If I left that file alone when someone removed it, I'd get critical bug > reports that the functionality is broken because even after repeated > dpkg-reconfigure attempts at entering a fetch frequency, it doesn't > fetch anything. If that happens, you didn't write the config script as debconf-devel advices. The way to go is to parse the configuration (does the file exist? If yes, which interval does it specify?) and put these values into the debconf database via db_set, then ask the questions, then in postinst db_get the answers and make the changes, if needed. This is all described in debconf-devel(7), under "Config file handling". > Please tell me how I should resolve this dilemma. Please don't just say > "if it's removed, don't recreate it"; give me some pseudo-code on how to > handle the different situations. I find it difficult to distinguish the > following two situations: > > - wwwoffle is freshly installed, there is and has never been a > /etc/cron.d/wwwoffle file, and the user runs dpkg-reconfigure and > enters a fetch frequency. This case can easily be distinguished because, like a postinst, config gets a second parameter which is the version number of the last-configured (i.e. the currently installed) package. If it's a fresh install, $2 is empty. I'd offer to write a patch if you don't want to, or don't have time to dig into this. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#327049: wwwoffle: Restores removed conffile
On Wed, Apr 05, 2006 at 03:50:48PM +0200, Paul Slootman wrote:
> On Wed 07 Sep 2005, Frank K?ster wrote:
> > and indeed the postinst scripts recreates the file if it has been
> > deleted. However, the policy says clearly:
> >
> > ,
> > | 10.7.3 Behavior
> > |
> > | Configuration file handling must conform to the following behavior:
> > |
> > | * local changes must be preserved during a package upgrade, and
> > | * configuration files must be preserved when the package is
> > | removed, and only deleted when the package is purged.
> > `
> >
> > Local modifications also include file deletion. You can't override this
> > rule by simply saying "don't do that".
>
> That same paragraph also states:
>
> ,---
> | If the existence of a file is required for the package to be sensibly
> | configured it is the responsibility of the package maintainer to
> | provide maintainer scripts which correctly create, update and maintain
> | the file and remove it on purge.
> `---
>
> If you enter a value via the debconf dialog that indicates that wwwoffle
> should regularly fetch its list, then why remove the cron.d entry...
> If I left that file alone when someone removed it, I'd get critical bug
> reports that the functionality is broken because even after repeated
> dpkg-reconfigure attempts at entering a fetch frequency, it doesn't
> fetch anything.
>
> Please tell me how I should resolve this dilemma. Please don't just say
> "if it's removed, don't recreate it"; give me some pseudo-code on how to
> handle the different situations. I find it difficult to distinguish the
> following two situations:
>
> - wwwoffle is freshly installed, there is and has never been a
> /etc/cron.d/wwwoffle file, and the user runs dpkg-reconfigure and
> enters a fetch frequency.
>
> - wwwoffle was already installed, there was a fetch frequency defined,
> but now the user has removed the /etc/cron.d/wwwoffle file and now
> re-runs dpkg-reconfigure.
debconf-devel(7) says that the configure script ("./debian/config") is
passed the same 2 arguments that the postinst gets, so you can tell
whether it is an initial installation, or an upgrade. If it an
initial installation, then you should recreate the file. If it is an
upgrade, and if the file doesn't exist, then you might consider
prompting the user "should it be recreated?", and, then, iff they
respond "yes", continue to ask questions, and rewrite the file. If it
is an upgrade, and the file does exist, then you should both ask the
normal questions and rewrite the file.
Does this do what you need for the package?
Frank, does it seem reasonable to you?
The only gripe I have with this is that it could be considered an overuse of
debconf.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
On Wed 05 Apr 2006, Frank Küster wrote: > Paul Slootman <[EMAIL PROTECTED]> wrote: > > > If you enter a value via the debconf dialog that indicates that wwwoffle > > should regularly fetch its list, then why remove the cron.d entry... > > Because debconf is not a registry. It's a frontend for maintainer > scripts to interact with local admins, but the actuall *settings* are > stored in /etc/. I'm talking about the case where you just entered a value, interactively. > > If I left that file alone when someone removed it, I'd get critical bug > > reports that the functionality is broken because even after repeated > > dpkg-reconfigure attempts at entering a fetch frequency, it doesn't > > fetch anything. > > If that happens, you didn't write the config script as debconf-devel > advices. The way to go is to parse the configuration (does the file > exist? If yes, which interval does it specify?) and put these values > into the debconf database via db_set, then ask the questions, then in > postinst db_get the answers and make the changes, if needed. This is > all described in debconf-devel(7), under "Config file handling". As I said above: I'm talking about the case where you just entered a value, interactively. Say, the configuration is parsed (the cron.d file is missing, so debconf is seeded with "never"), the user changes that to every 30 minutes, hence expects that from that moment on wwwoffle will fetch its list every 30 minutes. However, you demand that the postinst should never recreate the cron.d file, as the user removed it. Help! :) What to do? > > Please tell me how I should resolve this dilemma. Please don't just say > > "if it's removed, don't recreate it"; give me some pseudo-code on how to > > handle the different situations. I find it difficult to distinguish the > > following two situations: > > > > - wwwoffle is freshly installed, there is and has never been a > > /etc/cron.d/wwwoffle file, and the user runs dpkg-reconfigure and > > enters a fetch frequency. > > This case can easily be distinguished because, like a postinst, config > gets a second parameter which is the version number of the > last-configured (i.e. the currently installed) package. If it's a fresh > install, $2 is empty. No, it's freshly installed, but the user runs dpkg-reconfigure because he wants to turn on the fetch feature, which he didn't turn on during the initial install; that's the situation I meant to demonstrate; sorry if that wasn't clear. > I'd offer to write a patch if you don't want to, or don't have time to > dig into this. If you could take into account all possible situations... then please. Note that I am in the process of packaging 2.9, and the maintainer script will be changed a lot (I'm taking out support for upgrading from before woody, which will simplify things and which should be more than enough). Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
Paul Slootman <[EMAIL PROTECTED]> wrote: > On Wed 05 Apr 2006, Frank Küster wrote: >> Paul Slootman <[EMAIL PROTECTED]> wrote: >> >> > If you enter a value via the debconf dialog that indicates that wwwoffle >> > should regularly fetch its list, then why remove the cron.d entry... >> >> Because debconf is not a registry. It's a frontend for maintainer >> scripts to interact with local admins, but the actuall *settings* are >> stored in /etc/. > > I'm talking about the case where you just entered a value, > interactively. But I may have changed my mind, and i shouldn't be forced to use debconf then. No, I *mustn't* be forced. > As I said above: I'm talking about the case where you just entered a > value, interactively. Say, the configuration is parsed (the cron.d file > is missing, so debconf is seeded with "never"), the user changes that to > every 30 minutes, hence expects that from that moment on wwwoffle will > fetch its list every 30 minutes. However, you demand that the postinst > should never recreate the cron.d file, as the user removed it. No, I don't demand that. I only demand that the postinst script not create the file unconditionally. If a debconf question is seeded with "no", asked or not, and the postinst script acts according to the answer, everything is fine. >> This case can easily be distinguished because, like a postinst, config >> gets a second parameter which is the version number of the >> last-configured (i.e. the currently installed) package. If it's a fresh >> install, $2 is empty. > > No, it's freshly installed, but the user runs dpkg-reconfigure because > he wants to turn on the fetch feature, which he didn't turn on during > the initial install; that's the situation I meant to demonstrate; sorry > if that wasn't clear. So, where's the problem? He's asked the question, changes from "no" to "yes" and a specific value, and the change is done - or he doesn't change, either because he doesn't want to, or he doesn't see the questions, and no change is done. >> I'd offer to write a patch if you don't want to, or don't have time to >> dig into this. > > If you could take into account all possible situations... then please. > Note that I am in the process of packaging 2.9, and the maintainer > script will be changed a lot (I'm taking out support for upgrading from > before woody, which will simplify things and which should be more than > enough). Is the new maintainer script available somewhere? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#327049: wwwoffle: Restores removed conffile
On Wed 05 Apr 2006, Frank Küster wrote: > Paul Slootman <[EMAIL PROTECTED]> wrote: > > > On Wed 05 Apr 2006, Frank Küster wrote: > >> Paul Slootman <[EMAIL PROTECTED]> wrote: > >> > >> > If you enter a value via the debconf dialog that indicates that wwwoffle > >> > should regularly fetch its list, then why remove the cron.d entry... > >> > >> Because debconf is not a registry. It's a frontend for maintainer > >> scripts to interact with local admins, but the actuall *settings* are > >> stored in /etc/. > > > > I'm talking about the case where you just entered a value, > > interactively. > > But I may have changed my mind, and i shouldn't be forced to use debconf > then. No, I *mustn't* be forced. I'm talking about someone who wants to use debconf... He chose at one time to have the fetching active, removed the cron.d script later, and then changed his mind again, and thinks he can reactivate it via debconf. > > As I said above: I'm talking about the case where you just entered a > > value, interactively. Say, the configuration is parsed (the cron.d file > > is missing, so debconf is seeded with "never"), the user changes that to > > every 30 minutes, hence expects that from that moment on wwwoffle will > > fetch its list every 30 minutes. However, you demand that the postinst > > should never recreate the cron.d file, as the user removed it. > > No, I don't demand that. I only demand that the postinst script not > create the file unconditionally. If a debconf question is seeded with > "no", asked or not, and the postinst script acts according to the > answer, everything is fine. I read your bug report to mean that if the user removes the file, postinst should never, ever recreate it again, because that's what the user wants, otherwise he wouldn't have removed the file. And that's what I have a problem with, because that would mean that if he does dpkg-reconfigure again and enters a fetch frequency, "I" (the postinst script) wouldn't be allowed to create the file again. Your exact words were "and indeed the postinst scripts recreates the file if it has been deleted.", indicating that was the problem. You didn't qualify that statement with "unconditionally" or so... > >> This case can easily be distinguished because, like a postinst, config > >> gets a second parameter which is the version number of the > >> last-configured (i.e. the currently installed) package. If it's a fresh > >> install, $2 is empty. > > > > No, it's freshly installed, but the user runs dpkg-reconfigure because > > he wants to turn on the fetch feature, which he didn't turn on during > > the initial install; that's the situation I meant to demonstrate; sorry > > if that wasn't clear. > > So, where's the problem? He's asked the question, changes from "no" to > "yes" and a specific value, and the change is done - or he doesn't > change, either because he doesn't want to, or he doesn't see the > questions, and no change is done. My problem is with the wording of your bug report, you demand the file mustn't be recreated. If you now qualify that by saying that if the user does indeed enter a frequency again then it's OK to recreate the file, then I indeed don't have a problem anymore. > >> I'd offer to write a patch if you don't want to, or don't have time to > >> dig into this. > > > > If you could take into account all possible situations... then please. > > Note that I am in the process of packaging 2.9, and the maintainer > > script will be changed a lot (I'm taking out support for upgrading from > > before woody, which will simplify things and which should be more than > > enough). > > Is the new maintainer script available somewhere? Not yet. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
Paul Slootman <[EMAIL PROTECTED]> wrote:
>> > I'm talking about the case where you just entered a value,
>> > interactively.
>>
>> But I may have changed my mind, and i shouldn't be forced to use debconf
>> then. No, I *mustn't* be forced.
>
> I'm talking about someone who wants to use debconf...
I'm talking about the freedom to switch from and to debconf as I like,
or to not switch and stick to always using it (or never using it). Just
as it was designed.
> He chose at one time to have the fetching active, removed the cron.d
> script later, and then changed his mind again, and thinks he can
> reactivate it via debconf.
He can if it's coded properly.
> I read your bug report to mean that if the user removes the file,
> postinst should never, ever recreate it again, because that's what the
> user wants, otherwise he wouldn't have removed the file.
Sorry if I was too short. I never wanted to say that.
> And that's what I have a problem with,
Fine, so we don't have a problem with each other's goals :-)
> dpkg-reconfigure again and enters a fetch frequency, "I" (the postinst
> script) wouldn't be allowed to create the file again. Your exact words
> were "and indeed the postinst scripts recreates the file if it has been
> deleted.", indicating that was the problem. You didn't qualify that
> statement with "unconditionally" or so...
Sorry for that, I was just too short and assumed you'd figure out
yourself what I meant, which isn't a proper way to report a bug...
>> Is the new maintainer script available somewhere?
>
> Not yet.
So does it make sense that I start of with the old ones? I guess I need
config, postinst and maybe the templates file.
Here's a quick shot, untested:
In wwwoffle.config:
if [ -s /etc/cron.d/wwwoffle ]; then
... as before ...
elif [ -n "$CONFIG_ARG2" ]; # do this only when this is not a fresh install
db_set wwwoffle/fetchfrequency off
fi
db_get wwwoffle/fetchfrequency ###
rc=$?
- if [ $rc -eq 0 -o $rc -ge 30 ]; then # bashism, and won't catch "off"
+ if [ $rc = off ] || [ $rc -eq 0 ] || [ $rc -ge 30 ]; then
FREQ="$RET"
if [ "$FREQ" != off ]; then
# convert to digits only
FREQ=$( expr "$FREQ" : '\([0-9]*\)' )
if [ -z "$FREQ" ]
then FREQ=off
elif [ "$FREQ" = 0 ]
then FREQ=off
fi
fi
if [ "$FREQ" = off ]; then
if [ -s $CRONTAB ]; then
# replace only first occurrence of wwwoffle.cron-fetch line
perl -i.bak -pe
'unless($done==1){if(s,^(\s*#\s*)*([^#]*wwwoffle.cron-fetch),# $2,){$done=1;}}'
$CRONTAB
else
- ( echo "# min hr dom mon dow"
- echo "# If you want to disable this, comment out the line"
- echo "# below (don't simply remove this file)."
- echo "# */30 * * * * proxy [ -x
/etc/wwwoffle/wwwoffle.cron-fetch ] && /etc/wwwoffle/wwwoffle.cron-fetch"
- ) > /etc/cron.d/wwwoffle
- fi
+ :
else
But I don't understand the purpose of the first test where I fixed the
bashism - why do you only act on the crontab file if the value is zero
or if it is at least 30? That means that I can't set it to 20 via
debconf, doesn't it?
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Bug#327049: wwwoffle: Restores removed conffile
Real life delays, sorry... On Thu 06 Apr 2006, Frank K?ster wrote: > So does it make sense that I start of with the old ones? I guess I need Yes... > config, postinst and maybe the templates file. > > Here's a quick shot, untested: > > In wwwoffle.config: > > if [ -s /etc/cron.d/wwwoffle ]; then > ... as before ... > elif [ -n "$CONFIG_ARG2" ]; # do this only when this is not a fresh install >db_set wwwoffle/fetchfrequency off > fi > > db_get wwwoffle/fetchfrequency ### > rc=$? > - if [ $rc -eq 0 -o $rc -ge 30 ]; then # bashism, and won't catch "off" Hmm, that's not what I have in my wwwoffle.config ... 2.8e-2 at least doesn't have that. Besides, -o is NOT a bashism, I've been using that since SystemVR2. ash accepts it fine also. > But I don't understand the purpose of the first test where I fixed the > bashism - why do you only act on the crontab file if the value is zero > or if it is at least 30? That means that I can't set it to 20 via > debconf, doesn't it? You seriously need to study debconf the value is in $RET; here $rc contains the status, not the debconf value. 30 == question not asked. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
Paul Slootman <[EMAIL PROTECTED]> wrote: >> So does it make sense that I start of with the old ones? I guess I need > > Yes... So you mean the structure won't change much, and if I provide a patch against that it will still kind of apply to your new ones? >> config, postinst and maybe the templates file. >> >> Here's a quick shot, untested: >> >> In wwwoffle.config: >> >> if [ -s /etc/cron.d/wwwoffle ]; then >> ... as before ... >> elif [ -n "$CONFIG_ARG2" ]; # do this only when this is not a fresh install >>db_set wwwoffle/fetchfrequency off >> fi >> >> db_get wwwoffle/fetchfrequency ### >> rc=$? >> - if [ $rc -eq 0 -o $rc -ge 30 ]; then # bashism, and won't catch "off" > > Hmm, that's not what I have in my wwwoffle.config ... 2.8e-2 at least > doesn't have that. Strange, I must have looked at the sarge version or whatever. Just fetched the current sid version, and this part looks okay to me. > Besides, -o is NOT a bashism, I've been using that since SystemVR2. > ash accepts it fine also. You're right, it's not a bashism, and even dash understands it when called as /bin/sh. It's not POSIX, though, and posh doesn't know about it. Doesn't matter much, probably. >> But I don't understand the purpose of the first test where I fixed the >> bashism - why do you only act on the crontab file if the value is zero >> or if it is at least 30? That means that I can't set it to 20 via >> debconf, doesn't it? > > You seriously need to study debconf the value is in $RET; > here $rc contains the status, not the debconf value. > 30 == question not asked. Sorry, as I said this was just a "quick shot", I didn't think about it thoroughly. Of course I already knew the difference, and we should stop accusing each other of not having understood debconf (either the usage or the purpose...). I also don't have much time currently, therefore I can't promise you a working patch right now. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#327049: wwwoffle: Restores removed conffile
> I also don't have much time currently, therefore I can't promise you a > working patch right now. I have a version that I think works OK, I'll upload now. (2.9-1). If there are problems with it, feel free to NMU, using that version as a basis. I'm away on vacation for a week or so from tomorrow. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
On Wed, Apr 05, 2006 at 06:21:45PM +0200, Paul Slootman wrote: > My problem is with the wording of your bug report, you demand the file > mustn't be recreated. If you now qualify that by saying that if the user > does indeed enter a frequency again then it's OK to recreate the file, > then I indeed don't have a problem anymore. > > > >> I'd offer to write a patch if you don't want to, or don't have time to > > >> dig into this. > > > > > > If you could take into account all possible situations... then please. > > > Note that I am in the process of packaging 2.9, and the maintainer > > > script will be changed a lot (I'm taking out support for upgrading from > > > before woody, which will simplify things and which should be more than > > > enough). > > > > Is the new maintainer script available somewhere? > > Not yet. Hello Paul, what is the status with this package ? As a result of this problem, wwwoffle has been removed from testing. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
On Fri 02 Jun 2006, [EMAIL PROTECTED] wrote: > Hello Paul, what is the status with this package ? > As a result of this problem, wwwoffle has been removed from testing. Unfortunately real life got into the way. I hope to upload a fixed version within 10 days. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
Package: wwwoffle Version: 2.8e-2 Severity: serious Justification: Violates "must" clause of the policy /etc/cron.d/wwwoffle contains: # If you want to disable this, comment out the line # below (don't simply remove this file). and indeed the postinst scripts recreates the file if it has been deleted. However, the policy says clearly: , | 10.7.3 Behavior | | Configuration file handling must conform to the following behavior: | | * local changes must be preserved during a package upgrade, and | * configuration files must be preserved when the package is | removed, and only deleted when the package is purged. ` Local modifications also include file deletion. You can't override this rule by simply saying "don't do that". Regards, Frank -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages wwwoffle depends on: ii coreutils 5.2.1-2 The GNU core utilities ii debconf1.4.30.13 Debian configuration management sy ii debianutils2.8.4 Miscellaneous utilities specific t ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- debconf information: wwwoffle/string_port_number: 8080 wwwoffle/ageline_added: wwwoffle/use-htdig: false wwwoffle/ppp-fetch: true * wwwoffle/use-ppp-interface: false wwwoffle/ageline_lost: wwwoffle/text_new_location: wwwoffle/conf-perm: * wwwoffle/string_parent_proxy: none * wwwoffle/select_html_lang: de (German) wwwoffle/ipv6defaultnone: * wwwoffle/fetchfrequency: 30 wwwoffle/note_upgrade_config_failed: -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
