Re: Looking for a co-maintainer for adduser
Only on a well-written OS... ;) Mark Brown wrote: On Mon, Oct 06, 2003 at 01:01:52AM +0200, Marc Haber wrote: Well-written C++ using well tested class libraries tend to do a pretty good job, security-wise. I often find that well written code does a good job.
Re: Package verification and /usr/bin/install tool replacements
Kim Lester wrote:
Although debian packages may contain md5sums it seems package
verification is
not available (unless I have missed something).
Although your proposition seems more complete, have you try
debsums and checksecurity? debsums with the following
feature in /etc/apt/apt.conf
DPkg::Post-Invoke {
debsums --generate=nocheck -sp /var/cache/apt/archives;
};
Can be very handy in creating md5sums (BTW, I think it's a bug
against policy to include md5sums in control files).
Ciao!
Fabien
Accepted passivetex 1.22-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 14 Feb 2003 16:18:45 -0500 Source: passivetex Binary: passivetex Architecture: source all Version: 1.22-1 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: passivetex - Macros to process XSL formatting objects Closes: 161807 181019 Changes: passivetex (1.22-1) unstable; urgency=low . * New upstream release (closes: #181019) * Fo:leader now work again! (closes: #161807) Files: c936230a35acc7b793964fb5de671c57 578 tex optional passivetex_1.22-1.dsc de499bb71918008d571dd57d298662ef 1126653 tex optional passivetex_1.22.orig.tar.gz 7bdbb1209ced770e67cbed044677a681 2959 tex optional passivetex_1.22-1.diff.gz 11d5ce444b898d44a6cf1b52a09882a5 358660 tex optional passivetex_1.22-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+TV9Ojx/fybzglDYRAqOnAJ9UDJiIzyxm1/e09R/hUOorPOzU3ACfW5mL BWoeRgZKIhIyrX3ozPtf0/w= =NFWm -END PGP SIGNATURE- Accepted: passivetex_1.22-1.diff.gz to pool/main/p/passivetex/passivetex_1.22-1.diff.gz passivetex_1.22-1.dsc to pool/main/p/passivetex/passivetex_1.22-1.dsc passivetex_1.22-1_all.deb to pool/main/p/passivetex/passivetex_1.22-1_all.deb passivetex_1.22.orig.tar.gz to pool/main/p/passivetex/passivetex_1.22.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted passivetex 1.23-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 14 Feb 2003 23:05:30 -0500 Source: passivetex Binary: passivetex Architecture: source all Version: 1.23-1 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: passivetex - Macros to process XSL formatting objects Closes: 181055 Changes: passivetex (1.23-1) unstable; urgency=low . * Oops! Miss a version. 1.22 is really 1.23. (closes: #181055) Files: 269e61486c7384f888a1dba1f0411af6 578 tex optional passivetex_1.23-1.dsc de499bb71918008d571dd57d298662ef 1126653 tex optional passivetex_1.23.orig.tar.gz e52689c834fe14c4c83fd7b4d21ff855 2999 tex optional passivetex_1.23-1.diff.gz dec0e103b012074cd2f7d9d7298254be 358710 tex optional passivetex_1.23-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+Tb7cjx/fybzglDYRAveUAKCVUFIIdMJhBgNXcdAJsqlqkBRB9gCeMXp3 lUTttag4I1SG4ddyCVmLib0= =dC/3 -END PGP SIGNATURE- Accepted: passivetex_1.23-1.diff.gz to pool/main/p/passivetex/passivetex_1.23-1.diff.gz passivetex_1.23-1.dsc to pool/main/p/passivetex/passivetex_1.23-1.dsc passivetex_1.23-1_all.deb to pool/main/p/passivetex/passivetex_1.23-1_all.deb passivetex_1.23.orig.tar.gz to pool/main/p/passivetex/passivetex_1.23.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted passivetex 1.21-5 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 18 Dec 2002 15:03:38 -0500 Source: passivetex Binary: passivetex Architecture: source all Version: 1.21-5 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: passivetex - Macros to process XSL formatting objects Closes: 173517 Changes: passivetex (1.21-5) unstable; urgency=low . * Uses update-fmtutil in the prerm instead (must closes: #173517). Files: 8400b8310795b3f805289491e13167d5 578 tex optional passivetex_1.21-5.dsc 18306e78fcdb87fe4778104c8e5fa63e 2912 tex optional passivetex_1.21-5.diff.gz bd8d08c24b63e24ab6beefe097b07fa2 359482 tex optional passivetex_1.21-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+ANZIjx/fybzglDYRAl5oAKCww6w/rF8q7QlKezTfTKnqX5PRsQCfTPEL ixz6TYpK80bcKPAwgk5l2Ps= =dPsW -END PGP SIGNATURE- Accepted: passivetex_1.21-5.diff.gz to pool/main/p/passivetex/passivetex_1.21-5.diff.gz passivetex_1.21-5.dsc to pool/main/p/passivetex/passivetex_1.21-5.dsc passivetex_1.21-5_all.deb to pool/main/p/passivetex/passivetex_1.21-5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted passivetex 1.21-4 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Dec 2002 16:25:55 -0500 Source: passivetex Binary: passivetex Architecture: source all Version: 1.21-4 Distribution: unstable Urgency: medium Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: passivetex - Macros to process XSL formatting objects Closes: 172860 Changes: passivetex (1.21-4) unstable; urgency=medium . * Correct handle of conffile using templates (closes: #172860) Files: 73e35c29eb59baef3fa5eba957637fed 578 tex optional passivetex_1.21-4.dsc 493d5335f82cec8c2e4ef62db27de49d 2831 tex optional passivetex_1.21-4.diff.gz ac2e32a232f54cbf5043c5423fd77eac 359322 tex optional passivetex_1.21-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9/kf+jx/fybzglDYRAp9+AJ48Xc9CznJQQqNHxS01vSxT3YuFKQCfSv0R ep8qgNIwLyG5Qbw9jped4us= =dElr -END PGP SIGNATURE- Accepted: passivetex_1.21-4.diff.gz to pool/main/p/passivetex/passivetex_1.21-4.diff.gz passivetex_1.21-4.dsc to pool/main/p/passivetex/passivetex_1.21-4.dsc passivetex_1.21-4_all.deb to pool/main/p/passivetex/passivetex_1.21-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmltex 1.9-5 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Dec 2002 17:23:18 -0500 Source: xmltex Binary: xmltex Architecture: source all Version: 1.9-5 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: xmltex - TeX package for processing XML files Changes: xmltex (1.9-5) unstable; urgency=low . * Oops! Small error at recompilation. Files: 7853e2ac4858a2e372f7abf48eb1ccc7 582 tex optional xmltex_1.9-5.dsc 037fb7fbb22f8af18f4e9d58f3f5f723 9745 tex optional xmltex_1.9-5.diff.gz 124104ee5dd71f7c93dfb1aed3adb80c 195266 tex optional xmltex_1.9-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9/lKSjx/fybzglDYRAqGeAJ0UgPU9wZxLSkdJSdhlRK9DOjqixQCcCXMF Lgmy++pOutao7uDydpueyWo= =JC6p -END PGP SIGNATURE- Accepted: xmltex_1.9-5.diff.gz to pool/main/x/xmltex/xmltex_1.9-5.diff.gz xmltex_1.9-5.dsc to pool/main/x/xmltex/xmltex_1.9-5.dsc xmltex_1.9-5_all.deb to pool/main/x/xmltex/xmltex_1.9-5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted passivetex 1.21-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 1 Nov 2002 14:18:34 -0500 Source: passivetex Binary: passivetex Architecture: source all Version: 1.21-3 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: passivetex - Macros to process XSL formatting objects Closes: 166922 Changes: passivetex (1.21-3) unstable; urgency=low . * Undone the last change. It's really the right way to do it * Add main_memory_bot, just like jadetex. Should do it (closes: 166922) Files: 7790689842d408347df8c08147a5a5d0 580 tex optional passivetex_1.21-3.dsc 9308e89b248decd36d1010c2e2494872 2427 tex optional passivetex_1.21-3.diff.gz 22e92dec080d3c2c9d0045369b122d3b 358966 tex optional passivetex_1.21-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9wtv4jx/fybzglDYRAqmlAJ9KMB7A/498fb7fG9d0MbFRf2sVfACcCfYW mOZieJwmvlN4ZR4Mu9+Gehc= =vpEe -END PGP SIGNATURE- Accepted: passivetex_1.21-3.diff.gz to pool/main/p/passivetex/passivetex_1.21-3.diff.gz passivetex_1.21-3.dsc to pool/main/p/passivetex/passivetex_1.21-3.dsc passivetex_1.21-3_all.deb to pool/main/p/passivetex/passivetex_1.21-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmltex 1.9-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 1 Nov 2002 14:04:30 -0500 Source: xmltex Binary: xmltex Architecture: source all Version: 1.9-3 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: xmltex - TeX package for processing XML files Changes: xmltex (1.9-3) unstable; urgency=low . * Undo last change. It's really a passivetex bug. * Remove conffile handling. Dpkg already handle such things. Files: 0fa877fc20b4b04e9ce4643120a44c8a 584 tex optional xmltex_1.9-3.dsc 6254b76292f8e6e28d1b163ee1c5aca3 9412 tex optional xmltex_1.9-3.diff.gz 3c8073828483ce029988ea0c63255789 142040 tex optional xmltex_1.9-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9wtQijx/fybzglDYRAsiDAKCSwNDmZcVgIhRkTVPCbLhvaYoVvgCfeTbh NdKm0fbMzrVEfBH7aQ44SjQ= =GiDX -END PGP SIGNATURE- Accepted: xmltex_1.9-3.diff.gz to pool/main/x/xmltex/xmltex_1.9-3.diff.gz xmltex_1.9-3.dsc to pool/main/x/xmltex/xmltex_1.9-3.dsc xmltex_1.9-3_all.deb to pool/main/x/xmltex/xmltex_1.9-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmltex 1.9-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 29 Oct 2002 08:49:10 -0500 Source: xmltex Binary: xmltex Architecture: source all Version: 1.9-2 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: xmltex - TeX package for processing XML files Closes: 166922 Changes: xmltex (1.9-2) unstable; urgency=low . * Import passivetex setting here to be considered in the fmt creation. Thanks to Ralph Giles to point this out. (closes: 166922) Files: ede4271a09e5b74757f72abc68cb03a8 584 tex optional xmltex_1.9-2.dsc 93f18ce892736487c662c0586ef1112f 9773 tex optional xmltex_1.9-2.diff.gz f4f79a5ab2e524145ce49f9668283481 142508 tex optional xmltex_1.9-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9vpubjx/fybzglDYRAgXKAKCwY706w1AHSq3HSFIbRCx/2hkHxACgnyiG YfBTWzByIzOmrO7SS26JSl8= =7Bsv -END PGP SIGNATURE- Accepted: xmltex_1.9-2.diff.gz to pool/main/x/xmltex/xmltex_1.9-2.diff.gz xmltex_1.9-2.dsc to pool/main/x/xmltex/xmltex_1.9-2.dsc xmltex_1.9-2_all.deb to pool/main/x/xmltex/xmltex_1.9-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tkworld 1.4.0-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 22 Sep 2002 20:41:49 -0400 Source: tkworld Binary: tkworld Architecture: source all Version: 1.4.0-2 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: tkworld- a GUI to shell commands Closes: 71174 Changes: tkworld (1.4.0-2) unstable; urgency=low . * Replaces netscape with mozilla. A better replacement will be to provide full customization. Patch is welcome. (closes: #71174) Files: cf812159b40170d512fbc842ff6610bc 557 x11 optional tkworld_1.4.0-2.dsc a80cae859855c528a11d8f7f7fd51d07 3158 x11 optional tkworld_1.4.0-2.diff.gz b0098518070a78a3e3ea941bbbab8362 102422 x11 optional tkworld_1.4.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9jpkwjx/fybzglDYRAmA7AKCoPsxw2d/1b3Q/XIH0BRp+uWaSvACfaK1U rC7bL7iHpl1kNM2a38zNFLE= =oc7R -END PGP SIGNATURE- Accepted: tkworld_1.4.0-2.diff.gz to pool/main/t/tkworld/tkworld_1.4.0-2.diff.gz tkworld_1.4.0-2.dsc to pool/main/t/tkworld/tkworld_1.4.0-2.dsc tkworld_1.4.0-2_all.deb to pool/main/t/tkworld/tkworld_1.4.0-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted passivetex 1.21-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 21 Sep 2002 13:53:16 -0400 Source: passivetex Binary: passivetex Architecture: source all Version: 1.21-1 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: passivetex - Macros to process XSL formatting objects Closes: 160446 Changes: passivetex (1.21-1) unstable; urgency=low . * New upstream release * latextei.xml is replaced by teimath.xml (closes: #160446) Files: f09aeff5ec2191ea625f33ebe659932f 580 tex optional passivetex_1.21-1.dsc ee30860361416992d3f4c855ddee5445 031 tex optional passivetex_1.21.orig.tar.gz 84e164c0a8b1de1e0ade0c2f2ae5e063 2198 tex optional passivetex_1.21-1.diff.gz b3f1ef13205b2f28be065b12f14a14c2 358734 tex optional passivetex_1.21-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9jLmcjx/fybzglDYRAs37AJ0ZgD7Z3Ep6bTmpSWulWJ+2JB7foQCeK6ah 3fclzvJJRG7qzNK6OhnlP0M= =6lK/ -END PGP SIGNATURE- Accepted: passivetex_1.21-1.diff.gz to pool/main/p/passivetex/passivetex_1.21-1.diff.gz passivetex_1.21-1.dsc to pool/main/p/passivetex/passivetex_1.21-1.dsc passivetex_1.21-1_all.deb to pool/main/p/passivetex/passivetex_1.21-1_all.deb passivetex_1.21.orig.tar.gz to pool/main/p/passivetex/passivetex_1.21.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted passivetex 1.18-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Aug 2002 11:48:39 -0400 Source: passivetex Binary: passivetex Architecture: source all Version: 1.18-1 Distribution: unstable Urgency: low Maintainer: Fabien Ninoles [EMAIL PROTECTED] Changed-By: Fabien Ninoles [EMAIL PROTECTED] Description: passivetex - Macros to process XSL formatting objects Changes: passivetex (1.18-1) unstable; urgency=low . * Official package and new maintainer. Files: 109414b74f2bd69e574b55e659e310c4 580 tex optional passivetex_1.18-1.dsc e95863459b41bfa516fe72e91ca5339a 1091593 tex optional passivetex_1.18.orig.tar.gz 01b1ba459fe1270525164353ea45b34f 2134 tex optional passivetex_1.18-1.diff.gz 1452ca66e621be8d9bcf452c5a8b39e5 355108 tex optional passivetex_1.18-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZQ9yjx/fybzglDYRApr2AKC3y79gmWk1v90F8ZHtPrJsrzpsfQCfWN3a qozYxEblKmGsYfSes0pFERc= =NVpe -END PGP SIGNATURE- Accepted: passivetex_1.18-1.diff.gz to pool/main/p/passivetex/passivetex_1.18-1.diff.gz passivetex_1.18-1.dsc to pool/main/p/passivetex/passivetex_1.18-1.dsc passivetex_1.18-1_all.deb to pool/main/p/passivetex/passivetex_1.18-1_all.deb passivetex_1.18.orig.tar.gz to pool/main/p/passivetex/passivetex_1.18.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
A Quebecer in France.
Sorry, this message is for people currently living in France where I'm going this summer. I'm a little too much lazy to translate it currently and I expect the people interested will be able to read it in French. Thanks! === Bon, c'est juste un email envoyé sur plusieurs ML pour vous avertir de ma visite en France du 23 juin au 9 juillet. Je serai sur Paris du 23 au 25 juin, puis ensuite LaRochelle du 25 au 28 juin, suivi d'Audenges (Bassin d'Arcachon) le 28 et 29 juin pour finalement terminé mon voyage à Bordeaux à partir du 30 (avec la conférence sur Debian et le Logiciel Libre). J'ai bien hâte de rencontrer tous ces visages électroniques, d'échanger des poignées de mains et d'intéressantes discussions, et je serais aussi disponible pour signer vos clefs PGP pour les intéressés. Merci et à la prochaine, Fabien. PS: SVP, attention au reply... n'oubliez pas de retirer les ML dont vous ne faites pas parti ou en m'écrivant directement à mon adresse personnel (voir signature ci-bas). -- ---* *- Fabien Niñoles/ / [EMAIL PROTECTED] Chevalier Servant de Sa Dame / / C15D FE9E BB35 F596 127F Veneur Gris par la Clef / /BF7D 8F1F DFC9 BCE0 9436 Développeur pour Debian/ / http://www.tzone.org/~fabien --* *--
Re: [dickey@clark.net: Re: http://cgi.debian.org/cgi-bin/bugreport.cgi?bug=59191]
On Mon, Mar 20, 2000 at 07:56:07PM +0100, Raphael Hertzog wrote: Le Mon, Mar 20, 2000 at 03:38:34PM +0100, Santiago Vila écrivait: Perhaps we should open the Bug System to upstream maintainers by adding a flag to every package. If this flag is on, reports are automatically forwarded to a given upstream email address. I'm sure many upstream authors would ask this flag to be enabled for their packages, even if this means a small percentage of received bugs happen to be packaging bugs which would not have to be forwarded in normal circumstances. I can't believe it, usually I don't agree with you but here I do ! That's a pretty good idea. I'm sure that for most of the packages, there aren't that much Debian specific bugs and since the author can choose I don't see a reason not to implement it. Even better anybody should be able to register himself in the BTS so that he'll get all the bugreports for a specific package (or source package, but that's something more difficult to implement I guess) ... this would allow several maintainer to maintain the same package without using an alias or a list. Following a specific bug request and/or a specific package is always a feature I would like to see in the BTS. Currently, the only way to follow a bug already mentions on the BTS is to make a new bug report and merge it to the old. Having the possibilities to add someone to a specific bug reply will make it possible to form a bug test team for all people who has the same bug, and will greatly help to follow specific policy amendment (and futurely QA tasks ;) without necessarely being subscribe to the specific mailing lists. Adding to this the possibility to have architecture specific bugs, and distribution specific bugs, and we'll have the best BTS around the world. Ok, who does it ? ;-) We should at least report it has a wish list against debbugs. Hmm... it's already done by Lars (bug# 34071) and has more than a year already (03-03-1999). Seems the idea wasn't that original ;) Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com /pub -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: aptitude
On Sat, Mar 18, 2000 at 08:35:52PM +0100, Robert Ramiega wrote: On Wed, Mar 15, 2000 at 07:23:50AM -0500, Fabien Ninoles wrote: I tried to find it on download.stormix.com but failed It's in ftp://download.stormix.com:/storm/dists/rain/main/source/ I must have missed it... Anyway it needs dpkg.h and i cant find it on my system... Searcher on Debian Web site can't find it either =o(( dpkg.h is in the dpkg source, I think. Ian doesn't want to export the functionnalities of dpkg into a librarie since he couldn't change the interface then. -- Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Don't underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: aptitude
On Wed, Mar 15, 2000 at 10:55:38AM +0100, Robert Ramiega wrote: On Sun, Mar 12, 2000 at 08:00:27PM -0500, Fabien Ninoles wrote: You just miss another one: sl-stormpkg from Stormix. Sure, it's not on potato but add deb ftp://download.stormix.com/storm potato main in sources.list and install sl-stormpkg. It's GPLed, GNOME-based, used whatever commands you want for updating/upgrading (default is the dselect apt methods) under whichever (including current tty) x-terminal. Use it for a month now and really love it. Since it's GPLed where can i find sources? I'd like to compile it for PPC. I tried to find it on download.stormix.com but failed It's in ftp://download.stormix.com:/storm/dists/rain/main/source/ if I understand correctly, rain is their stable distribution and potato is just a recompilation of some packages for upgrade purpose. -- Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Don't underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: aptitude
On Wed, Mar 08, 2000 at 07:52:40AM -0800, Kenneth Scharf wrote: Just take my comments as a wish list for the future, I know this stuff is still alpha grade (but still very usefull). Nice thing about debian is that it not only has a bullet resistant package manager (not bullet proof as per some of the slink-potato upgrade horror stories I've been reading), but several different front ends. Gnome-apt looks good too, (but has a bug in that the 'terminal window' that shows the 'action' goes black after one screenfull scrolls up). I installed potato from scratch on a computer via the web (had to install the 'base' from floppies 'cause I couldn't get apt to use a proxy at first to see though a firewall) but got the rest via apt-get, dselect, gnome-apt, and aptitude. (can mixing package manager frontends screw up things?) Anyway it is LOOKING GOOD! Goodluck with the un-freeze process! You just miss another one: sl-stormpkg from Stormix. Sure, it's not on potato but add deb ftp://download.stormix.com/storm potato main in sources.list and install sl-stormpkg. It's GPLed, GNOME-based, used whatever commands you want for updating/upgrading (default is the dselect apt methods) under whichever (including current tty) x-terminal. Use it for a month now and really love it. Stormix make great efforts to make their distributions fully compatible with Debian. This should be applaused, especially in regards to the mess that some other vendors made. I hope to try it in a week or two. Just my 2 canadian cents. -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Sat, Oct 02, 1999 at 03:10:23PM +1000, Hamish Moffatt wrote: On Fri, Oct 01, 1999 at 09:06:59PM -0500, The Doctor What wrote: On Fri, Oct 01, 1999 at 08:47:20PM +1000, Craig Sanders wrote: In short, a summary (admittedly from my point of view) follows: In a discussion on whether network daemons should do one of the following: a) Simply start up, grabbing any ports it needs (most do this) b) Not start up (a few do this) c) Ask about what ports to grab and whether to start up (some do this) This letter is to make it public that I think Craig has gone too far. He has hurt my feelings and has been very insulting to everyone in debian-devel. And this is not the way to get things done. Did you consider his point, though? Why would you install a service if you don't want it to run? I can add I'm one of those who would prefer being asked. My configuration is that I have network service on init 3 and 5, [xwgk]dm on 4 and 5. Sometime I'm on a network, sometime I'm not. Having *any* service start automatically can be as annoying as having to restart all services after each upgrade. Given the possibilities that debconf give us, can't we consider to make it a possible choice of medium priorities, the default being that each daemon should (re)start themself? It's not as secure as it should be but is reasonable and more insecure daemon (like date, echo, etc.) can use a greater priority. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome. -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Little FAQ for users and maintainers
Mail cross-postoned, please, remove the debian-devel list before sending back Many time, apt-get break on conflicting files. It happens me often on unstable but also when upgrading from slink to potato. Here some recommendations to help users resolved the conflicts and also to help maintainers do the Right Things (TM) the first time. Should we consider building a debian-mentors FAQ for things like this? - For users: When a conflict occurs, try to run apt-get -f install several time until all conflict are removed or no more packages can be install without conflicting somewhere else. Sometime it takes more than one turn to apt-get to correct those packages. Also, take in note the conflicting packages and report them to the BTS under the package one you was trying to install or upgrade. This will help to improve the overall quality of Debian. For maintainers: Moving files from one package to another. Supposed that you move a file from Package foo to Package bar. If Package foo still existed, Package bar should included a Conflicts reading this way: Conflicts: foo ( new-version) where new-version is the version of the Package foo who has the conflicting file removed. If foo is removed, you should change it to Conflicts: foo or Conflicts: foo (= old-version) where old-version is the latest version of foo. This last one don't handle local package in the form of foo old-version.1 (that's the recommended way to do local NMU) and that's why it should be avoid when possible. -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Mon, Sep 27, 1999 at 02:23:03PM +0200, Federico Di Gregorio wrote:
Scavenging the mail folder uncovered Siggy Brentrup's letter:
There should be one for the main distribution. Assume I want to go
into the CD business providing support for packages in the main
dist. No major problem with most of the packages, but I am not willing
to support packages with philosophical, political or religious
contents.
The way it is, I can't say Support for all of Debian's main dist.
My point is, should there be subjective stuff in the main dist?
I don't know the answer but having non-doc (in the sense of
non-application-that-is-in-main-doc) stuff is bad. What if I package
the 3 CD set of US maps that is publicy available? That is about 1.8Gb
of sources plus 1.8Gb of .debs for about 3.6Gb of ftp space... and
nobody can tell me don't do that!
OTH, everybody can say you to not do that. The only point where policy
say you not to do something, is about dfsg-freeness. Even there, they
just say you to put them in non-free. What protect Debian from abuse
is the eye-balls of everyone. The same ones who say: He! new-maintainer
take too much time! or What all those packages waiting so long in
Incoming? or even: Should we consider a free client of a non-free
server to be non-free?. I have a great confidence about hearing the
herd of kitten if you really upload the US maps, I'm just not sure
if they'll just say you to remove it or ask you to upload the more
recent version ;)
What about having Debian be an OS+apps and have SPI found a *new*
association for the distribution of free *data*? The data can even use
.deb format, but Debian/doc is definitely the wrong place for
religious/political/etc stuff. IMHO!
Why can't Debian just can't be this association? That's right that
main/doc is missed named and that we need a better sectionning
(main/graphics is even worst and what about x11). When I submit
data, I knew that it was just a patch, an incomplete solution to
the problem. It has to be easily realisable, implementable and not
too much contrainst so that it will add to Debian without removing
anything. IMHO, that's why it was accepted with so few discussions.
It was just a first step but now it's done. Debian will continue
to grow and we will handle it better then some company that forget
their starter consumers to go for the mass market. It's simply not
the way we work.
Debian is one of the most interesting example of distributed development
I can see. A very flat organization, based on volunteers, distributed
around the world and with a organizational system to make it shame most
of the RD directors of TOP500 companies. Sure, Debian don't follow
the same model but, that's ok: we don't even share the same goals; they
want to make money, we want to make the best distribution and have some
fun by doing so.
We have some fantastic tools: the build system, dpkg/apt, debconf/menu
consors, the cd-scripts, dinstall, the BTS, the vote system, the build
queue, the policy modifications process, etc. All this tools manage the
growth of Debian fantastically. There still some bugs to work around
(growing numbers of critical bugs, lag in the new maintainer process...)
but new initiatives (qa.debian.org and the sponsorship page) proves that
we aware about them and that we are in the process of correcting them.
Maybe should we make more publicity about this aspect of Debian. I'll
just give a conference next month about the organization of Debian,
what we are, how we work and how can they work *with* us. A quick
poll of people around me, all implicated in Linux just show me a big
point: most (something like half the people) think that Debian is a
startup company like RH was a time ago. They can't believe that Debian
work the same way as Linux, even a more open one should I say. Maybe
ESR should brainwash them a little more about the OpenSource model ;)
To everyone, keep working on this, I'm pretty sure we can get out
of it *without* removing anything to Debian. Just make it even
better!
Ciao,
Fabien
{ who finally remove his Debian patriotic hat ;) }
BTW, why couldn't we make a Cecilia/RoseGarden/abc contest for a
Debian Hymn? The FSF has one, why not us ;)
Ciao,
Federico
--
Federico Di Gregorio [http://www.bolinando.com/fog] {Friend of Penguins}
Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED]
Try the Joy of TeX [http://www.tug.org]
-- brought to you by One Line Spam
--
Fabien NinolesChevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail:[EMAIL PROTECTED]
WebPage:http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: a question about BTS severities
On Tue, Sep 28, 1999 at 12:01:16PM +1000, Herbert Xu wrote:
On Mon, Sep 27, 1999 at 05:30:51PM -0700, Joey Hess wrote:
Actually, it should be critical if it's a root exploit. Grave only
includes
those that only comprise the user's account.
Last I checked, root is a user. This is not a formal definition we're
working from, please use common sense. (Note: grave is a _higher_ priotity
than critical. Note also: root exploits tend to turn into user account
exploits as soon as the attacker wants them to.)
Root may be a user, but he is a special one at that :) root has privileges
that no other users have. If a user account was compromised, the attacker
is only able to perform tasks that user was allowed to, however, if the
root account is compromised, then that implies the compromise of all user
accounts on that machine, and things like using privileged ports, or
doing port IO, etc.
I think that any user account exploit is critical - maybe it's a sudoers,
not. However, grave is for exploit such as external access to private file
without however giving login access to the machine.
Also, AFAIK, critical is listed above grave (and important and others) in
all the relevant docos that I've seen.
That's what I read also.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Fabien NinolesChevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail:[EMAIL PROTECTED]
WebPage:http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: Metapackages (was Re: Debian Weekly News - September 14th, 1999)
On Thu, Sep 16, 1999 at 12:51:16PM +0200, Laurent Martelli wrote: SB == Stephane Bortzmeyer [EMAIL PROTECTED] writes: SB On Thursday 16 September 1999, at 2 h 3, the keyboard of Laurent SB Martelli [EMAIL PROTECTED] wrote: very nice, but how will uninstallation be handled ? Will you be able to uninstall all the packages of a metapackage in one step ? SB Certainly not: SB - a package can be a member of several meta-packages, We could state that the default is not to remove a package as long as it belongs to a metapackage. SB - a package could have been installed before (and independently SB of) a metapackage which includes it). That could be tracked during the installation of the metapackage. It would know what packages were already installed before. Then when you want to remove the metapackage, you could say only remove packages that were installed by the metapackage or remove all packages, regardless of when they were installed. -- Laurent Martelli [EMAIL PROTECTED] What should be good is a new state saying that a package has been install by the dependencies check rather than by user direct selection. So, the package will stay as long as it resolved a dependency, but be remove when no more package who depends on it is install, on a dpkg --remove --pending. How sould we implement it? That's the big discussion: IMHO, this should be add to dpkg along with hold, installed, upgrade, purge, etc. Other think that dpkg is not the right tool for such a feature and this should be handle by apt. Just my 2 pennies. -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: FreeBSD-like approach for Debian? [was: Re: Deficiencies in Debian]
On Thu, Sep 16, 1999 at 12:48:43PM -0700, Jakob 'sparky' Kaivo wrote: On Thu, 16 Sep 1999, Raul Miller wrote: Thursday, September 16, 1999, 10:50:57 AM, Raul wrote: Um.. you're just not lazy enough... # cd /usr/local/bin # ln -s /usr/bin/perl On Thu, Sep 16, 1999 at 11:42:21AM -0700, Steve Lamb wrote: ln -s `which perl` /usr/local/bin/perl You're confusing keystroke time with character count. Hmm cd /uTABloTABbTABENTERln -s /uTABbTABperlENTER 28 keystrokes ln -s `which perl` /uTABloTABbTABENTER 28 keystrokes Of course, these assume a fairly clean /, /usr, and /usr/local. Someone may want to double-check my counting. The answer of course, is that the first is better, as you don't have to reach for the backtick. ;) BTW, I know you can also TABcomplete the which command, but you first have to type whic to get past matching while, so just typing h is simpler. -- Jakob 'sparky' Kaivo - [EMAIL PROTECTED] - http://www.ndn.net/ As time goes on, my signature gets shorter and shorter... - me What about: zsh# ln -s =perl /usr/local/bin 27 keystrokes without assuming anything or even: zsh# ln -s =perl ~lbin 18 keystrokes if you have ~lbin variable correctly set Just picking ;) -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Let's Debian blow... gracefully! [was Re: Intent to package GNU Philosophy web pages]
Quoting Joseph Carter [EMAIL PROTECTED]: On Tue, May 25, 1999 at 10:35:57AM +0100, Edward Betts wrote: I changed the description so it does not say it is a mirror anymore: [..] Does that help at all? Not really, but if enough people really think I'm wrong on this I won't press the issue. I also didn't press the issue with the anarchists thing, I'm hoping for a better solution to the overall size od the distribution. -- Joseph Carter [EMAIL PROTECTED]Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First! - Shinobi There are worse things than PerlASP comes to mind Although I tend to agreed with Joseph on this point, I also think that the main problem is still the same as with the Anarchy FAQ: No other cool place (personal web page is not the answer because is not part of the distribution) to place this kind of stuff. So I want to make a Suggestion: Creation of a sub-directory aside from main, contrib, non-free named data. The data directory will contain packages DFSG-Free that the maintainers feel they can be useful to a minority of people or is too big to be included in the main distribution. The main purpose is too provided data that's is not essential to any programs in main but can be useful for any user. Examples of those packages are: - Supplemental themes (a default should however be included in main); - Some not program specific documentation; - Tutorials; - Astronomical data; - Foo-Scripts; - Funny manpages. The following rules should be follow, however: - No packages in main should depend solely on a package in data. - The maintainer decision on this subject is just the same as with the Section: field. It's a suggestion that can be override by the archive maintainer. - The data should only contain packages compliant with the DFSG. - The data subdirectory is an entire part of Debian. It's purpose is to let the CD vendors/archives maintainers/users choice between a Debian Light who fit on a reasonable amount of CDs, and an Debian Extended who can fill you're entire RAID array. The reason for a seperate directory is for ease of mirroring and CD building. It gives us also an easy way to check if a package can be on data. I will really like to see this one at least second. It's an old thread that I saw reborn and kill too often. My english is not perfect, so it's certainly need some correction but I think the idea is here. Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le VeneurDebian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: Bug#23436: vrwave should maybe go in contrib?
On Mon, Jun 15, 1998 at 11:04:04PM +0200, Remco Blaakmeer wrote: On Sat, 13 Jun 1998, Javier Fernandez-Sanguino Pen~a wrote: Well, vrwave only needs a java runtime environment to run. The dependancies I've marked are related to jdk 1.1 (jdk1.1-runtime) or jdk 1.0.2 (jdk-shared OR jdk-static). Alas, I sent a mail to wnpp because I don't like this either, I would prefer a Depends: java (= 1.0.2) and let the package manager figure out if the dependancy is fulfilled with any version of Java runtime you have. You can't do that because of a limitation in dpkg. If a package Provides: java and another package Depends: java (= 1.0.2), the former package can never satisfy this dependency. To satisfy this versioned dependency, you'll have to have a package that is actually called java and has version 1.0.2 or higher. AFAIK there are other runtime environments (kaffee?) that would go into main, but since there is no virtual package as of now, and I really haven't tried it with these (maybe you could help?) the Dependancies are as shown. I remember to see some place for this issue in the policy but dpkg has already enough bugs against version dependencies for going to a feature-add [but may be is it the right time?] Virtual package version dependencies are something often ask and even apt is ready for it [According to the doc]. -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation/License freeness
On Mon, Jun 08, 1998 at 11:39:38AM +0200, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Mon, 8 Jun 1998, Marcus Brinkmann wrote: On Sat, Jun 06, 1998 at 08:42:14PM -0500, Chris Lawrence wrote: On Jun 06, Santiago Vila wrote: Documentation may be included in main so long as there are no restrictions on the unmodified use of the documentation and no restrictions on translating the documentation to another format, provided the translation preserves the natural language of the author. Mmm, sorry but I didn't write that :-) Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNXuxUyqK7IlOjMLFAQHnwAP8CxurYIwwUcAQHLiIU5j9BcObpiYe6x5a QGgqdTojuh65NPDq59db7onxIdUyfNoVuo3CbyWGFUZn3M+CPTwaIdSi7e4t61b2 nJu76KZCsEAepV2Fid8IBDZYVGs2PKuWHq+tmTgUUb66FD0k245CBbYGUK4rdKHS ErjxOJ/s6Wg= =2i6I -END PGP SIGNATURE- Yes, just look is from myself. -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation/License freeness
On Tue, Jun 09, 1998 at 07:56:31PM +0200, Marcus Brinkmann wrote: Hello Fabien! Hello Marcus! On Tue, Jun 09, 1998 at 10:41:38AM -0500, Fabien Ninoles wrote: I'm not sure I understand you well but here is my opinions about freeness of Documentation: Documentation describing the functionnality of a software are dependant of the software. Then, they should be considered as source by the DFSG. The reason underlying this is the same as why bad documentation is considered like a bug. The DFSG must be apply to them. This included most FAQ, manual and source. Yes, this is correct. Not technical documentation can be divised in two kind. Author works and Official Documents. Author works must not be changed. They express the opinions and observations from a person and can even be a description of something. They have the particularity to be fixed in time and always can't be fixed because heavily link to a given author and a given time. White Paper, most e-mails, and document such as Homesteading in the Noosphere or Le Corbeau et le Renard from Jean de la Fontaine, are of this kind. I considered this work free enough for Debian when simple verbatim reproduction, with or without a fee, are permitted without conditions. Even unofficial translations can be prohibited because we can't decided if the translation really correctly reflect the thought of the author. Yes, although it would be very sad if we would have much documents of this sort in our distribution. I don't think those sort of documents belong to the Debian distribution (are there any of these beside some email quotes in /usr/doc?). The most important thing is: We don't *need* to change them. There is no reason for us to change them, as we don't do censorship (well, we include them or we don't). I don't know what Homesteading in the Noosphere is, but if they are literature, well, copyright expires after some fifty years, and then it becomes free. Isn't overly important for us, too. Yes, literature is of this kind of documents. As you say, we don't need to change them, so why not including them simply because is not allowed us to do thing we already know we should not do [well, hope you understand what I try to say.] About the inclusion of such document, white paper [that's it, paper written to say why such software was written and the idea behind is design. CVS as one who merits some looks...] can be very interesting for understanding what the purpose of this kind of software. Is especially true with specialized software that are mostly distributed only by Debian [because other distribution don't care.]. Official document are like author works. They are bound with a specified time and loose all their value if modifications are done freely on them. However, translations should be permitted given it is clearly mark as a translation and that the authors are [may be] not accepting the work as a verbatim copy of the original. DFSG compliance can may be need modifications with version and/or title change [because people need to know what we are talking about], but aren't necessary IMHO. Do you have examples for this category? The only one I can think of are copyright documents. I think copyrights fit very well in your description. I can't think of other examples. RFC, W3C standard, POSIX, etc... Changing anything in this kind of document, even fixing bugs, are enough to say that the document is no longer the RFC 351 or the HTTP 3.0 standard. If we make change to such documents other than translating them, how someone can say its program are bug for bug compliant with such standard? We should not override the standard mecanism used for revising such documents who consists mostly in putting out a new revision of the standard with a different numbers. Remember that's harder to decided what's a bug in a document than in software. It's like trying to say if this document works well. Finally, it's possible for a document to included both technical part and non-technical part. The license should then permit the technical part to be changed accordingly to the source to be DFSG compliant. Yes, but it would be better to have them completely seperated. In a book, this seperation should be made clear using different chapters or whatever. It should probably be easy (and allowed) to remove the offending non-technical part, although I'm not sure if this is necessary. I'm not sure about mixing those types in one source... phew, this gets complicated! Yes, but some people like to put it, in example, in the introduction of a manual. We should be able to correct the technical and respecting the vow of the author to not change the introduction. I don't you want to put an info page in non-free simply because the author don't want you to remove his thanks to God and his family [Yes, the policy, as apply to some non-free package, express that's not sufficient free
Well, please ignore the precedent (was Re: Documentation/License freeness)
On Tue, Jun 09, 1998 at 06:41:25PM -0500, Fabien Ninoles wrote: On Mon, Jun 08, 1998 at 11:39:38AM +0200, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Mon, 8 Jun 1998, Marcus Brinkmann wrote: On Sat, Jun 06, 1998 at 08:42:14PM -0500, Chris Lawrence wrote: On Jun 06, Santiago Vila wrote: Documentation may be included in main so long as there are no restrictions on the unmodified use of the documentation and no restrictions on translating the documentation to another format, provided the translation preserves the natural language of the author. Mmm, sorry but I didn't write that :-) Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNXuxUyqK7IlOjMLFAQHnwAP8CxurYIwwUcAQHLiIU5j9BcObpiYe6x5a QGgqdTojuh65NPDq59db7onxIdUyfNoVuo3CbyWGFUZn3M+CPTwaIdSi7e4t61b2 nJu76KZCsEAepV2Fid8IBDZYVGs2PKuWHq+tmTgUUb66FD0k245CBbYGUK4rdKHS ErjxOJ/s6Wg= =2i6I -END PGP SIGNATURE- Yes, just look is from myself. -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 Well, sometime you just hope to doesn't this damn key to quickly... Sorry, this quote aren't mind, although it expresses some of my opinions ;) Ciao! -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation/License freeness
and/or title change [because people need to know what we are talking about], but aren't necessary IMHO. Finally, it's possible for a document to included both technical part and non-technical part. The license should then permit the technical part to be changed accordingly to the source to be DFSG compliant. What we need to keep in mind with deciding if a document is DFSG compliant is the user point of view. If it does more harm to allow modifications in a document, regarding both the historical aspect and the technical point of view, documents don't need to allow modifications. Allowing no verbatim modifications on Author Works can harm [just see what out-of- context citations can do in press media and you should understand me.]. Not allowing translation of Official Documents are, IMHO, discrimination. This documents needs to be known by everybody. However, other modifications can lead to the distribution of different standards whom all share the same name, which as everybody know is worst than not having any standard at all. Finally, source needs to be fixed and technical documentation who are not compliant with the source are already broken. Not allowe the documentation to be fixed is a bug in itself. All that's IM[NS]HO. -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Bazaar Politics (was: Debian Re-organization proposal)
I just split the subject of the previous to take more about politics in Debian and let people discuss about the proposal. I think we too much mess up with wordin like democracy and government. Debian are neither. It's a bunch of volunteers trying to work together. If voting let you think it's a democracy, don't be foul. It's a really an officialisation of a concensus. Debian needs it to ensure that's it's not only the big talker who leads, and loose all the silent majority of developpers. Voting is not need for submitting decisions, discussing about it or deciding who's working on what. Debian already works correctly for most of the Decision making process. Ideas are submit, discussed and most of the time, something came out [may be I'm a little optimistic here, but see apt, see the quality of the distribution. We are the only one who really supports that much features and without being paid for!] The problems came when it's time to put it out to the world. Are we sure that everybody agreed? Will we loose all ours maintainers by doing the move? Having a leader it's the easy solution. Whatever he decided, we can always blame it if it's not right. And I'm sure you'll do it! Even for petty thing like the Blue Eye Captain. The SPR are the solution proposes by Ian for helping thing a little. By this mean,he intents to ensure that everybody could talk even about subject it even doesn't have time to heard before. I'm pretty sure that most of the vote taken will be a big yes with no compromise. I think we are a little more than whatever cat crowd Bruce deems to call us when in his bad mood. I think we can recognize wise decision as a crowd and, contrarely to the common tought, us IQ aren't the lesser IQ of all of us divided by the number of people. If this was right, Debian will be the worst distribution in the World. We are an example. We do the Bazaar all the way. We should be proud about it. Not even red hat or slackware want to deal with so a big goal as we do in Debian [eh, we triple the number of package and support not two or three but four architectures!] Debian is still an example, and for now, we just try to solve the normal organisational problem it's happen, I mean ensuring that an idea wasn't lost in the under the normal mess of any bazaar. [sorry about my english, it's the first I try myself on something that's complicated in englis :) ] -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: consistency check
On Sat, Apr 25, 1998 at 06:11:25PM +1000, Anthony Towns wrote:
[...]
In particular, it checks that all the files listed as alternatives, as
diversions and in the dpkg database itself are all present and accounted
for, and produces a list of things that weren't listed but are still on
your system, and things that were listed, but aren't. It also takes into
account symlinks (if you've got a symlink from /usr/tmp to /var/tmp, it'll
complain if /var/tmp doesn't exist, for example), user home directories
(it'll make sure that everything in /home/aj is owned by aj, for example),
and a couple of other things.
It's still a work in progress -- in particular there are bunches of files
that are created when packages are installed but dpkg is never told about
(/etc/passwd is one example), which cruft doesn't cope with too well at the
moment -- but it's a start, at least.
That's the reason why I would like to see a
dpkg --{remove,add}-files [--package package] files...
option to dpkg. I think it's simple to implement just add/remove entry
to the package .list file and can ease the task for securing local files
by let it provides a local default package from dpkg in addition
to help checking the system.
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. PGP encrypted mail preferred.
``It's not a vision, or a fear. It's just a thought.''
--
Fabien Ninoles Running Debian/GNU Linux
E-mail:[EMAIL PROTECTED]
WebPage: http://www.callisto.si.usherb.ca/~94246757
WorkStation [available when connected!]: http://nightbird.tzone.org/
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
pgpnW1NS8aU4Q.pgp
Description: PGP signature
Re: AUC-TeX in xemacs
On Thu, Apr 09, 1998 at 05:28:45PM -0500, Douglas Bates wrote: Fabien Ninoles [EMAIL PROTECTED] writes: Sorry but from upgrading to xemacs20 make AUC-TeX not seems to work well in xemacs, especially the key bindings and no menu.=20 Here's an extract from my .emacs file, I only put the relevant part. ;; ;; AUC-TeX settings ;; ;; (setq TeX-auto-save t) (setq TeX-parse-self t) (setq-default TeX-master nil) ;; XEmacs seems to forget everything about LaTeX and by example bind C-c C-e to tex-close-latex-block in place of LaTeX-environment who aren't even define (but exists in auctex/latex.elc). This old behavior miss me a lot... Can some one can give me an hint? Try using M-x load-library tex-site RET immediately after starting xemacs. If that works then put (require 'tex-site) in your .emacs file. I think the thing that has changed is that tex-site is no longer autoloaded in the 50debian-site.el file -- Douglas Bates[EMAIL PROTECTED] Statistics Department608/262-2598 University of Wisconsin - Madisonhttp://www.stat.wisc.edu/~bates/ That's the point... I try to load the file but after already open a TeX file. May be this should be mentionned somewhere. Or is it a bug (minor one)? -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 pgp7iwKWsNXEy.pgp Description: PGP signature
Re: dinstall and PGP
On Wed, Apr 08, 1998 at 08:50:56PM +0100, Enrique Zanardi wrote: On Wed, Apr 08, 1998 at 08:23:48PM +0200, Marco d'Itri wrote: Can someone hack dinstall to install packages which are not PGP signed but has been copied to incoming? If the UID of the files is the one of a developer we can know who did upload the package. No. We know which account the uploader used. (Even that is not true. The uploader may have changed the UID if he obtained root privileges, but then he can bypass dinstall). And what about packages uploaded to chiar or erlangen? We should be talking about improving our security instead (by signing the packages, and not the .changes file). One of these days we will find trojan horses in Debian packages at compromised mirror sites, and will have to hear all that But, RPM packages are PGPsigned... stuff again and again. Signing changes files are enough because of the md5sums contained in the changed and md5 are an algorithm of mostly the same strength as the one used by pgp for signing up (only the ID are better encrypt), pratically speaking. For better checkup, check for dpkg-cert... I think it also check for the integrity of the files in the systems. So to speak, it was really to find a file that have the same md5 sums than an other one, to find one that's represent something is frankly harder, and to find one that can also do real harms is like finding a neutrinos: something that it's easier to think is an error that it's true. -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 pgpjSrg0EnJ2U.pgp Description: PGP signature
AUC-TeX in xemacs
Sorry but from upgrading to xemacs20 make AUC-TeX not seems to work well in xemacs, especially the key bindings and no menu. Here's an extract from my .emacs file, I only put the relevant part. ;; ;; AUC-TeX settings ;; ;; (setq TeX-auto-save t) (setq TeX-parse-self t) (setq-default TeX-master nil) ;; XEmacs seems to forget everything about LaTeX and by example bind C-c C-e to tex-close-latex-block in place of LaTeX-environment who aren't even define (but exists in auctex/latex.elc). This old behavior miss me a lot... Can some one can give me an hint? Thanks, -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 pgp6cHVtWEgQ1.pgp Description: PGP signature
