Accepted supercat 0.5.5-4.3 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 03 Aug 2016 02:45:30 +1000 Source: supercat Binary: supercat Architecture: source amd64 Version: 0.5.5-4.3 Distribution: unstable Urgency: medium Maintainer: Kumar Appaiah <aku...@debian.org> Changed-By: Craig Sanders <c...@taz.net.au> Description: supercat - program that colorizes text for terminals and HTML Changes: supercat (0.5.5-4.3) unstable; urgency=medium . * Non-maintainer upload * added automake to Build-Depends for /usr/bin/aclocal Checksums-Sha1: 1a520697b68abec650b1067a9f81f0a9b48eb5a0 1844 supercat_0.5.5-4.3.dsc 665b0ce3008d03cc57382bfbf59dce79f2ccae7e 5488 supercat_0.5.5-4.3.debian.tar.xz 1c1adce46f4d7b29f4a7313e3abf8be4480b37b0 17944 supercat_0.5.5-4.3_amd64.deb Checksums-Sha256: f1b629ea50d6829b6ce0f764b539ac475baeaad854237b9a35bd8e6bb65e6817 1844 supercat_0.5.5-4.3.dsc 2d10e8e1dc9de3c44514122cf9e822ca0d6811ea7596a90e7ee5a8409a97594c 5488 supercat_0.5.5-4.3.debian.tar.xz 0c3c472936a55a33fa8f7b802a6f2644f93f55d389e4a4a727af724a7469eb39 17944 supercat_0.5.5-4.3_amd64.deb Files: 96b107d2aef22fd27a2afff3f4b0762e 1844 utils optional supercat_0.5.5-4.3.dsc 4982c7d510cd055d1ceecbd5f6ef4940 5488 utils optional supercat_0.5.5-4.3.debian.tar.xz d1f2d728910bcaba48eb4bba9460c721 17944 utils optional supercat_0.5.5-4.3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXoM60AAoJEGNJDgVeB3TFpugP/RhBFLZPtgabecxKQQkxC74v 050Z2A0r4nuLDecctJ+q085a4x/FX67/tdEGlCzSPgi87rvoQCP6PdxVPqICRoCy jvyI3zTomWrQ4/Xks4e4kzNuYONR+MydcYZQA0HuUECjxOYGjv0fnl0bek8Eb9Gs GBeZGclkcbXDAllWVZo1BckpG/CJN4ADEju7UfzapDI3nVmLvwYKrghowfKfixy9 g+thlsKaW5PGTY+aI74F2GLzKia7blefNQWjMfx5Bl3iBmCC1zJB5R9Y9WwD8Nv8 +PHjAyPQVYjKMfJ07kznZI8TmDRam6dXn3uSmaxusy57IEwp8U5SYkByJxk/RHJd 43gJIRXtYJbiOsdN70IrgR9xR6r5Aq6NeF+dxVXw8OlWFJGN7biPRGeyzMXzChJQ apcQJIrVanc/MMwn2R8pLcpxswiIy9C4Dd8F5Eh3Mrewqso+m3S4VNSdWNSCMspj bRNPG6bufFeP+gUGmd4dpFvtNBWerwIxYNbdE++DDWeZn56fhKtTONapu7MPZs+W F0xooe7MCmnFPfKzAAaS1kne5Rxkb9vb4IEbzZJxnse02XbfOBlXVW0FXhMm1jA+ Jj/ceKW72z/4/AVTobFe4X486bdngLCVzc7txgi7JeHQ49x7yhE+xSMWzMPCAUNz gH7gpfJWZuncSYb6JsDC =L3CB -END PGP SIGNATURE-
Accepted supercat 0.5.5-4.2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 03 Aug 2016 01:53:39 +1000 Source: supercat Binary: supercat Architecture: source amd64 Version: 0.5.5-4.2 Distribution: unstable Urgency: medium Maintainer: Kumar Appaiah <aku...@debian.org> Changed-By: Craig Sanders <c...@taz.net.au> Description: supercat - program that colorizes text for terminals and HTML Changes: supercat (0.5.5-4.2) unstable; urgency=medium . * Non-maintainer upload * added autoconf to Build-Depends for autoupdate and autoreconf Checksums-Sha1: 45c94c55116c2503acd91552894e4315338832c0 1834 supercat_0.5.5-4.2.dsc 159166c16c40088492a13bf7e1cd8cc167d834bc 5468 supercat_0.5.5-4.2.debian.tar.xz a9d7831673d5715d703d9d0c403d2b754b15dc48 17912 supercat_0.5.5-4.2_amd64.deb Checksums-Sha256: ea724c5981cef4b70d8e47b90a375883bb682552d236a5dfaedb95e8bf57f90f 1834 supercat_0.5.5-4.2.dsc d94e5dfc2984195ce3181cde2291c7ee7c9f68c17df06fcc2304c832456aca72 5468 supercat_0.5.5-4.2.debian.tar.xz c3b5298a08c64ddd6ced4073cf2019913ee64dccc05b2929579580ac4d5681bd 17912 supercat_0.5.5-4.2_amd64.deb Files: 33ae3e79277416c0f3c7300271d9d804 1834 utils optional supercat_0.5.5-4.2.dsc dd28b0eebafb42cd49191412fd71307c 5468 utils optional supercat_0.5.5-4.2.debian.tar.xz 76fee5d902366aa21e57ca2db2cb3386 17912 utils optional supercat_0.5.5-4.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXoMQSAAoJEGNJDgVeB3TFqGAP/05sNHrmdJWIhs9qqeMHABhn snePmAE76lxf3tSkjIOVYP6rFO5syELVXvRSki+F9eqWAXbdMYuXkumT6D5tdqpk Ho6x4TrRCAKre3l/v6TUHUBEXCsaxmQF3qVu7jQc8+PxBIZcZ57oiiz/QGcXTNGD 2b/YsQfBxqRXF81Q7BECzRgbd1B49suHmFUA9CKJYqGUpmlK+cJXEwwqw981NJOS lbpWE+KkzT2OLxV6xNRNgmxlOpj/deipWnmobm9SJtR18zjjB73V95Ih3bAzCEgm gG2y1svxG3VNIIldHhL/vBYOOB7KJ261awF5/W6GifGf4VXjwES9raF2N73iUeni aLEBG0Iuo4wN4wM6obAZAtaIspFhTRc5tZXSHSho1kGBCeZujZ5cxgRr3WHVmVd0 YNJHSzXGh7Ebqj6qbOt+XQQ4FSW+27YCNkdIHYdlqdLzpR0WeWW9cHRzWPQkF2GY ZTdNJrbiER3i0a2ZLyTyPAWYIAes8e41HgHMhddJpFyKEAgZV8Gqg1BGew9dosKQ cRfJxXBDpo9Wt4uSGjDxHaS/u62Tuktjtuq9N7j3xfBR8+xnHEeIpwbKRV9+A1S6 qAqmupIyilSpc4wz/j+Z4qnrqR3Q0soBCD0YHLUUkYEh5UOPOI5u/hT6iagJOrwM kfEMJWeOTT1wkDEjm36Z =7Obt -END PGP SIGNATURE-
Accepted supercat 0.5.5-4.1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 02 Aug 2016 18:49:51 +1000 Source: supercat Binary: supercat Architecture: source amd64 Version: 0.5.5-4.1 Distribution: unstable Urgency: medium Maintainer: Kumar Appaiah <aku...@debian.org> Changed-By: Craig Sanders <c...@taz.net.au> Description: supercat - program that colorizes text for terminals and HTML Closes: 777396 793725 832079 Changes: supercat (0.5.5-4.1) unstable; urgency=medium . * Non-maintainer upload * applied patch from Maria Valentina Marin <marival...@gmail.com> to make the mtimes reproducible (Closes: #793725) * applied patch from Chris Lamb <la...@debian.org> to make the build reproducible (Closes: #777396) * fixed to work with input lines >= 1024 characters long (20KB should be plenty for pkg Depends: Lines) * added spcrc-dpkg-l and spcrc-package config files for colourising debian pkg info (Closes: #832079) * modified debian/rules to use latest autoconf and automake. deleted auto-generated files. * modified debian/rules to use dpkg-buildflags for hardening Checksums-Sha1: e687ab1e5a3763606c53f1b8b58f6bcbc70c07c2 1824 supercat_0.5.5-4.1.dsc fac87399101fdb2108e06d42ca9288a40e61eec0 5424 supercat_0.5.5-4.1.debian.tar.xz a3f1bf6c36b0419a229c46f22c85b8281ecb7a01 17860 supercat_0.5.5-4.1_amd64.deb Checksums-Sha256: ac4d90496017f6a39884c2580c73cfc1616abb4e4e9871f0aa7eb39b9acd2dc5 1824 supercat_0.5.5-4.1.dsc 02e0b8acf13cd3bd2c9c3452f887a97da263a548578d26544564f3eb2f452397 5424 supercat_0.5.5-4.1.debian.tar.xz 9012c2923093963708863a285e4c4fe1ce74849af199c6333918b7d0b112e194 17860 supercat_0.5.5-4.1_amd64.deb Files: 7e3f8e5a67ef918603684ca462685e29 1824 utils optional supercat_0.5.5-4.1.dsc 3bffc921a479f4ea6d67393ae099 5424 utils optional supercat_0.5.5-4.1.debian.tar.xz c50b48045671b72afd120959ce40b1e6 17860 utils optional supercat_0.5.5-4.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXoGPCAAoJEGNJDgVeB3TFmpUP/jLk0ll98Vnvvwe68KKYGFtZ KgmCBPmsuIPLursVwyLsCMv1l/Fi6SdJZbAMpZ3L00KQE/KrQ+LSdKSPjIW+Cyhe hEzfgZlXFxndGScXk8ZsiJ9WTT6DQyhWn/qikA4bjKgLHYhOIMUyBTyWXqQVdKw7 bH2UJaen3he5eKX99Arog18lJDiCdM5VpBF+ietAws/FHVul8+4pj57RFNb04/Dj xTGG7gIt0UXPH7JGBBXgGW8okig6D+Vcb6XIfDUIbdZ589dGYi6VS+EKbc8aaSvO G7F3O8ur/R9fiezO/YJzIa/us5jAlmk0wZXTjOb7v4D6UTJiZAY45NFWe4lvoCqd vhKfex4m+zFpl9OQliXgtgQaY5Dcci0/RzEHuRGg4GqDrd7vVDrwWLn9yF9AZZmp oE2OviwNRPPQft//MYSLIMdir/sPShVkylYd/PwfRtH+9C0bJALsdHLhF+WLzJUm +qm7jQKca3SaQVDbsqNJwD8q7b3p8/KO6L5n/ioO1s0AZ2ekCWIispcJQa/3/eyv 1enCjm2MnPyj7vP5H5O1ctV16C5bYcks7+ePmXLFWxuTin/wZdmvPdaoddvwerR4 eXI4CYDXBCGmkH7x/SGjqhuDurp1W+if0meXgpzaZurXZ6HGHKp8W7Pz5R/bXXpx 430+R9Dza1jGcTvRF779 =M8rB -END PGP SIGNATURE-
Accepted dlocate 1.07 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 21 Jun 2016 13:33:28 +1000 Source: dlocate Binary: dlocate Architecture: source all Version: 1.07 Distribution: unstable Urgency: medium Maintainer: Craig Sanders <c...@taz.net.au> Changed-By: Craig Sanders <c...@taz.net.au> Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 407412 532061 532704 563595 567080 614664 733864 788661 Changes: dlocate (1.07) unstable; urgency=medium . * updated VERSION_BANNER * (Closes: #532061, #407412, #532704, #563595, #567080, #614664, #733864, #788661, #567080) Checksums-Sha1: b1547b080b1c63ca80b3eab7293299d9e6ba54da 1359 dlocate_1.07.dsc 2f404fc907bb18cfefd23b1b69ead0ada2d20f62 42010 dlocate_1.07.tar.gz 930c7d2241071f10b01d571edfd1dc6fc5c597ea 23770 dlocate_1.07_all.deb Checksums-Sha256: fecd039d0ec73ecf568f85adc378f0074083ab3ecafe36e79e4b648066df3d99 1359 dlocate_1.07.dsc d5205cdb5072f30cbe82b50612ac5fce2b31ceac934ceac4f54bbda359af83b6 42010 dlocate_1.07.tar.gz 9e3a18aeeb83ef6d445789b26a763176c7753cc4c7d29f664ae87d147a0de6ff 23770 dlocate_1.07_all.deb Files: 762318633187c41e84aed6c4356d01f2 1359 utils optional dlocate_1.07.dsc a4700b408865baba3199de12d48658d8 42010 utils optional dlocate_1.07.tar.gz 9356966b79982583a14cb3213e1798aa 23770 utils optional dlocate_1.07_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXd83xAAoJEGNJDgVeB3TFUiUP+wZIZd04lF1MO2Pwgb+YwU1B lk25TLegV56EOJZuh/4eczZsxi0DlOJZ8UTDRIKgD5wPuZLYCHiYmY//rw8ptkAy SFnLWXUozvnSR+xvhf8G+fZ9Q3NbPHcpk5FbhXSPabCA6d9H5ZB4DjBRXavQvEmi 4EYVRTLAH+mva9yNRDotzcXvLBTUhm+23gCLLcB9M1HPMHqy+JHp/zUhTSuX99SN 8vDXfMtRoALgbfIW7hWbS6IhXWT/A0Nzl6ThEFohcNrEO0If2Ys42uV1IV2KbvoJ kDaARicPhL0AtT2T5HnDgU7crZ5TfF97NRoSKYtzd3gX9Spuf7nN6/BpL4KCqxqS 9IkV9HDODwerumhwpE0BN+VpJDl/J1uwvKaK7oNdATu6ePQlvJ6ySdff3I8M3Ytc KvsnbpVxULHgEv+oWdSbJnQzxORax0+a2bNpkEJLL9+SpRG6xdF6L43NP4NNZnZ8 gxTK2uRcxAWMpYvNgesELEjW4rurLPk6ghB/+ddzhaNFe1Y3A6UocERt3qFmEnBA b3v52SUm/DIVanwII6RYIcYvrt1hm3jCt8GjWzjoska0Mwtk59+gdAf0RAqb+OOx E9Nei36WfdNni/EgcSuANeGwSseXiOV88GISmTKD930wKJkZJ6+4l3eQM3wDIsFY iEEGiCff0LuaeLZUfsH2 =Gn0X -END PGP SIGNATURE-
Accepted arpwatch 2.1a15-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 01 Sep 2009 20:00:54 +1000 Source: arpwatch Binary: arpwatch Architecture: source amd64 Version: 2.1a15-1 Distribution: unstable Urgency: low Maintainer: KELEMEN Péter f...@debian.org Changed-By: Craig Sanders c...@taz.net.au Description: arpwatch - Ethernet/FDDI station activity monitor Closes: 288994 289426 315215 321504 427867 529097 Changes: arpwatch (2.1a15-1) unstable; urgency=low . * Non-maintainer upload to fix some outstanding bugs * latest upstream release (Closes: #427867) * converted packaging from dbs to debhelper * applied all existing patches from old 2.1a13 package * made bihourly.sh an example, and copied bihourly cron script from arpwatch-2.1a13 * added my pretty-print-arpwatch.pl script as an example * deleted duplicate errs= line from bihourly (Closes: #321504) * fixed sprintf in ec.c to zero-pad MAC addresses (Closes: #315215) * Applied patch from Sebastian Reichelt sebasti...@gmx.de to initialise interface variable (Closes: #289426) * updated watch file to v3 (Closes: #529097) * applied patch from Sebastian Reichelt to display IP in subject if hostname unknown (Closes: #288994) * updated ethercodes.dat from latest IEEE listing (~5000 new entries) * made /usr/share/arpwatch/ethercodes.dat a conffile so upgrades wont silently overwrite it if the user updates it. * installed arpwatch's *.awk scripts into /usr/lib/arpwatch and edited massagevendor to set AWKPATH before running awk. Checksums-Sha1: ca0ecda47da32b9c7e7f2794fae1c22d71a95960 772 arpwatch_2.1a15-1.dsc 8097b4d49679bd73a32799e7ba89b7702abaf2f9 235957 arpwatch_2.1a15-1.tar.gz 00b25396a430f71d59c5c5c3bf38b95fbc0e3bb5 186496 arpwatch_2.1a15-1_amd64.deb Checksums-Sha256: b7a325406b2a0417aa42ab698b0504d63e2192d6992d390b7225982dbba89bed 772 arpwatch_2.1a15-1.dsc bc075264862f0061d5cdb060c5c29539bb767ed28f6a5515d2758b1788dfa500 235957 arpwatch_2.1a15-1.tar.gz 78e01bce6db01d71e943f234c1622122140f989503f5ce9919d92e52dc22c9c9 186496 arpwatch_2.1a15-1_amd64.deb Files: 9692ee2ff63eef7405d614649454df75 772 admin optional arpwatch_2.1a15-1.dsc 4681c0ef975f7d6c8a80818a2d8df2b3 235957 admin optional arpwatch_2.1a15-1.tar.gz 6c26c0a4932c5d6dc7241a1204369956 186496 admin optional arpwatch_2.1a15-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkqq4CUACgkQ7DJoEM1WJvDZyACfQ0HzyaoYY+SlstVKqLttTnbq 6hgAn3EuZLwXOjM8ZZrb1PiVbU9wPJuv =1kDF -END PGP SIGNATURE- Accepted: arpwatch_2.1a15-1.dsc to pool/main/a/arpwatch/arpwatch_2.1a15-1.dsc arpwatch_2.1a15-1.tar.gz to pool/main/a/arpwatch/arpwatch_2.1a15-1.tar.gz arpwatch_2.1a15-1_amd64.deb to pool/main/a/arpwatch/arpwatch_2.1a15-1_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
NMU etiquette (arpwatch package)
(Please CC me on replies as i'm not subscribed to debian-devel) it's been a long time since I've done this, so i'd like to know what the current etiquette is for an NMI. arpwatch has had only sporadic NMU updates since 2004. I've packaged the latest version and applied a bunch of patches from the BTS (all that applied cleanly without conflicting with other patches), and fixed a few other minor bugs. most of these bugs are years old. I'd like to upload this to unstable, but i don't want to maintain the package forever. I've mostly worked on this NMU because I wanted to fix the sprintf for printing MAC addresses (zero-padded with %02x rather than just %x), and decided I may as well fix some of the other outstanding bugs too. probably the only really controversial thing about this NMU is that i've dumped the dbs-based packaging, and just gone with debhelper. I don't have time to learn dbs and have no inclination to do so, either. i like the *idea* of dbs but not the practice (i find it's a pain to work with -- it was easier for me to re-package the latest version of arpwatch from scratch than it was to figure out how dbs works just to make a one-line change for the sprintf problem). given that arpwatch has hardly been touched for the last few years, i'd guess that dbs is putting off other potential NMUs or maybe even an adopter too. anyway, here's the changelog entry: arpwatch (2.1a15-1) unstable; urgency=low * not-so-new upstream release (Closes: #427867) * converted packaging from dbs to debhelper * applied all existing patches from old 2.1a13 package * made bihourly.sh an example, and copied bihourly cron script from 2.1a13 * deleted duplicate errs= line from bihourly (Closes: #321504) * fixed sprintf in ec.c (Closes: #315215) * Applied patch from Sebastian Reichelt sebasti...@gmx.de to initialise interface variable (Closes: #289426) * updated watch file to v3 (Closes: #529097) * applied patch from Sebastian Reichelt to display IP in subject if hostname unknown (Closes: #288994) -- Craig Sanders c...@taz.net.au Tue, 01 Sep 2009 20:00:54 +1000 craig -- craig sanders c...@taz.net.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NMU etiquette (arpwatch package)
On Tue, Sep 01, 2009 at 09:30:04PM -0700, Steve Langasek wrote: I'm glad to see that Peter has approved of your NMU proposal, as migrating away from hand-rolled debian/rules files is a goal that I heartily support. However, your original question was one of etiquette, and I don't think that's been addressed in this thread. Yes, replacing the build system of a package in an NMU without the consent of the maintainer is an NMU faux pas. :-) yep, i figured that. which is why i made a point of highlighting the fact that i'd done it. NMUers should limit themselves to changes that directly fix bugs, and steer clear of design decisions regarding the packaging. my initial intent was just to fix the MAC address sprintf for myself, and use it on my own systems. then i looked at the dbs packaging for a while and the amount of work involved in just figuring out how it worked was too much, so i decided to just repackage the latest version for myself. and, of course, i kept all the previous patches and changes from the previous package. and then i fixed some of the other bug reports. when i'd done all that i figured it would be a shame to let that work go to waste on just my own systems and decided to find out about current NMU practices. arpwatch is quite useful for those who need it and doesn't really have any newer or better-maintained alternatives that do the same job. so, it's kind of an accidental NMU. i started off just wanting to fix a very minor problem for myself and a few hours later ended up with a complete new package. anyway, i'll be testing my arpwatch package on my own boxes for a while and, if i haven't introduced any new bugs, i'll upload it in a few days. If some of those design decisions mean no one is willing to NMU the package and the package falls into disrepair as a result, then it's a candidate for orphaning via the QA team processes; but we shouldn't force the issue by replacing a build system we don't like with another that the /maintainer/ may dislike just as much when they come back to the package. apart from occasional NMU over the last 5 years, arpwatch seems abandoned. IMO a working, updated, bug-fixed package is better than just letting it drop out of debian entirely - especially when it does a unique and useful job that no other package does. but then, i've never been precious about ownership of packages - mine or anyone else's. IMO, getting stuff done is far more important than WHO does it. and if the package's official maintainer doesn't like what was done in an NMU they can always ignore it or re-do it in their preferred style when they get around to it. but if Peter K had said not to upload it, i'd keep it as a private package, or just put it up on my web site for anyone else to download outside of debian. i may have misread it but Peter seemed to hint that he'd like someone to adopt arpwatch...hopefully the new form of the package will make it more appealing (or less unappealing) to someone. Other polite conventions regarding NMUs are spelled out in the developer's reference http://www.debian.org/doc/developers-reference/pkgs.html#nmu. thanks. craig -- craig sanders c...@taz.net.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted dlocate 1.02 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 03 Jun 2009 11:24:02 +1000 Source: dlocate Binary: dlocate Architecture: source all Version: 1.02 Distribution: unstable Urgency: low Maintainer: Craig Sanders c...@taz.net.au Changed-By: Craig Sanders c...@taz.net.au Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 42 531641 Changes: dlocate (1.02) unstable; urgency=low . * fixed example in dlocate.1 man page again (Closes: #42) * added '-k', and '-K' commands to list kernels and related packages * added optional support for gzip compression of /var/lib/dlocate/dlocatedb.txt * added support output filters (--package-only, --filename-only) (Closes: #531641) Checksums-Sha1: dfea8a017a0b53918393b3dec6f4f833328c34f6 687 dlocate_1.02.dsc 28029313f6021efa6cd7d3051677e29ea8ccd237 37601 dlocate_1.02.tar.gz 6b3aa0e90f915df27f01e6e6cde2a2692d4e5dd3 22470 dlocate_1.02_all.deb Checksums-Sha256: 2c429005c29fe038672e52aa94471ade831bdb49e04c1133c34805cf9065681a 687 dlocate_1.02.dsc 1d3473d1327ab2a34c12a674e56717b104b1957799dd1a80f9e322f3a422dd89 37601 dlocate_1.02.tar.gz 27f1fddbc8b6af73cab0652287cac2a9fbf5a50af1c8d09adf0284daadb70d65 22470 dlocate_1.02_all.deb Files: c402f55e5da6f19df5c6d322641248a8 687 utils optional dlocate_1.02.dsc 8274443ea8282737b845f1496caf8c1a 37601 utils optional dlocate_1.02.tar.gz 61c75c697dda54801a100d6ab005b6f0 22470 utils optional dlocate_1.02_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkol0eQACgkQ7DJoEM1WJvCg4gCfe/w4+Jh/oFXz7vBYCDhD+hDX uUEAn2MrhId8PRwqvJeHb87JHDoQVD/g =5oZF -END PGP SIGNATURE- Accepted: dlocate_1.02.dsc to pool/main/d/dlocate/dlocate_1.02.dsc dlocate_1.02.tar.gz to pool/main/d/dlocate/dlocate_1.02.tar.gz dlocate_1.02_all.deb to pool/main/d/dlocate/dlocate_1.02_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted dlocate 1.01 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 01 Jun 2009 09:56:54 +1000 Source: dlocate Binary: dlocate Architecture: source all Version: 1.01 Distribution: unstable Urgency: low Maintainer: Craig Sanders c...@taz.net.au Changed-By: Craig Sanders c...@taz.net.au Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 304045 Changes: dlocate (1.01) unstable; urgency=low . * added support for diversions (Closes: #304045) * fixed copy/paste error for -P (now correctly passes -P to grep rather than -E) * really moved the four dpkg-* man pages to section 8 Checksums-Sha1: 83d1509f73d89e034720bb8838247913107280d9 687 dlocate_1.01.dsc f5764e14afda3c2bd3c2f2a18b7de71b1ae69c76 37071 dlocate_1.01.tar.gz 04a7ae3f417b861c7e8c18ba18858c0c43cf2e39 20518 dlocate_1.01_all.deb Checksums-Sha256: e78bcc38b1065ced1f2ee334204f49bd6860855cb0e2f8df13e23592550c9d5c 687 dlocate_1.01.dsc 426d64ccf376bc42ea441d7d4eb3da43bd7d56db4bcb4cd6afb50dca25d59d8b 37071 dlocate_1.01.tar.gz c67e228df131a9cd93c70c4520beea4c561ffbd15dea98668517ebc0de04a945 20518 dlocate_1.01_all.deb Files: 8331c94de5a7f84352f859f13fe68134 687 utils optional dlocate_1.01.dsc 83d96c92457885d9143ca0e3b453ddce 37071 utils optional dlocate_1.01.tar.gz 2e0692339e7dcf13f3f786d2dceddea3 20518 utils optional dlocate_1.01_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkojGWkACgkQ7DJoEM1WJvBqLACePRlRaGUeiZ7jOOtFt0U6MBFv FHUAnRR5lYmL0hJPK+09oYD039epN+Er =8z9N -END PGP SIGNATURE- Accepted: dlocate_1.01.dsc to pool/main/d/dlocate/dlocate_1.01.dsc dlocate_1.01.tar.gz to pool/main/d/dlocate/dlocate_1.01.tar.gz dlocate_1.01_all.deb to pool/main/d/dlocate/dlocate_1.01_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted dlocate 1.0 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 30 May 2009 16:53:51 +1000 Source: dlocate Binary: dlocate Architecture: source all Version: 1.0 Distribution: unstable Urgency: low Maintainer: Craig Sanders c...@taz.net.au Changed-By: Craig Sanders c...@taz.net.au Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 49922 42 494651 494673 501870 505997 512446 513470 518309 523501 Changes: dlocate (1.0) unstable; urgency=low . * no longer use frcode and locate, see discussion in 494673. removed dependency on locate package. (Closes: #505997, #494651, #494673) * added support for several GNU grep options, -E, -F, -G, -P, and -w * the extra grep options obsolete the request for shell glob patterns (Closes: #49922) * checked for empty $PKGS (Closes: #523501) * fixed '-man' option, so that it doesn't break on man directories with locales * tired of people filing the same bug because they misunderstand the purpose of '-man'. added 'sort -u'. (Closes: #501870) * updated and fixed dlocate.1 man page (Closes: #518309) * corrected 'dlocate -l' example in man page (Closes: #42) * moved man pages for dpkg-hold, dpkg-unhold, dpkg-purge, dpkg-remove to section 8 (Closes: #512446) * added --verbose option to aid in debugging dlocate * fixed bug that broke support for multiple packages in most commands * fixed '-s' command so that it only calls grep-dctrl once if there are multiple package names * applied following 6 lintian fixes from era eriksson: (Closes: #513470) * debian/control: revert dependency on awk; as per Lintian error, it is in practice essential, and should not be declared * debian/copyright: add copyright year; disambiguate license as GPL v2 (fix lintian warning) * debian/rules: move binary-arch commands to binary-indep; do not ignore errors from make clean (fix lintian warnings) * debian/changelog: fix typo in 0.96.1 s/dancy/dency/ (fix lintian warning) * debian/postinst: don't use explicit path for /usr/sbin (fix lintian warning) * debian/postrm: add -e flag (fix lintian warning) Checksums-Sha1: 305ea6a207a8073b1090e12eea51f6667b38c56b 683 dlocate_1.0.dsc 4cb84953028e25b0fe2f7a9be38943a8ecb1f4e8 36544 dlocate_1.0.tar.gz e0f59394157ce1590e03ba0fb6d095a47e0c4eab 20172 dlocate_1.0_all.deb Checksums-Sha256: d317e27b1372891684495372399cc4144c78e8803c7435e1008aeaf924ed050c 683 dlocate_1.0.dsc e0ecac3b651fd9dcebaf900aab88d23e94713bbce526f87c7890febd70da7375 36544 dlocate_1.0.tar.gz d8e33720d26e8b52d4a7f490c7a13e10dcebe3c8f56bc56fd11c1244b28093c7 20172 dlocate_1.0_all.deb Files: bddbc804eb0748fd92490c0a3f12c2f5 683 utils optional dlocate_1.0.dsc ffe6f95a7306256cac513f3e5b1793ef 36544 utils optional dlocate_1.0.tar.gz 92ffd6360871a713a741b612d6ad16dc 20172 utils optional dlocate_1.0_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkohBB4ACgkQ7DJoEM1WJvDfJwCffy6J5k89TUGKpWqJkQcSkvwQ EcgAnj8SzwgpykWiT0auEkEAN2BYFgZr =G71/ -END PGP SIGNATURE- Accepted: dlocate_1.0.dsc to pool/main/d/dlocate/dlocate_1.0.dsc dlocate_1.0.tar.gz to pool/main/d/dlocate/dlocate_1.0.tar.gz dlocate_1.0_all.deb to pool/main/d/dlocate/dlocate_1.0_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted dlocate 0.96 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 27 Jun 2008 18:46:38 +1000 Source: dlocate Binary: dlocate Architecture: source all Version: 0.96 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 488222 Changes: dlocate (0.96) unstable; urgency=low . * accidentally deleted cron.daily rather than updating it. restored it. (Closes: 488222) * updated postinst to generate /var/lib/dlocate/dpkg.list with tab- separated fields, the same way that /etc/cron.daily/dlocate does. also removed COLUMNS=200 because the postinst doesn't need it any more than the cron.daily does. * updated man page for update-dlocatedb to note additional author Checksums-Sha1: 0a329c85c7c36173c952dfbb15ff8529eb22964c 687 dlocate_0.96.dsc 4387ad39467588d941176fbba5f3d88b3e905c48 33990 dlocate_0.96.tar.gz 8b631b66e94bf60426e7f5fcfb0faedd3b355870 17814 dlocate_0.96_all.deb Checksums-Sha256: 60c41bc02a77ebef06d42e3b18ae65005997c2cd7f2d0e95a5c60ed76ba86559 687 dlocate_0.96.dsc b19f842301c7f7dc727f83ac72b56bc3e1a85cf5837ab517cbe4d744b290afe1 33990 dlocate_0.96.tar.gz 56ed7df50002cbf0a9de89f5cf1d6270b3f2a88b8bdbffe07b6d972354ecee85 17814 dlocate_0.96_all.deb Files: 408b40a3b8feb200e943a7b38faa1157 687 utils optional dlocate_0.96.dsc 62b9ac5029821259134611a19205f577 33990 utils optional dlocate_0.96.tar.gz 4c0490de23d39ecc8f5092d166cd35cd 17814 utils optional dlocate_0.96_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhkqaAACgkQ7DJoEM1WJvDXXgCeKAwKRDZ8YqZqnpeC8k+Fpxi7 OywAn1GstIGFee7+T3Z103ynayR5OOQn =jH6e -END PGP SIGNATURE- Accepted: dlocate_0.96.dsc to pool/main/d/dlocate/dlocate_0.96.dsc dlocate_0.96.tar.gz to pool/main/d/dlocate/dlocate_0.96.tar.gz dlocate_0.96_all.deb to pool/main/d/dlocate/dlocate_0.96_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.96.1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 27 Jun 2008 19:58:57 +1000 Source: dlocate Binary: dlocate Architecture: source all Version: 0.96.1 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Changes: dlocate (0.96.1) unstable; urgency=low . * version 0.95 introduced a dependancy on awk, which is an optional package. the simple awk script has only been tested on my system with gawk, but it doesn't do anything gawkish so should work with mawk or original-awk. fixed Depends line. Checksums-Sha1: c594c884e3868e9da3917b611c934d5ccd64f462 695 dlocate_0.96.1.dsc 936936a124ac2ebe7096b6cf52c52981009016b9 34011 dlocate_0.96.1.tar.gz 3615eea5c388afd2b00825c520f101298e7522a3 17948 dlocate_0.96.1_all.deb Checksums-Sha256: 0edc1dbabd7d2f7c8c06c3da3ac069a2d90542e2526eb49f0b610438069289fa 695 dlocate_0.96.1.dsc e86ffac37d642f67f9c793d873edb7f47a5529172b8a192df6996754a9818e1c 34011 dlocate_0.96.1.tar.gz 694f78e72aa50af65cc0ccbb234a47464531acf9e34e76a9c530cb15b6fa3afb 17948 dlocate_0.96.1_all.deb Files: 82638ab56d48b2b4b383907d85c9b494 695 utils optional dlocate_0.96.1.dsc 32a6c408187d0c4c64504d21855ad9ff 34011 utils optional dlocate_0.96.1.tar.gz 46623765e9ca9d0d995286a1b2f4e960 17948 utils optional dlocate_0.96.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhkvN8ACgkQ7DJoEM1WJvAXBACeMV3n1SKBKt2eMFbD8mK5FWTb 9UAAn1EB1t/MqW90ava1j75iw4Luej8q =3/66 -END PGP SIGNATURE- Accepted: dlocate_0.96.1.dsc to pool/main/d/dlocate/dlocate_0.96.1.dsc dlocate_0.96.1.tar.gz to pool/main/d/dlocate/dlocate_0.96.1.tar.gz dlocate_0.96.1_all.deb to pool/main/d/dlocate/dlocate_0.96.1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.95 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 26 Jun 2008 20:53:30 +1000 Source: dlocate Binary: dlocate Architecture: source all Version: 0.95 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 42314 43145 43146 45057 54073 63902 67650 76149 78621 83196 84018 91785 100694 101426 129186 129251 132930 132931 314276 337711 456292 457572 42 487471 Changes: dlocate (0.95) unstable; urgency=low . * changed cron.daily to not use ionice if kernel version 2.6.13 * redirected stderr from ionice to /dev/null to avoid error messages if running under vserver or other environments without CFQ scheduling (Closes: #456292) * added Pawel Chmielowski [EMAIL PROTECTED] patch to update-dlocatedb which re-uses any old data from the existing dlocatedb. (Closes: #457572) * changed separator character when building the search regexp so that we don't end up grepping for everything. (Closes: #42) * while/read loops in bash are abysmally slow. replaced that loop in 'dlocate -l' section with an awk script. vast improvement in speed. Note: this required changing the field separator in $DPKGLIST from space to tab, so anyone who parses that file directly (nobody, i think) may need to modify their scripts. (Closes: #487471) * finally close some bugs that were actually closed ages ago in NMUs. (Closes: #314276, #337711, #83196, #54073, #63902, #84018, #67650, #78621, #132930, #91785, #100694, #101426, #129251, #132931, #129186, #76149, #43145, #43146, #45057, #42314) Checksums-Sha1: d2d38a87fa9bae80b6d9ef600c1c52c73d7832c5 687 dlocate_0.95.dsc 813879660d08425d6333789beeae2f040d698a24 33764 dlocate_0.95.tar.gz 50a3488b99ea2bea1587c068e060a7a04043e23d 17158 dlocate_0.95_all.deb Checksums-Sha256: 527dc0d77e4cf958c7426f8b3f7a43c68bc674774c384420049896648140ceab 687 dlocate_0.95.dsc 0f95bd4ebecef3cee077c5304b55e6222fdcbe207fa10d206be1ab86de49a88e 33764 dlocate_0.95.tar.gz add94e2b480a91747edce211bf1c135bba975886f56408c9d6dd5919d4c6a1e1 17158 dlocate_0.95_all.deb Files: ecdae4a0d47aba9fa0913a88db8ac68d 687 utils optional dlocate_0.95.dsc dd25608870600fa3ca400504e2fb91c5 33764 utils optional dlocate_0.95.tar.gz 771445427304cc5725f03e01ce3b7ab9 17158 utils optional dlocate_0.95_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhjfxQACgkQ7DJoEM1WJvBoVQCfQjMLqSdThtK/oAsBVhgZl8je wrQAnjPGvz61iEOp8S+jkXGgz1n3wu9c =03AR -END PGP SIGNATURE- Accepted: dlocate_0.95.dsc to pool/main/d/dlocate/dlocate_0.95.dsc dlocate_0.95.tar.gz to pool/main/d/dlocate/dlocate_0.95.tar.gz dlocate_0.95_all.deb to pool/main/d/dlocate/dlocate_0.95_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.94 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 03 Dec 2007 07:43:37 +1100
Source: dlocate
Binary: dlocate
Architecture: source all
Version: 0.94
Distribution: unstable
Urgency: low
Maintainer: Craig Sanders [EMAIL PROTECTED]
Changed-By: Craig Sanders [EMAIL PROTECTED]
Description:
dlocate- fast alternative to dpkg -L and dpkg -S
Closes: 350818 354644 453952
Changes:
dlocate (0.94) unstable; urgency=low
.
* optimisation for '-S' and 'DEFAULT' commands. run locate once
only with multiple filenames on the command line. significantly
faster when searching for multiple filenames. slighly slower
when searching for only one filename.
* the optimisation also means that $result is the exit-code of
all searches combined, rather than just the exit-code of the
last search to be run.
* this also fixes the double-vision symption reported in bug#354644
i'll close this bug for now, but may reopen it if it turns out
that an --exact-match option would be useful. (Closes: #354644)
* added '--ignore-case','-i' option for package and filename
searches ('-l','-S', and default command). (Closes: #350818)
* used ionice in /etc/cron.daily/dlocate (Closes: #453952)
Files:
508c0ce3e1d0535560df3c8695376675 483 utils optional dlocate_0.94.dsc
e2e99b4c294a50fa91db396dfa3fbc05 32918 utils optional dlocate_0.94.tar.gz
8b3eb28d752136b527e2062b31b2d1f6 16606 utils optional dlocate_0.94_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHUxwy7DJoEM1WJvARAnWsAJ9fKzH4ELCgZRrEWhbiL3KM/BP3AACeLCdA
LQeIAoXPOhd29Cj+kFidtjw=
=rIEP
-END PGP SIGNATURE-
Accepted:
dlocate_0.94.dsc
to pool/main/d/dlocate/dlocate_0.94.dsc
dlocate_0.94.tar.gz
to pool/main/d/dlocate/dlocate_0.94.tar.gz
dlocate_0.94_all.deb
to pool/main/d/dlocate/dlocate_0.94_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.93 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Nov 2007 18:27:22 +1100 Source: dlocate Binary: dlocate Architecture: source all Version: 0.93 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 220351 307371 447140 Changes: dlocate (0.93) unstable; urgency=low . * minor fix to -lsbin. now excludes all non-files, rather than just directories. also follows symlinks. * added '--' option to make it possible to search for partial files like -conf, -ls, and other '-*' that happen to match dlocate options. did i already mention that dlocate's arg processing really sucks and needs a rewrite? * added Makefile rules (make test) to automate testing of dlocate output, and to remind me to update the version banner in dlocate. (NOTE: breaks backwards-compatibility for anyone who relies on the old behaviour!) * check for unknown options (Closes: #220351, #307371) * only print header for 'dlocate -l' if there are any matching packages found. (Closes: #447140) * fixed dlocate's stderr redirection so that 'make test' works. (possible bug in bash - '/dev/stderr' treated differently to '2') Files: f51f7c5b1ec43fd3fd779506b97cc808 483 utils optional dlocate_0.93.dsc 91fbe0c5c7bb3d6406f500dfb9ae4774 32335 utils optional dlocate_0.93.tar.gz f0c22767fb377e101e8558dc5d3c1da0 15988 utils optional dlocate_0.93_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTmoG7DJoEM1WJvARAhpdAJ9v5Zu//s4xf9C6W5tVefoWxQ6D2QCfQ0xY RvrHHnVyQYD4nhJALaQsgmw= =sUZw -END PGP SIGNATURE- Accepted: dlocate_0.93.dsc to pool/main/d/dlocate/dlocate_0.93.dsc dlocate_0.93.tar.gz to pool/main/d/dlocate/dlocate_0.93.tar.gz dlocate_0.93_all.deb to pool/main/d/dlocate/dlocate_0.93_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.92 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 26 Nov 2007 19:26:50 +1100 Source: dlocate Binary: dlocate Architecture: source all Version: 0.92 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 452746 Changes: dlocate (0.92) unstable; urgency=low . * passed '--' to egrep so you can search for partial package names like '-utils', '-tools', etc. * fixed a bug in -md5check which prevented it from checking some packages with spaces in the filenames. * used '-r' (--no-run-if-empty) everywhere with xargs. (Closes: #452746) * also changed numerous tests of [ -e $PKG.* ] to [ -s $PKG.* ] to test for 'exists and not empty' rather than just 'exists'. * removed output of double-quotes (0x22) surrounding $PKG to make stderr output more parser-friendly. * added simple script to test dlocate output prior to uploading a new version (script is in source package only) Files: 8bb0aaa39208b7f7f5b5266f676756a6 483 utils optional dlocate_0.92.dsc 9c184f9d9bc20f47b94c905c644ec75b 13750 utils optional dlocate_0.92.tar.gz 41298b90fc0ab39373f389d25f38e79e 15448 utils optional dlocate_0.92_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHSoQ37DJoEM1WJvARAvrdAJ9Kjwit6dqhtIOUBWW/4cvKgyTB2QCfXW8G aNIcLshwY02axxzlWDCnM3I= =3sXr -END PGP SIGNATURE- Accepted: dlocate_0.92.dsc to pool/main/d/dlocate/dlocate_0.92.dsc dlocate_0.92.tar.gz to pool/main/d/dlocate/dlocate_0.92.tar.gz dlocate_0.92_all.deb to pool/main/d/dlocate/dlocate_0.92_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.91 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Nov 2007 21:20:26 +1100 Source: dlocate Binary: dlocate Architecture: source all Version: 0.91 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Changes: dlocate (0.91) unstable; urgency=low . * corrected minor mistake in dpkg-remove man page. Files: e307984c7d181a4f2b8cbc694f61f27e 483 utils optional dlocate_0.91.dsc 1c1cc2bc171c6bf231be14493455608c 12212 utils optional dlocate_0.91.tar.gz a0f53b9e2a3179acb2ce47e91119e073 15068 utils optional dlocate_0.91_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHRVgi7DJoEM1WJvARAo7zAJ0YeHolQl4eppa1APUPekI5zyHR2QCfbRjJ pGo6UuDMiPcV52bWbeOjJwQ= =tp1S -END PGP SIGNATURE- Accepted: dlocate_0.91.dsc to pool/main/d/dlocate/dlocate_0.91.dsc dlocate_0.91.tar.gz to pool/main/d/dlocate/dlocate_0.91.tar.gz dlocate_0.91_all.deb to pool/main/d/dlocate/dlocate_0.91_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.9 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 22 Nov 2007 20:48:19 +1100
Source: dlocate
Binary: dlocate
Architecture: source all
Version: 0.9
Distribution: unstable
Urgency: low
Maintainer: Craig Sanders [EMAIL PROTECTED]
Changed-By: Craig Sanders [EMAIL PROTECTED]
Description:
dlocate- fast alternative to dpkg -L and dpkg -S
Closes: 380081 452297
Changes:
dlocate (0.9) unstable; urgency=low
.
* cron.daily doesn't need to have COLUMNS=200. this was fixed in dpkg
years ago.
* redirect error output from -lsbin to /dev/null. (Closes: #452297)
* made -lsbin output consistent with other -ls options
* added dpkg-hold, dpkg-unhold, dpkg-remove, and dpkg-purge to /usr/sbin.
simple command line tools that i've been using for years to
flag/unflag a package for hold, or flag it to be removed or purged.
They *ONLY* change the status of the package which will be noticed
the next time dpkg, dselect, or apt-get is run.
* write simple man pages for dpkg-{hold,unhold,remove,purge}
* really fixed bad handling of first arg this time (Closes: #380081)
* updated date in dlocate.1 man page
Files:
331846d283a98f14b29451038faf0f23 481 utils optional dlocate_0.9.dsc
d98c3427c0769e7cf6eac92229f2f24c 12195 utils optional dlocate_0.9.tar.gz
b108bc76b535b5545315fb20507cc3f3 15008 utils optional dlocate_0.9_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHRVXN7DJoEM1WJvARAs37AJ0a36LlyPjhfrNzYZpsyAP8xJBV9gCcDrrT
yNx/ZGK2AYUJiMlzSrDrg30=
=/wUp
-END PGP SIGNATURE-
Accepted:
dlocate_0.9.dsc
to pool/main/d/dlocate/dlocate_0.9.dsc
dlocate_0.9.tar.gz
to pool/main/d/dlocate/dlocate_0.9.tar.gz
dlocate_0.9_all.deb
to pool/main/d/dlocate/dlocate_0.9_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.6 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 20 Nov 2007 23:12:18 +1100 Source: dlocate Binary: dlocate Architecture: source all Version: 0.6 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 65974 223698 224947 261733 268288 290562 319251 354285 360824 360824 375271 380081 451750 Changes: dlocate (0.6) unstable; urgency=low . * Applied patch from Andreas Metzler: GNU locate has been split off to a separate package. Adapt dlocate to work both with the new and the old setup. (Closes: #451750) * always pass '--' to locate. (Closes: #360824, #360824) * can not reproduce bug 65974. my guess is that update-dlocatedb hadn't been run. (Closes: #65974) * error messages now go to stderr (Closes: 375271) * first option is no longer a special case (Closes: #380081) * 'LINES=40' isn't needed. removed. (Closes: #224947) * shameful trailing blanks removed from -l output (Closes: #261733) * 'dlocate -l' no longer outputs one header for each package name. (Closes: #268288, #319251, #354285) * added '/' to start of dlocate -man regexp. (Closes: #290562) * dlocate now has --version and -V options (Closes: #223698) * dlocate really needs a rewrite. it started as a QD hack and grew beyond that. the remaining bugs need a rewrite to fix. expect a rewrite from scratch soon. Files: c5c3d6c7133bcd240d48bbf465a2f6fd 480 utils optional dlocate_0.6.dsc b1408d95f3888183731ec7e767a4c01b 9966 utils optional dlocate_0.6.tar.gz e15d24e2b1bd8c3e1c1deb3d22148381 10480 utils optional dlocate_0.6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQtTb7DJoEM1WJvARAtXsAJ487/M32t/aPpTNFmbB5wgLBK/BaACgiTIx i6lyxVLUU6Z78LrNFTb7+l4= =mRga -END PGP SIGNATURE- Accepted: dlocate_0.6.dsc to pool/main/d/dlocate/dlocate_0.6.dsc dlocate_0.6.tar.gz to pool/main/d/dlocate/dlocate_0.6.tar.gz dlocate_0.6_all.deb to pool/main/d/dlocate/dlocate_0.6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.7 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 21 Nov 2007 01:53:17 +1100 Source: dlocate Binary: dlocate Architecture: source all Version: 0.7 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 208425 289351 354648 361125 441109 441183 447141 Changes: dlocate (0.7) unstable; urgency=low . * fixed small bug in arg handling * added more commentary and examples in the dlocate man page to resolve various searching issues (both locate and egrep are different to dpkg's shell-style pattern matching). Also added 'SEE ALSO locate(1)' to the man page. (Closes: #441183, #208425, #447141) * man page for dpkg is in section 1. (Closes: #354648) * added -lsman option to list full path/filename of man pages. (Closes: #361125, #289351) * added -lsbin option to list full path/filename of binaries (Closes: #441109) Files: 3170a73d8bde3b5b75b20cd0437c1945 481 utils optional dlocate_0.7.dsc ed10d933687c99063018a0b365159e2d 10633 utils optional dlocate_0.7.tar.gz ab546230567b85a2abe0bd9894ae82f3 11270 utils optional dlocate_0.7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQvZ67DJoEM1WJvARAgOHAJ9J4zGL4N6/lqKIwfHLJcAR0jgMMgCfUkh6 FuLGUE/MjHrWR9U+YgKFtas= =tZNl -END PGP SIGNATURE- Accepted: dlocate_0.7.dsc to pool/main/d/dlocate/dlocate_0.7.dsc dlocate_0.7.tar.gz to pool/main/d/dlocate/dlocate_0.7.tar.gz dlocate_0.7_all.deb to pool/main/d/dlocate/dlocate_0.7_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dlocate 0.8 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 21 Nov 2007 10:29:20 +1100 Source: dlocate Binary: dlocate Architecture: source all Version: 0.8 Distribution: unstable Urgency: low Maintainer: Craig Sanders [EMAIL PROTECTED] Changed-By: Craig Sanders [EMAIL PROTECTED] Description: dlocate- fast alternative to dpkg -L and dpkg -S Closes: 61790 361196 413804 Changes: dlocate (0.8) unstable; urgency=low . * call md5sum -c with '-' rather than /dev/stdin (Closes: #413804) * can not reproduce 61790, and nobody else has ever reported anything similar. probably some problem with cron on Lazarus' system at the time (Apr 2000). (Closes: #61790) * improved error messages from update-dlocatedb. also modified script to comply with 'use strict;'. (Closes: #361196) Files: c57a51cac011257a0a0b38e00f8c56a5 481 utils optional dlocate_0.8.dsc e8f8405c67c97470f669595fc27c68fe 10860 utils optional dlocate_0.8.tar.gz ec3b466e858465cacc576ccd1aea3e69 11522 utils optional dlocate_0.8_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQ26z7DJoEM1WJvARAl7lAJ4tuAWGbOBQAFDXB2dVo4lWN5oUfwCfbg8g vrnQYKmows3x18dreRMJ7m4= =TOxI -END PGP SIGNATURE- Accepted: dlocate_0.8.dsc to pool/main/d/dlocate/dlocate_0.8.dsc dlocate_0.8.tar.gz to pool/main/d/dlocate/dlocate_0.8.tar.gz dlocate_0.8_all.deb to pool/main/d/dlocate/dlocate_0.8_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nethack popularity contest - number_pad?
On Thu, Oct 16, 2003 at 06:30:26PM -0700, Joshua Kwan wrote: Which is better? I like the default keys because you learn how to use nvi very efficiently knowing the hjkl-style keys :) I'm searching for as many opinions as possible so please speak up! i agree. hjkl keys are betterand gives the plausible excuse that playing nethack is really just training for vi :) craig
Re: tmda: Challenge-response is fundamentally broken (RAPNAP)
On Sat, Sep 06, 2003 at 11:32:04PM +1000, Russell Coker wrote: DNSBL's and spamassasin seem quite good at dealing with spam and are much less annoying. That combined with some new laws that are being enacted to combat spam should keep it to a managable level. oh, please tell me that these new laws are going to be the replacement of Duck Season with Spammer Season (Jan to Dec in any year). that'll work. i sometimes think that it's the ONLY thing that will really work. craig
Re: music sheet
On Tue, Sep 09, 2003 at 09:11:09AM +1000, Matthew Palmer wrote: On Tue, Sep 09, 2003 at 01:00:11AM +0200, Josip Rodin wrote: On Mon, Sep 08, 2003 at 06:55:31PM -0400, Jim Penny wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. The problem, amazingly enough, is that he did google for dueling banjos sheet music, You missed the spelling detail -- one l vs two. With the latter, Debian list archives aren't in the top ten. Of course, Matthew's post with the other spelling will now probably muddy that distinction, too. :) Aaaah crap, didn't think of that. Of course, with all the quoting, we're pushing it ever higher... why dont we just put up a page on www.debian.org with the requested sheet music (or, if it's copyrighted then appropriate links to sites where it can be found). we could also put the tale of Google and The Dueling Banjos on the same page. then make sure that there are enough links to this page that it gets the highest rank on google (perhaps by editing the archives to include a link in every page that mentions the song). craig ps: i just searched google for it myself and debian is down to 6th 7th place.
Re: IMPORTANT: your message to html-tidy
On Sun, Sep 07, 2003 at 11:09:57PM -0700, Steve Lamb wrote: On Mon, 8 Sep 2003 15:40:15 +1000 Matthew Palmer [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2003 at 06:04:39AM +0100, Karsten M. Self wrote: I'm coming to the view that we're approaching the era where all mail is going to have to be subject to filtering, at the MTA level. Depends on how useful you want your e-mail box to be. g It has been my experience that filtering at the MTA level has increased the usefulness of my mailbox considerably. aol me too /aol stats from last week's mail.log (from my home mail server which handles mail for about half a dozen people): 1 Bad HELO 10 RBL proxies.relays.monkeys.com 11 Recipient Domain Not Found 22 RBL relays.ordb.org 25 strict 7-bit headers 31 Relay access denied 32 RBL taiwan.blackholes.us 34 Sobig.F Virus 42 body checks 49 RBL spamdomains.blackholes.easynet.nl 56 header checks 61 RBL dnsbl.sorbs.net 182 IP Address in HELO 193 RBL brazil.blackholes.us 218 RBL blackholes.easynet.nl 271 Local access rule: Helo command rejected 342 RBL hongkong.blackholes.us 492 RBL dynablock.easynet.nl 924 RBL sbl.spamhaus.org 1080 Local address forgery 1099 Recipient address rejected 1133 Sender Domain Not Found 1771 RBL list.dsbl.org 1825 Dynamic IP Trespass 1902 RBL cn-kr.blackholes.us 2471 Local access rule: Client host rejected 3005 Need FQDN address 3581 Local access rule: Sender address rejected 4267 User unknown 25130 TOTAL Spamassassin stats: 382 spam 4093 clean 4475 TOTAL Percentages: spam:non-spam (25512/29605) 86.17% accepted spam (382/4475) 8.54% rejected spam (25130/25512) 98.50% i'm reasonably happy with that. 98.5% of all spam was rejected outright. only 382 spams (1.5%) made it through my postfix access lists, RBLs, etc to be tagged by spamassassin. these stats also demonstrate just how bad the spam problem has become. 86% of all attempts to deliver mail to my server were spam, ~25500 spams and ~4100 legit messages. if i wasn't blocking spam at the MTA, then at least half of those spams would have ended up in MY personal mailbox (or, more likely, tagged by spamassassin and saved into my spam.incoming folder)about 13000 more spams than i currently receive. craig ps: i love postfix. it has the best anti-spam features of any MTA. pps: anyone who wants my simple spam-stats.pl script can get it from http://taz.net.au/postfix/scripts/
Re: non-free software included in contrib
On Mon, Sep 01, 2003 at 09:47:46AM +1000, Matthew Palmer wrote: Ah, reductio ad absurdum. Such a wonderful means of demonstrating that you can't think up a decent argument, so you'll take something to it's illogical extreme to try and scare some people. more accurately, it is a useful tool for highlighting the absurdity of a given argument by pointing out the inevitable and logical conclusions of that argument. craig
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 10:42:17AM +1000, Brian May wrote: On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? no, i am not saying that. That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. the difference are : 1. a bounce is NOT the same thing as generating a new notification or confirmation message. 2. with modern MTAs that can reject mail from spammers/spamware/viruses during the SMTP session, there is no bounce message at all. by issuing a 5xx reject code during the smtp session, it leaves the task of bouncing the message up to the senderand very few (none, to my knowledge) virus or spamware programs have any code at all to send bounces. they just ignore the reject and move on to spamming the next victim address. this is beneficial both to the mail server itself (which is not clogged up with thousands of undeliverable bounces) and also to the poor bastard who has had their address forged by spamware or virus. reasons for rejecting during the smtp session include: unknown recipient, relay access denied, blacklisting (open relay, dialup/dynamic pool, known spam domain etc), local policies (message size, quota, etc), obvious spam/virus (e.g. content-filtering) and many others. 3. it is reasonable and correct for an MTA to assume that the sender address is correct. that is its job. it is not at all reasonable for an anti-virus or anti-spam system to make that assumption - almost all spam and most viruses are from forged addresses. this has been known for years, it is absolutely inexcusable that any anti-virus or anti-spam tool has been programmed without this knowledge in mind. 4. if an anti-virus or anti-spam mail system can NOT reject the mail during the smtp session then it MUST NOT send any notification/bounce back to the sender. the correct thing to do is to either tag the message and deliver it to the recipient address (perhaps after removing or de-fanging any virus), or to quarrantine it (and optionally send the *recipient* a notification message, or just let them check their quarranitine box every so often). The other option which many people seem to want is to discard the E-Mail without giving either party any indication of what happened. E-Mail that looks suspicious can be valid mail at times, for instance somebody I knew tried to send a ZIP file that happened to be executable via E-Mail. Do you simply discard such E-Mails (which gives no indication that something went wrong), or do you try to contact the sender to indicate that something went wrong? the answer to this is obvious: you reject it and leave it up to the sending mta/client to deal with it. if the sender is spamware or virus, there won't be any bounce message (nor should there be). if the sender is a legitimate client, then the user will be notified (usually via a dialog box) and the message will stay in the outbound queue or be bounced to the inbox or an error mbox. if the sender is a mail server, then it will bounce the message back to the original sender. if it was a legitimate email that bounced (e.g. unknown recipient) then that is what is supposed to happen. the only time this is a problem is when the sending MTA is an open relay, and the address was forged. there isn't much that can be done about that, however bounces from an open relay server will be rejected by any MTA that uses an open-relay blacklist (so no bounce will be delivered to the forged address). One approach for instance would be to modify the SMTP standard, and say if a host accepts the E-Mail then it is guaranteed to get it to the destination (ie. it signal OK until the message has been delivered), but that would break store-and-forward capabilities of secondary mail servers. that is pretty much the standard now, except that a host which accepts a message MUST either deliver it (directly or forward it on to the next hop), or it MUST bounce it. that word accept is crucial, however. if you don't accept the message (i.e. if you reject it with a 5xx reject code) then it's not your responsibility to either deliver or bounce it...it is the responsibility of the sending client or server. Even encryption does not help here, or at least I have not seen any proposals for any system that could scale to the Internet. GPG for instance only verifies the sender to the receiver, it could not be used to verify every sender to the MTAs involved. encryption
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 04:01:19PM +1000, Russell Coker wrote: Backup MX servers serve no useful purpose in the modern Internet, this is why big sites such as microsoft.com and hotmail.com don't have them. agreed. If you have a backup MX then it should know all the acceptable email addresses in your domain and enforce all rules regarding acceptable content. Then it can block content through SMTP 550 and 450 codes. yes. if you don't have 100% administrative control over your backup MX server(s) then you should NOT be using them. craig
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 11:49:40PM +, Brian May wrote: On Sat, Aug 30, 2003 at 04:01:19PM +1000, Russell Coker wrote: That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. A SMTP 550 code can convey all the information that is needed for bounces. There are two problems with this. 1. The modular design of SMTP agents like postfix do not allow scanning of messages before the message has been accepted by the MTA at the SMTP session. I think you would have to add hooks into smtpd, but that is going to complicate the code. not true. postfix header_checks and body_checks check the message *before* it is accepted by the MTA. if it fails the test, a final 5xx reject code is issued rather than a 2xx accepted code. recent experimental versions of postfix also allow the same thing to be done with content-filters, although use of this feature is not recommended by Wietse due to the time it takes for a filter like spamassassin to run - there is a risk of smtp timeouts, especially on busy servers. 2. All checks have to be automatic, and there is no chance of manual review to ensure that the messages where geniune before bouncing it. The list of known solutions follows: (nil) actually, the known solution is: - reject if you possibly can, tag and deliver otherwise. craig
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna wrote: On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: #2, Misplaced burden, is the reason for the 'grave' severity. People have a right to ask that unkown people that e-mail them confirm the e-mail. the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. such software is too brain-damaged to use. there is more than enough spam, viruses and other garbage clogging SMTP servers around the world without making things worse by using programs which falsely claim to be part of the solution. junk like this does not solve the problem, it is not part of the solution - it just amplifies the original problem: every virus or spam with forged headers results in even more confirmation and/or notification messages being sent in response. in short, it is automated spamware that contributes to denial of service attacks. craig
Re: logging out a ssh-user
this question really belongs on debian-user, not on debian-devel.
On Sat, Jul 26, 2003 at 07:55:28PM +0200, Dennis Stampfer wrote:
I have to log out a user who is logged in via ssh. The information that he
is not allowed to login comes from the utmp-file like the pid to kill.
if he's not allowed to login, then why not set his shell to /bin/false?
If he's logged in via telnet, I can do the job by killing that pid. That
does not work with ssh: For some reason, all what I get out of utmp is the
pid of the listening sshd which I can't kill if I don't want to disable
ssh-logins.
that would be because you're killing the wrong sshd PID.
I solved it by adding 2 to that pid to reach the child-ssh, checking if it is
sshd and owned by the user who is to be logged out. If that all is ok, I
kill that pid.
run ps and grep for the tty that he's logged in on. e.g. if he's on pts/3:
# ps aux | grep pts/3$
cas 7002 0.0 0.7 6352 1920 ?S17:00 0:00 sshd: [EMAIL
PROTECTED]/3
then kill it:
# kill -1 7002
or in one line:
# ps aux | grep pts/3$ | awk '{print $2}' | xargs kill -1
alternatively, apt-get install slay and run slay USERNAME.
craig
Re: Debian 10th birthday gear
On Tue, Jul 08, 2003 at 06:10:33PM +0800, Cameron Patrick wrote: On Tue, Jul 08, 2003 at 11:11:13AM +0200, Sebastian Rittau wrote: |100 million users | 1000 installations | | I would recommend to exchange these last two lines. More installations | than users? If you read it more carefully it implies that there are 100 000 users per installation - which also seems rather unlikely. :) you're all making a big mistake. those numbers were obviously binary, not decimal. craig
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 02:36:24PM -0500, Steve Langasek wrote: [...] This upstream change makes no sense from a usability standpoint; this new stunnel package would be pretty useless to me, and I wouldn't want to have it automatically installed on my systems if I were using the previous, working version. By the time a debconf note is sent, it's too late. the new version of stunnel is much better than the old one. i got bitten by the upgrade to 4.0-4 (when the init.d script didn't start stunnel unless ENABLED=1 in /etc/default/stunnel). big deal. i noticed it quickly enough and it took me less than a minute to scan the docs and discover that i should edit /etc/default/stunnel. the worst that happened was that my uucp-over-tcp clients weren't able to connect for a while. IMO, anyone who does an upgrade without bothering to check that important services are still running correctly afterwards is just plain sloppy and deserves whatever their negligence causes. the same applies to anyone who doesn't test upgrades of critical services on another, unimportant machine first...and for really important packages, it's a good idea to make sure you have a backup copy of the old version of the package before upgrading (dpkg-repack is useful here if it has been cleaned out of your local /var/cache/apt/archives)if the new version proves to be broken, revert to the old version. debian packages aren't a substitute for a competent and careful system admin, they're just a tool to make the sysadmin's job easier. craig
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:49:19PM -0400, Joey Hess wrote: If I ever add filtering to the notes debconf allows to be displayed, notes that refer the user to README.Debian will be at the top of the list to never be displayed. Of course, I am much more likely to bow to the pressure of notes like the one you're apparently adding, and completly disable all notes at some point, rather than adding filtering. I don't like arms races. how about a configuration option so that debconf notes get sent to an email address rather than to the screen? craig
Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption
On Sat, Jun 28, 2003 at 03:33:16PM -0500, Steve Langasek wrote: On Sat, Jun 28, 2003 at 04:08:05PM +0100, Millis Miller wrote: E) Email does binary attachments and uses MIME (mime types, base64 encoding) to attach and send them with the message. You can't do this by doing what is described above. You can UUEncode it, but A LOT of mail clients don't support UUEncoding anymore. Plus, you can attach multiple binary files with email, not just one UUEncoded file. For instance: uuencode file.bin | gpg --clearsign | mail OTOH, the above features seem useful. mime-construct does multiple mime attachments. it does an excellent job, a very useful and versatile tool. it doesn't do uuencode, but a) uuencode is deprecated and should be avoided, and b) that's easy enough to do anyway: (for i in file1.bin file2.bin file3.bin ; uuencode $i ; echo ; done) | \ gpg --clearsign | mail ... FWIW, i don't think that mere duplication of existing functionality is a reason for a package not to be included in debian(*), but email is a really bad name for this program and this package. it's far too generic. (*) the only criteria for inclusion in debian are: 1. is it free? 2. is someone willing to package and maintain it? craig
Re: Packages: an average 66321 bytes per line of description
On Mon, Jun 23, 2003 at 09:10:09PM -0500, Steve Langasek wrote: On Tue, Jun 24, 2003 at 07:56:42AM +0800, Dan Jacobson wrote: Fellas, looking in the Packages files, some big packages have little descriptions, some little packages have big descriptions, and this package description went wee wee wee, all the way home. Why does this belong on debian-devel instead of debian-curiosa? because some packages have really crappy useless descriptions. the worst culprits are usually sets of binary packages from the one source file which have package descriptions like libfoo-dev = dev files for libfoo, libfoo-doc = documention for libfoo, and libfoo = runtime files for foo library, without bothering to describe what foo actually is. well, duh! like nobody would ever guess that a package called libfoo-doc was the documentation for libfoo. tell the reader something we DON'T know. a package description is supposed to tell someone who has never heard of foo before a little bit about it, not just multiple variations of foo's name. craig
Re: Packages: an average 66321 bytes per line of description
On Tue, Jun 24, 2003 at 04:15:29PM -0500, Steve Langasek wrote: On Tue, Jun 24, 2003 at 10:41:59PM +0200, Josip Rodin wrote: On Tue, Jun 24, 2003 at 07:17:58PM +0200, Torsten Landschoff wrote: the worst culprits are usually sets of binary packages from the one source file which have package descriptions like libfoo-dev = dev files for libfoo, libfoo-doc = documention for libfoo, and libfoo = runtime files for foo library, without bothering to describe what foo actually is. well, duh! like nobody would ever guess that a package called libfoo-doc was the documentation for libfoo. tell the reader something we DON'T know. But he knows what libfoo is - or at least he is just a $ apt-cache show libfoo away from that information. Do we need to duplicate the description of a library package in each and every supporting package? not much use when you're in dselect, wondering what foo is and whether it's a good or useful thing to install. also not much use when the description for libfoo just says runtime files for foo, and none of the other obviously associated packages bother to describe it either. the person who packages it knows what it is, but he/she has to assume that the reader doesn't and should therefore provide a brief but useful description. not everyone catches every single announcement on slashdot or freshmeat or sourceforge, not everyone is fully aware of every project in every niche. Not all of it, but you can't object to duplicating a single sentence saying what it is. When the sentence in question is the one that goes in the short description, and already fills the available space without prepending runtime files for foo ? Is the concern here with the short descs (I don't expect much from short descs of affiliate packages), or with the long descs? the concern is with package descriptions that assume that the reader knows what foo is. just having a brief description in one of 3 or 4 or more packages (and some i've seen don't even bother describing it in one) isn't good enough. each individual package needs that brief description. craig
Re: Packages: an average 66321 bytes per line of description
On Wed, Jun 25, 2003 at 07:07:46AM +0800, Dan Jacobson wrote: Anyway, one liner snob descriptions just have to go. $ apt-cache show emacs21 Description: The GNU Emacs editor GNU Emacs is the extensible self-documenting text editor. Oops, I see, it is self-documenting. that's actually a perfectly adequate description. it tells someone who has never heard of emacs before that it is an editor. good enough. a description doesn't have to (and shouldn't!) summarise all of a package's features, all it needs to do is give someone a rough idea of what kind of beastie it is. for a package like emacs, it's basically impossible to summarise all of its features anyway. craig
optional filtering and/or tagging is the perfect compromise
On Sun, Jun 15, 2003 at 09:22:08AM -0500, Manoj Srivastava wrote: As I have said before, as long as the default is to not cause data loss for everyone (since dropping emails may cause data loss), but allow people to opt in to have their mail filtered, I would have no objection. Opt in filtering is fine, and what other people do with their email is certainly no business of mine. this is a more than reasonable compromise - so please let's do it. craig
Re: Problems with XFS patch and SMP
On Sun, Dec 08, 2002 at 04:26:03PM -0500, Bob Hilliard wrote: Bug#171943 reports that dictd 1.8.0 fails to start with the following error message: [EMAIL PROTECTED]:~$ /usr/sbin/dictd -d nofork :I: 2535 starting dictd 1.8.0/rf on Linux 2.4.19-xfs Tue Dec 3 23:43:09 2002 dictd (dict_index_open): Cannot mmap index file /dev/null(dict_index_open) Cannot mmap index file /dev/nulldict_index_open: No such device (dict_index_open) dict_index_open: No such device that looks like it may be a configuration errorwhy else would it be trying to mmap /dev/null? I have not experienced any problems with this version in woody, sarge or sid, using a 2.4.18 kernel, and I have not received any other similar bug reports. The reporter is running a 2.4.19 kernel with the XFS patch and SMP support. Are there any known issues with the XFS patch and SMP support that could contribute to this problem? not that i've noticed. i've been running 2.4.19 XFS on my SMP workstation for over a month without any problems at all. Linux siva.taz.net.au 2.4.19-xfs #1 SMP Sat Nov 2 14:31:23 EST 2002 i686 unknown unknown GNU/Linux Is anyone running dictd with a 2.4.19 kernel with the XFS patch and SMP support? i'm running the dict client on this machine, but not the dict server. i'm running the server on another machine (currently running ancient kernel 2.4.9 with XFS patches). i just installed dictd 1.8.0-1 and one small dictionary (dict-elements) to test it. it seems to run and answer queries without problems. running it with dictd -d nofork shows: [EMAIL PROTECTED] [11:04:49] ~# /usr/sbin/dictd -d nofork :I: 1493 starting dictd 1.8.0/rf on Linux 2.4.19-xfs Mon Dec 9 11:05:02 2002 :I: elements 130 20751507646260 a query for potassium results in the following output: :C: dict 1.8.0/rf on Linux 2.4.19-xfs :D: * potassium 1 :I: quit: d/m/c = 1/0/7; 0.000r 0.000u 0.000s if you have any other tests you'd like me to run, i'll leave dictd installed here for a day or two...then i'll remove it. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: bill gates Linux
On Fri, Dec 06, 2002 at 03:07:17AM -0800, [EMAIL PROTECTED] wrote: [...] I am trying to avoid the problem which I have of needing a degree in Rocket Science to even see anything on my computer which originates from the blessed Linus kernal. Who in this world can actually read hexadecimal code anyway. either 1) you're a troll or 2) you resent having to learn or understand anything about your computer or 3) both. in any case, my advice to you is thæ same: linux is probably not for you, you would be happier staying with windows. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Are we losing users to Gentoo?
On Thu, Nov 21, 2002 at 12:15:12PM -0800, Thomas Bushnell, BSG wrote: Craig Sanders [EMAIL PROTECTED] writes: i remember a year or so ago when i complained about this worthless practice i said that it would end up consuming hundreds of megabytes - i was told that was ridiculous, it would never happen. Megabytes! Horrors. You counted up to 96 MB in your computation, what computation? i provided an example directory listing taken directly out of my debian mirror. the approx 310MB came directly from du: falls:/home/ftp/pub/mirrors/debian/pool/main/k# du -sck kernel-image-*i386 14360 kernel-image-2.2.20-i386 3572kernel-image-2.2.20-reiserfs-i386 7544kernel-image-2.2.20-udma100-ext3-i386 14124 kernel-image-2.2.21-i386 14128 kernel-image-2.2.22-i386 85560 kernel-image-2.4.16-i386 76528 kernel-image-2.4.18-i386 96712 kernel-image-2.4.19-i386 312528 total *i386 missed one, should have been *i386*. add another ~20MB for: 19268 kernel-image-2.4.18-i386bf these figures don't include the alsa-modules or linux-wlan-ng kernel module packages that have to be compiled for each specific kernel (add another approx 17MB for those at the moment). which I will assume to be correct. how generous of you. you could have quibbled about every line of the directory listing i provided, but you restrained yourself - for that small mercy, i will be forever in your debt. Current cost of hard disk is something between $1.00 and $1.50 per gigabyte. it's not just the cost of disk space, it's the cost of bandwidth too - and recurring bandwidth expenses cost a LOT more than disks (once-off capital expenditure) Branden, could we afford to buy a couple 110 GB disks to hold this increase? can debian afford to buy the same for every mirror too? or pay the bandwidth costs of about 100MB per debian release of each kernel version? at an average of 4 or 5 debian releases per kernel-image package, that's about 400 or 500MB per kernel version. bandwidth isn't free, nor is it universally cheap. some countries are still paying up to $0.20 per MB for downloads, or even more. work out the cost for your location. even in the US where bandwidth is relatively cheap, it still adds up to real money. every mirror has this expense, just to provide allegedly optimised kernels for people who are too lazy to compile their own, who probably wouldn't even notice the optimisation anyway. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Are we losing users to Gentoo?
On Thu, Nov 21, 2002 at 07:27:06PM -0600, Steve Langasek wrote: On Fri, Nov 22, 2002 at 12:01:12PM +1100, Craig Sanders wrote: Current cost of hard disk is something between $1.00 and $1.50 per gigabyte. it's not just the cost of disk space, it's the cost of bandwidth too - and recurring bandwidth expenses cost a LOT more than disks (once-off capital expenditure) Are you referring to the increase in bandwidth requirements for the mirroring itself? yep. i wouldn't mind so much if all the extra i386 kernels were in a separate subdirectory under pool/main/k/ - then there would be no need to update regexp exclusion patterns every time there's a new i386 compatible architecture or a new compile-time option. it would still be wasteful, but a lot easier to manage. I wouldn't expect an increase in the number of available kernels to lead to an increase in the number of kernel packages users need to have installed. right, no significant increase. those who upgrade every day know that it costs them, and it only affects them if they use the debian-supplied kernels rather than compile their own. at worst, it's probably less than 10MB per week. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
/Packages.bz2 dc75329fbbb6556e26e52ad798ba73760484154f 87 non-free/binary-sparc/Release b43dc9ac181b4dbdac2ee33b8f888aacadf9839c 107883 non-free/source/Sources 3eacdacb58f276b1b4c08e42e28f6168fa72abea31343 non-free/source/Sources.gz 691a356bbb9fb6909a584f6618ba23f915b0b15e26431 non-free/source/Sources.bz2 e77f4e372bfd9d13ae0de223849dd927ad381ff0 88 non-free/source/Release c41143e0699764810c3a3433b5ff133289a3860114235 main/debian-installer/binary-alpha/Packages 1c08ba8db13f88635116c518b6014f14be55e202 4462 main/debian-installer/binary-alpha/Packages.gz 46fb71630491e58d5d4163cab13c980db44fa30c14257 main/debian-installer/binary-arm/Packages 81c5ba8e04d3c79eaa879f75dd1097c08df460a3 4477 main/debian-installer/binary-arm/Packages.gz 9810fae5665c2123eef1cf8712dd224ccaed00d914160 main/debian-installer/binary-hppa/Packages aa0e152302c53b3abfa2773df1f8083d1ac1ee60 4482 main/debian-installer/binary-hppa/Packages.gz 82c9d2c18d312290c56f3ed16ad277d3630e0c87 9154 main/debian-installer/binary-hurd-i386/Packages a7ffca40f79120c23359e00c096a16643920b370 3001 main/debian-installer/binary-hurd-i386/Packages.gz 9bf55fcb4accfaa23a8cc9c42241571b39a0223734318 main/debian-installer/binary-i386/Packages 5612c4ecb49ec3d2b00be0868c406f1bd4b68a40 7084 main/debian-installer/binary-i386/Packages.gz a9d2fa8c511504e934835cac50b1476b0c257b5814341 main/debian-installer/binary-ia64/Packages e763a99f0fd6914fe47c0fe4979300642ce6d625 4482 main/debian-installer/binary-ia64/Packages.gz f130ec50a1ffe420af228f49fe1ff587d6275d3d14157 main/debian-installer/binary-mips/Packages f5bed8be4f5c2adc579b2f30bcb58d4d616a3843 4473 main/debian-installer/binary-mips/Packages.gz c3ef04b00ec2f9f250aa81b30c94202f8ede120914237 main/debian-installer/binary-mipsel/Packages 5e76e18a9cd8ff9b46679a9f27ebe1eee5cfb648 4480 main/debian-installer/binary-mipsel/Packages.gz c50f2e125f56656fd8ef570597778db4922b099314299 main/debian-installer/binary-m68k/Packages 52302dcc18d75f969aac4f469be57af376b5768d 4488 main/debian-installer/binary-m68k/Packages.gz b94db7e7f11e6cfd5b5bef8bf5a07a799b0c32f519870 main/debian-installer/binary-powerpc/Packages 47e5e62a496fec22615f91cdff4d2ac77fd21226 5321 main/debian-installer/binary-powerpc/Packages.gz 0dc78e4041945a843b7ca92b338d5c6d63003d1115386 main/debian-installer/binary-s390/Packages 107ea89e39afb295bf99477bd9ebe7483c808dcb 4817 main/debian-installer/binary-s390/Packages.gz 8386c10cbcb3bebadc101a577e8516c3c3e46b50 1518 main/debian-installer/binary-sh/Packages 2cb939e446daf4b319b1c172ecd283ece2aee0f6 654 main/debian-installer/binary-sh/Packages.gz e6d7f7afad5eba7c04f6be8b4f64971ba5cb762314195 main/debian-installer/binary-sparc/Packages 9ca48708f119e3776fae836e2a8ab026d59244a5 4482 main/debian-installer/binary-sparc/Packages.gz craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: XFree 4.2.0 - again
On Tue, Apr 16, 2002 at 05:14:51AM +0300, Lasse Karkkainen wrote: You are probably sick and tired of this topic, but ... IT'S A QUARTER YEAR ANNIVERSARY OF 4.2.0 RELEASE! Yes, it really has been three (3) months (!) since it was released. so? 4.1 works just fine. Time to throw some gasoline on the flames ... Branden apparently is incapable of releasing it. So, I suggest that anyone, with enough knowledge and TIME, reading this, would volunteer as XFree package maintainer. Branden's comments suggest that he just doesn't have enough time for that. this may shock the hell out of Branden but i think he does an *excellent* job with the XFree packages. i may have some disagreements with him on various issues, but i have no problem at all with the quality or frequency of his work. debian needs more developers of his caliber. he took on X (an incredibly difficult set of packages) when everybody else had too much sense to even think about doing it and has done a fantastic job with it. there's a lot more to packaging a program than just compiling it and hoping that it mostly works on your own system. if you want that kind of quality-control then try redhat's contrib packages. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free software in main)
On Sun, Apr 07, 2002 at 10:08:53PM -0500, David Starner wrote: On Sun, Apr 07, 2002 at 10:26:48PM -0400, Colin Walters wrote: So the FDL is a free license because it's inconvenient for it to be not? No, they're saying that a vast majority of programs which are widely considered free by our community are using this license. Thus, the onus is on you to put forth a real argument for why it's not free. Um, it fails section 3 (Modifications permitted) of the DFSG? A strictly literal reading of the DFSG clearly prohibits Invariant Sections. Any body claiming that the FDL (with Invariant Sections) is free is basically proposing a change in the DFSG, or at least the readings or scope thereof. I'd say the onus is on the people who want to change the status quo. you're not allowed to change the license or the author's name of a GPL-licensed program so, by your strictly literal reading of the DFSG that makes the GPL non-free. The GPL, BSD license and other licenses we consider to be DFSG-free all allow invariant sections - specifically, attribution, copyright, license, and similar administrivia. even where this isn't specifically stated in the license, tradition custom within the free software community take it as a given that these things are not to be changedbut acknowledging that requires the application of common sense, which just proves that you're not playing the debian game. personally, i think that many debian people just like to argue pedantically for the sake of arguing pedantically. doesn't matter what the issue is, the main thing is that a good (i.e. long-winded and tedious) argument is had until everyone is bored into apathy. this practice is, of course, a wonderful morale booster. hip hip hooray. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 01:47:02AM -0800, Jonathan Walther wrote: I object to attempts to lock me in to a single MUA. so do i. it's evil. While I'm evaluating I expect to be able to continue using Mutt until I am confident enough in Evolution to cut the umbilical cord. i learnt long ago not to evaluate new MUAs on my main mailbox - or even with my usual login account. strange new MUAs (especially GUI ones) have a nasty habit of doing weird shit to mailboxes. they move it around or helpfully convert it to their own non-standard format or some other annoying thing. to evaluate an MUA safely, create another account on your system (you can have mail delivered to it by setting up .forward to CC your real account's mail to it) and login as (or su - to) that userid before running the MUA. better yet, just stick with mutt. It Workstm :-) craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: How to put files at a location determined at install-time.
On Mon, Dec 31, 2001 at 07:09:41PM +0100, Marc L. de Bruin wrote: So, the root-user might want the files to be physically installed on /raid1, e.g. /raid1/mydata, so that a user blah (/raid1/home/blah) can make a hardlink from /raid1/home/blah/afile to /raid1/mydata/afile. if the local sysadmin wants this, then they can move-and-symlink the directories to wherever they want. e.g. say your package uses /var/foo, but the sysadmin wants that data to be in /raid1/home/foo: mv /var/foo /raid1/home/ # alternatively use cp -af or tar # followed by rm -rf ln -s /raid1/home/foo /var/ this doesn't require any weird or special-case handling in the package. it's a fairly normal systems administration task. for example, it's not at all uncommon to move-and-symlink /usr/doc and /usr/share/doc to another partition when the /usr partition is too small. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: What config file for a .pm perl module ?
On Fri, Dec 28, 2001 at 01:11:15PM +0100, Eric Van Buggenhaut wrote:
print Dumper($virtula1);
I spent some time try to understand why it was failing ;)
oops. yeah. i should have cut-and-pasted the script i got working in
/tmp instead of what i originally typed in the message. there were a
few obvious errors in the message. but the point was to be provide
illustration of how to go about it, not an exact solution for your
problem. i.e. method, not detail.
---cut here---
#! /usr/bin/perl -w
use Data::Dumper ;
use strict ;
my @fields = qw(hostname username password port database attributes
connect driver dbhost) ;
my $virtual1 = {} ;
while () {
chomp ;
s/#.*// ;
s/^\s*|\s*$//g ; # strip leading trailing spaces
next if (/^$/) ;
my @line = split /\|/ ;
foreach(1..8) { # loop from $fields[1]..$fields[8]
$virtual1-{$line[0]}-{$fields[$_]} = $line[$_] ;
} ;
} ;
print Dumper($virtual1) ;
---cut here---
from the (modified) input you provided, this produces output like this:
---cut here---
$VAR1 = {
'personales' = {
'driver' = 'mysql',
'username' = 'root',
'attributes' = '{}',
'database' = 'acs',
'port' = '',
'password' = 'op.re,13',
'dbhost' = 'localhost',
'connect' =
'DBI:mysql:database=PaginasPersonales:host=localhost'
},
'acs' = {
'driver' = 'mysql',
'username' = 'root',
'attributes' = '{}',
'database' = 'acs',
'port' = '',
'password' = 'op.re,13',
'dbhost' = 'localhost',
'connect' = 'DBI:mysql:database=acs:host=localhost'
}
};
---cut here---
which is pretty much the structure you wanted.
other comments:
i still think you should use a field separator which isn't in the field
contents - much simpler, and far less prone to error.
there's also no need to have quotes (`) around the connect string -
you'll only have to strip them off before using it.
also, why have the connect string at all when it can be built up from
the details provided in the other fields? it seems to me that the
fields you need are:
username
dbi_driver
attributes
db_name
db_host
db_port
db_user
db_password
the connect string can be built up like so:
$connect = DBI:$driver:database=$db_name:host=$db_host ;
(using db_port, db_user, and db_password as well if required)
craig
--
craig sanders [EMAIL PROTECTED]
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Re: What config file for a .pm perl module ?
On Thu, Dec 27, 2001 at 07:03:38PM +0100, Eric Van Buggenhaut wrote:
I wanted to be able to use a config file similar to /etc/passwd like:
#This is the list of users needed by DBIx::Password
#(/usr/lib/perl5/DBIx/Password.pm)
#
#Syntax is:
#host:username:password:port:database:attributes:connect:driver:host
#
#You can use simple quotes when field contains colon(s)
acs:root:op.re,13::acs:{}:'DBI:mysql:database=acs:host=localhost':mysql:localhost
personales:root:op.re,13::acs:{}:'DBI:mysql:database=PaginasPersonales:host=localhost':mysql:localhost
since you have : characters within fields, it's far simpler to use
another character (e.g. pipe) as the field separator, like so:
acs|root|op.re,13||acs|{}|DBI:mysql:database=acs:host=localhost|mysql|localhost
personales|root|op.re,13||acs|{}|DBI:mysql:database=PaginasPersonales:host=localhost|mysql|localhost
TAB characters would be another good choice for field separator...or
anything which isn't going to appear within the fields.
while (IN) {
next if (/^#/ || /^$/);
@host = m/:?([^':]*)||:?'([^']*)'/g;
foreach (@host) {print $_ };
print \n;
}
try:
# set up an array containing the field names in order, so that
# we can use a for loop rather than a whole bunch of assignment
# statements.
@fields = qw(hostname username password port database attributes
connect driver dbhost);
my %virtual1 = {};
while () {
chomp ;
s/#.*//; # strip comments
s/^\s*|\s*$//g; # strip leading trailing spaces
next if (/^$/); # ignore blank lines (incl. comments)
my @line = split /\|/ ;
# do whatever you need with @line
# $line[0] = hostname
# $line[1] = username
# $line[2] = password
# ...
# $line[8] = dbhost
foreach(1..8) { # loop from $fields[1]..$fields[8]
$virtual1-{$line[0]}-{$fields[$_]} = $line[$_] ;
} ;
};
close(IN);
you can verify that this does what you want by using the Data::Dumper
module. e.g. by adding something like the following lines to the script:
use Data::Dumper ;
print $Dumper($virtual1);
alternatively, use the IniConf module (in package libiniconf-perl). it
uses ugly multi-line windows style .ini configurations, but the IniConf
module parses it automatically into a hash for you. it's almost ideal
for what you want to do, if you can handle the ugliness of .ini style
configurations.
craig
--
craig sanders [EMAIL PROTECTED]
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Re: Flamewars Why pedantic spelling is good.
On Sat, Dec 22, 2001 at 02:55:13AM -0600, Adam Heath wrote: On Sat, 22 Dec 2001, Craig Sanders wrote: yawn. you're wrong. again. I have seen no quotes from you, of other, *outside* sources, that show 'zonefile' in widespread use. I *have* seen posts saying that 'zone file' is, however. i don't feel under any obligation to act as a dictionary for lazy or stupid people, however earlier in this thread i already gave two examples of other DNS-related packages within debian that use the word 'zonefile'. in the description, no less. i guess you must have missed that because i failed to highlight the significance with an enormous flashing neon sign for the congenitally stupid. well here it is, just for you: BLINK Package: autodns-dhcp autodns-dhcp uses bind 8's dynamic update features to update a zonefile Package: zone-file-check Filename: pool/main/z/zone-file-check/zone-file-check_1.01-3_all.deb Description: Syntax-checker for BIND zonefiles This script is used for syntax-checking your zone-files after a of zonefiles, but also if you just want to check a single file. /BLINK any search on google or other search engines will reveal many thousands of uses of the word 'zonefile'. like i said, it's in common usage in the field and has been for years. but that couldn't possibly be evidence, could it? after all, that would mean i was right and that would be embarrassing to admit to, wouldn't it? [blah blah blah] All procedures were followed. To the letter. So, that obviously means that the bugs are incorrect. Not. there's more to a bug report than following procedure to the letter. relevance and correctness are more important attributes. the bug reports i complained about were incorrect because neither zonefile nor usenet are in any way spelling errors. and frankly, i don't give a damn whether you or anyone else agrees or disagrees. it's not in the least bit important. now please shut up and stop wasting everyone's time with this tedious thread. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Flamewars Why pedantic spelling is good.
[ drivel deleted ] in a word, No. btw, learn to spell authoritative. OTOH, it's kind of amusing to read someone who can't spell attempt to harangue me over spelling. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: thomas's trivia crusade
On Sat, Dec 22, 2001 at 11:17:34AM +0100, [EMAIL PROTECTED] wrote: Craig [EMAIL PROTECTED]@Sat, 22 Dec 2001 03:50:08 +0100: they are actually *REAL* bugs that affect the operation of the package, not trivial items like spelling mistakes that affect nothing. And because developer x does not fix his bugs, you think you shouldn't fix your bugs either? Think about your developer karma[0] man! ;-) no, that's not what i said. i said that there are real bugs that are actually worth spending time on...as opposed to non-bugs like whinges about the words zonefile and usenet. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Completely OT, just to quickly prove a point.
On Wed, Sep 26, 2001 at 10:08:04PM -0600, Russel Ingram wrote: On Thu, 27 Sep 2001, Craig Sanders wrote: I've used the make-kpkg command to create kernel packages, but they always come out with a custom-1.00 label on them and I haven't figured out how to get around that. RTFM. see the --revision option. Does anyone else on this list see this as a fairly unhelpful, and insulting response to a reasonable question? Please reply to me directly and to [EMAIL PROTECTED] DO NOT REPLY TO THE LIST! do not reply to me. i'm not interested in any comments related to any issues raised by this over-sensitive loser. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: XFS Kernel image packaging
On Tue, Sep 25, 2001 at 01:12:52PM -0600, Russel Ingram wrote: Pardon me if I sound like a newbie here. I am fairly new to the Debian way, but I am a Linux veteran. I have noticed that there are patches available in the debian package tree for the XFS filesystem but there are no available kernel-image packages with XFS already built in. Is there a specific reason for this or is it just because no one has stepped forward to offer such a package? because it's not necessary. we already have way too many kernel-images with trivial feature variations - that have no business being in debian supplied kernels, but should be compiled by those who need them when they need them. debian should provide only the bare minimum number of kernel images that are required to install debian...anything else should be a custom kernel compile by the end user. if and when XFS support gets into the mainstream kernel, then support for it should be compiled in. until then, it's only one of many optional patches available. in the meantime, if you want to compile a kernel with xfs support: 1. apt-get install kernel-source-2.4.9 kernel-package (you'll also need gcc and bin86 and so on, of course...and libdb3-dev if you want to compile aic7xxx support) 2. download the appropriate patch version from ftp://oss.sgi.com/projects/xfs/download/ 3. patch the kernel 4. there will be one reject, in .../linux/init/main.c - it's easy enough to patch this by hand with vi. 5. run make config and make-kpkg - whatever your usual kernel compile procedure is. i've done this dozens of times now. it works. I've used the make-kpkg command to create kernel packages, but they always come out with a custom-1.00 label on them and I haven't figured out how to get around that. RTFM. see the --revision option. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: isync vs mailsync
On Wed, Sep 05, 2001 at 09:43:09AM +1000, Brian May wrote: Despite these problems, Gnus is the only program I have seen that will highlight replies to my mail, something I find very valuable in large mailing lists like this one. btw, mutt will do that. it highlights messages sent by or to you. dunno if it looks at References: or In-Reply-To: lines for that, but it certainly uses From:, To:, and CC: headers. makes it quite easy to spot your messages and replies to them in large threads. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: reopening ECN bugreport/netbase
On Thu, Sep 06, 2001 at 01:37:02AM -0500, Scott Dier wrote: * Craig Sanders [EMAIL PROTECTED] [010905 20:17]: the correct solution is to NOT compile ECN support into the distribution kernels. that's a choice that should be left up to the individual system So, lets fix one problem by creating another problem! ECN isn't there anymore! no, that isn't a problem. the kernel works just fine without ECN being enabled. if you want it, you do what every other user of the linux kernel has to do and compile a new kernel with support for it. quite frankly, if someone doesn't know how to compile a kernel then they're not qualified to decide whether they want to use it or not. in that case, the correct course of action for a package maintainer is to cause the least harm. the fact is that there is no possibility of harm if ECN is disabled in the kernel, while there IS possibility of harm if it is enabled. therefore it should be disabled by default. anyone who is running servers busy enough that they actually need ECN should have enough of a clue to know how to compile a kernel and enable it. What if some users were actually using that? see above. since it's only been enabled in recent kernel-image packages, very few (if any) people will be be surprised by it being removed again. ECN IS NOT A USELESS RFC. ECN IS NOT A USELESS RFC. of course it's not. it will eventually be universal. some people actually like to use this stuff. yes, i know. i use it. however, it's an experimental feature which isn't needed on the debian distributed kernel images. it might be appropriate to have it on by default in a year or so. but not now. craig ps: why is it that so many people get so upset if their pet feature-of-the-month isn't the default in debian? debian's defaults should conform to the principles of Least Suprise and Least Harm, not the principle of Maximal GeeWhizzery. it's only a default, get over it. -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: reopening ECN bugreport/netbase
On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote: if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf /dev/null; then echo sys/net/ipv4/tcp_ecn=0 /etc/sysctl.conf fi to the kernel-image-2.4.x postinst. no, this is broken and evil. kernel-image packages should NOT override someone who chooses to have ECN enabled. the problem is that recent kernel-images have ECN support compiled in. they shouldn't. the correct solution is to NOT compile ECN support into the distribution kernels. that's a choice that should be left up to the individual system admin - if they want it, they can compile a kernel to support it. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: sysctl should disable ECN by default
On Mon, Sep 03, 2001 at 07:44:19AM +1000, Herbert Xu wrote: 1. CONFIG_INET_ECN must be turned on, otherwise the user will have to recompile the kernel to use it. yes, that is correct. if the user wants ECN, they should compile the kernel to enable it. [...] So do whatever you want, but please do it in the right place. which is in the kernel-image .config file. 1. stock kernel-images should only include options which are necessary for booting installing debian 2. they should not include non-essential experimental features. ECN fails on both counts. ECN is a good thing, and widespread adoption of it should be encouraged - BUT enabling it should require an informed act by the user since it is likely to result in network outages at the moment. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: support for older distributions
On Wed, May 09, 2001 at 04:49:04PM +1000, Brian May wrote: You say stable is old. That is exactly Russell's point. Some people want a mostly stable system, but need some up-to-date packages from woody. that's a choice people have to make. you can have an old 'stable' release, or you can have an up-to-date 'unstable' release. there really is no in-between, no matter how hard you might try to convince yourself otherwise. if you upgrade one package, you may have to upgrade another...and another...and if you're going to do that, you're better off upgrading to the version(s) in unstable because they're more likely to be tested and debugged by other people than a package recompiled for an old debian release. I wouldn't suggest going any further back then stable though. Craig for example, ask yourself: why is libc6-2.2.2-potato1 (or Craig whatever the potato version would be) any better or Craig safer than just installing libc6-2.2.2 from woody or sid? Craig i can't see how it could be, and all you've achieved is Craig having two divergent versions of 2.2.2 to support. I think you missed Russell's point. That was: compile unstable packages against stable's libc6. So libc6 would not be included in this list. libc6 was only an example. if not libc6, then libgtk or libfoo or libbar - or any application or tool. why is application bar any *more* reliable or trustworthy just because it is compiled against an old version of libc6 in potato? it's not. all you're doing is deluding yourself that your system is more stable than it would be if it was running unstable. the truth is that it is likely to be *less* stable because that particular combination of compiler/libraries/application version is less tested than what is in unstable. the sole advantage to this is so that you can lie to your boss and say we're running the stable release and be telling only a half-truth (or half-lie...doesn't matter, it's still bullshit) now it's your system, you can do whatever you want with it. that's not the point i'm making. i just don't like self-deception being touted as reality. Craig debian is a live distribution, easily upgraded in place Craig at any time over the internet - why limit yourself to Craig looking at debian in a way which is more suited to Craig commercial CD-ROM only closed source systems? Because some people don't want to upgrade libc6 on a stable system (ie. they want a mostly stable system), but require new features of particular packages in unstable, and are willing to risk the chance that these new packages may be broken. isn't this what 'testing' was supposed to be for? so that people could run almost-bleeding-edge systems where packages have had the really serious bugs discovered and fixed by foolhardy people like me who run unstable? Craig IMO, forcing debian into that model is missing a large part Craig of the point of debian. Craig potato's been released. woody's getting closer to Craig freeze. lets move on. woody's release is still months away (dare I say almost a year?). it might not take so long if people didn't get distracted by obsessively backporting rather than moving on to the next release. Sure, another approach is to compile your own version of the unstable package, but Russell takes then one step further to have a central repository for unstable package for stable. Instead of the current situation of having many different apt repositories, each with different selections of packages compiled for stable, you would have one big repository that could be used by everyone. a fine idea (really, i'm not being sarcastic). but ALL it is doing is making yet another unstable. think about it: that's all it is - just another unstable tree, but with different versions of stuff. why bother? craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: support for older distributions
On Wed, May 09, 2001 at 06:36:30PM +1000, Brian May wrote: Craig == Craig Sanders [EMAIL PROTECTED] writes: Craig why is application bar any *more* reliable or trustworthy Craig just because it is compiled against an old version of libc6 Craig in potato? It is not so much the new application I was thinking of, but all the old stable applications that already exist on the system. So recompiling foo for stable might produce a broken version of foo. fine. Downgrade or remove the package again. Problem solved. Nothing lost in the process, except time taken to down load, recompile and test the package. But installing a new version of libc6 on a stable system has the potential for breaking the whole system. ok, i see your point but don't think that libc6 is that much of a special case - any package has the potential to break the whole system. admittedly, some (libc6, ldso, bash, etc) more than others...but the potential is still there. IMO IME the biggest risk to a system running unstable is not so much bugs in libc6 or whatever, it's 1. bugs in package pre,post scripts: a simple typing error like rm -rf / var/spool/foo can wipe out a system (not that i've seen this one - i'm just aware of the possibility...so i upgrade non-vital systems first); and 2. faulty depends/conflicts or version mismatch (e.g. apache modules needing to be recompiled for major releases of apache) it gets even more interesting when you want an upgraded version of some application which depends on a newer version of some library which, in turn, depends on a whole bunch of other stuff including a newer libc6. what do you do then? do you recompile the whole dependancy chain (incl. libc6) for potato or do you say bugger it, it's less hassle and less risk to upgrade to unstable? at what point does recompiling for stable stop being a convenience for potato users and start being being a dead-end duplication of unstable? craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: support for older distributions
On Mon, May 07, 2001 at 02:45:53PM +0200, Russell Coker wrote: Currently there are two usable repositories of Potato packages. There's a repository of kernel-related packages to run 2.4.x kernels on Potato, and there's a repository of LDAP related packages and other things that Wichert is maintaining. Both of these are good work, but even combined they don't provide what I consider to be adequate support for Potato. I would like a version of Potato that is not entirely frozen. It should have updates not only for security reasons but also for addition of new programs, and for adding new programs which add significant functionality and don't break things (such as Wichert's LDAP packages). why? aside from the installer floppies (which aren't relevant for upgrades), the main significant difference between potato and woody (or between any versions of debian for that matter) is the version numbers of the packages included. the distinction between versions of debian is entirely arbitrary, a matter of consensus reality rather than actual reality. your suggestion would add a huge load of administrative and maintainence overhead in order to support a convenient fiction - providing little or no real benefit. worse than that, it subverts the only real point in having versioned releases - the ability to know what is included in any released version. debian provides mechanisms for easy upgrade between release versions, and we always have provided that - why complicate matters with branched sub-releases of old versions? you also risk creating greater problems back-porting packages from testing or unstable - they would be divergent packages which don't get anywhere near the same amount of testing and usage as packages in the mainline development cycle. for example, ask yourself: why is libc6-2.2.2-potato1 (or whatever the potato version would be) any better or safer than just installing libc6-2.2.2 from woody or sid? i can't see how it could be, and all you've achieved is having two divergent versions of 2.2.2 to support. debian is a live distribution, easily upgraded in place at any time over the internet - why limit yourself to looking at debian in a way which is more suited to commercial CD-ROM only closed source systems? IMO, forcing debian into that model is missing a large part of the point of debian. potato's been released. woody's getting closer to freeze. lets move on. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Thu, Apr 26, 2001 at 07:48:02PM +1000, Herbert Xu wrote: I won't go below that as an SMP kernel is always required, no it's not. anyone running SMP ought to have enough of a clue to compile their own kernel. why should everyone else pay the price for their cluelessness? and the 686 flavour covers a very large chunk of the i386 userbase. a 386 kernel covers all of the ia32 userbase. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Sat, Apr 28, 2001 at 02:15:50PM +1000, Herbert Xu wrote: Please also consider that if the user were to compile his own kernel, he would face the problem of having to recompile the modules packages if they're needed. use kernel-package and all the module packages are compiled automatically, with the modules_image target. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Mon, Apr 30, 2001 at 12:41:22PM +0200, Torsten Landschoff wrote: On Mon, Apr 30, 2001 at 05:19:12PM +1000, Craig Sanders wrote: anyone running SMP ought to have enough of a clue to compile their own kernel. This is the point where I disagree. I really hate having to build my own kernel just to do some tests with a fresh installation. so you have spent good money on a high-end SMP machine but you're not willing to put in 5(*) minutes work (running make config or menuconfig or xconfig) to build a kernel which is optimised for your hardware. strange. IMO, it's even stranger when you consider that it's 5 minutes work only for the first time that you compile a kernel for that machine (or type of machine if you have a bunch of similar or identical machines). after that, it's less work because you can re-use the old .config file and just run make oldconfig to handle any new compile-time options. (*) i'm not including the 3-15 minutes (depending on CPU and disk speed and memory) it takes to actually compile the kernel because that can run in the background - it's not work, it's just waiting (or getting on with something else while it's compiling) craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: Many ports open by default
On Sun, Apr 29, 2001 at 10:29:58PM -0600, Dwayne C. Litzenberger wrote: I suspect it's already been discussed before, so I'll ask instead of flaming. (See! I can learn!) many times before. Why does a server automatically get run just because it's installed? because if you didn't want it to run, you wouldn't have installed it. if you want to install it but not run it, then edit the startup script. simple. Shouldn't the default be to not run daemons unless they are explicitly enabled, [...] no, users shouldn't install daemon packages if they don't want the daemon to run - or they should learn how to edit the startup scripts (or inetd.conf) if they want non-standard behaviour. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: Many ports open by default
On Mon, Apr 30, 2001 at 02:25:34AM -0400, Andres Salomon wrote: If there's nothing that depends on portmap, then default to not installing portmap. speaking of portmap, debian's portmap is not an insecure thing to run by default because it is compiled with tcp-wrappers support and rejects all non-localhost connections that aren't explicitly allowed (by ip address) in /etc/hosts.allow Having daemons shut off by default is not the way to go, however. yep. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: Many ports open by default
On Mon, Apr 30, 2001 at 07:37:21AM -0500, Warren A. Layton wrote: Well, not everyone that installs ssh wants to run the server (some may just want to use the client to connect to other machines). This is just one example; I'm sure that there are many more. that means either: 1. ssh and sshd should be split into separate packages. if it bothers you enough, file a bug report. i'm happy with the way it is. or 2. the handful of people who want the ssh client but not the ssh daemon can learn how to edit /etc/init.d/ssh craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 09:56:58PM -0500, Rob Browning wrote: Just in case anyone else was confused, I'm still in favor of having at least *one* precompiled kernel per-architecture, so no one *has* to compile a kernel, i think everyone is in favour of that. the issue is whether it's appropriate to have a dozen or so kernel-image packages (and associated kernel-headers packages) per kernel version, when one(*) will do. (*) or whatever the minimum number is that will boot on all ia32 boxes. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 02:18:30AM +1000, Daniel Stone wrote: I could disagree pretty heavily by pointing that this would be shit as it would add an hour to the install. Why not just provide a stock i386 kernel and let people compile it later on? Some people need to patch in mm/swap patches, netfilter patches, their own hacks, etc, etc. please pay attention. nobody (at least as far as i can tell) has suggested getting rid of the stock kernel-image package, so there will be no effect at all on people who just want to install the system and run it. the point at issue is whether there should be dozens of kernel-image and kernel-headers packages when one is enough to do the job. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 10:31:46AM +1000, Herbert Xu wrote:
On Tue, Apr 24, 2001 at 05:26:27PM -0700, Aaron Lehmann wrote:
Ok, so why did this come up at all in the discussion of the kernel
package bloat? It seems to me that providing optimized kernels is a
Because someone asked why the kernel-headers necessary. Their
presence allows both our module maintainers and other maintainers
to compile modules easily. It doesn't mean that they will. But it
certainly makes it a lot more likely.
no, it makes it a lot less likely.
a person/company producing a binary kernel module is FAR more likely to
create one for debian if they only have to create one module, rather
than a dozen or so.
even if they can be bothered putting in the effort to figure out exactly
what kernel-headers package(s) and how it all works, they need installed
it's still a lot more work to produce and support a dozen versions(*) of
their module rather than just one.
(*) per kernel version that they choose to support.
You seem to be confusing the kernel-header discussion with the
kernel-image discussion. Please go back and reread the thread.
they're one and the same. kernel-{image,headers} package bloat has
been the topic of this thread from the beginning.
craig
--
craig sanders [EMAIL PROTECTED]
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 04:56:19PM +1000, Herbert Xu wrote:
a person/company producing a binary kernel module is FAR more likely to
create one for debian if they only have to create one module, rather
than a dozen or so.
There two discussions here:
1. The number of kernel flavours.
2. The need for kernel-headers for each flavour.
I was talking about 2.
i am, and always have been, talking about the bloated number of
kernel-{image,headers} packages.
sometimes that requires demolishing some of the digressions in order to
force things back to the point.
You seem to be confusing the kernel-header discussion with the
kernel-image discussion. Please go back and reread the thread.
they're one and the same. kernel-{image,headers} package bloat has
been the topic of this thread from the beginning.
In that case, you're mixing them up as well.
you are mistaken. i started the thread, i know what i started.
craig
--
craig sanders [EMAIL PROTECTED]
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: Referring what kernel-images to build to the technical committee?
On Wed, Apr 25, 2001 at 08:30:31PM -0400, Sam Hartman wrote: [...] i think you've done a good job of summarising the issues. i hope we can resolve this soon. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 07:30:47PM +1000, Herbert Xu wrote: On Tue, Apr 24, 2001 at 08:47:44AM +1000, Craig Sanders wrote: what is the DIFFERENCE between kernel-headers-2.4.2 and all the other 2.4.2 kernel headers packages? Kernel-headers-2.4.2 is built with the default config file, and the other ones are built with their respective config files. so, what's the difference between all the packages? they're the same header files from the same kernel source tree, aren't they? and while you're at it, how about answering the other questions that you ignored in my last message? Which were? it's only one kernel, one source tree...so where do all these different header files come from? what's the point of them? what do they provide that just plain kernel-headers-2.4.2 doesn't provide? craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Sun, Apr 22, 2001 at 09:18:33AM -0500, Adam Heath wrote: [...good stuff deleted...] Now, it doesn't take a genius, to see how this will cascade. [...more good stuff deleted...] The best way to handle all this, is to train users how to compile a kernel, or, let them pick the optimization they want, and we compile the kernel for them. well said. couldn't agree more. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Mon, Apr 23, 2001 at 07:24:13PM +1000, Herbert Xu wrote: How are they going to compile a kernel if they haven't even installed Linux? that's obvious. by installing linux and then compiling a kernel. The most important function of initrd is to reduce the number of kernel images needed on boot floppies to one. you're missing the point again. nobody is disputing that using initrd was a good idea - it's a useful tool. what is being disputed is the package bloat of having dozens of kernel-image packages taking up approx 110MB for EACH kernel version. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Mon, Apr 23, 2001 at 09:37:55PM +1000, Herbert Xu wrote: Andreas Metzler [EMAIL PROTECTED] wrote: mean by module builders [...] especially those outside Debian. The people from alsa who do not use Debian (How would they use a debian-package?) or debian-users who no debian-developers (= no @debian.org email-adress)? Pointers to documentation to enlighten me are welcome. I'm talking about people like VMWare, i.e., people who distribute binary only modules. you're still failing to explain this point adequately. what, exactly, is the difference between kernel-headers-2.4.2 and: kernel-headers-2.4.2-386 kernel-headers-2.4.2-586 kernel-headers-2.4.2-586tsc kernel-headers-2.4.2-686-smp kernel-headers-2.4.2-686 kernel-headers-2.4.2-k6 kernel-headers-2.4.2-k7 kernel-headers-2.4.2-pentium4 kernel-headers-2.4.2-pentiumiii kernel-headers-2.4.2-pentiumiii-smp ? it's only one kernel, one source tree...so where do all these different header files come from? what's the point of them? what do they provide that just plain kernel-headers-2.4.2 doesn't provide? craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Mon, Apr 23, 2001 at 06:59:55AM +0800, zhaoway wrote: this actually *helps* new users. Why? I can see your suggestion help mirrors (The trade-off is questionable.) But I can't see why it could help users. because new users are better off when they learn how to control their system. ignorance is not bliss. ignorance is a crippling affliction, especially when it comes to computers. anything that promotes ignorance by hiding the messy details of operating a computer is fundamentally wrong. I certainly don't think that make users (even make the task easier) to compile a kernel can do help to most of the users nobody is making them do anything. it's only if they need the slightly enhanced performance of a kernel optimised for their exact CPU that they need to compile a kernel. yes, it's better for every system to have a custom compiled kernel, but a plain 386 kernel will suffice for most people. the CPU optimisations for 486, k6, k7, p3, p4 and so on just aren't worth taking 5 times the storage space and 5 times the number of packages per kernel...if a user wants that negligible performance gain then they should compile the kernel themselves. the only excuse i can see for having all those kernel-image packages is to cater to the idiots in the slashdot crowd who say cool, distribution X rocks because it has kernel x.y.z and completely fail to understand that any kernel can be run with any distribution as long as the support tools (modutils, etc) are up to date. is that worth hundreds of MB in the archive, gigabytes of bandwidth to sync mirrors, and an extra CD in the release? no, not at all. no way. (That is *not* a task they should be bothered at all.) if they don't want to do it, they don't have to. if they can't be bothered, they're not even going to notice the difference between a 386 kernel and a k7 kernel. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:39:00AM +1000, Herbert Xu wrote: On Tue, Apr 24, 2001 at 08:20:42AM +1000, Craig Sanders wrote: what, exactly, is the difference between kernel-headers-2.4.2 and: kernel-headers-2.4.2-386 kernel-headers-2.4.2-586 kernel-headers-2.4.2-586tsc kernel-headers-2.4.2-686-smp kernel-headers-2.4.2-686 kernel-headers-2.4.2-k6 kernel-headers-2.4.2-k7 kernel-headers-2.4.2-pentium4 kernel-headers-2.4.2-pentiumiii kernel-headers-2.4.2-pentiumiii-smp ? These packages contain the modules directory and the autoconf.h file, neither of which you can do without if you want to compile binary modules with checksums. you're still not answering the question. what is the DIFFERENCE between kernel-headers-2.4.2 and all the other 2.4.2 kernel headers packages? why are they needed? and while you're at it, how about answering the other questions that you ignored in my last message? craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Tue, Apr 24, 2001 at 08:37:35AM +1000, Herbert Xu wrote: On Tue, Apr 24, 2001 at 08:15:03AM +1000, Craig Sanders wrote: On Mon, Apr 23, 2001 at 07:24:13PM +1000, Herbert Xu wrote: How are they going to compile a kernel if they haven't even installed Linux? that's obvious. by installing linux and then compiling a kernel. I hope you're being facetious. ask a stupid question, get a stupid answer. The most important function of initrd is to reduce the number of kernel images needed on boot floppies to one. you're missing the point again. nobody is disputing that using initrd was a good idea - it's a useful tool. Huh? Did you see what I was responding too? Just because this is in a thread about bloat, it doesn't mean that we aren't allowed to talk about other things. in normal circumstances, that would be fine and pass without comment. however, you have been using initrd as a distraction from the real issue of kernel bloat. you're willing to go off on long digressions about how wonderful initrd is, but ignore the issue of package bloat. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: Why does typing navigator run mozilla?
On Mon, Apr 23, 2001 at 05:32:45PM -0400, Matt Zimmerman wrote: Running the 'navigator' binary will communicate with a running version of Navigator, if one exists. This feature has been in Navigator years. yep, it's been there for years. it's mostly useful, but occasionally annoying when you really do want to run another instance of navigator. (the only times i want to do that is when paranoia makes me start up a new navigator binary before connecting to my bank's https site, then kill it afterwards. now that i'm using Galeon as my regular browser, that's no problem - i just start up netscape whenever i need to visit an SSL site) i just learnt to work around it, because i'd be even more annoyed if it started up a new binary every time. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Sun, Apr 22, 2001 at 01:38:42PM +1000, Herbert Xu wrote: if the user needs a more specific kernel (e.g. with SMP or compiled for a P2 or a K6 or whatever) then they can use manoj's excellent kernel-package (one of debian's best features, IMO) to build a custom kernel. This is exactly our disagreement. My position is that it is well within our capabilities to make this unnecessary. And you disagree with that which is fine with me. i disagree with you primarily because the cost of having so many kernel-image packages is too high. that cost is over 100MB per kernel version, that's several hundred MB with several kernel versions available (1 or 2 x 2.2.x kernels and 1 or 2 x 2.4.x kernels, possibly a 2.5.x kernel as well) that means extra bandwidth consumed to sync each and every mirror site...repeated every time a kernel-image is added to or upgraded in the archive. that could easily run into several gigabytes per month PER mirror...and dozens of gigabytes extra per month for master and ftp.debian.org to feed all the mirrors. there's also an economic cost too, of course. some places in the world have much cheaper bandwidth than Australia, some have much more expensive bandwidth, but here in Australia, a GB costs about $AUD200 (~= $USD100) to download. that's at $0.20/MB, an average price for Australia - some people pay more than that (as much as $0.35/MB), some pay less (as little as $0.07/MB)...so the price per GB ranges from $AUD70 to $AUD350. it also means more space consumed on the CD-ROM - several hundred MB extra wasted on kernel images in the release will mean at least one extra CD-ROM. that means a more expensive release, and more difficult and time-consuming to produce. it also means more gigabytes of bandwidth used by people mirroring the ISO images. the benefit of having all those extra kernel-image packages around is soemwhere been non-existant and negligible...but the cost is enormous. it's just plain wrong, and it should not happen. just as you stated you'd be filing bug-reports to get 2.2.17 kernel image removed from the archive, i'll be filing package should not exist bugs against all the excess kernel-image bugs. the correct thing to do is to encourage and educate our users about compiling their own kernel. if it's too hard then we should try to make it easier. why pander to ignorance when ignorance is a curable affliction? it's much better to cure it through education than to support and encourage it. what you want to do is detrimental in the long run - it serves to perpetuate the myth that compiling kernels is extremely difficult, and encourages laziness and ignorance on the part of the user. Most are. In my opinioin, there isn't anything that is particular important to most people which haven't been modularised yet. you seem to think that optimisations for specific ia32 sub-architectures are important enough to package... 2. it is, in general, *far* better to run a kernel which is specific to your exact hardware and your exact requirements than to use a generic kernel with a bunch of options you don't use and don't care about compiled in. IMHO, with the current 2.4.* setup, the difference between compiling your own and using the preexisting one is so minimal that most people will be able to use the precompiled one rather than building their own. there's good reason to worry about kernel modules now that there are known hax0r stealth modules which exist purely to hide the fact that a system has been compromised. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote: On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote: Unless you care about performace. Which is the main reason to use different packages for each CPU type. I compile my own kernels, and have for a long time. But it's a pain to go through all the poorly-documented options and takes quite a while to select those options and actually build a kernel. And then there's the times I have to go back and recompile because I left out my mouse drivers, or ide-scsi, or vfat. It's entirely rational to want to pick up the 10% improvement from hitting the right button in dselect and not worry about the 20% from recompiling the kernel. in that case, a far better solution is a package containing a bunch of pre-generated kernel .config files, plus a menu script to copy your choice to the right subdirectory (e.g. /usr/local/src/linux or wherever)...then run make menuconfig or make xconfig to let you tweak the .config before compiling. that would be one package, taking maybe a few hundred kilobytes total. call it kernel-helper and make it depend on kernel-package. problem solved. btw, if you've been compiling your own kernels for a long time then you probably do somthing similar to what i do - copy in the .config from the previous version and run make oldconfig before make menuconfig and make-kpkg. i've been doing this for years and it's a great way to manage kernels. i even make copies of the .config files which are specific to particular machines. for example, if i want to compile 2.4.2 for a machine called foobar and i have a previously saved .config for 2.2.17 for that machine then i copy it into /usr/local/src/linux, run make oldconfig, make menuconfig, and then build the kernel with make-kpkg...and finally copy it to the right machine with scp. similar, if machine barfoo is very similar to machine foobar then i might use foobar's .config as the base for creating barfoo's .config. perhaps doing this is not completely obvious to new users. in that case, we should be teaching them that this kind of thing is possible, educating our users to make effective use of the existing tools. we have good tools for managing kernel .config files and kernel versions. kernel-package is an outstanding piece of work...manoj has done some lots of other cool work too, but this by itself is more than enough to earn a great deal of respect. if users don't know that this exists or don't realise how useful it is, then that can be solved with education. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Sun, Apr 22, 2001 at 10:16:36PM +1000, Herbert Xu wrote: We clearly disagree, so let's leave it at that. no. just as you stated you'd be filing bug-reports to get 2.2.17 kernel image removed from the archive, i'll be filing package should not exist bugs against all the excess kernel-image bugs. Go ahead, I'll close them as soon as they're filed. and i'll open them again or file new ones. what you are doing is broken. And what does this have to do with our discussion? it's about as relevant as the rest of your digression on initrd and modules. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Sun, Apr 22, 2001 at 10:23:04PM +1000, Herbert Xu wrote: in that case, a far better solution is a package containing a bunch of pre-generated kernel .config files, plus a menu script to copy [...] that would be one package, taking maybe a few hundred kilobytes total. call it kernel-helper and make it depend on kernel-package. But why not take this one step further, let's just distribute what's in build-essential and let the users compile the rest. Let's rewind the clock back to times when men were men, and they compiled everything on their own box :) how is that taking it one step further? what i suggested was providing tools and documentation to assist users in building their own custom kernels, rather than providing a bloated number of still-generic kernels. this actually *helps* new users. what you want to do doesn't help at all, in fact it causes harm. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Mon, Apr 23, 2001 at 08:00:50AM +1000, Hamish Moffatt wrote: I do that too; what's the oldconfig step needed for though? I just jump straight to menuconfig and it always seems OK. i find it easier to deal with new config questions. it uses your old answers as input for any questions, and only prompts you to input answers to new questions. I agree that it is not too hard to compile your own kernel. I never use Debian's standard kernel-image packages (except on my 68K Mac, where it takes too long to recompile). is there such a thing as cross-compilation for the kernel? craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Sun, Apr 22, 2001 at 03:36:02PM -0700, Aaron Lehmann wrote: On Mon, Apr 23, 2001 at 08:33:43AM +1000, Craig Sanders wrote: is there such a thing as cross-compilation for the kernel? Yes - porting to new architectures would be nearly impossible otherwise. yep, true...but is it deep kernel hacker wizardry or is it accessible to mere mortals :) kernel-package even supports cross-compilation IIRC. cool, i didn't know thatdon't actually have any need for it. i was just curious. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: Dual CPU compilation.
On Sun, Apr 22, 2001 at 10:15:28PM -0400, Simon Law wrote: I'm the lucky new owner of a dual Pentium Pro system. It seems, however, that compiling stuff just doesn't use my extra CPU. I know I can compile with 'make -j 2' to use the second processor; but I don't know how to convince kernel-package and dpkg-deb (apt-get source) to do that for me. Any tips? this question belongs on debian-user, not debian-devel. type: export MAKE='make -j3' before running make-kpkg. note that the kernel is known to have problems compiling reliably when you use make -j. this won't be fixed until Keith Owens and others have got their fixed kernel build system into the kernel tree - that won't happen until 2.5.x i believe. i've successfully compiled several kernels using -j3, but it's not something i'd want to rely on at the moment. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: tar -I incompatibility
On Mon, Jan 08, 2001 at 12:28:15AM +1100, Hamish Moffatt wrote: Frankly, I don't see why gnu tar needs to be compatible with OS-specific versions because most of those are feature-poor anyway. the one reason for gnu tar to do that is so that it can be a drop-in replacement for those crappy versions. on every non-linux machine i have to use, the first thing i do is download and compile all the GNU tools including tar. i then change the PATH setting to include /usr/local/bin/gnu at the start. if the GNU commands were not backwards-compatible then it would be dangerous to do that. I agree with the suggestion that we modify tar for Debian to provide -I at least for compatibility for one more release. i think that whatever we do is going to be broken somehow. leaving it as -I means that GNU tar would no longer be a drop-in replacement for a proprietary tar. changing it to -j means that an upgraded GNU tar is no longer a drop-in replacement for older versions of GNU tar. both options suck. craig -- craig sanders
Bug#81396: root shell fscked after upgrade to woody
On Sun, Jan 07, 2001 at 04:38:10AM +0200, Eray Ozkural (exa) wrote: We use telnet here because this is a diverse university network; we can't force people to run ssh and any moron could go root on this machine if he really wanted to. why not? the most you'd have to do is put up a single web page with links to local copies of ssh clients for various platforms...and optionally replace telnetd with a script (or tcp-wrapper's twist capability) which printed a message displaying the URL and advising the user to install an ssh client. telnet problem solved with a minimum of user support calls. there's really no excuse for running (non-ssl) telnetd any more. good free ssh clients are available for just about every operating system. craig -- craig sanders
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 11:11:50PM -0700, John Galt wrote: On Thu, 4 Jan 2001, Craig Sanders wrote: Mail-Followup-To is the correct header to use. Mail-Followup-To isn't even a registered header! The closest thing to a registry that RFC822 implies is in the hands of SRI International is the thing about internet standards such as the RFCs is that they tell you what you *must* do, and what you *must not* do. as long as you follow those rules faithfully you are free to implement as many other good ideas as you like. http://www.dsv.su.se/jpalme/ietf/mail-headers/ (jpalme is as much of a member as one can be of the IETF RFC822 WG) which says that a Followup-To: header is from RFC 1036, but RFC 1036 is for USENET messages, not email. The only thing I can think of is that somebody liked the usenet idea of the followup-to: and just appended a mail on it. Just because somebody breaks the standards does NOT mean that everybody should. well done! it only took you a few years to catch on. that header has been in common usage for several years. btw, it's interesting that you mention Jacob Palme. take a look at the following document written by him in November 1997: http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt Network Working Group Jacob Palme Internet Draft Stockholm University/KTH draft-ietf-drums-mail-followup-to-00.txt Expires: May 1998 November 1997 The difference between pine and mutt is that you KNOW the overflows in pine incorrect, again. the difference between mutt and pine is that mutt is a decent piece of free software that works and follows the relevant standards, while pine is a broken piece of non-free shit which doesn't. Horsefeathers! The Mail-followup-to: header is NOT a part of the relevant standards! that wasn't what i said, and i in no way meant to imply that failure to implement an optional but well-documented and well-known header is what makes pine broken. pine is broken in numerous other ways. craig -- craig sanders
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 11:15:23PM +0100, Sven Burgener wrote: On Wed, Jan 03, 2001 at 05:23:55PM +1100, Craig Sanders wrote: the new 'testing' distribution (sid) should be even better - nearly all the benefits of 'unstable' but tested to at least install properly without error. Wrong: unstable-sid; testing-woody. yes, my mistake. i don't know why i called it sid when i know it isn't. a brainfart. my comments about the usefulness of the 'testing' distribution still apply. Personally, I would recommend the use of 'testing' in a production environment, but not unstable. One doesn't always have the time to fix problems related to the distribution itself whilst working in a production environment. i would recommend the use of either testing or unstable or stable depending upon the particular requirements of the situation. stable is good when you don't need or want any change at all. testing is good when you want/need to be mostly up-to-date with the latest versions but don't have the time to deal with packaging errors. unstable is good when you want/need to be up-to-date and have both the time and the skill to deal with any problems that may arise. most people with a decent net connection will probably settle for using 'testing'however that won't be much use if nobody uses 'unstable' as unstable packages won't get installed and tested, so bug reports won't be filed, so unstable packages will move into testing without actually having been tested by anyone. craig -- craig sanders
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 09:23:23PM -0900, Ethan Benson wrote: btw is it Mail-Copies-To: never or Mail-Copies-To: nobody ? i have seen both which is correct? (assuming any MUA actually pays any attention to this header anyway) 'nobody' is correct. 'never' is deprecated but still observed by many MUAs. from the draft of Mail-Copies-To posted to the usenet-format list on 6 Nov 2000 (Message-Id: [EMAIL PROTECTED]): 6. Optional Headers 6.1. Mail-Copies-To The Mail-Copies-To header indicates whether or not the poster wishes to have followups to an article emailed in addition to being posted to Netnews and, if so, establishes the address to which they should be sent. The content syntax makes use of syntax defined in [MESSFOR], but subject to the revised definition of local-part given in section 5.2. Mail-Copies-To-content= copy-addr / nobody / poster copy-addr = mailbox The keyword nobody indicates that the author does not wish copies of any followup postings to be emailed. The keyword poster indicates that the author wishes a copy of any followup postings to be emailed to him. Otherwise, this header contains a copy-addr to which the author wishes a copy of any followup postings to be sent. NOTE: Some existing practice uses the keyword never in place of nobody and always in place of poster. These usages are deprecated, but followup agents MAY observe them. craig -- craig sanders
Re: bugs + rant + constructive criticism (long)
On Thu, Jan 04, 2001 at 10:43:05AM -0800, Philip Brown wrote: [ Craig Sanders writes ] On Wed, Jan 03, 2001 at 11:26:25AM -0800, Philip Brown wrote: And in the case of the debian mailing lists, you should reply to the list. some replies should go to the list, and some replies should be private. it's up to the person writing the reply to make that decision, not the list software. But the primary point of a mailing list is for discussion ON THE LIST. Do you want to disagree with that? yes, of course i will disagree with that because it's wrong. there are as many primary purposes of mailing lists as there are mailing lists. So headers should be optimized for group discussion. Replying to individuals is a secondary function. that's for the person writing the reply to decide, not you and not the list operator. setting reply-to back to the list just makes it difficult (or in some cases impossible) to reply privately. ... however reply-to munging by list software does have the serious disadvantage of replacing any Reply-To header created by the original author of a message. So what, if the mailing software rewrites From: to have any reply-to information from the original sender? Then the information is still available. so your proposed solution to the evils of header munging is to do more header munging in an attempt to correct the problem? what a great idea! there are better solutions, including the Mail-Followup-To header which has been documented and in use for years. all decent MUAs should have implemented it by now. if they haven't then they are inadequate. the Reply-To header exists for the *person* who originally sent the message to be able to direct replies to their preferred destination. it is not there so that mailing lists can screw with it. So your argument is A mailing list is not a person, so it can't use reply-to:. Bad argument. no, my argument is that if a list sets the reply-to header then it makes it difficult (or impossible in some cases) to reply privately to the author of a message, so it should not do it. not munging the Reply-To header also follows the principle of doing least harm. if a reply is accidentally sent privately, no harm is done - just forward the message to the list if it matters. OTOH if a private reply is accidentally sent to the list (which happens all too often when Reply-To points back to the list) then harm is done with no possibility of undoing it because confidential or embarrasing material is now posted (and probably archived) publicly. setting Reply-To back to the list is brain-damaged and moronic behaviour on the part of the list operator. [http://faqs.org/rfcs/rfc822.html] rfc822, section 4.4.3, EXPLICITLY MENTIONS text message teleconferencing groups (eg mailing lists) as potential users of the reply-to header, expressly for the purpose of having reply direct email to the list yes, and the people who wrote that (and many others) have since realised and stated that it is broken and causes many more problems than it solves. that's why there are other documents recommending the Followup-To and Mail-Followup-To and other headers. this has been discussed many times over many years. you're not adding anything new to the discussion. And finally, example A.3.3 EXPLICITLY shows that reply-to is NOT exclusively for who wrote the message. It is for Where do you want replies to normally go to what's your point? it is for the person who wrote the message to direct where replies are to go. craig -- craig sanders
Re: bugs + rant + constructive criticism (long)
On Tue, Jan 02, 2001 at 07:45:53PM -0800, Jim Lynch wrote: But... if you are using woody for -production-, I'm sorry again, but that's an idiot move... and you know that if you have spent -any- time at all on OPN, much less enough to get familiar enough to help others on channel. And if you're talking about -sid-... rotflmao :) Now being serious: I hope you NEVER advise people on #debian to use anything not released for production. If I see it, you get devoiced QUICKLY. WTF for? you want to censor someone because they express opinions which you don't like? you might disagree, but unstable is just as safe to use on production systems as stable - especially for people who have a clue and have sufficient experience with debian. the main difference between 'stable' and 'unstable' is that stable has old versions with old bugs and old security holes while unstable has new versions with new bugs and new security holes. take your pick. i have no hesitation in recommending that people run unstable if they need the new features/bugfixes and if they have enough of a clue to cope with occasional packaging problems or are willing to learn how (it's not very hard - just become familiar with dpkg and apt). (if people don't have a clue, then i don't recommend that they run either stable or unstable. i recommend that they either acquire one in a hurry or go find a more appropriate career or hobby) as long as you test upgrades on an unimportant machine first there's little chance of a problem. i've been running *all* of my production servers on debian unstable for years (since 1995) with no major problems. they don't all get upgraded every day, but most get upgraded at least once every two weeks. i use unstable for building gateway boxes and workstations too...in fact, every debian box i build is debian unstable - so far, i've personally built over 200 of them and guided/supervised the building of many more. i have every intention of building more 'unstable' boxes as i need them. i'm sure that most debian developers have similar experiences with unstable. it may be too much trouble for the completely clueless but it's fine for anyone who's not afraid of getting their hands dirty. the new 'testing' distribution (sid) should be even better - nearly all the benefits of 'unstable' but tested to at least install properly without error. craig -- craig sanders
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 06:16:17AM -0800, Jim Lynch wrote: If you want to advocate the use of unstable software, please be my guest... but not on #debian. it changes daily, and can potentially break every day, potentially disasterously. So -no-. It's NOT appropriate to tell people to run servers on unstable software. if i ever happen to be on #debian and someone has a problem where the best solution is to upgrade to unstable (either a full dist-upgrade or just selected packages) then i certainly will recommend exactly that. it is *always* appropriate to provide a good solution to a problem - whether it accords with your opinion or not. On the other hand... if you want to -pay- me to take the support load for a limited period of time, I'll open the door, for a limited period of time. I'm a volunteer there, you already know what a volunteer is if you have anything at all to do with debian. there's no need to be so pompous and pretentious. you're just another volunteer, not the Thought Police. craig -- craig sanders
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 11:26:25AM -0800, Philip Brown wrote: [ D-Man writes ] Try mutt and its L command. The L command means list-reply, aka only send a message to the list, not to all recepients. It also sets a header flag so that other well-behaved MUA's don't send you an extra copy of their replies since you will get it on the list anyway. guess what? not everyone uses mutt. not everyone should. mutt's not the only decent MUA around. there are other which work properly. Reply-to is meant to send a message back to the person who wrote the first one, not to someone they wrote the message to. reply-to is meant to direct where you should send replies to. And in the case of the debian mailing lists, you should reply to the list. bullshit. some replies should go to the list, and some replies should be private. it's up to the person writing the reply to make that decision, not the list software. setting reply-to back to the list just makes it difficult (or in some cases impossible) to reply privately. it provides no benefit that can not be better achieved by either a) using a decent mailer, or b) having a bit of a clue and editing the To, and Cc: headers appropriately. however reply-to munging by list software does have the serious disadvantage of replacing any Reply-To header created by the original author of a message. the Reply-To header exists for the *person* who originally sent the message to be able to direct replies to their preferred destination. it is not there so that mailing lists can screw with it. craig -- craig sanders
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 09:53:04PM -0700, John Galt wrote: In fact, the only thing the RFC says to do is to honor Reply-To: headers, which I might note you didn't include in your message. Why should I, when it would be no different from my From: header? It would be in your case: Reply-to: debian-devel@lists.debian.org no, that would make it difficult for people to reply privately to him. Mail-Followup-To is the correct header to use. The difference between pine and mutt is that you KNOW the overflows in pine incorrect, again. the difference between mutt and pine is that mutt is a decent piece of free software that works and follows the relevant standards, while pine is a broken piece of non-free shit which doesn't. mutt allegedly shares code with pine... since the source-code of both programs is readily available it should be easy enough to check this allegation. craig -- craig sanders
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 08:41:43PM +, Mark Seaborn wrote: Dwayne C . Litzenberger [EMAIL PROTECTED] writes: So my question is: What do you wish for in a package manager? I want a system where I can install multiple versions of a library (or any package really) and say which version I want each program on the system to use, possibly on a per-user basis. The present system is a disaster waiting to happen: If I install a package from unstable, it often wants to replace my version of libc from stable with one from unstable. If this new libc is broken it could bring down the whole system, when what I really want to happen is for the new package to use the unstable libc and everything else carry on using the stable libc. this is the risk you take when you use unstable. if that risk is too great for you, then stick to the stable release. it's a small - tiny, even - risk, but it's there. deal with it. the amount of effort and bloat required to implement this idea for the handful of people who would find any use at all for it just isn't worth it. it's a gross violation of the KISS principle and would greatly increase the complexity of systems administration. when i upgrade a package, i want it to replace the previous version - i don't want to keep the last n versions around just on the off-chance i might have some use for them (e.g. the last 10 versions of libc6 or the last 10 versions of xbooks would waste an enormous amount of disk space). if i really need more than one version of a library installed, i can compile it in /usr/local and set LD_PRELOAD appropriately. craig -- craig sanders
Re: CGI bug scripts
On Sun, Sep 10, 2000 at 04:56:29PM -0700, Joey Hess wrote: Julian Gilbey wrote: Is it my imagination, or is bugreport.cgi *really* slow? I think that we should really investigate the possibility of using mod_perl. It's using CGI.pm, which is *big* and takes time to load. I've written scripts which I use under mod_perl and the time difference is astonishing. You can also just not use CGI.pm, which is horrendously bloated for most tasks. or modify it to run under speedycgi, which gives most of the benefits of mod_perl (persistent perl scripts, persistent database connections, compile-once rather than on every request, etc) without the hassles of mod_perl. unlike mod_perl, most CGI scripts work under speedyCGI with little or no modification...the main thing you have to remember is that the script is now persistent, so you have to be careful about use of global variables and even more careful about correctly initialising your variables - they will retain their values from one execution to the next. for many CGI scripts, the only change you have to make is change the #! /usr/bin/perl line to #! /usr/bin/speedy. mod_perl still has it's uses - speedy and mod_perl perform similar but far from identical tasks. for some jobs, mod_perl is better while for other jobs, speedy is better. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
