Uploaded sysklogd 1.4.1-2 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Sat, 21 Apr 2001 15:06:02 +0200 Source: sysklogd Binary: sysklogd klogd Architecture: m68k Version: 1.4.1-2 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon [EMAIL PROTECTED] Changed-By: Martin Schulze [EMAIL PROTECTED] Description: klogd - Kernel logging daemon sysklogd - System logging daemons Closes: 90534 90582 90970 93922 Changes: sysklogd (1.4.1-2) unstable; urgency=low . * Corrected location of GPL (closes: Bug#90582) * Added section and priority for binary packages * Added dependency to klogd so people who upgrade their sysklogd package won't lose it anymore (closes: Bug#93922) * Added code snipped to stop klogd/syslogd upon removal (closes: Bug#90534, Bug#90970) Files: 603810499cab338ac300f319cad32fba 51816 base required sysklogd_1.4.1-2_m68k.deb 9ad2c0b872bc9cf600c231a05d4e55ed 33874 base required klogd_1.4.1-2_m68k.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBOufGRW547I3m3eHJAQFHaAP8Ce+DeRkeJ2UoNJWoE0g4n3EyiiriKFJV T5TCW0OBmwGwjcppSf4lfzrJNFsN7xTeayIZIPawaFbxwR1Qyz8+V+EtsYCZpJYX d98+KUulS96UvZgBeXkCytqqeBqXvVN99xmVNDESzW5c+lQovcQ/rXK3lGXkgAO2 LRcJ93frddc= =86yD -END PGP SIGNATURE-
Uploaded escm 1.1-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 15:56:56 +0900 Source: escm Binary: escm Architecture: m68k Version: 1.1-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Hatta Shuzo [EMAIL PROTECTED] Description: escm - Embedded Scheme Processor Closes: 94949 Changes: escm (1.1-4) unstable; urgency=low . * applied a patch for debian/rules from Eric Gillespie Jr. (closes: Bug#94949) * delete duplicated page from escm.1 Files: 2757783e1bfd937b3517d3bdf4a86713 17134 utils optional escm_1.1-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66CnFEycGpQPNsdIRAgfbAJ93HTxRlIf3m4YGTC7OeL0qvwgshgCgqHnz u1pPIOTO2JTYHTLJM3V2dgM= =fFqd -END PGP SIGNATURE-
Uploaded slmon 0.4.1-2 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 18 Apr 2001 10:09:16 +0100 Source: slmon Binary: slmon Architecture: m68k Version: 0.4.1-2 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Alan Ford [EMAIL PROTECTED] Description: slmon - A simple S-Lang based system performance monitor Closes: 94317 95055 Changes: slmon (0.4.1-2) unstable; urgency=low . * Fix build-depends, closes: #94317, #95055 Files: f1d5366694a727d7e6a11975daa188d0 18750 utils optional slmon_0.4.1-2_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66CnKEycGpQPNsdIRAngVAJ9iKxNwj8YaypURzOf0cIXMoctGIgCcD0jA mEgK6ewEkXX3ANpSLAqKX1Y= =eYEL -END PGP SIGNATURE-
Uploaded gthumb 0.6-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 23:08:08 +0200 Source: gthumb Binary: gthumb Architecture: m68k Version: 0.6-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Remco van de Meent [EMAIL PROTECTED] Description: gthumb - an image viewer and browser for GNOME Changes: gthumb (0.6-1) unstable; urgency=low . * New upstream release Files: e305639660248ba98916616752cea9b7 100820 graphics optional gthumb_0.6-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE65/kXEycGpQPNsdIRAtAkAJ9UTDP27Z4K93duNiupbj4GAN9rxQCeP23w DPyRHAxRgaY8VRB1DobDuNg= =tNXD -END PGP SIGNATURE-
Uploaded smpeg 0.4.3-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 23:43:09 -0400 Source: smpeg Binary: smpeg-plaympeg libsmpeg0 libsmpeg-dev Architecture: m68k Version: 0.4.3-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Joe Drew [EMAIL PROTECTED] Description: libsmpeg-dev - SDL MPEG Player Library - development files libsmpeg0 - SDL MPEG Player Library - shared libraries smpeg-plaympeg - SMPEG command line MPEG audio/video player Changes: smpeg (0.4.3-1) unstable; urgency=low . * New upstream release * Put libsmpeg0 in section libs, libsmpeg-dev in devel to agree with the overrides file * Updated build-depends to libsdl1.2, added xlibs-dev to build-depends * My audio timestamp patch integrated upstream, removed from diff Files: 9b2535058670f8b2b945b7f141442323 92800 libs optional libsmpeg0_0.4.3-1_m68k.deb df8ad05990b982ec831b20b40ab3f374 92256 devel optional libsmpeg-dev_0.4.3-1_m68k.deb 65243fa9e1220aa98ef9ab7c6a585120 18432 graphics optional smpeg-plaympeg_0.4.3-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66CnMEycGpQPNsdIRAm7OAKCLz5FPeqYbGP8hsIY3xOYarFSHEwCeLAce A9/2osU+ej5lxXqmraAul2k= =WQex -END PGP SIGNATURE-
Uploaded xpaste 1.1-13 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 17:14:34 +0200 Source: xpaste Binary: xpaste Architecture: m68k Version: 1.1-13 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Bas Zoetekouw [EMAIL PROTECTED] Description: xpaste - A program to display the contents of the primary paste buffer. Changes: xpaste (1.1-13) unstable; urgency=low . * OK, now really changed the Maintainer field. * Changed priority to optional. Files: 03abc66ac6033979abdffaca3dbe2332 7846 x11 optional xpaste_1.1-13_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66CnUEycGpQPNsdIRAjTjAJ9c8P0B7QHItxm7lYjjSEBLR4FJvACfc8Yu GS6NVqHXht8LHQ3UKbReWPY= =LFlM -END PGP SIGNATURE-
Uploaded bonnie++ 1.01b-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 12:30:18 +0100 Source: bonnie++ Binary: bonnie++ Architecture: m68k Version: 1.01b-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Russell Coker [EMAIL PROTECTED] Description: bonnie++ - Hard drive bottleneck testing benchmark suite. Closes: 94349 Changes: bonnie++ (1.01b-1) unstable; urgency=low . * Compiled with GCC 2.95 for Debian. Closes:#94349 Files: 4d2e4ceb6e07315af6f59251412f1b1b 40832 utils optional bonnie++_1.01b-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66CnCEycGpQPNsdIRAt4lAJwOk/YxdEEJSL8AjgFK7IaWldcnNACgqlbZ YP2HiNjczcT7YabaNheCT2U= =Bqal -END PGP SIGNATURE-
Uploaded gxedit 1.23-7 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 10:19:58 -0700 Source: gxedit Binary: gxproc gtk-shell gxedit Architecture: m68k Version: 1.23-7 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Chris Waters [EMAIL PROTECTED] Description: gtk-shell - GTK-based Pop-up command to get user input gxedit - GTK-based text editor gxproc - GTK-based utility to show system information Closes: 94885 Changes: gxedit (1.23-7) unstable; urgency=low . * patched gtk-shell -ef to print an error message when it is unable to save a file, rather than crashing (closes:#94885) Files: 6bff899ff833b76a00ef133a7d9d1483 130962 editors optional gxedit_1.23-7_m68k.deb ec95ed9c74148e1905ebdb12ee4fd6a3 13710 utils optional gtk-shell_1.23-7_m68k.deb 0abd0d87948606581abaf283caf6dba5 17236 utils optional gxproc_1.23-7_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66DbyEycGpQPNsdIRAsyEAJ9LhvbLqHnZYpX3fUi/MBkkUh3BNgCgjZBP Ppnj7O/SRqW1UbgRNS8agv0= =/kq1 -END PGP SIGNATURE-
Uploaded sipp 3.1-7 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Apr 2001 13:50:25 -0400 Source: sipp Binary: sipp-dev sipp Architecture: m68k Version: 3.1-7 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Matthew Danish [EMAIL PROTECTED] Description: sipp - create and render 3-d scenes sipp-dev - development library for sipp Changes: sipp (3.1-7) unstable; urgency=low . * Updated Standards Version Files: fa8eae6a27500d36dca3c79c20c6f93a 44792 libs optional sipp_3.1-7_m68k.deb 45677a4f0fb2da367f93b63cf147154b 310068 devel optional sipp-dev_3.1-7_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE65/keEycGpQPNsdIRAoFAAJ9yV4qvtAehbJPvSAOUfGKZzZv8/gCeNioY tSvtEiBxJB04egag7kGr2pk= =ss9x -END PGP SIGNATURE-
Uploaded libunicode 0.4.0-2 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 24 Apr 2001 11:04:05 +0200
Source: libunicode
Binary: libunicode-dev libunicode0
Architecture: m68k
Version: 0.4.0-2
Distribution: unstable
Urgency: low
Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED]
Changed-By: Vincent Renardias [EMAIL PROTECTED]
Description:
libunicode-dev - The GNOME Unicode library - development files.
libunicode0 - The GNOME Unicode library.
Closes: 95081
Changes:
libunicode (0.4.0-2) unstable; urgency=low
.
* Updated config.{guess,sub} files.
Closes: #95081.
Files:
85b1b33db4153a739b554759ddda4a7a 58054 libs extra libunicode0_0.4.0-2_m68k.deb
e4354c81c8dbdf0f4b0b06f3618d1dc1 53676 devel extra
libunicode-dev_0.4.0-2_m68k.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Rick Younie [EMAIL PROTECTED]
iD8DBQE65/kaEycGpQPNsdIRAqcRAJ98igDP1Ztu23wtq2w+lG2IwYUJSQCfYwC9
QFxhPyjOsfNfK9OoFhcjIgw=
=Fn04
-END PGP SIGNATURE-
Uploaded ispell-da 1.4.13-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 apr 2001 14:53:54 +0200 Source: ispell-da Binary: idanish wdanish Architecture: m68k Version: 1.4.13-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Peter Makholm [EMAIL PROTECTED] Description: idanish- The Danish dictionary for ispell. Changes: ispell-da (1.4.13-1) unstable; urgency=low . * New upstream Files: aad3c452de58d37189d9e550c370ee6e 678424 text optional idanish_1.4.13-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66HzZEycGpQPNsdIRAtdVAJ0eGMGdY4uLOR+mviudEPV8LrlC+gCdGY4B hjDbragILCTHcUnmntudIjo= =6DLh -END PGP SIGNATURE-
Uploaded etherape 0.6.7-1 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Apr 2001 11:09:14 +0200 Source: etherape Binary: etherape Architecture: m68k Version: 0.6.7-1 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Frederic Peters [EMAIL PROTECTED] Description: etherape - Graphical network monitor modeled after etherman. Changes: etherape (0.6.7-1) unstable; urgency=low . * New upstream release. Files: 2c0eb4192c3dad4de30e6789d571036d 92490 net optional etherape_0.6.7-1_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66HFCEycGpQPNsdIRApW8AJ9KhU9IX/Z5ZImLIon44m9pf9RWBgCgh3rD rhSB3YffoBVW7ZB3kVH0wIw= =4sY6 -END PGP SIGNATURE-
Uploaded fmirror 0.8.4-3 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Apr 2001 18:03:50 +0200 Source: fmirror Binary: fmirror Architecture: m68k Version: 2:0.8.4-3 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Antonin Kral [EMAIL PROTECTED] Description: fmirror- memory efficient ftp mirror program Closes: 95121 Changes: fmirror (2:0.8.4-3) unstable; urgency=low . * end of line sequence fixed, right sequence, according to RFC959 is CRLF, Closes: #95121 Files: c477e3404fc78f56c404da47b7282a27 40882 net optional fmirror_0.8.4-3_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66HFLEycGpQPNsdIRAn9YAJ0ROzp711mqEcGWMwyTI6wsVFfqTwCdFMLd qbt1Fk8R5Z5jthgw/a9FuiE= =HPSv -END PGP SIGNATURE-
Uploaded dhid 4.0.1-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 17:12:18 +0200 Source: dhid Binary: dhid Architecture: m68k Version: 4.0.1-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Manuel Estrada Sainz [EMAIL PROTECTED] Description: dhid - Dynamic Host Information System (DHIS) client Changes: dhid (4.0.1-4) unstable; urgency=low . * build-depend on libgmp3-dev insted of libgmp2-dev. Files: 4caa9b9025d12c3e3a027b8271791ebd 19482 net optional dhid_4.0.1-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66HE/EycGpQPNsdIRAtDvAJ4l9+481Y/suo/xwczT74bMM/3TwACfYTHB 17+HIi7lhF2oF7qfSSKNjL0= =/BZc -END PGP SIGNATURE-
Uploaded libsmi 0.2.16-2 (m68k) to erlangen
-BEGIN PGP SIGNED MESSAGE-
Format: 1.7
Date: Tue, 24 Apr 2001 11:33:28 +0200
Source: libsmi
Binary: libsmi2-dev libsmi2
Architecture: m68k
Version: 0.2.16-2
Distribution: unstable
Urgency: low
Maintainer: buildd m68k user account [EMAIL PROTECTED]
Changed-By: Remco van de Meent [EMAIL PROTECTED]
Description:
libsmi2- A library to access SMI MIB information
libsmi2-dev - A library to access SMI MIB information (development files)
Closes: 95079
Changes:
libsmi (0.2.16-2) unstable; urgency=low
.
* Updated config.{guess,sub} using upstream CVS (closes: #95079)
Files:
734dfba4ae7fb26d6d93b0477144cd09 1392042 libs optional
libsmi2_0.2.16-2_m68k.deb
7ec7b4ab3867506dce9de1c42630f7dd 129714 devel optional
libsmi2-dev_0.2.16-2_m68k.deb
-BEGIN PGP SIGNATURE-
Version: 2.6.3i
Charset: noconv
iQCVAwUBOuh1A2547I3m3eHJAQF3IAP/cKTwha+zSJdAp1s7jjUYKH33pKCQrudU
JhHBrGuCi8aA7E3V8sQgTjxD/7/7wlpAbIQRnsO/L/0KvJKmfKDT3jBJ6Mn7iHNR
pQNtO3Hrb18I6lgGlxsHjm39PnZ0+V2JJQW2+uTgR6kCXwiHNKDbhd0VnXDROs2f
9yLXJ0/Xg8U=
=on35
-END PGP SIGNATURE-
Uploaded thrust 0.89-12 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 22:08:22 +0200 Source: thrust Binary: thrust Architecture: m68k Version: 0.89-12 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: RISKO Gergely [EMAIL PROTECTED] Description: thrust - a port of the classic Commodore 64 game Closes: 95008 Changes: thrust (0.89-12) unstable; urgency=low . * alpha svgalib build-depend removed (Closes: Bug#95008) Files: f8ffaae4af6b6012c8ba9d5fd200f887 97040 games optional thrust_0.89-12_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66LbLEycGpQPNsdIRAv8qAKCQ+u6qidTlIPUu2Skp8lJM4bUwYACghqpR NYEXSPxyiASKkvH86u7l6Dc= =iVBF -END PGP SIGNATURE-
Uploaded mopd 2.5.4-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 11:15:55 -0700 Source: mopd Binary: mopd Architecture: m68k Version: 2.5.4-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: David Whedon [EMAIL PROTECTED] Description: mopd - The Maintenance Operations Protocol (MOP) loader daemon. Closes: 94856 Changes: mopd (2.5.4-4) unstable; urgency=low . * fix build failure on alpha (closes: #94856) Files: 1f8a4fc560e06aca5b8ac7628bd76c48 46550 net extra mopd_2.5.4-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66LbEEycGpQPNsdIRAu20AJ9d3hEHbiSs3TqkHWy9qK11KjYBDACcCTv7 WOJ5ewPr00Vk9yP7fLiHbBo= =/Ne8 -END PGP SIGNATURE-
Uploaded xsok 1.02-7 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 14:30:31 +0200 Source: xsok Binary: xsok Architecture: m68k Version: 1.02-7 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Joel Rosdahl [EMAIL PROTECTED] Description: xsok - Generic Sokoban game for X11 Changes: xsok (1.02-7) unstable; urgency=low . * Move whole /var/lib/games/xsok to /var/games/xsok. Fixes: bug#94968. Files: 3a7d2f1e2f535f9a9fd4e221cadd3fc1 60874 games optional xsok_1.02-7_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66LbYEycGpQPNsdIRArenAJ0fYWqhDHMdlwPnRU7hUbSXNvmMAQCgssUJ ZR+TnFlIimWLS25KALykrgw= =Wjvf -END PGP SIGNATURE-
Uploaded libpam-ldap 107-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 08:01:27 +0300 Source: libpam-ldap Binary: libpam-ldap Architecture: m68k Version: 107-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Sami Haahtinen [EMAIL PROTECTED] Description: libpam-ldap - Pluggable Authentication Module allowing LDAP interfaces Closes: 94923 Changes: libpam-ldap (107-4) unstable; urgency=low . * there was a mysterious '| ' character in config. (Closes: #94923) Files: 9bd656d7411aeeafc7dd6c45f60b263d 33784 admin extra libpam-ldap_107-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66La8EycGpQPNsdIRArH4AKCAZLoB9Shpvjwqg5S5fAh62jGpUwCePKIn 3Teq2FC/0nxA1E2VDrP80SE= =Bh5O -END PGP SIGNATURE-
Uploaded xpenguins 1.2-4 (m68k) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 22 Apr 2001 21:39:16 +0200 Source: xpenguins Binary: xpenguins Architecture: m68k Version: 1.2-4 Distribution: unstable Urgency: low Maintainer: Debian/m68k Build Daemon (buildd4) [EMAIL PROTECTED] Changed-By: Bas Zoetekouw [EMAIL PROTECTED] Description: xpenguins - little penguins walk on your windows Closes: 86815 Changes: xpenguins (1.2-4) unstable; urgency=low . * Added a menu item to stop xpenguins (closes: #86815) Files: 6fd1cd5239763d217cdfe3d71fe4794d 37534 games optional xpenguins_1.2-4_m68k.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Rick Younie [EMAIL PROTECTED] iD8DBQE66LbSEycGpQPNsdIRAnQBAKCNE+NtdJ0bSYquhJA8pawnduWKvQCfcRS5 vdrc1Lu5cQyJzK9jzC+NhWE= =uLD+ -END PGP SIGNATURE-
Uploaded sendmail 8.11.3+8.12.0.Beta7-4 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 12:00:00 -0500 Source: sendmail Binary: sendmail libmilter-dev sendmail-doc Architecture: sparc Version: 8.11.3+8.12.0.Beta7-4 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. Closes: 94559 95068 95208 Changes: sendmail (8.11.3+8.12.0.Beta7-4) unstable; urgency=high . * Bumped default confMAX_RUNNERS_PER_QUEUE from 1 to 5 - please customize this locally - I've added a note to the postinst to hit those that don't read changelogs. * sendmail startup now cleans and runs the MSP queue * Upstream patch to allow group readable key file (for MSP) and update submit.mc appropriately * Upstream patch to correct queue management and add some debugging * Upstream patch to fix a qf handling race * Upstream patch to fix SEGV in malloc closes: #95068 * local patch (sent upstream) for compilation on PPC (thanks C.M. Connelly) closes: #94559 * Correct Makefile rules for generating submit.cf closes: #95208 * correct update_db/update_mc to better handle new install (missing *.mc and other databases). Files: b8d04bbf01b286234fa046e89ea497c2 1329880 mail extra sendmail_8.11.3+8.12.0.Beta7-4_sparc.deb 316d55b889bd44a5523d5a4eafb46ab6 532592 mail extra sendmail-doc_8.11.3+8.12.0.Beta7-4_sparc.deb f9c6a3e166473a22680349515c05f356 248776 devel extra libmilter-dev_8.11.3+8.12.0.Beta7-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE652xVfNc/ZB4E7C0RAk3/AJwP/GPu6HO6v1SHqLjlvaqv9WEFAQCdG8pW PuFkRek6CHrXXXkdWkQKsSc= =zTi2 -END PGP SIGNATURE-
Uploaded ttcn3parser 20010321-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Apr 2001 11:00:11 + Source: ttcn3parser Binary: ttcn3parser Architecture: sparc Version: 20010321-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: W. Borgert [EMAIL PROTECTED] Description: ttcn3parser - Parser for the TTCN-3 test specification language Closes: 94871 Changes: ttcn3parser (20010321-1) unstable; urgency=low . * New upstream version. * Added java-virtual-machine to build dependencies (closes: #94871). Files: 6a0a0339a037cdaa4a2615ef531b6db1 602226 devel optional ttcn3parser_20010321-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE652xSfNc/ZB4E7C0RAlZKAJ4tR4bEmkdnku0CCSTcQLyOvSuBKwCeInYb 2e6pKaIFBPp5HDvUH9N4ML8= =e+1i -END PGP SIGNATURE-
Uploaded bash 2.05-4 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Apr 2001 19:32:36 +0200 Source: bash Binary: bash-doc bash bash-builtins Architecture: sparc Version: 2.05-4 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: bash - The GNU Bourne Again SHell bash-builtins - Bash loadable builtins - headers examples Changes: bash (2.05-4) unstable; urgency=low . * Apply upstream patches p1-p4 (closes #92455). * Fixed in bash-2.05-alpha1: closes #47588. Files: 68e03907f74b7e060411808e303a41de 366288 base required bash_2.05-4_sparc.deb 87f648bb7b5876c8963d76bdd659f7c0 86936 utils optional bash-builtins_2.05-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE65zATfNc/ZB4E7C0RAmbSAJ9T3vl7IsCXIyPa8YjRD1zutBRcogCgmXuJ CM5ba+wIjdGra842ALucl+g= =dM7N -END PGP SIGNATURE-
Uploaded display-dhammapada 0.21-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Apr 2001 21:55:45 -0500 Source: display-dhammapada Binary: display-dhammapada Architecture: sparc Version: 0.21-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: David Starner [EMAIL PROTECTED] Description: display-dhammapada - Displays verses from the Dhammapada. Changes: display-dhammapada (0.21-1) unstable; urgency=low . * New upstream version - only minor changes from alt1 * UTF-8 man page and help Files: 2bf547cd2535642cd34d158610abefd2 62906 misc extra display-dhammapada_0.21-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE652TVfNc/ZB4E7C0RAsi5AJ9/uyDliXK3IwhJeX4s9eEfHeALdACgkLFW 4uowulYAfvvnlSzeBFom5cM= =PyoX -END PGP SIGNATURE-
Uploaded abuse 2.00-27 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Apr 2001 13:30:33 +0300 Source: abuse Binary: abuse Architecture: sparc Version: 2.00-27 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Arto Jantunen [EMAIL PROTECTED] Description: abuse - Crack dot Com's Abuse action game. Changes: abuse (2.00-27) unstable; urgency=low . * New Maintainer * Added Obsolete to the description * Changed depends to abuse-frabs | abuse-lib * Added recommends abuse-sdl Files: 5896da5b6e8599e959233b6b5d3d8ec5 287026 games optional abuse_2.00-27_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE652TRfNc/ZB4E7C0RAlcJAJwLxg4C5oN0supgzV3q1+mpvtoCIwCdGtd7 QP3vZFxUwBX5UwRE2mElzaE= =822T -END PGP SIGNATURE-
Uploaded devtodo 0.1.5-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Apr 2001 21:58:38 +0200 Source: devtodo Binary: devtodo Architecture: sparc Version: 0.1.5-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Arthur Korn [EMAIL PROTECTED] Description: devtodo- hierarchical, prioritized todo list manager Closes: 91809 93641 Changes: devtodo (0.1.5-1) unstable; urgency=low . * New upstream release - missed --paranoid in 0.1.4, this is default in /etc/todorc, closes: #93641 - 0.1.3 closes: #91809 * Changed src/support.cc to allow paranoid in todorc files. * fiddled with doc/Makefile.am (missing - before the test, added $(manlinks)). Files: 0e16d0e0acf1076f274ddd2eb3c365a6 145444 utils optional devtodo_0.1.5-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE651xEfNc/ZB4E7C0RAlAuAKCwDMKbFcbtY/qCkM6HoJrINDPWEQCfVFbG Bd5nnvgvw5hMHZnsqdMjuyk= =Z2rY -END PGP SIGNATURE-
Uploaded commonc++ 1.4.2-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Apr 2001 00:19:30 -0400 Source: commonc++ Binary: libcommonc++-dev libcommonc++-1.4 Architecture: sparc Version: 1.4.2-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Matt Zimmerman [EMAIL PROTECTED] Description: libcommonc++-1.4 - A GNU package for creating portable C++ programs libcommonc++-dev - Header files and static libraries for Common C++ Changes: commonc++ (1.4.2-1) unstable; urgency=low . * Non-maintainer upload (soon to be de facto maintainer) * New upstream version. Files: 432c2f47773346d57f4263b0bc47855d 552736 devel optional libcommonc++-dev_1.4.2-1_sparc.deb 43a6269557b1546e4d825e3be92e8fd9 124984 devel optional libcommonc++-1.4_1.4.2-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE651xBfNc/ZB4E7C0RAnSvAJ9j1jGef9riv/BoEmdh5TikzwpXkgCeI8vu X5kRL3nX0VFq7fVRnL/tPOI= =XxMp -END PGP SIGNATURE-
Uploaded saoimage 1.29.3-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Apr 2001 10:05:24 +0200 Source: saoimage Binary: saoimage Architecture: sparc Version: 1.29.3-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Tinguaro Barreno Delgado [EMAIL PROTECTED] Description: saoimage - A utility for displaying and processing astronomical images. Changes: saoimage (1.29.3-1) unstable; urgency=low . * New upstream release. Files: 794035a72ec566cda41a8355144ed06b 430426 misc optional saoimage_1.29.3-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE651xCfNc/ZB4E7C0RApoSAJwPVsnp2J6i+/VNlAA1QiVvZ4ppFACfVR2G P2O85P+dEpdYHlfN/fSR32M= =ZB0P -END PGP SIGNATURE-
Uploaded linpac 0.16pre2-1 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 18 Apr 2001 22:38:14 -0300 Source: linpac Binary: linpac Architecture: sparc Version: 0.16pre2-1 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: root [EMAIL PROTECTED] Description: linpac - Terminal for packet radio with mail client Changes: linpac (0.16pre2-1) unstable; urgency=low . * New upstream source. * Fix Alpha compile. See bug #94872 Files: 32d516861a803b1a7d4401cb2aff81f6 327236 hamradio optional linpac_0.16pre2-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE652TVfNc/ZB4E7C0RAlCOAJ9Jwf2Aj92iYuS4/gdRJusbTYyeVwCfezrF We/QBHoJKbstKbevdstQy1Y= =euum -END PGP SIGNATURE-
Uploaded gcc-2.95 2.95.4.ds1-0.010424 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Apr 2001 23:10:11 +0200 Source: gcc-2.95 Binary: gcc-2.95-doc libstdc++2.10-dbg chill-2.95 g77-2.95-doc protoize-2.95 cpp-2.95-doc gpc-2.95 gcc-2.95 g77-2.95 gobjc-2.95 g++-2.95 libstdc++2.10-glibc2.2 gpc-2.95-doc libg++2.8.1.3-dev cpp-2.95 gcj-2.95 libstdc++2.10-dev libg++2.8.1.3-glibc2.2 libg++2.8.1.3-dbg Architecture: sparc Version: 2.95.4.ds1-0.010424 Distribution: unstable Urgency: high Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: chill-2.95 - The GNU Chill compiler. cpp-2.95 - The GNU C preprocessor. g++-2.95 - The GNU C++ compiler. g77-2.95 - The GNU Fortran 77 compiler. gcc-2.95 - The GNU C compiler. gcj-2.95 - The GNU compiler for Java(TM). gobjc-2.95 - The GNU Objective-C compiler. gpc-2.95 - The GNU Pascal compiler. libg++2.8.1.3-dbg - The GNU C++ extension library - debugging files. libg++2.8.1.3-dev - The GNU C++ extension library - development files. libg++2.8.1.3-glibc2.2 - The GNU C++ extension library - runtime version. libstdc++2.10-dbg - The GNU stdc++ library (debugging files) libstdc++2.10-dev - The GNU stdc++ library (development files) libstdc++2.10-glibc2.2 - The GNU stdc++ library protoize-2.95 - Create/remove ANSI prototypes from C code Changes: gcc-2.95 (2.95.4.ds1-0.010424) unstable; urgency=high . * Apply updated ppc-fsirl patch (function.c removed) for all archs again. urgency=high for powerpc. * Remove patches included in ppc-fsirl patch: ppc-descriptions, ppc-ice. * Correct build dependency (hurd-i386) (#94038). * debian/rules2: Get free memory correctly on hurd (#94127). * close #68452: ash is available on sparc and doesn't have any special build rules for sparc. * close #79882: bind-8.2.3 compiles fine on i386. * Alpha related bug fixed in 2.95.3 (closes #94137). * Fix typo in docs (-fstdc - -stdc). Closes #94894, #94899. * Not a bug: #93481 (see report). Files: 775aa3d0870ac2f01b15f6714bde7b1f 1066400 devel standard gcc-2.95_2.95.4-0.010424_sparc.deb 942e8220410c57ed0808ea8f6684b009 127296 interpreters standard cpp-2.95_2.95.4-0.010424_sparc.deb 7fa22cde1b4f32681b4f0ee226138f80 1152174 devel standard g++-2.95_2.95.4-0.010424_sparc.deb 4ceab19382c265ad0156c6896d989716 36954 devel optional protoize-2.95_2.95.4-0.010424_sparc.deb 201809ce6230a026353dcd8b5025bdec 968560 devel optional gobjc-2.95_2.95.4-0.010424_sparc.deb 742eb7e5f1cec449e4c5d31a05e9ad31 1183168 devel optional g77-2.95_2.95.4-0.010424_sparc.deb 75cdbcb0ad59a6204cb5673c609ad126 969762 devel optional chill-2.95_2.95.4-0.010424_sparc.deb 20efbf72c9edf80c93a943b4050f4282 1027144 devel optional gcj-2.95_2.95.4-0.010424_sparc.deb dec8b28ec740413f9636632e97b21f3b 126726 base required libstdc++2.10-glibc2.2_2.95.4-0.010424_sparc.deb e4163be6f9d94645e8e78504b0632d8f 301126 devel standard libstdc++2.10-dev_2.95.4-0.010424_sparc.deb 5d5be348ae5bb37105ff89985a6514a2 308252 devel extra libstdc++2.10-dbg_2.95.4-0.010424_sparc.deb 379a392e90ef4b734534a65affd30e44 132652 libs extra libg++2.8.1.3-glibc2.2_2.95.4-0.010424_sparc.deb d97c4c27d06c723363240a8243f3770c 326006 devel extra libg++2.8.1.3-dev_2.95.4-0.010424_sparc.deb 74205d6bde67566e0a6a70e36df836ca 291304 devel extra libg++2.8.1.3-dbg_2.95.4-0.010424_sparc.deb a1ec9440825c3d97757c52af584962a9 1400276 devel optional gpc-2.95_2.95.4-0.010424_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE651w4fNc/ZB4E7C0RAlsaAKCAPd1eyZgDvfmZVuDCjX/lBeoTxACfQBt8 Kt7EDaMNXssrvGxbEkZL0Mc= =Yb+S -END PGP SIGNATURE-
Uploaded iptables 1.2.1a-2 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Apr 2001 00:05:26 -0400 Source: iptables Binary: iptables Architecture: sparc Version: 1.2.1a-2 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Laurence J. Lane [EMAIL PROTECTED] Description: iptables - IP packet filter administration for 2.4.X kernels Changes: iptables (1.2.1a-2) unstable; urgency=low . * restore ip6tables, patch provided by Marc Martinez Files: b51463b001fdeb945bf1aa1be85efac1 168972 net optional iptables_1.2.1a-2_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE651xIfNc/ZB4E7C0RAsZGAKCNEJpsZGj7vUGVpAclJoO6Vfi9PgCgjJmP dlZqqX6J9uLS04cwiKfNwwg= =YTyE -END PGP SIGNATURE-
Uploaded shellutils 2.0.11-6 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Apr 2001 07:28:08 -0400 Source: shellutils Binary: shellutils Architecture: sparc Version: 2.0.11-6 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: 94569 Changes: shellutils (2.0.11-6) unstable; urgency=low . * Big note on pwd man page that your shell's pwd might not be /bin/pwd * Ditto for echo * Changes to zh.po to allow building with new gettext, build-dep on same (Closes: #94569) Files: c97834b94c5f2fe5c57926164937f523 626992 base required shellutils_2.0.11-6_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE65zAHfNc/ZB4E7C0RAigVAJ9PR/3HyCXLfj9BodjHYEpgnmRNfQCfZfLk 18C+9VLnvODODH5oUs2JMhQ= =+99e -END PGP SIGNATURE-
Uploaded libgmp3 3.1.1-6 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Apr 2001 09:04:04 -0400 Source: libgmp3 Binary: libgmp3-dev libgmp3 Architecture: sparc Version: 3.1.1-6 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Dale Scheetz (Dwarf #1) [EMAIL PROTECTED] Description: libgmp3- Multiprecision arithmetic library libgmp3-dev - Multiprecision arithmetic library developers tools. Closes: 93361 Changes: libgmp3 (3.1.1-6) unstable; urgency=low . * changed config option to use --enable-mpbsd, creating the *needed mp libs, closes: #93361 Files: 2bb157333cc074c1d39480513afabd84 288554 libs extra libgmp3_3.1.1-6_sparc.deb ff530c1490cfd5c561f43d4186695ebe 251896 devel extra libgmp3-dev_3.1.1-6_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE651w9fNc/ZB4E7C0RAkSNAJ9RHDbysBzWPZ0iruMg/5DU8cjleQCggAhY OJp7+v6eSgeqahVB/xvMlsI= =+mQf -END PGP SIGNATURE-
Uploaded xbat 1.11-4 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Apr 2001 22:54:44 +0200 Source: xbat Binary: xbat Architecture: sparc Version: 1.11-4 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Joost Kooij [EMAIL PROTECTED] Description: xbat - A classic shoot-em-up game for X11. Changes: xbat (1.11-4) testing unstable; urgency=low . * Add README.jp to doc files (Fixes: #40793). * Fix scoredir location to /var/games per FHS (Fixes: #92514). * Unbreak postinst (Fixes: #94771). * Fix build-depends: add xutils, xlibs-dev (Fixes: #95106). * Reundebhelperize. * Fix menu entry. * Drop sgid. Must now be member of group games to save highscore. * Add unhandler for legacy suidmanager registrations to postinst. * Some tweaking and cleaning up of postinst and rules files. Files: 0f4d0513c7ab66e1be9e334d66aa139c 112430 games optional xbat_1.11-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE652TTfNc/ZB4E7C0RAqxlAKCHuTiHm3tAyBtPfpONBookRnXtyACggkps zpDVIkn6geG/zy2YRcnaTIc= =RFDq -END PGP SIGNATURE-
Uploaded make 3.79.1-5 (sparc) to ftp-master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Apr 2001 02:52:38 -0500 Source: make Binary: make-doc make Architecture: sparc Version: 3.79.1-5 Distribution: unstable Urgency: low Maintainer: Debian/SPARC Build Daemon [EMAIL PROTECTED] Changed-By: Manoj Srivastava [EMAIL PROTECTED] Description: make - The GNU version of the make utility. Closes: 89310 Changes: make (3.79.1-5) unstable; urgency=low . * fixed command execution in make. closes: Bug#89310 Files: 531c30c8829beac907a8cf3353a05b1b 389610 devel standard make_3.79.1-5_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Ben Collins [EMAIL PROTECTED] iD8DBQE651w7fNc/ZB4E7C0RAlR3AJ9hKQWI8xFjajq6zmd8ofh/d69tVwCbBdUm faUUjCF6lzU6AGeVf+xixNs= =W7Sb -END PGP SIGNATURE-
Re: Intent to package intel-rng-tools.
On Wed, Apr 25, 2001 at 01:14:22PM -0700, Alexander Hvostov wrote: On Wed, 25 Apr 2001 14:35:37 +0530 Viral [EMAIL PROTECTED] wrote: I am working on packaging intel-rng-tools. It is the daemon to utilise the RNG on i810 boards. Let me know if anyone is working on this. I shall otherwise upload it tonight. Isn't there a kernel driver for that? Yes, but one needs the daemon to use the driver. One could activate it from /proc, but that was removed and moved to a userland daemon. viral -- For long you live and high you fly, but only if you ride the tide, And balanced on the biggest wave, you race towards an early grave.
Re: Base Bug Week, 30th April to 6th May
Martin == Martin Michlmayr [EMAIL PROTECTED] writes: Martin Since the base system comprises our most important Martin packages, virtually all of which are installed on any Martin Debian system, your help is really needed! While Bug Martin Squashing Parties usually focus on Release Critical (RC) Martin bugs, we should also try to get the number of normal (or Martin even wishlist) bugs in the base as low as possible. This Martin involves writing patches or documentation -- everyone can Martin help with this; also non developers are encouraged to Martin participate. What is the easiest way to upgrade only base packages without upgrading anything else (unless required?). Ideally I would like to upgrade/install anything section==base or priority==required, but not anything else just yet (as I don't like upgrading to much stuff, partly because of the huge bandwidth required). Is this possible without manually copyingpasting from dselect? -- Brian May [EMAIL PROTECTED]
RFC: Thoughts on building modules
One thing that strikes me as excellent about Debian is the build system. The autobuilders and tools make it very likely that package builds are reproducible and a variety of tools like debhelper make it easier to do the right thing in many circumstances than doing something wrong. I've come away from this experience convinced that it is very important to have good tools for common tasks. Sadly, I don't think building module packages for modules not in the kernel lives up to the high standards of the rest of the Debian build process.,especially for module packages to work with stock kernels and be uploaded to the Debian archive. These concerns are mostly technical and are to a great extent independent of how many kernel images we have, although obviously if there are a lot of kernel images then autimation is even more important. Manoj's kernel package provides an excellent tool for building custom kernels for end users. It also provides an adequate tool for end users building modules for their kernels. The modules are shipped generally as tarballs that are unpacked into /usr/src/modules. Then, kernel-package generates .debs for each of these modules when make-kpkg modules_image is run. The make-kpkg modules target is intended for maintainers and is somewhat useful. However, it has several shortcomings for official modules package. Because it is run out of make-kpkg it is intended to build multiple modules for a single kernel version. It turns out what maintainers probably want is to build multiple versions of the same module for different kernel versions at once. Also, module maintainers probably want to build on multiple architectures. With make-kpkg this means having an account on multiple architectures. It would be really nice to be able to take advantage of the buildds to build modules for other architectures just as the build non-module packages. So, having established that we have some work to do, let's step back and think about what is going on when you try and build modules. Each architecture has a set of kernel-images that are current. Users running a stock kernel are expected to install one of these images. You as a module maintainer want to make it so that users can install a version of your module for the stock kernel image they have selected. So, for each architecture you want to find out what the current set of stock kernel images are. Normally, there will be at least one old kernel version supported and one or more new kernel versions; there may be multiple flavors/subarchitectures of each kernel version. There is currently no good way to find out what kernel images are available. You could grep through the packages file, but that doesn't exclude images awaiting removal or images for special purposes that are not stock images. Assuming you do manage to find out what stock images exist, you need to build your module for them. There are roughly two approaches you could take: using kernel headers or using kernel source. Apparently some/many modules require a kernel source tree; a kernel headers tree is insufficient. I don't actually know how common this is; I believe the module I maintain could successfully build against a kernel headers package if I tried. If you are using make-kpkg to build your modules then you must have a source tree. For i386 apparently the preferred way (according to kernel-image-i386 maintainer) is to use kernel headers. That may work fine for i386, but other architectures (sparc and m68k were checked) only provide one kernel headers package, not one kernel headers per flavor. This is problematic because at least according to the i386 kernel-image maintainer, we cannot guarantee that modversions symbols will be the same between flavors, so we cannot guarantee that modules built against one set of kernel headers will work with other kernel flavors. So, let's assume you want source for your kernel. On i386 you're all set; you basically just download the kernel source and build against it. On other platforms, it is more problematic. For Sparc, there are patches applied to the kernel in the kernel-image-2.2-sparc package for example. PPC, m68k and ARM appear to actually generate kernel-patch packages for their architectures although I have seen them get out of sync with the kernel images available in the archive. Normally these patches don't seem to affect interfaces my modules care about, so I can be sloppy and just download the kernel source package. However, if we are talking about reproducible builds, these patches matter, or at least an assertion that they will never affect module builds. There's also the issue of dependencies. When building most packages one person is driving the need for rebuilds by changing the source package. Sometimes some library or policy will change and you'll have to rebuild even though there are not source changes you would like to make. However this is fairly rare, and tends not to be
Re: Base Bug Week, 30th April to 6th May
On Thu, Apr 26, 2001 at 02:52:11PM +1000, Brian May wrote: Martin == Martin Michlmayr [EMAIL PROTECTED] writes: Martin Since the base system comprises our most important Martin packages, virtually all of which are installed on any Martin Debian system, your help is really needed! While Bug Martin Squashing Parties usually focus on Release Critical (RC) Martin bugs, we should also try to get the number of normal (or Martin even wishlist) bugs in the base as low as possible. This Martin involves writing patches or documentation -- everyone can Martin help with this; also non developers are encouraged to Martin participate. What is the easiest way to upgrade only base packages without upgrading anything else (unless required?). Ideally I would like to upgrade/install anything section==base or priority==required, but not anything else just yet (as I don't like upgrading to much stuff, partly because of the huge bandwidth required). Is this possible without manually copyingpasting from dselect? Just enter dselect, then on each category that you have packages installed, except for base/required, choose to hold them '='. Should be that simple, although I haven't run dselect in months. Gordon Sadler
Re: kernel-{image,headers} package bloat
On 25 Apr 2001 21:56:58 -0500, Rob Browning wrote: Just in case anyone else was confused, I'm still in favor of having at least *one* precompiled kernel per-architecture, so no one *has* to compile a kernel, but if they want a customized kernel, then, presuming the idea has merit, they would need to install the kernel-custom package, make a selection, and wait a bit. I'm going to have to agree on this one. I don't think anyone should be forced to compile a kernel, but if you care enough to want the optimizations then you should go through the process of doing it for yourself. That way, things will keep working quite well for those who want it to just work, and for those who want to shear off a few k of memory, they can do it for themselves. Everyone has a working kernel, module debate is moot, extra mirror load is nil, and most all the other major points of contention go away as well. Just my $0.02 - David Nusinow [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 09:56:58PM -0500, Rob Browning wrote: Just in case anyone else was confused, I'm still in favor of having at least *one* precompiled kernel per-architecture, so no one *has* to compile a kernel, i think everyone is in favour of that. the issue is whether it's appropriate to have a dozen or so kernel-image packages (and associated kernel-headers packages) per kernel version, when one(*) will do. (*) or whatever the minimum number is that will boot on all ia32 boxes. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 02:18:30AM +1000, Daniel Stone wrote: I could disagree pretty heavily by pointing that this would be shit as it would add an hour to the install. Why not just provide a stock i386 kernel and let people compile it later on? Some people need to patch in mm/swap patches, netfilter patches, their own hacks, etc, etc. please pay attention. nobody (at least as far as i can tell) has suggested getting rid of the stock kernel-image package, so there will be no effect at all on people who just want to install the system and run it. the point at issue is whether there should be dozens of kernel-image and kernel-headers packages when one is enough to do the job. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: Gnome bug 94684
You guys are getting more and more bureaucratic. That's sad. The package maintainer is a volunteer, and he knows you are also a developer. That said, why don't you report the bug directly to the upstream, instead of insisting on this (bureaucratic) procedure of reporting bugs to debian then waiting that debian developer to forward upstream while both of you debian developers are pretty sure it's an upstream issue? I agree that if you're a noname random clueless mere user then the package maintainer shouldn't just close this usibility bug blindly. Bureaucracy sucks. Relying on bureaucracy sucks even more. -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: Gnome bug 94684
zhaoway [EMAIL PROTECTED] writes: The package maintainer is a volunteer, and he knows you are also a developer. That said, why don't you report the bug directly to the upstream, instead of insisting on this (bureaucratic) procedure of reporting bugs to debian then waiting that debian developer to forward upstream while both of you debian developers are pretty sure it's an upstream issue? I agree that if you're a noname random clueless mere user then the package maintainer shouldn't just close this usibility bug blindly. There's a good reason. First, it is the sort of thing that might well be correctly solved in the Debian package and not upstream; that is, the best solution might be to provide a Debian upgrade path rather than a Gnome upgrade path. Second, I can't keep track of who upstream is for all the Debian packages. Third, the BTS is an exceptionally useful placeholder for work needed here. If the bug remains open in the BTS, then it serves to indicate the existence of the problem until its solved, and someone might actually fix it. With Christian Marillat's excessively eager bug-closing, one would never even know of such things. I'm happy if Christian doesn't have the time or expertise to fix the bug himself. He should leave it as a bug, or forward it. But I don't know how to fix it is not a reason for closing the bug. Thomas
Re: ITP: ttf-japanese-kandata
Thank you very much for checking facts. (I think if there is more to be discussed on this copyright, it should be moved to debian-legal list.) With your statement as presented, I had to concur with Branden. But I actually think this can be made into DFSG free package if you present copyright issues properly to the public with further documentation from Wakaba-san / Uchida-san. If there still remain any issues in some part of FONT, you can always remove those portions from package and replace them with the other PD fonts. If someone spend time in the future and provide patch to make them as homogeneous feel, that will make good FREE font set. As far as Uchida-san's portion is concerned, they are clearly PD. Big question is what did Mr. Wakaba used as the base of glyph. And how far modification later affected the total collection. If he started with then popular PC9800's ROM fonts with mere 16x16 bitmap fonts as starting point of making TT fonts, it may be well within fair use. This becomes more so, if heavy manual editing occurred to make these TT fonts to look homogeneous and legal shape. If he took these from TT MS fonts, maybe not. (Here I am talking complicated KANJI where 7 horizontal lines need to be identified within this small 16x16 bitmap space. It is equivalent of 8x8 in English) Documenting history of this font set and making them into clean set is the worthy cause. Following may be useful as a reference point for the copyright law. If I remember correctly, basic shape of glyph is not be copyrighted since it is common to all fonts and should be legible. Also for dot matrix fonts, mere coincident does not make a violation of copyright due to limited possibility of choice. Also note that, even with new copyright law, font itself is not covered by the copyright law in Japan. (Software is covered.) Japan has not verified WIPO 1997 treaty on this typeface thing either. (That is my web search result. IANAL.) I remember reading that ADOBE created postscript fonts in such a way that they can claim them as a software in which shape is programmed into a code. (This is to make sure they keep their right under most legal system.) So copyright of fonts are slightly different issue from ordinary software copyright in legal term. Regards, Osamu On Thu, Apr 26, 2001 at 12:22:46AM +, Takashi Okamoto wrote: document were not remained yet. Mr. wakaba said I think there is no problem because I(wakaba) and Mr.UCHIDA remake a lot of glyphs and nobody point out the problem up to now. But I can't guarantee it. -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki [EMAIL PROTECTED], GnuPG-key: 1024D/D5DE453D + + Fingerprint: 814E BD64 3288 40E7 E88E 3D92 C3F8 EA94 D5DE 453D + + http://www.aokiconsulting.com/ Cupertino, CA USA +
Re: Referring what kernel-images to build to the technical committee?
Sam Hartman [EMAIL PROTECTED] wrote: [...] Summary: Herbert has started building 8 different flavors of kernel-image for i386. These flavors correspond to CPU type; for example there is an appropriate kernel for people with 386 machines to run and an appropriate kernel for people with Athlon machines to run. [...] I'd like to summarize my understanding of the tradeoffs that we have identified in the debian-devel discussion so that if we do turn this issue over to the committee, they will know what concerns we have already identified. Please add to the following list if I have missed something. [...] performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. [...] Hello! _Afair_ it is necessary to run a k6 (or athlon) optimized kernel to use 3DNow! in applications like xmms or lame. This probably applys to ISSE, MTTR and MMX, too. Please correct me if I am wrong. tia, cu andreas -- Uptime: 10 seconds load average: 0.00, 0.00, 0.00 vim:ls=2:stl=***\ Sing\ a\ song.\ ***
Re: kernel-{image,headers} package bloat
On Thu, Apr 26, 2001 at 04:15:24PM +1000, Craig Sanders wrote: On Wed, Apr 25, 2001 at 09:56:58PM -0500, Rob Browning wrote: Just in case anyone else was confused, I'm still in favor of having at least *one* precompiled kernel per-architecture, so no one *has* to compile a kernel, i think everyone is in favour of that. the issue is whether it's appropriate to have a dozen or so kernel-image packages (and associated kernel-headers packages) per kernel version, when one(*) will do. Don't forget the proliferation of kernel modules in that count. This has already started with alsa recently, and I expect that more will follow before too long: alsa-modules-2.4.3-386 alsa-modules-2.4.3-586 alsa-modules-2.4.3-586tsc alsa-modules-2.4.3-686 alsa-modules-2.4.3-686-smp alsa-modules-2.4.3-k6 alsa-modules-2.4.3-k7 alsa-modules-2.4.3-pentium4 alsa-modules-2.4.3-pentiumiii alsa-modules-2.4.3-pentiumiii-smp kernel-headers-2.4.3 kernel-headers-2.4.3-386 kernel-headers-2.4.3-586 kernel-headers-2.4.3-586tsc kernel-headers-2.4.3-686 kernel-headers-2.4.3-686-smp kernel-headers-2.4.3-k6 kernel-headers-2.4.3-k7 kernel-headers-2.4.3-pentium4 kernel-headers-2.4.3-sparc kernel-image-2.4.3-386 kernel-image-2.4.3-586 kernel-image-2.4.3-586tsc kernel-image-2.4.3-686 kernel-image-2.4.3-686-smp kernel-image-2.4.3-k6 kernel-image-2.4.3-k7 kernel-image-2.4.3-pentium4 Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
libc6 broken?
Hello, I upgraded to unstable and now, my libc6 seems to be borken. If I try a ./configure or a make xconfig with a new Kernel, I get this error-msg: /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' If I try a make menuconfig, I get: debian:/usr/src/linux-2.4.3# make menuconfig rm -f include/asm ( cd include ; ln -sf asm-i386 asm) make -C scripts/lxdialog all make[1]: Entering directory `/usr/src/linux-2.4.3/scripts/lxdialog' /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status Unable to find the Ncurses libraries. You must have Ncurses installed in order to use 'make menuconfig' make[1]: *** [ncurses] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.3/scripts/lxdialog' make: *** [menuconfig] Error 2 I reinstalled my ncurseslibs and my libc6 packages, libstdc++-2.10-glibc and so on, but still get the same error. Any ideas? (Using an upgraded unstable from today, did a dist-upgrade too) Uli
Re: kernel-{image,headers} package bloat
Aaron Lehmann [EMAIL PROTECTED] wrote:
I've said before that over 2000 kernel configuration options exist and
Most of which can be decided at runtime once you start using initrd.
--
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: RFC: Thoughts on building modules
Sam Hartman [EMAIL PROTECTED] wrote:
I see three options. We can have the modules built out of the main
source package that also produces the architecture: all package
containing the tarball for end users to use with kernel-package.
Alternatively, we can have a separate modules source package for
building only the module; this has the advantage of separating the
module components from other components of the system, which is nice
for things like PCMCIA and Openafs that have significant userspace
components. We could also try and get module building integrated into
stock kernel source packages; this would have the advantage of
I personally prefer a variant of the second option, have a per-arch source
package which build-depends on a module-source .deb produced by the main
module source package. The reason it has to be per-arch is given later in
your message, i.e., you don't want to recompile the i386 modules if the
alpha kernel gets updated. The same per-arch package should build-depend
on the respective kernel-headers packages for the images that it wants to
build against.
BTW, this is how the kernel images are organised on alpha/i386/sparc.
If your module needs stuff outside kernel-headers, either it's doing
something wrong, or there's stuff in the kernel that needs to be moved
under include/.
--
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: Only one who have parse error in /var/lib/dpkg/available?
On Wed, 25 Apr 2001, Shaul Karl wrote: Package: ng-cjk Priority: optional Section: editors Installed-Size: 164 Maintainer: Yasuhiro Take [EMAIL PROTECTED] Architecture: i386 Source: ng Version: 1.4.3.1-1 Depends: libc6 (= 2.2.1), libncurses5, ng-common Filename: pool/main/n/ng/ng-cjk_1.4.3.1-1_i386.deb Size: 73550 MD5sum: dcf8a20ce9180fa42df [22:46:18 /tmp]$ wc /var/lib/dpkg/available 69953 307766 2547713 /var/lib/dpkg/available [22:46:41 /tmp]$ Is there a final new line? Yes there is: [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available -rw-r--r--1 root root 2547713 Apr 25 00:46 /var/lib/dpkg/available [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available 11557764 c e 9 1 8 0 f a 4 2 d f \n 11560001 [12:39:42 /tmp]$ and dpkg -l doc-linux-text works too. I do not know what was changed. Shouldn't there be a Description field after the MD5sum? -- Shaul Karl [EMAIL PROTECTED]
Re: Packages not making it into testing
On Wed, Apr 25, 2001 at 05:49:24PM -0500, Rahul Jain wrote: On Wed, Apr 25, 2001 at 11:57:50PM +1000, Hamish Moffatt wrote: Doesn't the user have to belong to the relevant group anyway? We already control access to things like floppy drives, sound cards etc through groups, so cd burning is another good example. I don't see how sgid cdrom will help here. Just make it non-sgid, and if they're a member of group cdrom, they can burn a cd, period. That's what I was saying we should do. That's what we do with other special hardware like audio and floppy drives. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
On Wed, Apr 25, 2001 at 08:27:18PM -0400, Josh Huber wrote:
Yes, which is different -- we have 4 kernel-image packages for
I'm open to suggestions as to which of the images can be dropped.
As far as I can see, there are two arguments against the present organisation
on i386:
1. The kernel images provide no/little benefit for our users.
2. The kernel images impose a strain on the mirrors that we can do without.
1 is a matter of opinion, and one which I do not agree with.
I do understand that everyone is operating under constrained resources. So
I'm always on the lookout for images that have little use or images that
can be merged. In particular, pentium4 will go in the next release as
there is very little demand for it, and for those who actually have it,
I doubt compiling the kernel is very time consuming [1].
This will bring the number of images down to 7, or in terms of size, about
70MB.
I'm willing to further reduce that to as little as 3 with the removal of
586/586tsc/k6/k7. However, I would like to see concrete evidence from
mirror operators that this 40M poses a significant problem for them before
I take this route as except k7, the three flavours take significant to
compile on their respective hosts. I won't go below that as an SMP kernel
is always required, and the 686 flavour covers a very large chunk of the
i386 userbase.
As to the kernels on the alpha architecture which I also maintain, I have
no plans whatsoever to go down this optimisation route as there simply
aren't enough users to justify the costs involved. It is also the case
that I simply to have an Alpha box that's sexy enough to do this :)
I cannot comment about the kernel maintainers on other architectures of
course. But I'm sure they will make the most sensible decisions for them.
[1] The point of this exercise is not to make it easier for people who don't
know how to compile kernels to be able to use optimised kernels. It is
for those who don't have a grunty box to keep up with the them.
--
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: Referring what kernel-images to build to the technical committee?
On Thu, Apr 26, 2001 at 12:58:10PM +1000, Craig Sanders wrote:
On Wed, Apr 25, 2001 at 08:30:31PM -0400, Sam Hartman wrote:
[...]
i think you've done a good job of summarising the issues.
I agree as well.
--
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: updating of /etc/rc?.d
Jason Lunz [EMAIL PROTECTED] wrote:
This is dpkg bug #67095. Is there any progress on this? I would love it
if I didn't have to re-disable nfs and portmap each time I upgraded
their packages.
What's wrong with adding an exit 0 to the init.d files?
--
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: Only one who have parse error in /var/lib/dpkg/available?
Shaul Karl [EMAIL PROTECTED] wrote:
Is there a final new line?
Yes there is:
[12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
-rw-r--r--1 root root 2547713 Apr 25 00:46
/var/lib/dpkg/available
[12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
11557764 c e 9 1 8 0 f a 4 2 d f \n
11560001
[12:39:42 /tmp]$
I'm not sure if this is your problem, but there should be two final
new lines. One to terminate the the MD5sum line, and one to terminate
the record.
--
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
Intent to package vcdimager.
Hello all, I plan to package vcdimager. From the README : This is GNU VCDImager, a VideoCD image mastering tool. This package contains GNU VCDRip, a VideoCD ripping tool, for ripping mpeg streams from VideoCD images and showing VideoCD information about the image. There already exists cdrdao which can clone VCDs, and vcdtools, which can create a VCD image from mpegs. vcdimager rips mpegs from the VCDs. viral -- There is no dark side of the moon really. Matter of fact it's all dark. pgpeeWM2PLzL9.pgp Description: PGP signature
ITP: darj - arj archive unpacking tool
(I filed this as bug#95252, but used X-Debian-CC instead of X-Debbugs-CC. Strange... I remember it being X-Debian-CC once.) darj - arj archive unpacking tool I've started writing a free version of unarj. I have unarj installed in case I come across .arj files on the net or on old floppies, and vrms listed it once too often :) So this is more of an intent to write than intent to package, but I do intend to package it once it is done. I will duplicate unarj's interface as closely as I can (except for the banner), both for ease of regression testing and in case there are scripts that parse unarj's output. I considered going the other way and making it behave like a proper unix utility, but... maybe in version 2. Its current state is that it can list the files in an archive, but can't uncompress or extract them. I'm not looking for help (I'm having fun writing this), but if you have any unusual arj archives lying around then I would appreciate a copy for testing. When it's done I will release it under the GNU GPL. Richard Braakman
libc6 broken?
Hello, I upgraded to unstable and now, my libc6 seems to be borken. If I try a ./configure or a make xconfig with a new Kernel, I get this error-msg: /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' If I try a make menuconfig, I get: debian:/usr/src/linux-2.4.3# make menuconfig rm -f include/asm ( cd include ; ln -sf asm-i386 asm) make -C scripts/lxdialog all make[1]: Entering directory `/usr/src/linux-2.4.3/scripts/lxdialog' /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status Unable to find the Ncurses libraries. You must have Ncurses installed in order to use 'make menuconfig' make[1]: *** [ncurses] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.3/scripts/lxdialog' make: *** [menuconfig] Error 2 I reinstalled my ncurseslibs and my libc6 packages, libstdc++-2.10-glibc and so on, but still get the same error. Any ideas? (Using an upgraded unstable from today, did a dist-upgrade too) Uli
Re: libc6 broken?
On Thu, Apr 26, 2001 at 12:28:51PM +0200 , Ulrich Wiederhold wrote:
Hello,
I upgraded to unstable and now, my libc6 seems to be borken.
works fine here. it wasn't upgraded in quite a while
If I try a ./configure or a make xconfig with a new Kernel, I get this
error-msg:
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
/lib/libc.so.6: undefined reference to [EMAIL PROTECTED]'
any optimized libs in /lib/i586(or whatever?)
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
sgore Debian - 3 million penguins can't be wrong.
Re: Packages not making it into testing
On Wed, Apr 25, 2001 at 03:53:15PM +1000, Anthony Towns wrote: Hello world, ciao + gdb uploaded 250 days ago, out of date by 240 days! doesn't build on sparc, see 86882 i'd like to adopt this, i'll mail to the maintainer. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Packages not making it into testing
Domenico Andreoli [EMAIL PROTECTED] writes: On Wed, Apr 25, 2001 at 03:53:15PM +1000, Anthony Towns wrote: + gdb uploaded 250 days ago, out of date by 240 days! doesn't build on sparc, see 86882 i'd like to adopt this, i'll mail to the maintainer. Do you have the resources to try and follow it on non-intel architectures as well? Gdb is a hairy package... Ciao, -- David N. Welton Free Software: http://people.debian.org/~davidw/ Apache Tcl: http://tcl.apache.org/ Personal: http://www.efn.org/~davidw/ Work: http://www.innominate.com/
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Adam Heath wrote: On Wed, 25 Apr 2001, Dale Scheetz wrote: On Wed, 25 Apr 2001, Wichert Akkerman wrote: Previously Dale Scheetz wrote: Then you break things for no good reason. These module builders you speak of should be using the same headers as glibc. Absolutely definitely not. Userland is different from kernelspace, and headers need not match at all. Feel free to search debian-devel or linux-kernel archives where that has been discussed way too often already. Kernel modules exist in kernelspace, not userland. Building them against any other headers than those used by glibc does nothing to improve the stability or usefulness of Debian. Ah, self-contradictory statement. A kernel-module must be built with the EXACT SAME environment as the kernel being run. This means they need an EXACT match of headers. The ones that are included with glibc are generic, and will NEVER match the running kernel(even across kernel versions, let alone flavors). Dale, get a clue about kernel module building. You are completely wrong on this. You're right, I'm an idiot. I have no idea what I was thinking... I also don't know why I got diverted from the issue of bloat. The idea of flavours seems to go beyond the version connectedness required by kernel drivers. We have always delivered a kernel-header package for each version of the kernel that we deliver. What is there about the modules problem that suggests there should be even more flavours? The difference in architectures is a simple symlink to the proper asm routines. What else needs to be tailored that can't be handled in postinst. The last thing we need in this distribution is more packages... Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Packages not making it into testing
On Thu, Apr 26, 2001 at 12:52:39PM +0200, David N. Welton wrote: Domenico Andreoli [EMAIL PROTECTED] writes: On Wed, Apr 25, 2001 at 03:53:15PM +1000, Anthony Towns wrote: + gdb uploaded 250 days ago, out of date by 240 days! doesn't build on sparc, see 86882 i'd like to adopt this, i'll mail to the maintainer. Do you have the resources to try and follow it on non-intel architectures as well? Gdb is a hairy package... mmmh, i cannot follow other arches, i have access to i386 only :( talking about resource to dig into it, i'm not so sure. if i never try i never can figure this out. i don't want to rewrite it all now, i'm *sure* i have not enough skills. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: updating of /etc/rc?.d
On Wed, Apr 25, 2001 at 09:43:56PM -0400, Jason Lunz wrote: [EMAIL PROTECTED] said: I've thought for a while that perhaps update-rc.d should have a --persistant option that would do the same thing as remove AND add a K symlink in /etc/rc9.d/ -- a valid but unused runlevel -- so that users could permanently disable things in one swift commandline. This is dpkg bug #67095. Is there any progress on this? I would love it if I didn't have to re-disable nfs and portmap each time I upgraded their packages. It is possible to disable a service simply by removing links in /etc/rc*.d . So long as you leave at least one (/etc/rc0.d/K*package would seem to be a good candidate), update-rc.d when called by packages on upgrade is a no-op. Something like: rm /etc/rc*.d/S*package should generally do the trick. Note, now that netbase has changed the dependency on portmap to a `suggests' you may remove it anyway. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: Gnome bug 94684
On 25 Apr 2001, Thomas Bushnell, BSG wrote: There's a good reason. First, it is the sort of thing that might well be correctly solved in the Debian package and not upstream; that is, the best solution might be to provide a Debian upgrade path rather than a Gnome upgrade path. I agree. Those are the little value-added things a Debian package adds to the raw source. And it sounds like this is a trivial kind of thing to fix. At the very least the maintainer should have a debconf screen popup that says Use KDE! :-) Second, I can't keep track of who upstream is for all the Debian packages. Why not? It's in the copyright file of each package. If it isn't--that's a bug. Zhaoway is right that you're a big boy and can talk to upstream developers without having to go through a middleman. Third, the BTS is an exceptionally useful placeholder for work needed here. If the bug remains open in the BTS, then it serves to indicate the existence of the problem until its solved, and someone might actually fix it. With Christian Marillat's excessively eager bug-closing, one would never even know of such things. This is true as well. What is the point of a bug tracking system if not to track bugs. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: Problem with installing Postgres throught APT
=?iso-8859-1?q?J=E9r=F4me?= Marant wrote: [copied to the list for comments] Can you find out why it wants to remove libpgsql2.1. postgresql-client nee ds this. Here is the problem: libpgsql2.1 provides libpgsql2 and conflicts with libpgsql2 It hasn't stopped its being installed on my system or on a number of others. I found the conflict was necessary to force the removal of libpgsql2, but it does indeed provide libpgsql2 to other packages that depend on that. I feel there must be some other problem with your system. -- 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 Submit yourselves therefore to God. Resist the devil, and he will flee from you. James 4:7
Re: Referring what kernel-images to build to the technical committee?
On Thursday 26 April 2001 09:05, Andreas Metzler wrote: performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. [...] Hello! _Afair_ it is necessary to run a k6 (or athlon) optimized kernel to use 3DNow! in applications like xmms or lame. This probably applys to ISSE, MTTR and MMX, too. I agree that having kernels compiled with support for different features is a good idea. We must provide an i386 kernel. There is software available which only runs with MMX. We should offer a kernel with MMX support which requires Pentium-MMX to support running this. For 3DNow! we should have a kernel which supports it. There is no need for a MTTR specific kernel. MTTR is not really needed as there is no software written which is unable to run without it. Our goal here should be compatibility with software. MTTR can increase speed significantly in certain situations, but there's lots of other ways of doing that for less effort which we aren't supporting. MTTR can allow you to work around broken hardware. But we can't provide enough kernels to support all combinations of broken hardware (I am sure that I could find a list of a dozen boolean options which are all needed to be in one state or another for various broken hardware - we can't provide 2^12 kernels). Also I think that we should have an SMP kernel in the list. Another issue is support for all the different SCSI controllers and RAID controllers. Perhaps we should spend more time working on initrd support? -- 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: auditd as logrotate replacement?
On Wed, Apr 25, 2001 at 08:35:51PM -0300, Alejo Sanchez wrote: well, your version would do it the dlopen() way. actually we were going to ask if there was a restriction on depending on dlopen(), as it could be possible on some non-dynamic plataforms. (no shared libraries, no dl library) You could look at libltdl from the libtool suite. I guess you could always use configure tests to figure this sort of stuff out. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Referring what kernel-images to build to the technical committee?
RC There is no need for a MTTR specific kernel. MTTR is not really RC needed as there is no software written which is unable to run RC without it. Our goal here should be compatibility with software. RC MTTR can increase speed significantly in certain situations, but RC there's lots of other ways of doing that for less effort which we RC aren't supporting. MTTR can allow you to work around broken RC hardware. But we can't provide enough kernels to support all RC combinations of broken hardware (I am sure that I could find a RC list of a dozen boolean options which are all needed to be in one RC state or another for various broken hardware - we can't provide RC 2^12 kernels). I think you are wrong about 'MTTR is not really needed'. One good example is aviplay (player for avi files). It perfomance is seriously affected by MTTR option. This fact is mentioned in its docs and I've seen myself *significant* difference in its perfomance when I've compiled kernel with MTTR option. Probably perfomance of simular programs will be affected too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Referring what kernel-images to build to the technical committee?
On Thursday 26 April 2001 16:38, Ilya Martynov wrote: RC There is no need for a MTTR specific kernel. MTTR is not really RC needed as there is no software written which is unable to run RC without it. Our goal here should be compatibility with software. RC MTTR can increase speed significantly in certain situations, but RC there's lots of other ways of doing that for less effort which we RC aren't supporting. MTTR can allow you to work around broken RC hardware. But we can't provide enough kernels to support all RC combinations of broken hardware (I am sure that I could find a RC list of a dozen boolean options which are all needed to be in one RC state or another for various broken hardware - we can't provide RC 2^12 kernels). I think you are wrong about 'MTTR is not really needed'. One good example is aviplay (player for avi files). It perfomance is seriously affected by MTTR option. This fact is mentioned in its docs and I've seen myself *significant* difference in its perfomance when I've compiled kernel with MTTR option. Probably perfomance of simular programs will be affected too. I've played many AVI files without MTRR support. It will still work, just a bit slower. If programs won't run at all (as in the case of MMX and 3DNow!) then we should compile different kernels. If they just don't run as fast then we can let the users compile their own kernels. If you want maximum video speed you want to compile your own kernel with AGP and DRI support etc... -- 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: Referring what kernel-images to build to the technical committee?
RC I've played many AVI files without MTRR support. It will still RC work, just a bit slower. I think it depends on configuration. On my home PC aviplay is almost unusable without MTRR. It looks like slide show instead movie. aviplay docs mention that some people reported up to x3 increase in perfomance. I've not seen such perfomance increase myself but it is really significant. With MTRR it is *possible* for me to watch movies. RC If programs won't run at all (as in the case of MMX and 3DNow!) RC then we should compile different kernels. If they just don't run RC as fast then we can let the users compile their own kernels. I understand your point. I just want you to understand that MTRR support in kernel can be more important than you think. Nowdays Linux is much less hackers project. There is a lot of people who don't need to know how recompile kernel. Many of them want to watch movies. Many of them will wonder 'Why Linux is so slow?'. RC If you want maximum video speed you want to compile your own RC kernel with AGP and DRI support etc... AFAIK both AGP and DRI can be compiled as modules so they should be compiled anyway in stock kernel. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
debian-devel´Ô ¾È³çÇϼ¼¿ä?
¢Ä ¿À´ÃÀÇ À¯¸Ó ¢Å ¡á°ú½Ã¿åA girl got an engagement ring, and would seize every opportunity for calling attention to it. In a group with girl friends no one noticed it. Finally when herfriends were sitting around talking, she got up suddenly and said, "It's awfully hot in here. I think I'll take my ring off." ¡Þseize every opportunity for ~ ing : ±âȸ¸¸ ÀÖÀ¸¸é ~ ÇÏ´Ù.¡Þcall attention to : ~ ¿¡ ÁÖÀǸ¦ ȯ±â½ÃÅ°´Ù. ¡Þawfully : very ¾àÈ¥¹ÝÁö¸¦ ¹ÞÀº ¾Æ°¡¾¾´Â ±âȸ¸¸ ÀÖÀ¸¸é »ç¶÷µé¿¡°Ô ±× ¹ÝÁö¸¦ º¸¿©ÁÖ·Á°í µé¾ú´Ù ÇѹøÀº ¿©ÀÚÄ£±¸µé°ú ¾î¿ï·È´Âµ¥ ¾Æ¹«µµ ±× ¹ÝÁö¸¦ ´«¿©°Ü ºÁÁÖÁö ¾Ê¾Ò´Ù¸¶Ä§³» ¾Æ°¡¾¾´Â ´Ùµé µÑ·¯¾É¾Æ À̾߱⸦ ³ª´©°í ÀÖ´Â ÆÇ¿¡ ¹ú¶± ÀÏ¾î¼¸é¼ ¸»Çß´Ù."¾îÈÞ, ´õ¿ö¼ ¸ø °ßµð°Ú³×. ³ª ¹ÝÁö¸¦ »©¾ß ÇÒ±îºÁ!" ¢Ä ¿À´ÃÀÇ ¿µ¾î ÇѸ¶µð ¢Å ¢Ã °¨»çÀÇ ¸»À» ÇÒ ¶§¿Ü±¹ÀεéÀº ³²¿¡°Ô ¾ÆÁÖ ÀÛÀº µµ¿òÀ» ¹Þ¾Æµµ "Thank you.(°¨»çÇÕ´Ï´Ù.)"¶ó°í ¸»ÇØ¿ä. ÀÌ°ÍÀº ¾î·ÈÀ» ¶§ºÎÅÍ ±×·± ±³À°À» ¹ÞÀ¸¸é¼ ÀÚ¶ó ¿Ô±â ¶§¹®¿¡ ¸ö¿¡ º£¾î ÀÖ¾î »ó´ë¹æÀÇ »ç¼ÒÇÑ µµ¿òÀ̳ª Ä£Àý¿¡µµ "Thank you."¶ó°í ¸»ÇÏ´Â ½À°üÀ» °®°Ô µÈ°Å °°¾Æ¿ä. ¹°·Ð, ¿ì¸®µµ ¸¶Âù°¡ÁöÁö¸¸¿ä."Thank you."¿¡ ´ëÇÑ ÀÀ´äÀº "õ¸¸¿¡¿ä."¶ó´Â ¶æÀ¸·Î "You are welcome. /Don't mention it. /Not at all."µîÀÇ Ç¥ÇöÀ» ¾²ÁÒ. A: It was very kind of you to go to that trouble for me.B: It was no trouble at all. It was my pleasure.A: It's very kind of you to say so.A: Àú¸¦ À§Çؼ ±×·± ¼ö°í¸¦ ÇØ ÁÖ½Ã´Ï Á¤¸» °í¸¿½À´Ï´Ù.B: ¹¹ ¼ö°í¶ö °ÍÀÌ ÀÖ³ª¿ä. Á¦°¡ ÁÁ¾Æ¼ ÇÑ ÀÏÀä.A: ±×·¸°Ô ¸»¾¸ÇØ ÁÖ½Ã´Ï Á¤¸» °í¸¿½À´Ï´Ù.¡á°¨»çÀÇ ±âº» Ç¥Çö¢Â Thank you. /Thanks. ¢¹°¨»çÇÕ´Ï´Ù.¢Â Thanks a lot. /Thank you very much. /Thank you so much. ¢¹´ë´ÜÈ÷ °¨»çÇÕ´Ï´Ù.¢Â I'd appreciate it. ¢¹±×·¸°Ô ÇØ ÁÖ½Ã¸é °¨»çÇÏ°Ú½À´Ï´Ù.¢Â I appreciate it very much. ¢¹±× Á¡ Á¤¸» °¨»çÇÕ´Ï´Ù.¢Â On behalf of our employees I'd like to thank you. ¢¹ÀúÈñ ȸ»ç¿øµéÀ» ´ëÇ¥Çؼ ´ç½Å¿¡°Ô °¨»ç µå¸®°í ½Í½À´Ï´Ù.¢Ä À߸ø ¾²ÀÏ ¼ö Àִ ǥÇö ¢Å¢Ã ¿©±â¼ 1È£¼±À¸·Î °¥¾ÆŸ¼Å¾ß ÇÕ´Ï´Ù¡áYou have to shift to the No.1 Line.¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡í(X)¡áYou'll have to transfer to the No.1 Line from here.¡ë¡ë¡ë¡í(O)¢Áshift´Â ´ë°³ °ÅÁÖÁö³ª »ý°¢À» ¹Ù²Û´Ù´Â ¶æÀ̹ǷΠ¿©±â¼´Â ¸ÂÁö ¾Ê¾Æ¿ä. ±³ÅëÆíÀ» °¥¾ÆŸ´Â °ÍÀº º¸Åë transfer¶ó°í ÇØ¿ä. ±×¸®°í ³ë¼±À» °¥¾ÆŸ´Â ȯ½Â¿ªµµ transfer¶ó°í Çϴµ¥, À̶§´Â ¸í»çÀÔ´Ï´Ù. ºñÇà±â ¿©Çà Áß¿¡ °¥¾ÆŸ´Â ±âÂøÁö´Â stopover¶ó°í ÇØ¿ä.¡ÞNow you have to switch to the No.1 Line.(¿©±â¼ 1È£¼±À¸·Î °¥¾ÆŸ¼¼¿ä.)¡ÞYou have to get over to the No.1 Line.(1È£¼± ÂÊÀ¸·Î °¡¼Å¼ Ÿ¼¼¿ä.) ¢Ä ¿À´ÃÀÇ ÀϾî ÇѸ¶µð ¢Å ¢ÂÀϺ»¾îµµ ¿µ¾î¿Í °°Àº ÇüÅ·Π±¸¼ºµÇ¾î ÀÖ½À´Ï´Ù.¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ë¡ëdebian-devel´Ô ¾È³çÇϼ¼¿ä? ÀúÈñ´Â Àüȸ¦ ÀÌ¿ëÇؼ °»ç¿Í 1 : 1 ·Î ¿Ü±¹¾î ÇнÀÀ» ÇÒ ¼ö ÀÖ´Â ¢Ä Online Korea ¢Å ¶ó°í ÇÕ´Ï´Ù.¹Ì¸® Çã¶ô¹ÞÁö ¾Ê°í ÆíÁö µå·Á Á˼ÛÇÕ´Ï´Ù. ºÎµð ³Ê±×·¯¿ì½Å ¿ë¼¸¦.. ÀúÈñ ȸ»ç¿¡¼´Â ¿Ü±¹¾î(¿µ¾î,ÀϾî)¿¡ °ü½É ÀÖ´Â ¸¹Àº ºÐµé²² ¸ÅÀÏ(¿ù-±Ý), ¿µ¾îÀ¯¸Ó¿Í »ýÈ°¿¡ ÇÊ¿äÇÑ È¸È ÇÑ ¹®À徿À» ¹«·á·Î º¸³» µå¸®°í ÀÖ¾î¿ä. À§¿Í °°Àº ³»¿ëÀÇ ¼ºñ½º¸¦ ¹Þ¾Æº¸±â ¿øÇÏ½Ã¸é ¡ì [EMAIL PROTECTED] ¡í·Î "yes"¶ó´Â ³»¿ëÀÇ ´äÀåÀ» Áֽñ⠹ٶø´Ï´Ù. ±×¸®°í, ÀúÈñ ÀüÈ ¿Ü±¹¾î °ÀÇ°¡ ±Ã±ÝÇϽŠºÐµéÀ» À§ÇØ, 1ȸ¿¡ ÇÑÇؼ¢Â ¹«·á ½Ã¹ü°ÀÇ ¢Âµµ ½Ç½ÃÇØ µå¸®°í ÀÖÀ¸´Ï Çѹø µé¾îº¸°í ½ÍÀ¸½Ã¸é Áö±Ý ½ÅûÇØ ÁÖ¼¼¿ä. ¹«·á ½Ã¹ü°ÀÇ ½Åû ¹æ¹ýÀº ¢º ÀÌ°÷ ¢¸ À» Ŭ¸¯ÇϽŠÈÄ °ÀÇ ½Åû¶õ¿¡ Àִ½ùü°ÀÇ ½Åû ÆûÀ» ÀÛ¼ºÇϼż º¸³» ÁÖ½Ã¸é µË´Ï´Ù.¹°·Ð, ÀüÈ 02-588-0510 À¸·Îµµ ½ÅûÇÏ½Ç ¼ö ÀÖ±¸¿ä. ¾Æ¹«ÂÉ·Ï ÀÌ ÇнÀ¹ýÀÌ debian-devel´ÔÀÇ È¸È ½Ç·Â Çâ»ó¿¡ ÀÛÀº º¸ÅÆÀÌ µÇ¾úÀ¸¸é ÇÕ´Ï´Ù. debian-devel´Ô²²´Â http://www.kr.debian.org/contact.hu.html¿¡ ÀÖ´Â ÁÖ¼Ò¸¦ º¸°í ¸ÞÀÏ µå·È´Âµ¥¿ä,ºÒÇÊ¿äÇÑ Á¤º¸¿´´Ù¸é Á¤¸» Á˼ÛÇÕ´Ï´Ù.¾ÕÀ¸·Î Çã¶ô¾ø´Â ¸ÞÀÏÀº µå¸®Áö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù.±×·³, ¾È³çÈ÷ °è¼¼¿ä.
Re: Referring what kernel-images to build to the technical committee?
On 04/26/2001 09:59:13 AM Russell Coker wrote: On Thursday 26 April 2001 16:38, Ilya Martynov wrote: RC There is no need for a MTTR specific kernel. MTTR is not really RC needed as there is no software written which is unable to run RC without it. Our goal here should be compatibility with software. RC MTTR can increase speed significantly in certain situations, but RC there's lots of other ways of doing that for less effort which we RC aren't supporting. MTTR can allow you to work around broken RC hardware. But we can't provide enough kernels to support all RC combinations of broken hardware (I am sure that I could find a RC list of a dozen boolean options which are all needed to be in one RC state or another for various broken hardware - we can't provide RC 2^12 kernels). I think you are wrong about 'MTTR is not really needed'. One good example is aviplay (player for avi files). It perfomance is seriously affected by MTTR option. This fact is mentioned in its docs and I've seen myself *significant* difference in its perfomance when I've compiled kernel with MTTR option. Probably perfomance of simular programs will be affected too. I've played many AVI files without MTRR support. It will still work, just a bit slower. If programs won't run at all (as in the case of MMX and 3DNow!) then we should compile different kernels. If they just don't run as fast then we can let the users compile their own kernels. If you want maximum video speed you want to compile your own kernel with AGP and DRI support etc... Naw, lets just quadruple the number of kernels we have so we can have: 1) kernel without AGP or DRI 2) kernel with AGP and no DRI 3) kernel without AGP with DRI 4) kernel with AGP and with DRI For each of the 30 or so processor revisions that can be compiled for. After all, if half a dozen kernels for the i386 port of debian is OK instead of 1, what's wrong with quadrupling it again? The same arguements apply to that case. Eventually there will be so many kernels that newbies will find it quicker and easier to navigate make xconfig that to navigate dselect. And optimizations aren't just limited to playing AVIs. I recall a few years ago a special version of mpg123 that was optimized for a 486. A 486-33 that could barely play a mono 22.1 K mpeg easily played stereo 44.2 K mpegs with the optimizations, if I recall correctly. We desparately need to include that of course. I'm sure similar optimizations could be added to mpg123 that would reduce processor load on a P4-1ghz by 0.001 % so we need to include that of course. If we are going to recompile everything to get 1% better performance, we should have the guts to split the i386 port into all the little processor families instead of this halfway stuff.
Re: Only one who have parse error in /var/lib/dpkg/available?
On Thu, 26 Apr 2001, Shaul Karl wrote: Yes there is: [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available -rw-r--r--1 root root 2547713 Apr 25 00:46 /var/lib/dpkg/available [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available 11557764 c e 9 1 8 0 f a 4 2 d f \n 11560001 [12:39:42 /tmp]$ and dpkg -l doc-linux-text works too. I do not know what was changed. No, there is no final new line. debian-devel1:/# od -cj 5199880 /var/lib/dpkg/available 23654010 r d . \n \n It looks like the file got truncated. Disk corruption? What apt-cache dumpavail(called from dselect [2]) interrupted?
Re: kernel-{image,headers} package bloat
On Thursday 26 April 2001 08:20, Craig Sanders wrote:
the point at issue is whether there should be dozens of kernel-image and
kernel-headers packages when one is enough to do the job.
I'm just a humble Linux-user, but still compile my own kernel. However, I do
this because I'm also a control-freak, and I like to know what is compiled
into it. I also like to decide /what/ modules I have, instead of everything.
But that's me.
If I understand this correctly, Herbert Xu wants to provide alternate
kernel-* to make it easier for users to run a better suited kernel. However,
doesn't that require the user to know more about his system? I would argue in
/favor/ of the kernel-{helper,custom} package, since if you wanted to use a
custom kernel, you still had to use apt/dselect/whatever to find the correct
image for your system. And if you /REALLY/ want those last drops of
performance, you still need to be something of a wizzard, using powertweak,
or /proc-hacks, or whatever.
If instead, you were able to type something akin to update-kernel or
whatever, and then have a kernel built suited to your arch, but with the
default Debian-options (ie. lotsa modules), wouldn't that be better? I
mean, just make a note to the user, to switch to another console, or minimize
the window in case of X. Then he'll get a kernel freshly built. IMHO, that's
much better. It also means that they only have to download a small update
each time there's a new kernel-release, instead of several megabytes. Dial-up
users should love this.
In the end, I am not sure this matters. Herbert seems to have set his mind
pretty strongly on this. I can't speak on behalf of him, of course, but it
seems that multiple flavours are here to stay, for better or for worse...
Regards
Kenneth
Lightweight Web browsers
Hi, I was looking for a lightweight web browser and I try tried all of those I could get in debs. Unfortunately, neither mozilla nor galeon nor konqueror are satisfactory in terms of memory usage (says less than 10 megs of RAM). However, I found a simple HTML browser called Encompass that takes far less memory than those I mentioned. Of course, it does not have all the feature these browsers can offer but it does handle HTML pretty well. I've build debs you can find there: deb http://people.debian.org/~jerome unofficial/ Tell me if you are interested to see it in debian. Thanks. -- Jérôme Marant
Curious e-mails from yucom.be
Today I received several e-mails that were near duplicates of interactions with the BTS last sunday, both from me and from others. The originals had headers like this (I've trimmed the extraneous stuff): Received: from gecko by master.debian.org with local (Exim 3.12 1 (Debian)) id 14rP8Z-0003SF-00; Sun, 22 Apr 2001 14:03:11 -0500 Received: via spool by [EMAIL PROTECTED] id=B79711.98796614612819 (code B ref 79711); Sun, 22 Apr 2001 19:03:08 GMT The duplicate has: Received: from btbntsys1.yucom.be (yucom.be) [212.8.180.1] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 14sj3f-00054p-00; Thu, 26 Apr 2001 05:31:35 -0500 Received: from mail pickup service by yucom.be with Microsoft SMTPSVC; Thu, 26 Apr 2001 12:27:07 +0200 Received: from murphy.debian.org ([216.234.231.6]) by yucom.be with Microsoft +SMTPSVC(5.5.1877.197.19); Sun, 22 Apr 2001 21:01:12 +0200 Received: (qmail 22943 invoked by uid 38); 22 Apr 2001 19:03:31 - Received: (qmail 22820 invoked from network); 22 Apr 2001 19:03:29 - Received: from master.debian.org ([EMAIL PROTECTED]) by murphy.debian.org with SMTP; 22 Apr 2001 19:03:29 - Received: from gecko by master.debian.org with local (Exim 3.12 1 (Debian)) id 14rP8Z-0003SF-00; Sun, 22 Apr 2001 14:03:11 -0500 Received: via spool by [EMAIL PROTECTED] id=B79711.98796614612819 (code B ref 79711); Sun, 22 Apr 2001 19:03:08 GMT Note that the message id is the same; it just went to yucom.be, who held it for a 4 days and then respewed it back to me at master. Any ideas what's going on? Or how I can make it stop? Thanks, Steve PS Notice that I refrained from making any snide comments about crappy Microsoft mail servers. -- 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: Referring what kernel-images to build to the technical committee?
On Thu, Apr 26, 2001 at 04:15:15PM +0200, Russell Coker wrote: On Thursday 26 April 2001 09:05, Andreas Metzler wrote: _Afair_ it is necessary to run a k6 (or athlon) optimized kernel to use 3DNow! in applications like xmms or lame. This probably applys to ISSE, MTTR and MMX, too. This is not correct. There is software available which only runs with MMX. We should offer a kernel with MMX support which requires Pentium-MMX to support running this. For 3DNow! we should have a kernel which supports it. All kernels, even if compiled with CONFIG_M386, will support MMX and 3DNow. It just won't use memcpy_mmx() or memcpy_3d() as the implementation of memcpy(). The important part is saving the correct number of FP registers, which is done. There is no need for a MTTR specific kernel. Right. You compile kernels with CONFIG_MTRR=y, and the kernel will detect if the processor supports it at run-time. (I am sure that I could find a list of a dozen boolean options which are all needed to be in one state or another for various broken hardware - we can't provide 2^12 kernels). If you were to report this as a kernel bug, it would probably be fixed quickly. i386 CONFIG_ dependencies are designed reasonably enough that you can expect to build one kernel that runs on most hardware (apart from non-arch driver issues.) Also I think that we should have an SMP kernel in the list. We could have one kernel with CONFIG_SMP=y. It doesn't conflict with other things, although this is an option that is likely to be on your list above. CONFIG_M386 is one as well, since the kernel can't use the better locking primitives that appeared in the 486. I'd like to see a single binary kernel (or two, because I'm suspicious about CONFIG_M386), and an easy system that allows you to build one of a set of standard kernels, i.e., a kernel that has everything enabled as modules, but varies in optimized processor, SMP, high memory support, etc. In particular, I don't think it's appropriate (in the idea I'm describing) to present the user with questions such as Do you want APM support? -- compile it in or as a module, and figure it out at run-time. In fact, most of the options could be auto-detected from /proc/cpuinfo. It could also be useful as a hardware tester at install time: Would you like to test your hardware (and get a kernel custom build for your hardware at the same time)? This process will potentially take a long time. (Yes, I realize this idea is a bit crazier than average.) dave...
Re: Only one who have parse error in /var/lib/dpkg/available?
At Thu, 26 Apr 2001 00:14:01 -0500 (CDT),
[EMAIL PROTECTED] wrote:
On Thu, 26 Apr 2001, Shaul Karl wrote:
Yes there is:
[12:36:41 /tmp]$ ls -l /var/lib/dpkg/available
-rw-r--r--1 root root 2547713 Apr 25 00:46
/var/lib/dpkg/available
[12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available
11557764 c e 9 1 8 0 f a 4 2 d f \n
11560001
[12:39:42 /tmp]$
and
dpkg -l doc-linux-text
works too. I do not know what was changed.
No, there is no final new line.
debian-devel1:/# od -cj 5199880 /var/lib/dpkg/available
23654010 r d . \n \n
It looks like the file got truncated. Disk corruption? What apt-cache
dumpavail(called from dselect [2]) interrupted?
I guess it is my fault. Maybe the description of ng-cjk lacks final new-line
like below, and i guess that's the cause.
sed 's/^ /+/' control | grep -A 11 '^Package: ng-cjk$'
Package: ng-cjk
Architecture: any
Depends: ${shlibs:Depends}, ng-common
Description: Nihongo MicroGnuEmacs with CJK support.
+Ng is Nihongo Mg, MicroGnuEmacs. It is a small lightweight Emacs-like
+editor. It can handle both Latin and CJK.
+.
+ng-cjk can handle ISO-2022-JP, Shift-JIS, EUC-JP as well as EUC-KR and
+EUC-CN(GB only). Latin is not supported.
+
Package: ng-cjk-canna
Architecture: any
I'll fix this right now and dupload it.
Thanks,
hirot
pgp0h8bN2Eevh.pgp
Description: PGP signature
Re: Gnome bug 94684
On 26-Apr-01, 06:52 (CDT), Jaldhar H. Vyas [EMAIL PROTECTED] wrote: On 25 Apr 2001, Thomas Bushnell, BSG wrote: Second, I can't keep track of who upstream is for all the Debian packages. Why not? It's in the copyright file of each package. If it isn't--that's a bug. Zhaoway is right that you're a big boy and can talk to upstream developers without having to go through a middleman. Yes, Thomas *could* report the bug upstream. However, he shouldn't have to; one of the Debian developer's jobs is to deal with this kind of stuff, even if dealing with it is only forwarding it upstream and marking it as such in the BTS. Our user's have every right to expect this. 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: auditd as logrotate replacement?
Julian Gilbey wrote: On Wed, Apr 25, 2001 at 08:35:51PM -0300, Alejo Sanchez wrote: well, your version would do it the dlopen() way. actually we were going to ask if there was a restriction on depending on dlopen(), as it could be possible on some non-dynamic plataforms. (no shared libraries, no dl library) You could look at libltdl from the libtool suite. I guess you could always use configure tests to figure this sort of stuff out. Julian I was only asking if release applications from debian are allowed to have dlopen() (even if it isn't used on most situations) AFAIK some OS don't, ie. OpenBSD. Alejo
Re: Referring what kernel-images to build to the technical committee?
Good summary, Sam. I'd like to add a couple extra points: On 25-Apr-01, 19:30 (CDT), Sam Hartman [EMAIL PROTECTED] wrote: Should build custom: Some argumed that users should build a custom kernel and the distribution was doing them a disservice by trying to provide kernels that met their needs. There was also a slightly different argument: That *if* the user needs the slight performance improvement offered by a CPU optimized kernel, then *probably* that user is both capable of building his/her own, *and* would gain further (and possibly more significant) performance benefits by many other choices one could make when configuring a kernel (module vs. non-module, etc.) Confusion: Adding 8 (or whatever it is) variations of each kernel version is going to make it harder to select the appropriate one. There is some fraction of the target audience who won't know what kind of CPU they have, and we don't want to have to add to the Debian installation instructions: Now open your computer's case, and locate the large chip with fans hanging off of it. Write down the numbers and letters on top of the chip. Now look them up in this table to determine the best kernel for your machine. How larget that fraction is I don't know, but I'd wager it was larger than 0. Archive Size: CD Size: Bandwith: Module Multiplication, size, bandwidth: Someone (sorry, forget who) proposed that instead of actually distributing a lot of different stock kernels, we distribute some sort kernel-tuner package that included the various config files and made it easy for a user to build a custom kernel that matched the Debian stock kernel except for CPU specificity (and one could extend this to a matrix of CPU/AGP/DRI choices). Perhaps it could present a menu of choices (pick the things you have) and then select (or generate) the appropriate config file, use make-kpkg to build the new kernel, and then install the new kernel.deb. Yes, it would take longer, but it doesn't have any of the negative impacts on the archive, and it starts the user on the path to custom kernel competency. 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: updating of /etc/rc?.d
[EMAIL PROTECTED] said: What's wrong with adding an exit 0 to the init.d files? dpkg will ask me whether I want to keep my changes each time I upgrade, rather than just overwriting the script. Jason
Re: Debian Afbackup
Salut Stephane Stephane Leclerc schrieb: I've see that you uploaded 13 Apr 2001 a fix version of afbackup. Do you know the status of this package?. I've sent an email to the official maintainer and never got an answer. I don't use afbackup myself, and from what I remember of the changelog (/usr/share/doc/afbackup/changelog.Debian.gz) it's regular maintainer hasn't made an upload for some years. It looks like we have to find a new maintainer for afbackup :(. The .deb is really old, don't works very well and I'll looking for a .deb version of the up to date version. I currently use it directly from the tarball but it's a paint to maintain on many boxes. And on Alpha, it's realy hard to compile. Thanks to let me know. Stef... .. . Linux - Debian - php4 - Apache - MySQL - Infogerance . . email: [EMAIL PROTECTED] - http://www.actionweb.fr . . Tel: (0)141 906 100-Fax: (0)141 906 101. .. ciao, 2ri -- Hardware, n.: The parts of a computer system that can be kicked.
Re: updating of /etc/rc?.d
[EMAIL PROTECTED] said: It is possible to disable a service simply by removing links in /etc/rc*.d . So long as you leave at least one (/etc/rc0.d/K*package would seem to be a good candidate), update-rc.d when called by packages on upgrade is a no-op. Something like: rm /etc/rc*.d/S*package should generally do the trick. That's a good hack, but I still think update-rc.d should support it directly. I was surprised to see portmap restarted after an ugrade when I'd previously done update-rc.d -f remove portmap. At the very least, this should be documented in update-rc.d(8). Note, now that netbase has changed the dependency on portmap to a `suggests' you may remove it anyway. I want portmap and nfs, but I only want them working once a month or so when I need them. Jason
Re: updating of /etc/rc?.d
[EMAIL PROTECTED] said: At the very least, this should be documented in update-rc.d(8). Actually, now that I look again, it is pretty well documented. never mind. Jason
Re: updating of /etc/rc?.d
That's a good hack, but I still think update-rc.d should support it directly. I was surprised to see portmap restarted after an ugrade when I'd previously done update-rc.d -f remove portmap. That was my feeling, that most users would probably wonder why it was started again.
Storage (8*IDE HDs) any experiences?
Hi all I notice there are these new-fangled motherboards with 2*ATA-100 and 2*ATA-33 ports. With 75GB disks, that baby should give us 600GB of raw disk space (8 drives) at around $2K US. Sounds attractive, considering that el-cheapo RAID boxes of similar capacity are around $10K. Anyone runs [Debian] Linux on an 8-drive box like that? Is that supported at all? Any gotchas I should know about? The mobo I'm looking at is ABIT BH6-II. TIA Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key Well, lusers are technically human. -- Red Drag Diva in ASR
Re: RFC: Thoughts on building modules
Herbert == Herbert Xu [EMAIL PROTECTED] writes: Herbert BTW, this is how the kernel images are organised on Herbert alpha/i386/sparc. This is misleading. The kernel-image-*-arch packages are much simpler because they do not depend both on a kernel source package and on a module deb package. Also, note that this maximizes work for the module maintainer, which is a valid thing to do, although I'd like to note that we seem to get a much better balance for other porting issues. Finally, it means that I cannot release a module for a new arch without package-installation access to that arch. It's my understanding that source-only uploads only work if there is an existing binary package that depends on the source package being installed, which is not the case for new package source uploads.
Formal request for review: [Sam Hartman hartmans@debian.org] Referring what kernel-images to build to the technical committee?
Hi. I posted the following message to debian-devel last night and have received agreement with the summary and apparently (it was not explicitly stated) with the committee as a forum from Craig and Herbert. Thus I'd like to ask you to look at this issue. There has been some other discussion in the thread that the following message starts and others have brought up some issues I did not cover in my summary. I recommend reading this discussion. If there are any administrative hoops I need to jump through please let me know. --- Start of forwarded message --- Resent-Date: Wed, 25 Apr 2001 20:30:46 -0400 (EDT) Date: Wed, 25 Apr 2001 20:30:31 -0400 (EDT) Message-Id: [EMAIL PROTECTED] To: debian-devel@lists.debian.org CC: [EMAIL PROTECTED], [EMAIL PROTECTED] (module package maintainers), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (kernel-image-i386 maintainer), [EMAIL PROTECTED] (concerned about package size) Subject: Referring what kernel-images to build to the technical committee? Reply-to: debian-devel@lists.debian.org From: Sam Hartman [EMAIL PROTECTED] Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel@lists.debian.org Resent-Sender: [EMAIL PROTECTED] [cc list is an attempt at stakeholders for this issue. If I missed people, I'm sorry. If I annoyed people by ccing them even though they read the list, well I'm sorry too, but there are a fair number of people who tend to want to be explicitly cc'd when an issue pertains to them.] Summary: Herbert has started building 8 different flavors of kernel-image for i386. These flavors correspond to CPU type; for example there is an appropriate kernel for people with 386 machines to run and an appropriate kernel for people with Athlon machines to run. Several concerns have been brought up on debian-devel, and while I believe that discussion has identified the tradeoffs involved, I do not believe we have reached consensus on a direction to follow. While Herbert is the maintainer of the kernel image for i386,I believe the implications of this issue extend far beyond his packages and thus this is an issue where the interests of different developers may come into conflict. Herbert's changes affect those who maintain module packages like ALSA, PCMCIA, I2C and Openafs. OSome have claimed these decisions affect the installation by CDs by taking up a significant chunk of a CD. Concerns were raised about the bandwith and archive space implications. I believe that since debian-devel doesn't seem to be able to come to consensus on this issue, we should refer the issue to a smaller group than will fairly consider all the tradeoffs involved and come up with a global direction for the project on this issue. One concern I have with Herbert's decision is that the i386 architecture is taking what appears to be a different direction than other architectures. I'd rather have a global direction than have each architecture go off and do their own thing. Naturally, the tradeoffs may affect different architcetures differently, so we may end up with a different set of kernel images for each architecture, but the relative weights of the tradeoffs and our overall goals could be decided globally. I propose the technical committee as an appropriate form to decide on this issue, but I am open to other fora. I'd like to summarize my understanding of the tradeoffs that we have identified in the debian-devel discussion so that if we do turn this issue over to the committee, they will know what concerns we have already identified. Please add to the following list if I have missed something. Note that I'm not trying to weight the tradeoffs here; I'm trying to be fairly objective. Comments of the form That's not important, are not appropriate at this time. cThe goal is to identify the issues and let whatever group we send this to evaluate the weights of the issues. Presumably such a group would ask for public comment on the weightings if they would find that comment useful. performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. Encouraging stock kernel use: By having appropriate stock kernels that meet people's needs we may encourage users to use the kernels. This provides better/more consistent testing of our configurationas well as easier upgrade. Herbert indicated that previosly he did not even use his own kernel image packages because they were not optmized. This should be considered separately from performance, because even if there is not a significant performance win, if many more users would use the stock kernel, the advantages of doing so might justify the change. That is, the perception of whether optimized kernels are needed influences whether people use them and the value of this
Re: libc6 broken?
On Thu, Apr 26, 2001 at 12:28:51PM +0200, Ulrich Wiederhold wrote: If I try a ./configure or a make xconfig with a new Kernel, I get this error-msg: /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' /lib/libc.so.6: undefined reference to [EMAIL PROTECTED]' Uh, why do you have libc 2.2.3? We don't have libc 2.2.3 in the archive. -- Taral [EMAIL PROTECTED] Please use PGP/GPG encryption to send me mail. Any technology, no matter how primitive, is magic to those who don't understand it. -- Florence Ambrose pgpxKn6AQmsgr.pgp Description: PGP signature
Re: Only one who have parse error in /var/lib/dpkg/available?
On Thu, 26 Apr 2001, Shaul Karl wrote: Yes there is: [12:36:41 /tmp]$ ls -l /var/lib/dpkg/available -rw-r--r--1 root root 2547713 Apr 25 00:46 /var/lib/dpkg/available [12:39:36 /tmp]$ od -cj 2547700 /var/lib/dpkg/available 11557764 c e 9 1 8 0 f a 4 2 d f \n 11560001 [12:39:42 /tmp]$ and dpkg -l doc-linux-text works too. I do not know what was changed. No, there is no final new line. debian-devel1:/# od -cj 5199880 /var/lib/dpkg/available 23654010 r d . \n \n It looks like the file got truncated. Disk corruption? What apt-cache dumpavail(called from dselect [2]) interrupted? I am not sure but the reason could also be a problem with a local server. At least for now, after an apt-get update from another server, it looks O.K: 1) The size of the file has grown a lot. 2) Now there is the terminating \n\n. [22:49:47 /tmp]$ od -cj 4462910 /var/lib/dpkg/available 21014476 f o r m s . \n \n 21014507 [22:52:04 /tmp]$ 3) The Description is the last field. I will watch it. Thank you for the help. -- Shaul Karl [EMAIL PROTECTED]
Re: Referring what kernel-images to build to the technical committee?
On Thursday 26 April 2001 18:19, David Schleef wrote: For 3DNow! we should have a kernel which supports it. All kernels, even if compiled with CONFIG_M386, will support MMX and 3DNow. It just won't use memcpy_mmx() or memcpy_3d() as the implementation of memcpy(). The important part is saving the correct number of FP registers, which is done. There is no need for a MTTR specific kernel. Right. You compile kernels with CONFIG_MTRR=y, and the kernel will detect if the processor supports it at run-time. So a 386 compiled kernel can still support MMX, 3DNow! and MTRR? In that case we only need a 386 kernel, but it might be nice to have a PentiumMMX compiled kernel as well (that should give better performance on all brands of CPU that are better than 486). (I am sure that I could find a list of a dozen boolean options which are all needed to be in one state or another for various broken hardware - we can't provide 2^12 kernels). If you were to report this as a kernel bug, it would probably be fixed quickly. i386 CONFIG_ dependencies are designed reasonably enough that you can expect to build one kernel that runs on most hardware (apart from non-arch driver issues.) I am thinking of the various IDE options for dealing with broken drives and controllers, PCI Quirks, etc. These things will break some machines when set one way and break other machines on the other setting. I'd like to see a single binary kernel (or two, because I'm suspicious about CONFIG_M386), and an easy system that allows you to build one of a set of standard kernels, i.e., a kernel that has everything enabled as modules, but varies in optimized processor, SMP, high memory support, etc. In particular, I don't think it's appropriate (in the idea I'm describing) to present the user with questions such as Do you want APM support? -- compile it in or as a module, and figure it out at run-time. In fact, most of the options could be auto-detected from /proc/cpuinfo. So we ship half the kernel as binary and compile the other half after installation? Sounds terrible. Why not just compile custom kernels for every user? It wouldn't be that difficult to write a script that asks a dozen easy questions, checks the /proc data, and then compiles an optimised kernel. -- 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
Formal request for review: [Sam Hartman hartmans@debian.org] Referring what kernel-images to build to the technical committee?
Hi. I posted the following message to debian-devel last night and have received agreement with the summary and apparently (it was not explicitly stated) with the committee as a forum from Craig and Herbert. Thus I'd like to ask you to look at this issue. There has been some other discussion in the thread that the following message starts and others have brought up some issues I did not cover in my summary. I recommend reading this discussion. If there are any administrative hoops I need to jump through please let me know. --- Start of forwarded message --- Resent-Date: Wed, 25 Apr 2001 20:30:46 -0400 (EDT) Date: Wed, 25 Apr 2001 20:30:31 -0400 (EDT) Message-Id: [EMAIL PROTECTED] To: debian-devel@lists.debian.org CC: [EMAIL PROTECTED], [EMAIL PROTECTED] (module package maintainers), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (kernel-image-i386 maintainer), [EMAIL PROTECTED] (concerned about package size) Subject: Referring what kernel-images to build to the technical committee? Reply-to: debian-devel@lists.debian.org From: Sam Hartman [EMAIL PROTECTED] Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel@lists.debian.org Resent-Sender: [EMAIL PROTECTED] [cc list is an attempt at stakeholders for this issue. If I missed people, I'm sorry. If I annoyed people by ccing them even though they read the list, well I'm sorry too, but there are a fair number of people who tend to want to be explicitly cc'd when an issue pertains to them.] Summary: Herbert has started building 8 different flavors of kernel-image for i386. These flavors correspond to CPU type; for example there is an appropriate kernel for people with 386 machines to run and an appropriate kernel for people with Athlon machines to run. Several concerns have been brought up on debian-devel, and while I believe that discussion has identified the tradeoffs involved, I do not believe we have reached consensus on a direction to follow. While Herbert is the maintainer of the kernel image for i386,I believe the implications of this issue extend far beyond his packages and thus this is an issue where the interests of different developers may come into conflict. Herbert's changes affect those who maintain module packages like ALSA, PCMCIA, I2C and Openafs. OSome have claimed these decisions affect the installation by CDs by taking up a significant chunk of a CD. Concerns were raised about the bandwith and archive space implications. I believe that since debian-devel doesn't seem to be able to come to consensus on this issue, we should refer the issue to a smaller group than will fairly consider all the tradeoffs involved and come up with a global direction for the project on this issue. One concern I have with Herbert's decision is that the i386 architecture is taking what appears to be a different direction than other architectures. I'd rather have a global direction than have each architecture go off and do their own thing. Naturally, the tradeoffs may affect different architcetures differently, so we may end up with a different set of kernel images for each architecture, but the relative weights of the tradeoffs and our overall goals could be decided globally. I propose the technical committee as an appropriate form to decide on this issue, but I am open to other fora. I'd like to summarize my understanding of the tradeoffs that we have identified in the debian-devel discussion so that if we do turn this issue over to the committee, they will know what concerns we have already identified. Please add to the following list if I have missed something. Note that I'm not trying to weight the tradeoffs here; I'm trying to be fairly objective. Comments of the form That's not important, are not appropriate at this time. cThe goal is to identify the issues and let whatever group we send this to evaluate the weights of the issues. Presumably such a group would ask for public comment on the weightings if they would find that comment useful. performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. Encouraging stock kernel use: By having appropriate stock kernels that meet people's needs we may encourage users to use the kernels. This provides better/more consistent testing of our configurationas well as easier upgrade. Herbert indicated that previosly he did not even use his own kernel image packages because they were not optmized. This should be considered separately from performance, because even if there is not a significant performance win, if many more users would use the stock kernel, the advantages of doing so might justify the change. That is, the perception of whether optimized kernels are needed influences whether people use them and the value of this
Re: Referring what kernel-images to build to the technical committee?
On Thu, Apr 26, 2001 at 10:13:01PM +0200, Russell Coker wrote: So a 386 compiled kernel can still support MMX, 3DNow! and MTRR? In that case we only need a 386 kernel, but it might be nice to have a PentiumMMX compiled kernel as well (that should give better performance on all brands of CPU that are better than 486). Except that the PentiumMMX kernel won't run on a Pentium -- it uses MMX instructions for memcpy(). (I now ramble into things I only slightly remember, so please check before believing...) I think the general consensus is that the original Pentium instruction ordering is best all-around, whereas PentiumPro is the worst. I am thinking of the various IDE options for dealing with broken drives and controllers, PCI Quirks, etc. These things will break some machines when set one way and break other machines on the other setting. I haven't heard of many problems like this recently. But I'm sure there will be such bugs during the lifetime of 2.4. So we ship half the kernel as binary and compile the other half after installation? Sounds terrible. Why not just compile custom kernels for every user? (Yes, that doesn sound terrible.) No, I meant to ship and install one standard complete kernel. If the user wants to run the automatic kernel optimisation script and compile a new kernel, cool. But the idea is to make it as simple as Do you want an optimized kernel? It wouldn't be that difficult to write a script that asks a dozen easy questions, checks the /proc data, and then compiles an optimised kernel. I tend to think that asking fewer questions is better -- a script will better know how to optimise the kernel for someone that is unprepared. And the people that want more configuration options should be compiling their own kernels anyway. dave...
New X problems...
I finally get my X system back into working order, find out I have memory problems with my kernel and upgraded to the 2.2.19. Now, when I bring up and xterm or a bash window, I get no cursor and no keystrokes appear in the window. I'm also having very flaky problems with mozilla not being able to get into simple web pages and download material. (I'm trying to get the current LSB spec) At this point I can't tell whether this has something to do with my new kernel, or is caused by something else. I'm pretty sure that once I got things working the last time, I used an xterm with no problems, so my suspicions lie heavily with the new kernel. Anyone have any ideas? Thanks, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: auditd as logrotate replacement?
On Apr 26, Alejo Sanchez [EMAIL PROTECTED] wrote: I was only asking if release applications from debian are allowed to have dlopen() (even if it isn't used on most situations) The patched mutt 1.2.x I maintain for debian does exactly this to support SSL and kerberos. -- ciao, Marco
Re: Referring what kernel-images to build to the technical committee?
Steve Greenland [EMAIL PROTECTED] wrote:
Confusion: Adding 8 (or whatever it is) variations of each kernel
version is going to make it harder to select the appropriate one. There
is some fraction of the target audience who won't know what kind of CPU
they have, and we don't want to have to add to the Debian installation
instructions:
Now open your computer's case, and locate the large chip with fans
hanging off of it. Write down the numbers and letters on top of the
chip. Now look them up in this table to determine the best kernel
for your machine.
There is a file called /proc/cpuinfo you know.
--
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: RFC: Thoughts on building modules
Sam Hartman [EMAIL PROTECTED] wrote:
This is misleading. The kernel-image-*-arch packages are much simpler
because they do not depend both on a kernel source package and on a
module deb package. Also, note that this maximizes work for the
How does that make it more complex?
issues. Finally, it means that I cannot release a module for a new
arch without package-installation access to that arch. It's my
understanding that source-only uploads only work if there is an
existing binary package that depends on the source package being
installed, which is not the case for new package source uploads.
Well, kernels/modules have traditionally required this kind of access.
There's no way around it I'm afraid.
--
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
