Uploaded gnupg 1.0.5-1 (m68k) to non-us
-BEGIN PGP SIGNED MESSAGE-
Format: 1.6
Date: Mon, 30 Apr 2001 02:12:38 +0100
Source: gnupg
Binary: gnupg
Architecture: m68k
Version: 1.0.5-1
Distribution: unstable
Urgency: low
Maintainer: buildd m68k user account [EMAIL PROTECTED]
Description:
gnupg - GNU privacy guard - a free PGP replacement.
Closes: 95729
Changes:
gnupg (1.0.5-1) unstable; urgency=low
.
* New upstream version.
* debian/README.Debian: fix spelling and update URL.
* debian/rules (binary): remove the new info files.
* scripts/config.{guess,sub}: sync with subversions, closes: #95729.
Files:
9fbbc7b7bb221adf44654f3ebdf6b119 955048 non-US optional gnupg_1.0.5-1_m68k.deb
-BEGIN PGP SIGNATURE-
Version: 2.6.3i
Charset: noconv
iQCVAwUBOvP0im547I3m3eHJAQEZ1wP9FTTtXlSzLCIQFbIX/g2cTnweEdX8YXqW
e9WPjku5ujHMQRJ6OhRgOBfv8QovCZWjj8n6/rDCAuKHaWHBfX00g2OByRRIybLc
okgqEbJriNVNrO1106tSssjcQ746iOyGpLpj3XH7wvSQkfV60Mh6CdHJIH/xEPzm
JvlgfqfBBIk=
=iQI/
-END PGP SIGNATURE-
Uploaded gengameng 3.0-2 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 11:13:08 -0400 Source: gengameng Binary: libgengameng-dev libgengameng3 Architecture: sparc Version: 3.0-2 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Daniel Burrows [EMAIL PROTECTED] Description: libgengameng-dev - Development files for the Generic Game Engine Library libgengameng3 - The Generic Game Engine library. (libgengameng) Closes: 96322 Changes: gengameng (3.0-2) unstable; urgency=low . * Re-ran libtoolize (closes: #96322) Files: 9b32b5235b037e75e5c4e7beee5e5d1b 33196 libs optional libgengameng3_3.0-2_sparc.deb 82c7a982562e4c31708951ba3c03206f 9946 devel optional libgengameng-dev_3.0-2_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6815rfNc/ZB4E7C0RAsgzAKCQi4B1aa3k/Ly3t4OtxCt23I62TwCcD2eZ A5YJK5W0OZnNXRjoCp11SEA= =wg1L -END PGP SIGNATURE-
Uploaded xpilot 4.3.2-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 May 2001 09:44:39 -0300 Source: xpilot Binary: xpilot-client-nosound xpilot-server xpilot xpilot-client-nas xpilot-client-rplay Architecture: sparc Version: 4.3.2-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Ben Armstrong [EMAIL PROTECTED] Description: xpilot-client-nas - Client (with nas sound support) for XPilot xpilot-client-nosound - Client (without sound support) for XPilot xpilot-client-rplay - Client (with rplay sound support) for XPilot xpilot-server - Server for hosting XPilot games Changes: xpilot (4.3.2-1) unstable; urgency=low . * New upstream release. Files: 0eb8b69d4f679670fc1cfed16d9e60e4 324854 games optional xpilot-client-nosound_4.3.2-1_sparc.deb 740da16d233d1b488da12e982383feb1 328114 games optional xpilot-client-nas_4.3.2-1_sparc.deb 83cde4db817d134044e22729d16cae4b 325650 games optional xpilot-client-rplay_4.3.2-1_sparc.deb 2682bf11c23c733e224df33b504ca76f 376744 games optional xpilot-server_4.3.2-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6815+fNc/ZB4E7C0RAoEtAJwP/HM+nzMIE6L/exxa8/ksCdjf1wCdGkW5 x91CaFeDMK87ORoWdPDwaP4= =Uw1Y -END PGP SIGNATURE-
Uploaded everybuddy-cvs 20010504-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 14:19:36 + Source: everybuddy-cvs Binary: everybuddy-cvs Architecture: sparc Version: 20010504-1 Distribution: unstable Urgency: high Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Michael D. Ivey [EMAIL PROTECTED] Description: everybuddy-cvs - All in one Instant Messaging client, cvs snapshots Changes: everybuddy-cvs (20010504-1) unstable; urgency=high . * New upstream release Files: 80365a5554364cd2eb612b2ca6c69b37 385290 net optional everybuddy-cvs_20010504-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE68153fNc/ZB4E7C0RAoDkAJ4i4RmyQtTo828NoBi6D+rN97hdVwCfRB3O SKiWWF/Etm89n9yzB7esuCo= =xPsB -END PGP SIGNATURE-
Uploaded mc 4.5.51-17 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 3 May 2001 22:21:44 +0200 Source: mc Binary: mc mc-common gmc Architecture: sparc Version: 4.5.51-17 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Martin Bialasinski [EMAIL PROTECTED] Description: gmc- Midnight Commander - A powerful file manager. - Gnome version mc - Midnight Commander - A powerful file manager. - normal version mc-common - Common files for mc and gmc Closes: 95256 95273 95457 95714 Changes: mc (4.5.51-17) unstable; urgency=low . * Interim upload to recompile with latest libgnome. mc 4.5.52 needs some more work. Closes: #95256, #95273, #95714, #95457 * Fixed zh_TW.Big5.po, thanks to Jack Howarth Files: 1992004c063e0ae25aac07fb67a399bc 420672 utils optional mc_4.5.51-17_sparc.deb 9d3384b9af9033f1fe9804b9be1ba7f2 1124414 utils optional gmc_4.5.51-17_sparc.deb 07e2e1ac02aeccf06bb2723d7982b91d 1239178 utils optional mc-common_4.5.51-17_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6815xfNc/ZB4E7C0RAi2YAKDJNAbKCIDGXEuqXdhW0eX0dltQbACggFu6 IG6tGmrXYhR1XoOPDRK5C2Q= =znZa -END PGP SIGNATURE-
Uploaded gtklp 0.6g-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 21 April 2001 10:52:41 +0100 Source: gtklp Binary: gtklp Architecture: sparc Version: 0.6g-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Matthias Kabel [EMAIL PROTECTED] Description: gtklp - Frontend for cups written in gtk Changes: gtklp (0.6g-1) unstable; urgency=low . * new upstream version Files: 0f8016bd1421e1035e53152eebc52246 65400 x11 optional gtklp_0.6g-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE68152fNc/ZB4E7C0RAg34AKC5lVGvVuV+cKGAK7qM2CEX2it0jwCgoT1H xkpqRSLGLP/dYgF83Lgn7Rk= =Lnwj -END PGP SIGNATURE-
Uploaded chemtool 1.3.1-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 17:30:13 +0200 Source: chemtool Binary: chemtool Architecture: sparc Version: 1.3.1-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Dr. Guenter Bechly [EMAIL PROTECTED] Description: chemtool - X11/GTK-based chemical formula drawing program Changes: chemtool (1.3.1-1) unstable; urgency=low . * New upstream release. * Updated package to latest standards version. Files: a6b34f5ce1f7e2a9209d14d2aafc6681 104830 science optional chemtool_1.3.1-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6816DfNc/ZB4E7C0RAkrjAKDETvot5e15LjaMGlcAAhQc9RtZAgCfYhL8 g/var4DZ+2XPpF+1lJihTVk= =aYPP -END PGP SIGNATURE-
Uploaded ripperx 2.0-4 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 3 May 2001 23:24:18 -0700 Source: ripperx Binary: ripperx Architecture: sparc Version: 2.0-4 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: tony mancill [EMAIL PROTECTED] Description: ripperx- a GTK-based ripper/encoder Closes: 96002 Changes: ripperx (2.0-4) unstable; urgency=low . * patched filename handling when ripping multiple files * patched gogo plugin to handle garbage in output - Closes: #96002 Files: 752a49330a0d085b63cf02d7f486cdaf 117300 misc optional ripperx_2.0-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6815/fNc/ZB4E7C0RAqSXAJ91GbYwNMfMZ081Fv6oQmN+Ec/AdgCglTwl P8ThSxNEYlhIrrONr5csOwU= =m1va -END PGP SIGNATURE-
Uploaded netstring 0.9.3-2 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 Apr 2001 16:45:38 +0200 Source: netstring Binary: ocaml-netstring Architecture: sparc Version: 0.9.3-2 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Stefano Zacchiroli [EMAIL PROTECTED] Description: ocaml-netstring - OCaml library for internet related string handling Closes: 96252 Changes: netstring (0.9.3-2) unstable; urgency=low . * Native code compilation now is optional (closes: Bug#96252) Files: cb16b976542b2efb7d102af89b84985f 265760 devel optional ocaml-netstring_0.9.3-2_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6815sfNc/ZB4E7C0RAqtJAJ96S7UFaZ+T5tGtZUFEG1OJmBcfIQCfc0Ip Ld5gHGnYVPfO4XsSla0bFJA= =d51I -END PGP SIGNATURE-
Uploaded ash 0.3.8-5 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 20:54:31 +1000 Source: ash Binary: ash-udeb ash ash-medium Architecture: sparc Version: 0.3.8-5 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Herbert Xu [EMAIL PROTECTED] Description: ash- NetBSD /bin/sh ash-medium - NetBSD /bin/sh with HETIO ash-udeb - NetBSD /bin/sh for boot floppies (udeb) Closes: 95433 96203 Changes: ash (0.3.8-5) unstable; urgency=low . * Added German translation to template file (Sebastian Feltel, closes: #96203). * Added missing initialisation in setalias() (closes: #95433). Files: 295e8bf7a8012e76378827cbbd6964db 80486 shells optional ash_0.3.8-5_sparc.deb f2e944ffde9e46d114ff71e42b867e2a 81502 shells extra ash-medium_0.3.8-5_sparc.deb 75ec35b563a4e28bc2bb3916e5b5c073 53164 debian-installer standard ash-udeb_0.3.8-5_sparc.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6815tfNc/ZB4E7C0RAnfIAJ9qR4eNY1aUPipl7B2wC4HP+93cTwCgk3x4 46UNFpB8sbaoAI9+KDdvyig= =+bbD -END PGP SIGNATURE-
Uploaded ftnchek 3.0.4-2 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 09:32:38 +0100 Source: ftnchek Binary: ftnchek Architecture: sparc Version: 3.0.4-2 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Mark Brown [EMAIL PROTECTED] Description: ftnchek- A semantic checker for Fortran 77 programs. Closes: 96215 Changes: ftnchek (3.0.4-2) unstable; urgency=low . * Install Emacs Lisp package (closes: #96215). Files: d68c1e3d1f0b171eae35855548d84442 193588 devel extra ftnchek_3.0.4-2_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6816GfNc/ZB4E7C0RAuhSAKC/GkQ1cCvLXJXQbalgOtWp+soQYwCffDnz phfHjy9XtQsfLVoftiI845U= =6DO7 -END PGP SIGNATURE-
Uploaded msyslog 1.01-18 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 14:25:09 +0200 Source: msyslog Binary: msyslog-om-pgsql msyslog-om-mysql msyslog Architecture: sparc Version: 1:1.01-18 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Arthur Korn [EMAIL PROTECTED] Description: msyslog- Modular system logging daemon msyslog-om-mysql - MySQL output module for msyslog msyslog-om-pgsql - PostgreSQL output module for msyslog Changes: msyslog (1:1.01-18) unstable; urgency=low . * Now mentioning Core-SDI and ALAT in the description with theyer permission to make it more obvious why modules will be installed under /usr/lib/alat/ starting with the next release. * Overhauled read-syslog to support all the new features of the next msyslog release: - Now understands ! and = in severities. This required to finally change the completely braindead semantics I used for severites, eg if read-syslog says 'auth.info file /var/log/auth.log' this does no more mean that auth.err is logged there as well. I did not have to change any of my scripts that use read-syslog, and hope that most others won't be affected by it as well. - accepts | before files. - added \s\/dev\/ to $rotate_taboo. Files: 976a76fe481c59d0fb3bebb23acdaf6b 93674 admin extra msyslog_1.01-18_sparc.deb 91b903e0fe5fdff9e9718e0290655f10 14026 admin extra msyslog-om-mysql_1.01-18_sparc.deb bf794b1ca9e34cf57942ce3427eb079a 14428 admin extra msyslog-om-pgsql_1.01-18_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6816HfNc/ZB4E7C0RAvzJAKCMIZXSyF8ivJoPTXplNjYoPEFGWACfaFEw aXpNH21gBCj+NA25DXj3ux4= =WDa+ -END PGP SIGNATURE-
Uploaded sendmail 8.11.3+8.12.0.Beta7-7 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 May 2001 14:00:00 -0500 Source: sendmail Binary: sendmail libmilter-dev sendmail-doc Architecture: sparc Version: 8.11.3+8.12.0.Beta7-7 Distribution: unstable Urgency: high Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Richard A Nelson (Rick) [EMAIL PROTECTED] Description: libmilter-dev - The sendmail Mail Filter API (Milter). sendmail - A powerful mail transport agent. sendmail-doc - A powerful mail transport agent. Changes: sendmail (8.11.3+8.12.0.Beta7-7) unstable; urgency=high . * Another upstream queue update * Upstream milter patch * More QUEUE/MSP parm cleanup in /etc/init.d/sendmail * Generate control/changelog dynamically (to handle multiple versions) now, need to update the rules file to support it (suggestions?). * Drop duplicate dontblamesendmail definition in submit.mc * Support MSP in daemon *or* cronjob mode * WOW... Look at the nice, new, small /etc/init.d/sendmail !!! but, please, don't look at the sourced pig ;-) Files: c17f85eba4c34f000a2cad480d41a577 1346818 mail extra sendmail_8.11.3+8.12.0.Beta7-7_sparc.deb b92736e50be1613255cd1fdf12e1fbde 533814 mail extra sendmail-doc_8.11.3+8.12.0.Beta7-7_sparc.deb 29b269335768b285f789ae182552244d 249404 devel extra libmilter-dev_8.11.3+8.12.0.Beta7-7_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6816IfNc/ZB4E7C0RApMEAJ4sI3nrk+gV/5qOdzihhltBOYc+rgCbBuef sfttJex/HzCG6/RfTJXyBl0= =RFhO -END PGP SIGNATURE-
Uploaded gentoo 0.11.16-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 3 May 2001 22:39:58 +0200 Source: gentoo Binary: gentoo Architecture: sparc Version: 0.11.16-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Josip Rodin [EMAIL PROTECTED] Description: gentoo - A fully GUI configurable X file manager using GTK+ Changes: gentoo (0.11.16-1) unstable; urgency=low . * New upstream version. * Updated for Policy 3.5.?. Files: e51a26b09698d219badb7a3cc8da7923 543008 x11 optional gentoo_0.11.16-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE68150fNc/ZB4E7C0RAu8iAJwKCHU5MovZSK4Z9LkiLyn9Y+ul/QCfVhSj sCuhV2rRPLXWlmZbPc9oZqY= =Jh39 -END PGP SIGNATURE-
Uploaded aterm 0.4.0-5 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 3 May 2001 15:49:20 +0200 Source: aterm Binary: aterm aterm-ml Architecture: sparc Version: 0.4.0-5 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Jordi Mallach [EMAIL PROTECTED] Description: aterm - Afterstep XVT - a VT102 emulator for the X window system aterm-ml - Afterstep XVT - a VT102 emulator for the X window system Changes: aterm (0.4.0-5) unstable; urgency=low . * debian/rules: DH_COMPAT=3, removed dh_testversion calls. * debian/control: + Standards-Version: 3.5.4.0 (no changes) + removed libtools from Build-Depends, upped the debhelper version * src/commands.c: fixed Home and End translations, they should work properly now. Thanks to Edward Bloch for the hint which helped solving this. Files: e17081ad3460a97c68d490282d2fb61a 103458 x11 optional aterm_0.4.0-5_sparc.deb 6f991ddfe2c6d4b5f5bf301931496410 272756 x11 optional aterm-ml_0.4.0-5_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6815zfNc/ZB4E7C0RAhq2AJ4jXFAHkdAmFhdb69p5cxhGC+NyHACfRXUT s33MnNfibtWFXNcCmOlbvu8= =ykXP -END PGP SIGNATURE-
Uploaded gnomekiss 0.6-4 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 17:58:17 +0200 Source: gnomekiss Binary: gnomekiss Architecture: sparc Version: 0.6-4 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Dr. Guenter Bechly [EMAIL PROTECTED] Description: gnomekiss - A KiSS paper doll viewer for GNOME Closes: 96135 Changes: gnomekiss (0.6-4) unstable; urgency=low . * Added lha as suggested package, because without it one cannot open the common lzh paperdoll files; closes: #96135 * Updated package to latest standards version. Files: 0a4946fb3888703ec4dcbc693a0d3efd 39726 games optional gnomekiss_0.6-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE68158fNc/ZB4E7C0RAiy6AJoD4l+8xDrTm6M9uUTp85/23SF1TACfVVmt cDIoU53/D6IlIqnCLBupj7o= =0PG8 -END PGP SIGNATURE-
Uploaded achilles 0.0.5-8 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 14:09:44 -0500 Source: achilles Binary: achilles Architecture: sparc Version: 0.0.5-8 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Matthew Danish [EMAIL PROTECTED] Description: achilles - An artificial life and evolution simulator Changes: achilles (0.0.5-8) unstable; urgency=low . * Updated Standards-Version * Now Build-Depends on libsdl1.2 instead of 1.1 Files: ce5ac7b94bce66de5bec47df37054c52 32552 science optional achilles_0.0.5-8_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6816CfNc/ZB4E7C0RAurzAKCjgsbAgk1Arhp5XW4jJhMChaY4uwCggbR8 3f0aGSczyZUB9pz6yV3jXSQ= =r9Zt -END PGP SIGNATURE-
Uploaded sysutils 1.3.8.5 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 03 May 2001 15:41:07 -0600 Source: sysutils Binary: sysutils Architecture: sparc Version: 1.3.8.5 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Lonnie Sauter [EMAIL PROTECTED] Description: sysutils - Miscellaneous small system utilities. Closes: 96211 Changes: sysutils (1.3.8.5) unstable; urgency=low . * Fixed missing /usr/doc symlink (closes: bug#96211) Files: 1e58bd7354bb6a43b98bfbc95ef9a6e2 50992 - optional sysutils_1.3.8.5_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6815yfNc/ZB4E7C0RAng1AKCFj5xa8DeUwiwPo3g5LB280YsSlQCeJYwP ZtXSxIGcx1ljr1FIYqTmS1Y= =EfnE -END PGP SIGNATURE-
Uploaded tcpspy 1.5-2 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 03:40:29 + Source: tcpspy Binary: tcpspy Architecture: sparc Version: 1.5-2 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Pablo Lorenzzoni [EMAIL PROTECTED] Description: tcpspy - Incoming and Outgoing TCP/IP connections logger. Closes: 96213 Changes: tcpspy (1.5-2) unstable; urgency=low . * Added groff, bison, flex to Build-Depends. (Closes: #96213) Files: 966879e3f6365ca9c00f9df97c4ad67e 35046 net optional tcpspy_1.5-2_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD4DBQE6816LfNc/ZB4E7C0RAggnAKC+U7KY4kWF9Gyo/adDK608piWfsQCYwoAB F+UskBOUfSld69JH1y/5WQ== =tB+S -END PGP SIGNATURE-
Uploaded tkrat 2.0.1-4.2 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 08:06:11 +0200 Source: tkrat Binary: tkrat Architecture: sparc Version: 1:2.0.1-4.2 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Mattia Monga [EMAIL PROTECTED] Description: tkrat - Tk based MUA Closes: 94707 96248 Changes: tkrat (1:2.0.1-4.2) unstable; urgency=low . * Deleted /usr/X11R6/bin from debian/dirs (closes: #96248) * My color patch closes a 'whishlist' bug submitted by me! (closes: #94707) Files: 46e68c6e8d44f5b79f12d70c00efd056 857558 mail optional tkrat_2.0.1-4.2_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE68155fNc/ZB4E7C0RAn4RAJ4yt4sbK5/57qpqlcP5IoNHDbALhwCgxGza fEw5B9D/qOOd89uU4YsrIOs= =8eiH -END PGP SIGNATURE-
Uploaded mserv 0.33-2 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Mar 2001 13:38:44 -0800 Source: mserv Binary: mserv-dev mserv Architecture: sparc Version: 0.33-2 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: David Whedon [EMAIL PROTECTED] Description: mserv - local centralised multiuser music server mserv-dev - local centralised multiuser music environment Closes: 81754 Changes: mserv (0.33-2) unstable; urgency=low . * fix time problem, thanks to Oren Laskin [EMAIL PROTECTED] * should modify /etc/mserv/config rather than writing a symlink to control mp3 archive location. * use logrotate so mserv.log doesn't grow without bound. * Initial upload (closes: #81754) Files: 1e35ac4c93afbc1beaeac7dda6f85f3d 122654 sound optional mserv_0.33-2_sparc.deb ca6d2e153f70fbe65aff73a5f884ab50 6008 sound optional mserv-dev_0.33-2_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6816MfNc/ZB4E7C0RAr+IAJ4/tUYPtNxuNg85AnpKLWBiK7WvqACfSX0c xecvSRp+RtFzPMwdw+w6+z8= =qBbH -END PGP SIGNATURE-
Uploaded main-menu 0.008 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 3 May 2001 21:12:57 -0400 Source: main-menu Binary: main-menu Architecture: sparc Version: 0.008 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Joey Hess [EMAIL PROTECTED] Description: main-menu - Debian installer main menu (udeb) Closes: 95315 Changes: main-menu (0.008) unstable; urgency=low . * Patch from Romain BEAUGRAND [EMAIL PROTECTED] to order() to fix the case of a package with no deps, which is added to the head of the list. Closes: #95315 Files: 64fdf55599493258023ac0eb4f5d113c 4658 debian-installer standard main-menu_0.008_sparc.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6816KfNc/ZB4E7C0RAuhgAKDExYwZuonb67FZzIPr4fszVZfoFQCeLB2v PQa48Wzmdz/eyYOY8/tkyJo= =x+VG -END PGP SIGNATURE-
Uploaded sox 12.17.1-3 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 4 May 2001 15:26:33 +0200 Source: sox Binary: sox Architecture: sparc Version: 12.17.1-3 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Guenter Geiger [EMAIL PROTECTED] Description: sox- A universal sound sample translator. Closes: 96192 Changes: sox (12.17.1-3) unstable; urgency=low . * fixed aiff handling, play manpage update (closes: #96192) Files: e8fddc2664fa7ed565924d0064250ae3 238542 sound optional sox_12.17.1-3_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE6816AfNc/ZB4E7C0RAlAjAJ97k9zaBqbhOPXohVVotIwwXtycHwCgw8Fv rxmkHFvA7QlLNBEDXEwwhmI= =vOtO -END PGP SIGNATURE-
Re: ALL: PARANOID from /etc/hosts.deny Should be Commented by default
* Joey Hess [EMAIL PROTECTED] [010425 11:12]: This is actually quite doable, you just need to have a clued isp[1] who sets up a nifty little forwarding trick in the reverse DNS. Here's an exmple of how my old ISP did it: net152 ns kitenet.net. 153 cname 153.net152.200.144.198.in-addr.arpa. The other nifty thing for ip blocks is this: apt.db $GENERATE 32-120 dhcp-address-$ A 192.168.4.$ -- 192.168.4.db-- $GENERATE 32-120 $ PTR dhcp-address-$.apt.private. - bind 8 will go off and expand those into addresses and I didn't even have to type them all! :) -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED] So little time, so little to do.-- Oscar Levant pgpa3pPKpRlDv.pgp Description: PGP signature
build depends on kernel-headers
In short, how do you do them? AFAICT, I could conceivably add either Build-Depends: kernel-headers or Build-Depends: kernel-headers-2.2.19 If I did the former, there doesn't seem to be any way to reliably get at the kernel headers. The only way I can see is to hardcode -I/usr/src/kernel-headers-2.2.19/include in the appropriate makefiles, which is obviously not any good. The latter'll obviously break as soon as 2.2.20 comes out and 2.2.19 gets removed from the archive. Also, doesn't there really need to be some way of saying I need the 2.2 kernel headers for programs that really do? Help! :) 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) pgpvPoVB3RQiA.pgp Description: PGP signature
Re: build depends on kernel-headers
Anthony Towns aj@azure.humbug.org.au wrote:
The latter'll obviously break as soon as 2.2.20 comes out and 2.2.19 gets
removed from the archive.
If you're building modules, then they'll have to be rebuilt when 2.2.20
comes out anyway. If this is a user-space program, then it better stop
using kernel headers all together or it will become useless with 2.4.
--
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
In short, how do you do them? What do you want to do with them? There are a whole load of wacky special source dependencies (*LINUX24-HEADERS and so on) which seem to be trying to solve variants of this problem. But this mechanism doesn't seem to be all that robust either. I think the whole idea of putting the kernel version number in the name of the headers package is pretty bogus. It would probably be better to just have a kernel-headers package which installed itself in /usr/src/kernel-headers; then you could declare dependencies on kernel-headers (= 2.2.19) or whatever. p.
Re: build depends on kernel-headers
Philip Blundell [EMAIL PROTECTED] wrote:
I think the whole idea of putting the kernel version number in the name of
the
headers package is pretty bogus. It would probably be better to just have a
kernel-headers package which installed itself in /usr/src/kernel-headers;
then you could declare dependencies on kernel-headers (= 2.2.19) or
whatever.
Having version numbers in the kernel-headers package name is a consequence
of having them in the kernel-image package name. The point of having them
in the kernel-image package name should be pretty obvious...
--
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: Many ports open by default
Tom Lear [EMAIL PROTECTED] wrote: Sure, don't run the daemon at all. When you install exim, rm /etc/init.d/rc?.d/S*exim and it won't start. Local processes will be BTW, I think this is what ssh should do if you choose not to run the daemon on startup (rather than making /etc/init.d/ssh not work at all). I have ssh installed on my laptop, and I don't want it running by default, but I'd like to be able to start and stop it with the /etc/init.d script. Anyone else agree with this (should I file a bug)? Hello! I do. It could use update-rc.d ssh stop 20 0 1 2 3 4 5 6 . instead of update-rc.d ssh defaults, if I chose not to run the ssh-Daemon. cu andreas -- Uptime: 10 seconds load average: 0.00, 0.00, 0.00 vim:ls=2:stl=***\ Sing\ a\ song.\ ***
Re: build depends on kernel-headers
Having version numbers in the kernel-headers package name is a consequence of having them in the kernel-image package name. The point of having them in the kernel-image package name should be pretty obvious... Actually, I'm not even completely convinced that having them in the kernel-image package name is particularly beneficial. But, even if we leave that the way it is, I don't think it's impossible to arrange for kernel-headers to be named differently. p.
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 06:23:39PM +1000, Anthony Towns wrote: In short, how do you do them? AFAICT, I could conceivably add either Build-Depends: kernel-headers or Build-Depends: kernel-headers-2.2.19 or Build-Depends: kernel-headers-2.2 or Build-Depends: kernel-headers-2.4 You'll notice that recent kernel-headers packages provide the major.minor if the kernel version. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Netscape v.s. C source code
* Steve M. Robbins | I tried Netscape, Mozilla, Galeon (mozilla-based), Browse X, and | lynx. None of them would display text/x-csrc. The first three tried | to save it to disk, BrowseX showed a blank page, and lynx completely | ignored my attempt to open the link. lynx opened it just fine here, and so did Opera (after asking because it was an unknown MIME-type). -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 06:07:54AM -0400, Ben Collins wrote: On Sat, May 05, 2001 at 06:23:39PM +1000, Anthony Towns wrote: In short, how do you do them? AFAICT, I could conceivably add either Build-Depends: kernel-headers-2.2 or Build-Depends: kernel-headers-2.4 You'll notice that recent kernel-headers packages provide the major.minor if the kernel version. Only kernel-headers-2.2.19-sparc (in i386/unstable) does this. Is that usable on i386? (If not, should it be arch: sparc, instead of arch: all?) In any event, how do I work out what directory to tell gcc to use? 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) pgpjor5ZTibeb.pgp Description: PGP signature
Re: Bug#96102: ITP: serpento -- dictd server written in python
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 -- --- | 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!
ITP: smartcard -- A smartcard utility for Linux
Package: wnpp Severity: wishlist `smartcard' allows you to control a smart card reader from the command line. Currently, it supports just a few basic commands which only work on plain I2C memory cards. URL: http://www.lionking.org/~kianga/software/smartcard/ Copyright: Copyright (C) 2000 Rene Puls [EMAIL PROTECTED] You are free to distribute this software under the terms of the GNU General Public License.
Packages to run kernel 2.4.x on potato (release 12)
I have prepared the packages needed to run kernels up to 2.4.4 on a Debian 2.2r3 (potato) system. Please read [1] for more information. Changes since the last release: + added: isdnutils Binary packages: o ipppd o isdnactivecards o isdneurofile o isdnlog-data o isdnlog o isdnutils-doc o isdnutils-xtools o isdnutils o isdnvbox o isdnvboxclient o isdnvboxserver o libcapi20 o pppdcapiplugin + added: kernel-image-2.4.4-i386 Binary packages: o kernel-headers-2.4.4 o kernel-headers-2.4.4-386 o kernel-headers-2.4.4-586 o kernel-headers-2.4.4-586tsc o kernel-headers-2.4.4-686 o kernel-headers-2.4.4-686-smp o kernel-headers-2.4.4-k6 o kernel-headers-2.4.4-k7 o kernel-image-2.4.4-386 o kernel-image-2.4.4-586 o kernel-image-2.4.4-586tsc o kernel-image-2.4.4-686 o kernel-image-2.4.4-686-smp o kernel-image-2.4.4-k6 o kernel-image-2.4.4-k7 + added: kernel-source-2.4.4 Binary packages: o kernel-doc-2.4.4 o kernel-source-2.4.4 o mkcramfs + patched util-linux with the international kernel patch + removed: kernel-image-2.4.3-i386 + removed: kernel-source-2.4.3 cu Adrian [1] http://www.fs.tum.de/~bunk/kernel-24.html -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Many ports open by default
On Fri, May 04, 2001 at 07:12:07PM -0700, Tom Lear wrote: BTW, I think this is what ssh should do if you choose not to run the daemon on startup (rather than making /etc/init.d/ssh not work at all). I have ssh installed on my laptop, and I don't want it running by default, but I'd like to be able to start and stop it with the /etc/init.d script. Anyone else agree with this (should I file a bug)? File a wishlist bug - it is a wish, isn't it? ;) cu Torsten pgpmRDg4OGeON.pgp Description: PGP signature
Re: Chrony mailing list needs a home
On Fri, May 04, 2001 at 09:48:54PM -0500, John Hasler wrote: Well I guess you could use sourceforge. I assume that the author has his reasons for not wanting to use Sourceforge. There are (were?) mailing lists for other projects on lists.debian.org...? -- Digital Electronic Being Intended for Assassination and Nullification
Re: rfc1149
Previously Christoph Simon wrote: The german expression has a somewhat special history. Germanic at least, possible even older (considering Dutch has the exact some meaning). Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: rfc1149
Previously Hamish Moffatt wrote: There's a lot more interesting ones than that. Last year, an RFC described transmission of electricity over IP. Probably because noone implemented RFC2549 yet: IP over Avian Carriers with Quality of Service. Unfortunately there still is ongoing litigation about which is the prior art: carrier or egg so large scale implementations are being put on hold for now. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Work-needing packages report for May 4, 2001
Carlos Laviola schrieb: I hope that's a joke, because, based _solely_ on that comparison table, the reason one should use snarf over wget is because it has a cool progressbar. snarf is also a lot smaller than wget. (According to the chart) ciao, 2ri -- They are really completely different things, so don't mix them up, but they have a close relation to each other. -- http://hurddocs.org/whatis/translator.html
Re: rfc1149
* Wichert Akkerman | Previously Hamish Moffatt wrote: | There's a lot more interesting ones than that. Last year, an RFC | described transmission of electricity over IP. | | Probably because noone implemented RFC2549 yet: IP over Avian Carriers | with Quality of Service. Unfortunately there still is ongoing litigation | about which is the prior art: carrier or egg so large scale | implementations are being put on hold for now. Also, considering that the top quality is Concorde, and the Concordes are having a hard time for the time being, I don't think anybody is going to implement it for some time. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 10:27:53AM +0100, Philip Blundell wrote:
Actually, I'm not even completely convinced that having them in the
kernel-image package name is particularly beneficial. But, even if we leave
that the way it is, I don't think it's impossible to arrange for
kernel-headers
to be named differently.
Kernel-image packages need to have version numbers encoded in them so that
upgrades can happen smoothly. Kernel-headers need the version numbers as
you may have multiple kernel-images packages in the archive.
The thing is, kernel-headers should not be used at all unless you're
compile glibc, or modules. Anything else will break.
--
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
Anthony Towns aj@azure.humbug.org.au wrote:
On Sat, May 05, 2001 at 06:07:54AM -0400, Ben Collins wrote:
AFAICT, I could conceivably add either
Build-Depends: kernel-headers-2.2
or
Build-Depends: kernel-headers-2.4
You'll notice that recent kernel-headers packages provide the
major.minor if the kernel version.
Only kernel-headers-2.2.19-sparc (in i386/unstable) does this. Is that
kernel-headers-2.4.* does this on i386 as well. I'll add it for the next
kernel-headers-2.2 release on alpha/i386.
--
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: Debconf and substitution in long description
On Thu, 3 May 2001, Joey Hess wrote:
[Substitution in long description]
I see nothing wrong with this, it should work.
Hrm, I just tested with a description of:
Description: ${hostname}
${hostname} long
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.
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: build depends on kernel-headers
On Sat, May 05, 2001 at 09:44:07PM +1000, Herbert Xu wrote: On Sat, May 05, 2001 at 10:27:53AM +0100, Philip Blundell wrote: Actually, I'm not even completely convinced that having them in the kernel-image package name is particularly beneficial. But, even if we leave that the way it is, I don't think it's impossible to arrange for kernel-headers to be named differently. Kernel-image packages need to have version numbers encoded in them so that upgrades can happen smoothly. Kernel-headers need the version numbers as you may have multiple kernel-images packages in the archive. The thing is, kernel-headers should not be used at all unless you're compile glibc, or modules. Anything else will break. False. That is the very thing I want to alleviate (people using kernel headers from the libc6-dev package). People should not be using them, but if they do, they should use a kernel-headers package, and not rely on the headers in libc6-dev which are different on all archs, and change almost every new glibc build. You are never guaranteed to get the prefered kernel headers for your program (be it a scsi level thing like cdrecord, or mount tools like util-linux). The point here is to make packages start moving to Build-Dep'ing on kernel-headers-* packages. The question is, how to allow them to do that easily. IMO, we can use alternatives. And it should be fairly easy update-alternatives --install /usr/src/kernel-headers-2.2 kernel-headers-2.2 \ /usr/src/kernel-headers-2.2.rev rev Where rev would be something like 19 (as in 2.2.19). This way each newer version would be prefered over the former. The only problem I see are the -preX releases. Someone would have to suggest how to handle that case since the priority field wont accept letters. Also, I think that packages should Build-Depends on kernel-headers-X.X. IMO, There is no reason to build-dep on anything more specific, and also no reason to build-dep on just kernel-headers (IOW, maintainers should test which kernel headers can be used). This way they can always just do: CFLAGS += -I/usr/src/kernel-headers-2.2/include And not have to worry about all the revisions, or detecting anything special. Xu, can this alternative system be added to the kernel-headers package scripts? Does anyone see a problem with this solution (that isn't already a problem with the current usage of kernel headers in libc6-dev that is)? Anyone got a solution for the -preX case, which would probably make this method rock solid? Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Debconf and substitution in long description
Simon Richter wrote:
Hrm, I just tested with a description of:
Description: ${hostname}
${hostname} long
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.
--
see shy jo
Re: Chrony mailing list needs a home
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 was thinking just use it for the list, and ignore the other stuff. -- see shy jo
Software of BeOpen is resurrected at SourceForge
Some time ago I told, that a company called BeOpen is no more. Well, I just found, that their software is available at SourceForge: http://sourceforge.net/projects/infodock/ http://sourceforge.net/projects/hyperbole/ http://sourceforge.net/projects/oo-browser/ -- Juhapekka naula Tolvanen * * U of Jyväskylä * * * [EMAIL PROTECTED] http://www.st.jyu.fi/~juhtolv/spam.html * * * STRAIGHT BUT NOT NARROW - slave screams. he's gonna cause this system to fall. slave screams. but he'll be glad to be chained to that wall.nine inch nails
Re: Bug#95975: mutt: doesn't use charset anymore
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. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯
Re: Bug#95975: mutt: doesn't use charset anymore
Richard == Richard Atterer [EMAIL PROTECTED] writes: Richard While we're at it: How on earth can I get rid of those Richard Warning: locale not supported by Xlib, locale set to C Richard messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts Richard etc in mutt. Unfortunately, this produces the above error Richard message with lots of X programs - especially annoying Richard when you use at(1); you always get a mail with the error Richard message. 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.) The mutt docs are not very compatible with Xlib. Ben -- Brought to you by the letters C and H and the number 1. A squib is a firecracker. Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 11:20:21PM +0200, Richard Atterer wrote: [...] messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts etc in mutt. Try LC_CTYPE=de_DE instead. -- CU, Patrick. Never run on auto-pilot - The Pragmatic Programmer pgpzbiy9d7Pvs.pgp Description: PGP signature
how to implement a renamed package
Hello, I am maintaing the Debian package puzzle and have a problem with the new upstream version. The package and program has been renamed by upstream to tree-puzzle, because there was a conflict with another program named puzzle. I was considering to make a new package tree-puzzle which conflicts and replaces puzzle, but this way the users of puzzle would not get the automatical upgrade of this new upstream version with 'apt-get upgrade'. Thus, how can I automatically replace the package puzzle with the new package tree-puzzle? Greetings, Guenter -- Linux: Who needs GATES in a world without fences?
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 11:09:20AM -0400, Ben Collins wrote: The point here is to make packages start moving to Build-Dep'ing on kernel-headers-* packages. The question is, how to allow them to do that easily. IMO, we can use alternatives. And it should be fairly easy update-alternatives --install /usr/src/kernel-headers-2.2 kernel-headers-2.2 \ /usr/src/kernel-headers-2.2.rev rev Where rev would be something like 19 (as in 2.2.19). This way each newer version would be prefered over the former. The only problem I see are the -preX releases. Someone would have to suggest how to handle that case since the priority field wont accept letters. How about: use 100*rev as the priority for standard kernel releases, and 100*rev+X for a -preX release and hope that there are never more than 99 pre-releases ;-) -S
Re: how to implement a renamed package
Sat, May 05, 2001 at 08:43:30PM +0200 wrote: Hello, I am maintaing the Debian package puzzle and have a problem with the new upstream version. The package and program has been renamed by upstream to tree-puzzle, because there was a conflict with another program named puzzle. I was considering to make a new package tree-puzzle which conflicts and replaces puzzle, but this way the users of puzzle would not get the automatical upgrade of this new upstream version with 'apt-get upgrade'. Thus, how can I automatically replace the package puzzle with the new package tree-puzzle? This is discussed in the Developer's Reference [1]: 9.3 Replacing or renaming packages Sometimes you made a mistake naming the package and you need to rename it. In this case, you need to follow a two-step process. First, set your debian/control file to replace and conflict with the obsolete name of the package (see the Debian Policy Manual for details). Once you've uploaded that package, and the package has moved into the archive, file a bug against ftp.debian.org asking to remove the package with the obsolete name. [1] : http://www.debian.org/doc/developers-reference/ch-archive-manip.en.html#s9.3 Greetings, Guenter -- Linux: Who needs GATES in a world without fences? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: build depends on kernel-headers
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. Ben People should not be using them, but if they do, they should use Ben a kernel-headers package, and not rely on the headers in Ben libc6-dev which are different on all archs, and change almost Ben every new glibc build. You are never guaranteed to get the Ben prefered kernel headers for your program (be it a scsi level Ben thing like cdrecord, or mount tools like util-linux). 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). Ben The point here is to make packages start moving to Build-Dep'ing on Ben kernel-headers-* packages. The question is, how to allow them to do that Ben easily. Ben IMO, we can use alternatives. And it should be fairly easy And hard code paths, unfortunately. Ben CFLAGS += -I/usr/src/kernel-headers-2.2/include Ben And not have to worry about all the revisions, or detecting anything Ben special. How do I build two packages that have different kernel header requirements? Ben Xu, can this alternative system be added to the kernel-headers package Ben scripts? Does anyone see a problem with this solution (that isn't Ben already a problem with the current usage of kernel headers in libc6-dev Ben that is)? Anyone got a solution for the -preX case, which would probably Ben make this method rock solid? Yes, I do. I think a less complex solution, that does not necesitate people installing debian kernel headers packages if they already have their own sources, or to have to build the package as root Try this: suggest the kernel-headers package, and set CFLAGS += -I$(KSRC)/include and instruct people to set the KSRC variable as needed. a) I do not want to hardcode /usr/src b) I do not want to hard code official debian header packages c) I do want to be able to build modules that require different kernel headers on the same box (I have one box where I do all my kernel builds) d) I do not want the kludge that is implied in the update alternatives. Have a default value for KSRC if you need, and arrange for the buildd's to create the /default-ksrc/../kernel-headers-X.X. manoj -- Q: What do you call 15 blondes in a circle? A: A dope ring. Q: Why do blondes put their hair in ponytails? A: To cover up the valve stem. 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
Je Sat, 5 May 2001 11:09:20 -0400, Ben Collins [EMAIL PROTECTED] scribis: IMO, we can use alternatives. And it should be fairly easy update-alternatives --install /usr/src/kernel-headers-2.2 kernel-headers-2.2 \ /usr/src/kernel-headers-2.2.rev rev Where rev would be something like 19 (as in 2.2.19). This way each newer version would be prefered over the former. The only problem I see are the -preX releases. Someone would have to suggest how to handle that case since the priority field wont accept letters. Also, I think that packages should Build-Depends on kernel-headers-X.X. IMO, There is no reason to build-dep on anything more specific, and also no reason to build-dep on just kernel-headers (IOW, maintainers should test which kernel headers can be used). This way they can always just do: CFLAGS += -I/usr/src/kernel-headers-2.2/include And not have to worry about all the revisions, or detecting anything special. That's a better version of what I suggested in Bug#96359, so you have my support. Now, how are we going to support: If there's a version of libc6 that's known to use kernel headers incompatible with a particular kernel-headers-*, then a package compiled against those kernel headers should conflict with that libc6. -itai
Installing debs in ~user/ or /usr/local?
Hi all, maybe it is a stupid question, but can debian packages be installed in other places than / ? I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Is this possible? Egon
Re: how to implement a renamed package
On Sat, May 05, 2001 at 12:39:48PM -0700, David Whedon wrote: Sat, May 05, 2001 at 08:43:30PM +0200 wrote: Hello, I am maintaing the Debian package puzzle and have a problem with the new upstream version. The package and program has been renamed by upstream to tree-puzzle, because there was a conflict with another program named puzzle. I was considering to make a new package tree-puzzle which conflicts and replaces puzzle, but this way the users of puzzle would not get the automatical upgrade of this new upstream version with 'apt-get upgrade'. Thus, how can I automatically replace the package puzzle with the new package tree-puzzle? This is discussed in the Developer's Reference [1]: 9.3 Replacing or renaming packages Sometimes you made a mistake naming the package and you need to rename it. In this case, you need to follow a two-step process. First, set your debian/control file to replace and conflict with the obsolete name of the package (see the Debian Policy Manual for details). Once you've uploaded that package, and the package has moved into the archive, file a bug against ftp.debian.org asking to remove the package with the obsolete name. Just out of curiosity: what happens if an unrelated package with the old, obsoleted name is introduced into the archive? In the case in hand, upstream renamed puzzle - tree-puzzle precisely because there exists something with the name puzzle. If that other puzzle got put into debian, there could be great confusion. Has this ever happened? -S
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: Hi all, maybe it is a stupid question, but can debian packages be installed in other places than / ? It is not a stupid question, IMHO. Unfortunately, I believe the answer is not in general. One of the problems is that .debs tend to install config files in /etc. I would suggest a search of the -devel archives, as this has come up at least once in the past year or so. I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Is this possible? I think it is desirable, but I think it requires non-trivial changes to several bits of the packaging system. If you do the search of the archives, you might post a summary of what you find, to refresh our memories. -S
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: maybe it is a stupid question, but can debian packages be installed in other places than / ? I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Is this possible? Debian packages require root privileges for installation. While you could unpack a .deb in your home directory and use the files in it, you would lose most of the advantages of using a packaging system (file tracking, autoconfiguration, etc.). If you use it this way, a .deb is no better than a .tar with binaries in it. I suppose you could install most simple .debs in a chroot environment where you owned everything, but many packages (notably those which run daemons, cron jobs, etc.) expect to be able to perform tasks as root. That said, .debs _are_ a good addition to .tar.gz for distribution. This is what Debian developers (in general) do: create and distribute .debs. -- - mdz
Re: Bug#95975: mutt: doesn't use charset anymore
On 5 May 2001, Ben Gertzfield wrote: Richard == Richard Atterer [EMAIL PROTECTED] writes: Richard While we're at it: How on earth can I get rid of those Richard Warning: locale not supported by Xlib, locale set to C Richard messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts Richard etc in mutt. Unfortunately, this produces the above error Richard message with lots of X programs - especially annoying Richard when you use at(1); you always get a mail with the error Richard message. 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.) The mutt docs are not very compatible with Xlib. In fact, this is bug 76906. On my sid machine, still not solved... -- Jean-Christophe Dubacq -- ATER en informatique à l'université de Caen Tel: 02 31 56 74 30 / 06 67 67 69 15 / 02 31 93 62 24 Email: [EMAIL PROTECTED] http://www.info.unicaen.fr/~jcdubacq/ Adresse: Jean-Christophe Dubacq, GREYC, Université de Caen, 14032 Caen Cedex
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote:
Hi all,
maybe it is a stupid question, but can debian packages be installed in other
places than / ?
i was thinking about this myself. i suppose in theory it is possible,
and the data.tar.gz has all the files that are installed, relative to
the root. the other peice is the control.tar.gz, which contains all the
maintainer scripts. and other miscleneously.
the problems i see with non-root:
suid/sgid binaries would lose those bits, and some functions of
maintainer scripts would fail (such as update-menus and update-rc.d)
also, /var/lib/dpkg/status and friends could not be updated.
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 - )
}
-john
Re: build depends on kernel-headers
Now, how are we going to support: If there's a version of libc6 that's known to use kernel headers incompatible with a particular kernel-headers-*, then a package compiled against those kernel headers should conflict with that libc6. Eh? Why would this be useful? p.
Re: Woody version number
Read the archives for the sad history of version numbers and the flamewars :) Please remember that the reason we went to using version names was prompted by Debian 1.0. [For those that don't know: Debian was at something like 0.97 when a vendor [?? Infomagic ??] released a prerelease snapshot which was broken in many ways as Debian 1.0 Debian had to bump to 1.1] The reason for the sub-versioning 2.2r2 etc. was originally prompted by CD vendors who wanted to be sure that they were pressing the latest and greatest Debian. Despite _heated_ arguments at the time, it has proved useful to have sub version mumbers - otherwise we'd have had to bump version numbers fairly regularly. The argument may now be academic, anyway, since few vendors would press hundreds of Debian disks anymore and the much wider availability of CD recorders mean that more people can get a current CD. It is useful on occasion to have silver CD's since these will read on almost every drive: could we arrange a pressing to mark 3.0 (I stil have Oficial 1.3 CD's!) If you think in terms of major version 1.1 - 1.3 2.0 - 2.2 (both over several years) with sub versions 3.0 - 3.3 [Woody and a bit] 4.0 [Fully FHS Debian on 8 architectures] etc. etc. We don't want to play the numbers game, nor do we need to. It is interesting to look back a couple of years to 1.3 and see how far we've come - also that at least one commercial Debian variant appears to have gone by the board. If you trust the Linux Weekly News editorial team, several other distributions want to pull out of the distribution market and move to being service providers [Turbolinux, S.u.S.E, Caldera and Red Hat all mentioned]. I want to see Debianthere in the long term and we may be down to being one of the few non-commercialdistributions that it remains free to download and use. Just my 0.02 Euro :) Andy
Re: build depends on kernel-headers
Je 05 May 2001 15:06:11 -0500, Manoj Srivastava [EMAIL PROTECTED] scribis: Try this: suggest the kernel-headers package, and set CFLAGS += -I$(KSRC)/include and instruct people to set the KSRC variable as needed. [...] Have a default value for KSRC if you need, and arrange for the buildd's to create the /default-ksrc/../kernel-headers-X.X. Why not have the default KSRC be /usr/src/kernel-headers-X.X? I think that's what Ben suggested... Also, by default do you mean set in debian/rules? -itai
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote: One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and 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. You should look into the S/390 port. -- - mdz
About native packages
Hi, it seems to be a trend that maintainers try to change their packages to be Debian native. Policy says about native packages (in the chapter about version numbering): -- snip -- debian_revision This part of the version number specifies the version of the Debian package based on the upstream version. It may contain only alphanumerics and the characters `+' and `.' (plus and full stop) and is compared in the same way as the upstream_version is. It is optional; if it isn't present then the upstream_version may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a Debian package, and so there is only one `debianization' of it and therefore no revision indication is required. -- snip -- From this, it should be clear that it's wrong to make a package like xv where we haven't even the permission to distribute modified binaries Debian native (see #96458). 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? - When there's during a freeze a new version in unstable and you fix a bug in the version in frozen you have to make a split in your upstream development. One argument for native packages is that you want to include the debian/ directory in your upstream package. You can do this even in non-native packages and when you change nothing the .diff.gz will be empty - but it's possible for you to change only the Debian package without releasing a new upstream version. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: maybe it is a stupid question, but can debian packages be installed in other places than / ? You could try the --root=dir, --admindir=dir or --instdir=dir options to dpkg. But I think that maybe this is not what you really want. I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? If the Makefile in the original source provides this functionality, then that is convenient to use in the Debian package source's debian/rules Makefile to install the binaries into the package build directory. Related to this is the --prefix option that can be given to the typical configure script in the original sources. If you don't specify that option when you ./configure, it usually defaults to /usr/local. Debian packages are generally spoken configured with --prefix=/usr. If user egon wants to install into his home directory, he should run configure the source with --prefix=/home/egon. After building the program, doing a make install will put all the files somewhere in /home/egon. Also, the programs that are installed there will look for their settings under /home/egon instead of /etc. This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Download package sources for your own rebuilding is just as easy as downloading the prebuilt .deb packages. Just add a deb-src line to your /etc/apt/sources.list file for every deb line it already has. After you apt-get update, you can cd into a work directory and type: apt-get source somepkg Then, do a cd somepkf-* and look around in the various README, INSTALL and other textfiles. There is a directory debian/ which contains some maintainer files, one of which is the rules file. This is a Makefile that contains the rules to build the source for Debian and to create the .deb package. It gives you a very efficient way to find out if there are any special tricks needed to compile the source. Now you can run ./configure --help, ./configure [options], make and make install. Is this possible? This is how it used to be before there was Debian ;-) Cheers, Joost
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 09:44:07PM +1000, Herbert Xu wrote: 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...
Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 19:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote: One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and 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. 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. Regards, Alex.
Re: build depends on kernel-headers
Ben Collins [EMAIL PROTECTED] wrote:
On Sat, May 05, 2001 at 09:44:07PM +1000, Herbert Xu wrote:
The thing is, kernel-headers should not be used at all unless you're
compile glibc, or modules. Anything else will break.
False. That is the very thing I want to alleviate (people using kernel
headers from the libc6-dev package).
Nope, I wasn't suggesting that people should. They should stop using kernel
header files whether it be kernel-headers or libc6-dev.
People should not be using them, but if they do, they should use a
kernel-headers package, and not rely on the headers in libc6-dev which
are different on all archs, and change almost every new glibc build. You
are never guaranteed to get the prefered kernel headers for your program
(be it a scsi level thing like cdrecord, or mount tools like
util-linux).
False. People should not be using kernel headers at all. Linus no longer
supports this, that is, if you do use it, you're on your own and it'll most
likely break with 2.4.
The preferred solution is to maintain your own set of headers that should
work across kernel versions.
The point here is to make packages start moving to Build-Dep'ing on
kernel-headers-* packages. The question is, how to allow them to do that
easily.
Personally I think you're trying to solve a problem that will become a
non-issue as people realise this and stop using kernel headers.
--
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 Sat, May 05, 2001 at 09:40:40PM -0400, Ben Collins wrote:
Personally I think you're trying to solve a problem that will become a
non-issue as people realise this and stop using kernel headers.
That's wishful thinking, but I agree. I'm not sure it is possible
though.
I'm more confident about it, since if they don't do this, their programs
won't compile at all with 2.4. I certainly won't be keeping
kernel-headers-2.2 around any longer than necessary.
--
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 09:46:32AM +1000, Herbert Xu wrote: The point here is to make packages start moving to Build-Dep'ing on kernel-headers-* packages. The question is, how to allow them to do that easily. Personally I think you're trying to solve a problem that will become a non-issue as people realise this and stop using kernel headers. That's wishful thinking, but I agree. I'm not sure it is possible though. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: how to implement a renamed package
Hi, On Sat, May 05, 2001 at 12:39:48PM -0700, David Whedon wrote: This is discussed in the Developer's Reference [1]: 9.3 Replacing or renaming packages Sometimes you made a mistake naming the package and you need to rename it. In this case, you need to follow a two-step process. First, set your debian/control file to replace and conflict with the obsolete name of the package (see the Debian Policy Manual for details). Once you've uploaded that package, and the package has moved into the archive, file a bug against ftp.debian.org asking to remove the package with the obsolete name. 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'? 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? Cheers, Guenter -- Linux: Who needs GATES in a world without fences?
Re: Installing debs in ~user/ or /usr/local?
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. -- - mdz
Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 16:48:05 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: maybe it is a stupid question, but can debian packages be installed in other places than / ? I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Is this possible? Debian packages require root privileges for installation. While you could unpack a .deb in your home directory and use the files in it, you would lose most of the advantages of using a packaging system (file tracking, autoconfiguration, etc.). If you use it this way, a .deb is no better than a .tar with binaries in it. I suppose you could install most simple .debs in a chroot environment where you owned everything, but many packages (notably those which run daemons, cron jobs, etc.) expect to be able to perform tasks as root. That said, .debs _are_ a good addition to .tar.gz for distribution. This is what Debian developers (in general) do: create and distribute .debs. One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and 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. This could also be useful for Debian developers. This way, they could not only develop their packages on Debian machines (on which they don't have root), but also test them. I imagine quite a few packaging bugs in unstable would be wiped out that way. ;) 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, 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]. Has anyone heard of an effort to do something like that?[3] [1] As some of you may notice, Quake 2 demands that it run in a directory with _all_ of its data files -- some of which normal users may change (eg, baseq2/config.cfg), and some of which normal users will probably never change, but might (eg, baseq2/pak?.pak). As it's done now, symlinks are created to files users are unlikely to change, and files users are likely to change are copied. With copy-on- write links, all files would be copy-on-write links, and the user can change any file, without wasting any more disk space than actually necessary. [2] The files in /etc/skel that get copied to new users' home directories might be changed by root from time to time, for whatever reason. Not all users are knowledgeable enough to change them, and of those who are, only some understand that they need to remove a symlink and copy the source file and edit that. With copy-on-write links, `adduser' would simply create copy-on-write links to the files in /etc/skel in a new user's home directory, and that new user can play with those files if they wish, and if they don't, they'll automatically receive updated versions of those files whenever root changes them in /etc/skel. [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. ;) Regards, Alex.
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'? 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. 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. Of course you should take this with disclaimers because I'm just going on what I think I remember seeing from past upgrades on my own machine. Ben. -- Ben Burton ([EMAIL PROTECTED]) http://baasil.humbug.org.au/bab/ Director of Training Australian Informatics Olympiad Committee Feminism... is about a social, anti-family political movement that encourages women to leave their husbands, kill their children, practice witchcraft, destroy capitalism and become lesbian. - Pat Robertson, candidate for the Republican presidential nomination, 1988
