More manpower to our core teams
When I was bitching about how hard it is to get new members into our core teams, Martin 'Joey' Schulze told me that they got in fact more manpower. He did not think this is worth an announcement but I find it very important to know that we still get fresh blood into crucial positions. So here is the list of the new nominations: FTP Archive Maintenance:Ryan Murray [EMAIL PROTECTED] Mailing Lists Administration: Robert McQueen [EMAIL PROTECTED] Security Team: Robert van der Meulen [EMAIL PROTECTED] Matt Zimmermann [EMAIL PROTECTED] Noah Meyerhans [EMAIL PROTECTED] System Administration: Ryan Murray [EMAIL PROTECTED] Philip Hands [EMAIL PROTECTED] Many thanks go to them for the contribution of their precious time to our project. Friendly Torsten pgpsNObxaq2QM.pgp Description: PGP signature
Uploaded vdkbuilder2 2.0.3-2 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 19 Aug 2002 17:02:51 +0200 Source: vdkbuilder2 Binary: libvdkbuilder2 vdkbuilder2 libvdkbuilder2-dev Architecture: m68k Version: 2.0.3-2 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Michael Vogt [EMAIL PROTECTED] Description: libvdkbuilder2 - Plugin libraries bundled with VDKBuilder libvdkbuilder2-dev - Header files and static libraries for VDKBuilder plugins vdkbuilder2 - RAD for VDK Changes: vdkbuilder2 (2.0.3-2) unstable; urgency=low . * rebuild against libgtk2.0-0png3 Files: cff50bbceffa15661c0c79a0944f7c70 73820 devel optional libvdkbuilder2-dev_2.0.3-2_m68k.deb 0963e20b39c8876b35069f448ea1230a 95904 libs optional libvdkbuilder2_2.0.3-2_m68k.deb 0a7d20597cf82e39028398ff9733f7e5 1183478 devel optional vdkbuilder2_2.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/ iD8DBQE9cJfCcS3JWD3FdvcRAi3wAJwMqBXER3kRfuHPAErXYbKCzkEAfACfSnQ2 oYVJpKTf3JJdbNT5/DYwW0s= =45xl -END PGP SIGNATURE-
Uploaded gnome-print 0.36-4 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 18:21:46 +0200 Source: gnome-print Binary: libgnomeprint-dev libgnomeprint-bin libgnomeprint-data libgnomeprint15 Architecture: m68k Version: 0.36-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: libgnomeprint-bin - The GNOME Print architecture - binary files libgnomeprint-dev - The GNOME Print architecture - development files libgnomeprint15 - The GNOME Print architecture - runtime library Changes: gnome-print (0.36-4) unstable; urgency=low . * Rebuild agaisnt the latest libgnome-dev 1.4.2-3 Files: 9f5472486ea18523b94b5f1716ee0121 228826 libs optional libgnomeprint15_0.36-4_m68k.deb 677f35dbcfe4226d84b446e0fc6cc555 247844 devel optional libgnomeprint-dev_0.36-4_m68k.deb 6c1ed8d81a3e3ab389c0b84404f2f49c 19534 libs optional libgnomeprint-bin_0.36-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9cJe4cS3JWD3FdvcRAnXDAJ4jY65XnQf/wR9/K6P3sJVZa9HbJACfetiU tFbFcD3cYn21XsUNFmwDvIc= =3vCb -END PGP SIGNATURE-
Uploaded gimp-freetype 0.3-5 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 30 Aug 2002 02:02:55 +0100 Source: gimp-freetype Binary: gimp-freetype Architecture: m68k Version: 0.3-5 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Bastien Nocera [EMAIL PROTECTED] Description: gimp-freetype - text plug-in for The Gimp 1.3 based on freetype Closes: 158707 Changes: gimp-freetype (0.3-5) unstable; urgency=low . * Fix dependency to make gimp-freetype installable again (Closes: #158707) Files: 000a09c02b86fcf59ae848ca8aa9269d 61088 graphics optional gimp-freetype_0.3-5_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9cJe0cS3JWD3FdvcRAg+9AJ9MPf8TVwVZxxHRwkj/7FuP2REftACeNQZD UG9V0uQoanhwFzlEYWfWrtI= =s9iQ -END PGP SIGNATURE-
Uploaded exim 3.36-1 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 30 Aug 2002 21:52:46 +0100 Source: exim Binary: eximon exim Architecture: m68k Version: 3.36-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Mark Baker [EMAIL PROTECTED] Description: exim - An MTA (Mail Transport Agent) eximon - X monitor for the exim mail transport agent. Closes: 115654 137110 137359 142561 144229 12 149036 150662 151557 151837 154208 154227 156725 Changes: exim (3.36-1) unstable; urgency=low . * New upstream version (Closes: #150662) * debian/prerm: Only run update-inetd if it exists (Closes: #154227, #156725) * debian/exim.8: fix options (Closes: #154208, #137110) * debian/prerm: only run /etc/init.d/exim if it exists (though I can't see how it would not exist except if someone deleted it) (Closes: #151837) * debian/README: Mention eximconfig * debian/exim.8: Reference other manpages (Closes: #12) * debian/config: Remove debug left in by mistake (Closes: #142561) * debian/newaliases: /usr/sbin/sendmail, not /usr/lib (Closes: #151557) * debian/postinst: Check DEBIAN_FRONTEND case-insensitively (Closes: #137359) * debian/config: Lower-case domain used in rewrite rule in generated config file (Closes: #149036) * debian/config: Include /etc/email-addresses rewriter first (Closes: #115654) * debian/config: Fixed example LOGIN authenticator (Closes: #144229) Files: 75180dd490d803ae2652a457043d0bc9 732694 mail important exim_3.36-1_m68k.deb b7c7c8cd92575538c5cf81a9ac3bc597 37822 mail optional eximon_3.36-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9cJd7cS3JWD3FdvcRAmhmAJ90mtmFZqN67y7kP7l3jSBumFHzfgCdGboT eU8CYy3UA48xWvQfNbAZqMI= =qJSf -END PGP SIGNATURE-
Uploaded sylpheed 0.8.2-1 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Aug 2002 11:12:19 -0300 Source: sylpheed Binary: sylpheed Architecture: m68k Version: 0.8.2-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Gustavo Noronha Silva [EMAIL PROTECTED] Description: sylpheed - Light weight e-mail client with GTK+ Closes: 156504 158403 Changes: sylpheed (0.8.2-1) unstable; urgency=low . * New upstream release * debian/control: - Build-Depends on libpng2-dev (Closes: #158403) * tools: - updated from sylpheed-claws 0.8.1claws120 * debian/rules: - installs all pngs (Closes: #156504) * patches/00configure: - changed patch to sylpheed.desktop, to use the png icon * debian/sylpheed.xpm: - removed Files: a8bcc4ccbfa39ff0b8635d885be5d037 1323064 mail optional sylpheed_0.8.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/ iD8DBQE9cKQ5cS3JWD3FdvcRApVNAJ0SldKADb8Vd08qCXQpqO4u0Zv2PgCfRC5H FfFIVWbE3hkvlyuKSPjYsB8= =1JRh -END PGP SIGNATURE-
Uploaded gnupg 1.0.7-2 (m68k) to non-us
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 01:42:58 +0100 Source: gnupg Binary: gnupg Architecture: m68k Version: 1.0.7-2 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: James Troup [EMAIL PROTECTED] Description: gnupg - GNU privacy guard - a free PGP replacement. Closes: 147679 149462 151969 156245 158492 Changes: gnupg (1.0.7-2) unstable; urgency=low . * debian/control (Suggests): add xloadimage since that's what gpg uses by default to view photo IDs. Thanks to Julien Danjou [EMAIL PROTECTED] for the suggestion. Closes: #156245 * debian/control (Depends): add hurd to the alternatives to makedev. Thanks to Michal Suchanek [EMAIL PROTECTED] for noticing. Closes: #158492 * po/it.po: patch to fix typos from Marco Bodrato [EMAIL PROTECTED] Closes: #149462 * g10/g10.c (main): remove the bogus undef of USE_SHM_COPROCESSING to match upstream and fix gabber and libgnupg-perl. Closes: #147679, #151969 Files: c96be4521d8b41e5c945f16338b00198 1159522 utils standard gnupg_1.0.7-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9bolKWgZ1HEtaPf0RAhmSAJ9UN6vImFqHfbgCLWBXKczSnT1IdgCghJjV zzgxYFxMYChwYUsAqkh+fMs= =ZJb0 -END PGP SIGNATURE-
Uploaded proftpd 1.2.5-3 (m68k) to non-us
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 18 Aug 2002 20:25:11 +0200 Source: proftpd Binary: proftpd-doc proftpd-ldap proftpd-pgsql proftpd proftpd-mysql proftpd-common Architecture: m68k Version: 1.2.5-3 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Ivo Timmermans [EMAIL PROTECTED] Description: proftpd- Versatile, virtual-hosting FTP daemon proftpd-common - Versatile, virtual-hosting FTP daemon proftpd-ldap - Versatile, virtual-hosting FTP daemon (with LDAP support) proftpd-mysql - Versatile, virtual-hosting FTP daemon (with SQL support) proftpd-pgsql - Versatile, virtual-hosting FTP daemon (with SQL support) Closes: 144882 148727 151362 153922 156464 156878 Changes: proftpd (1.2.5-3) unstable; urgency=low . * debian/proftpd.init: - Remove bashism; - signal(): remove superfluous proftpd in the find statement; (Closes: #156878) - Added new option force-stop, which will try to kill proftpd even though the config file says it is started from inetd (like force-start). (Closes: #153922) * debian/proftpd.config: Stop any running proftpd when the old setting was to be run standalone, and the new setting to run from inetd. (Closes: #144882, #151362) * debian/proftpd.postrm: Remove debconf calls. (Closes: #148727, #156464) * debian/copyright: - Include the license exception the ProFTPd team has given (long ago) to allow binaries linked against OpenSSL to be distributed. - Include licenses for contributed modules. Files: 451b34f20f37e0b22aa3b639cd87f3dd 157970 non-US optional proftpd_1.2.5-3_m68k.deb ef1e1a502da25774decc9d5886caefe8 74586 non-US optional proftpd-common_1.2.5-3_m68k.deb a0477691bfc2b1f4f4b05e9c1b4c6f44 174138 non-US optional proftpd-mysql_1.2.5-3_m68k.deb 46f2abb8f865f7e1171c371a5e2c2006 173868 non-US optional proftpd-pgsql_1.2.5-3_m68k.deb 78be7ef490707e613a231202fde11cfc 165844 non-US optional proftpd-ldap_1.2.5-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9boPtWgZ1HEtaPf0RAqjnAJ40nKa5DxOWdLSh72lM22fLgvm2/QCgiwim lCEC8UlG4+wJM+nTe6p4Spk= =5cnm -END PGP SIGNATURE-
Uploaded flashplayer 0.4.10-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 18 Aug 2002 16:33:08 +0200 Source: flashplayer Binary: flashplayer Architecture: m68k Version: 0.4.10-3 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Robert Millan [EMAIL PROTECTED] Description: flashplayer - A GPLed Flash Player Closes: 153232 Changes: flashplayer (0.4.10-3) unstable; urgency=low . * Using g++ instead of gcc for linking with c++ objects. (Closes: #153232) Files: aac388ba5be4822037e9bfe6c5964d5e 10442 net optional flashplayer_0.4.10-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFNEycGpQPNsdIRAlFBAJ9yg7qfMLOs4gLnJ8HEIfkGPmqnrACdFf7v omDJBY0dk6LszTcP1ZUfY/E= =B/8k -END PGP SIGNATURE-
Uploaded libgnome 2.0.3-1 (m68k all) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 19:35:22 +0200 Source: libgnome Binary: libgnome2-0 libgnome2-common libgnome2-dev Architecture: m68k all Version: 2.0.3-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: libgnome2-0 - The GNOME 2 library - runtime files. libgnome2-common - The GNOME 2 library - common files. libgnome2-dev - The GNOME 2 library - development files. Changes: libgnome (2.0.3-1) unstable; urgency=low . * New upstream release. Files: c52b3312f49962682e581f060a1812cd 114242 libs optional libgnome2-0_2.0.3-1_m68k.deb d370116993c6d1dbe835df85ce55dd50 120484 devel optional libgnome2-dev_2.0.3-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGFEycGpQPNsdIRApJfAJ9xdjdVIDEZ5aMMayB4fH3UAs+Z7gCgnuNe ZAhK8S8PYEt/oaZdKVFSXNY= =5fjp -END PGP SIGNATURE-
Uploaded fluxconf 0.8.8-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 20 Aug 2002 14:03:03 +0200 Source: fluxconf Binary: fluxconf Architecture: m68k Version: 0.8.8-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Emmanuel le Chevoir [EMAIL PROTECTED] Description: fluxconf - FluxBox configuration utility Changes: fluxconf (0.8.8-1) unstable; urgency=low . * New Upstream Release * Acknowlegded previous changes to the control file. (Thanks to Marcelo E. Magallon for the NMU.) * Fix error messages. Fluxconf already allows modifications to conffile locations. * Happy birthday to the author :-) Files: 16808eee9812e0a80c7bfc5ab78012ae 21138 x11 optional fluxconf_0.8.8-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFUEycGpQPNsdIRApSpAJ9l2KSG5sZHgrHb27puE/EhCACJKQCgidQr Ci89o15//AzYVCPu5LnOfF0= =kVC9 -END PGP SIGNATURE-
Uploaded heimdal 0.4e-18 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 15 Aug 2002 10:05:46 +1000 Source: heimdal Binary: libkafs0-heimdal heimdal-clients libkadm5clnt4-heimdal heimdal-clients-x libasn1-5-heimdal libhdb7-heimdal heimdal-lib libgssapi1-heimdal libkrb5-17-heimdal heimdal-servers libkadm5srv7-heimdal heimdal-kdc heimdal-dev heimdal-servers-x heimdal-docs Architecture: m68k Version: 0.4e-18 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Brian May [EMAIL PROTECTED] Description: heimdal-clients - Clients for Heimdal Kerberos heimdal-clients-x - X11 files for Heimdal Kerberos heimdal-dev - Development files for Heimdal Kerberos heimdal-kdc - KDC for Heimdal Kerberos heimdal-servers - Servers for Heimdal Kerberos heimdal-servers-x - X11 files for Heimdal Kerberos libasn1-5-heimdal - Libraries for Heimdal Kerberos libgssapi1-heimdal - Libraries for Heimdal Kerberos libhdb7-heimdal - Libraries for Heimdal Kerberos libkadm5clnt4-heimdal - Libraries for Heimdal Kerberos libkadm5srv7-heimdal - Libraries for Heimdal Kerberos libkafs0-heimdal - Libraries for Heimdal Kerberos libkrb5-17-heimdal - Libraries for Heimdal Kerberos Closes: 150967 Changes: heimdal (0.4e-18) unstable; urgency=low . * Apply patches from Mikael Andersson to fix FTP bug, closes: 150967. Files: 547e66265402d6c4529298c77f4d1dbc 102474 net optional heimdal-kdc_0.4e-18_m68k.deb 801c8c70ee83483818a9ca0fbe9ac52d 297182 net optional heimdal-dev_0.4e-18_m68k.deb 37c63b205ec73f8cacd8bd09e4b23688 51372 net optional heimdal-clients-x_0.4e-18_m68k.deb a4b9deed8d6eb89eb2159b4242f21242 206698 net optional heimdal-clients_0.4e-18_m68k.deb 109e10cdb52524d195f363de8e1482fc 34454 net optional heimdal-servers-x_0.4e-18_m68k.deb 0be838713fa201837c3f61747b05657a 140776 net optional heimdal-servers_0.4e-18_m68k.deb 20a24604f4db0d37287c8c88f6feef6d 54710 net optional libasn1-5-heimdal_0.4e-18_m68k.deb 1bf7d911bc0ec6a94c5d1f80de602f3c 109708 net optional libkrb5-17-heimdal_0.4e-18_m68k.deb 584bf5a1034140041e61ed1f8613eb58 37672 net optional libhdb7-heimdal_0.4e-18_m68k.deb 2557a20d4b2c1c91687d0ec230eac87d 39500 net optional libkadm5srv7-heimdal_0.4e-18_m68k.deb 6d9725c406fb45916c8468aaf056382e 31432 net optional libkadm5clnt4-heimdal_0.4e-18_m68k.deb f6e7e529cfbb7b4518cfc57df5afcadd 37808 net optional libgssapi1-heimdal_0.4e-18_m68k.deb 28d329cff11bce35c3c0b0c99826cbf9 28976 net optional libkafs0-heimdal_0.4e-18_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQF4EycGpQPNsdIRApC5AJ9RFGbTucXg8TZHoP1y4bQwiqMOKACeJhsU bCxofeohux6bsWgcQ7NjPVw= =tzap -END PGP SIGNATURE-
Uploaded nparted 0.1-7 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 21 Aug 2002 16:15:03 +0200 Source: nparted Binary: nparted Architecture: m68k Version: 0.1-7 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Julien LEMOINE [EMAIL PROTECTED] Description: nparted- Newt and GNU Parted based disk partition table manipulator Changes: nparted (0.1-7) unstable; urgency=low . * updated to follow the last version of Debian Policy Files: 9f2669071904c8e13ae2425f6bfacd73 26706 utils optional nparted_0.1-7_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGZEycGpQPNsdIRAuLmAKCQ/McJ27kVkT3A49JrZOGKeRIsZACcDlRf MWqdXne69hfUfyEuc02jawU= =ZIDK -END PGP SIGNATURE-
Uploaded cwi-cgen 0.8-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 13:56:41 +0200 Source: cwi-cgen Binary: cwi-cgen-dev Architecture: m68k Version: 0.8-4 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Julien LEMOINE [EMAIL PROTECTED] Description: cwi-cgen-dev - Generating C source code Changes: cwi-cgen (0.8-4) unstable; urgency=low . * Disable compilation on alpha and ia64 because cwi-aterm does not compile on theses architectures (Upstream authors have no plan to fix this now) * Resolved compilation problem (cannot create .rtreee at this step) Files: 35e837f3efc5e23a3a6614b751e6ef77 52196 devel optional cwi-cgen-dev_0.8-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFAEycGpQPNsdIRAifHAKCGZWx6pD/sOLIE8Uv6iEAmewnw8gCgm/lH shZpDowHu4znjwMnROvd2a8= =7Mim -END PGP SIGNATURE-
Uploaded gpgkeys 0.3.1-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 23 Aug 2002 11:56:50 +0200 Source: gpgkeys Binary: gpgkeys Architecture: m68k Version: 0.3.1-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Peter Mathiasson [EMAIL PROTECTED] Description: gpgkeys- GPG Keymanagement frontend Closes: 148366 Changes: gpgkeys (0.3.1-1) unstable; urgency=low . * New upstream release. Closes: #148366 (fonts not the same everywhere). * Compiled with libqt3-mt. Files: 710e0802e2ad0185a134c204a435c980 71286 utils optional gpgkeys_0.3.1-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFxEycGpQPNsdIRAvykAJ985gcNxljESI2MnYqXu1fY30KsjQCZAefS zwo+uVpWBQFhc0rSz9+rCDI= =lm4+ -END PGP SIGNATURE-
Uploaded gaim 0.59.1-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Aug 2002 02:42:42 +0100 Source: gaim Binary: gaim gaim-common gaim-gnome Architecture: m68k Version: 1:0.59.1-3 Distribution: unstable Urgency: high Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Robert McQueen [EMAIL PROTECTED] Description: gaim - GPL multi-protocol instant messenger client - Gtk+ version gaim-common - GPL multi-protocol instant messenger client - common files gaim-gnome - GPL multi-protocol instant messenger client - GNOME applet Changes: gaim (1:0.59.1-3) unstable; urgency=high . * The 'getting sick of this now' release. Third time lucky and all... * Ryan Murray (of gdk-pixbuf-dev fame) suggests dropping the new build dependencies and gently hacking the Makefile to substitute them out of linking the applet, because they're not actually necessary. This will also fix libpng2/3 compatibility issues that were making the applet fall back to the ugly xpm icon (until Christian Marillat stops being an idiot and links GNOME 1.4 against libpng2 again). * Thanks to Lukas Geyer (of JimButton fame) for pointing me at the right make features I needed to accomplish this without too much hacking. * Include a patch from Chris Blizzard (of RedHat fame) to fix an oversight in my fix for the browser security vunlerability. Access to unallocated memory in the non-manual browser handlers could have caused crashes in some situations. Cheers Chris. Sorry everyone. * Also edit the default manual browser command to not contain quotes any more. Debian should get a /usr/bin/sensible-browser or something. Files: 70f1f0faac9ffd6bc3e6fa052a07d7d9 371180 net optional gaim_0.59.1-3_m68k.deb 34307144375c391dcbdfe3e760531944 391594 net optional gaim-gnome_0.59.1-3_m68k.deb bb1d5debb6a6a4bb3b542180a41ea406 658498 net optional gaim-common_0.59.1-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFdEycGpQPNsdIRArdZAJ9UlGTqKnjPmJdDXm/A9dPuqppXbACfZgs0 ssFQuh3e8yQXzDBuwwlgM+g= =bIIC -END PGP SIGNATURE-
Uploaded zvbi 0.2.1-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 19:11:32 +0200 Source: zvbi Binary: libzvbi-dev libzvbi-0.1 Architecture: m68k Version: 0.2.1-3 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: libzvbi-0.1 - Video Blank Interval decoder - runtime files libzvbi-dev - Video Blank Interval decoder - development files Changes: zvbi (0.2.1-3) unstable; urgency=low . * Build against against libpng2-dev Files: 5444bf69b41d4c8cc841805ff6ab191f 120276 libs optional libzvbi-0.1_0.2.1-3_m68k.deb 0bd37e41a0f8743e8ba3586d3d16ff2a 289686 devel optional libzvbi-dev_0.2.1-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQHAEycGpQPNsdIRAhK+AKCJTmvIZdjNppLzNc5mDf5pR1Nm6wCgoWQi lMUURWXrpZIM3O9MqqoMqnE= =xFSI -END PGP SIGNATURE-
Uploaded gmoo 0.5.6-5 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 27 Aug 2002 15:41:35 +0200 Source: gmoo Binary: gmoo Architecture: m68k Version: 0.5.6-5 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Paul van Tilburg [EMAIL PROTECTED] Description: gmoo - a GTK+ based MOO (and MUD) Client Changes: gmoo (0.5.6-5) unstable; urgency=low . * Linked against libperl5.8. Files: 3d63b555eda967f4702235a7fb65903a 151942 net optional gmoo_0.5.6-5_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFmEycGpQPNsdIRAoFLAJ9gJEzCT9MOYTM6FWy/51hFB1sh/QCeI7Dw ITQcP+Nglc0YYp96ibxUVT8= =moS8 -END PGP SIGNATURE-
Uploaded libgnomecanvasmm1.3 1.3.9-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 14 Aug 2002 12:30:52 -0700 Source: libgnomecanvasmm1.3 Binary: libgnomecanvasmm1.3-dev libgnomecanvasmm1.3-9 Architecture: m68k Version: 1.3.9-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Bradley Bell [EMAIL PROTECTED] Description: libgnomecanvasmm1.3-9 - C++ wrappers for libgnomecanvas2 (shared library) (Developer Vers libgnomecanvasmm1.3-dev - C++ wrappers for libgnomecanvas2 (development files) (Developer V Changes: libgnomecanvasmm1.3 (1.3.9-1) unstable; urgency=low . * New upstream release Files: f8f1d918140e1cf5a19efe730953524a 284920 devel optional libgnomecanvasmm1.3-dev_1.3.9-1_m68k.deb 5ca6272eb84bb6644c51515db8aa4274 67918 libs optional libgnomecanvasmm1.3-9_1.3.9-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGKEycGpQPNsdIRAovfAJ4549BFHLpDx+pW/MbMcbPW0BPa9ACfZCjf y1yeWuMXTNUNN8ciQ6yf7EA= =S3rL -END PGP SIGNATURE-
Uploaded gnome-admin 1.0.3-13 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 24 Aug 2002 14:44:00 +0200 Source: gnome-admin Binary: gnome-admin Architecture: m68k Version: 1.0.3-13 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Noel Koethe [EMAIL PROTECTED] Description: gnome-admin - Gnome Admin Utilities (gulp) Closes: 157112 Changes: gnome-admin (1.0.3-13) unstable; urgency=low . * added gobjc to build-dep for ia64 (closes: Bug#157112) Files: 275fd1bc105aae43db09bc8803c4c6f2 58746 admin optional gnome-admin_1.0.3-13_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFtEycGpQPNsdIRAhumAJ9KTpWBgHhC1VcLgLTYkCUEpGsf7QCfUvUK 9O5Z6wIvVqL89TY01B+5Aic= =Snpd -END PGP SIGNATURE-
Uploaded ipfm 0.11.4-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 18 Aug 2002 12:16:58 +0200 Source: ipfm Binary: ipfm Architecture: m68k Version: 0.11.4-3 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Samuel Hocevar [EMAIL PROTECTED] Description: ipfm - A bandwidth analysis tool Closes: 146409 156204 Changes: ipfm (0.11.4-3) unstable; urgency=low . * Fixed minor grammar errors in the sample configuration (Closes: #146409). * Rebuilt against libpcap0.7 to remove dependency on libpcap0 which got removed from unstable (Closes: #156204). Files: 8ee7833c510681b4b9684d64387e656b 24404 net optional ipfm_0.11.4-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGBEycGpQPNsdIRArSdAJ0ZFLrRzfawwKwNBN5Lr30fIMtHKwCgj/uc JN98NWfM+7TCGvKBBbY/gyk= =tP2q -END PGP SIGNATURE-
Uploaded libnss-mysql 0.41-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 20 Aug 2002 13:12:34 +0200 Source: libnss-mysql Binary: libnss-mysql Architecture: m68k Version: 0.41-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Guillaume Morin [EMAIL PROTECTED] Description: libnss-mysql - NSS library for MySQL Changes: libnss-mysql (0.41-1) unstable; urgency=low . * New upstream release Files: 641f94587154ee3e1300e371dda57466 27190 admin optional libnss-mysql_0.41-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGUEycGpQPNsdIRArcoAJ4iKoQS1E6DX/2D7LlZmG+/G4cWxQCeLvpi lKqNk5bu5s0nE4W1tY0GMnU= =B/zV -END PGP SIGNATURE-
Uploaded gconf-editor 0.3-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 26 Aug 2002 15:56:14 +0900 Source: gconf-editor Binary: gconf-editor Architecture: m68k Version: 0.3-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Takuo KITAME [EMAIL PROTECTED] Description: gconf-editor - An editor for the GConf configuration system. Closes: 157768 Changes: gconf-editor (0.3-1) unstable; urgency=low . * New upstream release (closes: #157768) Files: e860541883ce8b381e60ab48b61bdcc4 72578 utils optional gconf-editor_0.3-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFhEycGpQPNsdIRAkJPAJ9sHJ3RTRNOHQAV8oDJ9F871/pMkgCfTGJ0 a66gf6exCs8iR2C5v5LIGEc= =5p9R -END PGP SIGNATURE-
Uploaded ocaml 3.06-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 30 Aug 2002 09:39:25 +0200 Source: ocaml Binary: ocaml-base ocaml ocaml-source ocaml-native-compilers Architecture: m68k Version: 3.06-3 Distribution: unstable Urgency: high Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Sven Luther [EMAIL PROTECTED] Description: ocaml - ML language implementation with a class-based object system ocaml-base - Runtime system for ocaml bytecode executables Changes: ocaml (3.06-3) unstable; urgency=high . * Added a Provide: ocaml-source-3.06 to the ocaml-source control file. (Asked by Jérôme Marant) Files: c623cd72422b070880eccffa57632722 4461146 devel optional ocaml_3.06-3_m68k.deb 9e8371ca8726a87be8514f7e807c3f27 165180 devel optional ocaml-base_3.06-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGfEycGpQPNsdIRAjffAKCViyODp5WLCtNjOp7LExmms5VF0wCfWOBB /9sL5b8/cn7QZwzlr7r4zoA= =CUc7 -END PGP SIGNATURE-
Uploaded iftop 0.5-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 26 Aug 2002 15:54:14 -0400 Source: iftop Binary: iftop Architecture: m68k Version: 0.5-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: christophe barbe [EMAIL PROTECTED] Description: iftop - Display bandwidth usage on an interface Closes: 157168 157176 Changes: iftop (0.5-1) unstable; urgency=low . * New Upstream release. * Exit nicely when running as non-root (Closes: #157168). * Better interface selection (Closes: #157176). Files: 0c8f98dfe67e82d98859a0ff14cfe798 16038 net optional iftop_0.5-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQF8EycGpQPNsdIRAvnSAKCigwCdE5xIq+a1ve60rrHpud0dVACeK25N BQWNSR/VLazsFNRGPMzPTw8= =viWb -END PGP SIGNATURE-
Uploaded fragrouter 1.6-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 15 Jul 2002 20:10:57 -0400 Source: fragrouter Binary: fragrouter Architecture: m68k Version: 1.6-1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Simon Law [EMAIL PROTECTED] Description: fragrouter - Test a NIDS by attempting to evade using fragmented packets Closes: 153117 Changes: fragrouter (1.6-1) unstable; urgency=low . * Initial Release. (Closes: Bug#153117) Files: 21706c4c18d3124c5db9b76bfdbf53fe 20106 net optional fragrouter_1.6-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFYEycGpQPNsdIRAh8KAJ989ZL/2K4W7NVIdHxPX9fAy9Cq5wCfab3W V5natDwdrg9FQBkuPAPQlbc= =CNi6 -END PGP SIGNATURE-
Uploaded e16menuedit 0.1-5 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 12 Jul 2002 17:22:49 -0400 Source: e16menuedit Binary: e16menuedit Architecture: m68k Version: 0.1-5 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Jon Bernard [EMAIL PROTECTED] Description: e16menuedit - enlightenment menu editor Closes: 138961 Changes: e16menuedit (0.1-5) unstable; urgency=low . * New maintainer. * Added debian/compat file. * Added debian/e16menuedit.manpages file. * Added debian/docs file. * Added debian/dirs file. * Added debian/compat file. * Updated to debhelper 4. * Added Recommends: enlightenment in debian/control. * Menus can now contain empty lines, closes: #138961 Files: 8b204610d2fd81ad9dcf184635b814ea 15634 x11 optional e16menuedit_0.1-5_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQFJEycGpQPNsdIRAhLFAJ4y7diohSnzxygIsnTIF3BvROec8QCdGMUE O0GDqz831Kj+Q8OzrUDUt1U= =DJuL -END PGP SIGNATURE-
Uploaded python-imaging 1.1.3-1.1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 24 Aug 2002 14:02:03 +0200 Source: python-imaging Binary: python-imaging-tk python2.1-imaging-tk python2.1-imaging python1.5-imaging-tk python-imaging python1.5-imaging-sane python-imaging-doc python-imaging-sane python2.2-imaging-sane python1.5-imaging python2.2-imaging python2.1-imaging-sane python2.2-imaging-tk Architecture: m68k Version: 1.1.3-1.1 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: python1.5-imaging - The Python Imaging Library. python1.5-imaging-sane - The Python Imaging Library SANE interface. python1.5-imaging-tk - The Python Imaging Library (Module with Tk support). python2.1-imaging - The Python Imaging Library. python2.1-imaging-sane - The Python Imaging Library SANE interface. python2.1-imaging-tk - The Python Imaging Library (Module with Tk support). python2.2-imaging - The Python Imaging Library. python2.2-imaging-sane - The Python Imaging Library SANE interface. python2.2-imaging-tk - The Python Imaging Library (Module with Tk support). Changes: python-imaging (1.1.3-1.1) unstable; urgency=low . * Change python default to python2.2. Files: bb1ef90ec469969299887fd25ec7c091 183998 graphics optional python1.5-imaging_1.1.3-1.1_m68k.deb 71fdb3acde52f46bb116ef74eb50f325 23528 graphics optional python1.5-imaging-tk_1.1.3-1.1_m68k.deb 86e813199d8e6b77bc919963d75af31a 29260 graphics optional python1.5-imaging-sane_1.1.3-1.1_m68k.deb fd5d61c94bb86d747f170642a567b49c 184018 graphics optional python2.1-imaging_1.1.3-1.1_m68k.deb b7d4422e845081f0b35dfcd7e9fafa8f 23516 graphics optional python2.1-imaging-tk_1.1.3-1.1_m68k.deb 3a24245e68bc1fe6446b89e3f6d54c92 29244 graphics optional python2.1-imaging-sane_1.1.3-1.1_m68k.deb 77b74ec780fcd4971267b2755c3a8485 184884 graphics optional python2.2-imaging_1.1.3-1.1_m68k.deb 8dd59775dc73b48c93405965cac63fbd 23512 graphics optional python2.2-imaging-tk_1.1.3-1.1_m68k.deb 80aef923bda14bef3bafef50ce2a6b48 29618 graphics optional python2.2-imaging-sane_1.1.3-1.1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGlEycGpQPNsdIRAmFYAJ91LGpVw3fq7liGoVNnRM8MD6vuAQCcD9ME LFmCH4tRTE+/PnlDMAXI1FU= =2zy2 -END PGP SIGNATURE-
Uploaded libnet-rawip-perl 0.09d-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 23 Aug 2002 23:17:05 +0200 Source: libnet-rawip-perl Binary: libnet-rawip-perl Architecture: m68k Version: 0.09d-4 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Christian Hammers [EMAIL PROTECTED] Description: libnet-rawip-perl - Perl interface to lowlevel TCP/IP Closes: 157623 Changes: libnet-rawip-perl (0.09d-4) unstable; urgency=low . * Fixed copyright. Closes: #157623 Files: 3d9c08950208cfdee13128a22520f457 50932 interpreters extra libnet-rawip-perl_0.09d-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGOEycGpQPNsdIRAl0uAJ0YGrpXclw6jDPiqUU9+culXCSFsACfYQ7v dhTcsDibNa5wVWd0r74Sdyw= =IZcD -END PGP SIGNATURE-
Uploaded python-imaging 1.1.3-2 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Aug 2002 14:53:50 +0200 Source: python-imaging Binary: python-imaging-tk python2.1-imaging-tk python2.1-imaging python-imaging python-imaging-doc python-imaging-sane python2.2-imaging-sane python2.2-imaging python2.1-imaging-sane python2.2-imaging-tk Architecture: m68k Version: 1.1.3-2 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Simon Richter [EMAIL PROTECTED] Description: python2.1-imaging - The Python Imaging Library. python2.1-imaging-sane - The Python Imaging Library SANE interface. python2.1-imaging-tk - The Python Imaging Library (Module with Tk support). python2.2-imaging - The Python Imaging Library. python2.2-imaging-sane - The Python Imaging Library SANE interface. python2.2-imaging-tk - The Python Imaging Library (Module with Tk support). Changes: python-imaging (1.1.3-2) unstable; urgency=low . * Also switched python-imaging-sane and python-imaging-tk to 2.2 as default version * Dropped python 1.5 packages Files: e34fd0549a59a6059f7c1420ca7f3d8a 184074 graphics optional python2.1-imaging_1.1.3-2_m68k.deb 38d436ba19418ebee226be086b0730e1 23562 graphics optional python2.1-imaging-tk_1.1.3-2_m68k.deb 375fc981828b6e3bef18eae872f79ccc 29288 graphics optional python2.1-imaging-sane_1.1.3-2_m68k.deb f9c3136c9d33cdf635c49b3afff1f19c 184948 graphics optional python2.2-imaging_1.1.3-2_m68k.deb 7121eab3febb601fd9fb807c37a92c71 23554 graphics optional python2.2-imaging-tk_1.1.3-2_m68k.deb 7cd349714010edfb2b0f72909bcbd7cc 29666 graphics optional python2.2-imaging-sane_1.1.3-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cQGrEycGpQPNsdIRAgUOAJoD2EGII90JXoGocvXagMk7HR2RgQCdHSpg ze3eEPSiZMNMjgLbSFF9zOw= =cexr -END PGP SIGNATURE-
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Fri, 2002-08-30 at 14:36, Branden Robinson wrote: I think it would be fair to tar mpg321 with the brush of non-free when ^un? that clearly wasn't your intent when you wrote it. Having a giant corporation smash your First Amendmendment[1] right to express yourself I, personally, am glad you exercised your first amendment right to write that word. via computer code is quite punishment enough. I have to admit that I'm considering just dropping development of mpg321 altogether, particularly if it's our judgement that we can't ship it. I can't say that I'd be overly sad in that case - the only mp3s I acquire these days are illegal ones my friends send me, as I encode all my CDs to Ogg now - but it's still a sign that we are just so utterly unimportant in a society ruled by the megacorps. [1] Okay, so you're Canadian, UDHR or whatever. I'm perfectly happy to ?? No amendments are needed; it's right in the Canadian Constitution. stand up for the First Amendment rights even of people who aren't governed by the U.S. Constitution. That makes me doubly-damned according to the Republican Party, I think. *FREE SPEECH* for *FOREIGNERS*!?!??? WHAT KIND OF GODLESS HEATHEN COMMONIST[sic] CRAP IS THIS? Thank God for multi-party systems. -- Joe Drew [EMAIL PROTECTED] [EMAIL PROTECTED] This particular group of cats is mostly self-herding. -- Bdale Garbee
Re: RFC: Handling of certificates in Debian
On Sat, Aug 31, 2002 at 12:18:04AM +0100, Andrew McDonald wrote: Even the hostname check can be problematic - does the user really need to accept the certificate every time because the name doesn't match? I think the issue is this: if no hostname check is done, how to you know you really are authenticating the remote host by the certificate you think you should be (say www.secure.org) and not another certificate instead (say www.crackers.com)? You might think you are accessing www.secure.org, but if you authenticated the remote host with www.crackers.com, chances are you may not be. Of course, if the user manually checks the certificate, there would be no problems, but how many people will manually check? (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). (I've solved this for mutt by using a cache where I save the hostname against the certificate fingerprint, mozilla does something similar.) I would imagine you would have to manually update this each time a new certificate is issued (unless I am mistaken). -- Brian May [EMAIL PROTECTED]
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Sat, Aug 31, 2002 at 12:15:48AM -0400, Joe Drew wrote: On Fri, 2002-08-30 at 14:36, Branden Robinson wrote: I think it would be fair to tar mpg321 with the brush of non-free when ^un? Yes. that clearly wasn't your intent when you wrote it. Having a giant corporation smash your First Amendmendment[1] right to express yourself I, personally, am glad you exercised your first amendment right to write that word. Hm. I have to admit that I'm considering just dropping development of mpg321 altogether, particularly if it's our judgement that we can't ship it. I can't say that I'd be overly sad in that case - the only mp3s I acquire these days are illegal ones my friends send me, as I encode all my CDs to Ogg now - but it's still a sign that we are just so utterly unimportant in a society ruled by the megacorps. I have to agree. :( [1] Okay, so you're Canadian, UDHR or whatever. I'm perfectly happy to ?? Universal Declaration of Human Rights. A document ratified by the U.N., I believe, which of course means nothing in Amerika. Sorry for all the typos. I guess I got excited and had an oggasm, which interfered with my typing. -- G. Branden Robinson|You can have my PGP passphrase when Debian GNU/Linux |you pry it from my cold, dead [EMAIL PROTECTED] |brain. http://people.debian.org/~branden/ |-- Adam Thornton pgpodxXB52xIR.pgp Description: PGP signature
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
On Sat, Aug 31, 2002 at 07:06:47AM +1000, [EMAIL PROTECTED] wrote: In a couple of days uncompressed Packages files for unstable will cease to be generated, and bzip2'ed Packages files will be generated in their place (actually, if you look carefully, they're already being generated). Sources.bz2 files are being added too. If you have any scripts looking at the uncompressed Packages files, you should change them to look at either the gzip or bzip2 versions now. this break apt-proxy with rsyncing Packages files. Please don't remove the normal uncompressed Packages files. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Make a software that is foolproof, and someone will make a better fool. pgpmAN2YpE0Ba.pgp Description: PGP signature
Re: Should we customize apps for a common debian-look?
On Fri, Aug 30, 2002 at 03:43:32PM +0200, Erich Schubert wrote: Redhat seems to be going to use a common look for their desktops (GNOME as well as KDE) in their new beta featuring a new icon set. Check out the screenshots at http://www.gnomedesktop.org/article.php?sid=616mode=order=0 I like them and i think they are impressive... It's one of the things Apple proved: desktop and apps that look smooth do make their users feel comfortable with them ;) While I think that it's generally a good idea to integrate these both desktops in as many ways as possible, I think that this is something that should be tackled upstream. We should stick with the default look of those desktop environments. - Sebastian
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
Le Fri, Aug 30, 2002 at 05:21:12PM -0600, Jason Gunthorpe écrivait: Then apt, or debian-cd, needs to be fixed. *shrug* Huh. debian-cd can just uncompress them, but file: uris are a bit of a pickle. debian-cd uses apt (with file uris) to get a handle on the mirror. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com
lack of libbz2 bindings [Was: Packages.bz2, ...]
On Fri, Aug 30, 2002 at 05:34:48PM -0500, Adam Heath wrote: Presuming things continue to work in unstable, the same change will be made to testing in a few weeks. Similarly, the Contents-*.gz files for unstable will probably be switching to .bz2 in the not too distant future. The changes uncomrpessed - .gz seems fine to me, but the changes .gz - .bz2 is IMO a bit risky. I'm thinking about the lack of binding for libbz2 library (or at least the .deb of them) for a lot of programming languages (e.g.: perl, python, ocaml seems to me to be missing such a binding). I have a lot of scripts (and I suppose a lot of people have too) that parse .gz version of debian db and if you switch it all to .bz2, this can be a problem. Obviously we can start writing, packaging, libbz2 binding and also is a minor problem if changing only Contents* file; this mail is just to add some relevance to this aspect. My 0.02 Eur, Cheers. -- Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy [EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! -- G.Romney pgpKUMANiMuEO.pgp Description: PGP signature
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
On Fri, 2002-08-30 at 23:05, Goswin Brederlow wrote: That will also break rsyncing them, which saves a lot. Let's just keep pestering gzip upstream to include the rsyncable patch.
Re: Work-needing packages report for Aug 30, 2002
On Fri, 30 Aug 2002, Rodrigo Henriquez wrote: I don't know if this is the place to send this mail, so sorry if i'm wrong. I like contribute in some of the following projects : emelfm (#158150), orphaned 119 days ago Description: file manager for X/gtk gadfly (#113080), orphaned 342 days ago Description: SQL database and parser generator in Python gide (#138039), orphaned 170 days ago Description: Gnome Integrated Develoment Environment gtkfind (#138075), offered 170 days ago Description: Graphical File Finder If you want to adopt them, feel free to do so. Make sure to make your intention clear in the BTS (http://www.debian.org/devel/wnpp will tell you what an ITA is). If you're not a DD yet, you can find a sponsor on debian-mentors and/or debian-qa (which I consider ontopic because the packages are orphaned ATM). If you only want to fix certain bugs without becoming their maintainer that is apprechiated too. Just send a patch to the BTS. Perhaps you CC debian-qa and ask for someone to apply, build and upload it. yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/
Re: Should we customize apps for a common debian-look?
#include hallo.h * Sebastian Rittau [Sat, Aug 31 2002, 03:44:31AM]: I like them and i think they are impressive... It's one of the things Apple proved: desktop and apps that look smooth do make their users feel comfortable with them ;) While I think that it's generally a good idea to integrate these both desktops in as many ways as possible, I think that this is something that should be tackled upstream. We should stick with the default look of those desktop environments. I think we just need a meta package which contains the color scheme data and pixmaps and some debconf questions aka: Would you like to use a uniform theme (colors, icons) for all users? If yes, which one?. Options: - Debian Theme (dark) - Debian Theme (bright) - Some Other Theme - use default theme of each software part This metapackage should be installed as one of the first when installing x-window-system task package. When a WM or desktop environment are configured in postinst, they can look for the debconf data of the-meta-package, generate a theme for their purposes (or even include prepared theme files in the package) and install it as default. OR SET IT as recommended theme if they offer a pre-setup dialog like KDE does. Gruss/Regards, Eduard. -- Gromitt Joey: wie drauf bekommen... habe hier kein netzanschlus (permission denied in der Firma) und Floppy hat das Ding nicht :) Joey dann mach's @home Gromitt Joey: aber ich will ich das jetzt machen :) *stampf* .. :) Joey Gromitt, kauf Dir 1 Netzanschluss. Wieso begibst Du Dich auch in die Wueste, wenn Du was trinken willst. *kopfschuettel* -- #debian.de
Re: why is /usr/sbin/install-info a perl script!!!
On Fri, Aug 30, 2002 at 11:09:04PM -0400, Jack Howarth wrote: I looked at a Yellow Dog Linux machine and noticed, however, that they had a texinfo 4.2 source package that builds an info package with a binary /usr/sbin/install-info instead of the perl version we have. Why is that and why don't we just NMU texinfo in sid to start building a binary install-info until perl 5.80's regex stops leaking memory like a sieve? What amazes me here the most is that the first thing that pops into your head as a solution is a non-maintainer upload. My god, sometimes I really think we need to raise the bar even higher. -- 2. That which causes joy or happiness.
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
On Sat, Aug 31, 2002 at 10:05:10AM +0200, Michael Bramer wrote: On Sat, Aug 31, 2002 at 07:06:47AM +1000, [EMAIL PROTECTED] wrote: In a couple of days uncompressed Packages files for unstable will cease to be generated, and bzip2'ed Packages files will be generated in their place (actually, if you look carefully, they're already being generated). Sources.bz2 files are being added too. If you have any scripts looking at the uncompressed Packages files, you should change them to look at either the gzip or bzip2 versions now. this break apt-proxy with rsyncing Packages files. Again, the correct solution, which is far more efficient in all respects, is to get pdiffs implemented (ideally with diff --ed, bzip2'ed, rather than context and gzip), both in apt-ftparchive and apt-get. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpicT0xqf6zC.pgp Description: PGP signature
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
On Sat, 31 Aug 2002, Anthony Towns wrote: On Sat, Aug 31, 2002 at 10:05:10AM +0200, Michael Bramer wrote: On Sat, Aug 31, 2002 at 07:06:47AM +1000, [EMAIL PROTECTED] wrote: In a couple of days uncompressed Packages files for unstable will cease to be generated, and bzip2'ed Packages files will be generated in their place (actually, if you look carefully, they're already being generated). Sources.bz2 files are being added too. If you have any scripts looking at the uncompressed Packages files, you should change them to look at either the gzip or bzip2 versions now. this break apt-proxy with rsyncing Packages files. Again, the correct solution, which is far more efficient in all respects, is to get pdiffs implemented (ideally with diff --ed, bzip2'ed, rather than context and gzip), both in apt-ftparchive and apt-get. Still, the Packages files should only be removed after no software in our stable distribution depends on it. If you remove the Packages file from unstable now you will break apt-proxy (and perhaps other tools too). Please don't. yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/
Re: lack of libbz2 bindings [Was: Packages.bz2, ...]
On Sat, Aug 31, 2002 at 11:15:17AM +0200, Stefano Zacchiroli wrote: The changes uncomrpessed - .gz seems fine to me, but the changes .gz - .bz2 is IMO a bit risky. I'm thinking about the lack of binding for You misread the mail. .gz will continue to be available, .bz2 will be there as well and the uncompressed files will be dropped. Greetings Torsten pgp30WliV1UYy.pgp Description: PGP signature
Re: why is /usr/sbin/install-info a perl script!!!
On Sat, Aug 31, 2002 at 12:15:51PM +0200, Josip Rodin wrote: What amazes me here the most is that the first thing that pops into your head as a solution is a non-maintainer upload. My god, sometimes I really think we need to raise the bar even higher. As long as people are only talking about doing an NMU I don't think it is a problem. Greetings Torsten pgpk7VO5XoxBw.pgp Description: PGP signature
Re: RFC: Handling of certificates in Debian
On Sat, 31 Aug 2002, Brian May wrote: On Sat, Aug 31, 2002 at 12:18:04AM +0100, Andrew McDonald wrote: Even the hostname check can be problematic - does the user really need to accept the certificate every time because the name doesn't match? I think the issue is this: if no hostname check is done, how to you know If no hostname check is done, it is a security bug. If no server and client certificate checks are done (and implemented), it is a security bug. (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. -- 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: More manpower to our core teams
On Sat, Aug 31, 2002 at 01:44:18PM +0200, Torsten Landschoff wrote: So here is the list of the new nominations: FTP Archive Maintenance: Ryan Murray [EMAIL PROTECTED] You forgot Randall Donald there. System Administration:Ryan Murray [EMAIL PROTECTED] Philip Hands [EMAIL PROTECTED] Er, Phil has been one of the four admins almost everywhere, before Ryan joined. Arguably he isn't involved as much, but still... Anyway, I don't see the point of posting their email addresses. -- 2. That which causes joy or happiness.
Re: why is /usr/sbin/install-info a perl script!!!
On Sat, Aug 31, 2002 at 01:26:17PM +0200, Torsten Landschoff wrote: What amazes me here the most is that the first thing that pops into your head as a solution is a non-maintainer upload. My god, sometimes I really think we need to raise the bar even higher. As long as people are only talking about doing an NMU I don't think it is a problem. No, it is a problem that they don't consider the option of simply communicating with the maintainers before even thinking of an NMU. (Mailing -devel may or may not include communication with the maintainers.) -- 2. That which causes joy or happiness.
Lintian reports for sid at lintian.d.o
Hi, For the record, http://lintian.debian.org/ now has reports for the current contents of sid, i.e. unstable. Knock yourself out, or something. :) -- 2. That which causes joy or happiness.
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
Hi All, we had similar problem with AGNULA, about mp3 and after an accurate investigation we have reached the following conclusions (a deliverable on free software will be soon ready at www.agnula.org): (Inter alia i suggest to read the following document, http://web.media.mit.edu/~eds/mpeg-patents-faq ) [quoting from an internal discussion: 1) mp3 (Mpeg-1 layer 3) is not patented per se; the format documents are public, they are published by www.iso.ch (TR bought them from them) and these documents describe precisely how the file format is done to comply to the Mpeg1 layer 3 standard; anybody can build an mp3 file This is important to understand: 2) there are Fraunhofer and Thompson patents for some encoding *algorithms* which Free Software encoders may therefore not use; 3) to my knowledge, neither bladeenc nor lame do use these algorithms (they are mainly for encoding at low bit rate, something these encoders don't do well - they were'nt designed for that) 4) however, from what I understand Fraunhofer and Thompson oblige bladeenc and lame developers to distribute *sources* and not *binaries* to always check that they are not using patented algorithms (now how's that for another use of source visibility :() 5) so, these encoders may not be distributed in binary-only form, I did'nt know of any patenting on decoding, but I may assume that the same concept applies end of quoting] NOTE: developing for bladeenc has been stopped by the author who's converting himself into a ogg user...:-) I think solution for Debian, and in general would be, untill ogg becomes more popular: - dropping mp3 enconders support, and asking applications authors like audacity (a sound editor) to support *export* only for ogg and not mp3. In this way the number of new encoded mp3 files should start to drop - mp3 decoders should be supported. Too many mp3 still around, getting read of them would make Debian less interesting for a number of users (i dont think they need to go in non-free) - offer mp3 to ogg convert tools, with big warning about possible quality loss (BTW i converted an mp3 -- wav -- ogg and i dint noticed such an horrendous loss of quality). (people using gnapster gtk-gnutella and these kind of software should start to share only ogg...) These are the conclusions we reached i thought it was important to share with you. thank you, marco trevisani -- ** * marco trevisani* * http://trevisani.mine.nu [EMAIL PROTECTED] * * http://www.agnula.org -- A GNU/Linux Audio Distribution* * Neither MS-Word nor MS-PowerPoint attachments please: * * See http://www.fsf.org/philosophy/no-word-attachments.html * ** pgp1Lc3SiwCbv.pgp Description: PGP signature
Re: [ANNOUNCE] Debian Developer Packages Overview
On Tue, Aug 27, 2002 at 2:43:29PM +0100, Daniel Silverstone wrote: Also, if you search for my GPG key id (20687895) then I get a listing of my packages and also those maintained by [EMAIL PROTECTED] We've had issues of my being mistaken for Daniel Stone in the past, and I don't appreciate it :) (Neither does he I should imagine :) You poor, poor bastard. I recommend a name change post-haste. I'd like to sincerely apologize to you for any humiliation caused for being confused with me. Cheers, The real DanielS (o/~ I'm the real DanielS ...) -- Daniel Stone [EMAIL PROTECTED] http://raging.dropbear.id.au KDE Developer [EMAIL PROTECTED]http://www.kde.org Kopete: Multi-protocol IM client http://kopete.kde.org pgpL5mBQbfWYr.pgp Description: PGP signature
Re: dpkg bug #156463: second opinions?
Adam Heath wrote: On Fri, 30 Aug 2002, Adam C Powell IV wrote: Greetings, Just writing to request a second opinion on this bug. Current dpkg behavior does not allow a package to replace a directory with a symlink during upgrade. This broke a libc6-dev upgrade when I made an unstable chroot from a potato tarball on an ARM system a couple of months ago. See bug 151669 and the debian-arm thread I started a while ago (URL below) for details. http://lists.debian.org/debian-arm/2002/debian-arm-200208/msg00017.html Wichert promptly closed my bug reporting this, #156463, saying this is the way it's supposed to be. IMHO, this is broken behavior, as it creates a limitation on package upgrading which has nothing whatsoever to do with policy, or with any sound reason for that matter. Furthermore, that upgrade behaves differently in this regard from remove then install (which works just fine) sounds bizarre. Is there something I'm overlooking such that things should be this way? Please cc me in replies as I'm not subscribed. So, what happens when someone does this: == mkfs.ext2 /dev/sda5 mount /dev/sda5 /mount/sda5/ cp -a /usr /mount/sda5/usr cp -a /var /mount/sda5/var rm -rf /usr rm -rf /var ln -s mount/sda5/usr usr ln -s mount/sda5/var var Uh, then /usr and /var are simlinks? I think you misunderstand part of the bug. There was a directory which was only in use by a single package. doing dpkg --remove libc6-dev would have removed it. Having removed it, dpkg --install libc6-dev...deb would have created it as a symlink. But merely upgrading libc6-dev resulted in its being left as an empty directory, causing packages to fail to build (because it was a subdir of /usr/include/asm). In your situation, you replace directories which *tons* of packages (every package?) use, which is an entirely different matter. If *any* other installed package had put files in /usr/include/asm/arch, then I could understand not replacing that dir with the new symlink. But they didn't. How is this not a dpkg bug? Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: why is /usr/sbin/install-info a perl script!!!
On Fri, Aug 30, 2002 at 11:09:04PM -0400, Jack Howarth wrote: the perl version we have. Why is that and why don't we just NMU texinfo in sid to start building a binary install-info until perl 5.80's regex stops leaking memory like a sieve? Why wouldn't we fix perl instead? You're not one of these random perl haters are you? How boring. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
ardour
Hi debian-devel! It's about ardour, a Ardour is a multichannel hard disk recorder (HDR) and digital audio workstation (DAW) [http://ardour.sourceforge.net/]. An ITP was filed a while ago [http://bugs.debian.org/95870]. It is quite big, written in C++, making heavy use of jack, ladspa, midi, rt. Way back last year, Mandrake distributed a C++ library compiled with options, that caused ardour not to be compilable and/or showing strange behaviour, strange bugs... Users complained they were not able to compile ardour because of these libraries and C++'s ABI instability. So Paul Davis (upstream) decided to include all C++ libraries except libstdc++ (I don't understand that exception) in the CVS tree. Namely libgtk-canvas, libgtkmm, libsigc++, libart. They are built along with ardour, compiled as static objects and linked statically. The other C++ libraries (libpbd, libmidi++, libgtkmmext, libardour) belong to ardour and are in the CVS anyway. The libraries having to do with GUI (libgtk-canvas, libgtkmm, libart, libgtkmmext) are statically linked into the ardour executable, the others are statically linked together into libardour (libpbd, libmidi++, libardour, libsigc++) which itself is shared. That makes the build process overly long and the binaries and the library overly large. In my attempt to prepare ardour for Debian I removed the external libraries and linked against the ones in Debian dynamically. [http://n.ethz.ch/student/robertjo/download/ardour/]. Paul reacted with I will firmly and publically denounce any packaging of Ardour that use dynamic linking to any C++ library except (and possibly including) libstdc++. (He means linking to libraries not compiled in one run with ardour). http://boudicca.tux.org/hypermail/ardour-dev/2002-Jun/0068.html Although stating this is problably not against the GPL, disobeying Paul as upstream won't make maintaining the Debian package very easy. It is clearly against policy and libpkg-guide. http://www.debian.org/doc/debian-policy/ch-files.html#s11.2 http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN199 Other threads about the discussion: http://boudicca.tux.org/hypermail/ardour-dev/2002-May/0415.html http://boudicca.tux.org/hypermail/ardour-dev/2002-Jun/0038.html http://boudicca.tux.org/hypermail/ardour-dev/2002-Aug/0256.html So there remain the following options: a) No ardour in Debian b) build the libraries with ardour and link statically against them (Pauls wish, against policy and my feelings) c) dynamically link against the libraries in Debian (against Paul, compliant with policy and my feelings) d) distribute *-dbg binaries that are statically compiled as a reference that is to be used prior to writing bug reports (I don't know how Paul thinks about this, whether he he wants fresh libraries to be compiled and whether that's okay with policy. At least lintian complains, though.) e) introduce a system to check the libraries for their correct compilation flags at runtime (I have no idea how to do that) What are the opinions? Robert. -- pgptcFJfTQTpy.pgp Description: PGP signature
install-info and LSB
Has there ever been any discussion of the binary /usr/sbin/install-info in terms of the Linux Standard Base? I ask because dpkg is providing a perl based version of this utility whereas all other distros appear to be using binary only version. This came up because the regex in perl 5.80 is buggy and breaks the perl install-info for building glibc now. As a workaround I rebuilt texinfo-4.2 with all of the redhat install-info related patches and substituted this binary only version for the one dpkg installs. While this version is sufficient for building the packages there does appear to be some incompatibilities related to installing glibc-doc with this version of install-info. I am wondering if we aren't violating the spirit if not the letter of LSB by using a non-standard version of install-info. Wouldn't it be better to move install-info out of dpkg, add any required additional functionality to the texinfo version of install-info and push those changes upstream to the texinfo maintainers? Since install-info is being called at both the Makefile level in builds as well as at the packager level (eg rpm or dpkg) it seems that we would be much better off if the install-info used by debian was uniform with what everyone else is using (be it a perl or binary version). Any comments? Jack
Re: ardour
On Sat, 31 Aug 2002, Robert Jordens wrote: Users complained they were not able to compile ardour because of these libraries and C++'s ABI instability. Distribution users (well, at least Debian's) don't have to worry about this, since you (the maintainer) will have taken care of those details already, and our dependency system will keep the build sane. Failing to build from source is a severe bug and causes the package to be removed from the stable releases, after all. So Paul Davis (upstream) decided to include all C++ libraries except libstdc++ (I don't understand that exception) in the CVS tree. Namely Ugh. No way in hell, this is prone to cause problems, including missing security updates, major breakage on uncommon archs, and so on. and are in the CVS anyway. The libraries having to do with GUI (libgtk-canvas, libgtkmm, libart, libgtkmmext) are statically linked into the ardour executable, the others are statically linked together into libardour (libpbd, libmidi++, libardour, libsigc++) which itself is shared. You cannot statically link libs in dynamic libs easily in many architectures, unless they are all built with -fPIC and other small details that are all too easy to get wrong. In my attempt to prepare ardour for Debian I removed the external libraries and linked against the ones in Debian dynamically. This is the right thing to do. I will firmly and publically denounce any packaging of Ardour that use dynamic linking to any C++ library except (and possibly including) libstdc++. (He means linking to libraries not compiled in one run with ardour). http://boudicca.tux.org/hypermail/ardour-dev/2002-Jun/0068.html He is wrong on doing that. It is his program, but the same way we do not go murderous on upstream maintainers that do not take the (extreme) pains to get sonames, library versioning, and other _distribution_ problems (because they are usually not a problem to a single user dealing with his own machine), upstream should not go in a fit or rage due to distributions doing what is right (for distributions). Although stating this is problably not against the GPL, disobeying Paul as upstream won't make maintaining the Debian package very easy. No, it will not. Maybe Paul can be made to understand that what you are doing is not going to damage his software, and that the Debian build will always be only an apt-get source -b away... It is clearly against policy and libpkg-guide. Yes. Such hideous linking [for something in a distribution, again this is NOT about a lone user and his machine] is not acceptable in Debian. a) No ardour in Debian Acceptable, IMHO. b) build the libraries with ardour and link statically against them (Pauls wish, against policy and my feelings) Not acceptable, no hideous hacks here please. c) dynamically link against the libraries in Debian (against Paul, compliant with policy and my feelings) Your call. d) distribute *-dbg binaries that are statically compiled as a reference that is to be used prior to writing bug reports (I don't know how Paul thinks about this, whether he he wants fresh libraries to be compiled and whether that's okay with policy. At least lintian complains, though.) How many Ardour users are able to use gdb to track down bugs? If the answer is the standard not many, you needn't do this IMHO. You will have to properly filter all bug reports so that you send Paul information he can use, but that's already implied in the duty of a downstream maintainer... -- 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: [ardour-dev] ardour
It's about ardour, a Ardour is a multichannel hard disk recorder (HDR) and digital audio workstation (DAW) [http://ardour.sourceforge.net/]. An ITP was filed a while ago [http://bugs.debian.org/95870]. It is quite big, written in C++, making heavy use of jack, ladspa, midi, rt. =20 Way back last year, Mandrake distributed a C++ library compiled with options, that caused ardour not to be compilable and/or showing strange behaviour, strange bugs...=20 This was not the only reason. Similar breakage occurs as soon as the user acquires a C++ library in binary format that was compiled by a g++ with either different options and/or a different ABI compared the one used to compile and link the application. If someone upgrades from g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every* C++ library on their system, problems will arise sooner or later (depending on how many C++ apps they run and how they were built). Users complained they were not able to compile ardour because of these libraries and C++'s ABI instability. They were able to compile things. If they could not have done this, life would have been easier. Instead, they compiled them, and then things didn't work. So Paul Davis (upstream) decided to include all C++ libraries except libstdc++ (I don't understand that exception) in the CVS tree. Namely libstdc++ is currently distributed with g++. as a result, the libstdc++ that you link against is more or less always compiled by the same version of g++ used to compile the C++ program. libgtk-canvas, libgtkmm, libsigc++, libart. They are built along with ardour, compiled as static objects and linked statically. The other C++ libraries (libpbd, libmidi++, libgtkmmext, libardour) belong to ardour and are in the CVS anyway. The libraries having to do with GUI (libgtk-canvas, libgtkmm, libart, libgtkmmext) are statically linked into the ardour executable, the others are statically linked together into libardour (libpbd, libmidi++, libardour, libsigc++) which itself is shared. this is not quite correct. libardour is the only one built as a shared library. all others are statically linked into the final exectuable. the shared library is just a development convenience - its where the most significant changes happen and avoiding a static relink every time that library changes its internals saves a considerable amount of time. That makes the build process overly long and the binaries and the library overly large. It also makes them stable and immune to compiler version SNAFUs. e) introduce a system to check the libraries for their correct compilation flags at runtime (I have no idea how to do that) this also needs to check the ABI of the compiler used. a library built by g++ 3.2 cannot be used with g++ 2.95, for example. --p
Re: ardour
On Sat, 31 Aug 2002 04:48 pm, Robert Jordens wrote: So there remain the following options: a) No ardour in Debian b) build the libraries with ardour and link statically against them (Pauls wish, against policy and my feelings) c) dynamically link against the libraries in Debian (against Paul, compliant with policy and my feelings) d) distribute *-dbg binaries that are statically compiled as a reference that is to be used prior to writing bug reports (I don't know how Paul thinks about this, whether he he wants fresh libraries to be compiled and whether that's okay with policy. At least lintian complains, though.) I suggest both C and D. -- 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: [ardour-dev] ardour
On Sat, 31 Aug 2002, Paul Davis wrote: Way back last year, Mandrake distributed a C++ library compiled with options, that caused ardour not to be compilable and/or showing strange behaviour, strange bugs...=20 This was not the only reason. Similar breakage occurs as soon as the user acquires a C++ library in binary format that was compiled by a g++ with either different options and/or a different ABI compared the one used to compile and link the application. If someone upgrades from g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every* C++ library on their system, problems will arise sooner or later (depending on how many C++ apps they run and how they were built). We are very, very, very painfully aware of that problem. We regard any such inconsistencies as problems to be fixed, btw. See the immense, monstruous thread about the ongoing C++ mass-recompile to switch to gcc 3.2 in debian-devel... Also, should ardor fail to work because a C++ lib is misbehaving, that is considered a bug on that library, and it will have to be fixed. this is not quite correct. libardour is the only one built as a shared library. all others are statically linked into the final exectuable. the shared library is just a development convenience - its where the most significant changes happen and avoiding a static relink every time that library changes its internals saves a considerable amount of time. The big problem with linking a lot of stuff statically into ardor *for Debian*, is that ardor now needs to be explicitly recompiled and reuploaded for every single security issue in any of the component libs. We cannot do that kind of service. It also makes them stable and immune to compiler version SNAFUs. Indeed. Debian stable is also supposed to be stable and immune to compiler version SNAFUs. As for unstable, the snafus get fixed quite fast, and users that cannot deal with them by themselves are told to stay away from Debian unstable. this also needs to check the ABI of the compiler used. a library built by g++ 3.2 cannot be used with g++ 2.95, for example. Yes. I think there is some Debian team trying to fix this up once and for all, along with the gcc guys. But I might be wrong. -- 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: [ardour-dev] ardour
Le sam 31/08/2002 à 17:18, Paul Davis a écrit : This was not the only reason. Similar breakage occurs as soon as the user acquires a C++ library in binary format that was compiled by a g++ with either different options and/or a different ABI compared the one used to compile and link the application. If someone upgrades from g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every* C++ library on their system, problems will arise sooner or later (depending on how many C++ apps they run and how they were built). This is the work of the distribution to get it right. Debian has already plans to make a smooth G++ transition without breakage. This does not justify at all the use of static linking (which is evil imho). They were able to compile things. If they could not have done this, life would have been easier. Instead, they compiled them, and then things didn't work. Debian users don't have to compile things. This is the maintainer's work, helped by the autobuilders. Moreover, the build dependencies can guarantee you the package will build fine if you try at home. this is not quite correct. libardour is the only one built as a shared library. all others are statically linked into the final exectuable. the shared library is just a development convenience - its where the most significant changes happen and avoiding a static relink every time that library changes its internals saves a considerable amount of time. No, the shared library is a user convenience. It avoids rebuilding everything that depends on a library after a security update. It avoids bloating the hard drive with static binaries. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: [ardour-dev] ardour in Debian
On Sat, Aug 31, 2002 at 11:18:26AM -0400, Paul Davis wrote: This was not the only reason. Similar breakage occurs as soon as the user acquires a C++ library in binary format that was compiled by a g++ with either different options and/or a different ABI compared the one used to compile and link the application. If someone upgrades from g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every* C++ library on their system, problems will arise sooner or later (depending on how many C++ apps they run and how they were built). The irony here is that Debian has stuck to g++ 2.95 for this reason, and is now preparing a plan for upgrading to g++ 3.2 in a sane and consistent manner. This will cause upgrades of Debian packages to go smoothly and correctly, but it may not work for locally compiled programs because those don't come with sufficient dependency information. If ardour can't be packaged for Debian, or if it links statically with a lot of C++ libraries, then the transition is less likely to be smooth. It's hard to be sure about this while the details are still being worked out. Still, there's a much better chance of it going right if ardour is simply packaged according to Debian policy, because that's what our upgrade plan will expect. Richard Braakman
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Sat, 31 Aug 2002 08:53:11 -0400, marco trevisani [EMAIL PROTECTED] wrote: 3) to my knowledge, neither bladeenc nor lame do use these algorithms (they are mainly for encoding at low bit rate, something these encoders don't do well - they were'nt designed for that) 4) however, from what I understand Fraunhofer and Thompson oblige bladeenc and lame developers to distribute *sources* and not *binaries* to always check that they are not using patented algorithms (now how's that for another use of source visibility :() If they insist we are violating their patent, it is their job to prove it, no? Guilty unless proven otherwise is illegal (at least in Japan). -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 Better just encrypt it all in your head :-). --- Derrick 'dman' Hudson, about encryption without any physical medium
Bug#159010: ITP: fonty-rg -- Set of fonts for linux console
Package: wnpp Version: N/A; reported 2002-08-31 Severity: wishlist * Package name: fonty-rg Version : 1.0 Upstream Author : Radovan Garabík [EMAIL PROTECTED] * URL : http://www.some.org/ * License : GPL Description : Set of fonts for linux console Based heavily on fonty package, fonty-rg contains fonts for linux console, including fonts for ISO-8859-1,2,3,4,5,6,7,8,9,10,11,13,14,15,16, KOI8-R,U,C, CP1250, CP1251, CP1252 codepages, as well as two unicode fonts with wide coverage, and an ISO-8859-16 ACM file. -- --- | Radovan Garabík http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
* Anthony Towns | Presuming things continue to work in unstable, the same change will be | made to testing in a few weeks. Similarly, the Contents-*.gz files for | unstable will probably be switching to .bz2 in the not too distant future. This will break debian-installer. It is probably easy to fix, but needs to be done. Just a FYI. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Debian based CD based distros
It appears that Debian is finally being used in the ways that we have been wishing for since before Bruce was DPL. YES, there are now some very impressive Debian-based distributions available from several sources. The first one I was shown by my neighbor is called Knoppix 3.1 and is produced by a German group. As a result it comes up in German, but there is a simple fix that will boot it in English (boot: knoppix lang=us) that only requires you to know that the equal sign is a shift 0. This CD boot up on any Intel machine, recongizes the hardware, negotiates an IP address, and provides a very well crafted KDE desktop. Also included are three pieces of FREE music. The software recognizes the sound card in most hardware, and only a few clicks of the mouse are required to play some cool sounds that are distributed under what looks like a DFSG compliant license (modification a distribution are both permitted} if you consider a wave file adequate source for music. While that was pretty impressive, my neighbor showed me bb which is an ascii art demo program with full sound and impressive ascii artistic displays. Open Office is also provided, which allows you to boot this CD up on an M$ machine without any impact on the file system, and edit Word and Excell documents on that machine without having to suffer the hangs and other failures I see every day at work. More than that, I will be using this CD when I need to work at the local library, and don't wish to leave any tracks on their machine. (Several libraries are worried in this day of terrorism driven government that their hardware might be confiscated to preserve evidence of terrorist activities [more likely to provide free hardware for the local constabulary], and this CD could allow them to run esentially diskless systems. Either a floppy or a zip drive could be provided by the user to carry away desired information, leaving the libraries hardware void of any interesting information, with no more reason for its confiscation...) The other CD I have seen is provided by CheapBytes, and is simply called DemoLinux 3.01. I haven't figured out who produces it, but it is very similar to the Knoppix CD except that it does not include the free music that Knoppix does. The main reason I mention these two excellent Debian spin-offs is that they both do a remoarkable on-the-fly hardware configuration for X and everything is wonderfully integrated and ready-to-use to a much greater extent that Debian is by itself. Those folks working on installation and configuration of the system could learn a lot from studying these CDs, not that we need to deliver a CD based release, but that we need a much quieter and more user friendly installation. While SUSE uses proprietary code to provide a very hands-off installation, with great hardware detection and no-info X configuration, there are things that can be learned from this product as well. SUSE is soo nicely integrated that I have begun recommending it for installation as Work Station replacements for perviously Windows based shops. The learnign curve for the user is miniscule, as everything is layed out in a familiar fashion and Open Office (also provided) provides the look and feel of the older office suite from M$ which they are already familiar with. (and the $49 one time purchase price beates the $200 per seat that my office pays for the priviledge of using Windblows) I still recommend Debian for server applications. It is still more powerful and complete that the professional package that SUSE provides, but maybe that is only because I understand Debian configuration better than I do SUSE ;-) For those of you who have not seen Knoppix or DemoLinux, I highly recommend you take a look at them, you will be very proud of the use Debian has been put to by these distros. (Give me a ping if you need a Knoppix CD. I'll be glad to toast one for you...) Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Is this the correct mailing list for support questions regarding the Debian libarchive-zip-perl-0.11
Hi users, I am in need of assistance regarding the addTREE function in the libarchive-zip-perl-0.11. Is this the correct mailing list for support questions regarding the Debian libarchive-zip-perl-0.11. If not which mailing list would be the most appropriate? Regards, Normand Charette PathFinder Software [EMAIL PROTECTED] Regards, Normand Charette PathFinder Software [EMAIL PROTECTED]
Re: Debian based CD based distros
On Sat, Aug 31, 2002 at 01:42:36PM -0400, Dale Scheetz wrote: The first one I was shown by my neighbor is called Knoppix 3.1 and is produced by a German group. As a result it comes up in German, but there is a simple fix that will boot it in English (boot: knoppix lang=us) that only requires you to know that the equal sign is a shift 0. There appears to be an english ISO. Is this the one you are using? Downloading. It be a couple of hours before I can try it myself.
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Sat, 2002-08-31 at 11:39, Oohara Yuuma wrote: If they insist we are violating their patent, it is their job to prove it, no? Guilty unless proven otherwise is illegal (at least in Japan). Yes, this is true. However, we also have the burden of hiring legal counsel to defend ourselves, and this is the real problem: we plain can't afford to do so - very few people can (generally it's only corporations who do). So, while we will legally be considered not-guilty or not-liable until we are found otherwise (probably), we just plain don't have the resources to establish the precedent or our not-liable-ness, and so must simply bow to the patent holder's request - i.e., they get what they want without a fight from us. -- Joe Drew [EMAIL PROTECTED] [EMAIL PROTECTED] A veritable oggasm of patent law erupts and coats all readers of debian-devel
Re: Is this the correct mailing list for support questions regarding the Debian libarchive-zip-perl-0.11
On Sat, 31 Aug 2002 at 11:00:25AM -0700, PathFinder Software wrote: Is this the correct mailing list for support questions regarding the Debian libarchive-zip-perl-0.11. If not which mailing list would be the most appropriate? Usually help/questions should be placed on debian-user. Certain applications (like apache and a few others) have their own list. See http://list.debian.org for a full listing of available lists. Regards, -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/ | gpg --import XP Source Code: #include win2k.h #include extra_pretty_things_with_bugs.h #include more_bugs.h #include remote_admin_abilities_for_MS.h #include more_restrictive_EULA.h #include sell_your_soul_to_MS_EULA.h //os_over=Windows 2000 os_ver=Windows XP
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Sat, 31 Aug 2002 17:39, Oohara Yuuma wrote: 3) to my knowledge, neither bladeenc nor lame do use these algorithms (they are mainly for encoding at low bit rate, something these encoders don't do well - they were'nt designed for that) 4) however, from what I understand Fraunhofer and Thompson oblige bladeenc and lame developers to distribute *sources* and not *binaries* to always check that they are not using patented algorithms (now how's that for another use of source visibility :() If they insist we are violating their patent, it is their job to prove it, no? Guilty unless proven otherwise is illegal (at least in Japan). The presumption of innocence only applies to criminal law not civil law. Civil law (sueing) is based on the balance of probabilities. If the sources of bladeenc were obscured then a magistrate could probably be persuaded by a good lawyer that it was done for the reason of concealing wrong-doing. -- 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: Debian based CD based distros
Le Sat, Aug 31, 2002 at 01:42:36PM -0400, Dale Scheetz écrivait: The other CD I have seen is provided by CheapBytes, and is simply called DemoLinux 3.01. I haven't figured out who produces it, but it is very DemoLinux is done by 3 french (-speaking) guys (working in a parisian university) : http://www.demolinux.org/ I've seen it in action too, it's really nice. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com
Re: install-info and LSB
On Sat, 31 Aug 2002, Jack Howarth wrote: Has there ever been any discussion of the binary /usr/sbin/install-info in terms of the Linux Standard Base? I ask because dpkg is providing a perl based version of this utility whereas all other distros appear to be using binary only version. This came up because the regex in perl 5.80 is buggy and breaks the perl install-info for building glibc now. As a workaround I rebuilt texinfo-4.2 with all of the redhat install-info related patches and substituted this binary only version for the one dpkg installs. While this version is sufficient for building the packages there does appear to be some incompatibilities related to installing glibc-doc with this version of install-info. I am wondering if we aren't violating the spirit if not the letter of LSB by using a non-standard version of install-info. Wouldn't it be better to move install-info out of dpkg, add any required additional functionality to the texinfo version of install-info and push those changes upstream to the texinfo maintainers? Since install-info is being called at both the Makefile level in builds as well as at the packager level (eg rpm or dpkg) it seems that we would be much better off if the install-info used by debian was uniform with what everyone else is using (be it a perl or binary version). Any comments? Yes. you're a moron.
Re: Debian based CD based distros
#include hallo.h * Dale Scheetz [Sat, Aug 31 2002, 01:42:36PM]: The main reason I mention these two excellent Debian spin-offs is that they both do a remoarkable on-the-fly hardware configuration for X and everything is wonderfully integrated and ready-to-use to a much greater All this on-the-fly hardware detection became only possible because of the excellent work done by Klaus Knopper and LinuxTag team. They are working extensively with the users and do required work to make hardware setup really working. Unfortunately, most of those autosetup is DWIW software. It does work with dirty tricks, but those tricks are the only way to make dirty broken hardware work. I suggested to use the files generated by Knoppix' tools as the default X config since it provides the most reliable auto-configuration I have ever seen, though Branden insisted on using his/Progeny's libdetect stuff. Dreaming a bit more, I would prefer having a small Knoppix as the installation system instead of D-I or PGI. Gruss/Regards, Eduard. -- Linux braucht kein Mensch, aber Mensch braucht Linux!
Non-Intel package uploads by maintainer
Since I have access to both Intel and Sparc hardware, it would be possible for me to upload both the i386 version and the Sparc version of the binary packages when I build a new release. Is there any reason not to do this? It seems that it might speed up the autobuild process, specially when it is a library like libgmp3 which other packages depend upon for their builds... The only problem I can see is in the construction of the dsc file. I get one built on the Intel and another one built on the Sparc. Must I do two uploads or is there a way to merge the two dsc files? TIA, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Non-Intel package uploads by maintainer
On Sat, Aug 31, 2002 at 03:09:52PM -0400, Dale Scheetz wrote: Since I have access to both Intel and Sparc hardware, it would be possible for me to upload both the i386 version and the Sparc version of the binary packages when I build a new release. Several people do this. It's not exactly common, but it's been done. Is there any reason not to do this? It seems that it might speed up the autobuild process, specially when it is a library like libgmp3 which other packages depend upon for their builds... I don't believe the buildds would care either way... The only problem I can see is in the construction of the dsc file. I get one built on the Intel and another one built on the Sparc. Must I do two uploads or is there a way to merge the two dsc files? It just takes a bit of manual hackery, and then update the GPG signature. -- 2. That which causes joy or happiness.
Re: Non-Intel package uploads by maintainer
On Sat, 31 Aug 2002, Dale Scheetz wrote: Is there any reason not to do this? It seems that it might speed up the autobuild process, specially when it is a library like libgmp3 which other packages depend upon for their builds... Not really. Once you upload the pkg, and in the next 15 minute time spam, the package is ACCEPTED, the buildds will start building it at that point. And, for small packages, this happens very quickly. The only slowdown is that those builds need to be signed.
Re: lack of libbz2 bindings [Was: Packages.bz2, ...]
On Sat, Aug 31, 2002 at 01:24:51PM +0200, Torsten Landschoff wrote: You misread the mail. .gz will continue to be available, .bz2 will be there as well and the uncompressed files will be dropped. quote Similarly, the Contents-*.gz files for unstable will probably be switching to .bz2 in the not too distant future. /quote switching sound to me like changing in favour of, but in facts I'm not a native english speaker. Sorry. Cheers. -- Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy [EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! -- G.Romney pgpGOxudcnhzz.pgp Description: PGP signature
UNSUBSCRIBE
Re: Non-Intel package uploads by maintainer
On Sat, Aug 31, 2002 at 03:09:52PM -0400, Dale Scheetz wrote: Is there any reason not to do this? It seems that it might speed up the Save you time, and if you aren't actually following the current status of the extra archs you build for, you might end up uploading it during an arch-specific transition, and require it to just be binNMU'd later on. autobuild process, specially when it is a library like libgmp3 which other packages depend upon for their builds... It won't speed things up much at all. The only problem I can see is in the construction of the dsc file. I get one built on the Intel and another one built on the Sparc. Must I do two uploads or is there a way to merge the two dsc files? Only a source build generates a dsc file. You shouldn't be building source more than once. The dsc files should also be identical, in any case. You _do_ need to use mergechanges on your .changes files and upload it as one, especially if you are on a slowlink. Otherwise the autobuilder might already have started building before your upload finishes, wasting the CPU (and buildd maintainer's) time. -- Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED]) The opinions expressed here are my own. pgpoWr6bK5j20.pgp Description: PGP signature
Re: why is /usr/sbin/install-info a perl script!!!
I am trying to get the glibc debian cvs for 2.2.92 to package (it builds and passes make check fine on debian ppc sid with the new gcc 3.2.1pre). However the buggy perl 5.80 in sid has broken install-info. I looked at a Yellow Dog Linux machine and noticed, however, that they had a texinfo 4.2 source package that builds an info package with a binary /usr/sbin/install-info instead of the perl version we have. Why is that and why don't we just NMU texinfo in sid to start building a binary install-info until perl 5.80's regex stops leaking memory like a sieve? Why are you making such a gigantic fuss and dragging in extra-debian groups (the LSB) and threatening NMU's when the maintainers of packages involved are actively working on the problem? Why do you not do basic reasearch before posting? It might help if you took the time to understand: 1. What debian install-info does. 2. What GNU install-info does. 3. Why blindly replacing one with the other is stupid. 4. Why perl is segfaulting. 5. Why it is not quite clear if this is a perl bug or an install-info bug. 6. Who already knows the answer to all of the above and is working on a fix. .. before mouthing off further on this subject. -- see shy jo pgp3ZO6lhMjDq.pgp Description: PGP signature
Re: lack of libbz2 bindings [Was: Packages.bz2, ...]
I demand that Stefano Zacchiroli may or may not have written... On Sat, Aug 31, 2002 at 01:24:51PM +0200, Torsten Landschoff wrote: You misread the mail. .gz will continue to be available, .bz2 will be there as well and the uncompressed files will be dropped. quote Similarly, the Contents-*.gz files for unstable will probably be switching to .bz2 in the not too distant future. /quote switching sound to me like changing in favour of, but in facts I'm not a native english speaker. Sorry. It looks to me like it's the files themselves which are doing the switching... applying s/switching/switched/ gives switched to. Would I be right in saying that only the filenames will be changed? ;-) I'd happily settle for deprecated in favour of (and dropped after sarge is released [1]) since this should allow those of us who are running stable [2] to grab the occasional binary package from testing or, possibly, unstable. [1] As opposed to after sarge releases. [2] On humanbrain-linux, if you're wondering. ;-) -- | Darren Salt | nr. Ashington, | linux (or ds) at | Linux PC, Risc PC | Northumberland | youmustbejoking | No Wodniws here | Toon Army | demon co uk | We've got Shearer, you haven't Join the group mind - become a Borg.
Re: Non-Intel package uploads by maintainer
Dale Scheetz [EMAIL PROTECTED] writes: Since I have access to both Intel and Sparc hardware, it would be possible for me to upload both the i386 version and the Sparc version of the binary packages when I build a new release. Is there any reason not to do this? It seems that it might speed up the autobuild process, specially when it is a library like libgmp3 which other packages depend upon for their builds... There are several reasons not to do this. Don't upload binaries at all. The autobuilder will check the build-process of your package. It will build in a clean chroot with proper build-depends. With proper versions of all tools. If you upload binaries you get the usual bugs of missing build-depends, wrong versions of tools or libraries and so on. Just because you had them installed. Only reason I see for binary uploads would be for archs that are far behind or packages that need that little extra time to build. (open office with its 4G space requirement also comes to mind). MfG Goswin PS: I assume dinstall got fixed to not delete sources-only uploads.
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Fri, Aug 30, 2002 at 04:55:46PM +0200, Robert Millan wrote: On Fri, Aug 30, 2002 at 10:31:23AM -0400, Joe Drew wrote: On Fri, 2002-08-30 at 10:16, Robert Millan wrote: currently non-US is the only place where it can be without breaking law. This is incorrect: mp3 patents exist in non-US places too, like Germany. we definitely need an mp3 decoder in debian if we want to fight the patent oppression at all. i think we need another branch for that kind of problems. lol, I doubt it would help. Just go to US patent office website and do a search on stuff like on title try The Wheel. :) I know, it's getting ridicules. What need to be done is for someone to sue the patent office for stifling innovation and promoting monopolies. ie. something it was originally created to fight. having mp3 players in non-free would still be illegal. mpg321 is free software that complies to DFSG and there's no reason to put it in non-free or non-free/non-US. If fraunhofer say that you are allowed to distribute mp3 players for free (but not for cost), then they must be put in non-free. And since they have patents all around the world, they can't be put in non-us. yes, but only non-free in states that impose patent restrictions. if we have such non-patented branch it would be free for users outside the circle. I'm not sure, but an app A that incorporates algorithm BOB and BOB is patented under a non-GPL license, then I don't think that A can be distributed as a GPL program.
Re: Non-Intel package uploads by maintainer
On Sat, Aug 31, 2002 at 03:09:52PM -0400, Dale Scheetz wrote: Is there any reason not to do this? It seems that it might speed up the I do that frequently and it seems to work well. I use Alpha, PowerPC, and i386 regularly and all three are machines I use to build on for Debian. Sometimes I need a package on more than one arch for my own purposes *right now*, and there's no reason not to upload the version for another arch to ftp-master while I'm at it. Especially since it can take days, even weeks, for packages to appear from the buildd's. -- John
Re: Non-Intel package uploads by maintainer
On Sun, Sep 01, 2002 at 12:17:01AM +0200, Goswin Brederlow wrote: Don't upload binaries at all. The autobuilder will check the build-process of your package. It will build in a clean chroot with proper build-depends. With proper versions of all tools. If you upload binaries you get the usual bugs of missing build-depends, wrong versions of tools or libraries and so on. Just because you had them installed. In his case, most of these will be noticed by the remaining nine buildds, anyway. /nitpick -- 2. That which causes joy or happiness.
Bug#159037: general: Time Problem
Package: general Version: N/A; reported 2002-08-31 Severity: normal Tags: sid I don't know what is causing this problem but all I know is that I have narrowed it down to being caused either by a package or by the install system. I installed from the woody install disks then upgraded to sid. What happenes is that the time jumps ahead then back, eg (this is output from while true; do date;done Sat Aug 31 19:07:26 EDT 2002 Sat Aug 31 19:07:26 EDT 2002 Sat Aug 31 19:07:26 EDT 2002 Sat Aug 31 19:07:26 EDT 2002 Sat Aug 31 20:19:01 EDT 2002 Sat Aug 31 20:19:01 EDT 2002 Sat Aug 31 20:19:01 EDT 2002 Sat Aug 31 19:07:27 EDT 2002 Sat Aug 31 19:07:27 EDT 2002 The only thing I did differently then previous installs was I told the installer that it could set the bios go UTC. The only time it is really noticable is when in X, the screensaver kicks in when it jumps. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux beyond.hjsoft.com 2.4.18 #1 SMP Sat Aug 31 10:49:35 EDT 2002 i686 Locale: LANG=C, LC_CTYPE=C -- no debconf information
Re: Non-Intel package uploads by maintainer
Goswin Brederlow [EMAIL PROTECTED] writes: There are several reasons not to do this. Don't upload binaries at all. Why? The autobuilder will check the build-process of your package. YOU should do that. It will build in a clean chroot with proper build-depends. With proper versions of all tools. man pbuilder|sbuild|chroot by hand There are enough ways to test your Build-Depends. And if you have an up2date chroot the versions of the Depends should be alright. -- begin OjE-ist-scheisse.txt bye, Joerg Encrypted Mail preferred! Registered Linux User #97793 @ http://counter.li.org end pgpvKBuSiGj1J.pgp Description: PGP signature
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Sat, Aug 31, 2002 at 05:15:00PM -0500, Adam Majer wrote: we definitely need an mp3 decoder in debian if we want to fight the patent oppression at all. i think we need another branch for that kind of problems. lol, I doubt it would help. Just go to US patent office website and do a search on stuff like on title try The Wheel. :) I know, it's getting ridicules. What need to be done is for someone to sue the patent office for stifling innovation and promoting monopolies. ie. something it was originally created to fight. The wheel is patented in Australia, not in the US. On the other hand, in the US there is a patent on using a laser pointer to exercise your cat, and one on swinging sideways on a playground swing. I do think that discouraging the use of patent-encumbered standards is a useful way to fight patent oppression. It sends the message that a patented standard is a dead standard. Maybe companies will review their habits in that light. yes, but only non-free in states that impose patent restrictions. if we have such non-patented branch it would be free for users outside the circle. I'm not sure, but an app A that incorporates algorithm BOB and BOB is patented under a non-GPL license, then I don't think that A can be distributed as a GPL program. Only if the patent holder for BOB is actively trying to enforce the license. If you're thinking of GPL section 7, then remember that it only applies to conditions specifically imposed on you, not merely the threat or possibility of such conditions. In general, I don't think we can adopt a useful and consistent stance on what to do with software that uses patented algorithms. There are just too many patents, and just about any program infringes on at least one of them. Even worse, it is impossible to prove that a program does NOT infringe on any patent. We'll have to consider the details of each case individually. Richard Braakman
Request Virtual Package: cl-sql-backend
Hello, In violation of policy (sorry!), I've been using a virtual package in my source package cl-sql. cl-sql defines a number of binary packages. The binary package cl-sql depends on the presence of one at least one cl-sql database backend. Thus, I have each of the binary database backend packages Provides: the virtual package cl-sql-backend. I'm filing a wishlist bug agains debian-policy requesting the addition of the virtual package cl-sql-backend. As per policy, I'll forward the either the consensus or lack of objections to [EMAIL PROTECTED] -- Kevin Rosenberg| .''`. ** Debian GNU/Linux ** http://b9.com/debian.html | : :' : The universal GPG signed and encrypted| `. `' Operating System messages accepted. | `-http://www.debian.org/
Re: Debian based CD based distros
On Sat, 31 Aug 2002, Dale Scheetz wrote: *** The main reason I mention these two excellent Debian spin-offs is that they both do a remoarkable on-the-fly hardware configuration for X and everything is wonderfully integrated and ready-to-use to a much greater extent that Debian is by itself. Those folks working on installation and configuration of the system could learn a lot from studying these CDs, not that we need to deliver a CD based release, but that we need a much quieter and more user friendly installation. Don't forget Libranet, http://www.libranet.com, an excelent Debian based distribution. Interesting use of the GPL as well. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs. See http://www.copyleft.co.nz
Re: Request Virtual Package: cl-sql-backend
On Sat, Aug 31, 2002 at 07:35:08PM -0600, Kevin Rosenberg wrote: In violation of policy (sorry!), I've been using a virtual package in Oops, never mind. I see now in the policy manual: Packages MUST NOT use virtual package names (except privately, amongst a cooperating group of packages) This virtual package name is only used by the single source package. -- Kevin Rosenberg| .''`. ** Debian GNU/Linux ** http://b9.com/debian.html | : :' : The universal GPG signed and encrypted| `. `' Operating System messages accepted. | `-http://www.debian.org/
Virus Alert
We have detected a virus (WORM_KLEZ.H) in your mail traffic sent from [EMAIL PROTECTED] in the file href.exe on 08/31/2002 21:26:41. We took the action delete. If you have questions regarding files or updating/installing Anti-virus protection on your PC, please contact your e-mail administrator or help desk.
Accepted python-optik 1.3-6 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 01:39:03 -0500 Source: python-optik Binary: python2.1-optik python2.2-optik python-optik Architecture: source all Version: 1.3-6 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: python-optik - advanced command-line parsing library for Python python2.1-optik - advanced command-line parsing library for Python 2.1 python2.2-optik - advanced command-line parsing library for Python 2.2 Changes: python-optik (1.3-6) unstable; urgency=low . * Python 2.1-2.2 transition. Files: 6bf962ee4b98d81b8891ba7affa5a3d0 939 interpreters optional python-optik_1.3-6.dsc 442975621f32d093c9657cd8ad5bed29 4247 interpreters optional python-optik_1.3-6.diff.gz de82da4dc7764bf6c56ea6ee32fce85e 4802 interpreters optional python-optik_1.3-6_all.deb 2b30d860e810c70654d771453a907c99 41784 interpreters optional python2.1-optik_1.3-6_all.deb 3d2e85e861096cce402871b04d11160d 41790 interpreters optional python2.2-optik_1.3-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iQEXAwUBPXBl1Vxpg5e5AmZiFAJR+gQAt3efWVcnG9yD46zcoJ94dEFrlkewQwGc ibYhfzlcKCZUEg8eD/0VyAbaV3K5P85KpRtXfiWThYnsf4kqVYy756v1s8294t9h XvQnOJ6cqsYQ1ueluAFSNnNZyc99OF9J0sI1+umNDaY+V0z3XCIOwqdEy4oXy1jb 0YKAwgMwbn0EAIbc8g9twIRkRR+8rEeh4n3y/eZ+kosV4Y9CZHtYDmeebUxUD/UT TrdUIhe4tSx5Uj9vXwYFzxR983lqYDxFashynifK9/SB08anLUZF7CY1bVdYeKXK cunpu79iM2h52JySTBPXbnb4AkSuWyq8BO0HxN0OTzw+8oWQ3nJRoRGZ =808N -END PGP SIGNATURE- Accepted: python-optik_1.3-6.diff.gz to pool/main/p/python-optik/python-optik_1.3-6.diff.gz python-optik_1.3-6.dsc to pool/main/p/python-optik/python-optik_1.3-6.dsc python-optik_1.3-6_all.deb to pool/main/p/python-optik/python-optik_1.3-6_all.deb python2.1-optik_1.3-6_all.deb to pool/main/p/python-optik/python2.1-optik_1.3-6_all.deb python2.2-optik_1.3-6_all.deb to pool/main/p/python-optik/python2.2-optik_1.3-6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted routeplanner 0.14.1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 02:16:15 -0500 Source: routeplanner Binary: routeplanner-gnome routeplanner Architecture: source all Version: 0.14.1 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: routeplanner - A highway trip planner routeplanner-gnome - A highway trip planner (GNOME interface) Changes: routeplanner (0.14.1) unstable; urgency=low . * Make most of the transition to Python 2.2... but we use python2.2-kjbuckets to avoid transition breakage for now. Files: acf329542e80ef1bca2813902e37b475 847 misc optional routeplanner_0.14.1.dsc d8f5fe1e7fe43c97f20284869b04c9da 345330 misc optional routeplanner_0.14.1.tar.gz 095c8f72069cb38f1ccd61d3aa42c06c 275686 misc optional routeplanner_0.14.1_all.deb f88e276c029ee10cc7bd3e6137842afe 32648 misc optional routeplanner-gnome_0.14.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iQEXAwUBPXBte1xpg5e5AmZiFAJS0QP/YqthJmYfw+4p0ewYyjp4+CC+akKhAe4H 66QYeacW8bMqGzzhfMizbSwtqixmhrvffyrINovOF5UvydYPhPLAyd1I6vTriCXQ Pnx+idloz/R3HpzD5hmcWjJeQ5k6QTD9BnUT5xq/ldqRFsDl0NjsxILLeFzaQgDR MIBwCdH4bOYEALLzZvP3OPbMiy7QA5z3R7vc/3jN+Sxh3ekpfMQM1LdV5xtGzEHT O/yaacLcrfUL+K6dmxAU8wZfbp8tvRPnqw7ei/bCS+jXzOaUQQC5y5RFxPfLR2aE oUuyz2tKZO1c3fPHsWft8V9c1y8SMe4XlyIMjdHF9/Nnjmg9KjuuqWyN =Tz1l -END PGP SIGNATURE- Accepted: routeplanner-gnome_0.14.1_all.deb to pool/main/r/routeplanner/routeplanner-gnome_0.14.1_all.deb routeplanner_0.14.1.dsc to pool/main/r/routeplanner/routeplanner_0.14.1.dsc routeplanner_0.14.1.tar.gz to pool/main/r/routeplanner/routeplanner_0.14.1.tar.gz routeplanner_0.14.1_all.deb to pool/main/r/routeplanner/routeplanner_0.14.1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pybliographer 1.0.11-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 02:19:38 -0500 Source: pybliographer Binary: pybliographer Architecture: source i386 Version: 1.0.11-5 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: pybliographer - A tool for manipulating bibliographic databases. Changes: pybliographer (1.0.11-5) unstable; urgency=low . * Transition to Python 2.2. Files: 4fad1e96e8846a917e450e2956147d33 1065 text optional pybliographer_1.0.11-5.dsc 2d146bce694ab981b686f685b9386576 939020 text optional pybliographer_1.0.11-5.diff.gz de412e96eea6b48f24f337250c4fb0d8 713760 text optional pybliographer_1.0.11-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iQEXAwUBPXBvYVxpg5e5AmZiFAIJxQP/Rvp49jHShAkuizXdfec4L7vNZ5cIqnpO x4rtTgj4vdRcd3BwmZ23hLtIDCaBbDGC++x6vFpM7hdjEEoY7OGSIY54hCX8K9Tp fr0XF9+Y7tKBfhhm/yIwqdBkDfdlcsbyfXSGhJcKhY4kdMVvTZB7orTNonLgFvpJ UwMc0qLNAmYEALQuYlMt6kJ8q85UDdNZ1J0wiyLk/nsYPZT90fq3xLq5QWSDoRFd q1TjVZ6M9/JRzFXJnebTUgOijxt+G9QtPX/oX+HD4yIdzghszBUHKNxl8uXdYIkk zeCLcnQjerjO8w6XRLipHuJNSfKI4ZUQ07XlC6ElK9xKUAPquiuKOrvQ =jXEx -END PGP SIGNATURE- Accepted: pybliographer_1.0.11-5.diff.gz to pool/main/p/pybliographer/pybliographer_1.0.11-5.diff.gz pybliographer_1.0.11-5.dsc to pool/main/p/pybliographer/pybliographer_1.0.11-5.dsc pybliographer_1.0.11-5_i386.deb to pool/main/p/pybliographer/pybliographer_1.0.11-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libtemplate-perl 2.08-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 03:37:18 -0400 Source: libtemplate-perl Binary: libtemplate-perl-doc libtemplate-perl Architecture: source i386 all Version: 2.08-1 Distribution: unstable Urgency: low Maintainer: Benjamin Hill (Mako) [EMAIL PROTECTED] Changed-By: Benjamin Hill (Mako) [EMAIL PROTECTED] Description: libtemplate-perl - template processing system written in perl libtemplate-perl-doc - documentation for libtemplate-perl (template toolkit) Closes: 157654 158831 Changes: libtemplate-perl (2.08-1) unstable; urgency=low . * New upstream release * Compiled for the new perl 5.8 pacakges. Closes: #158831 * Updated copyright file with pointer to perl's license. Closes: #157654 * Other minor changes. Files: f21455097c33d80711a77a19d2a8d245 665 interpreters optional libtemplate-perl_2.08-1.dsc 04b14a3ddb54db77a8eb7104635a7f23 804959 interpreters optional libtemplate-perl_2.08.orig.tar.gz 489705234551667545ee7f901ec1b8b1 4877 interpreters optional libtemplate-perl_2.08-1.diff.gz 7c2eeb649e63431c6c885e29bb09bd98 600720 doc optional libtemplate-perl-doc_2.08-1_all.deb 5ea701e2c9edc1953f0a897a745996bd 806960 interpreters optional libtemplate-perl_2.08-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD4DBQE9cHonic1LIWB1WeYRAhfYAKCRw1eVpGSSZS96DC18wTtiiS0XPgCXYWV7 YByIhqGzztcy+eErK1f2xA== =2mZT -END PGP SIGNATURE- Accepted: libtemplate-perl-doc_2.08-1_all.deb to pool/main/libt/libtemplate-perl/libtemplate-perl-doc_2.08-1_all.deb libtemplate-perl_2.08-1.diff.gz to pool/main/libt/libtemplate-perl/libtemplate-perl_2.08-1.diff.gz libtemplate-perl_2.08-1.dsc to pool/main/libt/libtemplate-perl/libtemplate-perl_2.08-1.dsc libtemplate-perl_2.08-1_i386.deb to pool/main/libt/libtemplate-perl/libtemplate-perl_2.08-1_i386.deb libtemplate-perl_2.08.orig.tar.gz to pool/main/libt/libtemplate-perl/libtemplate-perl_2.08.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ddd 1:3.3.1-17 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 09:59:59 +0200 Source: ddd Binary: ddd ddd-doc Architecture: source i386 all Version: 1:3.3.1-17 Distribution: unstable Urgency: low Maintainer: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Changed-By: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Description: ddd- The Data Display Debugger, a graphical debugger frontend. ddd-doc- Additional documentation for the Data Display Debugger. Closes: 158954 Changes: ddd (1:3.3.1-17) unstable; urgency=low . * Added missing backslash that caused configure not to get all the arguments it was intended to get. Thanks Herbert Xu. (Closes: #158954) Files: d9ec117377e0f54c374ac32c7b8c61fc 1097 devel optional ddd_3.3.1-17.dsc 4493785ed20da1ea0d13b46a9ee02433 723802 devel optional ddd_3.3.1-17.diff.gz eedf003832ef433ea03af3701362d311 3812300 doc optional ddd-doc_3.3.1-17_all.deb 128061d26ff45023c9e844706963641f 1577782 devel optional ddd_3.3.1-17_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iQEXAwUBPXB+zAxJU8feGmjHFAISJQP6Aq4DO641KgLcxaEefLZuOIWn+ITXkDgn Ws07sr9DkdMtHIdtC7V8KQjOaynx6NykiUuLhbuOLHOy5C4l/jTliFboXdfPs7yN KjcY4ua/VOe/Tko4Wol7VvA+8qlE/7B3GDkczw7nWexj4VCWklQ4fADhWwBbvyxL Ljwcyw2aQ4QEAJiPABbs6IIWNwxjmN4alOO0jMgFb7aEgfplGfiPNjrlo4LtGp34 Q4QrhorG4lgiD5S1aqVVKZK3ldoIGBj2Tz9UmPEkkaP1ikgJrty1qsVQi7p5Cq1d t5rsG8i5m2T1n2jzGtPUpis34Pp4zElzaIwrD3gFI4Hv0yriGVqPuCbv =1DHD -END PGP SIGNATURE- Accepted: ddd-doc_3.3.1-17_all.deb to pool/main/d/ddd/ddd-doc_3.3.1-17_all.deb ddd_3.3.1-17.diff.gz to pool/main/d/ddd/ddd_3.3.1-17.diff.gz ddd_3.3.1-17.dsc to pool/main/d/ddd/ddd_3.3.1-17.dsc ddd_3.3.1-17_i386.deb to pool/main/d/ddd/ddd_3.3.1-17_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted perlftlib 1.2-13.1 (sparc source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 18:22:13 +1000 Source: perlftlib Binary: fttools libft-perl Architecture: source sparc all Version: 1.2-13.1 Distribution: unstable Urgency: low Maintainer: Stephen Zander [EMAIL PROTECTED] Changed-By: Brendan O'Dea [EMAIL PROTECTED] Description: fttools- FreeType font utilities. libft-perl - Perl module for the FreeType library Changes: perlftlib (1.2-13.1) unstable; urgency=low . * NMU * Build for perl 5.8.0. Files: 4c72c2b481183d7b5581d43b09f4f4ee 610 interpreters optional perlftlib_1.2-13.1.dsc 7324b441493784ab8299b66078a9668b 8220 interpreters optional perlftlib_1.2-13.1.diff.gz 1b82ba2b0c852641c4199a79ffc82c55 12118 utils optional fttools_1.2-13.1_all.deb a1627433e618eeaadf7785ed281f5eb4 49850 interpreters optional libft-perl_1.2-13.1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cID18NyOALKMWZURAhxLAJ9W1kzzKB8J9l/zMuZ3rXoZHUjl7gCfRLwJ j+YzVTYUVcZEDs0PPTEtOek= =EyQn -END PGP SIGNATURE- Accepted: fttools_1.2-13.1_all.deb to pool/main/p/perlftlib/fttools_1.2-13.1_all.deb libft-perl_1.2-13.1_sparc.deb to pool/main/p/perlftlib/libft-perl_1.2-13.1_sparc.deb perlftlib_1.2-13.1.diff.gz to pool/main/p/perlftlib/perlftlib_1.2-13.1.diff.gz perlftlib_1.2-13.1.dsc to pool/main/p/perlftlib/perlftlib_1.2-13.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ptex-buildsupport 1.0.7+20020208-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 17:16:38 +0900 Source: ptex-buildsupport Binary: ptex-buildsupport Architecture: source all Version: 1.0.7+20020208-2 Distribution: unstable Urgency: low Maintainer: Masayuki Hatta [EMAIL PROTECTED] Changed-By: Masayuki Hatta [EMAIL PROTECTED] Description: ptex-buildsupport - Support files for building ASCII pTeX Changes: ptex-buildsupport (1.0.7+20020208-2) unstable; urgency=low . * Updated to Standards-Version: 3.5.6. Files: 2e20a9576da191bf404bf5b17e165629 636 tex optional ptex-buildsupport_1.0.7+20020208-2.dsc 3495e50c6b6ce1c93490fc49c2f149e6 3216 tex optional ptex-buildsupport_1.0.7+20020208-2.diff.gz a0dfee21b541de2e0585e39e6e54574f 3895408 tex optional ptex-buildsupport_1.0.7+20020208-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cHw3vA5bJSX0Hx8RAr9lAJ9rEPGt1Kt9vfRy181NsWhA412B6wCaA2ts lD1jcznVISJ8a557mALNAr8= =XIN7 -END PGP SIGNATURE- Accepted: ptex-buildsupport_1.0.7+20020208-2.diff.gz to pool/main/p/ptex-buildsupport/ptex-buildsupport_1.0.7+20020208-2.diff.gz ptex-buildsupport_1.0.7+20020208-2.dsc to pool/main/p/ptex-buildsupport/ptex-buildsupport_1.0.7+20020208-2.dsc ptex-buildsupport_1.0.7+20020208-2_all.deb to pool/main/p/ptex-buildsupport/ptex-buildsupport_1.0.7+20020208-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ptex-bin 3.0.1+0.04-12 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Aug 2002 16:04:35 +0900 Source: ptex-bin Binary: jbibtex-bin jmpost ptex-bin Architecture: source i386 Version: 3.0.1+0.04-12 Distribution: unstable Urgency: low Maintainer: Masayuki Hatta [EMAIL PROTECTED] Changed-By: Masayuki Hatta [EMAIL PROTECTED] Description: jbibtex-bin - make a bibliography for ASCII p(La)TeX / NTT j(La)TeX jmpost - Japanized MetaPost, a system for drawing pictures ptex-bin - ASCII pTeX binary files Closes: 145086 155880 Changes: ptex-bin (3.0.1+0.04-12) unstable; urgency=low . * Removed ptexconfig and jbibtexconfig - closes: #145086 * Enabled file-line-error-style option - closes: #155880 Files: de67f08e1b9d616a43be63f98fe46443 735 tex optional ptex-bin_3.0.1+0.04-12.dsc 21ced5a569638e976ea61f19c0d7a98d 19933 tex optional ptex-bin_3.0.1+0.04-12.diff.gz 68dd03b584114a97b75f87ecf4e4928d 203604 tex optional ptex-bin_3.0.1+0.04-12_i386.deb ae4edd8d5fd3028493218a08729884d5 47666 tex optional jbibtex-bin_3.0.1+0.04-12_i386.deb df53fa0eb32f0a2e7e6bffa605f62bc1 154010 tex optional jmpost_3.0.1+0.04-12_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9cINVvA5bJSX0Hx8RAuY5AJ9x6DHM10plVVIgKqAKEaLkZDdUQACfbh3P VbkE2eSXDFdVBSqv+zUwrpk= =wh1Q -END PGP SIGNATURE- Accepted: jbibtex-bin_3.0.1+0.04-12_i386.deb to pool/main/p/ptex-bin/jbibtex-bin_3.0.1+0.04-12_i386.deb jmpost_3.0.1+0.04-12_i386.deb to pool/main/p/ptex-bin/jmpost_3.0.1+0.04-12_i386.deb ptex-bin_3.0.1+0.04-12.diff.gz to pool/main/p/ptex-bin/ptex-bin_3.0.1+0.04-12.diff.gz ptex-bin_3.0.1+0.04-12.dsc to pool/main/p/ptex-bin/ptex-bin_3.0.1+0.04-12.dsc ptex-bin_3.0.1+0.04-12_i386.deb to pool/main/p/ptex-bin/ptex-bin_3.0.1+0.04-12_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
