Uploaded kdebindings 2.2.2-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 19:21:09 + Source: kdebindings Binary: libkdexparts-dev dcoppython libdcopc-dev libkdexparts1 dcopperl libdcopc1 Architecture: m68k Version: 2.2.2-4 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Bas Zoetekouw [EMAIL PROTECTED] Description: dcopperl - Perl bindings for DCOP dcoppython - Python bindings for DCOP libdcopc-dev - C bindings for DCOP (Development files) libdcopc1 - C bindings for DCOP libkdexparts-dev - Python bindings for DCOP libkdexparts1 - Python bindings for DCOP Closes: 158161 Changes: kdebindings (2.2.2-4) unstable; urgency=low . * Rebuilt for perl 5.8 (closes: #158161) Files: b64417bfdfab307c6a8733aab76e31ce 42922 libs optional dcoppython_2.2.2-4_m68k.deb 4a44e76401e36827194acc9e04ecc824 56464 libs optional dcopperl_2.2.2-4_m68k.deb e3e8f9a83e727e84b08191e660a91695 17724 libs optional libdcopc1_2.2.2-4_m68k.deb 58bbcb835c2c8852eae59cda31644e14 4902 devel optional libdcopc-dev_2.2.2-4_m68k.deb 8bd740a35b71ba47d0d978bbffe8d163 57978 libs optional libkdexparts1_2.2.2-4_m68k.deb e1120bc7647c80009aa55c157f200c7f 2852 devel optional libkdexparts-dev_2.2.2-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9csPxEycGpQPNsdIRAlVbAJ9+8VYQ5u+xLBlH78ZYtNJThOEtGACeLmdU Mg39Uosdbs6q0mw7CE/DB+4= =3bhx -END PGP SIGNATURE-
Uploaded libcurses-perl 1.06-2.1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 27 Aug 2002 22:09:54 +1000 Source: libcurses-perl Binary: libcurses-perl Architecture: m68k Version: 1.06-2.1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Brendan O'Dea [EMAIL PROTECTED] Description: libcurses-perl - Curses interface for Perl Changes: libcurses-perl (1.06-2.1) unstable; urgency=low . * NMU * Use PerlIO_FindFILE to fetch FILE* from PerlIO objects. * Build against perl 5.8.0. Files: 40c24baade29c28fcf63275595abc0ad 117414 libs extra libcurses-perl_1.06-2.1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9csP9EycGpQPNsdIRAhRgAJ0Zm00Y1nzkVEsjQAAkRWMDL7zErACfebN3 Pt7FspICdzwzDDXb80MIBLQ= =TQhF -END PGP SIGNATURE-
Uploaded ksymoops 2.4.6-2 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 18 Aug 2002 21:30:24 -0400 Source: ksymoops Binary: ksymoops Architecture: m68k Version: 2.4.6-2 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Stephen Frost [EMAIL PROTECTED] Description: ksymoops - Linux kernel oops and error message decoder Closes: 75481 81093 98469 111214 156802 Changes: ksymoops (2.4.6-2) unstable; urgency=low . * New Maintainer. Closes: Bug#156802, #98469 * Recompiled, tested and not crashing. Closes: Bug#75481 * Now depends on binutils. Closes: Bug#81093 * Manpage changed to refer to /usr/share/doc. Closes: Bug#111214 Files: e59383d6e65e2ab4aea2b06230a626ba 162742 utils optional ksymoops_2.4.6-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cwFEEycGpQPNsdIRAoLvAJoD3SWEal6fyA03q7n+0G8bLgRDCQCeLHWH iYW7K6YZqzkpZiKP5hxPbX0= =IvNQ -END PGP SIGNATURE-
Uploaded tardy 1.8-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 19:44:29 -0700 Source: tardy Binary: tardy Architecture: m68k Version: 1.8-4 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Matt Kraai [EMAIL PROTECTED] Description: tardy - A tar(5) post-processor. Changes: tardy (1.8-4) unstable; urgency=low . * Install this file as changelog.Debian.gz. Files: 5f68858955e3fed2a9f84f919dccc75d 51932 utils optional tardy_1.8-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cwFYEycGpQPNsdIRAjj3AKCK70VnfIZDFwwgTm17nkLQ7RNfCACgl08I wSOanslu5t63PUlMDdUxLTg= =cXOk -END PGP SIGNATURE-
Uploaded tuxpaint 2002.08.23-2 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Sep 2002 11:22:38 -0300 Source: tuxpaint Binary: tuxpaint tuxpaint-data Architecture: m68k Version: 2002.08.23-2 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Ben Armstrong [EMAIL PROTECTED] Description: tuxpaint - A paint program for young children Closes: 159017 159096 Changes: tuxpaint (2002.08.23-2) unstable; urgency=low . * Fix dependency on libsdl-image1.2. (Closes: #159096) * Add dependencies on libvorbis0, libvorbisfile3 and build-dep on libvorbis-dev (Closes: #159017) Files: 1c835af070a1333bd647df748a9727d2 68018 graphics optional tuxpaint_2002.08.23-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cwCqEycGpQPNsdIRAjbLAJ9YSmxA5r9xw7iu/jTDs7C7uN2H5wCfRl5F lCYrmQ75M6jbXD810Puhp4I= =uFz2 -END PGP SIGNATURE-
Uploaded imagemagick 5.4.8.2-1.3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 24 Aug 2002 01:32:24 +0200 Source: imagemagick Binary: perlmagick libmagick++5 libmagick5-dev libmagick5 libmagick++5-dev imagemagick Architecture: m68k Version: 4:5.4.8.2-1.3 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Josselin Mouette [EMAIL PROTECTED] Description: imagemagick - Image manipulation programs. libmagick++5 - The object-oriented C++ API to the ImageMagick library libmagick++5-dev - The object-oriented C++ API to the ImageMagick library.--developm libmagick5 - Image manipulation library (free version). libmagick5-dev - Image manipulation library (free version) -- development perlmagick - A perl interface to the libMagick graphics routines. Changes: imagemagick (4:5.4.8.2-1.3) unstable; urgency=low . * NMU for perl 5.8. Set perl build dependency to version 5.8. Use of a higher NMU version number, just in case. Files: a4b061200f590cca166a1fa1dfc8372b 1364692 graphics optional imagemagick_5.4.8.2-1.3_m68k.deb 18a47cbe8bf4a4da50aa65ed18c1b917 752260 libs optional libmagick5_5.4.8.2-1.3_m68k.deb 25870346a14d6097ecfbe3927596a52f 69372 devel optional libmagick5-dev_5.4.8.2-1.3_m68k.deb 466bf9854b8af9e884dd106d846d7ee7 146012 libs optional libmagick++5_5.4.8.2-1.3_m68k.deb dd6fc4e1515992de2ef84c83dcbf8f09 56568 devel optional libmagick++5-dev_5.4.8.2-1.3_m68k.deb 699209ef84932924e5f70319445c2d69 115526 interpreters optional perlmagick_5.4.8.2-1.3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cwCdEycGpQPNsdIRAsALAKCq12BZ+yEmUBQekyNk+bSw6fObKwCeOt7T ZPII90qbDsslhhmhDPKH2ts= =x8uP -END PGP SIGNATURE-
Uploaded libgnomeui 2.0.4-1 (all m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 19:40:24 +0200 Source: libgnomeui Binary: libgnomeui-0 libgnomeui-dev libgnomeui-doc libgnomeui-common Architecture: all m68k Version: 2.0.4-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: libgnomeui-0 - The GNOME 2 libraries (User Interface) - runtime files libgnomeui-common - The GNOME 2 libraries (User Interface) - common files libgnomeui-dev - The GNOME 2 libraries (User Interface) - development files libgnomeui-doc - The GNOME 2 libraries (User Interface) - documentation files Changes: libgnomeui (2.0.4-1) unstable; urgency=low . * New upstream release. Files: aed8af60f03593885dc21167e8f0b995 266548 libs optional libgnomeui-0_2.0.4-1_m68k.deb c3c8223b9a37556676f852e1f4ea 312806 devel optional libgnomeui-dev_2.0.4-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9cyKUcS3JWD3FdvcRAh3ZAJ40F6qQT6++UUdUz5F4AF+aNQog2ACbBaud nzwWDIaujemOGE5hCXCf5BI= =aYsi -END PGP SIGNATURE-
Uploaded fidelio 0.9.6-6 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Sep 2002 22:39:12 +0200 Source: fidelio Binary: fidelio Architecture: m68k Version: 0.9.6-6 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Samuele Giovanni Tonon [EMAIL PROTECTED] Description: fidelio- Gnome Hotline client. Changes: fidelio (0.9.6-6) unstable; urgency=low . * The lipng affair release; changed build-dep from gdk-imlib-dev to gdk-imlib1-dev Files: aac6ed680e0001db75190dc399584677 132374 net optional fidelio_0.9.6-6_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9cyKWcS3JWD3FdvcRAoITAJ9H2SD+U5eqrdlHyfkog0CqXCGuIgCcDjdT mCgXlCI3On0tCpr1uA2Q/Zw= =ZepN -END PGP SIGNATURE-
Uploaded libgnomecanvas 2.0.3-1 (m68k all) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 15:13:09 +0200 Source: libgnomecanvas Binary: libgnomecanvas2-dev libgnomecanvas2-common libgnomecanvas2-0 Architecture: m68k all Version: 2.0.3-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: libgnomecanvas2-0 - A powerful object-oriented display - runtime files. libgnomecanvas2-common - A powerful object-oriented display - common files. libgnomecanvas2-dev - A powerful object-oriented display - development files. Changes: libgnomecanvas (2.0.3-1) unstable; urgency=low . * New upstream release. Files: db4c76cb5945d0606c168a23347dc671 88866 libs optional libgnomecanvas2-0_2.0.3-1_m68k.deb 7d3e60473c311e466b9e33733875dbb3 694344 devel optional libgnomecanvas2-dev_2.0.3-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9cyKScS3JWD3FdvcRAu6tAJ9FxMU/FyuF8OXvLdzLVYFSfHJr3gCfYXsT 1eFhWb5sGKF1at90qzHvxG8= =kar/ -END PGP SIGNATURE-
Uploaded freetype 2.1.2-3 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 05:53:48 +0800 Source: freetype Binary: freetype2-demos libfreetype6 libfreetype6-dev Architecture: m68k Version: 2.1.2-3 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Anthony Fok [EMAIL PROTECTED] Description: freetype2-demos - FreeType 2 demonstration programs. libfreetype6 - FreeType 2 font engine, shared library files. libfreetype6-dev - FreeType 2 font engine, development files Changes: freetype (2.1.2-3) unstable; urgency=low . * CVS updates as of 2002-08-29 (around VER-2-1-3-RC1) * Make FreeType less strict when some slightly buggy fonts set the CMap format 4 last segment idRangeOffset to 0x. (Fixes: Bug#150678, #155864) Files: 9ef50dd2793f039832d3897b74a09888 252372 libs optional libfreetype6_2.1.2-3_m68k.deb 401be58fce32fb42716ddde21d33a8ad 594994 devel optional libfreetype6-dev_2.1.2-3_m68k.deb ec454cf1d98e761b44928d61c673bde2 39112 utils optional freetype2-demos_2.1.2-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9cyKAcS3JWD3FdvcRAjlQAJwLb9wLWQZF2OcIGg4fyQI0RTW4AACfSA+a 0m/bJa2FOJpe6NXxikMBCJU= =xo+c -END PGP SIGNATURE-
Uploaded libticalcs4 4.1.5-1 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 23 Aug 2002 11:57:48 +0200 Source: libticalcs4 Binary: libticalcs4-dev libticalcs4 Architecture: m68k Version: 4.1.5-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Julien BLACHE [EMAIL PROTECTED] Description: libticalcs4 - Provides functions to communicate with TI calculators libticalcs4-dev - Provides functions to communicate with TI calculators [developmen Changes: libticalcs4 (4.1.5-1) unstable; urgency=low . * New upstream release. * Bumped shlib to 4.1.5-1. Files: 46ae4b990ca1b997d830da832e8cdab2 99256 devel optional libticalcs4-dev_4.1.5-1_m68k.deb 76db354c7b654a17d0b70060b7ab06e4 77862 libs optional libticalcs4_4.1.5-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9cyKPcS3JWD3FdvcRAr+UAJoCnInPhPEp4ayvCev4msxwtunE2gCfQ++F CFCcu4li+0OYPooKFbvxwEE= =pn8L -END PGP SIGNATURE-
Uploaded gmessage 1.0.7-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 16 Jun 2002 01:06:25 +0200 Source: gmessage Binary: gmessage Architecture: m68k Version: 1.0.7-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Søren Boll Overgaard [EMAIL PROTECTED] Description: gmessage - A Gnome based xmessage replacement. Closes: 79553 Changes: gmessage (1.0.7-1) unstable; urgency=low . * Initial Release (closes: Bug#79553). * michael d. ivey [EMAIL PROTECTED] announced his intention to package this program some 1 and a half years ago. I have attempted to contact him, to determine if intends to follow through with the upload, but have received no reply. This package closes his original ITP. Files: 6f1eac2b5fce83e6446a2ff5d9572656 23956 x11 optional gmessage_1.0.7-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4lnEycGpQPNsdIRAmJFAJ9SGrZ9PDtZ8TFJuu7u7h/vRKVo0ACeOlIj rdCYtmRrHkSu/JviDd8quUA= =Oz3S -END PGP SIGNATURE-
Uploaded wmmemmon 0.7.0-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 24 Jun 2002 23:31:41 +0200 Source: wmmemmon Binary: wmmemmon Architecture: m68k Version: 0.7.0-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Søren Boll Overgaard [EMAIL PROTECTED] Description: wmmemmon - A dockapp to monitor memory/swap usages. Closes: 150893 Changes: wmmemmon (0.7.0-1) unstable; urgency=low . * Initial Release (closes: Bug#150893). Files: d24a48b7d8ecc29756be5c46a0f79dd5 37580 x11 optional wmmemmon_0.7.0-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4mQEycGpQPNsdIRAmV6AJ4xfzNK5pibyF4/hdrX5Lq8twgZTgCffW28 qy1yTDttHoitEQRwtiNogI8= =ZoFi -END PGP SIGNATURE-
Uploaded bogl 0.1.10-2 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Sep 2002 21:35:16 -0400 Source: bogl Binary: libbogl0 libbogl-dev bogl-bterm Architecture: m68k Version: 0.1.10-2 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Daniel Jacobowitz [EMAIL PROTECTED] Description: bogl-bterm - Ben's Own Graphics Library - graphical terminal libbogl-dev - Ben's Own Graphics Library - development files libbogl0 - Ben's Own Graphics Library - shared library Closes: 159045 Changes: bogl (0.1.10-2) unstable; urgency=low . * Build depend on libpng3-dev instead of libpng2-dev (Closes: #159045). Files: e369fce9ac2b29a8ed714bace6a6ea99 61830 devel optional libbogl-dev_0.1.10-2_m68k.deb 69e04c7132ef3850a446371f0cf7533a 37930 libs optional libbogl0_0.1.10-2_m68k.deb 5916da027c508a08f644a5030dab5ec7 16438 utils optional bogl-bterm_0.1.10-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4lTEycGpQPNsdIRAl8ZAJ9da66TKV63ZVL07BNPJXLy5HSoGgCgjLiy Sv6JKuP2Y02ao7yqJFivAew= =WaJe -END PGP SIGNATURE-
Uploaded wmweather 2.2.10-2 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 30 Aug 2002 18:47:50 +0200 Source: wmweather Binary: wmweather Architecture: m68k Version: 2.2.10-2 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Martin A. Godisch [EMAIL PROTECTED] Description: wmweather - WindowMaker dock app that shows your current weather Changes: wmweather (2.2.10-2) unstable; urgency=low . * Added Spanish debconf translation. Thanks to Ricardo Javier Cardenes [EMAIL PROTECTED]. Files: 260231a798cab7f8928605fd45977913 28914 x11 optional wmweather_2.2.10-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4nBEycGpQPNsdIRAjN/AJ9jnVcKTk6YWkr3/JEXgkin0GEDzQCgnqHJ kV2nALw0c3VWpXvr6WNPk6o= =ckNz -END PGP SIGNATURE-
Uploaded qe 0.2.0-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 03:36:11 +0800 Source: qe Binary: qe Architecture: m68k Version: 0.2.0-3 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Anthony Fok [EMAIL PROTECTED] Description: qe - A PE2-like text full-screen color text editor Closes: 159144 Changes: qe (0.2.0-3) unstable; urgency=low . * zh_TW.Big5.po did not conform to modern gettext format. Fixed, and renamed to zh_TW.po. Thanks to Gerhard Tonn for the FTBFS report. (No, this has nothing to do with gcc-3.2. :-) (Closes: Bug#159144) Files: 72c7449a1dabc77b6ba21fd8c63f2c2f 77740 editors optional qe_0.2.0-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4m2EycGpQPNsdIRArO+AJ9NZ5lBtnfCn/ZrktGRnUXlaLjI9ACgsOvL 56Aa8czpVCNSwjU6u48c0GA= =qOBG -END PGP SIGNATURE-
Uploaded scli 0.2.12-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 09:53:26 + Source: scli Binary: scli Architecture: m68k Version: 0.2.12-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Remco van de Meent [EMAIL PROTECTED] Description: scli - a collection of SNMP command line management tools Changes: scli (0.2.12-1) unstable; urgency=low . * New upstream release Files: 05a6c51e01787b114d27810181af416a 219866 net optional scli_0.2.12-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4nWEycGpQPNsdIRAp7rAKCg8iT+Ffz/PtClIVkC4R362RvEbwCgrD1G pCCQNNpOtoZhjCEU9ypEg3Y= =pXTv -END PGP SIGNATURE-
Uploaded gnome-system-monitor 2.0.2-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 14:45:46 -0400 Source: gnome-system-monitor Binary: gnome-system-monitor Architecture: m68k Version: 2.0.2-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Colin Walters [EMAIL PROTECTED] Description: gnome-system-monitor - Process viewer and system resource monitor for GNOME 2 Changes: gnome-system-monitor (2.0.2-1) unstable; urgency=low . * New upstream release. Files: 3a587402b624a82d8cea232e32c09e0f 182876 admin optional gnome-system-monitor_2.0.2-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4lJEycGpQPNsdIRAplWAJ9lHTu6/42EgYo50hLFpzSoyegMuwCfY3Z8 AEF4VCkrg8UqvsHQwajp8Y4= =1/yf -END PGP SIGNATURE-
Uploaded usenet-indexer 20010922-8 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 11 Jul 2002 10:44:58 +0200 Source: usenet-indexer Binary: usenet-indexer Architecture: m68k Version: 20010922-8 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Søren Boll Overgaard [EMAIL PROTECTED] Description: usenet-indexer - A Usenet indexer and web based frontend for searching Changes: usenet-indexer (20010922-8) unstable; urgency=low . * Fix error in README.Debian (Thanks Lazarus Long). * Fix error in httpd.conf.dist.Debian * Fix path to seach executable. * Merge patches into source. Files: dbedd5dcff824eff5ba73fb79d60bc9a 45774 news optional usenet-indexer_20010922-8_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4oAEycGpQPNsdIRAn4JAJ43yNjzIlHa6AN8ew+xXEOozUYEVwCdE3BR li21ag6mcfyVOusH82L87GA= =KvM4 -END PGP SIGNATURE-
Uploaded melon 1.6-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 09:03:16 +0200 Source: melon Binary: melon Architecture: m68k Version: 1.6-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Philipp Frauenfelder [EMAIL PROTECTED] Description: melon - Mail notifier with configurable icons, xbiff replacement Closes: 152301 Changes: melon (1.6-1) unstable; urgency=low . * New upstream release. Closes: #152301 Files: eb0dfc58f489259507aaf74086ba729b 304008 mail optional melon_1.6-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4n2EycGpQPNsdIRApA+AJ4+ZnZ2ZvC7prd4etqCYKQUIUXjoACePMsl txzTDyEJm7rRdBZAbYOvKY0= =Tprs -END PGP SIGNATURE-
Uploaded xchat 1.8.9-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 11:18:11 +0200 Source: xchat Binary: xchat-gnome xchat xchat-common xchat-text Architecture: m68k Version: 1.8.9-4 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Davide Puricelli (evo) [EMAIL PROTECTED] Description: xchat - IRC client for X similar to AmIRC xchat-gnome - IRC client for GNOME similar to AmIRC xchat-text - IRC client for console similar to AmIRC Closes: 159051 159255 Changes: xchat (1.8.9-4) unstable; urgency=low . * The Trnasition in progress release. * debian/control: Build-Depends on gdk-imlib1-dev; closes: #159051. * Built against python2.2; closes: #159255. Files: cf0ec2b3a498f00fc34ae3de68dc4865 185676 net extra xchat-gnome_1.8.9-4_m68k.deb 738c8966f7a34bcede9617fd56b20f79 97602 net optional xchat-text_1.8.9-4_m68k.deb 6e0cca006b96219d4b36c65d62859fda 179884 net optional xchat_1.8.9-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c4nsEycGpQPNsdIRAr67AKCA3koBUNd9IZGquv7Q17s4OEcfSgCgjChj MLdBSsX0Pbe6RZe60vPy24c= =AAQm -END PGP SIGNATURE-
Uploaded glade-2 1.1.1-8 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 30 Aug 2002 01:44:42 -0400 Source: glade-2 Binary: glade-2 glade-common-2 glade-gnome-2 glade-doc-2 Architecture: m68k Version: 1.1.1-8 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Eric Dorland [EMAIL PROTECTED] Description: glade-2- GTK+ 2 User Interface Builder glade-gnome-2 - GTK+ 2 User Interface Builder (with GNOME 2 support) Closes: 156775 Changes: glade-2 (1.1.1-8) unstable; urgency=low . * debian/control: Build-Dep on libgnutls5-dev (= 0.5.3-1) to fix segfault issue. (Closes: #156775). Files: 9e4b4c47e9b2713af7778f965db4e0c6 889240 devel extra glade-2_1.1.1-8_m68k.deb 16eb22fdc33107c267f9923f7a74d12c 932298 devel optional glade-gnome-2_1.1.1-8_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9c5k4cS3JWD3FdvcRAghSAJwP98JH6iTrcs9grIQhv+IXNNAmtwCfU0mk JBQ8jEHjsjK1vjxig+KyOSc= =67lb -END PGP SIGNATURE-
Uploaded net-snmp 5.0.3-2 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Sep 2002 21:35:12 -0500 Source: net-snmp Binary: libsnmp5 tkmib libsnmp5-dev snmp libsnmp-perl libsnmp-base snmpd Architecture: m68k Version: 5.0.3-2 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: David Engel [EMAIL PROTECTED] Description: libsnmp-perl - NET SNMP (Simple Network Management Protocol) Perl5 Support. libsnmp5 - NET SNMP (Simple Network Management Protocol) Library. libsnmp5-dev - NET SNMP (Simple Network Management Protocol) Development Files. snmp - NET SNMP (Simple Network Management Protocol) Apps. snmpd - NET SNMP (Simple Network Management Protocol) Agents. Closes: 156166 Changes: net-snmp (5.0.3-2) unstable; urgency=low . * Rebuild with perl 5.8. * Install additional UCD compatibility headers (closes: #156166). Files: 9dbc0751db7d1c5df7c3bb0f390072ed 58018 net optional snmpd_5.0.3-2_m68k.deb d6b696ed4bb143e00a1bcfbdacae0d2a 105508 net optional snmp_5.0.3-2_m68k.deb 0db8f0334643d7304c9edacb023a9ba0 923830 libs optional libsnmp5_5.0.3-2_m68k.deb 47899144f2f738058d0954411205d561 818582 devel optional libsnmp5-dev_5.0.3-2_m68k.deb a0e0361bf7f330d82eeed444c2482183 402602 interpreters optional libsnmp-perl_5.0.3-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9c5k3cS3JWD3FdvcRAp0yAJ9N2SLEZjBh3L892EwKXhIFze8qrgCdENbb c5kCun/aup9UfOBZ4lTypJI= =aycY -END PGP SIGNATURE-
Uploaded unac 1.7.0-1 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 12:59:11 +0200 Source: unac Binary: libunac1 libunac1-dev unaccent Architecture: m68k Version: 1.7.0-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Loic Dachary (OuoU) [EMAIL PROTECTED] Description: libunac1 - The unac programming library - runtime version. libunac1-dev - A C programmer's library that removes accents from a string. unaccent - Replace accented letters by their unaccented equivalent Changes: unac (1.7.0-1) unstable; urgency=low . * rules bugous install using prefix= instead of DESTDIR . * upgrade rules to DH_COMPAT=3 . * New upstream version Files: 205b5b6587c4e01a3d73f1baefa183f8 22122 libs optional libunac1_1.7.0-1_m68k.deb fd5e46c1b1c093015e64d396dae6594b 26368 devel optional libunac1-dev_1.7.0-1_m68k.deb d2e4e42c5a3a1ae791d0a7cd119fb99d 9372 utils optional unaccent_1.7.0-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9c5lDcS3JWD3FdvcRAokrAJ9QGC50UGYRYH2KexO5YTH3LXvezQCfW1ea TKdeUnn7yJGUwaoRbpWlbIA= =mw7I -END PGP SIGNATURE-
Uploaded gpgme 0.3.10-1 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 21:17:54 +0200 Source: gpgme Binary: libgpgme6 libgpgme-dev Architecture: m68k Version: 0.3.10-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Jose Carlos Garcia Sogo [EMAIL PROTECTED] Description: libgpgme-dev - GPGME - GnuPG Made Easy libgpgme6 - GPGME - GnuPG Made Easy Changes: gpgme (0.3.10-1) unstable; urgency=low . * New upstream version. Files: 55ac0b8b517ba22f33cf92c8736f 128648 devel optional libgpgme-dev_0.3.10-1_m68k.deb a21c1a50deb2577618321d129781127b 64738 libs optional libgpgme6_0.3.10-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9c+z2cS3JWD3FdvcRAj1JAKCAJzi2nIjOGwzTj/1WMxiPmK+r3QCfXa7X C6nwn3lucjF/32ND3Ig2rqY= =/KV+ -END PGP SIGNATURE-
Uploaded sawfish 1.1a-4 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 27 Aug 2002 18:29:14 +0200 Source: sawfish Binary: sawfish-gnome sawfish sawfish-lisp-source Architecture: m68k Version: 1:1.1a-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: sawfish- A window manager for X11. Closes: 150443 158488 Changes: sawfish (1:1.1a-4) unstable; urgency=low . * Add patch from Chris Boyle to support skip taskbar for G1 applications. (Closes: #150443) * Should depends on emacsen-common (Closes: #158488) Files: 4980272abde4d81a2ffb312f042b 1562404 x11 optional sawfish_1.1a-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9c+zpcS3JWD3FdvcRAogEAJ94VuwmFUJZID/g0U1rAPdzaA0k5wCbBUny 3VV64G4ubtgOCRtoe30jEnU= =4EUU -END PGP SIGNATURE-
Uploaded gtk-engines 0.12-8 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 11:28:43 -0600 Source: gtk-engines Binary: gtk-engines-metal gtk-engines-notif gtk-engines-raleigh gtk-engines-redmond95 gtk-engines-pixmap Architecture: m68k Version: 0.12-8 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Ed Boraas [EMAIL PROTECTED] Description: gtk-engines-metal - Metallic theme for GTK+ 1.2 gtk-engines-notif - Motif-like theme for GTK+ 1.2 gtk-engines-pixmap - Pixmap-based theme for GTK+ 1.2 gtk-engines-raleigh - GTK+ 2.0-like theme for GTK+ 1.2 gtk-engines-redmond95 - Windows-like theme for GTK+ 1.2 Changes: gtk-engines (0.12-8) unstable; urgency=low . * Rebuild against gdk-imlib1-dev (and, thus, libpng2) * Change Recommends: to Suggests: Files: 94fe9f4c055446b43bbdaea6556c012d 14584 graphics optional gtk-engines-notif_0.12-8_m68k.deb 47a8658de2d332e635c6ff857f94140f 15244 graphics optional gtk-engines-redmond95_0.12-8_m68k.deb 0bbff9620b2908e52ff74d9fb142b6ba 21508 graphics optional gtk-engines-metal_0.12-8_m68k.deb f4c0d7ea0c921df8e57f825ba15978e1 12978 graphics optional gtk-engines-raleigh_0.12-8_m68k.deb 147da41c3c6fe2fc6b810ec54d2924d1 477182 graphics optional gtk-engines-pixmap_0.12-8_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9c+zocS3JWD3FdvcRAjMRAJ4sOdHGT6Uqp58hyRnOABgsSI9bbgCaAkcC vjLCL67CtBawWV/MFy3i3hA= =OIlI -END PGP SIGNATURE-
Uploaded xmlto 0.0.10-3 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 10:13:07 -0400 Source: xmlto Binary: xmlto Architecture: m68k Version: 0.0.10-3 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: christophe barbe [EMAIL PROTECTED] Description: xmlto - XML-to-any converter Closes: 150067 Changes: xmlto (0.0.10-3) unstable; urgency=low . * Suggest passivetex which is now available in debian (closes: #150067). Files: 0d5b95dc29bd7c8290430756eac1c3d5 17570 text optional xmlto_0.0.10-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9c+zacS3JWD3FdvcRAv8lAJ9StxXAtEwyBAIvaVeMaWAYYuBLNQCfRm/S q8VMDsY6rXXD7H2nvYpnF5w= =62R1 -END PGP SIGNATURE-
Uploaded libsdl-sge 020104-3 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 19:30:50 +0200 Source: libsdl-sge Binary: libsdl-sge libsdl-sge-dev Architecture: m68k Version: 020104-3 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Julien Danjou [EMAIL PROTECTED] Description: libsdl-sge - Set of graphic functions that use SDL libsdl-sge-dev - Set of graphic functions that use SDL - development files Changes: libsdl-sge (020104-3) unstable; urgency=low . * Add -fPIC for compilation on hppa/ia64 Files: ddd42620a0d6aaffd5649a6ca01c12ba 57780 devel optional libsdl-sge-dev_020104-3_m68k.deb 352212d7bbd689fae88c7127fb89da94 45730 libs optional libsdl-sge_020104-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9c+z1cS3JWD3FdvcRAh9jAJ4rs02iEzo9qaT/wiba64UkrVPoYwCeIZTp MVAHwdggd0Swi8uufYmp0Fw= =E9Z2 -END PGP SIGNATURE-
Uploaded i2e 0.5-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 19:59:09 +0200 Source: i2e Binary: i2e Architecture: m68k Version: 0.5-4 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: i2e- English-Spanish translation dictionary. Closes: 126990 141949 141953 141954 Changes: i2e (0.5-4) unstable; urgency=low . * Fixed /usr/man to /usr/share/man (Closes: #126990) * Local manpage fixed (Closes: #141953) * No lintian errors (Closes: #141949, #141954) Files: 1e2f3ce52fffe69e722e1038569ee35d 211380 text optional i2e_0.5-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c/nfEycGpQPNsdIRAsv+AJ9nuqHBV7cZ7DB7xsjJs6Jf3ZbRdACdHbhD jmE4CRO2QbeciPADUD13+Nc= =or95 -END PGP SIGNATURE-
Uploaded nkf 1.92-8 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 17:44:06 +0900 Source: nkf Binary: nkf libnkf-perl Architecture: m68k Version: 1.92-8 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: NOKUBI Takatsugu [EMAIL PROTECTED] Description: libnkf-perl - Network Kanji code conversion Filter for Perl nkf- Network Kanji code conversion Filter Changes: nkf (1.92-8) unstable; urgency=low . * Rebuild with perl 5.8.0. Files: 9965043405f6da244f29f34be296353b 32496 text optional nkf_1.92-8_m68k.deb ee965c4405aa84ae93f07aa5a7fef8c8 15416 text optional libnkf-perl_1.92-8_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c/m1EycGpQPNsdIRAhoxAJwPGOyvrghb4+GyHT8by+5sCOmJKgCgiE5J eJTVfHJSH6/eI7bKpdk5ywo= =Zb1z -END PGP SIGNATURE-
Uploaded gs 7.05-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Sep 2002 01:10:37 +0200 Source: gs Binary: gs Architecture: m68k Version: 7.05-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Torsten Landschoff [EMAIL PROTECTED] Description: gs - The Ghostscript Postscript interpreter Changes: gs (7.05-1) unstable; urgency=low . * New upstream release. * debian/control: Use libpng3-dev instead libpng2-dev. Files: cb01b83d3b5e3517798e5dd01cb5f446 2844356 text optional gs_7.05-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c/moEycGpQPNsdIRAq8tAKCMuyjQIiflweSFQaYZEuYxJ98TUgCfaxP7 LDMjOgBkGZfkpIKI+QeyEMo= =el3q -END PGP SIGNATURE-
Uploaded deskmenu 1.4.0-2 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 19:15:53 +0200 Source: deskmenu Binary: deskmenu Architecture: m68k Version: 1.4.0-2 Distribution: unstable Urgency: high Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Stefan Pfetzing [EMAIL PROTECTED] Description: deskmenu - A root menu for X11 window managers Closes: 159230 Changes: deskmenu (1.4.0-2) unstable; urgency=high . * Updated the rc-example. * Updated the Build-depends. Closes: #159230 Files: e2936c3284d50428798c29dc88ee006a 15318 x11 optional deskmenu_1.4.0-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9dAQxcS3JWD3FdvcRAm4EAJ41GKOM+Rj6/yn2jimNma6+fIYSFQCggOlz Tnx+R4v2BP+SsEaeFdV6EnM= =zqvh -END PGP SIGNATURE-
Uploaded nessus-libraries 1.2.5-2 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 21:57:16 +0200 Source: nessus-libraries Binary: libnessus-dev libnessus1 Architecture: m68k Version: 1.2.5-2 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Josip Rodin [EMAIL PROTECTED] Description: libnessus-dev - Nessus static libraries and headers libnessus1 - Nessus shared libraries Closes: 159326 Changes: nessus-libraries (1.2.5-2) unstable; urgency=low . * libnessus-dev's includes.h includes openssl headers, so it has to depend on libssl-dev, thanks to James Troup for noticing, closes: #159326. Perhaps the OpenSSL dependency should be removed from the header file instead, but the upstream likes it better this way. * Reworked the remaining libpcap-nessus exclusion patches. Files: baa25263a368ecf6ae9ef83db9555399 44120 libs optional libnessus1_1.2.5-2_m68k.deb 0e1f95683b1346fb1c098bc95ef6f8db 60906 devel optional libnessus-dev_1.2.5-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9dAQZcS3JWD3FdvcRAnHfAJ9dkjkOscjMblKkwjtBnv79K0KACwCggKp0 D6fyZnojDMsMQFbyKsHpiQE= =4XZ3 -END PGP SIGNATURE-
Uploaded airsnort 0.2.1b-2 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 19:38:00 +0200 Source: airsnort Binary: airsnort Architecture: m68k Version: 0.2.1b-2 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Noel Koethe [EMAIL PROTECTED] Description: airsnort - WLAN sniffer Closes: 157216 Changes: airsnort (0.2.1b-2) unstable; urgency=low . * added patch from Lukas Geyer [EMAIL PROTECTED] from BTS (thanks for your help!) * Added build-dependence on libpcap-dev * src/decrypt.c: Added definition of DLT_PRISM_HEADER * Made configure executable (closes: Bug#157216) Files: 5bb010fb925b43d3cb2c11a86f8ea53a 38456 net optional airsnort_0.2.1b-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9dAQncS3JWD3FdvcRAiXnAJ4hMvoOAWfjI4oMBsxShTgz5OUvSACffrmc m9D2jSWTBYOQYgKnvHP4D90= =0ktF -END PGP SIGNATURE-
Uploaded libberkeleydb-perl 0.19-2.1 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 20:54:28 + Source: libberkeleydb-perl Binary: libberkeleydb-perl Architecture: m68k Version: 0.19-2.1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Bas Zoetekouw [EMAIL PROTECTED] Description: libberkeleydb-perl - Use Berkeley DB 3 databases from Perl Changes: libberkeleydb-perl (0.19-2.1) unstable; urgency=low . * Non-maintainer upload (BSP) * Rebuilt against perl 5.8 Files: e0557610b72c09d8bb75479cc80a30e3 107722 text optional libberkeleydb-perl_0.19-2.1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9dAQecS3JWD3FdvcRAlt8AJ4tGBZOAs5if3A9C+I1mWNScCEamQCfbCEJ 9M3XCYx1XDZwcbPs05LZ9K4= =+Ye0 -END PGP SIGNATURE-
Uploaded ethereal 0.9.6-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Sep 2002 10:13:06 +0200 Source: ethereal Binary: ethereal ethereal-dev tethereal ethereal-common Architecture: m68k Version: 0.9.6-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Frederic Peters [EMAIL PROTECTED] Description: ethereal - Network traffic analyzer ethereal-common - Network traffic analyser (common files) ethereal-dev - Network traffic analyser (development tools) tethereal - Network traffic analyzer (console) Closes: 158808 158909 Changes: ethereal (0.9.6-1) unstable; urgency=low . * New upstream release. * Fixes security issue in the ISIS protocol dissector (susceptible to buffer overflow). (see http://www.ethereal.com/appnotes/enpa-sa-6.html) * Add missing header files (packet-tcp.h and packet-tpkt.h) to ethereal-dev (closes: #158808) * Add default PYTHONPATH to idl2eth (closes: #158909) Files: 6aca7603009b9ea801f6975b33501c66 277328 net optional ethereal-common_0.9.6-1_m68k.deb 59a3098d9c5633af98ffac1057cba74b 1493352 net optional ethereal_0.9.6-1_m68k.deb f8032682dc30bc27eca84b60ad786463 1317004 net optional tethereal_0.9.6-1_m68k.deb 09aff44a8e92fbc3b6abee146d00fcfa 147300 devel optional ethereal-dev_0.9.6-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9c/m8EycGpQPNsdIRAkQzAKCFSZgE4XqPsxSaCMXH3eiGmh3yHgCeIECN Obl3cNu0xhk0SzLVZKUCNm4= =l1SB -END PGP SIGNATURE-
Packages affected by removal of free mp3 players
If the worst does happen, and we need to remove all mp3 players from Debian, many packages will be affected. Most of these are because of their dependency on libsmpeg, which is the SDL MPEG audio and video decoder. Others depend on other MP3-playing libraries, such as libmad, mpeglib (which is named oddly), etc. (Please let me know if I've forgotten some.) A few packages depend on mpg321 as well - mostly front-ends. Some notable packages affected are pygame (affects pyddr, for those unfortunate few who cannot attend the 12-step meetings), alsaplayer, GAnSO, ogle, and many others. One of the main culprits is libsdl-mixer1.2, I think: this causes many (most?) SDL games, including frozen-bubble, to be affected by the removal of libsmpeg0. I don't know if libsdl-mixer can be compiled without smpeg support, though, or what this would mean for users of libsdl-mixer1.2. In the very worst case, we may be able to get a new upstream version of libsdl-mixer released which supports only Vorbis. For those which depend on pure mp3 playing libraries such as libmad, we may be SOL - especially in the case of programs which require the ability to decode MPEG 1 layer 3, like ogle. Suggestions are welcome. Attached are the lists of reverse dependencies for the packages I could think of. -- Joe Drew [EMAIL PROTECTED] [EMAIL PROTECTED] This particular group of cats is mostly self-herding. -- Bdale Garbee alsaplayer alsaplayer-alsa alsaplayer-common alsaplayer-esd alsaplayer-gtk alsaplayer-jack alsaplayer-nas alsaplayer-oss alsaplayer-text audacity avifile-mad-plugin dvb-zapping gqmpeg gstreamer-mad gstreamer-plugins irmp3 kreatecd libmad0 libmad0-dev madplay mp3burn mpg123-el mpg321 mq3 mserv nautilus1.1-suggested ogle ogle-gui ogle-mmx playmp3list simplecdrx vlc-mad artsbuilder brahms kdemultimedia-dev libarts-mpeglib mpeglib noatun noatun-plugins rosegarden4 black-box bugsquish bumprace castle-combat chromium circuslinux crimson criticalmass csmash csmash-demosong defendguin enigma frozen-bubble ganso gemdropx gl-117 gltron gnome-office heroes-common heroes-ggi heroes-sdl icebreaker jumpnbump jumpnbump-levels junior-arcade junior-art junior-games-gl junior-puzzle junior-typing ksmp3play lbreakout2 lgeneral libopenal0 libopenal-dev libsdl-mixer1.2 libsdl-mixer1.2-dev libsdl-ocaml libsdl-ocaml-dev libsdl-perl libsdl-ruby libsmpeg0 libsmpeg-dev ltris madbomber mangoquest mirrormagic moon-lander penguin-command prboom pygame pysol-sound-server python2.1-pygame python2.2-pygame python-pygame rockdodger rocks-n-diamonds smpeg-gtv smpeg-plaympeg smpeg-xmms solarwolf toppler tuxpaint tuxracer tuxtype vectoroids vegastrike
Re: Improper NMU (Re: NMU for libquota-perl)
On Mon, Sep 02, 2002 at 02:25:30AM +0100, Colin Watson wrote: On Sun, Sep 01, 2002 at 09:19:17PM -0400, Elie Rosenblum wrote: On Mon, Sep 02, 2002 at 02:16:11AM +0100, Colin Watson wrote: Technically it wasn't. The upload is still in the DELAYED queue, which is really just a convenient automated way of saying I'll NMU this package in n days if I don't hear anything, with the added bonus of allowing the maintainer to poke at it and see exactly what would go in in the absence of a maintainer upload. I usually explain this when using the delayed queue. I assume you also submit a bug. Quite. Would you agree that performing an NMU without a BTS entry is wrong? Do you generally do this without leaving a bug for a few days first? In the case of the perl transition I've been given to understand by the actions of other developers that the -devel-announce post on 31st July was enough. Otherwise no. I see. Well, I disagree with this (as do I believe some others), but only in that no NMU should be done until the bug has existed for a few days (if nothing else, this addresses the distinct possibility of NMUs actually breaking stuff, which has already been brought up in this thread). I'm probably not going to convince you of this, any more than you will convince me that I'm wrong here. I have not, however, been hit with this general case...I've been hit with an irresponsible maintainer performing an NMU without submitting a bug at all, even if it was 5 minutes before he uploaded. This is just plain wrong, and something that can cause us really serious problems if people start to imagine that it's acceptable - especially since we have little control over which keys can successfully upload any given package. -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_
Application for Employment / Contract Work
*** Please Note: Do Not Use your Reply button if you wish to respond to this email *** *** Please reply to [EMAIL PROTECTED] *** Hello, I came across your website, and thought I would send you a copy of my CV / Resume (please scroll down the page) to see if you are in need of any help in promoting your site with regards to Search Engines or if your company requires any Accounting help. I am currently living in Thailand and would like to assist you in any way I can. Please contact me 015151302 or on [EMAIL PROTECTED] and we can discuss your immediate needs. Thank you and have a nice day. Tony Heller -- Finance Manager / Accounting Consultant / LAN Administrator My name is Tony Heller and I am a 33-year-old Canadian male, presently living in Jomtien, Thailand. I am seeking employment as a Finance Manager or for contract work as an Independent Consultant for a company based in South East Asia. I am willing to re-locate anywhere in Thailand and would also consider a position in another South East Asian country. I recently moved to Thailand, largely as a result of September 11th, after eight years of living and working in Indonesia. (I worked for four years in Jakarta and another four in Bali.) I can speak Bahasa Indonesia (Indonesian language) fluently. I am a Certified General Accountant and have a Finance Degree from the British Columbia Institute of Technology located in Vancouver, B.C. Canada. I have held positions as both Finance Manager and Computer Consultant for several large companies in Asia. My primary roles have been consolidating accounting data and organizing that data into clear and precise Financial Statements that Managers, Directors and Owners can clearly understand. My past 3 years were spent building Bali System Development, a computer software company that focuses on writing software databases, multi media presentations and general LAN support issues. As an owner of that company with 30 programming staff, I have a great deal of experience with regard to most computerized accounting methods and solutions. I have especially worked extensively with ACCPAC, MYOB and Peachtree. Personal Information My Background I lived with my family in West Vancouver, B.C. Canada until I attended University. I was actively involved in many sports and excelled at soccer and gymnastics during my younger years. After high school, I worked on a kibbutz in Israel for 6 months and then backpacked through most of Asia, the Middle East and Europe. Upon my return to Vancouver in 1987, I enrolled, and completed my degree in the Finance Management program at The British Columbia Institute of Technology (B.C.I.T). After graduating, I enrolled in the final two-year program of the Certified General Accountants of Canada at night, and worked for Azcom Information Systems in Vancouver as a Network Engineer during the day. After passing the Certified Network Engineer Program, also at B.C.I.T., I was promoted to the role as LAN Administrator of the British Columbia Medical Association and was in charge of more than 400 personal computers running on a Novell network. In 1994, I decided to take my skills and expertise to Asia, and seek employment. I moved to Jakarta, Indonesia and started consulting for companies, generally helping them computerize their accounting systems, troubleshooting various LAN problems, and assisting in any Internet (Website) assistance required. In 1997 I left Jakarta to take on the position of Finance Manager for the Bali Golf and Country Club. I worked there for 1 1/2 years and decided to leave the position and open my own company. Bali didn't have any professional computer companies, at that time, so I opened Bali System Development. (BSD) BSD grew from 4 programmers to 30 in two years. (Our clientele included more than 75 companies and individuals. Business was very good until September 11th. In November 2001, I moved my family to Pattaya, Thailand. BSD is still a functional company with 15 programmers and is currently being run by my partner. I, however, am now a silent partner and am seeking employment as either a Finance Manager or Accounting Consultant in South East Asia. I would also consider the position as a LAN Administrator or any position that utilizes my skills and expertise. I am willing to re-locate if necessary, on either a salaried or hourly contract work basis. I can utilize the programmers at Bali System Development to help with any necessary programming that may be required. If you have any further questions regarding my background, please email me. Education I spent my teenage years studying at Hillside Secondary School in West Vancouver, B.C. Canada. Shortly after graduation, in 1986, I attended The British Columbia Institute of Technology in Burnaby,
Re: Please compile treetool on alpha, arm, hppa, ia64, powerpc and s390
On Fri, 30 Aug 2002, Branden Robinson wrote: Okay. What you have is a license, then; it's just a very informal one. Email from a person granting you permission to do things not ordinarily permitted by copyright law is a license, when that person has appropriate legal standing to grant such permission. Such communications are just as valid as the GNU GPL or BSD licenses, if less formal. Well but it avoids §8 of DFSG and what I intended to say was there is no license for upstream source - and that's really a pitty in this case because this program which is obviousely used by a lot of biologists needs some work and nobody can do it because of the missinging upstream license. Kind regards Andreas.
Re: woody CD not bootable with adaptec + scsi-cdrom
Richard Atterer [EMAIL PROTECTED] writes: So the final solution was to use multiboot only on the first CD, the other CDs use the same method as potato. The few machines on which it fails are either old or have a SCSI CD-ROM, booting from one of the later CDs should work for them. AFAIK if the woody release multiboot CD fails, it even prints a message which tells you to do that. Haven't seen that. But maybe that wasn't ready or not included on the Linuxtag CDs. They are pre stable. MfG Goswin PS: I will see if I can get a real woody to test this. Don't want to waste the traffic though.
Re: woody CD not bootable with adaptec + scsi-cdrom
Andreas Metzler [EMAIL PROTECTED] writes: Disclaimer: Because I do not work on the debian-cd, bf or installer and do not follow the mailing lists regularily, I do not know much about this issue and there are probably lots of errors in this mail. Goswin Brederlow [EMAIL PROTECTED] wrote: I just crasht my system working on libsafe and hat to boot from CD. I the discovered that the woody CD (linuxtag prerelease) doesn't boot. I heard of similar for the real woody release CDs on irc. Can anyone boot the CDs, which one of the set and what hardware? Same if you can't boot. Hello, Lots of people can, the official CD-image _were_ tested. - I think the linuxtag prerelease CD is similar to the official CD1. I can boot from CD1, on a PentiumMMX-class machine (SiS 5591/5), an iirc 1 year old Athlon 800 (VIA 133) and a 2 month old Duron1200 (VIA 266A). Who cares about your cpu? What cdrom? ide or scsi? What controler? Also whats different between potato and woody? potato used floppy-emulation, woody _CD1_ uses isolinux(??). That explains the difference in output. The floppy emulation shows up when the adaptec detects the bootable cdrom. Or is that unrelated? potato has this multiboot thing and woody not anymore, right? What was wrong with it? Seems to be more compatible the old way. It is not, search the Debian-CD mailing-list. IIRC: Basically Microsoft switched the CD-boot method they used for their OS CDs, the BIOS manufacturers followed suit and dropped support for or did not fix bugs in the old method and added support for the new method. For maximum compatibility with old computers you need floppy-emulation, for new computers you need the new method. BTW RedHat et al. don't use floppy-emulation, too. If your computer cannot boot woody CD1 try CD2-CD7 - they use floppy-emulation and should work on old computers. Good to know. Is that in the install docs somewhere? MfG Goswin
Re: Improper NMU (Re: NMU for libquota-perl)
Hi Elie! You wrote: The NMU was made before I was in any way contacted. That's exactly why it was uploaded to DELAYED instead of incoming. I don't think anyone is arguing that the fix isn't needed; I don't, however, appreciate being treated like an MIA maintainer and having If so, why didn't you upgrade the package before? There has been ample warning about the perl 5.8 transition and the BSP. my responsibilities coopted. There is no urgency that requires an NMU if it's not important enough to file a bug. Oh, I could very well have filed a grave bug along with the NMU. I just found it more convenient to mail the maintainer directly. I agree with you that the guidelines state that this communication should be done via the BTS (I wasn't aware of that, and I will do that in the future), but I find this a minor issue, because it wouldn't have changed anything. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| | [EMAIL PROTECTED] | Pablo Picasso | +---+
Re: The harden-*flaws packages.
Hi Thanks for the arguing. On Sun, Sep 01, 2002 at 09:22:56PM -0400, Daniel Martin wrote: Martin Schulze [EMAIL PROTECTED] writes: Please see the thread summarized in http://www.debian.org/News/weekly/2002/29/: Policy for Woody Point-Releases. [4]Several [5]developers [6]would [7]like to add new packages and updates to their packages to the recently released stable distribution of Debian. Adding new packages and random updates to the stable distribution, however, would nullify the entire idea of having a stable release, Joey [8]explained. Hence, the same policy as before will be used for point-releases of woody. Yes, but how does this apply to a package that does nothing but conflict with existing packages? (As is the case with most of the harden-* packages) Agreed, _random_ updates would be a bad thing. However, what the maintainer is proposing here is updates that are driven by DSAs. Although I find it a slight stretch, one could easily argue that the updates to the harden-*flaws packages are security updates. These updates share another feature with security updates. Imagine the package netostrich, which helps you bury your head in the sand remotely. Now, suppose the upstream authors discover a flaw in the 2.0 series of netostrich prior to version 2.33 which allows random network users to bury other people's heads in the sand. Sarge soon contains 2.34 with the security fix, yet woody contains 2.29.1 with a backported fix. Then there would similarly need to be two harden-remoteflaws; one for woody, which conflicts with netostrich prior to 2.29.1, and one for sarge, which conflicts with netostrich prior to 2.34. The harden-*flaws update has to be backported along with the backported fix to netostrich. Now, if we want the harden-remoteflaws package to be at all useful, it needs to be updated along with DSAs... Yes. Luckily I just saw someone that have written a script that checks the DSA:s and tell the maintainer that he/she has a vulnerable package. That is a good solution (best?). The problem is that the DSA is not able to distinguish between local/remote/3rdparty flaws but that is not always interesting. Hrm. The more I think about this the more I wonder if maybe the harden-*flaws packages make much sense in stable at all. If someone is apt-get'ing from security.debian.org, they're already replacing vulnerable versions with fixed ones. If someone is updating from a point release CD, the same thing applies. The only case where I can see it making sense is with someone following testing with most of their packages on hold (they really want a stable system, and only upgrade a package when they need to). Am I missing a scenario? Yes. When you have a lot of own-compiled debs in an other archive which can be more or less stable. So my suggestion (which it probably will be) is that the harden-*flaws package either contain that (or such a) script or depend on it. Maybe I will merge the *flaws into a flaws package. Regards, // Ola -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Security notification script
Hi again, I'm I right when I say that this script only can follow the DSA:s that cover woody? It is nice but I would really like a version that can handle sid too. :) It would be some more text processing but I think it is doable. Do you want me to make a dependency/recommend from harden-*flaws to this package? Regards, // Ola On Fri, Aug 30, 2002 at 01:13:18PM +0200, Ola Lundqvist wrote: On Mon, Aug 26, 2002 at 09:31:34PM +0100, Rob Bradford wrote: I have written a python script that allows you to compares locally installed packages with those on security.debian.org. Furthermore it provides a description of the problem/DSA name if the package is mentioned in the DSA RDF. That looks really interesting for the harden packages. Especially for the harden-*flaws packages. It is probably a better approach than uploading new harden-fooflaws everytime. Is it possible for your script to differentiate between local and remote flaws? The script is intended to be run as a normal user in a crontab, and thus produces no output if the system is completely upto date. You will need to install python2.2 and python2.2-xml prior to using the script which can be found at http://www.robster.org.uk/files/security-update-check.py Any feedbacl/ideas would be much appreciated. I plan to make some minor changes and package this up later this week :) Maybe you want to have it in the harden-*flaws package or simply make these depend on your package. The later is maybe better. Regards, // Ola Cheers Rob -- Rob 'robster' Bradford Founder: http://www.debianplanet.org/ Developer: http://www.debian.org/ Monkey with keyboard: http://www.robster.org.uk/ -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Improper NMU (Re: NMU for libquota-perl)
Elie Rosenblum [EMAIL PROTECTED] writes: On Mon, Sep 02, 2002 at 02:25:30AM +0100, Colin Watson wrote: On Sun, Sep 01, 2002 at 09:19:17PM -0400, Elie Rosenblum wrote: On Mon, Sep 02, 2002 at 02:16:11AM +0100, Colin Watson wrote: Technically it wasn't. The upload is still in the DELAYED queue, which is really just a convenient automated way of saying I'll NMU this package in n days if I don't hear anything, with the added bonus of allowing the maintainer to poke at it and see exactly what would go in in the absence of a maintainer upload. I usually explain this when using the delayed queue. I assume you also submit a bug. Quite. Would you agree that performing an NMU without a BTS entry is wrong? Do you generally do this without leaving a bug for a few days first? In the case of the perl transition I've been given to understand by the actions of other developers that the -devel-announce post on 31st July was enough. Otherwise no. I see. Well, I disagree with this (as do I believe some others), but only in that no NMU should be done until the bug has existed for a few days (if nothing else, this addresses the distinct possibility of NMUs actually breaking stuff, which has already been brought up in this thread). I'm probably not going to convince you of this, any The Bug existet since 31st July even if it wasn't formaly in the BTS against your package. more than you will convince me that I'm wrong here. I have not, however, been hit with this general case...I've been hit with an irresponsible maintainer performing an NMU without submitting a bug at all, even if it was 5 minutes before he uploaded. This is just plain wrong, and something that can cause us really serious problems if people start to imagine that it's acceptable - especially since we have little control over which keys can successfully upload any given package. In the case of something so trivial as causing a recompile for a problem that has been known for some time the warning given by the delayed upload should be enough. Do we realy need to mass-file bugreports for this? Thats the alternative to mentioning something like the perl transition on -devel and then fix it in a group effort some time afterwards. You might have a point in general but not in this case. Just my 2c of though, don't blame anyone else. Goswin
Re: The harden-*flaws packages.
Daniel Martin [EMAIL PROTECTED] writes: Martin Schulze [EMAIL PROTECTED] writes: Hrm. The more I think about this the more I wonder if maybe the harden-*flaws packages make much sense in stable at all. If someone is apt-get'ing from security.debian.org, they're already replacing vulnerable versions with fixed ones. If someone is updating from a point release CD, the same thing applies. The only case where I can see it making sense is with someone following testing with most of their packages on hold (they really want a stable system, and only upgrade a package when they need to). Am I missing a scenario? They should have stable as their distribution with highest priority for apt. That includes security for stable. On top of that the few packages they want more current can be installed from woody or sid. No need to keep everything else on hold, making stable first priority for apt should be enough. And then they would get security updates. MfG Goswin
Re: Packages affected by removal of free mp3 players
Joe Drew [EMAIL PROTECTED] writes: If the worst does happen, and we need to remove all mp3 players from Debian, many packages will be affected. Most of these are because of Why no non-free versions? their dependency on libsmpeg, which is the SDL MPEG audio and video decoder. Others depend on other MP3-playing libraries, such as libmad, mpeglib (which is named oddly), etc. (Please let me know if I've forgotten some.) A few packages depend on mpg321 as well - mostly front-ends. un versions or dummy versions could be provided to make the software work but not the mp3 features. Would be quite stupid for mpg321 but for ogg it would make sense. People could then get a real mp3lib from non-free or somewhere else and replace the un version with that without recompile of the debs. MfG Goswin
Bug#159271: ITP: ogmtools -- Tools for handling Ogg media streams
Package: wnpp Version: N/A; reported 2002-09-02 Severity: wishlist * Package name: ogmtools Version : 0.901 Upstream Author : Moritz Bunkus [EMAIL PROTECTED] * URL : http://www.bunkus.org/videotools/ogmtools/ * License : GPL, LGPL, BSD, MIT/X, etc. Description : Tools for handling Ogg media streams These tools allow information about (ogminfo) or extraction from (ogmdemux) or creation of (ogmmerge) OGG media streams. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux mykene 2.4.19-xfs #1 Mon Aug 26 14:55:46 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=C
Re: Java policy
Hi again. I have not seen very much complains on the policy. Actually none on fact. So what further steps should I take in order to make this an official policy? On Sat, Aug 31, 2002 at 01:56:15PM +0200, Robert Bihlmeyer wrote: Ola Lundqvist [EMAIL PROTECTED] writes: There are some things that might want to be added before it becomes truly official. See the policy at: http://www.debian.org/doc/packaging-manuals/java-policy/ * gcj and how to handle that (should it be mentioned at all?). I don't have the specifics to that handy. URL? Somewhere in the [EMAIL PROTECTED] archives, do not remember. * should all virtual machines that provides a java2 virtual machine also provide a 'java2' command (not 'java'). As the originator of this request, I'd be happy to have an official version without this and punt this to the next version. Ok. * How to handle jar dependencies? Should there be some kind of mechanism for that? Since nobody is currently on top of that, I'd suggest leaving it out, too. Agreed. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: woody CD not bootable with adaptec + scsi-cdrom
Goswin Brederlow [EMAIL PROTECTED] wrote: Andreas Metzler [EMAIL PROTECTED] writes: [...] Goswin Brederlow [EMAIL PROTECTED] wrote: [...] I the discovered that the woody CD (linuxtag prerelease) doesn't boot. I heard of similar for the real woody release CDs on irc. Can anyone boot the CDs, which one of the set and what hardware? [...] I can boot from CD1, on a PentiumMMX-class machine (SiS 5591/5), an iirc 1 year old Athlon 800 (VIA 133) and a 2 month old Duron1200 (VIA 266A). Who cares about your cpu? Hello, Nobody does, but mentioning CPU and mainboard chipset should give a good idea how old the system was. (I do not know the exact dates, else I would have mentioned them.) What cdrom? ide or scsi? What controler? Sorry, all machines were IDE only. Also whats different between potato and woody? potato used floppy-emulation, woody _CD1_ uses isolinux(??). That explains the difference in output. The floppy emulation shows up when the adaptec detects the bootable cdrom. Or is that unrelated? Afaik no, my old computer's BIOS showed too whether it was using floppy emulation. [...] If your computer cannot boot woody CD1 try CD2-CD7 - they use floppy-emulation and should work on old computers. Good to know. Is that in the install docs somewhere? Of course. | 5.2 Booting from a CD-ROM [...] | CD #1 [...] | If your hardware doesn't support booting of multiple images, put | one of the other CDs in the drive. It appears that most SCSI CD-ROM | drives do not support isolinux multiple image booting, so users | with SCSI CD-ROMs should try either CD2 (vanilla) or CD3 (compact), | or CD5 (bf2.4). BTW it'd be nice if could respect Mail-Followup-To and did not cc me, I would be very surprised if your MUA Gnus did not support this. TIA, cu andreas -- Unofficial _Debian-packages_ of latest _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
[PHP] Standard placement of PHP libraries?
I guess this is probably going to turn into a mini-policy discussion, and I
hope so, because I think we need some level of standardisation.
There are several PHP extension libraries packaged for Debian; I guess the
most famous is probably pear, but I maintain one (phtml, used by some other
packages I maintain) and I know there are a couple of others out there, too.
By these libraries I'm not talking about binary modules, I'm talking about
extension libraries written in PHP and available by include('whatever').
It's the 'whatever' that I'm mostly interested in discussing for now.
PEAR uses /usr/share/pear, and has an entry in include_path for it. Hence,
to use any PEAR-shipped function, simply refer to the file by name, relative
to that directory. Nice, very simple, I highly approve. Since PEAR holds a
special status, perhaps that should change.
But what about every other PHP extension library out there? libphp-adodb,
for instance, uses /usr/lib/adodb - in violation of the FHS, I believe,
since PHP scripts shouldn't be architecture specific. But that's not really
the issue here - the point is, where *should* PHP includes go?
I would like to propose /usr/share/php4 as the place for all scripts
intended to run under php4 (whatever subversion) and intended for inclusion
in other PHP scripts. All packages would install their inclusion hierarchy
under /usr/share/php4/package name, and scripts which wanted to use their
functionality would include('package name/include.php'). Naming of
include files, including their extension, would be left to the discretion of
individual maintainers.
The bonus would be that the php4 maintainer would only have to add one
(fairly self-explanatory) directory entry to php4.ini for all time, no other
package would have to worry about modifying php4.ini or getting the user to
do so (BTDT, not much fun).
I can't see any real downsides, as long as everybody plays along. I'd like
to know of any that anyone can think of. If there are no objections, and
anyone else thinks it's a worthwhile idea, I'll put my thoughts into a
formal proposal to Policy, for official comment. I'd rather get shot down
in flames now than get my hopes up.
--
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org
Re: Improper NMU (Re: NMU for libquota-perl)
On Sun, Sep 01, 2002 at 09:06:20PM -0400, Elie Rosenblum wrote: The NMU was made before I was in any way contacted. Would you please stop bitching, you're getting on my nerves. Except you nearly nobody sees this as a problem. If you're not able to maintain your packages properly and in a timely manner, and your holding up a major part of the distribution, it's your fault. The was no harm done, it was pointed out several times how you can prevent the NMU'ed package from entering unstable, so you have absolutely no point. Remember: You're just the package maintainer. The package does not belong to you and it's not yours by any means. - Sebastian
[PHP] Placement of PHP programs?
As a kind of an adjunct to the other discussion on PHP libraries, what about PHP programs? Not quite so touchy, as I can't see a single way forward here (and there's no blazingly obvious reason to do so). So what are people's best thoughts on the matter? Most packages I've seen put their web-accessible content in /usr/share/package, then either set up a separate apache config and include it from the main apache config (phpgroupware does it this way, for one example) while other packages modify apache.conf more intrusively. I'm a fan of the phpgroupware method, which at least minimises pain. So where to put the program itself? /usr/share is the common place, I guess that's the place to go. Does anyone think there's another good place, and has a reason for it? Config should, of course, go in /etc/packagename, including (if appropriate) the apache config to allow apache to find it. But what if people are using a different Web server? It's possible, so why are we blindly assuming apache? Should we cater for the default, and anyone doing differently should know enough to fix the problem themselves? That's a possibility. And what about where in the docroot we put our program for accessability? Right in the docroot might squash something already there. How about letting the user choose? Ooh, there's something that could start a hornet's nest. Check if something's already there - but how do we do that? ls /var/www/packagename *might* work, grep '/packagename' /etc/apache/*.conf would help too. We'd probably find most cases between those two checks. Anyway, I want to know your thoughts. Please share. -- Matthew Palmer, Debian Developer [EMAIL PROTECTED] http://www.debian.org
RFC: A regression test framework for Debian packages?
One year ago, Martin Michlmayr made a speach at the Debian Conference 1 about Quality Assurance within Debian and the progress that have been made so far. He mentioned that we lack regression tests for packages, but as far as I know, no solution has been found. What are regression tests? -- Regression tests are tests that are made to ensure that the behaviour of a given program has not changed across releases. Why? Currently, we have some way to check a package before it gets installed. That is what Lintian (and Linda as well ;-) is here for: checks are performed on the content of the binary and source package. However, we have no way to check a package after its installation. And in most of the cases, Lintian checks cannot prevent software breakages. Until now, developers need to test packages manually: installation, upgrade, removal, purge, failures and so on. This can be very painful and boring when you have different ways to configure your packages, especially when they have to be configured through debconf. Furthermore, some packages may perform some complex tasks like database creation/upgrades, web server configuration, mail aliases management, etc and user configuration and environment may vary, making the success of such tasks unpredictable. What? - The main idea is to make tests on package installation and after their installation is completed. Here is a list of possible tests that come to my mind (in no special order): - tests on maintainer scripts: maintainer scripts perform some very simple tasks like: changing ownerships and permissions, starting daemons, creating users/groups, etc. They are likely to change across releases, and as they are mostly written in shell, they are error prone. This could be as complex as checking that a database has been properly configured, that a LDAP directory has been properly populated, that a web server has been correctly modified. - debconf tests: there are usually many possible answer to debconf question and different paths within. Some tests can be written to simulate user interaction, providing a broader set of configuration answer. Checks would be made with respect to some given answers. - configuration files tests: some behaviours may vary with respect to configuration options. Tests would provide a set of configuration files and their matching expected behaviour. - application-specific tests: sometimes Debian customize applications and we may want to see if nothing has been broken. - ... How? In a chrooted environment, we can install deboostrap and package dependencies through APT. Then, we need some program that would execute some simple scripts in a pseudo language (for safety purpose, tests must be error prone as much as possible) describing what tests have to be performed, and how they would be performed. This is only a short summary :-) Do we need this? - Although this may look boring for small packages, I have many reasons to think that this can be usefull for complex packages. We can imagine running such test overnight for packages maintained via CVS. Comments are welcome. Thanks. Cheers, PS: Please, no CC on reply, I'm subscribed to the list. -- Jérôme Marant
Re: Improper NMU (Re: NMU for libquota-perl)
On Mon, 2 Sep 2002, Sebastian Rittau wrote: Remember: You're just the package maintainer. The package does not belong to you and it's not yours by any means. Oh, I think you are very mistaken. It is not his in the sense that it's under GPL. But it's his in the sense that since he is its official maintainer others should respect that. And as is the case in the GPL world - everybody is free to fork his package and maintain his own, if he thinks some maintainer is not doing his work or refusing to let someone else do it in a better way. This being said I'm not refering here to the quality of anybody's work nor to what has been discussed in this thread here - just to the basic principle. *t -- --- Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11 ---
Re: Improper NMU (Re: NMU for libquota-perl)
Le Mon, Sep 02, 2002 at 12:20:22AM -0400, Elie Rosenblum écrivait: Would you agree that performing an NMU without a BTS entry is wrong? Nope. The strict minimum is : - create a patch for the NMU - make the patch available to the maintainer (via direct mail or bts) If you upload the package to DELAYED, it is enough to respect the spirit of the NMUs guidelines (which are in developers-reference). BTW, the developers-reference evolved quite a bit since the good old days, and the DELAYED stuff is mentionned in the NMU guidelines... please read it again. http://www.debian.org/doc/manuals/developers-reference/index.en.html I've been hit with an irresponsible maintainer performing an NMU without submitting a bug at all, even if it was 5 minutes before he uploaded. This is ridiculous. An NMU is not a punishment for bad maintainers, it's an offer of help to help you catch up in your Debian work. No one should be offended by an NMU. especially since we have little control over which keys can successfully upload any given package. You want respect for yourself, you don't want to be treated like an irresponsible maintainer, but you show absolutely no respect to people who are doing NMUs to help you. Think about it, people doing NMUs are other Debian developers like you who take their free time to help you, and look how you thank them. Even if he made a mistake, it's not a big one, the upload was to DELAYED, the package has not yet been installed, you have a chance to dump the NMU by uploading your own fix. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com
Re: Improper NMU (Re: NMU for libquota-perl)
On Mon, 2 Sep 2002, Sebastian Rittau wrote: If you're not able to maintain your packages properly and in a timely manner, and your holding up a major part of the distribution, it's your fault. I'm interested in this. Individuals differ greatly in their working methods. So what is considered: in a timely manner? (Seriously.) I have dropped out of several co-operative projects in the past simply because I'm a relatively slow worker -- i.e. I don't tend to give three or four fast responses to collective development _in the same day_. I find that sort of speed of progression highly de-motivating. Am I alone in this? (I might take up to a week to respond to any particular event -- this is normal for _me_.) I'm curious as to what the expectations of other debian-developers are -- for example, does not being online 24/7 -- or even once a day -- effectively create a barrier to participation in collective development projects in debian? (Theory would say: No. But what does _practical_ experience dictate?) So I guess my question really is: what is timely; and what is untimely? Where is it defined? By whom? Does it make sense? Just curious. msw -- Martin Wheeler -StarTEXT - Glastonbury - BA6 9PH - England [EMAIL PROTECTED]http://startext.demon.co.uk/ GPG pub key:8D6B948B ECC6 D98E 4CC8 60E3 7E32 D594 BB27 3368 8D6B 948B - Share your knowledge. It's a way of achieving immortality. -
Re: Improper NMU (Re: NMU for libquota-perl)
On Mon, 2 Sep 2002, Raphael Hertzog wrote: This is ridiculous. An NMU is not a punishment for bad maintainers, it's an offer of help to help you catch up in your Debian work. No one should be offended by an NMU. ... and might I add, that in the case of documentation, it should be actively sought after? (From each and every reader?) That is, insofar as text presentation (grammar; syntax; orthography; punctuation; etc.) is concerned; factual content of the text should be subject to discussion with the author[s] of the documentation. Although when information given is plain wrong, or out of date, I'm all in favour of instantaneous amendment by the reader without reference to the author. (I speak in knowledge of cause; I'm guilty of not updating out-of-date information myself in most documents I maintain.) In this respect, maintainership of documentation is vastly different to maintainership of code; but the basic principle of intervention to *help* (and not obliquely castigate), holds true. msw -- Martin Wheeler -StarTEXT - Glastonbury - BA6 9PH - England [EMAIL PROTECTED]http://startext.demon.co.uk/ GPG pub key:8D6B948B ECC6 D98E 4CC8 60E3 7E32 D594 BB27 3368 8D6B 948B - Share your knowledge. It's a way of achieving immortality. -
Re: RFC: A regression test framework for Debian packages?
This one time, at band camp, Jérôme Marant wrote: In a chrooted environment, we can install deboostrap and package dependencies through APT. About 6 months ago I started writing some code in expect to do just this, to test my quake2-data installer package. I was able to install the package into an UML machine, answer the debconf questions, and check the location of the installed files (being an installer package, not all files installed by the package are in the deb). I haven't touched this code for a long time, but I've been meaning to clean it up and start doing regression testing on parts of the archive. I envisage being able to run it once a week on the entire archive, testing the ability of every pacakge to cleanly upgrade from woody to sarge, and back again. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg
Re: Improper NMU (Re: NMU for libquota-perl)
On Mon, Sep 02, 2002 at 09:32:42AM +, Martin Wheeler wrote: I have dropped out of several co-operative projects in the past simply because I'm a relatively slow worker -- i.e. I don't tend to give three or four fast responses to collective development _in the same day_. I find that sort of speed of progression highly de-motivating. Am I alone in this? (I might take up to a week to respond to any particular event -- this is normal for _me_.) I treat mailing list discussions as a lagged IRC conversation--when I see a message, time permitting, I reply to it. If I'm actively working on a project, I'm generally monitoring related lists, so I don't have a problem with any number of replies a day. I don't expect the same from all developers (especially when time zones, sleeping habits and employment cause us to be active on lists at different times of day), but when I'm being forced-delayed pending a discussion, having less than an interaction a day is frustrating. A week would probably drive me away from a project completely, at least for active development. If, by the time I get a reply, I've forgotton that I was waiting for one--a couple days--it's no longer a cohesive discussion, in my mind, but a series of related but disconnected emails. -- Glenn Maynard
Re: Improper NMU (Re: NMU for libquota-perl)
On Mon, Sep 02, 2002 at 09:16:24AM +0200, Goswin Brederlow wrote: In the case of something so trivial as causing a recompile for a problem that has been known for some time the warning given by the delayed upload should be enough. While a recompile *should* be trivial they still have the potential to break things. For example, I'm currently in the middle of preparing a NMU for a package. As in this case the NMU involves no code changes (a tweak to the control file is all) but unfortunately a simple recompile of the package produces binaries that fail to work. This is unquestionably a bug in the package but it's not something that would have been shown up if someone simply rebuilt without properly testing. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Improper NMU (Re: NMU for libquota-perl)
Le Mon, Sep 02, 2002 at 09:32:42AM +, Martin Wheeler écrivait: Individuals differ greatly in their working methods. So what is considered: in a timely manner? (Seriously.) In this case, it is several weeks since the first announce of the perl 5.8 update. And we don't have a generic response, it depends on the package you maintain and so on. If you just uploaded dpkg with a very annoying bug, it would be almost unacceptable to disappear for a full week. For a secondary package it doesn't matter... Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com
Re: [PHP] Placement of PHP programs?
Matthew a écrit : As a kind of an adjunct to the other discussion on PHP libraries, what about PHP programs? Not quite so touchy, as I can't see a single way forward here (and there's no blazingly obvious reason to do so). So what are people's best thoughts on the matter? Most packages I've seen put their web-accessible content in /usr/share/package, then either set up a separate apache config and include it from the main apache config (phpgroupware does it this way, for one example) while other packages modify apache.conf more intrusively. I'm a fan of the phpgroupware method, which at least minimises pain. Shouldn't webpage go to /var/www or at least /var/, and _not_ /usr/share ? We are talking about PHP, but it's still webpages after all. The apache configuration should go into a separate file in /etc/apache/ which would be included in httpd.conf later; easier to modify I guess. The software configuration should stay into the its location, the software directory. -- Fabien Penso [EMAIL PROTECTED] | LinuxFr a toujours besoin de : http://perso.LinuxFr.org/penso/ | http://linuxFr.org/dons/ A PHP Template Engine ? Take the best ! http://templeet.org/ pgpmL8cOmeRRY.pgp Description: PGP signature
Re: RFC: A regression test framework for Debian packages?
On Mon, 2 Sep 2030 11:20:05 +0200 How? In a chrooted environment, we can install deboostrap and package dependencies through APT. Then, we need some program that would execute some simple scripts in a pseudo language (for safety purpose, tests must be error prone as much as possible) describing what tests have to be performed, and how they would be performed. This is only a short summary :-) pbuilder has hooks to provide such checkings. regads, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Fri, Aug 30, 2002 at 01:42:26PM +0200, Richard Atterer wrote: RA As usual Heise got it right: RA http://www.heise.de/newsticker/data/vza-28.08.02-000/ (German). c't is a good info source, but this time they seem biased. First of all, they completely miss the point that you made below: RA Thomson tolerate violations against their license are far as RA *de*coders are concerned. ... However, such a statement is not RA enough for us to keep MP3 decoders in the distribution, I'm afraid. Next, their take on Ogg smells FUD: It is not a good idea as yet to rely exclusively on Ogg Vorbis, however: Even if Ogg Vorbis manages to close the quality gap between it and MP3 or even manages to get ahead of the latter, it will still take some time before Ogg-capable portable players make their appearance as hardware. IFAIK (IANA Musician) Ogg Vorbis outmatches quality of MP3 for quite some time. The hardware issue is indeed present, there is no free fixed-point Vorbis decoder yet, but there is proprietary one, which matches situation with hardware MP3 players that require loyalty fee. If I'm not missing something and there is no other obstacles to adoption of Ogg Vorbis save for inertia, the above sentence is just that, FUD. -- Dmitry Borodaenko
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Fri, Aug 30, 2002 at 04:55:24PM +0200, Robert Millan wrote: RM we definitely need an mp3 decoder in debian if we want to fight the RM patent oppression at all. i think we need another branch for that RM kind of problems. Debian/liberty in APT over FreeNet, anyone? -- Dmitry Borodaenko
Re: RFC: A regression test framework for Debian packages?
On Mon, Sep 02, 2002 at 08:19:19PM +0900, Junichi Uekawa wrote: On Mon, 2 Sep 2030 11:20:05 +0200 How? In a chrooted environment, we can install deboostrap and package dependencies through APT. Then, we need some program that would execute some simple scripts in a pseudo language (for safety purpose, tests must be error prone as much as possible) describing what tests have to be performed, and how they would be performed. This is only a short summary :-) pbuilder has hooks to provide such checkings. Good, this is a good place to do such test IMO, I'll have a deeper look at it. Thanks. -- Jérôme Marant
Re: Some proposals about the Email-subsystem, was Re: RFC: OpenLDAP and TLS/SSL
On Sun, Aug 25, 2002 at 02:56:46PM +1000, Martijn van Oosterhout wrote: On Sat, Aug 24, 2002 at 10:10:24PM -0600, Georg Lehner wrote: Hello! El sáb, 24-08-2002 a las 17:28, Martijn van Oosterhout escribió: ... Proposal: By default no MTA will be installed. Umm, this may sound silly, but how will you do local delivery if there is no MTA installed? ... Not silly. MDA's like procmail can do local delivery standalone. Obviously no queue needed. (..) What I'm saying is that to must have a mail-server install, even if it is just ssmtp or something like that. Yes, however the mail server should not be running as a daemon nor listening for incoming port 25 connections. I hope this is clearer. Yes. Javi
Re: shouldn't root.adm , -rw-r----- , be policy for all non-public log files?
On Mon, Aug 26, 2002 at 06:13:30PM +0200, Joost van Baal wrote: Hi, I maintain the Lire package, which processes log files from e.g. sendmail, bind, apache, boa and lots of other services. I don't want to run any Lire processes as root. However, of course, the processes need Which is quit sensible on your behalf. read access to log files. Unfortunately, there seems to be no rule or policy on how access permissions for log files should be. Wouldn't it be nice if all non-public log files were owned by group `adm', and groupreadable? (World readability for public log files is fine too, of course.) Currently, this is the case for quite a lot of commonly found log files. I recently added a FAQ item in the Securing Debian Manual (http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1) AFAIK there is no policy regarding log files, however, there *should* be one. (...) , although similar issues were raised, no conclusion seems to have been reached on this specific subject (other than adm is to read logs.) If so then policy should tell package maintainers to create logs as root.adm or package_user.adm. IMHO the problem should be fixed by clarifying the policy and having it written down. How about submitting a policy proposal? Regards Javi
Re: Security notification script
On Mon, Sep 02, 2002 at 08:58:43AM +0200, Ola Lundqvist wrote: Hi again, I'm I right when I say that this script only can follow the DSA:s that cover woody? It is nice but I would really like a version that can handle sid too. :) It would be some more text processing but I think it is doable. There are no DSAs for sids.. Javi
Re: Security notification script
On Mon, Aug 26, 2002 at 09:31:34PM +0100, Rob Bradford wrote: I have written a python script that allows you to compares locally installed packages with those on security.debian.org. Furthermore it provides a description of the problem/DSA name if the package is mentioned in the DSA RDF. Notice that the RDF does not include *all* the DSAs, just the latest (10?). Thus, if there is a week with *many* security updates your script might miss vulnerable packages if not run daily. The script is intended to be run as a normal user in a crontab, and thus produces no output if the system is completely upto date. You will need to install python2.2 and python2.2-xml prior to using the script which can be found at http://www.robster.org.uk/files/security-update-check.py Why Python? If you plan this script to be included in Debian-standard (such as the cron task in checksecurity) python is out of the question. Could you write it in Perl? Any feedbacl/ideas would be much appreciated. I plan to make some minor changes and package this up later this week :) Well, it's already done. Check out Tiger: http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-keep-up-to-date The problem with Tiger is that it has to be updated (both by the maintainer and the administrator) to work effectively until a create a 'tiger-signatures' package that can be updated regularly. But probably a stand-alone script is a good idea, it would appreciate it better in another language. You cannot consider installing python in a production environment where it's not really need it. Tiger, for example, is completely shell-based (does not even need Perl). Regards Javi pgpjgOEwiMxk7.pgp Description: PGP signature
Re: Security notification script
On Mon, Sep 02, 2002 at 02:00:21PM +0200, Javier Fernández-Sanguino Peña wrote: On Mon, Sep 02, 2002 at 08:58:43AM +0200, Ola Lundqvist wrote: Hi again, I'm I right when I say that this script only can follow the DSA:s that cover woody? It is nice but I would really like a version that can handle sid too. :) It would be some more text processing but I think it is doable. There are no DSAs for sids.. Well there are no DSA for sid but in the DSA released for potato, woody (and sarge?) unstable packages is mentioned. That is at least true for the latest DSA:s. See for example: http://www.debian.org/security/2002/dsa-159 ... For the unstable distribution (sid) this has been fixed in version 1.5.2-24 of Python 1.5, in version 2.1.3-6a of Python 2.1 and in version 2.2.1-8 of Python 2.2. Python 2.3 is not affected by this problem... Yes it is in the text but it would be really nice to parse this kind of stuff. Regards, // Ola Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: RFC: A regression test framework for Debian packages?
On Mon, Sep 02, 2002 at 08:19:23PM +1000, Jamie Wilkinson wrote: This one time, at band camp, Jérôme Marant wrote: In a chrooted environment, we can install deboostrap and package dependencies through APT. About 6 months ago I started writing some code in expect to do just this, to test my quake2-data installer package. I was able to install the package into an UML machine, answer the debconf questions, and check the location of the installed files (being an installer package, not all files installed by the package are in the deb). I haven't touched this code for a long time, but I've been meaning to clean it up and start doing regression testing on parts of the archive. I envisage being able to run it once a week on the entire archive, testing the ability of every pacakge to cleanly upgrade from woody to sarge, and back again. Nice! How does it work exactly? How do you write tests? Do you have scenarii or something? -- Jérôme Marant
Re: RFC: A regression test framework for Debian packages?
On Mon, 2 Sep 2030 13:51:42 +0200 (B (B (B This is only a short summary :-) (B (B pbuilder has hooks to provide such checkings. (B (B Good, this is a good place to do such test IMO, I'll have a deeper (B look at it. (B (B (BCurrently I only have: (B$ ls -l pbuilder-script/ (B-rwxr-xr-x1 dancer dancer 96 6$B7n(B 20 13:44 B90linda (B (B (Bwhich runs B90linda script when build succeeds, which does: (B (B#!/bin/bash (B# run linda on generated deb files (Bapt-get install -y linda (Blinda /tmp/buildd/*.deb (B (B (B (Band I've been running this through all of archive for a while now. (B (B (Bregards, (Bjunichi (B (B (B-- (B[EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Improper NMU (Re: NMU for libquota-perl)
On Mon, Sep 02, 2002 at 09:32:42AM +, Martin Wheeler wrote: On Mon, 2 Sep 2002, Sebastian Rittau wrote: If you're not able to maintain your packages properly and in a timely manner, and your holding up a major part of the distribution, it's your fault. I'm interested in this. Individuals differ greatly in their working methods. So what is considered: in a timely manner? (Seriously.) Before somebody else is sufficiently motivated to do it. I see no point in holding it against somebody if they don't fix it first - as long as either somebody fixes it, or nobody cares, why does it matter? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpbmRjrFdgxe.pgp Description: PGP signature
Re: Security notification script
On Mon, Sep 02, 2002 at 02:07:34PM +0200, Javier Fernández-Sanguino Peña wrote: On Mon, Aug 26, 2002 at 09:31:34PM +0100, Rob Bradford wrote: I have written a python script that allows you to compares locally installed packages with those on security.debian.org. Furthermore it provides a description of the problem/DSA name if the package is mentioned in the DSA RDF. Notice that the RDF does not include *all* the DSAs, just the latest (10?). Thus, if there is a week with *many* security updates your script might miss vulnerable packages if not run daily. That is a good point. Is it possible to get this kind of information from elsewhere (yes it is possible to dig it out of the html-pages) in a similar (easy) manner? The script is intended to be run as a normal user in a crontab, and thus produces no output if the system is completely upto date. You will need to install python2.2 and python2.2-xml prior to using the script which can be found at http://www.robster.org.uk/files/security-update-check.py Why Python? If you plan this script to be included in Debian-standard (such as the cron task in checksecurity) python is out of the question. Could you write it in Perl? Well I do not think it is suitable for standard (yet). It is a little bit too non-mature for that. But I could rewrite his (I'm not the author) code into perl if that is really needed. But of course it should be better to write it in shell-code but that is not that easy as to use xml interfaces within perl or python. Any feedbacl/ideas would be much appreciated. I plan to make some minor changes and package this up later this week :) Well, it's already done. Check out Tiger: http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-keep-up-to-date The problem with Tiger is that it has to be updated (both by the maintainer and the administrator) to work effectively until a create a 'tiger-signatures' package that can be updated regularly. It is about the same problem as harden-*flaws. But probably a stand-alone script is a good idea, it would appreciate it better in another language. You cannot consider installing python in a production environment where it's not really need it. Tiger, for example, is completely shell-based (does not even need Perl). Good point. Regards, // Ola Regards Javi -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Improper NMU (Re: NMU for libquota-perl)
On Sun, Sep 01, 2002 at 12:42:20PM -0400, Elie Rosenblum wrote: On Sun, Sep 01, 2002 at 06:37:52PM +0200, Bas Zoetekouw wrote: Hi Elie! You wrote: Why did you NMU this instead of submitting a bug? This is inappropriate. Well, it's the intent of a bug squashing party to _decrease_ the number of RC bugs, not to increase it. Also, we're trying to get the perl transition done this weekend. Of course, I could've mailed you beforehand, but the fix is trivial, so I didn't really see the need for that. I maintain several perl libraries, and it would be easier if I just did them all at once. Which you can still do. I uploaded to DELAYED, so sooner uploads will be prefered by the installer. I also don't see a bug submitted with this. If you're submitting NMU's, you sure as hell better be submitting bugs with patches (or the fact that no patch is required other than rebuilding with an updated system). The latter is the case here - the only changes are those clearly documented in the mails to debian-perl and debian-devel-announce, specifically: - The usual changelog entry - Increase of the version for perl in Build-Depends to = 5.8.0 All maintainers are supposed to be subscribed to -devel-announce, so you must have received the mail warning you this would happen quite some time ago. Please delete your uploads. There's no need. DELAYED exists for precisely this purpose. An upload to DELAYED says this: I have built this fix, and it will be NMUed in X days unless you upload something first. If you upload a fixed package before the time runs out, then the version of the package in DELAYED will be lower than the one in the pool, so the upload will be rejected. If you don't, the package is fixed anyway by the NMU. Either way, everybody wins. The whole point of DELAYED is (AIUI) to allow this kind of upload, where the maintainer has advance notification and a chance of override it, but if they don't then the new package will go into the pool. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpZRaydU8uZy.pgp Description: PGP signature
Re: RFC: A regression test framework for Debian packages?
This one time, at band camp, Jérôme Marant wrote: On Mon, Sep 02, 2002 at 08:19:23PM +1000, Jamie Wilkinson wrote: This one time, at band camp, Jérôme Marant wrote: In a chrooted environment, we can install deboostrap and package dependencies through APT. About 6 months ago I started writing some code in expect to do just this, to test my quake2-data installer package. I was able to install the package into an UML machine, answer the debconf questions, and check the location of the installed files (being an installer package, not all files installed by the package are in the deb). I haven't touched this code for a long time, but I've been meaning to clean it up and start doing regression testing on parts of the archive. I envisage being able to run it once a week on the entire archive, testing the ability of every pacakge to cleanly upgrade from woody to sarge, and back again. Nice! How does it work exactly? How do you write tests? Do you have scenarii or something? The expect script starts up a user-mode-linux on a pre-built chroot, and then attempts to install the package in it. If that succeeds, it tries to purge it. Testing an upgrade/downgrade requires a trivial bit of hacking in the script. Debconf questions/answers are read from a file, the questions are watched for in the console output. It's horridly inefficient, though---I chose uml over chroot because I wanted ordinary users to be able to run it. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg
Re: Improper NMU (Re: NMU for libquota-perl)
On Sun, 1 Sep 2002 19:14:37 +0200 Raphael Hertzog [EMAIL PROTECTED] wrote: I also don't see a bug submitted with this. If you're submitting NMU's, you sure as hell better be submitting bugs with patches (or the fact that no patch is required other than rebuilding with an updated system). The NMUer has to send the patch of the NMU to the maintainer, either through the BTS or directly, yes. Please use the BTS for tracking patches. It's often very hard to track, and NMUs do get lost. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: The harden-*flaws packages.
On Mon, Sep 02, 2002 at 08:47:53AM +0200, Ola Lundqvist wrote: Yes. Luckily I just saw someone that have written a script that checks the DSA:s and tell the maintainer that he/she has a vulnerable package. That is a good solution (best?). The problem is that the DSA is not able to distinguish between local/remote/3rdparty flaws but that is not always interesting. Why duplicate the work the Tiger package is already doing? I do not see the merit of checking *only* for DSAs published in the RDF file (since that RDF file is limited to a few DSAs only). If you want a program to check for security flaws please use one designed for that precisely. Tiger is such a program. Just have the *flaws package recommend: or depend: on tiger. Of course, there is room for improvement, the DSAs could be parsed from the WML source to retrieve both the description *and* wether it's a local or remote issue and populate the report accordingly (it currently just checks against version packages) *also* we could provide MD5sums of know vulnerable packages (in the stable distribution and proposed-updates). Also, this information needs to be splitted off the package so it can work like antivirus updates. Thus, signature updates could go to proposed-updates without needing to update the program itself. Regards Javi
Re: RFC: A regression test framework for Debian packages?
On Mon, Sep 02, 2002 at 10:42:32PM +1000, Jamie Wilkinson wrote: Nice! How does it work exactly? How do you write tests? Do you have scenarii or something? The expect script starts up a user-mode-linux on a pre-built chroot, and then attempts to install the package in it. If that succeeds, it tries to purge it. Testing an upgrade/downgrade requires a trivial bit of hacking in the script. Debconf questions/answers are read from a file, the questions are watched for in the console output. It's horridly inefficient, though---I chose uml over chroot because I wanted ordinary users to be able to run it. Thanks. -- Jérôme Marant
Re: RFC: A regression test framework for Debian packages?
On Mon, Sep 02, 2002 at 09:27:27PM +0900, Junichi Uekawa wrote: On Mon, 2 Sep 2030 13:51:42 +0200 This is only a short summary :-) pbuilder has hooks to provide such checkings. Good, this is a good place to do such test IMO, I'll have a deeper look at it. Currently I only have: $ ls -l pbuilder-script/ -rwxr-xr-x1 dancer dancer 96 6$B7n(B 20 13:44 B90linda which runs B90linda script when build succeeds, which does: #!/bin/bash # run linda on generated deb files apt-get install -y linda linda /tmp/buildd/*.deb and I've been running this through all of archive for a while now. Thanks. -- Jérôme Marant
Re: Packages affected by removal of free mp3 players
On Mon, 2002-09-02 at 03:23, Goswin Brederlow wrote: Joe Drew [EMAIL PROTECTED] writes: If the worst does happen, and we need to remove all mp3 players from Debian, many packages will be affected. Most of these are because of Why no non-free versions? Non-free versions aren't in Debian, and so removal doesn't really affect them. However, for free packages, Removal could be moving them to non-free or contrib, which notwithstanding Branden's thoughts is still a possibility. -- Joe Drew [EMAIL PROTECTED] [EMAIL PROTECTED] This particular group of cats is mostly self-herding. -- Bdale Garbee
Re: [PHP] Placement of PHP programs?
On Mon, 02 Sep 2002, Fabien Penso wrote: As a kind of an adjunct to the other discussion on PHP libraries, what about PHP programs? Not quite so touchy, as I can't see a single way forward here (and there's no blazingly obvious reason to do so). So what are people's best thoughts on the matter? Most packages I've seen put their web-accessible content in /usr/share/package, then either set up a separate apache config and include it from the main apache config (phpgroupware does it this way, for one example) while other packages modify apache.conf more intrusively. I'm a fan of the phpgroupware method, which at least minimises pain. This is probably the best way to do it. Shouldn't webpage go to /var/www or at least /var/, and _not_ /usr/share ? We are talking about PHP, but it's still webpages after all. Don't you dare stuff my /var up with constant, non-arch-specific, program text that should be in /usr in the first place :) Hint: the fact it is in php4 makes it no more special than anything else. The software configuration should stay into the its location, the software directory. As long as this is outside the exported url-space of the program. The braindamage has to be stopped somewhere... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: The harden-*flaws packages.
Hi On Mon, Sep 02, 2002 at 03:09:28PM +0200, Javier Fernández-Sanguino Peña wrote: On Mon, Sep 02, 2002 at 08:47:53AM +0200, Ola Lundqvist wrote: Yes. Luckily I just saw someone that have written a script that checks the DSA:s and tell the maintainer that he/she has a vulnerable package. That is a good solution (best?). The problem is that the DSA is not able to distinguish between local/remote/3rdparty flaws but that is not always interesting. Why duplicate the work the Tiger package is already doing? I do not see the merit of checking *only* for DSAs published in the RDF file (since that RDF file is limited to a few DSAs only). Well my thought was to check for all DSA:s which apparently this script do not. If you want a program to check for security flaws please use one designed for that precisely. Tiger is such a program. Just have the *flaws package recommend: or depend: on tiger. On the other hand tigher does a lot of other things too. But the link you gave me was very interesting. Of course, there is room for improvement, the DSAs could be parsed from the WML source to retrieve both the description *and* wether it's a local or remote issue and populate the report accordingly (it currently just checks against version packages) *also* we could provide MD5sums of know vulnerable packages (in the stable distribution and proposed-updates). Also, this information needs to be splitted off the package so it can work like antivirus updates. Thus, signature updates could go to proposed-updates without needing to update the program itself. Agreed. Without having too much digging in tiger it might be a good idea. The contact I have had with tiger is not very pleasant because it bugged me with a lot of non-issues. That is maybe the reason why I deinstalled it. :) Regards, // Ola Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Bug#159302: ITP: mcvs -- a version control system that is layered on top of CVS.
Package: wnpp Version: N/A; reported 2002-09-02 Severity: wishlist * Package name: mcvs Version : 0.22-1 Upstream Author : Kaz Kylheku [EMAIL PROTECTED] * URL : http://users.footprints.net/~kaz/mcvs.html * License : GPL Description : a version control system that is layered on top of CVS. It is more capable than CVS, and is easier to use. Its main features are: . * Directory structure versioning. * Sane corner cases. * Simple branching and merging. * Support for symbolic links. * Tracking of third party code containing moves and renames. * Ease of deployment. testing versions will be available from http://pumuki.hispalinux.es/debian/packages/ -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux reypastor 2.2.20HL1 #4 mar may 21 15:35:56 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: The harden-*flaws packages.
On Mon, Sep 02, 2002 at 04:09:21PM +0200, Ola Lundqvist wrote: Hi If you want a program to check for security flaws please use one designed for that precisely. Tiger is such a program. Just have the *flaws package recommend: or depend: on tiger. On the other hand tigher does a lot of other things too. But the link you gave me was very interesting. Tiger can be configured easily to just check *one* thing. Just customize the cron job at will. (..) Agreed. Without having too much digging in tiger it might be a good idea. The contact I have had with tiger is not very pleasant because it bugged me with a lot of non-issues. That is maybe the reason why I deinstalled it. :) There are still false positives in tiger, the template mechanism, however, takes care so that an admin just sees a security warning *once* and not in every run of the security test script (It's a simple diff, mind you, but it works) Regards Javi
Orphaning websec...
I am orphaning websec, here is the description: Web Secretary is a web page monitoring software. However, it goes beyond the normal functionalities offered by such software. Not only does it detect changes based on content analysis (instead of date/time stamp or simple textual comparison), it will email the changed page to you WITH THE NEW CONTENT HIGHLIGHTED! It is a small but very useful package, which is unmaintained upstream. I have kept it inside debian, because users still request for small changes now and then. You will need a bit of perl knowledge to maintain it. Joop
Re: The harden-*flaws packages.
On Mon, Sep 02, 2002 at 05:01:14PM +0200, Javier Fernández-Sanguino Peña wrote: On Mon, Sep 02, 2002 at 04:09:21PM +0200, Ola Lundqvist wrote: Hi If you want a program to check for security flaws please use one designed for that precisely. Tiger is such a program. Just have the *flaws package recommend: or depend: on tiger. On the other hand tigher does a lot of other things too. But the link you gave me was very interesting. Tiger can be configured easily to just check *one* thing. Just customize the cron job at will. That can be interesting for the harden-*flaws pacakges (or similar). (..) Agreed. Without having too much digging in tiger it might be a good idea. The contact I have had with tiger is not very pleasant because it bugged me with a lot of non-issues. That is maybe the reason why I deinstalled it. :) There are still false positives in tiger, the template mechanism, however, takes care so that an admin just sees a security warning *once* and not in every run of the security test script (It's a simple diff, mind you, but it works) Ahh that looks great. Last time I checked it did not. Now I might be able to use it again. :) Now we just have to solve the upload-to-security problem, or simply write some other check that scans the security.d.o web pages and make clever things of it. Maybe using tiger, maybe some other things. But because tiger can do similar things that might be useful. Regards, // Ola Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Sun, Sep 01, 2002 at 03:28:23AM +0300, Richard Braakman wrote: RB I do think that discouraging the use of patent-encumbered RB standards is a useful way to fight patent oppression. It sends RB the message that a patented standard is a dead standard. Maybe RB companies will review their habits in that light. As a one who lives in a post-communist dictatorship, I have a different moral position on this issue. Discouraging use of patent-encumbered technologies is the same as political emigration: it is the easy way out of the oppression, but it is nothing else but a defeat, and when you are fleeing to another country, this defeat will follow you there. If you want to fight oppression, you should fight where you stand, and not run away until you're locked in a corner. When you are retreating in such a way, you agree to abandon things that are important to you: useful technologies become casaulty to patents and your home and friends become casaulty to politics. Thus, you suffer major immediate damage, while damage you deliver to oppressor is minor and, honestly speaking, merely potential. Even worse, the fact that you retreat without a fight actually encourages further oppression, both on the territory you left and on territory you enter. Instead, I would try to do some actual damage to the oppressors, in this case by finding or creating such a way to ignore their limitations that will not put the whole Debian project in a danger. I think making patents practically unenforceable over free software would deliver much stronger message. Quoting Declan McCullagh: Put another way, who made a bigger difference: Yet another letter-scribbling activist or Phil Zimmermann? If you want to make a difference, don't just take your ball and walk away: they don't need your ball. -- Dmitry Borodaenko
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Mon, 2 Sep 2002 17:22, Dmitry Borodaenko wrote: Discouraging use of patent-encumbered technologies is the same as political emigration: it is the easy way out of the oppression, but it is nothing else but a defeat, and when you are fleeing to another country, this defeat will follow you there. If you want to fight oppression, you should fight where you stand, and not run away until you're locked in a corner. That moral stance makes sense. However it can be applied in a different way to this situation. Resolving to not use your PC for audio or video applications because of patents would be fleeing from opression. Writing and supporting new programs to perform the same tasks without the patents is actively fighting back. If the MP3 patents become worthless because everyone wants to use Vorbis technologies instead then the Frauhofer Institute will lose significant amounts of money! -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: Improper NMU (Re: NMU for libquota-perl)
John Goerzen wrote: I'm concerned that a single person has the power to dictate such dramatic changes in our procedures. Why is the NMU procedure not codified in Debian Policy? There, at least, we have a better mechanism of updating it. Debian policy does not dictate how developers do stuff, it describes the proper content of debian packages. Aj's pronouncement that we should loosen NMU procedures was accepted because it made it clear that this was a good idea and people agreed with it, and because we generally respect Aj to make decisions that are good for the release, not because it was a pronouncement from on high. -- see shy jo pgpumu6609ey5.pgp Description: PGP signature
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Mon, Sep 02, 2002 at 05:56:08PM +0200, Russell Coker wrote: DB Discouraging use of patent-encumbered technologies is the same as DB political emigration: it is the easy way out of the oppression, DB but it is nothing else but a defeat, and when you are fleeing to DB another country, this defeat will follow you there. If you want to DB fight oppression, you should fight where you stand, and not run DB away until you're locked in a corner. RC That moral stance makes sense. RC RC However it can be applied in a different way to this situation. RC Resolving to not use your PC for audio or video applications RC because of patents would be fleeing from opression. Writing and RC supporting new programs to perform the same tasks without the RC patents is actively fighting back. Agreed. But, encouraging development of patent-free and better alternative is not exactly the same as discouraging the use of patent-encumbered _free_ software. I'm all for the former, but I disagree with the latter. -- Dmitry Borodaenko
Re: The harden-*flaws packages.
On Mon, Sep 02, 2002 at 05:13:51PM +0200, Ola Lundqvist wrote: Now we just have to solve the upload-to-security problem, or simply write some other check that scans the security.d.o web pages and make clever things of it. Maybe using tiger, maybe some other things. But because tiger can do similar things that might be useful. It's in my todo list. Now DSAs are much more easy to parse. Some older DSAs (pre-1999) might need special parsing however. Also, DSAs could be improved to add an 'affected versions' tag (currently only the package name is provider, you can infer the affected versions by looking the versions which *fix* the vulnerability). Javi
Re: Improper NMU (Re: NMU for libquota-perl)
On Mon, Sep 02, 2002 at 10:41:48AM +0200, Raphael Hertzog wrote: Le Mon, Sep 02, 2002 at 12:20:22AM -0400, Elie Rosenblum ?crivait: Would you agree that performing an NMU without a BTS entry is wrong? Nope. The strict minimum is : - create a patch for the NMU - make the patch available to the maintainer (via direct mail or bts) If you upload the package to DELAYED, it is enough to respect the spirit of the NMUs guidelines (which are in developers-reference). BTW, the developers-reference evolved quite a bit since the good old days, and the DELAYED stuff is mentionned in the NMU guidelines... please read it again. http://www.debian.org/doc/manuals/developers-reference/index.en.html Please also read section 5.2.3. The exceptions everyone is talking about are documented there as well, and that's during the release cycle. As for _unstable_: Bug fixes to unstable by non-maintainers are also acceptable, but only as a last resort or with permission. The following protocol should be respected to do an NMU: And the rules following it make sense, and should really be followed. DELAYED is fine. Not submitting a bug is not fine. I've been hit with an irresponsible maintainer performing an NMU without submitting a bug at all, even if it was 5 minutes before he uploaded. This is ridiculous. An NMU is not a punishment for bad maintainers, it's an offer of help to help you catch up in your Debian work. No one should be offended by an NMU. I am offended with how the NMU was done. I've had one other NMU done before and it was done right; however, it also broke the package in question. I don't think I bitched that it was done though. especially since we have little control over which keys can successfully upload any given package. You want respect for yourself, you don't want to be treated like an irresponsible maintainer, but you show absolutely no respect to people who are doing NMUs to help you. Think about it, people doing NMUs are other Debian developers like you who take their free time to help you, and look how you thank them. Even if he made a mistake, it's not a big one, the upload was to DELAYED, the package has not yet been installed, you have a chance to dump the NMU by uploading your own fix. I just want him to follow the guidelines. I think he would have been within the guidelines by something as incredibly simple as a BTS entry. How fucking hard is that? -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_
Re: [PHP] Standard placement of PHP libraries?
Matthew I would like to propose /usr/share/php4 as the place for all Matthew scripts intended to run under php4 (whatever subversion) and Matthew intended for inclusion in other PHP scripts. I agree, but let's not forget about php3. -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 EngSoc adopts market economy: cheap is wasteful, efficient is expensive.
Re: [PHP] Standard placement of PHP libraries?
On Mon, Sep 02, 2002 at 07:05:40PM +1000, Matthew Palmer wrote:
I guess this is probably going to turn into a mini-policy discussion, and I
hope so, because I think we need some level of standardisation.
There are several PHP extension libraries packaged for Debian; I guess the
most famous is probably pear, but I maintain one (phtml, used by some other
packages I maintain) and I know there are a couple of others out there, too.
By these libraries I'm not talking about binary modules, I'm talking about
extension libraries written in PHP and available by include('whatever').
It's the 'whatever' that I'm mostly interested in discussing for now.
PEAR uses /usr/share/pear, and has an entry in include_path for it. Hence,
to use any PEAR-shipped function, simply refer to the file by name, relative
to that directory. Nice, very simple, I highly approve. Since PEAR holds a
special status, perhaps that should change.
But what about every other PHP extension library out there? libphp-adodb,
for instance, uses /usr/lib/adodb - in violation of the FHS, I believe,
since PHP scripts shouldn't be architecture specific. But that's not really
the issue here - the point is, where *should* PHP includes go?
Adam Conrad and I have begun hammering out a PHP mini-policy (not yet
ready for public consumption) that calls for all PHP classes to be
shipped in /usr/share/php. Yes, PEAR obviously violates this at present
-- so transitioning to the new scheme will require shipping a default
include path that looks in both /usr/share/php and /usr/share/pear.
In discussing this, we concluded that most PHP classes currently use
their own directories as a means of eliminating namespace collisions;
however, this is clearly inappropriate, as it pushes the burden of
resolving collisions on the user, rather than on the maintainer. PHP's
handling of classes should be the same as that of other scripting
languages, such as perl and python.
I would like to propose /usr/share/php4 as the place for all scripts
intended to run under php4 (whatever subversion) and intended for inclusion
in other PHP scripts. All packages would install their inclusion hierarchy
under /usr/share/php4/package name, and scripts which wanted to use their
functionality would include('package name/include.php'). Naming of
include files, including their extension, would be left to the discretion of
individual maintainers.
We had ruled out /usr/share/php4, on the grounds that many, if not most,
PHP classes are not specific to php4; some will work with php3, and many
should be forward-compatible with php5.
As far as using /usr/share/php4/package name, I'm not aware of any such
requirement for other scripting languages. I think it's reasonable to
allow PHP packages to install their classes in the manner which is most
convenient, and let package conflict resolution take care of the rest.
PEAR already provides us a structure for the namespace, which we ought to
take advantage of.
Steve Langasek
postmodern programmer
pgpO8d4Z534BQ.pgp
Description: PGP signature
Re: RFC: Handling of certificates in Debian
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote: On Sat, 31 Aug 2002, Brian May wrote: (note that I really like this realiance on checking the hostname, for instance it doesn't work properly with virtual name domains under https, but it somehow seems to have become the defacto default, and we seem to be stuck with it for now). It can, if the [EMAIL PROTECTED]@#$ browsers implement the altName extension. Uh, except that on the server side if you're going to have different certs for different virtual servers then unless they each have their own IP there's no way for apache to know which cert to use because the SSL connection and whatnot is set up prior to the HTTP headers being sent. That's my understanding anyway. Stephen pgpKRbTKYiJPJ.pgp Description: PGP signature
