Uploaded lsof 4.55-2 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 01:45:03 +0200 Source: lsof Binary: lsof Architecture: m68k Version: 4.55-2 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Jim Mintha [EMAIL PROTECTED] Description: lsof - List open files. Closes: 94922 Changes: lsof (4.55-2) unstable; urgency=low . * Add Provides for lsof-2.2 (Closes: Bug#94922) Files: c553a1f4df5973b1e79a08856c27622d 255734 utils standard lsof_4.55-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE69PS5EycGpQPNsdIRAsB9AKCEc5ekcWGMkxR1Ov6hhrh7F60lGACfS7Lv JjqHI1bV6Dv4LsAGB9VCshU= =rdEw -END PGP SIGNATURE-
Uploaded penguineyes 0.10-8 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 May 2001 17:38:51 -0300 Source: penguineyes Binary: penguineyes penguineyes-gnome Architecture: m68k Version: 0.10-8 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Gustavo Noronha Silva [EMAIL PROTECTED] Description: penguineyes - A gnome version of xeyes penguineyes-gnome - A gnome version of xeyes Closes: 94169 Changes: penguineyes (0.10-8) unstable; urgency=low . * templates: added German translation to debconf's template file, thanks to Sebastian Feltel [EMAIL PROTECTED] (Closes: #94169) * control: modified build-dependency, changed libdb2-dev to libdb3-dev * configure.in: made a little uggly hack to switch to -ldb3 as gnome-config --libs applets gives an erroneous output Files: 7b18dba53f4204a5cd6bce63b96bac83 241642 x11 optional penguineyes_0.10-8_m68k.deb ca5a0794d3113cbcb7941bc8067e45ba 247666 x11 optional penguineyes-gnome_0.10-8_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE69HG1EycGpQPNsdIRAg54AJ9BBrdqp9IdbaiCw9MdpjdAjvEk9gCgrWaG N5KHWvhJcINgvs+lR9UbqBk= =Dw3r -END PGP SIGNATURE-
Uploaded gtkdiff 1.8.0-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 15 Apr 2001 20:14:13 +0200 Source: gtkdiff Binary: gtkdiff Architecture: m68k Version: 1.8.0-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Gregor Hoffleit [EMAIL PROTECTED] Description: gtkdiff- A graphical text comparision tool Closes: 89371 Changes: gtkdiff (1.8.0-1) unstable; urgency=low . * New upstream version: - diff3(1) support. No directory diff3 support yet. - -o option to specify a merge output file. - Improved keyboard navigation (PageUp and PageDown). - Bug fixes. - The ~/.gnome/gtkdiff file has been changed. - gtkdiff-cvs and gtkdiff-rcs work with directory names as arguments (closes: #89371). Files: 5ef419970013f2b4a6dbc9e94b60de32 94722 text optional gtkdiff_1.8.0-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE69K+pEycGpQPNsdIRAiPRAKCJkmHBQn19ehD05UEOuWmFdPMdcACfWmJ3 navwd7lnOn4Gy1D/0jBOvpc= =0TSQ -END PGP SIGNATURE-
Uploaded krb5 1.2.2-4 (m68k) to non-us
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Fri, 20 Apr 2001 02:47:21 -0400 Source: krb5 Binary: krb5-kdc krb5-doc krb5-rsh-server libkrb5-dev libkrb53 krb5-ftpd krb5-clients krb5-user libkadm54 krb5-telnetd krb5-admin-server Architecture: m68k Version: 1.2.2-4 Distribution: unstable Urgency: low Maintainer: buildd m68k user account [EMAIL PROTECTED] Changed-By: Sam Hartman [EMAIL PROTECTED] Description: krb5-admin-server - Mit Kerberos master server (kadmind) krb5-clients - Secure replacements for ftp, telnet and rsh using MIT Kerberos krb5-ftpd - Secure FTP server supporting MIT Kerberos krb5-kdc - Mit Kerberos key server (KDC) krb5-rsh-server - Secure replacements for rshd and rlogind using MIT Kerberos krb5-telnetd - Secure telnet server supporting MIT Kerberos krb5-user - Basic programs to authenticate using MIT Kerberos libkadm54 - MIT Kerberos administration runtime libraries libkrb5-dev - Headers and development libraries for MIT Kerberos libkrb53 - MIT Kerberos runtime libraries Closes: 94407 Changes: krb5 (1.2.2-4) unstable; urgency=low . * Fix shared libraries to build with gcc not ld to properly include -lgcc symbols, closes: #94407 Files: 563dac1cdd3ba922f9301fe074fbfc80 65836 non-us/main optional libkadm54_1.2.2-4_m68k.deb bb620f589c17ab0ebea1aa6e10ca52ad 272198 non-us/main optional libkrb53_1.2.2-4_m68k.deb 40af6e64b3030a179e0de25bd95c95e9 143264 non-us/main optional krb5-user_1.2.2-4_m68k.deb ffe4e5e7b2cab162dc608d56278276cf 141870 non-us/main optional krb5-clients_1.2.2-4_m68k.deb 4fe01d1acb4b82ce0b8b72652a9a15ae 54592 non-us/main optional krb5-rsh-server_1.2.2-4_m68k.deb b3c8c617ea72008a33b869b75d2485bf 41292 non-us/main optional krb5-ftpd_1.2.2-4_m68k.deb 5908f8f60fe536d7bfc1ef3fdd9d74cc 42090 non-us/main optional krb5-telnetd_1.2.2-4_m68k.deb 650ea769009a312396e56503d0059ebc 160236 non-us/main optional krb5-kdc_1.2.2-4_m68k.deb 399c9de4e9d7d0b0f5626793808a4391 160392 non-us/main optional krb5-admin-server_1.2.2-4_m68k.deb 6f962fe530c3187e986268b4e4d27de9 398662 non-us/main optional libkrb5-dev_1.2.2-4_m68k.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBOvVPPm547I3m3eHJAQHyaQP+M7RXVEqZ2/xHiPzaPcZRJ4q7o0zbMaU8 qG/Mi6kuR1EhRNMjMH4Cp6ctbhRDHK5FR/8v7UkOd+ETDAhiw7eqJnLC60EZxZ/H CiOs8JklAXDERkQ3i7EYybv46Gxx91pIs2nE4xVKnG16d/wFELWMBLY6skF1B2/g zZju3cuFCCE= =Vm59 -END PGP SIGNATURE-
Uploaded cyrus-imapd 1.5.19-7 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 Apr 2001 16:31:40 +0200 Source: cyrus-imapd Binary: cyrus-admin cyrus-pop3d cyrus-common cyrus-imapd cyrus-dev cyrus-nntp Architecture: m68k Version: 1.5.19-7 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Michael-John Turner [EMAIL PROTECTED] Description: cyrus-admin - CMU Cyrus mail system (administration tool) cyrus-common - CMU Cyrus mail system (common files) cyrus-dev - CMU Cyrus mail system (developer files) cyrus-imapd - CMU Cyrus mail system (IMAP support) cyrus-nntp - CMU Cyrus mail system (NNTP support) cyrus-pop3d - CMU Cyrus mail system (POP3 support) Closes: 90804 Changes: cyrus-imapd (1.5.19-7) unstable; urgency=low . * Updated Build-Depends (Closes: Bug#90804). Files: fe25c10bb03140e7abc1409bdf034cc4 387242 mail extra cyrus-common_1.5.19-7_m68k.deb 1c8a52bedc6e6786121e81f7647f4135 112934 mail extra cyrus-imapd_1.5.19-7_m68k.deb a70a0353972bc559b9fddf8adbcd7d5f 51820 mail extra cyrus-pop3d_1.5.19-7_m68k.deb 0396cbe5b18b4c0e6d7b02c0b2ee135b 111670 mail extra cyrus-nntp_1.5.19-7_m68k.deb b9a389765336a5338e66cc2095f532ea 37458 mail extra cyrus-admin_1.5.19-7_m68k.deb 595006224d41a8165f60e9e550b89ea4 73850 devel extra cyrus-dev_1.5.19-7_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE69WmaEycGpQPNsdIRAk7SAJ47ZD4Ni21fOVkjfydoD9qeYa7qJACgqtSV JExGNUSYuRwQ2ihzQjF9SJ4= =jXLM -END PGP SIGNATURE-
Uploaded libterm-readkey-perl 2.14-2.1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 5 May 2001 13:05:23 +0200 Source: libterm-readkey-perl Binary: libterm-readkey-perl Architecture: sparc Version: 2.14-2.1 Distribution: unstable Urgency: medium Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Raphael Hertzog [EMAIL PROTECTED] Description: libterm-readkey-perl - Change terminal modes, and perform non-blocking reads Changes: libterm-readkey-perl (2.14-2.1) unstable; urgency=medium . * Yet Another NMU. No changes. Did that because there was a sparc binary-only NMU 2.14-2 that caused it to not get through testing. Files: eeb11ce5b561afcf27e17d8f5171769f 26486 libs optional libterm-readkey-perl_2.14-2.1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69X8afNc/ZB4E7C0RArZ7AJ9Rn6CAFgnGG3kMthxTz5gCZQ1wFACfWRrF FxbfpAOGpsMk5BfUuufwr3A= =g2nl -END PGP SIGNATURE-
Uploaded rpm 4.0.2-7 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 22:34:03 -0400 Source: rpm Binary: librpm0-dev librpm0 rpm Architecture: sparc Version: 4.0.2-7 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Joey Hess [EMAIL PROTECTED] Description: librpm0- RPM shared library librpm0-dev - RPM shared library, development kit rpm- Red Hat Package Manager Closes: 95789 Changes: rpm (4.0.2-7) unstable; urgency=low . * Build with new libpopt-dev to fix versoned libpopt0 dependancy problem. Closes: #95789 Files: d10b0785805c7c9f53581d531462e1d0 466608 admin optional rpm_4.0.2-7_sparc.deb 3a9e7e9fb8169cab327c3799d19b2a5e 272004 libs optional librpm0_4.0.2-7_sparc.deb 5639e963d12cb103ff2eea5f73a023ba 343526 devel extra librpm0-dev_4.0.2-7_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69LYHfNc/ZB4E7C0RAoJPAJ4xY6mkiEq89uyZaIT40H5wvzIqJgCgn4WW mGOlqyhuvZS20HBIlpncWQ8= =fKkK -END PGP SIGNATURE-
Uploaded marbles 0.0.010307-2 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 03:23:24 +0200 Source: marbles Binary: marbles Architecture: sparc Version: 0.0.010307-2 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Uwe Hermann [EMAIL PROTECTED] Description: marbles- A game where you build figures out of colored marbles. Closes: 96183 Changes: marbles (0.0.010307-2) unstable; urgency=low . * postinst: Changed 'chown owner.group' to 'chown owner:group', because, if using a dot as separator between owner and group, chown can fail if owner contains a dot. * Removed the unnecessary '.2' file which shouldn't have been there at all. * Recompiled against libsdl1.2. Updated Build-depends. Thanks to Robert Bihlmeyer [EMAIL PROTECTED] for suggesting this. Closes: #96183. * Updated Standards-Version to 3.5.4.0. No changes necessary. * Don't install AUTHORS into /usr/share/doc/marbles anymore, because /usr/share/doc/marbles/copyright already contains the name and email of the (upstream) author. Suggested by Ralf Treinen [EMAIL PROTECTED]. * Upload sponsored by Ralf Treinen [EMAIL PROTECTED]. Files: cb18cb1959afb651b22a81e84a10b411 780262 games optional marbles_0.0.010307-2_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69LYKfNc/ZB4E7C0RAmsSAJ9FRUlrs8MnRA9Lwn8hZCGI3gVQogCdHCpQ HBDI7UrGPfs/A44jw7skwR0= =hEpV -END PGP SIGNATURE-
Uploaded fileutils 4.1-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 2 May 2001 19:56:55 -0400 Source: fileutils Binary: fileutils Architecture: sparc Version: 4.1-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Michael Stone [EMAIL PROTECTED] Description: fileutils - GNU file management utilities. Changes: fileutils (4.1-1) unstable; urgency=low . * New upstream version Files: 068e580fbe86042586b19b9f8cbd23bb 673266 base required fileutils_4.1-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69LX7fNc/ZB4E7C0RAuzJAJ98L0PxI8DHNv1wgrmYByqJNr60GQCfUXBV xeUiF+XGmTx0tjBI5Dxuw6g= =Qj7e -END PGP SIGNATURE-
Uploaded python-imaging 1.1.1.ds1-5 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 5 May 2001 14:47:41 +0200 Source: python-imaging Binary: python2-imaging-tk python-imaging-doc python-imaging-tk python-imaging-sane python2-imaging-sane python-imaging python2-imaging Architecture: sparc Version: 1.1.1.ds1-5 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Simon Richter [EMAIL PROTECTED] Description: python-imaging - The Python Imaging Library. python-imaging-sane - The Python Imaging Library SANE interface. python-imaging-tk - The Python Imaging Library (Module with Tk support). python2-imaging - The Python Imaging Library. python2-imaging-sane - The Python Imaging Library SANE interface. python2-imaging-tk - The Python Imaging Library (Module with Tk support). Closes: 72435 Changes: python-imaging (1.1.1.ds1-5) unstable; urgency=low . * Took over maintainership (Closes: #72435) Files: 61b0cb20e49659cefbd4d357d35ce8ad 181064 graphics optional python-imaging_1.1.1-4_sparc.deb a06f2d9f044d1e276a271d51d49ffca0 5666 graphics optional python-imaging-tk_1.1.1-4_sparc.deb 9bce33a8ff6c2d35a3588fd450bb6210 13434 graphics optional python-imaging-sane_1.1.1-4_sparc.deb cae07eafdc658bfae26c0a57c6ad9db0 180936 graphics optional python2-imaging_1.1.1-4_sparc.deb 46b827f078ec5e82ea78c26f5e0ebcbf 5640 graphics optional python2-imaging-tk_1.1.1-4_sparc.deb 75eacf4099775bb8ede5d84982c97ea4 13426 graphics optional python2-imaging-sane_1.1.1-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69X8afNc/ZB4E7C0RAgbXAJsELMz4eQLY0+/WXqF3eJ4rUIMugwCgl42F o5VM18uASBWbbAs1WwOiAKQ= =l7oj -END PGP SIGNATURE-
Uploaded xscreensaver 3.32-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 17:03:31 -0500 Source: xscreensaver Binary: xscreensaver-gl xscreensaver Architecture: sparc Version: 3.32-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Larry Daffner [EMAIL PROTECTED] Description: xscreensaver - Automatic screensaver for X xscreensaver-gl - GL(Mesa) screenhacks for xscreensaver Closes: 963432 Changes: xscreensaver (3.32-1) unstable; urgency=low . * New upstream version (Closes: #963432) Files: 4db8a3c06870dfc2502f715d8f4a2e41 2587962 x11 optional xscreensaver_3.32-1_sparc.deb 906c3e78351351e41f1b71f2fe9e9c16 1093966 x11 optional xscreensaver-gl_3.32-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69ZSDfNc/ZB4E7C0RAiquAKDJJ/EYCzd8YOpmcZtlFOGDJzualwCeKwAk 84mzsAyHS+YnyxmegCFCN/o= =hGD+ -END PGP SIGNATURE-
Uploaded emacs20 20.7-6 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 5 May 2001 09:47:40 -0500 Source: emacs20 Binary: emacs20 emacs20-el Architecture: sparc Version: 20.7-6 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Rob Browning [EMAIL PROTECTED] Description: emacs20- The GNU Emacs editor. Closes: 45317 65017 74570 88231 95953 Changes: emacs20 (20.7-6) unstable; urgency=low . * Fix improper usage of dpkg-statoverride and make sure movemail is set up right. (closes: #95953) * Fix bad manpage location in postinst update-alternatives call. * Fix bad .so in ctags manpage (closes: #88231, #45317, #65017, #74570) Files: 61c5e6985452c22c90fb3ea964a27bd3 9076126 editors standard emacs20_20.7-6_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69LYCfNc/ZB4E7C0RAp5pAKCVjJfSMAi8GSiDGSj/8g/sDBzdEQCeJWtI YXRtoExvTd+RzQmKNmHVF44= =//AX -END PGP SIGNATURE-
Uploaded gnubg 0.02-4 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 6 May 2001 18:24:40 +1200 Source: gnubg Binary: gnubg-bearoffs gnubg Architecture: sparc Version: 0.02-4 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Corrin Lakeland [EMAIL PROTECTED] Description: gnubg - A GTK/ascii backgammon program gnubg-bearoffs - Improved play for gnubg (gnu backgammon) Changes: gnubg (0.02-4) unstable; urgency=low . * changed kgammon to kbackgammon Files: 71b0a84c2af5e5badf4d42d001cd53ce 470376 games optional gnubg_0.02-4_sparc.deb a4392c8129f936cc8970e7e70d421a04 2430136 games optional gnubg-bearoffs_0.02-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69LYSfNc/ZB4E7C0RAg22AJ0ZS1w7s7aa7VFw7eYmaUiegdbmxgCeN4si 2trvbbMqqsNy2O8c8V+8hNE= =NgSe -END PGP SIGNATURE-
Uploaded fetchmail 5.8.1-4 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 5 May 2001 01:57:50 -0300 Source: fetchmail Binary: fetchmailconf fetchmail Architecture: sparc Version: 5.8.1-4 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Henrique de Moraes Holschuh [EMAIL PROTECTED] Description: fetchmail - POP3, APOP, IMAP mail gatherer/forwarder Closes: 95737 Changes: fetchmail (5.8.1-4) unstable; urgency=low . * The A Debian developer's way is fraught with peril release * New Dutch template, thanks Thomas J. Zeeman (closes: #95737) * Add debconf and initscript support to run the system-wide fetchmail daemon as user fetchmail. It is safer, but it won't work if fetchmail is told to deliver to a MDA. Unfortunately, now the initscript violates the KISS principle quite throughoutly. Files: 80f6fa04dc7c1ba431f6926900cd4b20 396302 mail optional fetchmail_5.8.1-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69ZSJfNc/ZB4E7C0RAhh9AJ9WobjIE3qHezfoVo1XlkOQJI31FACfXBKI Lwx6/jSP2IkBeURROoAjSxg= =i4Xq -END PGP SIGNATURE-
Uploaded shellutils 2.0.11-7 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 2 May 2001 20:47:37 -0400 Source: shellutils Binary: shellutils Architecture: sparc Version: 2.0.11-7 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Michael Stone [EMAIL PROTECTED] Description: shellutils - The GNU shell programming utilities. Closes: 78372 95343 95816 Changes: shellutils (2.0.11-7) unstable; urgency=low . * su suid on hurd (Closes: #78372) * Reformat stty(1) (Closes: #95816) * Change to free translation in fr.po (Closes: #95343) Files: cea567e10df782f522793ba757ff8faf 610300 base required shellutils_2.0.11-7_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69LYAfNc/ZB4E7C0RAuC9AJ9R+P4N/WxY0aCtxn5cluSmjDw52gCgtAh5 dCzTK08CeLfTpTIMTDhb/0A= =1vmX -END PGP SIGNATURE-
Uploaded althea 0.4.3-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 15:31:01 -0400 Source: althea Binary: althea Architecture: sparc Version: 0.4.3-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Jimmy Kaplowitz [EMAIL PROTECTED] Description: althea - IMAP email client for GTK+ Changes: althea (0.4.3-1) unstable; urgency=low . * New upstream release Files: 521731e2a91dde5141e391676cd8ce27 371146 mail optional althea_0.4.3-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69LYJfNc/ZB4E7C0RAmh8AKCN/Ln0Pi8tS5OEBu1e3hg8PdAKhQCdHs1V 77dB+XaTCee7IZHZruZctS8= =Svv1 -END PGP SIGNATURE-
Uploaded uqwk 2.17-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 5 May 2001 09:25:15 +0200 Source: uqwk Binary: uqwk uqwk-spool Architecture: sparc Version: 2.17-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: peter karlsson [EMAIL PROTECTED] Description: uqwk - Offline mail and news package creator (NNTP version). uqwk-spool - Offline mail and news package creator (spool version). Changes: uqwk (2.17-1) unstable; urgency=low . * New upstream release: - Fixed a one-off error in a mail reading error message. Files: e38b2a0706152f8e93317ed4f2820001 72282 comm optional uqwk_2.17-1_sparc.deb 17882bd82cfec1c2548485e75f59400d 69326 comm optional uqwk-spool_2.17-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69LYQfNc/ZB4E7C0RAh8ZAKC42oEqZg0zVCIZJy/D7wjR5oVjXQCgsvrI X9pFCPhEtUDfn5lU3KAg6ww= =EvCe -END PGP SIGNATURE-
Uploaded ipchains 1.3.10-9 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 5 May 2001 13:03:36 +0200 Source: ipchains Binary: ipchains Architecture: sparc Version: 1.3.10-9 Distribution: unstable Urgency: medium Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Lenart Janos [EMAIL PROTECTED] Description: ipchains - Network firewalling for Linux 2.2.x Changes: ipchains (1.3.10-9) unstable; urgency=medium . * The init script now clears the firewall rules before it restores the saved ones on start, and after saving the current ones on stop. A notice also put into the defaults file as it might be recommended to do an ipchains -F after disabling the init script. Thanks to Martin Schulze [EMAIL PROTECTED] for reporting these lacks. * Removed conffiles as the init script and the defaults file are added automagically by dh_installinit. Files: 474a28fcb3f358e4e1565fafe8c799c1 79570 base important ipchains_1.3.10-9_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69X8XfNc/ZB4E7C0RAvOXAJ97VyhtTICQhsiHnzlC07JJTvyI6wCeMqsh T8CUG70f6TI+WIXEhITpPdE= =5In3 -END PGP SIGNATURE-
Uploaded man-db 2.3.17.1-5 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 5 May 2001 00:19:00 +0100 Source: man-db Binary: man-db Architecture: sparc Version: 2.3.17.1-5 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Colin Watson [EMAIL PROTECTED] Description: man-db - Display the on-line manual. Closes: 5360 94642 Changes: man-db (2.3.17.1-5) unstable; urgency=low . * Formally took over upstream maintenance. No release yet, but updated debian/copyright with new location of upstream source (and also Wilf's distribution site for old sources). * Generate man-db-manual.txt from man-db-manual.html at build time using html2text, rather than including it in the diff. (The next upstream release will have both generated from the original nroff source.) * Don't run configure in the clean rule, and ignore errors due to not finding the makefile. In normal autobuilds it just wastes time. . * Bumped database format version to 2.3.2. This really should have been done a long time ago. * If database information is found to be in an old format, then ignore it and use the filesystem instead. mandb will fix it up when it's run, as it is in the postinst (although this may well become optional soon). * Explicitly close the database if the version number is wrong, so that the above works. * Lower warnings about wrong version numbers to debugging messages. * All hail debootstrap for making the testing above so painless! . * Taught lexgrog how to detect grap and vgrind. Preprocessor lines (with '\, see man(1)) are no longer strictly necessary for these. It's still good practice to declare what preprocessors your man page needs if it uses any - even tbl - for compatibility with older versions of man. * History updates for the man pages. * Made accessdb check for /var/cache/man in preference to /var/catman, and updated the man page accordingly. (Incidentally, I'd have preferred it if the Japanese translator hadn't improvised text that wasn't in the English version, as now I don't know how to update it to keep up with this change. Please don't do this in future.) * Fixed the --test option to mandb (it really doesn't alter existing databases now), and documented it. It should be almost feasible to use it for lintian checks now, if need be (closes: #5360). * Generate a warning if displaying a page requires going through a whatis reference with no link in the filesystem. Supporting this is necessarily a major performance hog; see policy bug #94995 for more information. * Removed code preventing symlinks outside a mantree from working. I can't see how it's a security problem, and in some situations (e.g. stow) such symlinks are useful (closes: #94642). Files: 1a13f8096b3793b8c58ea3dd901b27f1 343032 doc important man-db_2.3.17.1-5_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69X8ZfNc/ZB4E7C0RAiltAKCnOghABHDxCTKy0VAnjObNF/c5MACfQSEv HMmGjVAcKlC1aOOpMune7lE= =84dH -END PGP SIGNATURE-
Uploaded ferm 1.0pl1-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 5 May 2001 00:54:53 +0300 Source: ferm Binary: ferm Architecture: sparc Version: 1.0pl1-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Tommi Virtanen [EMAIL PROTECTED] Description: ferm - maintain and setup complicated firewall rules Changes: ferm (1.0pl1-1) unstable; urgency=low . * New upstream version. * Fixed a small grammar error in description. Files: 2f31b78e40743fa3948b0ec0355ba436 32288 net optional ferm_1.0pl1-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE69ZSGfNc/ZB4E7C0RArEhAJ9ih8dGOWiRiz63azAhUnghWABaFQCgnZqq et/j1W02yGx+cZZ8eIGmkpE= =mP9w -END PGP SIGNATURE-
Re: how to implement a renamed package
Thanks, - I know this and have done it previously in the case of zicq and krolden. However, what I really wanted to know is, how this (or any other) procedure can take care that the users of the old package will get the renamed package automatically updated with 'apt-get upgrade'? Oh, I see, the simple replaces and conflicts won't work there (I just tested it on some dummy packages because I thought it would, but you are right, it doesn't.) Otherwise, the new (renamed) upstream version could be easily overlooked and the users would just wonder why the old package is removed from the archives. As far as I know the standard procedure depends on the active selection of the renamed package, and the only replacement-effect is that it will remove the old package when it is installed. But the problem is: How shall the user know that the new package replaces another package with a different name? I haven't found anything better than Ben Burton's suggestion of the dummy package foo that depends on newfoo, that isn't very graceful, I'll admit. David
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 11:20:21PM +0200, Richard Atterer wrote: While we're at it: How on earth can I get rid of those Warning: locale not supported by Xlib, locale set to C messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts etc in mutt. Unfortunately, this produces the above error message with lots of X programs - especially annoying when you use at(1); you always get a mail with the error message. I got an error very similar to this. possibly that error, though not only for mutt. Basically it was for any X program pretty much. Back when I had an X installation I had compiled myself (4.0.2) on potato. I had compiled form the instructions with the X source, and got that error with all programs, it was not till I read the DRI compile howto page a few months later and saw this instruction in http://dri.sourceforge.net/doc/DRIcompile.html === 9.3 Update Locale Information To update your X locale information do the following: cd ~/DRI-CVS/build/xc/nls ../config/util/xmkmf -a make make install === once I did that it all worked fine and I have not seen the message since. See You Steve -- [EMAIL PROTECTED] http://wibble.net/~sjh/ Look Up In The Sky Is it a bird? No Is it a plane? No Is it a small blue banana? YES
Re: build depends on kernel-headers
The thing is, kernel-headers should not be used at all unless you're compile glibc, or modules. Anything else will break. So you're saying it's better to hardcode syscall numbers and stuff than using the kernel headers? Sre... Also chiming in: Suppose my code reads a struct from a device file. That struct is defined in a kernel header (not part of glibc). You're saying I should duplicate that header in my source rather than build-depend on kernel-headers-X.X? Hmmm... -itai
Re: build depends on kernel-headers
On Sun, May 06, 2001 at 01:25:32AM -0400, Itai Zukerman wrote:
Also chiming in: Suppose my code reads a struct from a device file.
That struct is defined in a kernel header (not part of glibc). You're
saying I should duplicate that header in my source rather than
build-depend on kernel-headers-X.X? Hmmm...
Yes, because otherwise your code probably won't compile.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
netscape in unstable and mouse capture
Hello, As usual I has several windows open. In one window, I had a list of options to select, which involved opening up a window with a list of selections I can choice. At the same time, Netscape popped up a dialog box for another window you are now loading a secure page. However, the mouse was still being captured by the pop up window, so I could not push the OK button. At the same time, I couldn't make a selection in this pop-up window, because Netscape required me to push OK at the first dialog box. So feeling a bit irritated, I went to a text mode console, and killed netscape with -9 (as the standard kill never seems to work for Netscape). Now the mouse is still captured, and I can't access anything other then this E-Mail program. (Is this a bug in xserver-xfree86 that netscape is now dead, but the mouse is still captured, or is that an unavoidable side affect of kill -9?) Is there anyway of resolving this situation without killing the X server? Sorry, I am currently typing blind, as this window is hidden by another window, and I can't change it, so lets see how it comes out -- Brian May [EMAIL PROTECTED]
Caching Proxy for apt-get via http?
Hi folks, To reduce network load and speed up upgrades I have installed a caching proxy on one of my machines (using Apache). But it doesn't work very well. Packages are downloaded from http.us.debian.org, even if they should have been taken from the cache due to an upgrade of another machine just a few minutes ago. The cache size is 300 MByte, so I doubt that this happens due to lack of space. And cheating Round Robin by using an IP address instead of 'http.us.debian.org' didn't help either. Does anybody out there know what is the problem here? Maybe its the failure of Apache. What are your suggestions for running a cache for apt-get? Regards Harri
Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 22:35:58 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 05:47:21PM -0700, Alexander Hvostov wrote: On Sat, 5 May 2001 19:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: You should look into the S/390 port. The S/390 port is hardware specific. For obvious reasons (how many Debian machines are S/390s?), this is inadequate. And anyway, I was referring to a Linux kernel in a process (ie, it behaves just like any other program, albeit rather large), not two Linux kernels running separately, which is what I understand the S/390 port does. Hardware support is what is necessary to do what you described (in your previous message) at this time. What you described above sounds more like user-mode Linux. That's what I was describing. I had forgotten the name. Thanks! Regards, Alex.
Re: Caching Proxy for apt-get via http?
On Sun, May 06, 2001 at 07:54:17AM +0200, Harald Dunkel wrote: Does anybody out there know what is the problem here? Maybe its the failure of Apache. What are your suggestions for running a cache for apt-get? As far as I am aware, Apache's caching functionality is rather primitive. Try Squid. -- - mdz
Re: Caching Proxy for apt-get via http?
Harald == Harald Dunkel [EMAIL PROTECTED] writes: Harald Hi folks, To reduce network load and speed up upgrades I Harald have installed a caching proxy on one of my machines Harald (using Apache). But it doesn't work very well. Packages Harald are downloaded from http.us.debian.org, even if they Harald should have been taken from the cache due to an upgrade of Harald another machine just a few minutes ago. Harald The cache size is 300 MByte, so I doubt that this happens Harald due to lack of space. And cheating Round Robin by using an Harald IP address instead of 'http.us.debian.org' didn't help Harald either. Have you told squid that it can use greater then 100MByte (the default)? (When I upgraded squid from unstable to stable, I told dpkg to install the new config file, with the low default limit. squid was automatically restarted, and it proceeded to remove files from my cache. Ooops. Something you have to watch out for) Harald Does anybody out there know what is the problem here? Harald Maybe its the failure of Apache. What are your suggestions Harald for running a cache for apt-get? In my squid file, I put in refresh_pattern \.deb$ 43200 100%43200 refresh_pattern Release$720 100%720 refresh_pattern Packages.gz$720 100%720 refresh_pattern Sources.gz$ 720 100%720 to try and eliminate this problem. Seems to work fine. So far... -- Brian May [EMAIL PROTECTED]
Re: Debconf and substitution in long description
On Sat, 5 May 2001, Joey Hess wrote: The first substitution worked, the second didn't. I suspect this may be because I'm running testing instead of unstable at home. I'll try unstable debconf now. That sounds similar to a bug I fixed in 0.9.36. Indeed the version from unstable works. I'll make the package depend on debconf = 0.9.36 then. Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 02:15:58PM -0700, John H. Robinson, IV wrote:
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote:
workaround: just extract the data.tar.gz where you want it.
dpkg-home () {
[ $1 ] || { echo usage: $0 deb_to_install.deb [dir_to_install]
return 1 }
( cd ${2:-$HOME}
ar p $1 data.tar.gz | tar xzf - )
}
Or simply:
dpkg --extract deb dir
--
- mdz
Re: how to implement a renamed package
Hello, On Sat, May 05, 2001 at 10:23:47PM -0500, Ben Burton wrote: Hi.. I've never done this myself, but I'm sure I've seen it happen in the past: If you're replacing foo with newfoo, you upload a new dummy package foo that contains absolutely nothing, but depends on newfoo. This way apt-get upgrade will get the latest (empty) foo and thus drag in newfoo with it. Many thanks. That is probably the best solution currently possible. I will do it this way, and will request the removal of the dummy package from the archives after a sufficiently long transition period. Cheers, Guenter -- Linux: Who needs GATES in a world without fences?
RE: netscape in unstable and mouse capture
Well, I don't know the solution for that, but one thing I know for sure now: you're a hell of a touch typist :) On 06-May-2001 Brian May wrote: Hello, As usual I has several windows open. In one window, I had a list of options to select, which involved opening up a window with a list of selections I can choice. At the same time, Netscape popped up a dialog box for another window you are now loading a secure page. However, the mouse was still being captured by the pop up window, so I could not push the OK button. At the same time, I couldn't make a selection in this pop-up window, because Netscape required me to push OK at the first dialog box. So feeling a bit irritated, I went to a text mode console, and killed netscape with -9 (as the standard kill never seems to work for Netscape). Now the mouse is still captured, and I can't access anything other then this E-Mail program. (Is this a bug in xserver-xfree86 that netscape is now dead, but the mouse is still captured, or is that an unavoidable side affect of kill -9?) Is there anyway of resolving this situation without killing the X server? Sorry, I am currently typing blind, as this window is hidden by another window, and I can't change it, so lets see how it comes out -- Brian May [EMAIL PROTECTED] -- carlos laviola - icq #981913 $ chown us:us /your_base -R chown: what you say!!
Re: netscape in unstable and mouse capture
Carlos == Carlos Laviola [EMAIL PROTECTED] writes: Carlos Well, I don't know the solution for that, but one thing I Carlos know for sure now: you're a hell of a touch typist :) Well... It was only the last paragraph which was completely hidden... Ooops. Perhaps I shouldn't have said that grin. -- Brian May [EMAIL PROTECTED]
Re: Caching Proxy for apt-get via http?
Brian May wrote: Have you told squid that it can use greater then 100MByte (the default)? I haven't tried Squid yet, cause Apache was already in place. Of course I will try it. Many thanx for your configuration hints. Regards Harri
Re: Bug#95975: mutt: doesn't use charset anymore
On Sat, 5 May 2001 10:57:43 -0700, Ben Gertzfield wrote: Just use LC_CTYPE=de_DE. It'll work fine in mutt. (The problem is, if I remember correctly, that X uses ISO8859-1, without the first dash.) Ok, but now I am confused... LC_CTYPE=de_DE LANG=de_DE LC_MESSAGES=C Should give me german umlauts and the prompts/messages should still be like before, right? Do I really not have to set ISO-8859-1 somewhere? Alexander -- Hackers confuse Xmas (25 Dec) with Halloween (31 Oct) Alexander Koch - - WWJD - aka Efraim - PGP 0xE7694969 - KOCH1-RIPE
Re: Bug#95975: mutt: doesn't use charset anymore
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve However, Steve $ LANG=hr_HR LC_COLLATE=C ls -A Steve .A .B .C .a .b .c A B C a b c Steve which was Arthur's point, I believe. That means you can't have ls sort in a different order though (as defined by native language) without messing up the hidden files. IMHO, it seems that ls should (perhaps with a special option which can be aliased to be the default) treat files with a leading . as special, and put these before the other files. After all, the leading . is not defined by the language being used, rather it is a hack used by many user level programs that consider the file a hidden file. (sorry if I missed the point of all of this) -- Brian May [EMAIL PROTECTED]
debian.org
Hello, I hope you can help me. May I ask if your company/organization put MS Word files on your CD's? We are the sole distributors of icWord, which isthe Microsoft word viewer for the Mac. Our SW allows Mac users to view, copy and print Word documents without having to purchase or use Microsoft Word. icWord viewer is also designed for CD distribution purposes. Do you think you could find interest in such a viewer? If you have any questions please feel free to contact me. Your opinionwill be appreciated. Thank you, Penny B. Panergy Ltd. [EMAIL PROTECTED]
Re: build depends on kernel-headers
On Sun, May 06, 2001 at 03:29:58PM +1000, Herbert Xu wrote: On Sun, May 06, 2001 at 01:25:32AM -0400, Itai Zukerman wrote: Also chiming in: Suppose my code reads a struct from a device file. That struct is defined in a kernel header (not part of glibc). You're saying I should duplicate that header in my source rather than build-depend on kernel-headers-X.X? Hmmm... Yes, because otherwise your code probably won't compile. ... when the kernel interface changed. Now tell me what is better - the package not building with the changed kernel or not working after being installed at x*1000 machines? cu Torsten pgpoW2TD3BPmt.pgp Description: PGP signature
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 03:06:11PM -0500, Manoj Srivastava wrote: Ben == Ben Collins [EMAIL PROTECTED] writes: Ben False. That is the very thing I want to alleviate (people using kernel Ben headers from the libc6-dev package). However, that is what 99% of the programs out there need to do, since they really are not dependent on the specifics of kernel structures, and we should discourage un needed dependency on kernel structures. All I want is to be able to build ipmasqadm... (It needs ip_masq.h, which used to be in libc6-dev, but isn't any longer) Now, for the 1% or so of the packages that really are wedded to kernel headers, that is correct. But then these packages should not run on n a kernel version that they were compiled for. (HINT: if your program can run on a kernel different from the one you compiled for, the chances are that you do not need specific kernel headers; at most, you need to say headers from a kernel later than blah). Sure, fine, wonderful. How do I do this, exactly? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: build depends on kernel-headers
Anthony Towns aj@azure.humbug.org.au wrote:
All I want is to be able to build ipmasqadm... (It needs ip_masq.h,
which used to be in libc6-dev, but isn't any longer)
For a legacy application like ipmasqadm, the solution is to simply copy
ip_masq.h from a 2.2 kernel tree and be done with it.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
On Sun, May 06, 2001 at 10:43:25AM +0200, Torsten Landschoff wrote:
On Sun, May 06, 2001 at 03:29:58PM +1000, Herbert Xu wrote:
Yes, because otherwise your code probably won't compile.
... when the kernel interface changed. Now tell me what is better -
Nope, they won't compile at all because kernel headers are not designed
to be used in user space programs. On architectures like the alpha, there
are definitions such as current which will stop any programs that include
headers which in turn include it from compiling.
the package not building with the changed kernel or not working after
being installed at x*1000 machines?
What is better is a sane local header that works with all kernels.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Why why why!!???
On Friday 04 May 2001 18:27, Noah L. Meyerhans wrote: On Fri, May 04, 2001 at 11:33:58AM -0400, Jaldhar H. Vyas wrote: Oh crap. Ok guys it's been a lot of fun. I really enjoyed working with you and meeting some of you in person but now that Debian is going to be shut down I'll have to look for another operating system. Does anyone know if Microsoft Windows is any good? This should probably not have been sent to the person that originally sent in the erroneous hack notification. We can make fun of their idiocy all we want, but we shouldn't email them personally with it. When they repeatedly respond abusively when it is explained what they did wrong then why not send it to them? Also do you really think we should make publically fun of people without giving them the courtesy of CCing them in on it? -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Bug#95975: mutt: doesn't use charset anymore
On Sun, May 06, 2001 at 07:27:16AM +, Alexander Koch wrote: [...] Should give me german umlauts and the prompts/messages should still be like before, right? Do I really not have to set ISO-8859-1 somewhere? You have to set it in /etc/locale.gen. Make sure that there is a line de_DE ISO-8859-1 without # in front of it. Then call locale-gen. -- CU, Patrick. Never run on auto-pilot - The Pragmatic Programmer pgpbC2HN16yaH.pgp Description: PGP signature
Re: build depends on kernel-headers
On Sun, 6 May 2001, Herbert Xu wrote: ... the package not building with the changed kernel or not working after being installed at x*1000 machines? What is better is a sane local header that works with all kernels. I maintain util-linux that is a user space package that needs many kernel headers (and the package in unstable compiles only with 2.4 kernel headers). I do currently use the kernel haeaders libc6-dev ships. Would it be the right solution to copy the 2.4.4 kernel headers into the package and use them? cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: debian.org
On Sun, May 06, 2001 at 11:42:28AM +0200, [EMAIL PROTECTED] wrote: Hello, I hope you can help me. May I ask if your company/organization put MS Word files on your CD's? We are the sole distributors of icWord, which is the Microsoft?? word viewer for the Mac. Our SW allows Mac users to view, copy and print Word documents without having to purchase or use Microsoft Word. icWord?? viewer is also designed for CD distribution purposes. Do you think you could find interest in such a viewer? If you have any questions please feel free to contact me. Your opinion will be appreciated. How interesting. I wonder what drugs posessed them to think we'd be interested in this... :) -- - -/- - Rahul Jain - -\- - - -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- - - -/- I never could get the hang of Thursdays. - HHGTTG by DNA -\- - |--||--||-|--|-|-|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
Re: Bug#95975: mutt: doesn't use charset anymore
On Sun, May 06, 2001 at 07:27:16AM +, Alexander Koch wrote: Just use LC_CTYPE=de_DE. It'll work fine in mutt. (The problem is, if I remember correctly, that X uses ISO8859-1, without the first dash.) Ok, but now I am confused... LC_CTYPE=de_DE LANG=de_DE LC_MESSAGES=C Should give me german umlauts and the prompts/messages should still be like before, right? Do I really not have to set ISO-8859-1 somewhere? Yes, because the locale alias file will assume ISO-8859-1 automatically. % grep ^de_DE' ' /usr/lib/X11/locale/locale.alias de_DE de_DE.ISO8859-1 -- Digital Electronic Being Intended for Assassination and Nullification
Does BTS clean old bugs?
On the bts web interface, it's written that closed bugs are cleaned up after a period of inactivity. Are they permanently erased? I'd prefer that a complete history of all bugs is preserved. Thanks, -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Caching Proxy for apt-get via http?
Harald Dunkel wrote: Brian May wrote: Have you told squid that it can use greater then 100MByte (the default)? I haven't tried Squid yet, cause Apache was already in place. Of course I will try it. I've got the same effect using Squid. When I tried to install Xpilot (just for testing of course :-), then some files (not all!) were not cached, as it seems. Of course I checked the cache size, the maximum file size, etc. ??? Regards Harri
Re: Does BTS clean old bugs?
On Sun, May 06, 2001 at 03:00:56PM +0300, Eray Ozkural (exa) wrote: On the bts web interface, it's written that closed bugs are cleaned up after a period of inactivity. Are they permanently erased? I'd prefer that a complete history of all bugs is preserved. They aren't, that sentence is unclear, a bug has already been filed. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Does BTS clean old bugs?
On Sun, May 06, 2001 at 03:00:56PM +0300, Eray Ozkural (exa) wrote: On the bts web interface, it's written that closed bugs are cleaned up after a period of inactivity. Are they permanently erased? I'd prefer that a complete history of all bugs is preserved. they are archived. thats what the `search archived bugs' option in the search page is for. it would be quite a mess if bugs were listed on packages for eternity after they are closed. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIaPrppsOaj.pgp Description: PGP signature
Re: Does BTS clean old bugs?
Josip Rodin wrote: On Sun, May 06, 2001 at 03:00:56PM +0300, Eray Ozkural (exa) wrote: On the bts web interface, it's written that closed bugs are cleaned up after a period of inactivity. Are they permanently erased? I'd prefer that a complete history of all bugs is preserved. They aren't, that sentence is unclear, a bug has already been filed. Yes, it is a bit ambiguous indeed. Thanks, -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: build depends on kernel-headers
On Sun, May 06, 2001 at 12:28:32PM +0200, Adrian Bunk wrote:
I maintain util-linux that is a user space package that needs many kernel
headers (and the package in unstable compiles only with 2.4 kernel
headers). I do currently use the kernel haeaders libc6-dev ships. Would
it be the right solution to copy the 2.4.4 kernel headers into the package
and use them?
It needs to be looked at on a case-by-case basis. In general though,
if you need access to something that is not provided by glibc, you'll
have to setup a local header file and maintain it yourself as new
kernel releases come out.
I wouldn't expect the Debian maintainer to have to go through this
though, as this is something that must be dealt with in the upstream
util-linux package.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
libggi2 and testing?
Is there any reason why libggi2 from unstable is not in testing? All architectures have now been compiled, being all present and up-to-date in the pool, but update-excuses gives no hints as to why it hasn't been accepted in testing. It (update-output) mumbles something incoherent about the package on alpha, but it's now been built for alpha. I ask because my package mirrormagic seems to be held up by libsdl, and libsdl appears to be held up by libggi2. Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: libggi2 and testing?
On Sun, May 06, 2001 at 11:27:13PM +1000, Drew Parsons wrote: Is there any reason why libggi2 from unstable is not in testing? All architectures have now been compiled, being all present and up-to-date in the pool, but update-excuses gives no hints as to why it hasn't been accepted in testing. It (update-output) mumbles something incoherent about the package on alpha, but it's now been built for alpha. Yup, but the version on alpha depends libc6.1 = 2.2.3-1 or so, and libc6 2.2.3-1 doesn't build on i386... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: build depends on kernel-headers
On Sun, 6 May 2001, Herbert Xu wrote: I maintain util-linux that is a user space package that needs many kernel headers (and the package in unstable compiles only with 2.4 kernel headers). I do currently use the kernel haeaders libc6-dev ships. Would it be the right solution to copy the 2.4.4 kernel headers into the package and use them? It needs to be looked at on a case-by-case basis. In general though, if you need access to something that is not provided by glibc, you'll have to setup a local header file and maintain it yourself as new kernel releases come out. What do you suggest in my specific case with util-linux? I wouldn't expect the Debian maintainer to have to go through this though, as this is something that must be dealt with in the upstream util-linux package. You mean every upstream source should ship it's own kernel headers? That's ugly and it reminds me that libtool does the same (every program tht uses libtool ships it's own copy of libtool) - and every time I compile a program that uses libtool under NetBSD/sparc-1.5 I must do a libtoolize --force to prevent a miscompilation of the libraries - it would be much more easy when the programs would use a locally installed libtool instead. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Chrony mailing list needs a home
On Fri, May 04, 2001 at 09:48:54PM -0500, John Hasler wrote: Joey Hess writes: Well I guess you could use sourceforge. I assume that the author has his reasons for not wanting to use Sourceforge. I believe sunsite.auc.dk does provide services to opensource projects as well, you may want to take a look at that. regards, Filip -- When you are having a bad day, and it seems like everybody is trying to tick you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle. -- John Galt pgpYzil3u8MIz.pgp Description: PGP signature
Re: Caching Proxy for apt-get via http?
On Sun, May 06, 2001 at 07:54:17AM +0200, Harald Dunkel wrote: Does anybody out there know what is the problem here? Maybe its the failure of Apache. What are your suggestions for running a cache for apt-get? Umm... how about apt-proxy? -- Andrew Suffield [EMAIL PROTECTED] pgp1umND2vBVo.pgp Description: PGP signature
ITP: wmfinder -- A graphical file manager for WindowMaker
retitle 80278 ITP: wmfinder -- A graphical file manager for WindowMaker thanks Hi, I intend to package wmfinder, which is a Qt based file manager for WindowMaker. The packaging will take some time, as the program currently uses Qt 1.45, which has been dropped. I'm talking to upstream about converting it to Qt 2. Program home page is http://www.imago.ro/wmfinder , license is GPL 2. Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: About native packages
Adrian Bunk [EMAIL PROTECTED] writes: It's different when the Debian maintainer is also upstream. It is argued that then there's only one `debianization'. That's all right but please consider the following cases before making your package Debian native: - Do you want to release a new upstream version to fix a missing build dependency? And further- What if your program outlives your interest in it? i.e. what if someone else takes it over upstream eventually, and they're not a Debian developer? I tend to think that in many cases, preserving the upstream/Debian distinction is wise, even if not totally necessary ATM. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
A Quebecer in France.
Sorry, this message is for people currently living in France where I'm going this summer. I'm a little too much lazy to translate it currently and I expect the people interested will be able to read it in French. Thanks! === Bon, c'est juste un email envoyé sur plusieurs ML pour vous avertir de ma visite en France du 23 juin au 9 juillet. Je serai sur Paris du 23 au 25 juin, puis ensuite LaRochelle du 25 au 28 juin, suivi d'Audenges (Bassin d'Arcachon) le 28 et 29 juin pour finalement terminé mon voyage à Bordeaux à partir du 30 (avec la conférence sur Debian et le Logiciel Libre). J'ai bien hâte de rencontrer tous ces visages électroniques, d'échanger des poignées de mains et d'intéressantes discussions, et je serais aussi disponible pour signer vos clefs PGP pour les intéressés. Merci et à la prochaine, Fabien. PS: SVP, attention au reply... n'oubliez pas de retirer les ML dont vous ne faites pas parti ou en m'écrivant directement à mon adresse personnel (voir signature ci-bas). -- ---* *- Fabien Niñoles/ / [EMAIL PROTECTED] Chevalier Servant de Sa Dame / / C15D FE9E BB35 F596 127F Veneur Gris par la Clef / /BF7D 8F1F DFC9 BCE0 9436 Développeur pour Debian/ / http://www.tzone.org/~fabien --* *--
Re: build depends on kernel-headers
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony All I want is to be able to build ipmasqadm... (It needs ip_masq.h, Anthony which used to be in libc6-dev, but isn't any longer) % cp /path/to/old/kerhnel/source/include/linux/ipmasq.h ipmasq.h manoj -- The mosquito exists to keep the mighty humble. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
Itai == Itai Zukerman [EMAIL PROTECTED] writes: Itai Why not have the default KSRC be /usr/src/kernel-headers-X.X? I Itai think that's what Ben suggested... Are you aware that that is what we used to do, circa libc5 days? And that we have moved away from that, for all the reasons that have been posted here several time before? (look at README.headers in the kernel-package docs for a blow by blow account). manoj -- It's all magic. :-) --Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
Aaron == Aaron Lehmann [EMAIL PROTECTED] writes: Aaron So you're saying it's better to hardcode syscall numbers and stuff Aaron than using the kernel headers? Sre... We already have a process for packages that actually do need kernel headers, and are thus dependent on particular kernel versions. Are you also sure you have considered the impact of using one set of kernel structures, and linking with a libc that uses perhaps an incompatible set of kernel-structures? Kernel modules are loaded into the kernel, and thus are in the kernel's context, but user space modules, linked with libc, are playing with fire when they assume that the incompatible kernel structures they have been compiled with are not going to cause problems. If your package does meet the criteria, it is extremely rare, and I do not think it is wirth the infrastructure to cater to the very few packages that shall meet these criteria. manoj -- Under deadline pressure for the next week. If you want something, it can wait. Unless it's blind screaming paroxysmally hedonistic... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
Adrian == Adrian Bunk [EMAIL PROTECTED] writes: Adrian I maintain util-linux that is a user space package that needs Adrian many kernel headers (and the package in unstable compiles Adrian only with 2.4 kernel headers). I do currently use the kernel Adrian haeaders libc6-dev ships. Would it be the right solution to Adrian copy the 2.4.4 kernel headers into the package and use them? Depends on how often the structures you depend on change. I would assume that you are OK with any fairly recent kernel includes, such as those provided by libc. If not, I would expect to see util-linux-2.4.4 out there soon. manoj -- Love IS what it's cracked up to be. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote: I'm beginning to think a better solution would be an operating system within an operating system, and let the user play in her `own' system, and while it for all intents and purposes seems to be running on bare metal, it really is a virtual machine. That would be quite fantastic for doing normally privileged operations without a security risk, though. In the Hurd, any user can boot a sub-Hurd system off a root filesystem image. (root means root filesystem, has nothing to do with the user root). In this sub-Hurd, it appears that the user has indeed control over a new instance of the Hurd operating system. The root filesystem can contain different software than the default system. From the default system, the processes run under the id of the user, but within the sub-Hurd, the user can acquire super-user privileges (uid 0). No permissions leak outside the sub Hurd. sub-Hurds can be nested of course. There is currently no virtualization implemented: All direct kernel accesses (hardware access etc) are simply forwarded to the systems kernel. However, the kernel is used for few things: As a microkernel based system, most of the functionality lives in user space kernels (which are duplicated in the sub Hurd). However, the boot process (the command used to boot the sub-Hurd) can intervene such kernel calls and virtualize them. This is something that interested people can work on. Indeed, you can implement whatever functionality you want. Again, systems security is strictly preserved by the default servers (modulo bugs ;). For that to work, you'd also need to set up a base system for each and every developer. That would waste a lot of disk space in a hurry. Perhaps copy-on-write file links would do the trick here, allowing root to keep a central repository of a prototypical base system, and allowing each developer to change it at will, For the Hurd we plan something called shadowfs. shadowfs will allow to stack filesystems in a single view. For example, you could join a read-only ext2fs filesystem and a tmpfs (in RAM) over it. Files in the tmpfs would shade the underlying ext2fs files, and new files would be created in the tmpfs, too. This way you get the copy-on-write trick you imagined. But that's not all. Ideally, such a shadowfs implementation would merge multiple filesystem trees, for example the system tree (ro) plus a user provided root filesystem. Then you can use this shadowfs to boot a sub-Hurd from, running from the default system usually but running from your files where they exist. This way you can test new servers in the sub Hurd with minimal cost. Oh, did I mention that all sub Hurd processes appear in the parents sub Hurd process table? This way you can attach gdb to them (from the outside) and debug them like any other process (even system-critical servers). Of course, if the sub Hurd crashes, the parent systems are not affected. but without wasting disk space unless something actually changes. Of course, that means big changes in the kernel's VFS code and possibly elsewhere, but copy-on-write links would be way cool for other reasons as well[1-2]. In Linux, yes. This would be close to impossible to implement securely without rewriting major parts of the kernel (possibly all). The Hurd provides the substantial features and design paradigms today (there are bugs, and there are missing features like full virtualization and shadowfs, but booting a sub Hurd for example works). [3] I understand Microsoft has done something like that in one of their operating systems or another. It was on Slashdot a while back. Most people said that what they `invented' are really just symlinks, but the major difference is that they're copy-on-write, whereas writing to a symlink on Unix will write to the file pointed to, but overwriting a symlink will overwrite the symlink, not the file pointed to this; is a pseudo-copy-on-write behavior, but not real copy-on-write like what MS did. Of course, they attached some lame marketroid buzzword TLA to it, but `copy-on-write link' works for me. ;) If you want such a thing, you can implement this as a Hurd filesystem server and run it as a user. You don't need to recompile, install and boot a new kernel. You just attach your server to some directory (mount if you want), and go. You'd probably violate some POSIX requirements with such a thing, but you don't need to limit yourself to it. The Hurd is a POSIX system in its default configuration, but the idea of the Hurd is that any user can extend the system in such ways you describe (and others) without asking anyone. For the far future, giving shadowfs, I'd be interested in a simple packaging system which allows to install multiple version of a single package, and which allows users to install packages. Basically, users packages would be mirrored over the root filesystem with shadowfs, and a sub Hurd
Finishing the FHS transition
Hi, I want to suggest to finish the FHS transition. This includes the following steps: - Packages with Standards-Version = 3.0 must follow the FHS. Policy version 3.0.0.0 was released 30 Jun 1999 and I consider this enough time for every maintainer to switch to at least this Standards-Version. However, there are still 253 packages in unstable (including contrib, non-free and non-US/*) that have an older Standards-Version in the control file. The list (sorted by maintainer) follows below. Some of the maintainers are perhaps MIA, others are definitely not. If noone has a good argument against this I'll send RC bugs in one week to force the upgrade of the Standards-Version. - A change in the policy to remove the obsolete /usr/doc symlinks. List of packages with Standards-Version 3.0 -- snip -- Adam Di Carlo ([EMAIL PROTECTED]) onshore-timesheet Adam Klein ([EMAIL PROTECTED]) ncompress Alan Bain ([EMAIL PROTECTED]) nec Alex Romosan ([EMAIL PROTECTED]) f77reorder Alex Romosan ([EMAIL PROTECTED]) nte Alex Romosan ([EMAIL PROTECTED]) vat Alistair Cunningham ([EMAIL PROTECTED])xchain Anders Hammarquist ([EMAIL PROTECTED]) sformat Andreas Franzen ([EMAIL PROTECTED]) pgapack Anthony Fok ([EMAIL PROTECTED])lexmark7000linux Anthony Towns ([EMAIL PROTECTED]) cruft Anthony Towns ([EMAIL PROTECTED]) distributed-net-pproxy Apt Packaging Team ([EMAIL PROTECTED]) gnome-apt Araki Yasuhiro ([EMAIL PROTECTED]) kcc Arpad Magosanyi ([EMAIL PROTECTED])barracuda Avery Pennarun ([EMAIL PROTECTED]) apmd Avery Pennarun ([EMAIL PROTECTED]) netselect Avery Pennarun ([EMAIL PROTECTED]) wvdial Ben Gertzfield ([EMAIL PROTECTED]) gimp Ben Gertzfield ([EMAIL PROTECTED]) wmifs Bernd Schumacher ([EMAIL PROTECTED]) snmptraplogd Björn Brenander ([EMAIL PROTECTED]) tcputils Brad Bosch ([EMAIL PROTECTED])id-utils Brent A. Fulgham ([EMAIL PROTECTED]) bbmail Brent A. Fulgham ([EMAIL PROTECTED]) efuns Brent A. Fulgham ([EMAIL PROTECTED]) openacs Brian Bassett ([EMAIL PROTECTED])sml-nj C. Thomas ([EMAIL PROTECTED]) wmheadlines Carey W. Evans ([EMAIL PROTECTED])x3270 Chad Miller ([EMAIL PROTECTED]) sc Charles Briscoe-Smith ([EMAIL PROTECTED]) bock Charles Briscoe-Smith ([EMAIL PROTECTED]) cup Charles Briscoe-Smith ([EMAIL PROTECTED]) gramofile Charles Briscoe-Smith ([EMAIL PROTECTED]) infocom Charles Briscoe-Smith ([EMAIL PROTECTED]) int-fiction Charles Briscoe-Smith ([EMAIL PROTECTED]) jlex Charles Briscoe-Smith ([EMAIL PROTECTED]) libggidemos Charles Briscoe-Smith ([EMAIL PROTECTED]) propsel Charles Briscoe-Smith ([EMAIL PROTECTED]) recite Charles Briscoe-Smith ([EMAIL PROTECTED]) rocks-n-diamonds Charles Briscoe-Smith ([EMAIL PROTECTED]) saytime Charles Briscoe-Smith ([EMAIL PROTECTED]) strn Charles Briscoe-Smith ([EMAIL PROTECTED]) xggi Chris Leishman ([EMAIL PROTECTED]) cfs Chris Leishman ([EMAIL PROTECTED]) urlredir Christian Hammers ([EMAIL PROTECTED])myodbc2.50.26 Christian Leutloff ([EMAIL PROTECTED]) rxtx Christian Meder ([EMAIL PROTECTED]) afbackup Christian Meder ([EMAIL PROTECTED]) ftape-doc Christian Meder ([EMAIL PROTECTED]) ftape-tools Christoph Lameter ([EMAIL PROTECTED])wmf Christoph Martin ([EMAIL PROTECTED]) pgp5i Christophe Le Bars ([EMAIL PROTECTED]) doc-debian-fr Chu-yeon Park ([EMAIL PROTECTED])rat Clint Adams ([EMAIL PROTECTED]) set6x86 Craig Sanders ([EMAIL PROTECTED]) dlocate Craig Sanders ([EMAIL PROTECTED]) libdevel-symdump-perl Craig Sanders ([EMAIL PROTECTED]) libfile-tail-perl Craig Sanders ([EMAIL PROTECTED]) speedy-cgi-perl Craig Sanders ([EMAIL PROTECTED]) tkinfo Dale E. Martin ([EMAIL PROTECTED])tyvis Dale James Thompson ([EMAIL PROTECTED]) postilion Daniel Martin ([EMAIL PROTECTED])cqcam Daniel Martin ([EMAIL PROTECTED])tkdesk Darren Benham ([EMAIL PROTECTED]) wmcpu Darren Benham ([EMAIL PROTECTED]) wmdate Darren Benham ([EMAIL PROTECTED]) wmgrabimage Darren Benham ([EMAIL PROTECTED])
Re: Finishing the FHS transition
Adrian Bunk wrote: ... Oliver Elphick ([EMAIL PROTECTED]) libpgsql This package is obsolete and should not be included in any release. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C If it is possible, as much as it depends on you, live peaceably with all men.Romans 12:18
Re: Finishing the FHS transition
On Sun, 6 May 2001, Oliver Elphick wrote: Adrian Bunk wrote: ... Oliver Elphick ([EMAIL PROTECTED]) libpgsql This package is obsolete and should not be included in any release. Please ask the ftp admins to remove the package from unstable (file a bug against ftp.debian.org). cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Voltaire will be unavailable for a bit
Voltaire is about to move temporarily across the country. It should be available again in about a week; it might take as long as two. Debian/PowerPC may languish a little bit in its absence :( -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote: I want to suggest to finish the FHS transition. This includes the following steps: - Packages with Standards-Version = 3.0 must follow the FHS. Didn't we already have this discussion? The Standards-Version field is not a reliable indication of much of anything. I strongly object to removing packages because of what amount to cosmetic issues, and an incorrect Standards-Version (one that doesn't reflect the version of policy that the package _actually_ complies with) is really no more than a cosmetic issue (no software actually uses that field). I only have a few of the listed packages installed on my system, but most of the ones I checked did indeed use /usr/share/doc (and /usr/share/man, in those cases where man pages were present). I suspect that this is due to the use of debhelper, but anyway Checking for FHS violations should be done by checking for FHS violations, not by checking an unreliable and all-but-meaningless field in some configuration file. (Plus, as a side issue, by a strict reading of the FHS, we should be using /usr/share/menu rather than /usr/lib/menu, which means RC bugs against nearly every package in the system!) :-) - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. Now, if we're really down to 253 packages that use /usr/doc (with no symlink), then maybe it's time. But, unfortunately, that number, 253, measures *claimed* compliance, not actual compliance. Now, my poking around suggests that there are actually far *fewer* than 253 packages still using /usr/doc. And if that's true, then it's definitely time to remove the symlinks. But it might be nice to have some hard facts, rather than speculation based on unreliable claims made by inattentive package maintainers. Ben Gertzfield ([EMAIL PROTECTED]) wmifs Eric Leblanc ([EMAIL PROTECTED])groovycd Eric Leblanc ([EMAIL PROTECTED])zangband Gene McCulley ([EMAIL PROTECTED]) xcopilot Javier Fernandez-Sanguino Pen a ([EMAIL PROTECTED]) spellcast Luis Francisco Gonzalez ([EMAIL PROTECTED]) xgammon Rob Browning ([EMAIL PROTECTED]) emacs20 Robert Woodcock ([EMAIL PROTECTED]) cd-discid Takuo KITAME ([EMAIL PROTECTED]) bbdb Vincent Renardias ([EMAIL PROTECTED]) gdb Vincent Renardias ([EMAIL PROTECTED]) gnumeric Wichert Akkerman ([EMAIL PROTECTED]) sed I inspected these packages. Only emacs20 lacked the /usr/share/doc directory. If that ratio holds true (which I doubt), then we've only got 21 packages left to transition! :-) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
mailq's fake output
Another change in sendmail = another little problem :))) Seriously: few days ago mailq isn't runnable by normal user, as Richard told me. Now the things are changed, if an user (even if he is a member of mail group) run mailq he always get: /var/spool/mqueue is empty Total requests: 0 even if there are mails in the sendmail queue !!! I'm talking about sendmail 8.11.3+8.12.0.Beta7-6, it this problem fixed in -7 version ? Cheers! -- - Zack - Stefano Zacchiroli [EMAIL PROTECTED] ICQ# 33538863 Home Page: http://www.students.cs.unibo.it/~zacchiro Undergraduate Student of Computer Science at University of Bologna, Italy SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134) Information wants to be Open pgpAHujwu53N2.pgp Description: PGP signature
Re: Finishing the FHS transition
Chris Waters schrieb: (Plus, as a side issue, by a strict reading of the FHS, we should be using /usr/share/menu rather than /usr/lib/menu, which means RC bugs against nearly every package in the system!) :-) /usr/lib/menu is not shareable, since it would be most confusing to have a menu item that just doesn't work, because the package it belongs to is installed on another machine with which /usr/share is shared. ciao, 2ri -- Q: How does a Unix guru have sex? A: gunzip strip touch finger mount fsck \ more yes fsck fsck fsck umount sleep
Re: Finishing the FHS transition
On Sun, 6 May 2001, Chris Waters wrote: I want to suggest to finish the FHS transition. This includes the following steps: - Packages with Standards-Version = 3.0 must follow the FHS. Didn't we already have this discussion? The Standards-Version field is not a reliable indication of much of anything. I strongly object Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- to removing packages because of what amount to cosmetic issues, and an Where did I say that I want to remove the packages??? I said that I want to send bug reports. incorrect Standards-Version (one that doesn't reflect the version of policy that the package _actually_ complies with) is really no more than a cosmetic issue (no software actually uses that field). you must specify the most recent version number of this policy document with which your package complies: You must upgrade this field when your package complies with a more recent policy - and when your package does already comply with a more recent policy nothing more than an upload with an updated Standards-Version field is needed. I only have a few of the listed packages installed on my system, but most of the ones I checked did indeed use /usr/share/doc (and /usr/share/man, in those cases where man pages were present). I suspect that this is due to the use of debhelper, but anyway Checking for FHS violations should be done by checking for FHS violations, not by checking an unreliable and all-but-meaningless field in some configuration file. ... See above: I want to file a RC bug either because a) the package follows a too old policy or b) because it violates the _must_ in the polict that says that the Standard-Version must get updated. a) needs discussion whether we consider packages not following the FHS too much out of date, b) is a violation of the policy that doesn't need discussion - that means the only question is whether anyone disagrees that we want to have all packages in unstable to follow the FHS. cheers cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
menu and FHS (was Re: Finishing the FHS transition)
On Sun, May 06, 2001 at 09:13:26PM +0200, Arthur Korn wrote: /usr/lib/menu is not shareable Yes, it is. There's a reason why each entry starts: ?package(name) Anyway, that's not really relevent -- /usr/share is for architecture-independent static files. The FHS doesn't grant exceptions for files that would cause breakage if they actually were shared between different machines. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#96102: ITP: serpento -- dictd server written in python
On Sat, May 05, 2001 at 12:24:56PM +0200, I wrote: On Fri, May 04, 2001 at 09:19:29AM +0200, Tollef Fog Heen wrote: * Radovan Garabik | Can it be run from inetd? I'm really dying for a dict server that can be | | More or less, yes, it can, but currently it is a bit unusable | since it takes forever to start (it has to parse the index file(s), | and parsing is written in python - rewritting it in C is on my TODO list) Why not just using cPickle and smart caching? It's pretty fast, ime. well, that is a _really_ good idea, shame it did not occur to me :-) I am going to experiment with it a bit And it's done - using cPickle cut down startup time from 15 seconds to about 4 sec. Then I changed initialization to parse/unpickle index files only when the database is accessed for the first time, and startup time went down to about 1 second for biggest dictionary (webster). All on PIII 600 MHz with plenty of memory (i.e. all necessary files were already in buffer cache) Package is in incoming, you have to set up manually inetd.conf if you want to run it from inetd (this will be improved later) Also, it includes its own dictdconfig now, so automatic configuration to include all installed databases should work. -- --- | Radovan Garabik 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: Finishing the FHS transition
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote: If noone has a good argument against this I'll send RC bugs in one week to force the upgrade of the Standards-Version. The packages inetutils, gnumach, hurd and mig are only applicable to the Hurd, and we have not determined yet how much and what of the FHS is applicable to us. Most of it is, but we might need an appendix for the Hurd just as there is an appendix for Linux. In any way, I will bump the number if it makes you happy on my next update, and Jeff Bailey took over maintenance of GNU inetutils, he is preparing an update, but I wouldn't consider an old standards version a release critical bug. You will have to bother and check each package individually if there is actually a violation of current policy or a critical bug that warrants a release critical bug report. GNU Hurd Maintainers (bug-hurd@gnu.org) gnumach GNU Hurd Maintainers (bug-hurd@gnu.org) hurd GNU Hurd Maintainers (bug-hurd@gnu.org) mig Marcus Brinkmann ([EMAIL PROTECTED])inetutils Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote: Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- Ok, please ignore my other mail. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Who uses ccmalloc?
On Sun, May 06, 2001 at 19:31:43 +0200, Adrian Bunk wrote: J.H.M. Dassen (Ray) ([EMAIL PROTECTED]) ccmalloc To the best of my knowledge, there's no upstream for ccmalloc anymore. I'm not using it myself, and there are several (possibly better) alternatives available. I'm therefore pondering dropping it, unless someone can convince me it's still being used. Ray -- Cyberspace, a final frontier. These are the voyages of my messages, on a lightspeed mission to explore strange new systems and to boldly go where no data has gone before.
Re: Proposing task-debian
John Hasler [EMAIL PROTECTED] writes: How about an ordinary meta-package named emacs? That might be OK. Bear in mind that there used to be a real package named emacs, though, so you should be wary of breaking upgrades from very old systems. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: libggi2 and testing?
On Sun, 6 May 2001, Anthony Towns wrote: On Sun, May 06, 2001 at 11:27:13PM +1000, Drew Parsons wrote: Is there any reason why libggi2 from unstable is not in testing? All architectures have now been compiled, being all present and up-to-date in the pool, but update-excuses gives no hints as to why it hasn't been accepted in testing. It (update-output) mumbles something incoherent about the package on alpha, but it's now been built for alpha. Yup, but the version on alpha depends libc6.1 = 2.2.3-1 or so, and libc6 2.2.3-1 doesn't build on i386... After two build failures (because of broken gcc and fileutils) it did finally build and I did upload it to incoming. If no new problems arise and Ben doesn't upload a new version it will go into testing in four days. Cheers, aj cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Finishing the FHS transition
On 06-May-01, 14:27 (CDT), Adrian Bunk [EMAIL PROTECTED] wrote: Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- Uhh, when did that become a must? In 3.5.2 the first paragraph says You should specify the most recent version of the packaging standards with which your package complies in the source package's `Standards-Version' field. Even in 3.5.4, towards the end of that section it says You should regularly, and especially if your package has become out of date, check for the newest Policy Manual available and update your package, if necessary. When your package complies with the new standards you should update the Standards-Version source package field and release it. It says nothing about uploading just to notify that you are still compliant. Hmmm, I don't remember a proposal to change this; I suspect the must slipped in during the recent rewrites, and as Chris Waters pointed out, it is certainly inconsistent with the intent of the field according to recent discussion. you must specify the most recent version number of this policy document with which your package complies: You must upgrade this field when your package complies with a more recent policy - and when your package does already comply with a more recent policy nothing more than an upload with an updated Standards-Version field is needed. Nonsense. I'm not going to upload new versions of packages simply to change that field. Lot's of policy updates have zero effect on most packages, and I doubt many of our users want to spend the time and money downloading and installing a new version of a package to confirm that. I would strongly object if (for example) Branden suddenly started uploading new versions of the X packages every time a new version of policy was released. I'll wait a few days for one of the policy editors to say Oops, that was an accident; if that's not the case, I need to propose an ammendent that clarifies reality, so that Adrian doesn't get mislead again :-). Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Who uses ccmalloc?
On Sun, May 06, 2001 at 10:28:56PM +0200, J.H.M. Dassen (Ray) wrote: On Sun, May 06, 2001 at 19:31:43 +0200, Adrian Bunk wrote: J.H.M. Dassen (Ray) ([EMAIL PROTECTED]) ccmalloc To the best of my knowledge, there's no upstream for ccmalloc anymore. I'm not using it myself, and there are several (possibly better) alternatives available. I'm therefore pondering dropping it, unless someone can convince me it's still being used. It is maintained upstream, just moved a bit...: http://www.inf.ethz.ch/personal/biere/projects/ccmalloc Last change(webpage): 5 Feb 01 Version: 0.3.4 (dated 5 Mar 01) I still use it sparingly, I'm no expert with it. Think I use dmalloc the most, possible electric-fence as well. Gordon Sadler
Re: Bug#96224: libgmp3: Move documentation in the -dev package
DS == Dale Scheetz [EMAIL PROTECTED] writes: [...] DS I can be convinced on either count. How would you feel about my presenting DS this issue to the developers at large, with you and I agreeing to follow DS the concensus of the group? Go ahead. DS At this point that seems a waste of time ... I've had a nights sleep on DS it, and I'm currently leaning toward the extreme solution. So I forward this myself. DS Arguments: DS 1. It's been like this forever... DS 2. No one (with the exception of Christian) has ever asked that it be DS moved, and several requests have been made for additional documentation. DS 3. The documentation is development in nature, and should go into the -dev DS package. DS 4. The info, demos, and docs sections are about as large as the libraries DS themselves. Removing them from the runtime is a 50% savings. 5. You can't build demos source if the -dev package isn't installed. 6. Example files should be installed in /usr/lib/package/examples According to the Debian Policy chapter 13.7 DS Conclusion: DS While the principle of least surprise is important, it should not be DS used to stifle progress. Moving the docs and demos out of the runtime DS package is a significant bloat reduction. Moving them into -dev is not. DS Making a third package -doc, containing the info, doc, and demo sections DS now found in the runtime package makes the most sense. Thus a DS non-development system can still have complete documentation when needed DS without either the runtime or the -dev packages installed. (screw 'em if DS they can't find it ;-) My conclusion: You can't build demos source if the -dev package isn't installed. And the info documentation is *really* for developper. This package contain libraries, so an end user don't need to know how to program this library. Christian
Re: build depends on kernel-headers
On Sun, May 06, 2001 at 03:45:39PM +0200, Adrian Bunk wrote:
What do you suggest in my specific case with util-linux?
Which specific program in util-linux and what specific headers?
You mean every upstream source should ship it's own kernel headers?
Yes, they should ship their own headers for kernel data structures and they
need to maintain it so that it works across kernel versions.
That's ugly and it reminds me that libtool does the same (every program
tht uses libtool ships it's own copy of libtool) - and every time I
compile a program that uses libtool under NetBSD/sparc-1.5 I must do a
libtoolize --force to prevent a miscompilation of the libraries - it
would be much more easy when the programs would use a locally installed
libtool instead.
Well someone's got to maintain the kernel/user space interface. If it
isn't glibc (which does it for most things), then it's whoever uses it.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Aaron == Aaron Lehmann [EMAIL PROTECTED] writes: Aaron So you're saying it's better to hardcode syscall numbers Aaron and stuff than using the kernel headers? Sre... Manoj We already have a process for packages that actually Manoj do need kernel headers, and are thus dependent on Manoj particular kernel versions. We do? please explain what it is. Herbert produces kernel headers packages for all flavors of kernels he produces. I do not believe the other arches do this.
Re: Caching Proxy for apt-get via http?
On Sun, May 06, 2001 at 03:05:12PM +0100, Andrew Suffield wrote: On Sun, May 06, 2001 at 07:54:17AM +0200, Harald Dunkel wrote: Does anybody out there know what is the problem here? Maybe its the failure of Apache. What are your suggestions for running a cache for apt-get? Umm... how about apt-proxy? If you don't mind running (and debugging) experimental code.. Has a particularly hard time with round-robin mirrors not being in-sync, or (I think) occationally a mirror not supporting rsync access at all. Also has trouble with over-returning to the client. FE will return 5MB of a 200k deb.. And it requires rsync access to the repository. Despite all this, I did find it working a bit better on my dialup connection than squid was. Oh yeah, you'll want to give it a big cache, too. It doesn't seem to be able to clean its own cache properly. -- Ferret
Re: Finishing the FHS transition
Chris Waters wrote: - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. No, it is supposed to happen one release _after_ a release in which all the packages have made the transition. So sarge at the earliest, not woody. -- see shy jo
Re: build depends on kernel-headers
Sam Hartman [EMAIL PROTECTED] wrote:
We do? please explain what it is. Herbert produces kernel headers
packages for all flavors of kernels he produces. I do not believe the
other arches do this.
You obviously weren't listening to me when I explained this in the bloat
thread. If you aren't compiling a kernel module, then the flavoued kernel
headers packages do not exist for you, period.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
Herbert == Herbert Xu [EMAIL PROTECTED] writes: Herbert Sam Hartman [EMAIL PROTECTED] wrote: We do? please explain what it is. Herbert produces kernel headers packages for all flavors of kernels he produces. I do not believe the other arches do this. Herbert You obviously weren't listening to me when I explained Herbert this in the bloat thread. If you aren't compiling a Herbert kernel module, then the flavoued kernel headers packages Herbert do not exist for you, period. I thought Manoj's comments applied to modules.
apt complaining about valid dependencies
What is apt-get upgrade complaining about here? On a cursory glance, there isn't anything wrong with any of these proposed installations: This is apt 0.5.3. 148 packages upgraded, 0 newly installed, 0 to remove and 11 not upgraded. Sorry, but the following packages have unmet dependencies: alsa-utils: Depends: libc6 (= 2.1.97) but 2.2.2-4 is to be installed asclock: Depends: libc6 (= 2.2.1-2) but 2.2.2-4 is to be installed asclock-themes: Conflicts: asclock ( 2.0.12) but 2.0.12-3 is to be installed awe-midi: Depends: libawe0.4 but 0.4.3.1-1.2 is to be installed Depends: libc6 (= 2.2.2-2) but 2.2.2-4 is to be installed Depends: libncurses5 (= 5.2.20010310-1) but 5.2.20010318-1 is to be installed battleball: Depends: libc6 (= 2.1.97) but 2.2.2-4 is to be installed bluefish: Depends: libglib1.2 (= 1.2.0) but 1.2.10-1.1 is to be installed Depends: libtiff3g but 3.5.5-3 is to be installed c2man: Depends: libc6 (= 2.1.2) but 2.2.2-4 is to be installed clanlib0-common: Depends: libbz2 but 0.9.5d-4 is to be installed Depends: libhdf4g (= 4.1r3) but 4.1r4-5 is to be installed craft: Depends: libc6 (= 2.2.1-2) but 2.2.2-4 is to be installed debhelper: Depends: file (= 3.23-1) but 3.33-4 is to be installed Depends: lynx debmake: Depends: file but 3.33-4 is to be installed Depends: patch but 2.5.4-3 is to be installed deity-curses: Depends: libc6 (= 2.2.2-2) but 2.2.2-4 is to be installed dhelp: Depends: libc6 (= 2.1.2) but 2.2.2-4 is to be installed dia: Depends: dia-common (= 0.86-7) but 0.86-7 is to be installed diald: Depends: libc6 (= 2.2.2-2) but 2.2.2-4 is to be installed Depends: ppp ( 2.2) but 2.4.1-1 is to be installed doc-base: Conflicts: dhelp ( 0.3.14) but 0.3.23 is to be installed dpkg-perl: Depends: perl5 Depends: libnet-perl but 1.0703-4.1 is to be installed dupload: Depends: perl (= 5.003) but 5.6.0-21 is to be installed Depends: libnet-perl but 1.0703-4.1 is to be installed dwww: Depends: perl but 5.6.0-21 is to be installed enlightenment: Depends: libungif4g (= 4.1-1) but 4.1-6 is to be installed evolution: Depends: libjpeg62 but 6b-1.3 is to be installed Depends: libldap2 (= 2.0.2-2) but 2.0.7-5 is to be installed Depends: liboaf0 (= 0.6.5) but 0.6.5-5 is to be installed Depends: libtiff3g but 3.5.5-3 is to be installed flex: Depends: libc6 (= 2.1.2) but 2.2.2-4 is to be installed freeciv-xaw3d: Depends: freeciv (= 1.10) but 1.11.4-3 is to be installed Depends: xaw3dg (= 1.3-1) but 1.5-7 is to be installed freetype2-dev: Depends: libc6-dev but 2.2.2-4 is to be installed Conflicts: freetype0-dev but it is not installable Conflicts: freetype1 (= 1.0.0.1998-03-22-1) but 1.0.0.1998-03-22-4 is to be installed gabber: Depends: libgnomemm1.1 but 1.1.17-1 is to be installed gglyph: Depends: libc6 but 2.2.2-4 is to be installed libgtkhtml7: Depends: libgtk1.2 (= 1.2.10-1) but 1.2.10-1 is to be installed Depends: libunicode0 (= 0.4.0-2) but 0.4.0-2 is to be installed E: Internal Error, InstallPackages was called with broken packages! -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C If it is possible, as much as it depends on you, live peaceably with all men.Romans 12:18
Re: apt complaining about valid dependencies
On Mon, 7 May 2001, Oliver Elphick wrote: What is apt-get upgrade complaining about here? On a cursory glance, there isn't anything wrong with any of these proposed installations: It's an error with how the message is printed, it is showing the wrong number for 'is to be installed' IIRC. Jason
Re: apt complaining about valid dependencies
Hi, First I'd try: apt-get -f install Then I'd try to resolve each problem separately. Eg: apt-get install alsa-utils apt-get install asclock . Also, have you tried a dist-upgrade? - Tal On Mon, May 07, 2001 at 12:15:19AM +0100, Oliver Elphick wrote: What is apt-get upgrade complaining about here? On a cursory glance, there isn't anything wrong with any of these proposed installations: This is apt 0.5.3. 148 packages upgraded, 0 newly installed, 0 to remove and 11 not upgraded. Sorry, but the following packages have unmet dependencies: alsa-utils: Depends: libc6 (= 2.1.97) but 2.2.2-4 is to be installed asclock: Depends: libc6 (= 2.2.1-2) but 2.2.2-4 is to be installed [...] -- .--. / Tal Danzig: [EMAIL PROTECTED] \ (Libranet GNU/Linux http://www.libranet.com ) `'
Re: build depends on kernel-headers
On Mon, 7 May 2001, Herbert Xu wrote: What do you suggest in my specific case with util-linux? Which specific program in util-linux and what specific headers? ... (I tried my best but I can't garuantee this is 100% complete...) fdisk: linux/unistd.h linux/hdreg.h linux/blkpg.h linux/types.h linux/major.h cfdisk: linux/unistd.h linux/types.h linux/hdreg.h sfdisk: linux/unistd.h linux/hdreg.h mkswap: asm/page.h hwclock: asm/io.h asm/rtc.h asm/cuda.h linux/version.h linux/mc146818rtc.h linux/kd.h setterm: asm/ioctls.h mount + umount: asm/types.h asm/page.h linux/posix_types.h linux/loop.h linux/nfs.h linux/unistd.h linux/nfs_mount.h swapon: linux/unistd.h pivot_root: linux/unistd.h fdformat: linux/fd.h setfdprm: linux/fd.h raw: linux/raw.h linux/major.h fsck.minix: linux/fs.h linux/minix_fs.h mkfs.minix: linux/fs.h linux/minix_fs.h setterm: linux/unistd.h cytune: linux/tty.h linux/tqueue.h linux/cyclades.h linux/version.h dmesg: linux/unistd.h cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Finishing the FHS transition
* Adrian Bunk [EMAIL PROTECTED] [20010506 21:27]: See above: I want to file a RC bug either because a) the package follows a too old policy or For the /usr/doc problem, bugs with severity: normal have already been filed by doogie and joeyh. For these packages, you simply have to change the severity. At the moment, 103 of these bugs are still open (248 bugs were filed originally): Package: acm Maintainer: Enrique Zanardi [EMAIL PROTECTED] 91371 Package acm still has at least one file in /usr/doc 91382 Package acm still has at least one file in /usr/doc Package: authbind Maintainer: Ian Jackson [EMAIL PROTECTED] 91376 Package authbind still has at least one file in /usr/doc 91387 Package authbind still has at least one file in /usr/doc Package: bock Maintainer: Charles Briscoe-Smith [EMAIL PROTECTED] 91396 Package bock still has at least one file in /usr/doc Package: cqcam Maintainer: Daniel Martin [EMAIL PROTECTED] 91415 Package cqcam still has at least one file in /usr/doc Package: cracklib-runtime Maintainer: Jean Pierre LeJacq [EMAIL PROTECTED] 91407 Package cracklib-runtime still has at least one file in /usr/doc Package: cracklib2 Maintainer: Jean Pierre LeJacq [EMAIL PROTECTED] 91414 Package cracklib2 still has at least one file in /usr/doc Package: cracklib2-dev Maintainer: Jean Pierre LeJacq [EMAIL PROTECTED] 91429 Package cracklib2-dev still has at least one file in /usr/doc Package: csound-doc Maintainer: Guenter Geiger [EMAIL PROTECTED] 91433 Package csound-doc still has at least one file in /usr/doc Package: cup Maintainer: Charles Briscoe-Smith [EMAIL PROTECTED] 91422 Package cup still has at least one file in /usr/doc Package: doc-debian-fr Maintainer: Christophe Le Bars [EMAIL PROTECTED] 91417 Package doc-debian-fr still has at least one file in /usr/doc Package: dtlk Maintainer: [EMAIL PROTECTED] (James R. Van Zandt) 91438 Package dtlk still has at least one file in /usr/doc Package: dtmfdial Maintainer: [EMAIL PROTECTED] (Stephen J. Carpenter) 91450 Package dtmfdial still has at least one file in /usr/doc Package: dvidvi Maintainer: [EMAIL PROTECTED] (David A. van Leeuwen) 91439 Package dvidvi still has at least one file in /usr/doc Package: emacs20-el Maintainer: Rob Browning [EMAIL PROTECTED] 91554 Package emacs20-el still has at least one file in /usr/doc Package: emacsen-common Maintainer: Rob Browning [EMAIL PROTECTED] 91457 Package emacsen-common still has at least one file in /usr/doc Package: f77reorder Maintainer: Alex Romosan [EMAIL PROTECTED] 91444 Package f77reorder still has at least one file in /usr/doc Package: faqomatic Maintainer: [EMAIL PROTECTED] (Scott K. Ellis) 91465 Package faqomatic still has at least one file in /usr/doc Package: ftape-doc Maintainer: Christian Meder [EMAIL PROTECTED] 91463 Package ftape-doc still has at least one file in /usr/doc Package: ftape-util Maintainer: Christian Meder [EMAIL PROTECTED] 91462 Package ftape-util still has at least one file in /usr/doc Package: gap4-gdat Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 91470 Package gap4-gdat still has at least one file in /usr/doc Package: gap4-tdat Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 91469 Package gap4-tdat still has at least one file in /usr/doc Package: gbdk-dev Maintainer: Masato Taruishi [EMAIL PROTECTED] 91472 Package gbdk-dev still has at least one file in /usr/doc Package: gbdk-examples Maintainer: Masato Taruishi [EMAIL PROTECTED] 91471 Package gbdk-examples still has at least one file in /usr/doc Package: gcc-m68k-linux Maintainer: Martin Mitchell [EMAIL PROTECTED] 91476 Package gcc-m68k-linux still has at least one file in /usr/doc Package: gerstensaft Maintainer: Martin Schulze [EMAIL PROTECTED] 91477 Package gerstensaft still has at least one file in /usr/doc Package: glimpse Maintainer: Marco Budde [EMAIL PROTECTED] 91484 Package glimpse still has at least one file in /usr/doc Package: gs-aladdin-manual Maintainer: Marco Pistore [EMAIL PROTECTED] 91486 Package gs-aladdin-manual still has at least one file in /usr/doc Package: gs-aladdin-manual-de Maintainer: Marco Pistore [EMAIL PROTECTED] 91483 Package gs-aladdin-manual-de still has at least one file in /usr/doc Package: gsfonts Maintainer: Torsten Landschoff [EMAIL PROTECTED] 91489 Package gsfonts still has at least one file in /usr/doc Package: gsfonts-other Maintainer: Torsten Landschoff [EMAIL PROTECTED] 91485 Package gsfonts-other still has at least one file in /usr/doc Package: htget Maintainer: Troy Hanson [EMAIL PROTECTED] 91497 Package htget still has at least one file in /usr/doc Package: id-utils Maintainer: Brad Bosch [EMAIL PROTECTED] 91555 Package id-utils still has at least one file in /usr/doc Package: idled Maintainer: John Goerzen [EMAIL PROTECTED] 91513 Package idled still has at least one file in /usr/doc Package: infocom Maintainer: Charles Briscoe-Smith [EMAIL PROTECTED] 91515
Re: Bug#96224: libgmp3: Move documentation in the -dev package
Hi Christian Dale, On Sun, May 06, 2001 at 11:11:14PM +0200, Christian Marillat wrote: DS == Dale Scheetz [EMAIL PROTECTED] writes: [...] DS I can be convinced on either count. How would you feel about my presenting DS this issue to the developers at large, with you and I agreeing to follow DS the concensus of the group? Go ahead. I'd be happy to give an opinion. However, based on this one message and the bug report, I can't figure out what the contentious issue is. It is evident to me that the (programmer) docs and example code does not belong in the runtime libgmp3 package. Christian seems to be asking that they get moved to the -dev package, which seems logical enough to me. Dale seems to be arguing that a new -doc package should be created, and the docs moved there, instead. To me, that seems like overkill. But if the packager (Dale) is doing the work, who am I to argue? If Dale has agreed to do move the docs (either to -dev or to -doc), that seems to me to answer the bug report. I don't understand what question Christian's posting to -devel is supposed to raise. -S
Re: RaiserFS PPC status
On Mon, May 07, 2001 at 12:03:43AM +0200, Just a friendly Jedi Knight wrote: You mean XFS from Linus kernel tree? there are some patches on penguinppc.org This is not in Linus's kernel tree. Are you using SGI's 1.0 release? In any case, that should not affect the compilation of the tools much. Anyway i have trouble compiling mkfs.xfs I tried: gcc version 2.95.4 20010319 (Debian prerelease) gcc version 3.0 20010402 (Debian prerelease) and xfsprogs 1.2.4 Debian source package as well as source taken from penguinppc.org. I always get this: you should stick to gcc 2.95 for compiling the kernel, and probably the userspace tools, too. gcc -O1 -g -DNDEBUG -funsigned-char -Wall -I../include '-DVERSION=1.2.4' -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -o xfs_db -L../libxfs addr.o agf.o agfl.o agi.o attr.o attrshort.o bit.o block.o bmap.o bmapbt.o bmroot.o bnobt.o check.o cntbt.o command.o convert.o data.o dbread.o debug.o dir.o dir2.o dir2sf.o dirshort.o dquot.o echo.o faddr.o field.o flist.o fprint.o frag.o freesp.o hash.o help.o init.o inobt.o inode.o input.o io.o malloc.o mount.o output.o print.o quit.o sb.o uuid.o sig.o strvec.o type.o write.o main.o -lxfs /usr/lib/libuuid.a ../libxfs/libxfs.a(xfs_inode.o): In function `libxfs_xlate_dinode_core': /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: undefined reference to `__fswab64' /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: relocation truncated to fit: R_PPC_REL24 __fswab64 /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: undefined reference to `__fswab64' /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: relocation truncated to fit: R_PPC_REL24 __fswab64 /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:564: undefined reference to `__fswab64' /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:564: relocation truncated to fit: R_PPC_REL24 __fswab64 /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:564: undefined reference to `__fswab64' /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:564: relocation truncated to fit: R_PPC_REL24 __fswab64 ../libxfs/libxfs.a(xfs_mount.o): In function `libxfs_xlate_sb': /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_mount.c:205: undefined reference to `__fswab64' /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_mount.c:205: relocation truncated to fit: R_PPC_REL24 __fswab64 collect2: ld returned 1 exit status make[2]: *** [xfs_db] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/opt/src/robert/XFS/xfsprogs-1.2.4' make: *** [built] Error 2 grepping my xfsprogs tree, I get: ./include/libxfs.h:extern __inline__ __const__ __u64 __fswab64 (__u64 x); maybe your GCC isn't inlining the function? note that this declaration has /* ick */ on the line above it. But I think the relocation truncated to fit: R_PPC_REL24 __fswab64 messages are important. I'll leave it to someone more knowledgable about GCC and ELF to comment on that. These are the only errors I get... This must be some bug in gcc on powerpc as it compiles cleanly on i386 (and from looking on ftp.debian.org on other platforms also). I don't even have idea how to bite this... I'm only on x86 here, so all I can say is yeah :) -- - -/- - Rahul Jain - -\- - - -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- - - -/- I never could get the hang of Thursdays. - HHGTTG by DNA -\- - |--||--||-|--|-|-|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote: On Sun, 6 May 2001, Chris Waters wrote: Didn't we already have this discussion? The Standards-Version field is not a reliable indication of much of anything. I strongly object Policy says: Policy says doesn't make the packages comply. And you can file all the bugs reports you want, but that doesn't magically fix the packages. And until they're fixed, you can't use them as a reliable indicator of FHS compatibility. QED. We have many packages with old Standards-Versions which actually comply with newer standards and *are* FHS compatible, and we have packages with newer Standards-Versions that are NOT FHS compatible. I think that if you really want to focus on FHS compatibility, you're better off ignoring the Standards-Version issues for now. Its just another can of worms. Picking the minimum Standards-Version for release is something we normally do at freeze time. In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. You're misinterpreting this. It does not mean that every package must be reuploaded every time policy changes. Most recent should be checked at the time you create the source package, not rechecked daily. Note that the next paragraph mentions filing bug reports if the package becomes too much out of date. If any is too much, why bother to say too much? to removing packages because of what amount to cosmetic issues, and an Where did I say that I want to remove the packages??? I said that I want to send bug reports. RC bugs mean the package must be removed from the next release if it's not fixed. Unless you can guarantee that the bugs will be fixed (i.e., you're volunteering to fix them yourself), you _are_ asking for package to be removed when you file RC bugs. Anyway, I apologize for a reminder I'm sure you don't need. It's just a habit of mine, please forgive me. Bottom line, I think there remains a lot of work checking the subtle and not-so-obvious stuff in the FHS before we can confidently claim FHS compatibility (and even *begin* to work on actual compliance). The easy stuff, as your evidence shows, we're actually quite close on. It's the harder stuff, like /var/lib/games (which Kamion was going to investigate) and the random hard-to-identify files that need to move from /usr/lib to /usr/share that needs the most attention. So, anyway, that's a nice list of packages you made, and I think it's probably very useful -- all those packages should inspected -- I just don't think it's very useful for the purpose you intended. And I think mass filings of RC bugs would be premature at best. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 06:29:05PM -0400, Joey Hess wrote: Chris Waters wrote: - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. No, it is supposed to happen one release _after_ a release in which all the packages have made the transition. So sarge at the earliest, not woody. Right. Even better point. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
