New author/maintainer for pinfo needed
Hi, I've so far maintained the package pinfo, an alternative info-file viewer. The last release has been some time ago and there are also some open bug reports. I've talked with the author about the package and he decided that he has no longer time to work on this package. Therefor the program needs a new author to be viable in the future. Ideally the new author is also a debian developer or in the new maintainer queue and would take the package over. If nobody is interested in becoming the author of pinfo, I'm going to orphan the package in a week. Christian -- Debian Developer (http://www.debian.org) 1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F 96A4 1C98 EEF3 B7CE C7E8 pgphZQOcX31R1.pgp Description: PGP signature
Accepted dput 0.9.2.15 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 13 Nov 2004 22:21:06 +0100 Source: dput Binary: dput Architecture: source all Version: 0.9.2.15 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: dput - Debian package upload tool Closes: 268489 268489 279975 Changes: dput (0.9.2.15) unstable; urgency=low . * More verbose error message for ftp uploads. And also use active ftp per default. (Closes: #268489) * Fix user name selection. * dcut: gracefully fail if no uploader was specified. (Closes: #268489) * Again thanks to Thomas Viehmann for providing the patches * Applied a patch from Matthew Palmer to improve the parsing of comma-seperated values by dput. (Closes: #279975) Files: e4a3b33e1131b12fe7bd69c3e2e6c853 569 devel optional dput_0.9.2.15.dsc 55a1088b171a0bc13e7d4e1d7aaa5280 51168 devel optional dput_0.9.2.15.tar.gz 26a8ac86d38f5c28dcf8011cb10042c1 36706 devel optional dput_0.9.2.15_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.90-cvs (GNU/Linux) iEYEARECAAYFAkGoNDUACgkQHJju87fOx+iKxwCfe09Uvlz2HRNhrArKiqEzKklU PwsAmwWzu8e7bPj9g9G7S+CtKcjUinMW =4CWR -END PGP SIGNATURE- Accepted: dput_0.9.2.15.dsc to pool/main/d/dput/dput_0.9.2.15.dsc dput_0.9.2.15.tar.gz to pool/main/d/dput/dput_0.9.2.15.tar.gz dput_0.9.2.15_all.deb to pool/main/d/dput/dput_0.9.2.15_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pinfo 0.6.8-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 16 Oct 2004 20:58:03 +0200 Source: pinfo Binary: pinfo Architecture: source i386 Version: 0.6.8-3 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: pinfo - An alternative info-file viewer Closes: 261167 268591 Changes: pinfo (0.6.8-3) unstable; urgency=low . * Fixed a typo in the infopage. (Closes: * Updated russian translation. (Closes: #268591) * Applied patch from Matthew Mueller to fix segfaults in pinfo when going back. (Closes: #261167) * The last two chances were included with the permission of the upstream author. Files: 7a32c6b63605b9ef506f34073c6e2919 587 doc optional pinfo_0.6.8-3.dsc 10800dc05aa8fe54829b856fffc6c7ac 8488 doc optional pinfo_0.6.8-3.diff.gz ced34846c26233b1ff14fcc34adab1f6 82848 doc optional pinfo_0.6.8-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.90-cvs (GNU/Linux) iEYEARECAAYFAkF6kJAACgkQHJju87fOx+hqRwCeIOe+mxtED41ZqL/EeIMl+qIt eP4AoIi3s8tlkMm8cftzZwbALrTyOsJQ =DlMd -END PGP SIGNATURE- Accepted: pinfo_0.6.8-3.diff.gz to pool/main/p/pinfo/pinfo_0.6.8-3.diff.gz pinfo_0.6.8-3.dsc to pool/main/p/pinfo/pinfo_0.6.8-3.dsc pinfo_0.6.8-3_i386.deb to pool/main/p/pinfo/pinfo_0.6.8-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dput 0.9.2.14 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 Jun 2004 19:48:38 +0200 Source: dput Binary: dput Architecture: source all Version: 0.9.2.14 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: dput - Debian package upload tool Changes: dput (0.9.2.14) unstable; urgency=low . * Added Dutch debconf translation. Thanks to Luk Claes. This will address his bugreport #245920. * Added support for passing additional ssh_config options. This is based on a suggestion (and loosely on a patch) by Stefan Völkel. Thanks! * Very minor cleanup of dput.cf(5). * Fixed the debug message output for ftp connections. A patch for dcut was provided by Dann Frazier. The change for dput was based on it. Thanks! Files: 507cc07cd5ee21b2207d454dfcb18a5f 568 devel optional dput_0.9.2.14.dsc 763ec6e98d80bdede3f26fb488c4a84b 60973 devel optional dput_0.9.2.14.tar.gz 6bc07e4c073a54543b7067b77fcf0352 36412 devel optional dput_0.9.2.14_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.6-cvs (GNU/Linux) iEYEARECAAYFAkEcinUACgkQHJju87fOx+hFPQCfehv4rBrYXEm5P+5LdoP5lkcC zkEAnAqMJ5HcH3l3oFHnpae92l/aM78z =lMzZ -END PGP SIGNATURE- Accepted: dput_0.9.2.14.dsc to pool/main/d/dput/dput_0.9.2.14.dsc dput_0.9.2.14.tar.gz to pool/main/d/dput/dput_0.9.2.14.tar.gz dput_0.9.2.14_all.deb to pool/main/d/dput/dput_0.9.2.14_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tinycdb 0.74-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Jul 2004 20:12:02 +0200 Source: tinycdb Binary: tinycdb Architecture: source i386 Version: 0.74-1 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: tinycdb- a package for creating and reading constant databases Changes: tinycdb (0.74-1) unstable; urgency=low . * New upstream release. Files: e10d4996aa07425203e87b5cb63ec532 549 utils optional tinycdb_0.74-1.dsc 73a29c3ec6c1e5a07dc23ebd4b870bc9 27448 utils optional tinycdb_0.74.orig.tar.gz d8412d96f60318a6b69b9574f27eba66 3259 utils optional tinycdb_0.74-1.diff.gz 11e69236292e267a75d71cbf8a5f7efb 28584 utils optional tinycdb_0.74-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.6-cvs (GNU/Linux) iEYEARECAAYFAkEH7lkACgkQHJju87fOx+ibbQCfWCQTunmeOPXJR7XVpQUPm5kX rYYAn2KCkKeDWKcwcZMQjdWlL/dmmdG3 =f7AO -END PGP SIGNATURE- Accepted: tinycdb_0.74-1.diff.gz to pool/main/t/tinycdb/tinycdb_0.74-1.diff.gz tinycdb_0.74-1.dsc to pool/main/t/tinycdb/tinycdb_0.74-1.dsc tinycdb_0.74-1_i386.deb to pool/main/t/tinycdb/tinycdb_0.74-1_i386.deb tinycdb_0.74.orig.tar.gz to pool/main/t/tinycdb/tinycdb_0.74.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted slidentd 1.0.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Jul 2004 20:26:11 +0200 Source: slidentd Binary: slidentd Architecture: source i386 Version: 1.0.0-1 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: slidentd - A minimal ident (RfC 1413) daemon Changes: slidentd (1.0.0-1) unstable; urgency=low . * New upstream release. * Changed architecture back to any since the necessary build depends are now available. This will address the bug #257422. Files: ef4569b3f1baee369c380f53a7473b2e 599 net extra slidentd_1.0.0-1.dsc 59b89db95d447262894c5a56bd24ec04 30255 net extra slidentd_1.0.0.orig.tar.gz fe8b018639b225c9062db43d65e51cf7 3491 net extra slidentd_1.0.0-1.diff.gz 4f1c8990e6eb1812d976b7d88b385822 31682 net extra slidentd_1.0.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.6-cvs (GNU/Linux) iEYEARECAAYFAkEH8EIACgkQHJju87fOx+iHJgCfc7zHe0qjRoWV1KdZuTNT+hHc Sy8AnRFYu4+97ztwq91ohnZF3eLMfKnO =3WT8 -END PGP SIGNATURE- Accepted: slidentd_1.0.0-1.diff.gz to pool/main/s/slidentd/slidentd_1.0.0-1.diff.gz slidentd_1.0.0-1.dsc to pool/main/s/slidentd/slidentd_1.0.0-1.dsc slidentd_1.0.0-1_i386.deb to pool/main/s/slidentd/slidentd_1.0.0-1_i386.deb slidentd_1.0.0.orig.tar.gz to pool/main/s/slidentd/slidentd_1.0.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dput 0.9.2.13 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 21 Jan 2004 13:34:03 +0100 Source: dput Binary: dput Architecture: source all Version: 0.9.2.13 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: dput - Debian package upload tool Changes: dput (0.9.2.13) unstable; urgency=low . * Added Japanese debconf translations. This fixes the bugreport #227825. * Added duct and duct.1 manpage to create and upload .command files. This will address the wishlist request #224524. Thanks to Thomas Viehmann for contributing that code. * dput will now recognize the options -P and --passive for passive ftp. This fixes the bug report #228826. * This also includes a patch from Thomas Viehmann to fix an incorrect debug message. #224404 Files: 1b9c70cc15042b5cde38f0f281dee13d 568 devel optional dput_0.9.2.13.dsc 3a29ede2470d7607f2e7bbeec8a67d93 56409 devel optional dput_0.9.2.13.tar.gz 48d87d8f068fe2ccb135cfe13924f0c0 35560 devel optional dput_0.9.2.13_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.5-cvs (GNU/Linux) iEYEARECAAYFAkBXUTwACgkQHJju87fOx+j/rACfTDfT4W8Q1gZiMJyqFUwtzNoE 390AmQGCauKGXGiXLo9oQaq74pDGaXA1 =Ho0W -END PGP SIGNATURE- Accepted: dput_0.9.2.13.dsc to pool/main/d/dput/dput_0.9.2.13.dsc dput_0.9.2.13.tar.gz to pool/main/d/dput/dput_0.9.2.13.tar.gz dput_0.9.2.13_all.deb to pool/main/d/dput/dput_0.9.2.13_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fbgetty 0.1.698-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 10 Dec 2003 20:18:34 +0100 Source: fbgetty Binary: fbgetty Architecture: source i386 Version: 0.1.698-5 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: fbgetty- A console getty with and without frame buffer capability Changes: fbgetty (0.1.698-5) unstable; urgency=low . * Orphaning the package. Files: e608590977f8acb50f0bf3ede7376793 618 admin optional fbgetty_0.1.698-5.dsc 6e60c5f8f94e6f1a4bcc8ebb177669f3 5969 admin optional fbgetty_0.1.698-5.diff.gz 73f96329cb2bb1c9ec8f47a246722072 45246 admin optional fbgetty_0.1.698-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.4-cvs (GNU/Linux) iEYEARECAAYFAj/XckgACgkQHJju87fOx+gKPgCePSBpASWuEqw9829eTq3KwKwB GRwAoIpHCs6v73p22Y/tTm69CMtAwXAw =akrp -END PGP SIGNATURE- Accepted: fbgetty_0.1.698-5.diff.gz to pool/main/f/fbgetty/fbgetty_0.1.698-5.diff.gz fbgetty_0.1.698-5.dsc to pool/main/f/fbgetty/fbgetty_0.1.698-5.dsc fbgetty_0.1.698-5_i386.deb to pool/main/f/fbgetty/fbgetty_0.1.698-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recovery status update
Hi James, first let me thank you for your good work so far on the recovery of the debian machines. I just wanted to add one note: On [05/12/03 1:51], James Troup wrote: Use the anonymous upload queue on ftp-master. I believe you want to use something like dupload --to anonymous-ftp-master foo.changes for dupload and dput ftp-master foo.changes for, err, dput. But I don't use either of these programs and haven't tested that. The default configuration of dput was changed in the past to use the anonymous upload-queues. Only if people really want to use scp/rsync (like I do when testing new releases), it's necessary to specify the host. Otherwise it's enough if people use dput foo.changes, if they haven't modified the default configuration (except for username. ;-) Christian -- Debian Developer (http://www.debian.org) 1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F 96A4 1C98 EEF3 B7CE C7E8 pgpU4h5ObJ9DG.pgp Description: PGP signature
Accepted john 1.6-19 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 Dec 2002 22:17:09 +0100 Source: john Binary: john Architecture: source i386 Version: 1.6-19 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: john - An active password cracking tool Changes: john (1.6-19) unstable; urgency=low . * This release wouldn't have been possible without the help from Jeronimo Pellegrini and Gergely Nagy. Both were a great help for me and so it's only fair to credit them here and say a big THANK YOU! * john will create now the files john.pot, john.ini and restore in the directory where it was started from. * Changed the unshadow.1 manpage as suggested by Colin Watson. This means that one occurance of .br was replaced by .PP and an newline was added. This will address the issue of the slightly broken unshadow manpage, that has been reported as bug #142848. * The manpage john.1 won't mention the non-existing john-ini.5 anymore. This is going to fix the bug #122438. * Integrated two patches from Jeronimo Pellegrini that are going to improve the cronjob. Also thanks to Gergely Nagy for his help with devising and developing the patches. This should address bug #162991. * Also the whole setup and behaviour of the cronjob has been modified. This should also fix the bug #118012 since the code has been changed. * Updated the URL pointer in the FAQ. This should fix the bug report #159580. * Changed the wrong comment in the file /etc/john-mail.conf. This will fix the bug #162599. * Fixed the location of password.lst and the location of the files for the incremental mode in /etc/john.ini. This will fix the bugreport #79831. * Reworked support for translation of debconf messages. Now this package is using po-debconf for this purpose. Files: 3c62f3f3a3e435c80675d56da538dcd1 578 admin optional john_1.6-19.dsc e48f1804c1fe1e72db28522d10b9402b 14579 admin optional john_1.6-19.diff.gz 38a226ef35c5fcb9f8fac1f4904bf473 523366 admin optional john_1.6-19_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.3-cvs (GNU/Linux) iEYEARECAAYFAj9WYB8ACgkQHJju87fOx+h1GACfZeczRoqN7IDp3AGVNnyafi5x HsYAn2OkaHHipRPaIzv6zW7MRk/t/ibK =9jU8 -END PGP SIGNATURE- Accepted: john_1.6-19.diff.gz to pool/main/j/john/john_1.6-19.diff.gz john_1.6-19.dsc to pool/main/j/john/john_1.6-19.dsc john_1.6-19_i386.deb to pool/main/j/john/john_1.6-19_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fbgetty 0.1.698-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 Jun 2003 21:19:48 +0200 Source: fbgetty Binary: fbgetty Architecture: source i386 Version: 0.1.698-4 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: fbgetty- A console getty with and without frame buffer capability Changes: fbgetty (0.1.698-4) unstable; urgency=low . * Added two more example issue files. Thanks to Robert Olejnik who pointed me to these two files, which I missed. * Also this release will contain the necessary code in postrm to uninstall the info page. This will fix the bug report #160570. * Changed the manpage to reference /sbin/fbgetty instead of /etc/fbgetty. This will fix the bug report #132850. Files: fc289875e2cced0e18ed16ead41838bd 608 admin optional fbgetty_0.1.698-4.dsc 25fe1bb6293aded7f9859dc30168896b 4814 admin optional fbgetty_0.1.698-4.diff.gz f9ee09adcee154fd83b1fc3afb895fd6 45108 admin optional fbgetty_0.1.698-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.3-cvs (GNU/Linux) iEYEARECAAYFAj9NJfkACgkQHJju87fOx+gv8wCdErY1GrGywTmiK7XA/vq68mn7 O/cAni3TKHg8t21HiYK/DqoS4EBvqBqs =CmY6 -END PGP SIGNATURE- Accepted: fbgetty_0.1.698-4.diff.gz to pool/main/f/fbgetty/fbgetty_0.1.698-4.diff.gz fbgetty_0.1.698-4.dsc to pool/main/f/fbgetty/fbgetty_0.1.698-4.dsc fbgetty_0.1.698-4_i386.deb to pool/main/f/fbgetty/fbgetty_0.1.698-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pinfo 0.6.8-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Aug 2003 10:51:09 +0200 Source: pinfo Binary: pinfo Architecture: source i386 Version: 0.6.8-1 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: pinfo - An alternative info-file viewer Changes: pinfo (0.6.8-1) unstable; urgency=low . * New Upstream release. * This version will now correctly lookup entries in the dir page, when several matches are found. This fixes the bugreport #206155. * This version also allows selection of dir page with numbers. I verified this with the entry from automake-1.6. So the bugreport #186255 will now also be fixed. * The search prompt will now use a default item. So the bugreport #204055 will now also be fixed. Files: 0d22c87038fd3bb3ac994b6af4031136 586 doc optional pinfo_0.6.8-1.dsc 55feb4ebaa709b52bd00a15ed0fb52fb 319857 doc optional pinfo_0.6.8.orig.tar.gz 07569cd378d271b72201fd47aed51b6b 5166 doc optional pinfo_0.6.8-1.diff.gz f3198264e17b522132563fecd69bab2a 82646 doc optional pinfo_0.6.8-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.3-cvs (GNU/Linux) iEYEARECAAYFAj9HLvcACgkQHJju87fOx+jQegCghyEtp2Ows/HETA0Qi/SuXYIB gqEAmQHfK+KKWpPKUrxCE+C+1CTnunzU =rWdh -END PGP SIGNATURE- Accepted: pinfo_0.6.8-1.diff.gz to pool/main/p/pinfo/pinfo_0.6.8-1.diff.gz pinfo_0.6.8-1.dsc to pool/main/p/pinfo/pinfo_0.6.8-1.dsc pinfo_0.6.8-1_i386.deb to pool/main/p/pinfo/pinfo_0.6.8-1_i386.deb pinfo_0.6.8.orig.tar.gz to pool/main/p/pinfo/pinfo_0.6.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted slidentd 0.0.19-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 16 Aug 2003 13:00:21 +0200 Source: slidentd Binary: slidentd Architecture: source i386 Version: 0.0.19-5 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: slidentd - A minimal ident (RfC 1413) daemon Changes: slidentd (0.0.19-5) unstable; urgency=low . * Specify exactly the arches that slidentd can now be build on due to the new build-dependency on dietlibc-dev. * Fixed the postrm script to only remove the ident entry that it created and not others. This was reported together with the solution by Wesley W. Terpstra as bugreport #206249. Files: f7c1c3e6dcd4849a503f2948af507b1a 649 net extra slidentd_0.0.19-5.dsc 9012166a514d70d335c6eee46a1c7fc4 3553 net extra slidentd_0.0.19-5.diff.gz c40a22715e1ef00d06d3bfd1b4dea5c5 30670 net extra slidentd_0.0.19-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.3-cvs (GNU/Linux) iEYEARECAAYFAj9ChxgACgkQHJju87fOx+jbrwCfXbNl99Hjo99v+IR+/FDyKpW8 /XsAn1fMWdW4E6QuwCANYpfidZLvHKyR =YuPg -END PGP SIGNATURE- Accepted: slidentd_0.0.19-5.diff.gz to pool/main/s/slidentd/slidentd_0.0.19-5.diff.gz slidentd_0.0.19-5.dsc to pool/main/s/slidentd/slidentd_0.0.19-5.dsc slidentd_0.0.19-5_i386.deb to pool/main/s/slidentd/slidentd_0.0.19-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dput 0.9.2.11 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 29 Apr 2003 11:09:06 +0200 Source: dput Binary: dput Architecture: source all Version: 0.9.2.11 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: dput - Debian package upload tool Changes: dput (0.9.2.11) unstable; urgency=low . * Removed the host chiark from the configuration file, since it's not available anymore according to Ross Burton. This will fix the bug that he reported as #190744. * Increased the allowed range of days for the delayed argument. This wil address the bugreport #196561. * Applied a patch from Thomas Viehmann to reformat the warning about lintian and the option -o. This issue was reported as bug #199905. * Applied a patch from Thomas Viehmann to support the usage of ~ for the local upload method. This issue was reported as bug #199912. * From now on, this package will use po-debconf for managing the translation of the debconf note. This change was introduced due to the work of Christian Perrier. This will address the issue reported as #200127. * Applied another patch from Thomas Viehmann to output an error message if the execution of an external command fails. This will address the issue reported as #172528. Files: 62bc41f4a888f9ad722d4b3e2b3a8c47 568 devel optional dput_0.9.2.11.dsc 73b12279e2d6e2cd04cad24ac483081f 41296 devel optional dput_0.9.2.11.tar.gz df133ea80d14605f5ad0971bae40ac16 28508 devel optional dput_0.9.2.11_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.3-cvs (GNU/Linux) iEYEARECAAYFAj8+BQMACgkQHJju87fOx+j6yACbBdGPYJQtY0J/KyxPjjSIkTUf LWoAn1nnOd/iAhjcA9ytPIZB+zsNl81B =Y0aR -END PGP SIGNATURE- Accepted: dput_0.9.2.11.dsc to pool/main/d/dput/dput_0.9.2.11.dsc dput_0.9.2.11.tar.gz to pool/main/d/dput/dput_0.9.2.11.tar.gz dput_0.9.2.11_all.deb to pool/main/d/dput/dput_0.9.2.11_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted slidentd 0.0.19-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 30 Jul 2003 08:20:21 +0200 Source: slidentd Binary: slidentd Architecture: source i386 Version: 0.0.19-3 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: slidentd - A minimal ident (RfC 1413) daemon Changes: slidentd (0.0.19-3) unstable; urgency=low . * The build-dependency of this package has been changed to dietlibc, because libowfat is linked against dietlibc. This also means that slidentd is now statically linked. * The postinst will not set the /usr/doc link anymore. * The copyright file not refers to the location of the GNU GPL. * Removed . from the end of the short description. Files: 79195ccef26d80212d0882fd30c9522f 588 net extra slidentd_0.0.19-3.dsc 6224603525269cbd6ecc5a648396fe56 3338 net extra slidentd_0.0.19-3.diff.gz 3a8506a0eeec609bf120ec916f23470f 30430 net extra slidentd_0.0.19-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.3-cvs (GNU/Linux) iEYEARECAAYFAj87bZoACgkQHJju87fOx+g5kQCeIk2KlgxIkyIF54//8ClIksqm WHUAniPIidj7dScN8BZZXdKplmkAm+Ft =ZBeE -END PGP SIGNATURE- Accepted: slidentd_0.0.19-3.diff.gz to pool/main/s/slidentd/slidentd_0.0.19-3.diff.gz slidentd_0.0.19-3.dsc to pool/main/s/slidentd/slidentd_0.0.19-3.dsc slidentd_0.0.19-3_i386.deb to pool/main/s/slidentd/slidentd_0.0.19-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libowfat 0.15-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 19 Jun 2003 08:18:50 +0200 Source: libowfat Binary: libowfat-dev Architecture: source i386 Version: 0.15-1 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: libowfat-dev - A reimplementation of libdjb Changes: libowfat (0.15-1) unstable; urgency=low . * New Upstream release. * This release will fix the typo in the function buffer_GETC and therefor the bug report 192955 will be resolved. Files: 39c8e7c3f44c2a1fe9888291d320663f 586 libdevel optional libowfat_0.15-1.dsc 668841fba1e65468fee7134c958e3b55 92572 libdevel optional libowfat_0.15.orig.tar.gz dfa953e8099b3f0de982a3c6cedcfc6d 2446 libdevel optional libowfat_0.15-1.diff.gz 2e51079d75a28b723bc55067351d4a48 135698 libdevel optional libowfat-dev_0.15-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.3-cvs (GNU/Linux) iEYEARECAAYFAj7xWcAACgkQHJju87fOx+iBwACfdiFR76EuN+wUKGkrD/NBPZgA TBsAnAjXiYU+EZsGGCCU6zSfgVuZX1kC =sqm5 -END PGP SIGNATURE- Accepted: libowfat-dev_0.15-1_i386.deb to pool/main/libo/libowfat/libowfat-dev_0.15-1_i386.deb libowfat_0.15-1.diff.gz to pool/main/libo/libowfat/libowfat_0.15-1.diff.gz libowfat_0.15-1.dsc to pool/main/libo/libowfat/libowfat_0.15-1.dsc libowfat_0.15.orig.tar.gz to pool/main/libo/libowfat/libowfat_0.15.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dput 0.9.2.10 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 12 Mar 2003 21:52:18 +0100 Source: dput Binary: dput Architecture: source all Version: 0.9.2.10 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: dput - Debian package upload tool Changes: dput (0.9.2.10) unstable; urgency=low . * Thanks to the offer from Thomas Viehmann, dput will now have two maintainers taking care of it. * Included a patch from Thomas Viehmann suppress error messages from dpkg which happened when the installed check was used. This will close the problem reported as #154960. * The option -o will now reliable simulate a normal run thanks to another patch from Thomas Viehmann. This will address the issue reported as #149711. * dput will now check the architecture in the installed packages check thanks to a patch from Thomas Viehmann. So the bug #154959 will now also be solved. * Also dput will now not fail when trying to use a delayed directory, but instead report an error. And again thanks to Thomas Viehmann for the patch to solve the bug #182922. * Fixed bare debug statement that should have been caught earlier. This will now finally solve bug #133287. * Changed dependency on python to also include python 2.3 as requested by Robert Millan. He also verified that the basic functionality still works fine with the newer python version. So this will address the issue reported as bug #182800. Files: bc7d673e499e08829aa286c2fc4e39f7 556 devel optional dput_0.9.2.10.dsc dabcbdb8b70f1de9fba92724cd50f95d 37096 devel optional dput_0.9.2.10.tar.gz c1f4b48fffecdb11945b7b22e4d6240c 27866 devel optional dput_0.9.2.10_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.2-cvs (GNU/Linux) iEYEARECAAYFAj6L0vQACgkQHJju87fOx+ilDwCcDdIWCODfWWWKj4L4XPGMPRbs XCkAn2v6RE9/AeDBzVUP+qayuPBW6ZIm =XEMO -END PGP SIGNATURE- Accepted: dput_0.9.2.10.dsc to pool/main/d/dput/dput_0.9.2.10.dsc dput_0.9.2.10.tar.gz to pool/main/d/dput/dput_0.9.2.10.tar.gz dput_0.9.2.10_all.deb to pool/main/d/dput/dput_0.9.2.10_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pinfo 0.6.7-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 13 Feb 2003 09:54:08 +0100 Source: pinfo Binary: pinfo Architecture: source i386 Version: 0.6.7-1 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: pinfo - An alternative info-file viewer Changes: pinfo (0.6.7-1) unstable; urgency=low . * New Upstream release. * Now pinfo will also recognize entries like 'xxx/yyy' which are for example used by emacs21. This will address the issue reported as #174418. * This version will now also support the proper usage of the option -f. It will recognize raw file names when they begin with certain characters. This should fix the issue reported as #153527. Files: 53b81ca4c6fa84ca2f9bd0d23456a1e4 585 doc optional pinfo_0.6.7-1.dsc d0ac823aa8fe528ed54004d022cb0896 318720 doc optional pinfo_0.6.7.orig.tar.gz 760fe706e584b389379e9b45f341e2a0 5044 doc optional pinfo_0.6.7-1.diff.gz 952703505979317261edc20c57552510 80692 doc optional pinfo_0.6.7-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.2-cvs (GNU/Linux) iEYEARECAAYFAj5LX+gACgkQHJju87fOx+iqQwCfXWgOPjU9U/F3WttPChkoYAOQ ls4An2MhFIQWsBCvF2RX/s6lZGhL1Ol5 =ofoB -END PGP SIGNATURE- Accepted: pinfo_0.6.7-1.diff.gz to pool/main/p/pinfo/pinfo_0.6.7-1.diff.gz pinfo_0.6.7-1.dsc to pool/main/p/pinfo/pinfo_0.6.7-1.dsc pinfo_0.6.7-1_i386.deb to pool/main/p/pinfo/pinfo_0.6.7-1_i386.deb pinfo_0.6.7.orig.tar.gz to pool/main/p/pinfo/pinfo_0.6.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tinycdb 0.73-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Nov 2002 10:36:59 +0100 Source: tinycdb Binary: tinycdb Architecture: source i386 Version: 0.73-1 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: tinycdb- a package for creating and reading constant databases Changes: tinycdb (0.73-1) unstable; urgency=low . * First Debian release, based on the debian directory that Michael Tokarev, the upstream author, had provided in the package itself. So only some minor changes were necessary. Files: 6c77bf0aa7b2caf24e5d1ce3f4a4d20b 549 utils optional tinycdb_0.73-1.dsc 4a751aad0ac3067a7b922c40e495d79e 20333 utils optional tinycdb_0.73.orig.tar.gz 816d2fb937bede4484ab108e8aa77f44 2785 utils optional tinycdb_0.73-1.diff.gz 5dbcbd234b05d8e2d7f968c09bb28e92 26942 utils optional tinycdb_0.73-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.1-cvs (GNU/Linux) iEYEARECAAYFAj3zidUACgkQHJju87fOx+gd/wCeJSxOZr3pdmVnFZqbdLcZhEx8 ifEAn3EExVR2ljkcnZOx/wr/VLMTwSFC =Vqao -END PGP SIGNATURE- Accepted: tinycdb_0.73-1.diff.gz to pool/main/t/tinycdb/tinycdb_0.73-1.diff.gz tinycdb_0.73-1.dsc to pool/main/t/tinycdb/tinycdb_0.73-1.dsc tinycdb_0.73-1_i386.deb to pool/main/t/tinycdb/tinycdb_0.73-1_i386.deb tinycdb_0.73.orig.tar.gz to pool/main/t/tinycdb/tinycdb_0.73.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dput 0.9.2.9 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Dec 2002 16:39:27 +0100 Source: dput Binary: dput Architecture: source all Version: 0.9.2.9 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: dput - Debian package upload tool Closes: 171006 Changes: dput (0.9.2.9) unstable; urgency=low . * Another bugfix, because something broke the rsync upload method. A dummy variable will take care of this. (Closes: #171006) Files: 70983ac53107e715596b593c7093ec33 554 devel optional dput_0.9.2.9.dsc 4fb814fa1ccb32bc11d231d2e4f1fab2 35547 devel optional dput_0.9.2.9.tar.gz 51e6bebb89eef77583cf7bc4291bb9ad 26720 devel optional dput_0.9.2.9_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.1-cvs (GNU/Linux) iEYEARECAAYFAj3qLdEACgkQHJju87fOx+iuKwCfY7eeDp0+itfIvJuRTlxL1jQU GuYAnjGxScCtG4jHt0dvmtahW+fTlNuN =Qjr/ -END PGP SIGNATURE- Accepted: dput_0.9.2.9.dsc to pool/main/d/dput/dput_0.9.2.9.dsc dput_0.9.2.9.tar.gz to pool/main/d/dput/dput_0.9.2.9.tar.gz dput_0.9.2.9_all.deb to pool/main/d/dput/dput_0.9.2.9_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#171237: ITP: tinycdb -- a package for creating and reading constant databases
Package: wnpp Version: unavailable; reported 2002-11-30 Severity: wishlist * Package name: tinycdb Version : 0.73 Upstream Author : Michael J. Tokarev [EMAIL PROTECTED] * URL : ftp://ftp.corpit.ru/pub/tinycdb * License : Public Domain [1] Description : a package for creating and reading constant databases tinycdb is a small, fast and reliable utility set and subroutine library for creating and reading constant databases. The database structure is tuned for fast reading: . - Successful lookups take normally just two disk accesses. - Unsuccessful lookups take only one disk access. - Small disk space and memory size requirements; a database uses 2048 bytes for the header and 24 bytes per record, plus the space for keys and data. - Maximum database size is 4GB; individual record size is not otherwise limited. - Portable file format. - Fast creation of new databases. - No locking, updates are atomical. . tinycdb implements almost all API as found in cdb-0.75 written by D.J. Bernstein, so it should be source-compatible. It also implements the query interface as found in earlier versions of cdb (0.6x) and freecdb. It also contains some enhancements, like allowing to check existance of a record in a yet-to-be-created cdb database file. . This package contains both the utility to manipulate constant databases and the development files. [1] This is the complete license text for it: |You can do whatever you like with this package. The code is placed |at the public domain. | |This package is distributed in a hope it will be useful, but |WITHOUT ANY WARRANTY; without even the implied warranty of |MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Both, the upstream author and I believe that this contains no legal problem and is acceptable as DSFG-free license. If there's any problem with the license, please inform me about the problem and a suggested change. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux salem 2.4.20-rc2 #1 Sun Nov 17 10:28:49 CET 2002 i586 Locale: LANG=POSIX, [EMAIL PROTECTED] -- Free yourself from negative influence. Negative thoughts are the old habits that gnaw at the roots of the soul. Moses Shongo, (Seneca)
Accepted libowfat 0.14-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 7 Nov 2002 10:17:02 +0100 Source: libowfat Binary: libowfat-dev Architecture: source i386 Version: 0.14-1 Distribution: unstable Urgency: low Maintainer: Christian Kurz [EMAIL PROTECTED] Changed-By: Christian Kurz [EMAIL PROTECTED] Description: libowfat-dev - A reimplementation of libdjb Changes: libowfat (0.14-1) unstable; urgency=low . * New Upstream release. * Removed postinst script since policy doesn't enforce it anymore. Also the prerm was removed due to the old script cleaning up /usr/doc. Files: ebc3dc1cf021531d3d1e0b28889c2d2a 557 devel optional libowfat_0.14-1.dsc 80a5c0ede8b025c5afb639ce88069661 76636 devel optional libowfat_0.14.orig.tar.gz 7a427d39bd9c121f21a6cd166de1668c 2216 devel optional libowfat_0.14-1.diff.gz 6eb30dc920e1e354f488b54b65e8a6e3 120544 devel optional libowfat-dev_0.14-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.1-cvs (GNU/Linux) iEYEARECAAYFAj3KSF8ACgkQHJju87fOx+jXrACfV5jRkdrC5Ktz8sf+sbsFUMNU QrcAn2FrrVWXFGFuJp+iWYCcphXnPnIk =WZq8 -END PGP SIGNATURE- Accepted: libowfat-dev_0.14-1_i386.deb to pool/main/libo/libowfat/libowfat-dev_0.14-1_i386.deb libowfat_0.14-1.diff.gz to pool/main/libo/libowfat/libowfat_0.14-1.diff.gz libowfat_0.14-1.dsc to pool/main/libo/libowfat/libowfat_0.14-1.dsc libowfat_0.14.orig.tar.gz to pool/main/libo/libowfat/libowfat_0.14.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#129025: general: exim crash with sig11 while getservbyname
reassign 129025 exim thanks On 13/01/02, [EMAIL PROTECTED] wrote: Package: general Version: 20020113 Severity: important You are reporting a problem with the mail server software exim and so this bug should reported against the package exim and not general. in exim-3.33/src/transports/smtp.c, line 1889: struct servent *smtp_service = getservbyname(ob-service, tcp); does a crash with signal 11 on my installation, i dunno but /etc/services seems correct and if i use the following, it works: Seems? Do you have such an entry in /etc/services? |smtp25/tcp mail Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgppZrCNZYONP.pgp Description: PGP signature
Re: Bug#125904: ITP: fungetty, a fun new getty for Linux framebuffers
On 25/12/01, Ben Pfaff wrote: Ben Armstrong [EMAIL PROTECTED] writes: On Thu, Dec 20, 2001 at 02:36:52AM -0800, Ben Pfaff wrote: If so, then maybe you should have a look at fungetty, a replacement for the standard Linux getty that can display full-color graphics above the login prompt. I hacked this up over the last week or so, and it seems to work pretty well. It can display many kinds of PNG files above the login prompt. There are some bugs and limitations, but nothing unreasonable. How does this differ from fbgetty? fbgetty doesn't actually implement its `image' command for the issue file. At least, AFAICT. And why then don't you hack on fbgetty and add the necessary code? You could then send me a patch which I forward to the upstream author. So far he hasn't been biting me and I think he would at least take a close look at your patch and maybe completely or partial incorporate it. Upstream had to first fix some terminal issues which showed up and the broken secure exec functionality to get fbgetty working fine again. The next release after the current one, which I'm testing right now, will be 0.2.x and the new feature of actually implementing the image command would be at least in my opinion a nice feature. So Ben, if you are interested to hack on fbgetty to get the image functionality implemented for the next release, just mail me privately. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpQPvnZw6DlB.pgp Description: PGP signature
Re: An alarming trend (no it's not flaimbait.) (fwd)
Damn, I didn't want to post here anymore, but looks like I need to add some points. :-( On 26/12/01, Brian Wolfe wrote: Heh, I was not aware that a non-developer could subscribe to d-d. Looking at http://lists.debian.org and reading the list description would have told you that before. On Wed, Dec 26, 2001 at 08:41:54AM +, David Graham wrote: SNIP Nice bait I'll bite, but if you want to read it you'll have to subscribe... It's not fair to throw the rock and hide the hand 1) learn how to properly format a mail message (i.e. fold at 75th column) Oops. Darnit, how to do this automaticly with vi? By reading the documentation or hasn't vi some documentation? Look around for textwidth and wrapmargin. 2) learn how to package a deb and adopt whichever package you think you're better at maintaining than the original maintainer Read up on packaging, attempted applying diffs from debian , sucessfully I might add. But as for creating new packages... I haven't had a lot of time to try it. ;-P Mind you this has been in the last 2 years... Aehm, if you already successfully applied the diffs to a source package, then it's not difficult to build a new debian package from that source. And it's enough if new developers start by taking over old packages that they daily use and which have been orphaned. 3) if the package is dead upstream, fork it and maintain it yourself. Most free software licences allow it. Anyone care to donate a time machine to me? I know this sounds routine and a lot like an escapeism but. I honestly do not have to time to maintain my own GPLd software, run a company, advocate Linux smartly, make nice with the family, maintain a 5,000 sq ft warehouse, maintain my sanity, and have a life. Adding package maintenance would be just a little more, but i'd like to regain at least ONE of the seven days of the week for myself before delving into somethign as complex as properly packaging a program for debian. Well, taking over the upstream for a software is quite difficult since you need to know the source well and be a good programmer. But maintaining a debian package doesn't require that much time and knowledge. So if you find enough time to send loud complaintments to this list and then discuss them, it would be better to stop sending those complaints but instead spend the time by sending in an ITA or ITO for some debian package and help improving debian. I can say this though, if Debian were to address the issues I have brought up in a realistic manner, I would be willing to toss my personal time into the project once I have some available, as well as possibly some idle company employee time once I can afford it. Who is Debian? This is a _volunteer_ _based_ _organization_ so everyone is spending the time on the tasks he's interested it. And even you won't be able to force anyone to address the issues who posted, until either he has enough interested and time to take care of some or you pay some of our developers to take care of this issues. Or maybe you even find it enough time to take care of them yourself and contribute that way to Debian. Christian P.S.: I'm aware that some parts of this mail maybe seen as a bait for flames, but that's not the intention. I'm just writing my own opinion and statements about this and will now switch back to silence and disappear in an unseens shadow. :-( -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp8mdY3hNyKU.pgp Description: PGP signature
Re: An alarming trend (no it's not flaimbait.)
So, that's hopefully my last post for quite a long time. On 26/12/01, David D. W. Downey wrote: * Pierfrancesco Caci ([EMAIL PROTECTED]) wrote: 1) learn how to properly format a mail message (i.e. fold at 75th column) Quit pickin at the measly stuff and pay attention to the content of his words. Laying the bear trap here only gets you laughs from the other hunters. Wrong. If you want people to read a mail and follow the content, then you have to proper format it, so that's it's easy to read it. Did you ever read some books or newspapers and noticed the format that they are using? With your argumentation we can remove all those formatting and prints books and newspapers on a large paper roll and read it. 2) learn how to package a deb and adopt whichever package you think you're better at maintaining than the original maintainer Pointing out a failure in a system doesn't mean one has the ability to do what you are asking. It simply means he found a failure. In Not directly. He found a situation that he think it's flawed and which needs to be changed. But without either having enough people interested to take care of it, it won't change until he steps forward and starts working on changing it. this instance, his becoming a maintainer does nothing to solve the problem he's point at other than for that single package. Pushing Wrong, he can then help with other packages, make NMU's if the maintainer gave him permission or track MIA developers done and then orphan their package and let Debian QA take care of them. someone off into this section only further proves the point that debian's starting to potentially fall apart since you completely prove that you either failed to hear or desired not to hear what his content. And you seem to ignore that this is _volunteer_ _based_. Debian Developers will work on those issues that they are interested in and not the things you want to see them working on. If you want to see Developers working on some issue, either start paying them for doing the work, convince enough to work on the issue or start the work on your own. The BTS will happily accept your mails and debian-qa will be interested to hear about MIA developers which you tracked down and which agree to orphan their packages or aren't reachable in any way. Why are you listing all that crap bub? Probably what a few of you are asking. Only to show my experience with different distros, linux, and where I feel I gain my credence for my vote for Brian's comments. And then you are not able to use your experience to create solutions to help debian but to also start lenghty discussions here? Thanks for showing me that at least a part of our user base seems to have changed and see Debian as company which they pay for and which they can force into working on certain issues. Debian is a solid distro to me. It's got heart, strength of charactor both in it's member software, and it's member users and developers. It's withstood 99% of the Let's add every feature we can lay our hands on cause that'll show we know what we're doing! crowd. It's solidly built, loved, and protected over by a loyal group of users. This is more than I can say for the majority of the distributions out there. So why are you then not contributing something back to the Debian project if you quite like it that much? Folks, our user base (non official developers and general users alike) deserve to be listened to when they say something. Listening is one thing, but doing something is much better and at least people like you who according to their own description have enough experience and knowledge, should think about spending some time on helping and improving debian by working on it instead of starting lenghty discussions and complaining loud. Why? Simply because of issues with Debian, be it the installer of old, the lack of certain support, all different reasons. But one And you aren't able to work on the installer or even just clearly describe the people working on it which parts need to be improved in your opinion and why? Lack of certain support? Try to write exact descriptions what kind of support you are lacking and then talk with the maintainers who are responsible for it about adding it or helping them add it. *doesn't* happen to debian. If each maintainer is watching his or her upstream, updates with their source when it's released, and if the upstream is *not* providing the updates like they should, either Pardon? You want to give us a exact defintion for updates like they should? There's no way to define that and sometimes upstream authors also disappear simply because they have a lack of time. announce to the BTS that the source is cold, or attempt to Why should one do that? If the package is still working fine and contained no bugs, there's in my opinion no need to do this. And if the package is too buggy, it's easier to contact the ftpmaster via the BTS and ask for package
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Henrique de Moraes Holschuh wrote: On Tue, 25 Sep 2001, Christian Kurz wrote: On 01-09-24 Henrique de Moraes Holschuh wrote: On Mon, 24 Sep 2001, Christian Kurz wrote: Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. In my Oh, how so? I think you know how the method of how to break out of a chroot. Having some symlink inside the chroot would in my opinion make this task easier then it normally is. But feel free to prove me wrong. and would instead suggestion to modify the documents stating that all config files should be in /etc to make a exception for $CHROOT. wears QA hat NEVER. This is not some low-grade distribution where you can go around scattering configuration files all over the filesystem. I will fight tooth and nail against such an atrocity. /wears QA hat Well, then we have to find some other way like cp, rsync, or something else to keep one copy of the files in /etc and one in $CHROOT/etc. Using mount --bind is like I stated before, no option. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp65GidExMe7.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Roberto Suarez Soto wrote: On Sep/25/2001, Christian Kurz wrote: Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? I think that maybe he refers to the fact that, for example, you may have formatted your ext2 partitions so they are incompatible with 2.0.x Well, I once heared about this, but never read an explanation what exactly causes the differences in the ext2 partitions created while running a 2.0.x kernel and why they have been introduced. kernels. Or to the lot of programs (iptables and related, for example) that only work with 2.4.x. Well, iptables is only available for kernel 2.4.x, but with kernel 2.2.x you can still build a firewall with ipchains or ipfwadm if you still use a 2.0.x kernel. So if you want to build a firewall you are not forced to kernel 2.4.x. The decision which kernel and software to use is still left to the administrator. That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Have you tried any *BSD? I would prefer any Debian to them if I had to Yes, I worked quite some time with FreeBSD and also took a short look at NetBSD. (I hadn't time to install OpenBSD for testing purposes.) seriously take charge of one :-) (but again, that's only my opinion; and I'm Well, I wouldn't agree with you, but that's an other discussion which doesn't belong on this list. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpBfNW5Anj13.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-26 Riku Voipio wrote: On Tue, Sep 25, 2001 at 04:34:31PM +0200, Christian Kurz wrote: On 01-09-25 Steve Greenland wrote: I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? apt-cache search usb for example. Which package exactly do you mean? I don't see any package in that list which would force you to use a kernel 2.4.x. Also do you really want to compare hardware for the usb port with a daemon that you run on a server? stick with 2.2, then *you* deal with the issues. The maintainers have That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Forcing new users to deal with historic burden is not an answer. Pardon? New users are absolutely not forced to deal with historic burden. I'm just proposing that any script or debian package which offers to create a bind chroot should not depend on new kernel specific stuff like mount -bind. I really can't understand your problem with limiting chroot bind9 feature to kernels with --bind mounts support. They still can run bind9 perfectly, although less securely. So, you want to either force every admin running bind9 to either upgrade to kernel 2.4.x or have a less secure system? That's like I stated before a good approach if you want to have people move to some other distribution or free operating system, but not to have people use debian anymore. If 2.2 kernel users want chrooted bind, they a) have already done it - no extra work So let's forget those users and ignore that they maybe also happy about having a debian package set up a chroot for them? b) upgrade to 2.4 - sheez, that was hard... Which is not always an option. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpRrzThslsXy.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-26 Roberto Suarez Soto wrote: On Sep/26/2001, Christian Kurz wrote: I think that maybe he refers to the fact that, for example, you may have formatted your ext2 partitions so they are incompatible with 2.0.x Well, I once heared about this, but never read an explanation what exactly causes the differences in the ext2 partitions created while running a 2.0.x kernel and why they have been introduced. The features are documented in mke2fs(8), under -O (or it seems, for what I've seen). They don't seem to be too useful (unless I'm missing something), but anyway they are there. Thanks for the pointer, which explains the features and partly reasons for them. If someone has a pointer to an even more detailed or longer explanation, please mail me. Well, iptables is only available for kernel 2.4.x, but with kernel 2.2.x you can still build a firewall with ipchains or ipfwadm if you still use Yes, but it's not the same building a firewall with 2.4.x and building a firewall with 2.2.x or 2.0.x. There are a few things that you can do only with 2.4, not with lower versions. Stateful firewalling, for example. Well, you may have not the full features available but you can build with all version a firewall and have at least filtering per ip or port available. So compared to the situation with bind, by using cp,rsync or some other tool for keeping the config files in sync, this would still be possible. If mount -bind is used for creating the chroot this would not be possible and it would be like needing kernel 2.4.x for building a firewall. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpf6TNPq43Ox.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Henrique de Moraes Holschuh wrote: On Mon, 24 Sep 2001, Christian Kurz wrote: Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. In my opinion there should be absolutely no link from $CHROOT to any file outside the chroot. So instead of creating a $CHROOT that contains everything without any link to the outside you want to decrease the security by having links from outside to inside? I don't agree with that and would instead suggestion to modify the documents stating that all config files should be in /etc to make a exception for $CHROOT. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgphj8SPASqTg.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Wichert Akkerman wrote: Previously Henrique de Moraes Holschuh wrote: And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. bind mounts. As I wrote in two emails before, this isn't a solution, since this forces an administrator to use kernel 2.4.x instead of maybe still using 2.2.x. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpjbyKDuFjJj.pgp Description: PGP signature
Re: what happened to the dput package?
On 01-09-25 Jochen Voss wrote: there used to be a package called dput, but now I cannot find it anymore. For example visiting http://packages.debian.org/dput shows the message No responses to your query and aptitude lists it as an obsolete package. What happened to this package? Was it renamed? Or did a do something wrong? No, you did absolutely nothing wrong. Due to the new dependency on GnuPG of dput, it had to be removed from ftp.debian.org and reuploaded to non-us.debian.org. But after uploading it to non-us.debian.org there's still some action from the ftp masters needed to make it available again. This hasn't happened so far. I can make a temporary second upload of the current package version to people.debian.org. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpWBIeg4rDmI.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Steve Greenland wrote: On 25-Sep-01, 03:12 (CDT), Christian Kurz [EMAIL PROTECTED] wrote: As I wrote in two emails before, this isn't a solution, since this forces an administrator to use kernel 2.4.x instead of maybe still using 2.2.x. I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? stick with 2.2, then *you* deal with the issues. The maintainers have That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpAWaw71repF.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Martin F Krafft wrote: also sprach Christian Kurz (on Mon, 24 Sep 2001 10:59:13PM +0200): Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. except if you want to enable the usual /etc/bind/ editing of conf-files, which would make administering the chroot no different than administering the non-chrooted bind. Wouldn't that also be possible by using cp -axp to sync the two copies of the config files? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpZWdtildXMW.pgp Description: PGP signature
Re: what happened to the dput package?
On 01-09-25 Sean 'Shaleh' Perry wrote: On 25-Sep-2001 Steve M. Robbins wrote: On Tue, Sep 25, 2001 at 02:10:22PM +0100, Andrew Suffield wrote: On Tue, Sep 25, 2001 at 02:07:36PM +0200, Jochen Voss wrote: there used to be a package called dput, but now I cannot find it anymore. For example visiting http://packages.debian.org/dput shows the message No responses to your query and aptitude lists it as an obsolete package. What happened to this package? Was it renamed? Or did a do something wrong? It's moving to non-us, but is (was?) NEW, pending an overrides update. Really? Why? it likely wants to depend on ssh. No, dput doesn't depend on ssh, it only suggest it like rsync. But it depends on GnuPG now, therefor the change. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTwlDB8c7eP.pgp Description: PGP signature
Re: what happened to the dput package?
On 01-09-25 Sean 'Shaleh' Perry wrote: No, dput doesn't depend on ssh, it only suggest it like rsync. But it depends on GnuPG now, therefor the change. why the depends on gpg? Because the default behaviour of dput is to check the signatures on the .dsc and the .changes file. So it won't be useful without GnuPG in the default behaviour except you select to ignore the signature check. Christian -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Ben Franklin
Re: bind9-chroot (was: questions on ITP)
On 01-09-23 Martin F Krafft wrote: complicated for i did not know about the mount --bind option. sure, this only works with 2.4.x, but if any chroot changes to bind9 are going public, then this will be bundled with a 2.4.x kernel-image, right? will testing be 2.4.x? So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable solution, since the decision which kernel is used, should never be depending on a chroot-setup, but on the decision of the system administrator. So this script should work with kernel 2.2.x and 2.4.x so that everyone can use it with the kernel version he likes to use. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp1wgch2tmtZ.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Marco d'Itri wrote: On Sep 24, Christian Kurz [EMAIL PROTECTED] wrote: So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable Yes, since managing a chroot environment without bind mounts is way It maybe harder, but that's not a good reason to force system administrator to run a kernel 2.4.x for having the bind debian package chrooted. The reason which kernel version is used on a server should always belong to the admin and should never be imposed by some software. harder and IMO cannot easily/correctly be done by a package. Why not? What do you think makes that part so difficult? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpMGY9yuKZcn.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Martin F Krafft wrote: also sprach Christian Kurz (on Mon, 24 Sep 2001 10:31:54AM +0200): So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable solution, since the decision which kernel is used, should never be depending on a chroot-setup, but on the decision of the system administrator. So this script should work with kernel 2.2.x and 2.4.x so that everyone can use it with the kernel version he likes to use. okay, you do have a point. it's not too difficult to make bind chrooted without remounting /etc/bind - one way would be to store Thanks, that would be in my opinion the best option, since that way every administrator can use the kernel version he wants. $CHROOT/etc/bind in the chroot, and then have a symlink from the real /etc/bind to the chroot one. Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgprw63g9mhDj.pgp Description: PGP signature
Re: gpg and trustdb very slow
On 01-09-18 Joey Hess wrote: It'd be nice if someone would look at optimizing it sometime; the behavior I see with strace is absurd, and could easily be done with no syscalls, at least, by just reading the whole trustdb into memory. I know that the Werner revamped the whole keyring code about 1 or two weeks ago. I just tried the --list-keys with my private and the debian keyring specified in the options file and I didn't took more then 5 minutes for me. (AMD K6-200). So I don't think if anyone would really want to optimize the code more, he should look at the current cvs code. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpKkCna6h751.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-06 Nick Phillips wrote: On Thu, Sep 06, 2001 at 07:47:26PM +0200, Christian Kurz wrote: upstream packages because they are not part of a package? The translation of the error messages and other messages of a program belong to the package of it. That depends on whether you're distributing one package or thousands. Why do make this dependant on the number of packages? I think that using some count like you do, is a bad thing. Because if you're only distributing one package or small group of packages (say, KDE), then your focus is making the translations available for all the So you want to compare packages from an upstream with packages created by either someone or a team for a distribution? people who use that package, whether or not the particular distribution they got it from has infrastructure to support translations. Hence it makes sense to put the translations in the package in that case. If on the other hand you are one of those distributions, distributing all sorts of packages, some of which have upstream translations, some of which don't, some of whose maintainers are able and willing to spend time on translations, some of whose maintainers aren't, then it doesn't make sense to set yourselves up in such a way (translations always living in packages) that translations will only be available when the maintainer does work on them. Which creates the situation, that packages in debian will on the one hand be different then the one you can get from the upstream and on the other hand it's a violation of our social-contract: | software will be widely distributed and used. We will feed back | bug-fixes, improvements, user requests, etc. to the upstream authors | of software included in our system. So if we correct wrong translation or create a new translation, then we shall send it to the upstream and inform them. With your suggestion above, this will only happen, if either the translator is doing this task also or if the maintainer is taking care of the translation. In all other cases, where the maintainer is not taking care of the translation, we'll have a nice violation of that statement. And since the maintainer is the contact to the upstream and responsible for the debian package, he shall be involved in the translation. Splitting translation out of upstream packages is in my opinion a bad thing and should never be done. But if we want to be, and are, able to easily add extra translations, or override poor-quality upstream translations (all without causing hassles for maintainers), then why not? Because for example I would prefer to be informed if any of my packages has a bad upstream translation and some has better one for me. Then I can forward and discuss it with the upstream and he can include it maybe in the official upstream sources. That way we wouldn't only improve the translation for people using debian, but also for people who are using some other free operating system and the upstream package. Fine, no-one is saying that you shouldn't be able to arrange to be notified when a particular package has a translation made available. And how do you propose to integration this notifications? According to your statement, everyone can update the translation without having to hassle with me and that's the point which makes me sad. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpDbHwSPjryI.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-05 Nick Phillips wrote: The translation of any part of a package, be it the text of error messages, So, shall we now remove all .po files and other translation from upstream packages because they are not part of a package? The translation of the error messages and other messages of a program belong to the package of it. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpNVcw3nJbiu.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-06 Nick Phillips wrote: On Thu, Sep 06, 2001 at 01:08:25PM +0200, Christian Kurz wrote: On 01-09-05 Nick Phillips wrote: The translation of any part of a package, be it the text of error messages, So, shall we now remove all .po files and other translation from upstream packages because they are not part of a package? The translation of the error messages and other messages of a program belong to the package of it. That depends on whether you're distributing one package or thousands. Why do make this dependant on the number of packages? I think that using some count like you do, is a bad thing. If upstream includes translations, then we don't have to worry about the maintainer managing inclusion of whichever languages people happen to write translations for. But if we want to be, and are, able to easily add extra translations, or override poor-quality upstream translations (all without causing hassles for maintainers), then why not? Because for example I would prefer to be informed if any of my packages has a bad upstream translation and some has better one for me. Then I can forward and discuss it with the upstream and he can include it maybe in the official upstream sources. That way we wouldn't only improve the translation for people using debian, but also for people who are using some other free operating system and the upstream package. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpobuT4Njd53.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-04 Nick Phillips wrote: On Tue, Sep 04, 2001 at 09:06:04PM +0200, Michael Bramer wrote: I don't expect most maintainers to be able or inclined to keep track of a shedload of different translations, and those who are that keen should May I ask if you are aware about the ongoing translation of the debconf templates via the bts? If yes, would you mind explaining what's the difference between keeping track of thsoe translation/bugreports and keeping track of the package translation via a simple ddts mail? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpK9nBMBbLu1.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-04 Wouter Verhelst wrote: On Tue, 4 Sep 2001, Michael Bramer wrote: Maybe I have on next WE more time and I can improve the server and make this notification mail configable per package and someone can remove his packages from the notification process. You didn't already? Jeez... In the US, this is illegal... and isn't gluck located in the states? Would you telling me which part of this emails make them exactly illegal? They maybe annoying for some people, but they are not illegal in my opion. [1] Christian [1] No, I'm not a lawyer. P.S.: If you already call this e-Mails illegal, did you started lawsuits against all other us-based senders of mails to you, which you consider illegal? -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp2W4MEEMiiZ.pgp Description: PGP signature
Re: CUPS
On 01-09-03 Michael Meskes wrote: On Mon, Sep 03, 2001 at 11:16:31AM -0500, Dimitri Maziuk wrote: Probably because you're supposed to use a gooey web browser to add a printer... a bit much for a postinst script. Not exactly. The way I read the docs you can use lpadmin from the commandline to add a printer. In fact it works for the default deskjet ppd. Well, that's also a possible method for adding a printer. Do you get any error messages then on the console or in the logfiles beneath /var/log/cups? WTF is cupsomatic-ppd anyway? Go to http://localhost:631, add _a_ printer (say, call it foobar), get a PPD for your printer and copy it to /etc/cups/ppd/foobar.ppd. You can then use web frontend to configure things, duplex printing, watermark etc. Works for me. But that's a hack and not a real configuration option. Hm, do you need the cupsomatic-ppd because there's no other ppd file in the cups package for your printer available? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpy7cgCc0Ckz.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On 01-09-01 Martijn van Oosterhout wrote: Can you store multiple signitures in the same file? Yes, that possible by using the OpenPGP format. You'll either need to use one-pass-signature packets, like GnuPG does by default, or the cleartext signed format. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpAhcfhcu5Nb.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On 01-09-01 Simon Richter wrote: On Sat, 1 Sep 2001, Christian Kurz wrote: not be ascii armored since this would only introduce transmission overhead and gain nothing. The file name for this file is constructed from the Why does it gain nothing? What about problems during transmission? The ascii armor output which is protected by a crc checksum would help notice such a transmission problem. dpkg already has a mechanism for finding packages that have been corrupted by transferring them in ASCII mode. I mean, the .tar.gz is already binary, Since which day does dpkg download packages in ascci-mode from a url? Are you sure that you are not mixing up dpkg and apt-get? dpkg has as far as I know no mechanismen to detected corrupted packages and therefor having an ascii-armored signatures, with a crc checksum to detect transmission errors will be helpful. so why should the file following it be ASCII? Because there are situations where you don't use a tool that checks if the transmission was fine. You should not only find a solution for the specific case, that a tool downloads the packages from a server and already checks if the transmission was fine, but also for situations where such a tool is not provided. If the original filename is no more than sizeof(ar_name)-2 bytes long, .s is appended to it. If it is longer, the part of the file name before the .s? Another new extension? If you want to achive confusion for our users and developers, that's a possible way to go. If you really don't want to use ascii armor, then the extension should be .sig or if you use ascii-armor then .asc. The problem here is the filename length limit. I would have gone for .sig otherwise. Besides, you will only see those if you look at .deb files directly. And that will never happen? I'm tempted to say that there are cases where you have to look into the .deb directly or extract it via ar/tar. And the people will be confused in those cases, if they notice a file called .s, because that's an unusual extension. - Modify the autobuilders and existing developer scripts (debsign) so that they call dpkg-deb to sign the packages additionally to signing the .changes file. Sign packages build by an auto-builder? Of course. katie needs to verify that they were indeed created by an official autobuilder. How do you want to handle the issue with the passphrase in a secure way? How do you want to ensure that the key is safely placed on the autobuilder and how do you want to ensure that only trusted people have access to the autobuilder and especially this key? Placing a key on an auto-builder with script that contains the passphrase to sign all packages, is hazardous. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp0eljz1vprX.pgp Description: PGP signature
Re: CUPS
On 01-09-02 Michael Meskes wrote: I wanted to install DeskJet_670C-cdj670.ppd or DeskJet_670C-pcl3.ppd from cupsomatic-ppd but just got a lpadmin: add-printer failed: The requested resource was not found on this server. Would you mind telling us which version of cups you have installed? You didn't include that information. Anyway, there does not seem to be much documentation and the web interface on port 631 gives some error messages resp. tells me that the resource is not available. Under the following URL http://localhost:631/documentation.html is a lot of documentation about Cups, especially also an administrator and an user manual. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp3Nq16vm7lh.pgp Description: PGP signature
Re: FWD: Popularity-contest submission doesn't go through to apenwarr-survey@klecker.debain.org
On 01-04-29 Joey Hess wrote: Anyone have a clue? Received: from myhostname.my.isp.com ([EMAIL PROTECTED] [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with +ESMTP id f3QDlYZ2018784 for [EMAIL PROTECTED]; Thu, 26 Apr 2001 07:47:34 +-0600 Suddenly here the email is address to [EMAIL PROTECTED] while in the previous line: Received: (from [EMAIL PROTECTED]) by myhostname.my.isp.com (8.12.0.Beta7/8.12.0.Beta7/Debian +8.12.0.Beta7-1) id f3QDkJuS015600 for [EMAIL PROTECTED]; Thu, 26 Apr 2001 07:46:19 -0600 Here it's addressed to [EMAIL PROTECTED] So I would assume that something on myhostname.my.isp.com is rewriting the email @debian.org to @klecker.debian.org. And I don't think that this localpart apenwarr-survey is available in the sub-domain klecker.debian.org but instead in the domain debian.org. So I would suggest that the configuration of this mail-server myhostname.my.isp.com will be checked to see why suddenly the rcpt-to changes. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpb9gkna3qRy.pgp Description: PGP signature
Re: FWD: Popularity-contest submission doesn't go through to apenwarr-survey@klecker.debain.org
On 01-04-30 Matthijs Melchior wrote: Christian Kurz wrote: On 01-04-29 Joey Hess wrote: Anyone have a clue? Received: from myhostname.my.isp.com ([EMAIL PROTECTED] [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with +ESMTP id f3QDlYZ2018784 for [EMAIL PROTECTED]; Thu, 26 Apr 2001 07:47:34 +-0600 Suddenly here the email is address to [EMAIL PROTECTED] while in the previous line: Received: (from [EMAIL PROTECTED]) by myhostname.my.isp.com (8.12.0.Beta7/8.12.0.Beta7/Debian +8.12.0.Beta7-1) id f3QDkJuS015600 for [EMAIL PROTECTED]; Thu, 26 Apr 2001 07:46:19 -0600 Here it's addressed to [EMAIL PROTECTED] So I would assume that something on myhostname.my.isp.com is rewriting the email @debian.org to @klecker.debian.org. And I don't think that this localpart apenwarr-survey is available in the sub-domain klecker.debian.org but instead in the domain debian.org. So I would suggest that the configuration of this mail-server myhostname.my.isp.com will be checked to see why suddenly the rcpt-to changes. Please look at the following: $ host -v -t MX -A debian.org Query about debian.org for record types MX Found 1 address for debian.org Checking debian.org address 198.186.203.20 !!! debian.org address 198.186.203.20 maps to klecker.debian.org $ host -v -A http.us.debian.org [...] So, mail to debian.org is the same as mail to klecker.debian.org No! This is absolutely wrong. The output just shows that the MX (Mail-Exchange) for the domain debian.org is klecker.debian.org. This has absolutely nothing to do with the email-address under the domain @debian.org. Never assume from an MX output something about the mail-address and local-parts in a domain and/or it's subdomains. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpCoX7U7Qe36.pgp Description: PGP signature
Re: Lightweight Web browsers
On 01-04-27 Jérôme Marant wrote: Christian Kurz [EMAIL PROTECTED] writes: May I ask why you don't mention that this is a web browser for Gnome? This information would be helpful for people that look for a lightweight HTML browser, but don't want to install Gnome. For those people this browser will not be a alternative, since it pulls in the whole bunch of gnome libs. :( I mainly focused on low memory consumption, and Encompass meet this requirement. Since maybe it wasn't obvious. I quite like to see software and especially a web browser that doesn't use much memory. Then, mentioning Gnome usually make people think that the Gnome Desktop Environment is required to run the browser which is not the case. Well, I think that's a wrong assumption that people make, but you can't change it. So maybe it should have been worded mentioned the dependency on the gnome libs. And unless you have disk space restrictions, I don't see the problem with installing gnome libs since these are shared between a growing number of applications. (Political reasons for not installing Gnome are not good reasons) Sarcasm So come on people, let's install all 6000 packages, because maybe we could use them once. /Sarcasm Well, I just try to keep my system as clean as possible, which includes for me that I also check the installed libraries. And every time I try one of those gnome apps, I'm astonished about the big bunch of libraries that I have to install. Therefor I would prefer applications that just depend on the GTK Libraries and not the Gnome-Libraries. Therefor I would prefer it to know in advance if an ITP'ed software could become interesting for me or not. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpyWb9Ik8b2E.pgp Description: PGP signature
Re: Lightweight Web browsers
On 01-04-27 Jérôme Marant wrote: Christian Kurz [EMAIL PROTECTED] writes: Sarcasm So come on people, let's install all 6000 packages, because maybe we could use them once. /Sarcasm Listen, I've packaged it in order to make available in debs for people willing to test it. Now, don't blame me about those gnome dependencies since I'm not upstream. APT is ment to show you packages to be installed and does not force you to install. He, I didn't blame you or anyone else for this, I just used some sarcasm around your statement about disk space. And apologies for not mentioning Gnome ... (since it seemed to bother you) Not only me. It's just that the Gnome Libaries install a bunch of packages and also need quite some disk-space. Therefor I and I think some other people too would like to know before if the software depends on that bunch of libraries or not. Well, I just try to keep my system as clean as possible, which includes for me that I also check the installed libraries. And every time I try one of those gnome apps, I'm astonished about the big bunch of libraries that I have to install. Therefor I would prefer applications that just depend on the GTK Libraries and not the Gnome-Libraries. Therefor I would prefer it to know in advance if an ITP'ed software could become interesting for me or not. Please note that did not ITPed it since I'm not sure people except from me are interested in such a browser. And It does not seem to make you very happy. Unless people are interested to see it in debian I won't upload it. Sorry, I forgot that when I wrote my statement. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpc4qKV4tspW.pgp Description: PGP signature
Re: Lightweight Web browsers
On 01-04-26 Jérôme Marant wrote: However, I found a simple HTML browser called Encompass that takes far less memory than those I mentioned. Of course, it does not have all the feature these browsers can offer but it does handle HTML pretty well. I've build debs you can find there: May I ask why you don't mention that this is a web browser for Gnome? This information would be helpful for people that look for a lightweight HTML browser, but don't want to install Gnome. For those people this browser will not be a alternative, since it pulls in the whole bunch of gnome libs. :( Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpPOddeUQNTn.pgp Description: PGP signature
Re: lilo.conf
On 01-01-06 Matt Zimmerman wrote: On Sat, Jan 06, 2001 at 05:40:53PM +0100, Christian Kurz wrote: On 01-01-06 Matt Zimmerman wrote: On Sat, Jan 06, 2001 at 01:58:48PM +0100, Cosimo Alfarano wrote: On Sat, Jan 06, 2001 at 01:33:57PM +0100, Peter Makholm wrote: Don't assume devfs! A lot of us uses it, but before our standard kernel uses it our lilo package shouldn't assume it unless it is very sure that it will work. He shouldn't assume it even if debian standard kernel package uses it. A lot of users don't use them (both std kernel and devfs). Especially since devfs support is still considered experimental. Hm, it's not marked as experimental in kernel 2.4.0, but as work in progress. So support for it would be really good. mizar:[~/src/linux/2.4.0/linux] egrep 'VERSION|LEVEL' Makefile | head -3 VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 0 mizar:[~/src/linux/2.4.0/linux] grep -B 1 ^CONFIG_DEVFS_FS Documentation/Configure.help /dev file system support (EXPERIMENTAL) CONFIG_DEVFS_FS mizar:[~/src/linux/2.4.0/linux] grep ' CONFIG_DEVFS_FS ' fs/Config.in dep_bool '/dev file system support (EXPERIMENTAL)' CONFIG_DEVFS_FS $CONFIG_EXPERIMENTAL It will only show up if CONFIG_EXPERIMENTAL is defined. Hm, did you bother to read the explanation of devfs? There you find a statement, that is work in progress and so I wouldn't consider it experimental anymore. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpSdxtwDxNdz.pgp Description: PGP signature
Re: (open)ssh-2.3.0p1 when??
On 01-01-07 Brian Frederick Kimball wrote: Damian M Gryski wrote: On Sun, 07 Jan 2001, Svante Signell wrote: Is openssh ever going to be upgraded? Latest unstable version is 2.2.0p1-1.1 from September? while the latest OpenBSD release is now 2.3.0p1! Maybe the package also should change name from ssh to openssh. openssh 2.3.0p1 was installed into unstable (sid) on Dec 30. Huh? Where did you got this information? There was only an upload to non-us on Dec 30. Just uploaded or actually installed? It didn't show up on non-us.debian.org until today (Jan 7th). I think the package should show up soon on non-us. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Re: Upcoming Events in Germany
On 01-01-06 Goswin Brederlow wrote: == Martin Schulze [EMAIL PROTECTED] writes: July 5-8 LinuxTag 2001, Stuttgart http://www.linuxtag.org/ http://www.infodrom.ffis.de/Debian/events/LinuxTag2001/ Already planed to be there. I will be there any way, but I have to work out some other things before. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpQ1JrRxlart.pgp Description: PGP signature
Re: lilo.conf
On 01-01-06 Matt Zimmerman wrote: On Sat, Jan 06, 2001 at 01:58:48PM +0100, Cosimo Alfarano wrote: On Sat, Jan 06, 2001 at 01:33:57PM +0100, Peter Makholm wrote: Don't assume devfs! A lot of us uses it, but before our standard kernel uses it our lilo package shouldn't assume it unless it is very sure that it will work. He shouldn't assume it even if debian standard kernel package uses it. A lot of users don't use them (both std kernel and devfs). Especially since devfs support is still considered experimental. Hm, it's not marked as experimental in kernel 2.4.0, but as work in progress. So support for it would be really good. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpE1qLPfiAvx.pgp Description: PGP signature
Re: Anybody seen Loic Prylli lately?
On 01-01-04 Chuan-kai Lin wrote: Does anyone know where Loic has been lately (i.e., for the past two years or so)? AFAIK his last package upload was in November 1998, and the mail I sent him about whether he needs help with mailx has generated no reply. Since mailx is important, if the maintainer is indeed MIA, somebody should take over this package and jove. I would volunteer for mailx in the unlikely event that nobody else wants that package. If you would have looked into unstable first, you would have noticed that jove has been taken over by Cord Beermann, an upcoming new maintainer and I had once a contact with Loic to talk with him about his jove package. Now I'm waiting for his answer about mailx, so please wait some time more, so that I be able to get an answer from him. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Re: List of packages that could be dropped
On 00-12-28 Wichert Akkerman wrote: Previously Christian Kurz wrote: |dpkg-scriptlib -- dpkg-perl and dpkg-python (142 days old) Is any package using functions of dpkg-perl or dpkg-python? If yes, I think someone should take care of this packages and the bugs that are in them. If not, could we move this packages from our distribution to experimental until they are fixed and a new maintainer for them has been found? tetex depends on dpkg-perl. Hm, could this be the scripts written in sh-syntax. If I remember correctly, they are just doing some file-test and linking. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpJb9CsGL9L5.pgp Description: PGP signature
Re: List of packages that could be dropped
On 00-12-26 Ben Collins wrote: On Tue, Dec 26, 2000 at 03:22:21PM +0100, Christian Kurz wrote: |silo (195 days old) Has this package been removed from unstable and if yes, why? It's currently still listed in the wnpp but I could find it which apt-cache search silo. You can only remove this if you want sparc to be unbootable, which I hope is not your intention. If it's so important why is still marked as orphaned in wnpp? Or has already some taken over maintainership and just forgotten that there exists the WNPP? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp2Ry7P82p50.pgp Description: PGP signature
Re: List of packages that could be dropped
On 00-12-27 Jonathan McDowell wrote: On Tue, Dec 26, 2000 at 06:59:16PM -0500, Ben Collins wrote: On Tue, Dec 26, 2000 at 03:22:21PM +0100, Christian Kurz wrote: |silo (195 days old) Has this package been removed from unstable and if yes, why? It's currently still listed in the wnpp but I could find it which apt-cache search silo. You can only remove this if you want sparc to be unbootable, which I hope is not your intention. Um, I was going to adopt this until I saw: silo (0.9.9-1) unstable; urgency=low * New upstream * Took over silo's packaging -- Erick Kinnee [EMAIL PROTECTED] Mon, 4 Sep 2000 10:54:23 -0500 Which I assumed meant Erick had done so? Well, if this is really true, then he should have closed the WNPP bug against silo a long time ago already. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp3Vw46FI7BV.pgp Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On 00-12-25 Matt Zimmerman wrote: On Mon, Dec 25, 2000 at 01:29:44PM +, Marc Haber wrote: On Sat, 23 Dec 2000 15:41:54 -0500, Matt Zimmerman [EMAIL PROTECTED] wrote: However, I would say that if the program dies so frequently that it needs a wrapper like this, it should probably be fixed. console-log uses less syslog which dies every time the user types Q. And it needs to die if the log has been rotated. It would be nice if less included a feature to close and reopen the current file. Then this would not be necessary. Well, this is a feature that tail on FreeBSD has. If you start it with -F, it will tail you the current file like our tail -f. But if know the logfile will be rotated, it will notice this and reopen the new current one and tail this one. This is a feature that I really miss in GNU tail. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTPZeKJ9TrV.pgp Description: PGP signature
List of packages that could be dropped
Hi, we currently have a really huge list of packages that are orphaned and so I looked at them to see if we can drop some of them. Here are some suggestion and my comments. Any comment from you is appreciated: |ppd-gs (1 year and 357 days old) Do we really need this package still for users of alladin ghostscript or is it not needed anymore? |tcp4u (1 year and 81 days old) [Package libtcp4u3] Is this package still useful or can we drop it? |cthugha (1 year and 31 days old) Is this package really used by someone or useful for anything? The description is not very helpful in finding this out. |silo (195 days old) Has this package been removed from unstable and if yes, why? It's currently still listed in the wnpp but I could find it which apt-cache search silo. |dip (1 year and 81 days old) Fabrizio, has this package really been taken over? If yes, could you please close the wnpp-bug for it? Thanks. |libmikmod (214 days old) Is any architecture still using libmikmod1 or could we drop this part of the libmikmod package? |rel (1 year and 41 days old) Is this package used by anyone or can we just drop it? |mhash (235 days old) Has this package been dropped from unstable? If yes, can we close the wnpp-bug about it? |guavac (2 years and 53 days old) Can we please drop this package from our distribution as even upstream orphaned this package? |malaga (210 days old) Has this package been dropped? If yes, why and could be please close then the bug about it against wnpp? |admesh (349 days old) Has this package any good purpose or could it be dropped? |dpkg-scriptlib -- dpkg-perl and dpkg-python (142 days old) Is any package using functions of dpkg-perl or dpkg-python? If yes, I think someone should take care of this packages and the bugs that are in them. If not, could we move this packages from our distribution to experimental until they are fixed and a new maintainer for them has been found? |fnlib (104 days old) Has this package been removed from our distribution? is enlightenment not using it anymore? Or has it just be renamed? If the first is true, can we close the wnpp bug for it or if the last is true, can then someone please rename the bug in wnpp for it? |xipmsg (74 days old) Is this piece of software really used this days, where we have, ICQ,AIM,Jabber and other instant messenger tools? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpkAkyvCViB5.pgp Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On 00-12-26 Andreas Fuchs wrote: Today, Christian Kurz [EMAIL PROTECTED] wrote: Well, this is a feature that tail on FreeBSD has. If you start it with -F, it will tail you the current file like our tail -f. But if know the logfile will be rotated, it will notice this and reopen the new current one and tail this one. This is a feature that I really miss in GNU tail. Uh, is this what you mean? $ echo bar /tmp/foo $ tail -f /tmp/foo (sleep 1; echo baz /tmp/foo; sleep 1; echo qux /tmp/foo) bar[time passes] baz[time passes] == /tmp/foo: file truncated == No, because you truncate the file here and that shouldn't happen. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpl4AsasGZgg.pgp Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On 00-12-26 Ethan Benson wrote:
On Tue, Dec 26, 2000 at 12:26:10PM +0100, Christian Kurz wrote:
Well, this is a feature that tail on FreeBSD has. If you start it with
-F, it will tail you the current file like our tail -f. But if know the
logfile will be rotated, it will notice this and reopen the new current
one and tail this one. This is a feature that I really miss in GNU tail.
in fact GNU tail does have this feature, its just done a bit
differently:
tail --follow=name --retry /var/log/messages
ive been using this for ages without any problems, works quite nicely
with log rotation, tail just outputs a message saying the file has
been replaced, and follows the new one.
Well, as I'm a bit lazy in typing always this long option names, I just
wrote a patch to support -F and --follow-forever that do the same. As
the patch is very small, I will just attach it to this mail. (Yes, I
will seperately send it to the BTS.)
Ciao
Christian
--
Debian Developer and Quality Assurance Team Member
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Binary files textutils-2.0.old/src/.tail.c.swp and
textutils-2.0/src/.tail.c.swp differ
diff -uNr textutils-2.0.old/src/tail.c textutils-2.0/src/tail.c
--- textutils-2.0.old/src/tail.cThu Aug 5 16:38:02 1999
+++ textutils-2.0/src/tail.cTue Dec 26 17:33:25 2000
@@ -187,6 +187,7 @@
{allow-missing, no_argument, NULL, CHAR_MAX + 1},
{bytes, required_argument, NULL, 'c'},
{follow, optional_argument, NULL, 'f'},
+ {follow-forever, optional_argument, NULL, 'F'},
{lines, required_argument, NULL, 'n'},
{max-unchanged-stats, required_argument, NULL, CHAR_MAX + 2},
{max-consecutive-size-changes, required_argument, NULL, CHAR_MAX + 3},
@@ -1311,7 +1312,7 @@
count_lines = 1;
forever = from_start = print_headers = 0;
- while ((c = getopt_long (argc, argv, c:n:f::qs:v, long_options, NULL))
+ while ((c = getopt_long (argc, argv, c:n:f:F::qs:v, long_options, NULL))
!= -1)
{
switch (c)
@@ -1357,6 +1358,11 @@
follow_mode = XARGMATCH (--follow, optarg,
follow_mode_string, follow_mode_map);
break;
+
+ case 'F':
+ forever = 1;
+ follow_mode = Follow_name;
+ reopen_inaccessible_files =1;
case CHAR_MAX + 1:
reopen_inaccessible_files = 1;
pgpjEdviCRNa3.pgp
Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On 00-12-26 Matt Zimmerman wrote: On Tue, Dec 26, 2000 at 12:26:10PM +0100, Christian Kurz wrote: On 00-12-25 Matt Zimmerman wrote: It would be nice if less included a feature to close and reopen the current file. Then this would not be necessary. Well, this is a feature that tail on FreeBSD has. If you start it with -F, it will tail you the current file like our tail -f. But if know the logfile will be rotated, it will notice this and reopen the new current one and tail this one. This is a feature that I really miss in GNU tail. It sounds pretty easy to implement; just stat() and compare the inode number. Is this how the FreeBSD tail does it? Why not write a patch for GNU tail? I'm not sure how FreeBSD tail handle this exactly, as I didn't look at it's code till now. But after having read the Mail from Ethan I think about patching tail to have an option -F which combines --follow=name and --retry. :) Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpFL4vjQnvNg.pgp Description: PGP signature
Re: Scsh (Was: Re: My orphaned packages.)
On 00-09-12 Daniel Kobras wrote: On 11 Sep 2000, Karl M. Hegbloom wrote: Daniel == Daniel Kobras [EMAIL PROTECTED] writes: Daniel On 10 Sep 2000, Karl M. Hegbloom wrote: `scsh' ought to be taken over by someone who actually uses it. I've not even looked at it in over a year. Daniel If nobody objects I'd like to do this together with Martin Daniel Gasbichler who wrote a fair part of scsh 0.6. But me Daniel having just applied for Debian maintainership this will Daniel take some time... I also have an adoption offer from Georg Bauer (Cc'd), who I responded to on the attached message, telling him that if he contacts the new maintainer team and has a working `scsh' package, he can have it. Since you are teaming with Martin Gasbichler, and since Martin is a co-author of Scsh, I'd say that puts you two in as most qualified to handle the package. (Daniel? Please forward this mail to Martin.) Perhaps the three of you could team? What do you all think? Sounds good to me. Martin is on vacation for a couple of days but I'm sure we can work out a scheme everyone's confident with as soon as he's back. The big problem IMHO however being that neither of us is registered as a developer so far. I'd be happy to work on debs for a recent version of scsh but we'd really need some maintainer to adopt the package until my appliance gets through. You don't need a package maintainer to adopt the package for getting a new package uploaded. A sponsor for you and Martin would be enough to upload the package to the archive. Do you already are in the NM-Queue (nm.debian.org)? Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I propose gazillion packages (LONG)
On 00-08-17 Juhapekka Tolvanen wrote: AIDE: http://www.cs.tut.fi/~rammer/aide.html |[EMAIL PROTECTED] apt-cache show aide |Package: aide |Version: 0.7-6 |[...] |Maintainer: Mike Markley [EMAIL PROTECTED] boxes: http://www6.informatik.uni-erlangen.de/~tsjensen/boxes/ |[EMAIL PROTECTED] apt-cache show boxes |Package: boxes |Version: 1.0.1-1 |[...] |Maintainer: KELEMEN Peter [EMAIL PROTECTED] QuickList: http://www.quicklist.org/ |[EMAIL PROTECTED] apt-cache show quicklist |Package: quicklist |Version: 0.8.6-2 |[...] |Maintainer: Bradley Bell [EMAIL PROTECTED] Artistic Style: http://astyle.sourceforge.net/ |[EMAIL PROTECTED] apt-cache show astyle |Package: astyle |Version: 1.11.6-1 |[...] |Maintainer: Sean 'Shaleh' Perry [EMAIL PROTECTED] deroff: http://www.moria.de/~michael/deroff/ |[EMAIL PROTECTED] apt-cache show deroff |Package: deroff |Version: 1.1-2 |[...] |Maintainer: David Frey [EMAIL PROTECTED] mp3_check: http://mp3check.sourceforge.net/ |[EMAIL PROTECTED] apt-cache show mp3check |Package: mp3check |Version: 1.97-1 |[...] |Maintainer: Norbert Tretkowski [EMAIL PROTECTED] So, may I suggest that in the future you first check which software is already packaged for debian? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp3Pg7FzA5FF.pgp Description: PGP signature
Re: ITP John the ripper
On 00-03-26 Matt Zimmerman wrote: On Sat, Mar 25, 2000 at 03:39:24PM +0100, Christian Kurz wrote: as jsut discussed on debian-devel, I would like to package John the Ripper. If someone already has done or is working on it, please mail me, then I will stop packing it. Otherwise I will try to upload this package till friday next week to woody. I briefly looked into packaging this a while ago, and I couldn't find a license in the distribution. Are you aware of a license for this program, or have you contacted the upstream author? After talking with the upstream author, this program has now been packaged for debian is available on master in incoming. Ciao Shorty -- Debian Developer and Quality Assurance Committee Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpjFlyBK8R4l.pgp Description: PGP signature
Re: ITP John the ripper
On 00-03-26 Josip Rodin wrote: On Sun, Mar 26, 2000 at 11:15:20AM -0500, Matt Zimmerman wrote: as jsut discussed on debian-devel, I would like to package John the Ripper. If someone already has done or is working on it, please mail me, then I will stop packing it. Otherwise I will try to upload this package till friday next week to woody. I briefly looked into packaging this a while ago, and I couldn't find a license in the distribution. Are you aware of a license for this program, or have you contacted the upstream author? A friend of mine asked Solar Designer, and he said it's GPL or something... Well, I asked him to add a note to the package which describes the license of the package. Hopefully I can convince him to do so, so that I or somebody else are able to package it. Ciao Christian -- Debian Developer and Quality Assurance Committee Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTzLlSmhIAw.pgp Description: PGP signature
ITP John the ripper
Hi, as jsut discussed on debian-devel, I would like to package John the Ripper. If someone already has done or is working on it, please mail me, then I will stop packing it. Otherwise I will try to upload this package till friday next week to woody. Ciao Christian -- Debian Developer and Quality Assurance Committee Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTYeO90YH8l.pgp Description: PGP signature
Re: ITO penguineyes and bvi
On 99-09-23 Stijn de Bekker wrote: On Tue, Sep 21 1999, Christian Kurz wrote: I intent to orphan bvi and penguineyes. I will orphan bvi, because I don't use it much anymore and penugineyes will get orphaned, because I gave gnome I try, but I don't like it much and so I want to remove it, which makes packaging penguineyes a bit hard. If somebody wants to take one of the packages over, feel free to do so. I'll take over the bvi package. Remco van de Meent has already offered to sponsor as I'm no official maintainer yet. Okay, it's yours. Ciao Christian -- * Christian Kurz Debian Developer/QA-Team * * Use Debian - a free Operating System * pgprMVzlURAiQ.pgp Description: PGP signature
ITO penguineyes and bvi
Hi, I intent to orphan bvi and penguineyes. I will orphan bvi, because I don't use it much anymore and penugineyes will get orphaned, because I gave gnome I try, but I don't like it much and so I want to remove it, which makes packaging penguineyes a bit hard. If somebody wants to take one of the packages over, feel free to do so. Ciao Christian -- * Christian Kurz Debian Developer/QA-Team * * Use Debian - a free Operating System *
Request for Packaging
Hi, here are some collected request for programms, which should IMHO be packaged for Debian: 8-8 CUT HERE 8-8 What's bjorb? Overview Bjorb is secure TCP relay software. Bjorb provides to you secure end-to-end connection over insecure network such as Internet. Highlights * Bjorb relays all 'static port' based TCP communications with SSL protocol. Such as SMTP, POP3, NNTP, HTTP, TELNET. Not FTP. * Bjorb can make a usual telnet server behave like SSL telnet. License Bjorb itself is free software. You can use, modify, and redistribute for non-commerical and commerical purpose in most case. Read COPYRIGHT file for more details. Bjorb uses SSLeay library. 8-8 CUT HERE 8-8 PGP Moose / by Greg Rose [EMAIL PROTECTED] The aim of this software is to monitor the news postings of moderators of USENET newsgroups, and to automatically cancel forged messages purporting to be approved. This can be extended to the approvals of individual users to automatically cancel messages that appear without having been authorised by the user. This has (obviously) been prompted by the recent spammings and other events. This software and protocol is designed around cryptographic signatures. The protocol is designed to allow the use of different signature techniques. This implemention assumes the use of PGP signatures, but can be easily modified to use others, such as the Digital Signature Standard. PGP was chosen for its widespread availability around the world. PGP, the crux of the cryptographic software, was written by Phil Zimmermann [EMAIL PROTECTED], who otherwise has nothing to do with this. The cryptographic framework was written by Greg Rose [EMAIL PROTECTED], as were the INN news system hooks. http://people.qualcomm.com/ggr/PGPMoose.tar.Z ftp://ftp.dinoex.sub.de/pub/approved/PGPMoose.tar.Z 8-8 CUT HERE 8-8 Dejasearch A frontend to DejaNews (http://www.dejanews.com/), the popular Usenet archive and search engine. It will submit a search for you to DejaNews, then retrieve and consolidate all search results into one single HTML file, sorted in newsgroup, subject and date (reverse) order. http://homemade.hypermart.net/dejasearch/dejasearch12.tar.gz http://homemade.virtualave.net/dejasearch/dejasearch12.tar.gz 8-8 CUT HERE 8-8 mkmf makefile editor (revision 4.11) ftp://ftp.uni-koeln.de/util/mkmf.tar.gz 8-8 CUT HERE 8-8 Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
[DONT SEND ME A CC!] Dale Scheetz [EMAIL PROTECTED] wrote: On Wed, 19 May 1999, Christian Kurz wrote: [You don't need to send me an extra Cc as I read the lists on which I write. Thanks!] Dale Scheetz [EMAIL PROTECTED] wrote: On Wed, 19 May 1999, Christian Kurz wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. I would rather see the old bugs closed. An old bug is still a bug. Don't like the messages, help close the bugs. Wrong. Brian White is no longer the release manager, so he has no special privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. No one needs to take on that job, as the BTS already reports all open bugs twice a week to every developer. Are you sure? I don't know that this is done by the BTS and have never heard about this? Here is a sample of the beggining of what I normally get on Tuesdays: -begin paste- Date: Tue, 4 May 1999 16:29:46 -0500 From: Debian Bug Tracking System [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Unanswered problem reports by maintainer and package Resent-Date: 4 May 1999 21:30:06 - Resent-From: [EMAIL PROTECTED] Resent-cc: recipient list not shown: ; The following problem reports have not yet been marked as `taken up' by a message to [EMAIL PROTECTED] or or `forwarded' by a message to [EMAIL PROTECTED] ---end paste-- Note that this is a subscription list, so you must request placement on this automated report generator. Hm, this looks for me like you use a cronjob to fetch your bugreports. Or where is this described? On Friday the report is ordered differently, and can be grepped for your name to separate out your own bugs from all the rest. Hm, sound interesting. You can also request limited reports on your own. Send the word help in the body of a message to [EMAIL PROTECTED] and you will get a list of all the commands that the request server responds to. Among them are requests for indexes by package, or by maintainer. You can then take these indexes and request the actual bug report itself. Oh so you need to set this up on your own? There's only one point which I'm missing: How many maintainers use this? Is this used by nearly every maintainer or only some? I think we need a mechanismen, which is configurable, which automatically tells you after some time which bugs are open and need to be closed. So you are automatically subsribed to these messages, but you can stop it if you want. If this was simply a report to the list, once in a while, like the critical bugs that need to be fixed list, there would be no problem. Instead this mail is generated automatically and sent to every developer with an open bug report over a certain age. Well what is the problem with this? I don't see any offence in getting a message that says that I (the maintainer) has still open bug over a certain age. I think this is a good reminder for the maintainers as you The problem is that I can not request that the messages stop, like I can with this list, and the other BTS lists. Even aggressive, and angry requests have met with rejection. This is, by definition, unwanted spam. So why don't we contact Brian and ask him about making this configurable? Has anyone contacted him yet about this? If not, I will write him a mail at the weekend. may forget to fix bugs. Take a look at the ppp-package and how many open bugs there have been. The maintainer hadn't fixed them and so I helped him. (Sorry Phil, but this is a good example and No, I don't want to praise me with this). Or have you taken a look at the list on http://master.debian.org/~ajt/bugsbyage.txt? Have you seen how many open old bugs we got? How do you think we get this fixed without reminding the developers of their open bugs? How do the nag messages to Phil help you know which of his bugs are in need of repair. I meant that this messages are good for a maintainer who had so many open bugs to see which bugs he need to fix and maybe ask others to help him. It was not about me. Your idea that mainainers forget to fix a bug is simply FUD. Nobody forgets a bug, they either don't have the time to figure out what is wrong, or for what ever reason cannot put the manpower into solving the problem. Under these conditions a NMU is very reasonable. I never turn down such help
Re: request to kill nag messages
Christian Meder [EMAIL PROTECTED] wrote: On Wed, May 19, 1999 at 09:24:19PM +0200, Christian Kurz wrote: Well what is the problem with this? I don't see any offence in getting a message that says that I (the maintainer) has still open bug over a certain age. I think this is a good reminder for the maintainers as you may forget to fix bugs. Take a look at the ppp-package and how many open bugs there have been. The maintainer hadn't fixed them and so I helped him. (Sorry Phil, but this is a good example and No, I don't want to praise me with this). Or have you taken a look at the list on http://master.debian.org/~ajt/bugsbyage.txt? Have you seen how many open old bugs we got? How do you think we get this fixed without reminding the developers of their open bugs? I think you miss the point. Nobody's arguing that we shouldn't keep a public list of open old bugs. For interested developers it makes sense to do some qa after checking such a list. ACK The point is that the diligent maintainer is well aware of his/her open old bug reports and usually has some valid reasons to leave the bug report open. Then why doesn't he place a message in the BTS saying why it isn't possible to fix the bug? So that people lookin throught the BTS see, if they can help to fix the bug or if this isn't possible? Example: I've got an open old bug report that flying (a X11 pool game) doesn't support 16/24 bit displays. The upstream This would speak for making the mechanismen configurable. Would this be a solution? Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Christian Meder [EMAIL PROTECTED] wrote: On Thu, May 20, 1999 at 11:48:25AM +0200, Christian Kurz wrote: Christian Meder [EMAIL PROTECTED] wrote: Example: I've got an open old bug report that flying (a X11 pool game) doesn't support 16/24 bit displays. The upstream This would speak for making the mechanismen configurable. Would this be a solution? Making which mechanism configurable ? The bug system ? The nag messages ? Could you expand what you are aiming at ? I meant the nag-messages about which we are talking here. Would be a solution to make it configurable if you want to get those or not? Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Branden Robinson [EMAIL PROTECTED] wrote: On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. I would rather see the old bugs closed. An old bug is still a bug. Don't like the messages, help close the bugs. Wrong. Brian White is no longer the release manager, so he has no special privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. This is no different from some helpful developer spamming people who, say, have had bugs open for over a year. Such people have (rightly) come under fire in the past. And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
[You don't need to send me an extra Cc as I read the lists on which I write. Thanks!] Dale Scheetz [EMAIL PROTECTED] wrote: On Wed, 19 May 1999, Christian Kurz wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. I would rather see the old bugs closed. An old bug is still a bug. Don't like the messages, help close the bugs. Wrong. Brian White is no longer the release manager, so he has no special privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. No one needs to take on that job, as the BTS already reports all open bugs twice a week to every developer. Are you sure? I don't know that this is done by the BTS and have never heard about this? If this was simply a report to the list, once in a while, like the critical bugs that need to be fixed list, there would be no problem. Instead this mail is generated automatically and sent to every developer with an open bug report over a certain age. Well what is the problem with this? I don't see any offence in getting a message that says that I (the maintainer) has still open bug over a certain age. I think this is a good reminder for the maintainers as you may forget to fix bugs. Take a look at the ppp-package and how many open bugs there have been. The maintainer hadn't fixed them and so I helped him. (Sorry Phil, but this is a good example and No, I don't want to praise me with this). Or have you taken a look at the list on http://master.debian.org/~ajt/bugsbyage.txt? Have you seen how many open old bugs we got? How do you think we get this fixed without reminding the developers of their open bugs? This is no different from some helpful developer spamming people who, say, have had bugs open for over a year. Such people have (rightly) come under fire in the past. And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. This is not a person asking a developer to fix a bug. This is an automated system that spits out messages with NO content of use to the developer, and adds nothing but bulk to the already functional system. Where has the message no content? It tells you which bugs are very old and haven't been fixed, so you can take a look at them and fix them. And the point that this is an automated system doing this is IMHO no cause to treat them like spam. It's has been automated as a normal person can't to this on her own. This _is_ spam, and nothing more. Please be aware that any message with the word Nag in the subject is always deleted and never read when sent to me, so if you really want to contact me don't use that word ;-) Well, that's you problem, but better would be a kill on the From-Line instead of the Subject. You aren't really suggesting that any well meaning person is correct to set up an automated system for notifying developers about place your important issue here, then you should not complain when some dodo sends you, and the list, critical information about how to get rich quick. He is only trying to be informative... Well, I don't like spam as it has nothing to do with my work or my hobby. But these messages are there for informing me, that I have open bugs and that I need to fix them. So it's a reminder for me as developer. Or how should we remind developer of their old bugs? Go by hand through the BTS and sort them out? Are you sure that every developer knows which open bugs he has and how old they are? I'm not and since the messages are not send every day or every week or every month but instead after a certain amount of time, more than 4 months, I don't treat them like spam. Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Brian Almeida [EMAIL PROTECTED] wrote: On Wed, May 19, 1999 at 04:45:11PM +0200, Christian Kurz wrote: And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. Considering the X bug list, I'm sure branden got a quite large mailing from 'Nag' about old bugs - yet from what I understand, he can't possibly go through that list until some modifications are done to the BTS. Hm, in the list from NAG are the URLs which lead to the page with the bugreport on it. So what modifications need to be done for making these messages usable? 'Nag' also goes to developers personally, not only to -devel. So where's the problem with getting an reminder about your old open bugs, which you need to fix? Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Brian Almeida [EMAIL PROTECTED] wrote: On Wed, May 19, 1999 at 09:28:33PM +0200, Christian Kurz wrote: So where's the problem with getting an reminder about your old open bugs, which you need to fix? I don't NEED a reminder about my bugs. There should be an option to TURN THE BLOODY THING OFF. OK, this would be a good point. Making it configurable if you want to get those messages or not. But in general I don't think that should be turned off. Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Adrian Bridgett [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. No, these bugs are also important and need to be resolved as every bug. The decision which bugs are important does not depend on the age. And the nag-messages to this list has come, as the bugs are general bugs and there's no developer for them. Every developer can fix those bugs and so it's a good to sent this message to the list. Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
