Preparation of Debian GNU/Linux 3.0r2 (II)
Preparation of Debian GNU/Linux 3.0r2 = An up-to-date version is at http://master.debian.org/~joey/3.0r2/. I am preparing the second revision of the current stable Debian distribution (woody) which will probably be released soon. This report is to allow people to comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future. An ftpmaster still has to give the final approval for each package since they are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. If it is a kernel package, I can detect a similar amount of packages to remove, preferably older versions of the new packages. It is ((1 OR 2 OR 3) AND 4) OR 5 Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. acm stable5.0-3 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source acm updates 5.0-3.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 333 - integer overflow apcupsd stable3.8.5-1.1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source apcupsd updates 3.8.5-1.1.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 277 - buffer overflows, format string aspell-en stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc aspell stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc source libaspell-dev stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc libaspell10stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc The license incorrectly says that it's LGPL but it is in fact a unique license which is non-DFSG-free. atftpd stable0.6 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc atftpd updates 0.6.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc atftp stable0.6 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source atftp updates 0.6.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 314 - buffer overflow autorespond stable2.0.2-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source autorespond updates 2.0.2-2woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 373 - buffer overflow balsa stable1.2.4-2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source balsa updates 1.2.4-2.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 300 - buffer overflow bind-devstable1:8.3.3-0.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind-devupdates 1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind-docstable1:8.3.3-0.woody.1 all bind-docupdates 1:8.3.3-2.0woody1 all bindstable1:8.3.3-0.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bindupdates 1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 196 - several vulnerabilities bugzilla-doc stable2.14.2-0woody2 all bugzilla-doc updates 2.14.2-0woody4 all
Cherche DD pour signature de clé sur 25/90/68/70
Tout ça pour dire que devenir DD, c'est bien, mais se taper 250 bornes pour faire signer sa clé, ça me parait pas terrible ... Y aurait-il un DD dans les régions sus-citées ? -- .,p***=b_ Nicolas Rueff ?P .__ `*b Montbéliard - France |P .d?'`, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] | `#?_._oH' +33 6 77 64 44 80 `H. ``' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated. -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/E/IT d- s:- a24? C++ UL+++$ P++ L !E W+++ N++ o? K- w-- !O M- V-- !PS !PE !Y PGP+++ t+ 5 X+ R* tv++ b DI++ D++ G++ e+++ h r- y++ --END GEEK CODE BLOCK-- pgpumDCFUX0uH.pgp Description: PGP signature
Re: Cherche DD pour signature de clé sur 25/90/68/70
Nicolas Rueff [EMAIL PROTECTED] wrote: Yo, Tout ça pour dire que devenir DD, c'est bien, mais se taper 250 bornes pour faire signer sa clé, ça me parait pas terrible ... Y aurait-il un DD dans les régions sus-citées ? Oui. Je suis à Belfort en semaine et à Colmar le week-end. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Re: Cherche DD pour signature de clé sur 25/90/68/70
On Tue, Nov 11, 2003 at 02:27:38PM +0100, Julien BLACHE wrote: Nicolas Rueff [EMAIL PROTECTED] wrote: Yo, Tout ça pour dire que devenir DD, c'est bien, mais se taper 250 bornes pour faire signer sa clé, ça me parait pas terrible ... Y aurait-il un DD dans les régions sus-citées ? Oui. Je suis à Belfort en semaine et à Colmar le week-end. Moi je suis sur Strasbourg, mais je peut me deplacer eventuellement. Je crois que Raphael est aussi sur le sud de l'alsace. Amicalement, Sven Luther
Re: Cherche DD pour signature de clé sur 25/90/68/70
Le Tuesday 11 November 2003, Nicolas Rueff écrit : Tout ça pour dire que devenir DD, c'est bien, mais se taper 250 bornes pour faire signer sa clé, ça me parait pas terrible ... Y aurait-il un DD dans les régions sus-citées ? Quant à moi, je sur sur Mulhouse et travail à l'EuroAirPort. Nicolas -- pgpQUDJtOBZGA.pgp Description: PGP signature
Re: Cherche DD pour signature de clé sur 25/90/68/70
Ainsi parla Nicolas Rueff le 315ème jour de l'an 2003: Tout ça pour dire que devenir DD, c'est bien, mais se taper 250 bornes pour faire signer sa clé, ça me parait pas terrible ... Y aurait-il un DD dans les régions sus-citées ? Après avoir reçu quelques réponses, une question m'est venue (Aahh, l'éternel quête de connaissances ...). Existe-t-il un site géolocalisant précisément les DD ? Ou ai-je eu une idée révolutionnaire, ce qui m'étonnerait vu mon déficit de sommeil ;) -- .,p***=b_ Nicolas Rueff ?P .__ `*b Montbéliard - France |P .d?'`, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] | `#?_._oH' +33 6 77 64 44 80 `H. ``' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated. -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/E/IT d- s:- a24? C++ UL+++$ P++ L !E W+++ N++ o? K- w-- !O M- V-- !PS !PE !Y PGP+++ t+ 5 X+ R* tv++ b DI++ D++ G++ e+++ h r- y++ --END GEEK CODE BLOCK-- pgpyAtpc0QZMv.pgp Description: PGP signature
Re: Cherche DD pour signature de clé sur 25/90/68/70
On Wednesday November 12 2003 05:21, Sven Luther wrote: Moi je suis sur Strasbourg, mais je peut me deplacer eventuellement. Je crois que Raphael est aussi sur le sud de l'alsace. Moi je suis sur Okazaki, mais je peux me déplacer sur Nagoya assez facilement. Comment-ça je sors ? Mike
Re: libc6-i686 only for 2.6 kernels? was: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, 2003-11-11 at 15:29, Daniel Jacobowitz wrote: On Tue, Nov 11, 2003 at 05:08:16AM +0100, Dagfinn Ilmari Mannsåker wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Mon, Nov 10, 2003 at 07:17:13PM -0800, Mike Fedyk wrote: On Sat, Nov 08, 2003 at 06:43:09PM +0100, Robert Millan wrote: And Nikita just pointed out there's libc6-i686. It might make sense to add linux-i686 too. I'm open for discussing that, but this discussion doesn't belong on the ITP bug. And why is it only for 2.6 kernels? The processor specific package should support NPTL, and it doesn't require 2.6... That sentence is contradictory - NPTL requires 2.6. But there should be a non-NPTL i686-optimized libc6 too, as in /lib/i686/cmov/ in addtion to the current /lib/tls/i686/cmov/. Gotta draw the line somewhere. We chose to draw it there. Building glibc four times on x86 hardware seems to be a bit excessive for our needs. How long does a glibc compile take? Eg., would just basic i386 binaries, with say a -builder version (or script - anything remotely along the lines of gentoo), be a better way to optimize packages? For example: optimize-build --auto-detect-current-platform --arch i686 --no-mmx my-package-that-really-needs-maximum-optimization Packages (such as kernel, glibc, gimp) could optionally provide a hints file with optmized build recommendations (+'ve as well as -'ve) which could be overridden, etc. (I haven't used or looked at gentoo, so I don't know if what I am saying is plain silly or not ...) Such a scheme would have the advantages of: - minimizing debian repo size (no custom optimized binary packages) - optimal optimization as opposed to lcd/lowest denominator optimize and at least the disadvantages of: - not so simple to get optimized build (although possibly could configure to auto optimize some packages) - optimized-build local packaging scripts would need to be written (ie. it doesn't yet exist) There are surely more (dis)advantages not on the top of my head... cheers zen
ftpmaster accepts packages that have been rejected a few days ago
Hi, since more than a few months, I am maintainer of the linux-atm package. I have used that package for my work until june, when I changed jobs. I have put up the package for adoption, but continue to maintain it until someone else offers to take it. I don't think that I am doing too bad a job of maintaining linux-atm, but it surely is not low-maintenance compared to my other packages. However, I have spent too much time for Debian and this package for the waste-basket because ftpmaster recently decided to give me the finger. In early November, people asked me to package br2684ctl, a new program that has not been officially released by the linux-atm upstream. So I would have to pull br2684ctl from upstream CVS and include it in my package that contains released software only. I was very reluctant to do so, but agreed when people convinced me that br2684ctl is useful for a lot of people and threaten to package it themselves. I thought that it would be a bad idea to have two source packages from the same upstream. But I decided to put br2684ctl into its own .deb to be able to distinguish between unreleased development software and released software versions. After spending too much time with packaging (br2684's addition to the build toolchain required a lot of learning about autoconf, automake and libtool), I finally uploaded to experimental. I had to wait almost three weeks to have the package REJECTED by ftpmaster, incarnated by James Troup. He was unusually polite, but the mail exchange ended with him announcing that Well, sorry, but I'm personally not prepared to add (overrides for) a package to unstable with nothing but an 8k binary and a 1k manpage. He consented with having private e-mail published, which I really appreciate. This is not the first time that I have had a package rejected for being too small, giving myself the impression that my work is not appreciated by Debian. Maybe I don't add enough bloat to my packages? Bringing the linux-atm source package into a state that allows building br2684ctl locally why not automatically building it was another half day of fighting with automake. Well, to make things short, the people who asked me to include br2684ctl with linux-atm have prepared their own package - of course still only consisting of an 8k binary and a 1k manpage and uploaded to unstable. This time, the package was promptly ACCEPTed in a matter of days (http://lists.debian.org/debian-devel-changes/2003/debian-devel-changes-200311/msg00760.html). I am currently tempted to stop wasting time for Debian since I obviously don't have a chance of getting new packages into the archive since I usually work on small but useful things. I don't know if ftpmaster has a personal problem with me or doubts my skills and qualification, but I simply don't appreciate working for the waste basket. I don't have enough spare time to afford this. Even if this is not a personal issue of Mr. Troup towards me, having ftpmaster behave like A today and like B tomorrow is a bad thing. If I had a chance of knowing beforehand if a package uploaded will be handled by Mr. Troup or somebody else, there would be a chance of being handled fairly, but if the ftpmasters obviously don't communicate with each other, and if there won't be a method of getting ftpmaster's opionion about a new package before any more time is wasted, maintainers will continue to be chased away, which is a loss for Debian. I would like to ask other maintainers: What would you do if you have had packages repeatedly rejected while others get the very same packages (wasting even more archive space because upstream source is multiplied) accepted without problems? Retire? Stop uploading? Asking other people to upload for you? Try to be more submissive towards powerful people on un-electable posts? Any comments will be appeciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Kernel 2.4.22-k7-1: initrd cannot mount proc from cramfs image
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Found the thread about init/cramfs, this seems a different issue.] I installed the kernel-image-2.4.22-1-k7 package on an Asus L3355M laptop, but it won't boot, giving the same kernel panic with both lilo and grub. Relevant parameters for lilo: boot=/dev/hda root=/dev/hda5 # compact install=/boot/boot-menu.b map=/boot/map image=/boot/vmlinuz-2.4.22-1-k7 label=linux initrd=/boot/initrd.img-2.4.22-1-k7 read-only Relevant parameters for grub: title Debian GNU/Linux, kernel 2.4.22-1-k7 root(hd0,4) kernel /boot/vmlinuz-2.4.22-1-k7 root=/dev/hda5 ro initrd /boot/initrd.img-2.4.22-1-k7 boot Here are the last lines on the screen before the panic: RAMDISK: cramfs filesystem found at block 0 RAMDISK: Loading 3532 blocks [1 disk] into ram disk... done. Freeing initrd memory: 3532k freed VFS: mounted root (cramfs filesystem). mount: Usage: mount [-t filesystemtype] [-o options,...] device mountpoint This is a builtin command. /etc/fstab and /etc/mtab are NOT supported. cat: No file proc/sys/kernel/real-root-dev. /linuxrc: cannot create proc/sys/kernel/real-root-dev: directory nonexistent VFS: Cannot open root device hda5 or 03:05 Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on 03:05 Having mounted the initrd cramfs image with the command # mount /boot/initrd.img-2.4.22-1-k7 /initrd -o loop the contents of the linuxrc script are: #!/bin/sh # # $Id: linuxrc,v 1.7 2003/08/05 10:14:01 herbert Exp $ export PATH=/sbin:/bin mount -nt proc proc proc root=$(cat proc/sys/kernel/real-root-dev) echo 256 proc/sys/kernel/real-root-dev umount -n proc mount -nt tmpfs tmpfs tmp || mount -nt ramfs ramfs tmp echo $root tmp/root It looks like it cannot mount the proc filesystem. The command # /initrd/bin/mount --help includes a mention of the -n parameter, so that may not be the problem. Adding the boot parameter devfs=mount to grub results in the following added line, but still no joy: - --- 01.txt2003-11-11 08:20:43.0 +0100 +++ 02.txt 2003-11-11 08:21:08.0 +0100 @@ -2,6 +2,7 @@ RAMDISK: Loading 3532 blocks [1 disk] into ram disk... done. Freeing initrd memory: 3532k freed VFS: mounted root (cramfs filesystem). +Mounted devfs on /dev mount: Usage: mount [-t filesystemtype] [-o options,...] device mountpoint This is a builtin command. /etc/fstab and /etc/mtab are NOT supported. Any hint about what to look for? Thanks. - -- The open-source movement seems on the verge of winning its bid to define the computing infrastructure of tomorrow - and the core of that infrastructure will be Unix machines running on the Internet. -- Eric S. Raymond Nicola Larosa - [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/sJS7Xv0hgDImBm4RAun6AKC+JB/mXYP/sgEXAFGe8J5nAd/1gACfY/c1 iNRSjTTqIfG36dEjMAzpOaY= =gG5z -END PGP SIGNATURE-
Re: ftpmaster accepts packages that have been rejected a few days ago
On Tue, Nov 11, 2003 at 08:18:51AM +0100, Marc Haber wrote: Even if this is not a personal issue of Mr. Troup towards me, having ftpmaster behave like A today and like B tomorrow is a bad thing. If I There's more than one person behind ftpmaster. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Latest version of fvwm packaged
Hi, The development branch of fvwm is nearing a stable release, and has had a huge number of new features. The maintainer has been very reluctant to package this branch, even in a people.debian.org repository, so I decided to package FVWM 2.5.8 for myself; and I have decided to share this with others as well. The packages are lintian clean, and can be found at: deb http://people.debian.org/~srivasta/ packages/ deb-src http://people.debian.org/~srivasta/ packages/source/ There have been significant new features in the 2.5.X series, and just the GNOME 2 compatibility should be enough to require this in Sarge. These packages were configured as follows (I see no reason not to allow rplay and xrender compatibility in fvwm). As you can see below, I have included as many of the features as I could. manoj ./configure --build i386-linux \ --prefix=/usr\ --sysconfdir=/etc/X11/fvwm\ --libexecdir=/usr/lib\ --mandir=/usr/share/man --with-stroke-library\ --enable-multibyte FVWM Configuration: Version: 2.5.8 Executables: /usr/bin Man pages: /usr/share/man Modules: /usr/lib/fvwm/2.5.8 Data files: /usr/share/fvwm Perl lib:/usr/share/fvwm/perllib Locale msg: /usr/share/locale ar de fr sv_SE With Asian bi-direct. text support? yes With Gettext Native Lang Support? yes (libc) With GTK+ required for FvwmGtk? yes With GDK image support in FvwmGtk? no: Failed on gdk-imlib, see config.log With GNOME libs support in FvwmGtk? no: Can't find working gnome-config With PNG image support? yes With ReadLine sup. in FvwmConsole? yes With RPlay support in FvwmEvent?yes With Shaped window support? yes With Shared memory for XImage? yes With Session Management support?yes With Mouse strokes (gestures)? yes With Xinerama multi-head support? yes With Xft anti-alias font support? yes (version 2) With XPM image support? yes With Xrender image support? yes -- Hold still while I flame you. Karl Lehenbauer Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Latest version of fvwm packaged
Manoj Srivastava [EMAIL PROTECTED] [2003-11-11 09:58]: Hi, The development branch of fvwm is nearing a stable release, and has had a huge number of new features. The maintainer has been very reluctant to package this branch, even in a people.debian.org repository, so I decided to package FVWM 2.5.8 for myself; and I have decided to share this with others as well. The packages are lintian clean, and can be found at: deb http://people.debian.org/~srivasta/ packages/ deb-src http://people.debian.org/~srivasta/ packages/source/ There have been significant new features in the 2.5.X series, and just the GNOME 2 compatibility should be enough to require this in Sarge. These packages were configured as follows (I see no reason not to allow rplay and xrender compatibility in fvwm). As you can see below, I have included as many of the features as I could. can I simply update to the new packages by inserting the deb-statements into my /etc/apt/sources.list ? I'm running unstable. Thanks for any help. wbr, Lukas -- Lukas Ruf | Wanna know anything about raw | http://www.lpr.ch | IP? http://www.rawip.org |
Re: possible compromise for ITP: linux?
Eike Sauer [EMAIL PROTECTED] wrote: Andrew Suffield schrieb: [...] - this packages adds nothing, and would occupy a fair chunk of space in the archive. I don't know how short Debian is of space. How large would Robert's packages be? ~30MB for linux_2.4.22.orig.tar.gz and a single Kernel-Image is ~9MB on i386. Multiply the latter by the number of supported architectures. There already are several packages with complete kernel sources which take as much place as his package would, right? [...] Robert does not propose to remove the existing kernel-source packages therefore the calculation is simple - more than 100MB required space in exchange for ...? cu andreas
Re: radiusd-freeradius history and future
On Sun, Jan 12, 2003 at 01:21:53PM -0500, Chad Miller wrote: [cc debian-devel] On Sun, Jan 12, 2003 at 05:07:41PM +0100, Toni Mueller wrote: [...] Who withdrew [radiusd-freeradius] or caused it's withdrewal, then? Curious minds want to know, and also, it's a bit misty right now... (...) A few months ago, the Sarge release coordinator swept all gravely-buggy- older-than-3?-months packages from sid, including radiusd-freeradius. Wichert immediately asked for the package to be added back, but someone noted that freeradius, a GPL program, linked against libssl, so it couldn't go back in. What is the current status of this issue? There are yet no radiusd-freeradius (or freeradius) packages either in sid or (even) in ftp://ftp.freeradius.org/pub/radius/. The issue on SSL linking (described in DWN [1]) doesn't look as it is has been fixed and the debian/ directory in the CVS has not seen any change for quite some time (+5 months) Anyone? Regards Javi [1] http://www.debian.org/News/weekly/2003/02/
Re: Latest version of fvwm packaged
On Tue, Nov 11, 2003 at 02:39:15AM -0600, Manoj Srivastava wrote: The development branch of fvwm is nearing a stable release, and has had a huge number of new features. The maintainer has been very reluctant to package this branch, even in a people.debian.org repository, so I decided to package FVWM 2.5.8 for myself; and I have decided to share this with others as well. The packages are lintian clean, and can be found at: deb http://people.debian.org/~srivasta/ packages/ deb-src http://people.debian.org/~srivasta/ packages/source/ cool... hehe :)) -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: ftpmaster accepts packages that have been rejected a few days ago
On Tue, Nov 11, 2003 at 08:16:23AM +, Mark Brown wrote: On Tue, Nov 11, 2003 at 08:18:51AM +0100, Marc Haber wrote: Even if this is not a personal issue of Mr. Troup towards me, having ftpmaster behave like A today and like B tomorrow is a bad thing. If I There's more than one person behind ftpmaster. Obviously this is one more case of lack of communication within the Debian Project. -- Rico -mc- Gloeckner | 1024D/61F05B8C | jabber:[EMAIL PROTECTED] http://www.ukeer.de |RICO-RIPE | sip:[EMAIL PROTECTED] == mv ~/.signature http://www.ukeer.de/signature.html ==
Re: [SSI-devel] development direction...
Hello all, I'm Cc:-ing debian-devel The original thread is at http://sourceforge.net/mailarchive/message.php?msg_id=6473235 The question is whether there are any processes within the Debian project that could eliminate the obstacles Aneesh pointed out to us. Regs, Csan (I'm not subscribed to debian-devel, please Cc: me) Idzs Aneesh Kumar KV [EMAIL PROTECTED]: Watson, Brian J. (HP) wrote: Csan wrote: Just curious... have you considered migrating to the Debian Project as a base? Aneesh Kumar has historically maintained Debian support for openSSI. Unfortunately, he hasn't had much time recently, so it's fallen a bit out-of-date. Mario Carvalho has volunteered to help pick up some of the slack. I think he's more interested in built-from-scratch vanilla distros, which may not be dramatically different from Debian. He's probably waiting for me to respond to some of his e-mails before moving forward on this. ;) If anyone else would like to contribute to Debian support, I'm sure Aneesh and Mario would appreciate it. Debian is lacking the below features 1) Phase 2 of clusterwide run level support 2) Latest openssi patches with vanilla tree ( probably not important for x86 user ), because some of the command now depends on the latest features in the kernel. In case anybody need any help in understanding how things work now feel free to ask me. -aneesh -- ph: 603-884-5742 Csan alias Janos Holanyi Debian Group leader - Association of Hungarian Linux Users URL: http://debian.linux.hu/ Email: csani AT lme.linux.hu gpg --keyserver hkp://pgp.mit.edu --recv-keys 82CBB661
Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86
On Mon, Nov 10, 2003 at 10:53:42PM -0500, Branden Robinson wrote: On Sun, Nov 09, 2003 at 03:12:19PM +0100, Mattia Dongili wrote: * Package name: xfree86-driver-synaptics Please be sure to mention in the package description that this is a driver module *for* the XFree86 X server, not a driver module *from* the XFree86 Project, Inc. Description : Synaptics TouchPad driver for XFree86 I recommend Synaptics TouchPad driver for XFree86 X server. An input driver for the XFree86 X server to enable advanced features of the Synaptics Touchpad including: This is a sentence fragment, no matter how many things you list next. :) I suggest changing the beginning of the sentence to This package provides an input driver Hehe, ok! approved :) thanks again for your support (I'll subscribe to debian-x for a bunch of more questions) -- mattia :wq! pgpPV5tBONkHL.pgp Description: PGP signature
RE: ftpmaster accepts packages that have been rejected a few days ago
Mark Brown wrote: On Tue, Nov 11, 2003 at 08:18:51AM +0100, Marc Haber wrote: Even if this is not a personal issue of Mr. Troup towards me, having ftpmaster behave like A today and like B tomorrow is a bad thing. If I There's more than one person behind ftpmaster. Obviously, he knows that: Marc Haber wrote: Even if this is not a personal issue of Mr. Troup towards me, having ftpmaster behave like A today and like B tomorrow is a bad thing. If I had a chance of knowing beforehand if a package uploaded will be handled by Mr. Troup or somebody else, there would be a chance of being handled fairly, but if the ftpmasters obviously don't communicate with each other [...]
Re: create new Debian-Kernel project (was: ITP: linux -- Linux 2.4 kernel)
On Mon, Nov 10, 2003 at 05:11:45PM +0100, Eduard Bloch wrote: 'linux' is a perfect name for the package. The tarballs contain that very name. Note that the name is choosen not only to attract the user, but also to catch that who blindly use apt-get source linux. The user wouldn't get the well-known and good kernel-source packages but something which is under control of Robert. Further, what they would get is not a clean source but something with debian/ dir inside which would confuse make-kpkg. I would not mind if he had called it linux-rmh or such. That means you find 99% of packages in Debian to be unclean. Now it's your turn to start a crusade to solve that problem. But don't start with me. Are you implying that you make up names for the software that you package, rather than use the name given to it by upstream? I believe you don't. Ah, that is a good base to start a discussion. Of course it is better to keep the upstreams name but make exceptions if they are too generic, to confusing or to offensive (though we did already accept such ones, eg. pornview ;)). As I said before, you should discuss this with upstream. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Why you are wrong [Was: On linux kernel packaging issue]
On Mon, Nov 10, 2003 at 05:08:48PM -0600, Joe Wreschnig wrote: Of course, I'm far from a compiler and chip design expert (or even novice); this is what I remember from my classes last year. :) But it shows how complicated optimizing compilers can get, and why you can't say any optimization is always good/safe/faster/etc. The only truly safe way to tell is extensive, controlled benchmarking. An optimisation that makes things unsafe or slower isn't an optimisation. The compiler shouldn't produce any code that is incorrect or slower. Of course, it can't stop you from taking a P4-optimised binary and running it on an Athlon. I think you could say that any optimisation is safe and not slower; otherwise it's not an optimisation. The job of compiling for modern processors does seem daunting (especially VLIW architectures like ia64). Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: ftpmaster accepts packages that have been rejected a few days ago
Marc Haber [EMAIL PROTECTED] writes: I had to wait almost three weeks to have the package REJECTED by ftpmaster 20031023144719~jennifer~Moving to new~linux-atm_2.4.1-10_i386.changes 20031103144602~lisa~rejected~linux-atm_2.4.1-10_i386.changes Hmm, that doesn't even look like 2 weeks to me... but hey, who needs facts when you're flaming, right? Any comments will be appeciated. In the series of mails that followed the initial REJECT, I said (in [EMAIL PROTECTED]): | If you disagree with that, you can either try your luck with another | ftp-master or get rough consensus on debian-devel that I'm wrong. -- James
Re: Why you are wrong [Was: On linux kernel packaging issue]
On Monday 10 Nov 2003 19:54, Andrew Suffield wrote: We refuse to accept it blindly because it's wrong. There have been cases when architecture-specific optimisations have made programs run slower (recently the instruction ordering for that via i686 chip comes to mind); GCC gets it wrong from time to time, and there's no reason to think it's currently right (since everybody who asserts it is has failed to provide anything but circumstancial evidence, and we all know that software sucks). Don't all these arguments apply to architecture independent optimizations also? Incidentally, your standard of proof There have been cases is pretty weak, I would say there have been cases where architectural optimizations have increased performance.
Re: Kernel 2.4.22-k7-1: initrd cannot mount proc from cramfs image
Nicola Larosa [EMAIL PROTECTED] wrote:
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 3532 blocks [1 disk] into ram disk... done.
Freeing initrd memory: 3532k freed
VFS: mounted root (cramfs filesystem).
mount: Usage: mount [-t filesystemtype] [-o options,...] device mountpoint
This is a builtin command. /etc/fstab and /etc/mtab are NOT supported.
If you're using busybox then try regenerating the initrd image with
BUSYBOX=no.
--
Debian GNU/Linux 3.0 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: ftpmaster accepts packages that have been rejected a few days ago
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc Haber [EMAIL PROTECTED] wrote: James Troup. He was unusually polite, but the mail exchange ended with him announcing that Well, sorry, but I'm personally not prepared to add (overrides for) a package to unstable with nothing but an 8k binary and a 1k manpage. [...] This is not the first time that I have had a package rejected for being too small, giving myself the impression that my work is not appreciated by Debian. Maybe I don't add enough bloat to my packages? Maybe you split too much? ;-) Bringing the linux-atm source package into a state that allows building br2684ctl locally why not automatically building it was another half day of fighting with automake. Well, to make things short, the people who asked me to include br2684ctl with linux-atm have prepared their own package - of course still only consisting of an 8k binary and a 1k manpage and uploaded to unstable. This time, the package was promptly ACCEPTed in a matter of days (http://lists.debian.org/debian-devel-changes/2003/debian-devel-changes-200311/msg00760.html). [...] Even if this is not a personal issue of Mr. Troup towards me, having ftpmaster behave like A today and like B tomorrow is a bad thing. If I had a chance of knowing beforehand if a package uploaded will be handled by Mr. Troup or somebody else, there would be a chance of being handled fairly, but if the ftpmasters obviously don't communicate with each other, and if there won't be a method of getting ftpmaster's opionion about a new package before any more time is wasted, maintainers will continue to be chased away, which is a loss for Debian. [...] As you were asking for opinions: I do think it is ok for ftpmaster to reject the package, imho the rationale for the split to distinguish between unreleased development software and released software versions. is a little bit weak. However the inconsistency that another member of the ftp-master team accepted an identical package later is a really bad thing. cu andreas, who does not want you to stop your Debian work for evident reasons. - -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/sLijHTOcZYuNdmMRAl1EAJ4pfTFRpKQ2yxYwpm5llsmwItgdmgCfba4w 4zYhEZKbzda4EIIZ9RpvcW0= =kWCb -END PGP SIGNATURE-
Re: ftpmaster accepts packages that have been rejected a few days ago
On Tue, 11 Nov 2003 10:33:33 +, James Troup [EMAIL PROTECTED] wrote: In the series of mails that followed the initial REJECT, I said (in [EMAIL PROTECTED]): | If you disagree with that, you can either try your luck with another | ftp-master or get rough consensus on debian-devel that I'm wrong. It is usual that people who dare to question your judgment get flamed on -devel. I have had my share of that. No, thank you. You are the secret Boss of the project. You control who gets accounts, has her key in the key ring, and you control what gets into the archive. So, if you say no, the Debian doesn't want your work, that's the official voice of the project. And if you say well done, thanks for your contribution a week later to another DD having duplicated the effort that was already done, that's - again - the official voice. The official voice saying go fsck yourself to the first DD. This is bad. It is a pity that you still behave like you consider /dev/random a significant part of your daily operation. This is doing great harm to the project, and it is scaring skilled people away on a daily basis. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 01:35:29PM +, Matthew Garrett wrote: I'm so scared. wchan won't be displayable! What were you saying about sarcasm? The fact remains that it's a bug, You're going outside the scope of the question. Someone argued the way System.map is upgraded is a dessign problem, but it's just a bug. and it's a bug that you should already have thought of. I don't see why. I have a bunch of resources to find a solution for this trivial bug. Put simply, if this is the level of research you've done, I don't think you're suitable for packaging something as important as the kernel. I'm not suitable because my package has a trivial bug? Sorry, but you're not entitled to put my skills in question. I don't see why should I address that. But don't worry, if it turns out there's a reason to, I'm pretty capable of solving it. Because it's a bug, and if you're going to maintain your packages then you need to address bugs. Is getting wchan displayable a reason to solve the System.map issue? If it is, I'll solve it. But I haven't seen anyone explaining what is wchan useful for at all. It give me the impression that you are just using bugs as an excuse for trolling me, but when it comes to actualy discuss them all you have to say is I'm incompetent. You're mixing trivial maintainer issues with this ITP. It's very pity of you if you're doing it on purpose. No, I'm saying that you're proposing to package a major piece of infrastructure and give it a name that may attract users into installing it, and the amount of thought and consideration that you seem to have put in is insufficiently large for me to consider that it'll do anything other than convince people that Debian kernel packagers are on crack. Which would, again, be bad. My amount of thought and consideration will apply when I get bug reports through the BTS. Untill that happens, I refuse to use the ITP log as your particular BTS for flaming me. Specialy if all the bugs you can came up with are ridiculous ones with trivial fix. Which brings back the question on wether you're looking for bugs on purpose just for the sake of trolling. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: possible compromise for ITP: linux?
On Mon, 10 Nov 2003, Adam Heath wrote: On Tue, 11 Nov 2003, Santiago Vila wrote: If Robert is such an incompetent developer as some people say and the package does not build on the 11 different architectures, then the package will not propagate to testing and the world will be safe from the disaster. You misunderstand how testing works. If a *new* package doesn't build on some arch, it won't be held up from testing because of it. It's only when an *existing* package that *previously* built on some arch, and now it doesn't, that testing will ignore it. You are right. I missed that little detail. But anyway you can submit a serious FTBFS bug if that happens to be the case. Do the testing scripts ignore serious bugs?
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 02:23:52PM +, Colin Watson wrote: On Mon, Nov 10, 2003 at 12:03:38PM +0100, Robert Millan wrote: On Sun, Nov 09, 2003 at 08:33:00PM +, Matthew Garrett wrote: klogd will be unable to look up symbols, and ps and top need it for wchan to be displayable. I'm so scared. wchan won't be displayable! As a prospective maintainer of an important package, it ill behooves you to make fun of legitimate bug reports. No, you're confused. I don't blame you because you probably missed where the whole System.map discussion came from. As I just told to Matthew, someone claimed that my package has a dessign problem in the way it deals with System.map upgrades. But it actualy resulted that it's just a bug that prevents wchan from being displayable. I can fix that bug without much trouble. I'm not making fun of bug reports. Rather, I laugh at people who pretend I'm incompetent because my package has a trivial bug, or who pretend the dessign of my package is broken in a way that I can't solve such trivial bugs. In particular, klogd not being able to look up symbols means that you and upstream will get less useful bug reports when the kernel oopses. Thanks Colin, at last someone cared to give me positive feedback. I'll fix the System.map issue. How do you propose to do that without changing the package name, and without leaving old System.map junk around for eternity? I don't see how it can be possible. (This is exactly the same question as Matthew asked, of course; but it is an important question relative to this ITP and I want to see it answered.) I don't like turning this ITP into a technical discussion to prove either my dessign is consistent or I'm capable as a maintainer. However I'll respond to your question this time: Place the package files in /usr/lib, and copy them conditionaly (debconf) into /boot. The debconf question would properly explain that if per chooses to update it, then the system must be rebooted promptly. Another option: Place the package files in /boot, but save a backup of them before (preinst). Then prompt the user to reboot through debconf. Or even a combination of the two. You're mixing trivial maintainer issues with this ITP. It's very pity of you if you're doing it on purpose. You're proposing a packaging scheme where the package name is not changed for new kernel versions. It is entirely legitimate for people to bring up potential problems with this scheme. I'm disappointed that you feel it necessary to brush them off just to railroad your proposal through. I don't feel it necessary. But this is not the first trivial maintainer issue I'm being pointed at in this ITP, and I'm getting the impression that some people are doing it deliberately. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: libc6-i686 only for 2.6 kernels? was: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, 11 Nov 2003 14:28, Isaac To wrote: Unless one patch the kernel to support all the things like .pid files in /proc, futex, O(1) scheduler, ... (i.e., as in the 2.4 kernel of Redhat). I have been seriously considering a kernel-patch-2.4-redhat package which contains a patch with everything from the Red Hat enterprise kernel. This would (among other things) offer a solution to the performance issues with 4G RAM machines discussed recently on debian-isp. Currently I haven't got time, but it's on my to-do list. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages 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/~russell/ My home page
Re: ftpmaster accepts packages that have been rejected a few days ago
On Tue, Nov 11, 2003 at 11:54:26AM +0100, Marc Haber wrote: On Tue, 11 Nov 2003 10:33:33 +, James Troup [EMAIL PROTECTED] wrote: In the series of mails that followed the initial REJECT, I said (in [EMAIL PROTECTED]): | If you disagree with that, you can either try your luck with another | ftp-master or get rough consensus on debian-devel that I'm wrong. It is usual that people who dare to question your judgment get flamed on -devel. Actually, the people who get flamed are the ones that say self-evidently stupid things. I have had my share of that. No, thank you. You are the secret Boss of the project. And with paranoid fantasies like that, is it any wonder you've had your share? For reference, the distribution of packages wrt Installed-Size looks like: .- number of packages | . size of package, rounded down to nearest power of two (in kB) v v 9 0 - 1 3 2 7 4 92 8 218 16 928 32 2499 64 2565 128 2077 256 1711 512 1270 1024 870 2048 610 4096 295 8192 209 16384 60 32768 16 65536 3 131072 [0] Generally, it's much better to put related programs together into a single package than distribute them separately, even if that offends your aesthetic sensibilities. The whole point of Debian is to put the awkwardness of finding the right tools for the jobs into the hands of a competent maintainer, rather than passing it on to our users. Servers, rather than tools, can be a different matter. Large programs can be a different matter too. Packages below a certain size, probably 15-30kB are generally more of a nuisance to keep around separately than to merge into a related package. Cheers, aj [0] cat Packages_i386 | grep ^Installed-Size | cut -d\ -f2 | perl -nle 'print $_ ? 2**int(log($_)/log(2)) : 0;' | sort -n | uniq -c -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgpb5WeZYZWf5.pgp Description: PGP signature
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 07:50:54PM +, Andrew Suffield wrote: On Mon, Nov 10, 2003 at 11:58:46AM +0100, Robert Millan wrote: On Sun, Nov 09, 2003 at 10:43:49PM +0100, Eduard Bloch wrote: 1) You said before you were concerned about my package occupiing the package namespace in the archive. The fact that you don't like the name of my package proves your previous argument was intentionaly bogus. The fact of the too generic package name was mentioned before within other arguments against your linux package. How many software programs called linux are around? Dozens. Lots of people have created variations on the theme of linux. Does your response imply that variations on the theme of linux and programs called linux are the same thing? If it does, I clarify that my question does not. Which means your response is irrelevant. If it doesn't, tell me which are these dozens I never heard about them. You're not even talking about packaging the one released from kernel.org, you're talking about creating your own fork (vis. patches to make it work on different architectures). Read my debian/copyright file. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 04:34:16PM +0100, Eduard Bloch wrote:
Thanks for addressing this. Well, it is in
[EMAIL PROTECTED] - instead of answering what
actually justifies that name, there is only another subset of {look in
the first proposal|look at Herbert agreeing (vague)|there are others who
support me so stop wasting my time}.
You're very confused. I don't need a single person supporting me to prove
my package has advantages. The fact that Herbert and others supported me
is just an added value.
The relevant part of my mail was look in the first proposal. And I'm
still waiting for a link to a part of the discussion that:
1) Claims my pretended advantages are inconsistent.
2) Is not clarified by me in a response.
When you find it (if there is such), I'll simply find what is wrong in that
claim and point it out. All I've seen so far in these messages is a bogus
smoke curtain.
This is what i've been doing all along this thread and I can keep doing it for
weeks, or months.
Why cannot you invent something new to convince us?
As I said before I'm unwilling to understand your sarcasm.
Oh Robert... Faster detection of sarcasm demonstrates how good someone
understands the stuff in question.
That might imply I'm incompetent. Fortunately, I don't have to prove my
competence for you.
--
Robert Millan
[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.
-- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 07:57:12AM -0800, A.J. Rossini wrote: Why does the lack of response from Herbert prove that this package is a bad idea? I'm saddened that you have to revert to intimidation in place of a technical argument. Herbert did respond with a single message, somewhat positively if I recall. Check the archives on this thread. Indeed. And I don't mind linking to it for the nth time: http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00452.html -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: ftpmaster accepts packages that have been rejected a few days ago
On Tue, 2003-11-11 at 10:54, Marc Haber wrote: | If you disagree with that, you can either try your luck with another | ftp-master or get rough consensus on debian-devel that I'm wrong. You are the secret Boss of the project. You control who gets accounts, has her key in the key ring, and you control what gets into the archive. So, if you say no, the Debian doesn't want your work, that's the official voice of the project. And if you say well done, thanks for your contribution a week later to another DD having duplicated the effort that was already done, that's - again - the official voice. The official voice saying go fsck yourself to the first DD. This is bad. Personally I don't see James as the 'official voice' of the Debian project. It's a bit presumptuous of you to assume that it's him being inconsistent in applying his rules. He's not. If you had actually *READ* the email you quoted you'd have noticed that it was me who accepted the br2684ctl package. It is a pity that you still behave like you consider /dev/random a significant part of your daily operation. This is doing great harm to the project, and it is scaring skilled people away on a daily basis. If the presence of more than one person behind a *TASK ADDRESS* can be considered /dev/random, then perhaps you should strike out against all the people who maintain packages in groups. I admit that if I'd remembered the br2684ctl - linux-atm link, I possibly wouldn't have accepted the package, however as James stated in his email: * Well, sorry, but I'm personally not prepared to add (overrides for) * a package to unstable with nothing but an 8k binary and a 1k * manpage. He personally wasn't prepared to add the package. He didn't prevent you trying to get other opinions on the matter though. Your package was rejected for being too small to warrant being split out from the linux-atm package. With no direct way to reference the br2684ctl package to the linux-atm package when I came to process some NEW packages last night, I applied common sense to the upload I had in front of me and accepted it. When linux-atm gets to the point that the br2684ctl program is sufficiently stable to be included in the main package, I invite you to file a bug requesting that the br2684ctl source package be removed, having been obsoleted by the linux-atm package. We have procedures in place to handle all this, perhaps it's time you learnt to use those, instead of whining about things which aren't even the case. Regards, Daniel Silverstone (the FTP master who appears to have inadvertantly confused you) -- Daniel Silverstone http://www.digital-scurf.org/ Hostmaster, Webmaster, and Chief Code Wibbler: Digital-Scurf Unlimited GPG Public key available from keyring.debian.org KeyId: 20687895
Bug#220199: ITP: mecab -- a Japanese Morphological Analysis System
Package: wnpp Severity: wishlist * Package name: mecab Version : 0.76 Upstream Author : Taku Kudo [EMAIL PROTECTED] * URL or Web page : http://cl.aist-nara.ac.jp/~taku-ku/software/mecab/ * License : LGPL Description : a Japanese Morphological Analysis System Mecab is a morphological analysys system. It can segment and tokenize Japanese text string, and can output with many additional informations (pronunciation, semantic information, and others). It will print the result of such an operation to the standard output, so that it can either written to a file or further processed. A first version of the package is available at http://namazu.org/~tsuchiya/debian/mecab/ -- TSUCHIYA Masatoshi
Re: Why you are wrong [Was: On linux kernel packaging issue]
On Tue, Nov 11, 2003 at 09:24:35PM +1100, Hamish Moffatt wrote: On Mon, Nov 10, 2003 at 05:08:48PM -0600, Joe Wreschnig wrote: Of course, I'm far from a compiler and chip design expert (or even novice); this is what I remember from my classes last year. :) But it shows how complicated optimizing compilers can get, and why you can't say any optimization is always good/safe/faster/etc. The only truly safe way to tell is extensive, controlled benchmarking. An optimisation that makes things unsafe or slower isn't an optimisation. The compiler shouldn't produce any code that is incorrect or slower. Of course, it can't stop you from taking a P4-optimised binary and running it on an Athlon. I think you could say that any optimisation is safe and not slower; otherwise it's not an optimisation. Mmm. -ffast-math and -funsafe-math-optimizations, off the top of my head. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Why you are wrong [Was: On linux kernel packaging issue]
On Tue, Nov 11, 2003 at 10:19:58AM +, Will Newton wrote: On Monday 10 Nov 2003 19:54, Andrew Suffield wrote: We refuse to accept it blindly because it's wrong. There have been cases when architecture-specific optimisations have made programs run slower (recently the instruction ordering for that via i686 chip comes to mind); GCC gets it wrong from time to time, and there's no reason to think it's currently right (since everybody who asserts it is has failed to provide anything but circumstancial evidence, and we all know that software sucks). Don't all these arguments apply to architecture independent optimizations also? Yes. And actually, those have the same problem. We blithely use -O2 for most things, but in fact -Os can be faster on some processors with some programs (-O3, on the other hand, can often make things worse). However, the status quo wins out here again. We'd need compelling evidence to go around changing from -O2 to -Os. Meanwhile, we *do* have compelling evidence that -O2 is usually better than -O0, and furthermore we have evidence that it breaks in some cases, leading some packages to be compiled with different sets of optimisation flags. Incidentally, your standard of proof There have been cases is pretty weak, I would say there have been cases where architectural optimizations have increased performance. You're making the exact same mistake that I was describing. Basic predicate logic: Let the statement under test be For all X, p(X) is true. What I said is: Let there be a value A such that p(A) is false. The statement is therefore false. What you are saying is: Let there be a value B such that p(B) is true. This neither proves nor disproves the statement under test. However, it proves this different statement: There exists an X such that p(X) is true. Be very careful about the difference between For all and There exists. It is parallel to the difference between and and or. Here is my point again, in terms of semiformal logic: Let X be a program and p(X) be the predicate X runs faster with this set of optimisations. Now, For all X, p(X) is true leads us to conclude that we should apply these optimisations to all programs, while There exists an X such that p(X) is true leads us to ask For what values of X?, and apply those optimisations to just those programs. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: using freedesktop.org libs
On Tue, Nov 11, 2003 at 01:14:30AM +0100, Michel D?nzer wrote: I found this idea very interesting. I think that the debian project should take more advantage of the freedesktop.org libs. Glancing briefly at the packages in sid, we've been using the ones they have released for a while. Unreleased libraries do not belong in unstable. It's not about released vs. unreleased but XFree86 vs. freedesktop.org. Presumably you think freedesktop.org will do a better job of maintaining them. So why are you so eager to use things which they say aren't ready for release, if you trust their skills so much? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: create new Debian-Kernel project (was: ITP: linux -- Linux 2.4 kernel)
This one time, at band camp, Eduard Bloch wrote: #include hallo.h * Jamie Wilkinson [Mon, Nov 10 2003, 06:54:22PM]: The fact of the too generic package name was mentioned before within other arguments against your linux package. IIRC you prefered not to answer to it but refered to an URL which did not contain the answers. 'linux' is a perfect name for the package. The tarballs contain that very name. Note that the name is choosen not only to attract the user, but also to catch that who blindly use apt-get source linux. The user wouldn't get the well-known and good kernel-source packages but something which is under control of Robert. Further, what they would get is not a clean source but something with debian/ dir inside which would confuse make-kpkg. I would not mind if he had called it linux-rmh or such. I do not understand your point, you are trying to protect users who inadvertently type apt-get source linux? When I type apt-get source pppoeconf, do I not get the source to the Debian package of ppoeconf? Why should it be any different? I'm not convinced that people type apt-get source x inadvertently either. Your second sentence is flagrant abuse, and its tone seems common in your attempts at constructing a reasoned argument. Please try to keep civil, Eduard. I trust your ability to maintain your packages, as I trust everyone else in this project, at least until I see the product of their work. Confusing make-kpkg would be an issue, I suppose -- given that one could want to get any kernel source and build it with the tools they're familiar with. If it were me, I'd make sure to include some extra information in the package README. 2) I use the upstream name. If you don't like it, bitch upstream. Sorry, how much did you drink to find an answer like this one? If Linus changes the package name (which is unlikely to happen ;)), I am sure you would rename your ITP to follow him. Are you implying that you make up names for the software that you package, rather than use the name given to it by upstream? I believe you don't. Ah, that is a good base to start a discussion. Of course it is better to keep the upstreams name but make exceptions if they are too generic, to confusing or to offensive (though we did already accept such ones, eg. pornview ;)). I concur that packages have been renamed where their name is too generic, such as verbs and short nouns (one of my earliest packages, imgstamp, was originally named 'stamp' and rejected). However, this is the word 'linux'. What else do you think it could possibly refer to? -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, A.J. Rossini wrote: Jamie Wilkinson [EMAIL PROTECTED] writes: This one time, at band camp, Eduard Bloch wrote: You repeat this again and again and got answers from me and others to such an ultimate argument. But did you ask yourself why Herbert does not participiate this discussion to help you? Why does the lack of response from Herbert prove that this package is a bad idea? I'm saddened that you have to revert to intimidation in place of a technical argument. Herbert did respond with a single message, somewhat positively if I recall. Check the archives on this thread. You are entirely correct but alas this datapoint is irrelevant. I'm not convinced that lack of participation of one party constitutes proof. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Andrew Suffield wrote: On Mon, Nov 10, 2003 at 11:58:46AM +0100, Robert Millan wrote: On Sun, Nov 09, 2003 at 10:43:49PM +0100, Eduard Bloch wrote: 1) You said before you were concerned about my package occupiing the package namespace in the archive. The fact that you don't like the name of my package proves your previous argument was intentionaly bogus. The fact of the too generic package name was mentioned before within other arguments against your linux package. How many software programs called linux are around? Dozens. Lots of people have created variations on the theme of linux. You're not even talking about packaging the one released from kernel.org, you're talking about creating your own fork (vis. patches to make it work on different architectures). In the context of Debian, does that make software such as 'larch' and 'blootbot' forks of their upstream? Of course not. There are already several forks of the Linux kernel in Debian anyway. Robert wishes to attempt to unify them, does that not grant him use of the name 'linux'? -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 10:32:11AM -0500, Lukas Geyer wrote: Robert Millan [EMAIL PROTECTED] writes: apt-get source kernel-image-* doesn't bring me the real source. Instead, if I want the real source I must be root and install a binary package. Do you deny that this is confusing? I don't understand why you must be root, could you elaborate? I am no expert in Debian kernel packaging, but why not fetch the source of kernel-image-*, see what kernel-patch-* packages it depends on and get the source of them and kernel-source-*? Yes, but that's even more confusing. It is not what I would do, as I build my kernels with make-kpkg, but it doesn't seem impossible. To a new user this will all be confusing, but they should not compile their own kernels anyway. It would be confusing to anyone who isn't experienced with it. Making it a standard Debian package makes it easy to be understood for developers who are not familiar with that. But this is my discussion. If I don't take part in it, who will respond to all these bogus arguments some people enjoy sending in? Rather, this is you and the other trolls who are wasting my time. Yeah, sure, if 90% of the people disagree with you, they must all be trolls. Reminds me of that guy on the wrong lane on the highway... Again, I haven't said that. But I won't discuss over this. Now do go ahead and do tell me that the packaging is easy to understand. Define easy then, because with the information I have at hand the only reasonable interpretation is easy for Robert Millan to understand. It's easy for people who are already used to Debian de-facto standards. Since I am and you're not [1], that makes a difference. Therefore don't expect to understand it. [1] Your reasoning shows either you're not used to them, or you're plainly trolling. I'll assume the first at your convenience. What makes you think that Marcelo doesn't use Debian standards? Do you have any evidence or is this just trolling on your side? A package that adheres to Debian de-facto standards is easy to understand for people who are used to Debian de-facto standards. Marcelo pretends my package, which adheres to Debian de-facto standards, is not easy to understand. Therefore, his reasoning shows he's either not used to them, or plainly trolling. Some people publicly said in this thread they like the package. Many more stated the opposite opinion, but I guess you see them all as trolls. I don't. But you're abusing my references to trolling. Herbert said he likes it at least as an experiment. I got other private mails from well-known developers who like my proposal and pity your trolling attempts. Yeah, anonymous sources, and what does well-known mean? The cabal? People who hold an opinion on this and don't weigh in publicly can't be accounted for. That's right. Btw, you cut-off the line above in the same paragraph: Some people publicly said in this thread they like the package. Since when do we package everything and then see if it makes the popularity contest? In my opinion you are adding to archive bloat and this package should not hit unstable. Once it is there, it will take ages until it gets removed. Why not upload to experimental or such and if Herbert really likes it, then at some point it can replace the current kernel packages. I still see a lot of substantial problems, in particular the removal of the old kernel on upgrade. I never remove an old kernel before I have thoroughly tested the new one. Last example where this was necessary was the vanilla 2.4.22 which leads to hard lock-ups after suspend from sleep on this iBook. Not unusable but pretty annoying, and always good to have an older kernel to boot into handy. As I said before, I don't mind uploading to experimental is there's a consensus on that. As for the updating issue, I just sent an explanation on how I can deal with that in response to Colin (but the mail is not archived yet). So you want to add to the archive bloat? Just to have the Linux kernel as a standard Debian package? So should we all start repackaging our favorite applications where the maintainer packaging or default configuration or compiler options are not to our taste? I hope you would not want that, but I see your package doing exactly that for the kernel. I have the maintainer's consentment, so it makes sense to me. Why is that wasting time? It is called quality assurance, first of all trying to keep non-needed stuff out of the archive, second (at least in my opinion) to make sure the maintainers understand their packages. (For the record, I consider your repeated statement that Herbert is the real maintainer and you are only the packaging monkey a quite lame excuse. I don't want Debian maintainers to be just repackagers, not for upstream, not for another maintainer.) When one of your bugs is caused by a Build-Dependency on another package, does
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 08:31:39AM -0600, Steve Greenland wrote: But you haven't responded to any of the *legitimate* arguments, except to say they're bogus, and that you solve them by ignoring them. That implies all my responses merely claim they're bogus. It's very easy to pretend that, but I disagree. Rather, this is you and the other trolls who are wasting my time. No, they're a bunch of experienced Debian developers trying to explain, in the face of overwhelming willful ignorance, *why* the kernel packages are set up the way they are, and why what you're wanting to do is a bad idea. I didn't claim all of them are trolling. But a few of them are. Also IIRC I haven't put in question their experience as developers. dpkg-buildpackage That doesn't give me the source, except by side effect, and I don't want to have to build the package just to get the source. (Yes, I'm well aware that there are other ways to see the source, but you didn't answer the question as stated.) You're directing your question to the wrong place. This doesn't apply only to my package, but to all Debian packages. So if there is a flaw on this (which I don't think there is) it applies to the rest of Debian. And since there are a couple of these hacks floating around, how to get the unpacked patched source is non-obvious. It's as easy as in the rest of packages in Debian, no more, no less: Read debian/rules. No, most of the packages in Debian give me the source with a simple 'dpkg-source -x'. No rules file reading necessary. Not that many, actualy. An important number of them apply patches dynamicaly either directly or after unpacking upstream sources. It's easy for people who are already used to Debian de-facto standards. Since I am and you're not [1], that makes a difference. Therefore don't expect to understand it. [1] Your reasoning shows either you're not used to them, or you're plainly trolling. I'll assume the first at your convenience. CDBS is *NOT* a de-facto standard, When I said de-facto standards I didn't refer to CDBS. There's currently no de-facto standard for debian/rules files, although there are a bunch of attempts at becoming one (and CDBS is one of them). I responded to this before. We don't provide the Linux kernel packaged as a standard Debian package. apt-get install kernel-image-2.4-386 That's not standard. Do you apt-get install bash-image-2-386, or apt-get install bash-source-2? But certainly, you must be very scared of that possiblity, since you're wasting your time and inventing bogus arguments just to prevent it from even being in Debian at all. The people objecting to your proposal have no vested interest in anything except a working Debian distribution. Your package is inherently likely to lead to breakage and confusion. I agree that my package is in an experimental and inmature stage, if that's what you mean. Uploading to experimental instead of unstable is an option, renaming to linux-experimental as Colin pointed is an option, too. I accept to do one of these if there's a clear consensus. Are you just completely incapable of conceiving or admitting that you've made a mistake, and that you need to solve the problems being presented rather than just ignoring them and insulting people by assuming that they're making personal attacks? Actualy, I recall making some mistakes in this thread, and rectifiing. I don't recall insulting people, unless you think troll is an insult. Less risky? That's interesting. If you have some suggestions, perhaps you can help me improve my package. Oh, that's a hoot, since you've been ignoring or belittling every one who has been trying to improve it. I haven't ignored anyone. As for belittling, it only applies to those who found dessign problems which actualy don't exist. Of course it does. Tell me what is inconsistent in my list of advantages. (And please, don't repeat the same arguments over again). Which is it? Do you want the answer, or are you going to continue to ignore the answer? Your question implies I have ignored someone's argument, which AFAIK isn't true. If you are going to claim otherwise, provide a link to it. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 07:25:41PM +, Andrew Suffield wrote: On Sun, Nov 09, 2003 at 08:17:58PM +0100, Robert Millan wrote: - I'm not trying to make a package, the package is already made and it works fine. I'm using it right now. Okay, please don't write software or maintain any packages. I can't think of anything more indicative of total inexperience than it works fine. That's subjective. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Matthew Garrett wrote: Robert Millan wrote: On Sun, Nov 09, 2003 at 08:33:00PM +, Matthew Garrett wrote: klogd will be unable to look up symbols, and ps and top need it for wchan to be displayable. I'm so scared. wchan won't be displayable! What were you saying about sarcasm? The fact remains that it's a bug, and it's a bug that you should already have thought of. Put simply, if this is the level of research you've done, I don't think you're suitable for packaging something as important as the kernel. This doesn't mean that you shouldn't do it (as an academic exercise it'd be a wonderful learning experience, and lessons learned may be well applied else where) - I just don't think it should go anywhere near the archive. Bollocks. Kernels install /boot/System.map-$version. There's a symlink from /boot/System.map to the current version. You are told you need to reboot after installing a kernel package. How much more research is there that needs to be done for this particular issue? It looks to me like you're harping on a single issue which would have been encountered during the process of making this package, and based on this Robert is suddenly a second-class maintainer? If everyone in this project had to get the right answer first time, there would be a lot fewer maintainers and a lot fewer bugs in the BTS. You're mixing trivial maintainer issues with this ITP. It's very pity of you if you're doing it on purpose. No, I'm saying that you're proposing to package a major piece of infrastructure and give it a name that may attract users into installing it, and the amount of thought and consideration that you seem to have put in is insufficiently large for me to consider that it'll do anything other than convince people that Debian kernel packagers are on crack. Which would, again, be bad. I'd reiterate that you're implying Robert is going to make a half-arsed attempt and upload something he hasn't tested, but I've already said that. Besides, it's already evident that Debian maintainers (as a superset of kernel packagers) are on crack. -- This thread scores 3 Trogdors out of a possible 5 for flamability.
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Robert Millan wrote: Place the package files in /usr/lib, and copy them conditionaly (debconf) into /boot. The debconf question would properly explain that if per chooses to update it, then the system must be rebooted promptly. Another option: Place the package files in /boot, but save a backup of them before (preinst). Then prompt the user to reboot through debconf. Or even a combination of the two. A third method may involve a rc script that makes sure the correct version of System.map is installed. Then the only time kernel symbols are not found is between the package upgrade and just after the next reboot. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Why you are wrong [Was: On linux kernel packaging issue]
On Tue, 11 Nov 2003, Andrew Suffield wrote: On Tue, Nov 11, 2003 at 09:24:35PM +1100, Hamish Moffatt wrote: On Mon, Nov 10, 2003 at 05:08:48PM -0600, Joe Wreschnig wrote: Of course, I'm far from a compiler and chip design expert (or even novice); this is what I remember from my classes last year. :) But it shows how complicated optimizing compilers can get, and why you can't say any optimization is always good/safe/faster/etc. The only truly safe way to tell is extensive, controlled benchmarking. An optimisation that makes things unsafe or slower isn't an optimisation. The compiler shouldn't produce any code that is incorrect or slower. Of course, it can't stop you from taking a P4-optimised binary and running it on an Athlon. I think you could say that any optimisation is safe and not slower; otherwise it's not an optimisation. Mmm. -ffast-math and -funsafe-math-optimizations, off the top of my head. or -fstrict-aliasing, which won't work with waaay too much code out there, including (from warnings I see) a lot of kernel-level stuff, such as alsa. I must remember to start filing bugs everywhere I see those warnings. Ugh. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Matthew Garrett wrote: Jamie Wilkinson wrote: I do not expect Robert's package to make any more of an attempt to convince you a reboot is required than any of the other kernel packages. The current kernel packages include the version number in the package name, whereas Robert seems to be suggesting that his package would maintain the same name. As a result, if I upgrade a stable box, I'm going to need to reboot the system, whereas currently I can upgrade everything other than the kernel and then deal with the kernel at my leisure. I think this is a regression. I think your assumption is probably false. There are maintainer scripts in pacakges for a reason. There are init scripts. I'm surprised I have to explain this to you. I also wonder how many participants in this thread who have voiced valid concerns also have an idea for how to go about solving those concerns, but are too interested in tearing Robert apart than offering useful advice. -- This thread scored 3 Trogdors out of a possible 5 in flamability.
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Marcelo E. Magallon wrote: How do the current kernel packages guarantee this? Why would Robert's package need to behave any differently? The current kernel packages don't make the old stuff just dissappear, so it's less of an issue in that case. In fact, the only bad situation with the current kernel packages is when you update between package releases of the same kernel version, and the current kernel packages make plenty of noise in that situation. I've had another thought, which was spurred by the System.map discussion; and some people are probably going to hate it because it duplicates some of the effort of having a package management system in the first place. The grub package doesn't ever install itself to /boot, it requires the admin to copy the binaries from /usr/lib after an upgrade (or my memory is totally flawed). It wouldn't be so difficult to rotate the previous (good) kernel and associated files and replace them with the new kernel. An update-kernel script which ran after installation, and again at boot time, could check to make sure the latest kernel was in place and that ones bootloader could find it, and that the previous kernel was also accessible to the bootloader. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 09:29:58AM -0500, Michael Poole wrote: Robert Millan writes: And even if it was, I claimed my packages has some advantages, but didn't claim it doesn't have any disadvantages. Please explain why the putative advantages outweigh the disadvantages. I don't have to do that. My package is worthy as long as the advantages outweight the disadvantages in some situations, but not exhaustively (i.e, for every situation), since I'm not replacing the current ones. 1) I haven't built a 2.4 kernel lately, but in linux-2.6, selecting some mandatory features in upstream for 386 (FPU and 486 instruction emulation) disables SMP support. How will you build a package for both 386 and x86 SMP machines? Keep in mind your claim that your system would get rid of the many kernel-image-* packages. Well, my package will be built in the way that supports a wider number of CPUs. Both building for i386 without SMP support and building for i486 with SMP are viable options. However, the real (long-term) solution would be to get upstream not imposing mandatory features for 386. 2) With your packages, how will someone be able to keep a known-good kernel on her machine when updating from one version of Linux to another? Complaining that bootloaders have the same problem is specious: they are considerably smaller, so it's more likely that changed code paths were tested by the packager. User space also differs: you can have many system utilities statically linked. If you have just one kernel installed, though, you better have both rescue disk and physical access to the machine. I just explained that in my response to: [EMAIL PROTECTED] 3) One of the benefits you claim is that people can apt-get source to get the source. You have also said that your target audience excludes those who build their own kernels. To me, this is inconsistent. What is the target audience for this benefit? The use of build their own kernels is ambigous here. My target audience excludes those who costumise them (apply patches, sub-arch optimisation, etc). It doesn't exclude developers who want to compile my package the standard way in order to change it and merge their changes. I.e, the same that happens for the rest of packages in Debian. 4) Another benefit you claim is that people on less commonly used architectures can get autobuilt kernels in the case of security patches. Not exactly. It shocks me that you ask this because it was actualy in a reply to you: http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html Handled by autobuilders, [...] This is specialy important for security updates. [...] I.e: The benefits apply to security updates, but that's not the only updates they apply to. The only suggestion I saw to deal with multi-platform testing was that some per-architecture team would do that. Who has volunteered to be on such teams? That question is not pertinent to my package. The same per-architecture team who does porting tasks for the standard Linux package is implicitly doing them for mine (Since they use the same patchset). 5) How will you handle architectures where the current upstream kernel is not based on the same version as your package? The main suggestion I see is that they'd have to use the current system for their kernels, which seems very bad for consistency. I pretend to package all upstream branches (2.4, 2.6, etc). The -defaults package can be selective across arquitectures (like gcc-defaults does). 6) Autobuilding from your source package may speed up releasing security patches. Cannot a similar speedup can be achieved by writing some scripts (much smaller and less time to maintain) to automatically build the current kernel packages? These scripts already exist. They're called autobuilders. Your integration of multiple architectures will also slow down normal updates, since you have to get the new package revisions and then resolve any conflicts. Just like it happens to the rest of Debian packages. 7) #include System.map.discussion, but s/System.map/modules/g for the kernel being replaced. Currently, installing a different version of the kernel (not just a different revision of the package) makes both sets of modules available. We should not require users to reboot so quickly after making a currently safe upgrade: I suspect I am not alone in preferring to update packages on a different schedule than when I reboot. This is trivial, too. Take my response on System.map, the solution for this would be similar. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 09:41:53AM -0500, Michael Poole wrote: In what way is updating between releases worse than updating within the same release? It is worse because a lot more code changes. I am sure that you have enough packaging (and Debian user) experience to recognize that. I am willing to assume that enough testing of Debian's package revision 2 (relative to revision 1) went on that my machine won't die. I am not willing to make the same assumption regarding Linux 2.4.23 relative to Linux 2.4.22, whether they are from a Debian package or from upstream. Yep. That makes sense. See my previous mail to Colin for my explanation on how my package can deal with backups. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Robert Millan wrote: being presented with. I'd really LOVE to. But this is my discussion. If I don't take part in it, who will respond to all these bogus arguments some people enjoy sending in? Rather, this is you and the other trolls who are wasting my time. What I'd really like to see is some packages uploaded to your home on gluck, because this thread isn't advancing *anyones* arguments. -- This thread scores 3 Trogdors out of a possible 5 for flamability.
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At Tue, 11 Nov 2003 11:59:24 +0100, Martin Schulze wrote: Preparation of Debian GNU/Linux 3.0r2 = An up-to-date version is at http://master.debian.org/~joey/3.0r2/. I am preparing the second revision of the current stable Debian distribution (woody) which will probably be released soon. This report is to allow people to comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. Please, please wait. Before you release r2, we must solve Japanese Watanabe font problem. See http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00142.html It makes very serious problem in Japan to release current status. But some of relational maintainers don't act. ttf-xtt-watanabe-mincho (Bug#214587), ttf-xwatanabe-mincho (Bug#214395), ttf-xtt-wadalab-gothic (Bug#214400), xfonts-intl-japanese-big (Bug#215371) must be removed and have already been reassigned to ftp.debian.org. Please do your work, ftp maintainers. watanabe-vfont (Bug#214399) aren't reassigned to ftp.debian.org, but this must be removed. Please action, Taruishi-san. ttf-kochi-mincho and ttf-kochi-mincho-naga10 (Bug#214402) aren't reassigned to ftp.debian.org. These package can be replaced by new kochi font (kochi-subst), but if Goto-san hasn't any time for this work, they must be removed. Please answer, Goto-san. Thanks, - -- Kenshi Muto [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iEYEARECAAYFAj+w42oACgkQQKW+7XLQPLGHtQCgmjaIU7Wu10/V7nemxEToYPq7 Gw8AnjxCcQbMuZmANFM+T2HixUjuNt7e =i8Vh -END PGP SIGNATURE-
Re: Why you are wrong [Was: On linux kernel packaging issue]
Glenn McGrath wrote: A program that is CPU bound will benefit from compiler optimisations. Define compiler optimisations. The teoretical compiler optimisations would run your programs faster, but... too much people spoke about optimisation without knowing what it means. Do you think -O3 would run code faster that -O2? If not: you will think is it a bug of gcc? Anyway: optimize the programmer time, not the code [1]: a less confuse code (thus less optimized) will help to write, maintain and debug better programs, so at the long run will run faster and better that an program written with all kind of optimisations. ciao giacomo [1] Unix philosophy or maybe only a ESR citation
Re: possible compromise for ITP: linux?
Andreas Metzler schrieb: Eike Sauer [EMAIL PROTECTED] wrote: There already are several packages with complete kernel sources which take as much place as his package would, right? Robert does not propose to remove the existing kernel-source packages Even he was a bit vague about that (sometimes I understood the large number of kernel packages used as an argument for his idea, which seemed to imply that he wants to remove many of them), I understood that. I wanted to say that the size of his packages are not too large to be included if we find they do something useful. therefore the calculation is simple - more than 100MB required space He didn't want to support all architectures, so let's say 50 to 100 MB. in exchange for ...? That goes to Robert. A cleaner design comes to my mind, which is not much for 50-100 MB being reproduced. Ciao, Eike
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
Robert Millan schrieb: I don't see why. I have a bunch of resources to find a solution for this trivial bug. You are implying the other DDs are your ressource for finding what you are calling trivial bugs. They are not. It's your duty to think of most of it beforehand. If you didn't want to imply that: Which ressources do you have? Why did you not already use them? I'm not suitable because my package has a trivial bug? Sorry, but you're not entitled to put my skills in question. Straight question, straight answer: Did you think about system.map at all? Is getting wchan displayable a reason to solve the System.map issue? If it is, I'll solve it. But I haven't seen anyone explaining what is wchan useful for at all. It's not our duty to explain why we want feature A or B. If your are going to provide a new style of packaging something, it's your duty do do it at least as well as the old style and to preserve ALL features, no matter how useful you find them personally. My amount of thought and consideration will apply when I get bug reports through the BTS. That's too late for thoughts. You are telling us: I'll throw this package in Debian, I don't care about features I don't use, if anybody does, he should file a bug report. That's not what I'd call thorough working. Which brings back the question on wether you're looking for bugs on purpose just for the sake of trolling. YOU are the one who should look for bugs (on purpose!) before. All those people do this to help you seeing the difficulties in your project. It's meant to help you. Ciao, Eike -- Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. Kristian Wilson, Nintendo, Inc, 1989
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
#include hallo.h * Robert Millan [Tue, Nov 11 2003, 12:21:32PM]: (This is exactly the same question as Matthew asked, of course; but it is an important question relative to this ITP and I want to see it answered.) I don't like turning this ITP into a technical discussion to prove either my dessign is consistent or I'm capable as a maintainer. However I'll respond to your question this time: Why could you not just wait for the debian-kernel mailing list to be created and really discuss your proposal there with other maintainers (which may have more experience in packaging kernels for different architectures) instead of pushing your own ideas as the one best thing? Place the package files in /usr/lib, and copy them conditionaly (debconf) into /boot. The debconf question would properly explain that if per chooses to update it, then the system must be rebooted promptly. (You can read peoples mind? ;) A similar method is also on my Design paper for the next debian-kernel generation...) Note that copying files takes double space. Better method would be installing the files into a new directory /boot/dk-linux-x.y.z/ and adding symlinks from them to /boot/ Same for /usr/lib/dk-linux-x.y.z/. You're proposing a packaging scheme where the package name is not changed for new kernel versions. It is entirely legitimate for people to bring up potential problems with this scheme. I'm disappointed that you feel it necessary to brush them off just to railroad your proposal through. I don't feel it necessary. But this is not the first trivial maintainer issue I'm being pointed at in this ITP, and I'm getting the impression that some people are doing it deliberately. As said before, people look for reasons to justificate the choice of the package name, causing additional confusion for users and waste of archive space without seeing much advantages. And you fail to explain those advantages so don't wonder about so many people not liking this ITP. MfG, Eduard. -- Ich weiß. Habe ja während der letzten LinuxTage miterlebt, daß die meisten Debian-Entwickler in der Tat eine seltene Rarität von Spezies sind, die völlig ohne Schlaf oder Körperhygiene auskommen. -- Klaus Knopper
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 11:26:43AM -0600, Marcelo E. Magallon wrote: apt-get source kernel-image-* doesn't bring me the real source. Instead, if I want the real source I must be root and install a binary package. Do you deny that this is confusing? Non-intuitive? Yes, I grant you that. Confusing? No, I don't find it confusing. Both words are valid to me. But you conveniently ignored a bit of my message: after installing kernel-tree-x.y.z you have the source _with_ patches applied. I don't really mind either way, but I'm looking for consistency in your argumentation, and I'm not finding it. You seem to claim the source package is of paramount importance to you, yet I don't understand how you are happy with a source package format which _does not_ give you the sources of the package as used to generate the binaries. The paramount importance matter, to me, is adhering to Debian standards. Which means apt-get source brings you either the patched source or the source with a set of patches. Which of them happens is beyond the scope of my arguments. You said: I've got news for you: Debian is a distribution. Who started the nitpick wording? Go back to [EMAIL PROTECTED] and, for a change, _read_ what I wrote. Please be more specific. Do you refer to: Let me spell this out for you: unless you _replace_ kernel-source-* and kernel-image-* and whatnot, you are not solving your perceived problem, you are making it worse. At some point you claimed it's not your intention to replace, but to offer an alternative. Having a gazillion variations of a theme might be a good software developing methodology, but I've got news for you: Debian is a distribution. My response still applies. Being The Universal Operating System means supporting lots of variations for all sort of (justificable) preferences. Again, your complain is that there are too many kernel-foo packages, Don't put words in my mouth. I said the current package set is confusing, which it is. So that's not the source of the confusion? Then why do you bring the number of packages into the discussion? Look at what you said in [EMAIL PROTECTED]. _You_ are the one making the explicit connection between confusing and the number of packages. There are two paragraphs on that mail referring to the confusion issue. You're ignoring the first one, which doesn't refer to the number of packages. In what way the presence of 136 separate kernel-* packages affects the confusability of my pair of linux-* ones? Oh, right, you don't want to solve a problem in Debian, you want to solve it in a little corner of your mind and just ignore whatever else. Somewhat. Except that little corner pretends to be integrated within Debian. No, I could do the same with plain dh-make'ed templates. It'd have the advantage that I wouldn't have to discuss silly arguments with you. 1. CDBS doesn't preclude the use of debhelper. You already know this. 2. This specific point wouldn't exist, but that doesn't mean I'd still be objecting to your ITP. If you go back and read [EMAIL PROTECTED] you'll notice that I didn't object to your particular choice of source packaging. The only reason why we are discussing that matter is because you claim this is a significant advantage of your work (you keep referring people back to [EMAIL PROTECTED], where this is one out three points you list as benefits) I don't recall claiming that using CDBS is a significant advantage in my package. Certainly, in [EMAIL PROTECTED] there's no reference to CDBS. Futhermore, you argue that the packaging is confusing and non-standard. I take you think that CDBS is somehow standard and easy to understand. It's neither. After apt-get source foo, foo-x.y still _does not_ contain the sources used to build the package. You have to take extra steps to do that. dpkg-buildpackage LOL... good one. (it was a joke, right?) If I bother to apt-get source foo, it's not because I want to dpkg-buildpackage it right away, is it? Not having a standard way to patch source (or unpack and patch, in cases such as libc6 and xfree86), means that you have to use debian/rules something to get the source that's actually used to build the package. There are good reasons for needing such a system, but this should be the exception, not the rule. But I'm drifting... No, you're actualy right. My response was an oversight. However, this problem applies to all Debian packages, not just mine. Point is 'apt-get source linux-2.4' won't give you the sources used to generate the binaries. If you claim this is the case, then you have to accept that 'apt-get source kernel-image-2.4.22-i386' also does. Both packages have build dependencies which pull _additional sources_ into the tree. If you are serious about that dpkg-buildpackage
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 07:34:23PM +, Andrew Suffield wrote: On Mon, Nov 10, 2003 at 12:57:02PM +0100, Robert Millan wrote: But the real results are shown through Popularity Contest [1] when my package reaches unstable. So keep your arguments on this for later. That is possibly the stupidest thing I have seen all week. Uhm.. is there a prize? -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Kernel 2.4.22-k7-1: initrd cannot mount proc from cramfs image
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the attention, Herbert. If you're using busybox then try regenerating the initrd image with BUSYBOX=no. I did not generate the image, i'm using a stock kernel-image-2.4.22-1-k7 package, no trace of busybox in the initrd image, and it's not even installed on this machine. Do you suggest I try mkinitrd'ing a new image anyway? - -- There are, in the end, no worthwhile things in the world; there are only worthwhile doings. -- Steve Talbott, NetFuture Nicola Larosa - [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/sOkuXv0hgDImBm4RAh1xAJ976HWTyvqMuaaJd+zGjS51LowJugCgpjDe 6hXVhZ46R8bNVfdJaNzYppk= =nJJF -END PGP SIGNATURE-
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 02:29:48PM +, Colin Watson wrote: On Mon, Nov 10, 2003 at 12:57:02PM +0100, Robert Millan wrote: On Sun, Nov 09, 2003 at 07:47:37PM -0600, Marcelo E. Magallon wrote: Look, if you want to waste time, waste _yours_. OTOH, if you want to take part in the discussion, do bother to address the issues you are being presented with. I'd really LOVE to. But this is my discussion. If I don't take part in it, who will respond to all these bogus arguments some people enjoy sending in? Rather, this is you and the other trolls who are wasting my time. Oh, I see: anybody who disagrees with you is a troll. That's interesting. I haven't said that. My quote is above (and I don't retract from it). Some people publicly said in this thread they like the package. Herbert said he likes it at least as an experiment. I got other private mails from well-known developers who like my proposal and pity your trolling attempts. Oh, wow, I was wondering how long it would take for this to appear! I got two of such mails, but you don't have to believe me if you don't want to. Specialy because I'm not going to paste their names here. However, you can't deny that Some people publicly said in this thread they like the package. Herbert said he likes it at least as an experiment. The lurkers support me in email They all think I'm great don't you know. You posters just don't understand me But soon you will reap what you sow. [...] That was funny. I haven't even thought of my scheme as becoming the preferred way of distributing Debian Linux. So I'll ignore your bogus hipothesis. Why not call it linux-experimental or linux-rmh or similar then? I'm sure a lot of people would be much happier with your proposal if it didn't claim the important namespace of linux, which implies that it is the preferred kernel package. If there's consensus on that, I agree. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Why you are wrong [Was: On linux kernel packaging issue]
On Monday 10 November 2003 23:56, Darren Salt wrote: Converting some multiplies to shifts (or shift plus some other arithmetic), or arranging that one of the source registers normally contains the lower value, can also help. (At least, on ARM...) Gcc already does do this when appropriate (multiply by 2^x), and has been for as long as i can remember. Tom -- ^__^| Tom Badran (oo)\__ | Imperial College (__)\ )\/\| Department of Computing ||w || --- || ||| Using Debian SID pgpofV8sx60Eg.pgp Description: signature
Re: possible compromise for ITP: linux?
On Mon, Nov 10, 2003 at 06:22:13PM +0100, Eike Sauer wrote: Hello! Hi Eike, The discussion doesn't seem to be very productive any more. Time to come to a compromise? Sounds nice. What about letting Robert build and upload (if ftp-masters agree) his package, *if* he puts it in experimental, uses a description that contains a warning about the experimental status of the package in a prominent place, and not calling it linux, but... (Robert, please choose. linux-tng, linux-experimental and other names have been proposed). If all works out fine and such packages eventually become the standard way of installing the linux kernel, the name could be changed then (as well as distrubution and description). If it's not working, an important package name stays usable. I agree with all the above, as long as there's consensus to do that. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
Jamie Wilkinson wrote: Kernels install /boot/System.map-$version. There's a symlink from /boot/System.map to the current version. And Robert's proposal currently results in the System.map-$version for my current kernel vanishing, along with my modules. You are told you need to reboot after installing a kernel package. No. You're currently told that you need to reboot after installing a kernel package for the same kernel version as you're currently running. This happens rarely. It looks to me like you're harping on a single issue which would have been encountered during the process of making this package, and based on this Robert is suddenly a second-class maintainer? If someone is hoping to maintain a critical part of infrastructure, then I do expect them to have some idea of what all the strange little files it provides do and how messing things up could break them, yes. For instance, I wouldn't even consider going anywhere near maintaining glibc, despite having messed about with its guts quite considerably. I just don't understand the code sufficiently. If everyone in this project had to get the right answer first time, there would be a lot fewer maintainers and a lot fewer bugs in the BTS. If you're uploading a package that otherwise already exists in the archive, and your package fucks shit up that the other one doesn't, then you're doing something wrong. No, I'm saying that you're proposing to package a major piece of infrastructure and give it a name that may attract users into installing it, and the amount of thought and consideration that you seem to have put in is insufficiently large for me to consider that it'll do anything other than convince people that Debian kernel packagers are on crack. Which would, again, be bad. I'd reiterate that you're implying Robert is going to make a half-arsed attempt and upload something he hasn't tested, but I've already said that. I'm implying that because he's so far stated that various issues aren't real problems. I don't think it'll be a half-arsed attempt, and I imagine that it will be tested, but I think it's likely to prove of significantly lower quality than the package that already exists. Frankly, I think that would be true pretty much independent of who maintains it - Herbert has a good deal of familiarity with the kernel, and many years of experience. The kernel packages are decent. Uploading new packages with a name that's going to attract people into installing them and which are likely to be of lower quality is just insane. Besides, it's already evident that Debian maintainers (as a superset of kernel packagers) are on crack. Most users don't find that packages they install break stuff. -- Matthew Garrett | [EMAIL PROTECTED]
Re: ftpmaster accepts packages that have been rejected a few days ago
On Nov 11, Daniel Silverstone [EMAIL PROTECTED] wrote: When linux-atm gets to the point that the br2684ctl program is sufficiently stable to be included in the main package, I invite you to file a bug requesting that the br2684ctl source package be removed, having been obsoleted by the linux-atm package. This is what I already plan to do as the br2684ctl maintainer. -- ciao, | Marco | [2978 scDmkZcDJQKbI]
Re: possible compromise for ITP: linux?
On Mon, Nov 10, 2003 at 11:30:54PM +, Andrew Suffield wrote: - this packages adds nothing, and would occupy a fair chunk of space in the archive. The advantages cited were rapidly debunked and no more were given. I haven't seen any of them being debunked. The only exception is the second paragraph of the second advantage, which started with This is specialy important for security updates. But not being specialy important for something doesn't mean it isn't an advantage at all. - this package cannot be safely upgraded (without forcing a reboot). I sent an explanation on how to send this a while ago (in response to Colin, not yet archived). Basicaly, backing up in preinst solves the problem. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
On Tue, Nov 11, 2003 at 11:59:24AM +0100, Martin Schulze wrote: I'm confused. On the one hand, you say: The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. It is ((1 OR 2 OR 3) AND 4) OR 5 But on the other hand: aspell-en stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc aspell stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc source libaspell-dev stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc libaspell10stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc The license incorrectly says that it's LGPL but it is in fact a unique license which is non-DFSG-free. A package I have recently adopted, scsh, is in the same case. It is in main, but in fact contains non-free parts. A (temporary, until all different authors are traced and that they can agree to free the code) solution is in sid (source, i386) and underway for the other arches and sarge. Does this warrant an update in a woody revision? Why? Is this considered a Security issue, because it may cause people with guns (police) to come to your house and threaten you? Shall I then contact the security team about this, too? Shall I then prepare an updated package, with correct copyright file, for stable/non-free, and try to get people to compile it for all arches? -- Lionel signature.asc Description: Digital signature
Re: possible compromise for ITP: linux?
On Tue, Nov 11, 2003 at 09:36:30AM +0100, Andreas Metzler wrote: Robert does not propose to remove the existing kernel-source packages therefore the calculation is simple - more than 100MB required space Approximately. It depends on how many architectures can be supported. in exchange for ...? We already went through this. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: create new Debian-Kernel project (was: ITP: linux -- Linux 2.4 kernel)
#include hallo.h * Jamie Wilkinson [Tue, Nov 11 2003, 11:28:43PM]: Note that the name is choosen not only to attract the user, but also to catch that who blindly use apt-get source linux. The user wouldn't get the well-known and good kernel-source packages but something which is under control of Robert. Further, what they would get is not a clean source but something with debian/ dir inside which would confuse make-kpkg. I would not mind if he had called it linux-rmh or such. I do not understand your point, you are trying to protect users who inadvertently type apt-get source linux? When I type apt-get source This was just a counter-argument to a bogus one: apt-get source kernel-image-... would not bring the real source usable to compile a kernel. Note that his package does not that either. pppoeconf, do I not get the source to the Debian package of ppoeconf? Why should it be any different? I'm not convinced that people type apt-get source x inadvertently either. Eh, do you really know how the kernel stuff is currently packaged? The problem was not getting the source of the package. In fact, apt-get source kernel-image-... gets the exact source of the package but not the whole source. In order to get the actual source you have to run debian/rules with some argument first. So if he just repackages the kernel-source from Herbert he does not do it much different. Your second sentence is flagrant abuse, and its tone seems common in your attempts at constructing a reasoned argument. Please try to keep civil, Eduard. I trust your ability to maintain your packages, as I trust everyone else in this project, at least until I see the product of their work. Thanks. But who do you trust more: Robert or experienced kernel-image packagers? Confusing make-kpkg would be an issue, I suppose -- given that one could want to get any kernel source and build it with the tools they're familiar with. If it were me, I'd make sure to include some extra information in the package README. Look, you just admit that getting the source is not that easy one-step work as expected by the user. And if does require some extra work, what is the big difference between fiddling with the current system and with the CDBS version? The last one requires even more additional build-dependencies. Are you implying that you make up names for the software that you package, rather than use the name given to it by upstream? I believe you don't. Ah, that is a good base to start a discussion. Of course it is better to keep the upstreams name but make exceptions if they are too generic, to confusing or to offensive (though we did already accept such ones, eg. pornview ;)). I concur that packages have been renamed where their name is too generic, such as verbs and short nouns (one of my earliest packages, imgstamp, was originally named 'stamp' and rejected). However, this is the word 'linux'. What else do you think it could possibly refer to? linux-kernel-experimental, kernel-experimental or such. MfG, Eduard. -- Kannst Du wie jedes ordentliche Device mit ACK oder 200 Ok antworten? -- Joey
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 11:59:32PM +1100, Jamie Wilkinson wrote: This one time, at band camp, Robert Millan wrote: Place the package files in /usr/lib, and copy them conditionaly (debconf) into /boot. The debconf question would properly explain that if per chooses to update it, then the system must be rebooted promptly. Another option: Place the package files in /boot, but save a backup of them before (preinst). Then prompt the user to reboot through debconf. Or even a combination of the two. A third method may involve a rc script that makes sure the correct version of System.map is installed. Then the only time kernel symbols are not found is between the package upgrade and just after the next reboot. Sounds viable. I'll try to remember that. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
#include hallo.h * Jamie Wilkinson [Tue, Nov 11 2003, 11:40:11PM]: There are already several forks of the Linux kernel in Debian anyway. Robert wishes to attempt to unify them, does that not grant him use of the name 'linux'? Bug nobody was bold enough to take exactly this (as said very generic) name. And Robert does not have agreement with maintainers of the packages he wants to unify. So it is yet another fork. And what does the next person do who tries to unify them? MfG, Eduard. -- Katzen erreichen mühelos, was uns Menschen versagt bleibt: durchs Leben gehen ohne Lärm zu machen. -- Ernest Hemingway
Re: Tutor in Torino: cercasi
Il mar, 2003-11-11 alle 13:27, Fabio Massimo Di Nitto ha scritto: On Tue, 11 Nov 2003, Federico Di Gregorio wrote: almeno due di sicuro ;P forza GRANATA! :P il mio colore preferito e` blu cobalto. -- Federico Di Gregorio Debian GNU/Linux Developer[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] La felicità è una tazza di cioccolata calda. Sempre. -- Io signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: radiusd-freeradius history and future
On Tue, Nov 11, 2003 at 10:13:22AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: On Sun, Jan 12, 2003 at 01:21:53PM -0500, Chad Miller wrote: [cc debian-devel] On Sun, Jan 12, 2003 at 05:07:41PM +0100, Toni Mueller wrote: [...] Who withdrew [radiusd-freeradius] or caused it's withdrewal, then? Curious minds want to know, and also, it's a bit misty right now... (...) A few months ago, the Sarge release coordinator swept all gravely-buggy- older-than-3?-months packages from sid, including radiusd-freeradius. Wichert immediately asked for the package to be added back, but someone noted that freeradius, a GPL program, linked against libssl, so it couldn't go back in. What is the current status of this issue? There are yet no radiusd-freeradius (or freeradius) packages either in sid or (even) in ftp://ftp.freeradius.org/pub/radius/. The issue on SSL linking (described in DWN [1]) doesn't look as it is has been fixed and the debian/ directory in the CVS has not seen any change for quite some time (+5 months) Hi Javi. I don't use RADIUS servers any more, so I've lost interest in maintaining FreeRADIUS. Someone in the freeradius-devel list (I don't remember who, atm) seemed interested in packaging it, at least with a sponsor. - chad -- Chad Miller GPG: 9E6947D9Jabber: [EMAIL PROTECTED] (not email) et c. @ http://wiki.chad.org/ChadMiller pgp9Fp0QOOPsN.pgp Description: PGP signature
Re: create new Debian-Kernel project (was: ITP: linux -- Linux 2.4 kernel)
Jamie Wilkinson writes: However, this is the word 'linux'. What else do you think it could possibly refer to? Most people seem to think that 'Linux' is the name for the whole kit and kaboodle: kernel, userland, and everything. They are wrong, but they still will be confused by a package named simply 'linux'. Thus 'linux-kernel', 'hurd-kernel', 'netbsd-kernel', etc would be better. 'Linux-kernel' would make searching easier, too. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
Robert Millan [EMAIL PROTECTED] writes: On Mon, Nov 10, 2003 at 09:29:58AM -0500, Michael Poole wrote: Robert Millan writes: And even if it was, I claimed my packages has some advantages, but didn't claim it doesn't have any disadvantages. Please explain why the putative advantages outweigh the disadvantages. I don't have to do that. My package is worthy as long as the advantages outweight the disadvantages in some situations, but not exhaustively (i.e, for every situation), since I'm not replacing the current ones. So far I have not seen any situation where the benefits will be both noticable and reliable. In the case of some benefits, your target audience remains indistinct. In the case of other benefits, you release untested code for critical system components. In the case of every benefit, your ITP shows more zeal than foresight. 1) I haven't built a 2.4 kernel lately, but in linux-2.6, selecting some mandatory features in upstream for 386 (FPU and 486 instruction emulation) disables SMP support. How will you build a package for both 386 and x86 SMP machines? Keep in mind your claim that your system would get rid of the many kernel-image-* packages. Well, my package will be built in the way that supports a wider number of CPUs. Both building for i386 without SMP support and building for i486 with SMP are viable options. However, the real (long-term) solution would be to get upstream not imposing mandatory features for 386. You do not understand. I specifically mentioned what that features were so that it would be clear it's not mandatory per upstream: It is mandatory for Debian's current user space ABI. Specifically, many applications use native floating point support, and glibc uses 486-specific instructions for locking. Before you say the real solution would be to get upstream not excluding that emulation from SMP think about why they are exclusive. 2) With your packages, how will someone be able to keep a known-good kernel on her machine when updating from one version of Linux to another? Complaining that bootloaders have the same problem is specious: they are considerably smaller, so it's more likely that changed code paths were tested by the packager. User space also differs: you can have many system utilities statically linked. If you have just one kernel installed, though, you better have both rescue disk and physical access to the machine. I just explained that in my response to: [EMAIL PROTECTED] The solutions listed there involve leaving ~36 MB of old files on the user's system indefinitely, without them being tracked by dpkg. Someone already objected to this -- it defeats the point of a packaging system. Those solutions don't even pass the sniff test, so I am surprised you raise them as serious suggestions. 3) One of the benefits you claim is that people can apt-get source to get the source. You have also said that your target audience excludes those who build their own kernels. To me, this is inconsistent. What is the target audience for this benefit? The use of build their own kernels is ambigous here. My target audience excludes those who costumise them (apply patches, sub-arch optimisation, etc). It doesn't exclude developers who want to compile my package the standard way in order to change it and merge their changes. I.e, the same that happens for the rest of packages in Debian. Perhaps I am being dense, but what does merge their changes mean except to customize their kernels? The only suggestion I saw to deal with multi-platform testing was that some per-architecture team would do that. Who has volunteered to be on such teams? That question is not pertinent to my package. The same per-architecture team who does porting tasks for the standard Linux package is implicitly doing them for mine (Since they use the same patchset). You claimed that the autobuilder will help when security patches become available. You can either claim to apply those patches quickly (more quickly than they are currently available) or claim that the porting teams will provide tested patches that you just integrate. To claim both is inconsistent, and such shoddy thinking does not inspire faith in your ability to integrate these patches. 5) How will you handle architectures where the current upstream kernel is not based on the same version as your package? The main suggestion I see is that they'd have to use the current system for their kernels, which seems very bad for consistency. I pretend to package all upstream branches (2.4, 2.6, etc). The -defaults package can be selective across arquitectures (like gcc-defaults does). That does not answer my question. Right now, the current kernels on arm are 2.4.19 and 2.2.19. On x86 and mips, 2.4.22. On m68k, 2.4.20 and 2.2.25. On sparc, 2.4.21 or 2.2.20 (depending on subarch). On s390, 2.4.19. Out of six architectures I checked, only two pairs use the same kernel version.
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 02:17:10PM +0100, Eike Sauer wrote: Robert Millan schrieb: I don't see why. I have a bunch of resources to find a solution for this trivial bug. You are implying the other DDs are your ressource for finding what you are calling trivial bugs. They are not. It's your duty to think of most of it beforehand. If you didn't want to imply that: Which ressources do you have? Why did you not already use them? I didn't want to imply that. I was referring to general packaging resources like preinst script, debconf, etc. (Actualy, I explained some possible ways to solve this in response to Colin. Then Jamie added other possibilities, like using init.d scripts or an update-kernel script) I'm not suitable because my package has a trivial bug? Sorry, but you're not entitled to put my skills in question. Straight question, straight answer: Did you think about system.map at all? Yes. I decided to not provide it and investigate later wether it was worth providing or not. Is getting wchan displayable a reason to solve the System.map issue? If it is, I'll solve it. But I haven't seen anyone explaining what is wchan useful for at all. It's not our duty to explain why we want feature A or B. If your are going to provide a new style of packaging something, it's your duty do do it at least as well as the old style and to preserve ALL features, no matter how useful you find them personally. Agreed. But the discussion on system.map started with someone claiming the bug implied either a dessign problem in my package or that I'm incompetent. My amount of thought and consideration will apply when I get bug reports through the BTS. That's too late for thoughts. You are telling us: I'll throw this package in Debian, I don't care about features I don't use, if anybody does, he should file a bug report. That's not what I'd call thorough working. That's not exact. I do care about features even if I don't use them, what I dislike is discussing things in this ITP that actualy belong to the BTS. Which brings back the question on wether you're looking for bugs on purpose just for the sake of trolling. YOU are the one who should look for bugs (on purpose!) before. Yes, but not in order to feed a discussion like this one. All those people do this to help you seeing the difficulties in your project. It's meant to help you. Probably most of them, but not all. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Wed, Nov 12, 2003 at 12:13:42AM +1100, Jamie Wilkinson wrote: I've had another thought, which was spurred by the System.map discussion; and some people are probably going to hate it because it duplicates some of the effort of having a package management system in the first place. The grub package doesn't ever install itself to /boot, it requires the admin to copy the binaries from /usr/lib after an upgrade (or my memory is totally flawed). It wouldn't be so difficult to rotate the previous (good) kernel and associated files and replace them with the new kernel. An update-kernel script which ran after installation, and again at boot time, could check to make sure the latest kernel was in place and that ones bootloader could find it, and that the previous kernel was also accessible to the bootloader. Maybe. I'm open to try that as long as it doesn't imply adding extra binary packages (which is one of the points in my package). Btw, as a grub co-maintainer, I think the idea sounds nice for grub. Although I'm not sure if it's already implemented (update-grub?). Anyway, ask Jason ;) -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
Robert Millan [EMAIL PROTECTED] wrote: On Mon, Nov 10, 2003 at 09:29:58AM -0500, Michael Poole wrote: [...] 5) How will you handle architectures where the current upstream kernel is not based on the same version as your package? The main suggestion I see is that they'd have to use the current system for their kernels, which seems very bad for consistency. I pretend to package all upstream branches (2.4, 2.6, etc). The -defaults package can be selective across arquitectures (like gcc-defaults does). The question was: How do you provide 2.4.x for architecture blah and 2.4.y for architecture foo, which are two versions of the same upstream branch. Afaict you were proposing to have one package for each upstream /branch/. You cannot have linux-2.4_2.4.x.orig.tar.gz and linux-2.4_2.4.y.orig.tar.gz at the same time in the Debian archive, once you upload 2.4.y to sid, 2.4.x with xy is not available in sid anymore. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Bug#220212: ITP: zope-zstylesheet -- Simple product designed to allow easy style sheets
Package: wnpp Severity: wishlist * Package name: zope-zstylesheet Version : 4.2.5 Upstream Author : Adrian 'Haqa' Hungate [EMAIL PROTECTED] * URL : http://zope.org/Members/haqa/ZStyleSheet * License : OpenSource Description : Simple product designed to allow easy style sheets This is a simple product designed to allow easy ZOPE based administration of style sheets. Features: # Complex style sheets can be constructed in a logical (to me at least) way. # Static style sheets can be imported (And the importer may even remove some selector duplication). # You can now select that sections of the tree render only if the user is using a specific browser. # The style sheet renders in multiple ways depending on how it is called - sheetname.tag : Inserts a link rel tag into your page. - sheetname.style : Inserts the sheet between tags - sheetname.index_html : Returns the sheet with the Content-Type header text/css - sheetname.preview : Renders the sheet as an html page so you can review it. It even insert a link rel tag at the top (Only really shows off H1, H2 and PRE). - This now (Version 4.0) allows the Z Style Sheet to be rendered into a page in one of three different ways (Based on the linkstyle property) * Normal Z Style Sheet : Default same as sheetname.tag * Insert a Style Block : Same as sheetname.style * ZMI Compatible : This is a special mode to be compatible with the manage_page_style.css We can found licence here. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux nico-sid 2.4.20ctx-16 #1 Tue Feb 25 13:58:02 CET 2003 i686 Locale: LANG=C, LC_CTYPE=C -- Nicolas Ledez - Virtual Net (www.virtual-net.fr) 80, avenue des Buttes de Coesmes - 35700 RENNES tel: +33 2 23 21 06 32 - fax: +33 2 99 38 16 85 signature.asc Description: Digital signature
Bug#220216: ITP: zope-lockablefolder -- variant of the standard Folder that can restrict access to its contents
Package: wnpp Severity: wishlist * Package name: zope-lockablefolder Version : 0.1.0 Upstream Author : Butch Landingin [EMAIL PROTECTED] * URL : http://www.zope.org/Members/butchland/LockableFolder * License : BSD ? Description : variant of the standard Folder that can restrict access to its contents This product provides a variant of the standard Folder that can restrict access to its contents that have been explicitly set as inaccessible, so they are no longer visible as a URL path but can still be accessed via DTML/Script/ZPT TALES. After locking, objects are no longer accessible, even through management screens. They must be unlocked so they can be managed again. # Copyright (c) 2001 Butch Landingin # All rights reserved. Written by Butch Landingin [EMAIL PROTECTED] # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # # 1. Redistributions of source code must retain the above copyright #notice, this list of conditions and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions and the following disclaimer in the #documentation and/or other materials provided with the #distribution. # # 3. The name of the author may not be used to endorse or promote # products #derived from this software without specific prior written #permission # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR # IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED # WARRANTIES # OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE # DISCLAIMED. # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, # BUT # NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF # USE, # DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE # OF # THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # # In accordance with the license provided for by the software upon # which some of the source code has been derived or used, the following # acknowledgement # is hereby provided : # # This product includes software developed by the Zope Corporation # for use in the Z Object Publishing Environment # (http://www.zope.org/). -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux nico-sid 2.4.20ctx-16 #1 Tue Feb 25 13:58:02 CET 2003 i686 Locale: LANG=C, LC_CTYPE=C -- Nicolas Ledez - Virtual Net (www.virtual-net.fr) 80, avenue des Buttes de Coesmes - 35700 RENNES tel: +33 2 23 21 06 32 - fax: +33 2 99 38 16 85 signature.asc Description: Digital signature
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Wed, Nov 12, 2003 at 12:19:33AM +1100, Jamie Wilkinson wrote: What I'd really like to see is some packages uploaded to your home on gluck, because this thread isn't advancing *anyones* arguments. I did that a few days before sending the ITP: http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00204.html But noone responded. One could wonder why everyone who pointed out problems in my package in the ITP didn't send the mail before.. oh well. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 02:29:13PM +0100, Eduard Bloch wrote: I don't like turning this ITP into a technical discussion to prove either my dessign is consistent or I'm capable as a maintainer. However I'll respond to your question this time: Why could you not just wait for the debian-kernel mailing list to be created and really discuss your proposal there with other maintainers (which may have more experience in packaging kernels for different architectures) instead of pushing your own ideas as the one best thing? As I said before, I'm open for discussion, not trying to push my own ideas as the one best thing. Note that I initialy explained how my package isn't meant to be the one best thing and replace the current ones, but rather an addition for people to have more options. I'm still not sure if my package will fit exactly with your former proposal, but I'll be happy to discuss all your concerns in debian-kernels. Place the package files in /usr/lib, and copy them conditionaly (debconf) into /boot. The debconf question would properly explain that if per chooses to update it, then the system must be rebooted promptly. (You can read peoples mind? ;) A similar method is also on my Design paper for the next debian-kernel generation...) It was a somewhat logical conclussion, so it isn't strange that we came up with the same separately. And excuse me for not having read all the docs you pointed at before, as you have noticed I've been really busy with other things (like, say, responding to hundreds of emails). Note that copying files takes double space. Better method would be installing the files into a new directory /boot/dk-linux-x.y.z/ and adding symlinks from them to /boot/ Same for /usr/lib/dk-linux-x.y.z/. Sounds nice. We can discuss all this later. As I said, I'm open for that. I don't feel it necessary. But this is not the first trivial maintainer issue I'm being pointed at in this ITP, and I'm getting the impression that some people are doing it deliberately. As said before, people look for reasons to justificate the choice of the package name, causing additional confusion for users and waste of archive space without seeing much advantages. And you fail to explain those advantages so don't wonder about so many people not liking this ITP. Could be, but that doesn't justify using maintainer issues as an excuse against my ITP. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: using freedesktop.org libs
On Tue, 2003-11-11 at 13:11, Andrew Suffield wrote: On Tue, Nov 11, 2003 at 01:14:30AM +0100, Michel D?nzer wrote: I found this idea very interesting. I think that the debian project should take more advantage of the freedesktop.org libs. Glancing briefly at the packages in sid, we've been using the ones they have released for a while. Unreleased libraries do not belong in unstable. It's not about released vs. unreleased but XFree86 vs. freedesktop.org. Actually, I misread your paragraph above and drew the wrong conclusions. Sorry about that. I agree that unreleased libraries aren't for sid, but maybe for experimental? :) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
What is so damn hard about respecting a Mail-Followup-To: header? On 11-Nov-03, 06:24 (CST), Robert Millan [EMAIL PROTECTED] wrote: I didn't claim all of them are trolling. But a few of them are. Also IIRC I haven't put in question their experience as developers. Your reply to Marcello: It's easy for people who are already used to Debian de-facto standards. Since I am and you're not [1], sure sounds like you're questioning Marcello's experience. Your footnote (Your reasoning shows either you're not used to them, or you're plainly trolling.) doesn't help. No, most of the packages in Debian give me the source with a simple 'dpkg-source -x'. No rules file reading necessary. Not that many, actualy. An important number of them apply patches dynamicaly either directly or after unpacking upstream sources. Not that many, actually? Are you serious? If so, we now know for sure which participant in this thread is not familiar with Debian packaging. First you write: It's easy for people who are already used to Debian de-facto standards. And then you write: When I said de-facto standards I didn't refer to CDBS. There's currently no de-facto standard for debian/rules files, although there are a bunch of attempts at becoming one (and CDBS is one of them). So which is it? Are there de-facto standards for people to be familiar with, or are are there no de-facto standards? You can't even be consistent with your own quote staring you in the face. Steve PS I wrote this, and then decided not to post it, until I read your reply to Lukas Guyer, which once again made a big deal about how you were following the de-facto standards of Debian. It's amazing how much intellectual dishonesty one person can demonstrate in so little space. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Bug#220219: ITP: vbtp -- VisioBraille's Transfer Protocol
Package: wnpp Severity: wishlist * Package name: vbtp Version : 1.0 Upstream Authors : Samuel Thibault [EMAIL PROTECTED], Sébastien Hinderer [EMAIL PROTECTED] * URL : http://perso.ens-lyon.fr/samuel.thibault/vbtp-1.0.tar.gz * License : GPL, version 2 or higher Description : VisioBraille's Transfer Protocol This program allows you to exchange files with a VisioBraille braille terminal.
Re: possible compromise for ITP: linux?
On Tue, Nov 11, 2003 at 02:05:50PM +0100, Eike Sauer wrote: Andreas Metzler schrieb: Eike Sauer [EMAIL PROTECTED] wrote: There already are several packages with complete kernel sources which take as much place as his package would, right? Robert does not propose to remove the existing kernel-source packages Even he was a bit vague about that (sometimes I understood the large number of kernel packages used as an argument for his idea, which seemed to imply that he wants to remove many of them), I understood that. I wanted to say that the size of his packages are not too large to be included if we find they do something useful. I'll try to be more specific. The argument consists in that I provide a pair of separate packages (linux and linux-2.4) which are clearly distinguishable from the big set (kernel-*). Then the user can choose between figuring out how the kernel-* work, or figuring out how the linux* work. My pretension is that the former is much more simple and straightforwarded for the end user (and developer). in exchange for ...? That goes to Robert. Uhm. As I told him we already went through this. I was asked this question already, and already responded, so I don't really know what to say. Just have a look at: http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 12:21:32PM +0100, Robert Millan wrote: or who pretend the dessign of my package is broken in a way that I can't solve such trivial bugs. Look, you see whatever you want to see, but you are still missing the forest for the trees. When I mentioned System.map this was an _example_, get it? The fundamental problem with your package is that you have: Package: linux-2.4 Version: 2.4.22-1 /boot/vmlinuz-2.4.22 /boot/System.map-2.4.22 /lib/modules/2.4.22/... and you have to handle upgrades to either of: Package: linux-2.4 Version: 2.4.22-2 /boot/vmlinuz-2.4.22 /boot/System.map-2.4.22 /lib/modules/2.4.22/... or: Package: linux-2.4 Version: 2.4.23-1 /boot/vmlinuz-2.4.23 /boot/System.map-2.4.23 /lib/modules/2.4.23/... I'll just assume you can follow that. You have to handle the following upgrades: a) linux-2.4 (2.4.22-1) - linux-2.4 (2.4.22-2) b) linux-2.4 (2.4.22-1) - linux-2.4 (2.4.23-1) Right? Assuming the user is running 2.4.22, in case a) you are replacing the _running_ kernel image. In particular, the System.map file _on disk_ does not correspond to the running kernel image anymore. Stuff like top, ps, klogd and ksymoops won't work properly (if you have to ask why or why this is important, just go RTFM). The _modules_ on disk don't correspond to the loaded modules, and it's possible that they don't even load anymore. In this situation the most sensible thing to do is reboot. It's a PITA but it can't be worked around without changing the kernel's idea of its own version (or better said, without ensuring somehow that 2.4.22-1 and 2.4.22-2 exist at the same time on the machine, which we don't support, this is not rpm) Still with me? In b) you _still_ have this problem because dpkg is going to remove linux-2.4 (2.4.22-1)'s files and put linux-2.4 (2.4.23-1)'s in place. Still there? By this point the problem should be self evident, but since we've gotten to the point where I have to spell this out for you, I'll just keep explaining. The situation is now worse: there are _no traces_ of 2.4.22 left on the system. Loading modules will just fail, because the modules are _not_ there. System.map-2.4.22 is gone for good, so any sort of debugging at this level will be just harder if not impossible (if you like decoding kernel addresses in your head for breakfast that's fine, but I know plenty of people who don't). The user _has_ to reboot into a kernel that he's not even sure _works_. If you claim that _every_ time you have upgraded a kernel it's worked right out of the box, I'm going to ask the Smithsonian to put you on exhibition. I'm sure it will be more successful than that lame Star Wars thing. Still following? With the current kernel-image-2.4.22-1-i386 packages you have: Package: kernel-image-2.4.22-1-i386 Version: 2.4.22-1 /boot/vmlinuz-2.4.22 /boot/System.map-2.4.22 /lib/modules/2.4.22/... Package: kernel-image-2.4.22-1-i386 Version: 2.4.22-2 /boot/vmlinuz-2.4.22 /boot/System.map-2.4.22 /lib/modules/2.4.22/... Package: kernel-image-2.4.23-1-i386 Version: 2.4.23-1 /boot/vmlinuz-2.4.23 /boot/System.map-2.4.23 /lib/modules/2.4.23/... [ Here I'll just state that I don't know if the -1- bit in the package name modifies the kernel version in any way because it's been ages since the last time I used the official debian kernel images. ] With this we have: c) kernel-image-2.4.22-1-i386 2.4.22-1 - 2.4.22-2 and that's it. There's no 2.4.22-1 to 2.4.23-1 upgrade path because that _is not_ an upgrade with this scheme. That's a feature. Installing kernel-image-2.4.23-1-i386 doesn't nuke kernel-image-2.4.22-1-i386. Is that clear with you? Since the only upgrade to handle is 2.4.22-1 - 2.4.22-2 we still have the same problem that I described before with System.map and the modules, but _only_ that problem. We don't have the things gone for good problem and we don't have the very ugly is this thing going to work at all? problem. Do you see the forest now? How do you propose to do that without changing the package name, and without leaving old System.map junk around for eternity? I don't see how it can be possible. I don't like turning this ITP into a technical discussion to prove either my dessign is consistent or I'm capable as a maintainer. You are proposing to package a fundamental piece of software in a way that's prone to _break_. Since this ITP is _only_ about repackaging something we already provide, the discussion about the design decisions is more than justified. However I'll respond to your question this time: Oh, thanks, you answer questions for a change. Place the package files in /usr/lib, and copy them conditionaly (debconf) into /boot. The debconf question would properly explain that
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 12:21:32PM +0100, Robert Millan wrote: On Mon, Nov 10, 2003 at 02:23:52PM +, Colin Watson wrote: As a prospective maintainer of an important package, it ill behooves you to make fun of legitimate bug reports. No, you're confused. I don't blame you because you probably missed where the whole System.map discussion came from. As I just told to Matthew, someone claimed that my package has a dessign problem in the way it deals with System.map upgrades. But it actualy resulted that it's just a bug that prevents wchan from being displayable. I can fix that bug without much trouble. No, I don't think I'm confused, I'm quite aware of where the discussion came from, and it's not just a bug that prevents wchan from being displayable. You actually acknowledged my comment about the more serious problem later in your mail, so don't pretend that it doesn't exist up here, please. How do you propose to do that without changing the package name, and without leaving old System.map junk around for eternity? I don't see how it can be possible. (This is exactly the same question as Matthew asked, of course; but it is an important question relative to this ITP and I want to see it answered.) I don't like turning this ITP into a technical discussion to prove either my dessign is consistent or I'm capable as a maintainer. ITPs are frequently about ensuring that the design is valid! If you thought they were just a rubber-stamping exercise, well, I'm sorry to disappoint you, but peer review is an integral part of this project. However I'll respond to your question this time: Place the package files in /usr/lib, and copy them conditionaly (debconf) into /boot. The debconf question would properly explain that if per chooses to update it, then the system must be rebooted promptly. Another option: Place the package files in /boot, but save a backup of them before (preinst). Then prompt the user to reboot through debconf. Or even a combination of the two. Either satisfies the first part of my question, but at least your second option doesn't satisfy the second part of my question. I'll repeat: without leaving old System.map junk around for eternity When would you clean up the backups you've created? It's very easy in Herbert's scheme: you remove the package containing it. It doesn't seem to be so well-organized in yours. The same goes for kernel modules, as other people have mentioned: this is essentially the same problem (files or directories that normally have the upstream version number in their names) but more difficult. As for the first option with debconf questions, well, that might work, although I haven't fully thought out how it would interact with kernel modules (what if users decide to copy hand-built modules into /lib/modules, which is fairly common practice when testing things - would they be removed when the newer version is installed? I'd hope not. If not, when do you plan to remove modules that apply to older kernel versions? Never?). There's been an increasing consensus over the years that we should have fewer debconf questions, not more; perhaps this is an exception, but I think it would be wise of you to seek review by debconf experts before it enters the archive. I'm not asking these questions to harass you: I'm asking them because I genuinely have trouble believing that it's possible to solve them in a high-quality way if you do not change the kernel package name from one upstream release to the next. The main feature of your proposal from a user's point of view seems to be that the package name will not be changed from one upstream release to the next, and therefore I think it is entirely appropriate for us to examine the implications of this proposal on debian-devel in response to your ITP. You're proposing a packaging scheme where the package name is not changed for new kernel versions. It is entirely legitimate for people to bring up potential problems with this scheme. I'm disappointed that you feel it necessary to brush them off just to railroad your proposal through. I don't feel it necessary. But this is not the first trivial maintainer issue I'm being pointed at in this ITP, and I'm getting the impression that some people are doing it deliberately. They're not trivial, and of course we're doing it deliberately. When somebody posts an ITP that proposes to introduce an alternate packaging of an important set of packages, it is entirely appropriate to examine the consequences of that alternate packaging on debian-devel. Brushing people's concerns off as trivial just reinforces the impression that you don't really care about the consequences. I hope this isn't the case. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, 11 Nov 2003 23:54:38 +1100, Jamie Wilkinson [EMAIL PROTECTED] said: This one time, at band camp, Matthew Garrett wrote: Robert Millan wrote: On Sun, Nov 09, 2003 at 08:33:00PM +, Matthew Garrett wrote: klogd will be unable to look up symbols, and ps and top need it for wchan to be displayable. I'm so scared. wchan won't be displayable! What were you saying about sarcasm? The fact remains that it's a bug, and it's a bug that you should already have thought of. Put simply, if this is the level of research you've done, I don't think you're suitable for packaging something as important as the kernel. This doesn't mean that you shouldn't do it (as an academic exercise it'd be a wonderful learning experience, and lessons learned may be well applied else where) - I just don't think it should go anywhere near the archive. Bollocks. Kernels install /boot/System.map-$version. There's a symlink from /boot/System.map to the current version. Actually, that would be a bug. There is no need for such a symlink, and indeed, it would break unrelated packages (like keeping a kernel-image-X.XX package around for safekeeping), so it would be an RC bug. manoj -- The Devil can cite scripture for his purpose. Shakespeare, Merchant of Venice Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Latest version of fvwm packaged
On Tue, 11 Nov 2003 10:02:49 +0100, Lukas Ruf [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] [2003-11-11 09:58]: Hi, The development branch of fvwm is nearing a stable release, and has had a huge number of new features. The maintainer has been very reluctant to package this branch, even in a people.debian.org repository, so I decided to package FVWM 2.5.8 for myself; and I have decided to share this with others as well. The packages are lintian clean, and can be found at: deb http://people.debian.org/~srivasta/ packages/ deb-src http://people.debian.org/~srivasta/ packages/source/ There have been significant new features in the 2.5.X series, and just the GNOME 2 compatibility should be enough to require this in Sarge. These packages were configured as follows (I see no reason not to allow rplay and xrender compatibility in fvwm). As you can see below, I have included as many of the features as I could. can I simply update to the new packages by inserting the deb-statements into my /etc/apt/sources.list ? I'm running unstable. That's the way it is supposed to work. Please remember that you may have to tweak your ~/.fvwm2rc scripts, since a number of new features have been added, and some things have changed. manoj -- Quote from telephone inquiry We're only hiring one summer intern this year and we won't start interviewing candidates for that position until the Boss' daughter finishes her summer classes. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
bbs.51cy.net
http://cs.51cy.net 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28F1 http://cs.51cy.net
Re: RFC: Moving libraries to /lib?
Okay, since discussion on -devel has died, here is what I do: On Mon, Sep 23, 2002 at 10:54:00AM +0200, Torsten Landschoff wrote: I got a bug report on libldap2 which requests to move the libraries to=20 /lib, as /usr can not be unmounted when using PAM/NSS and LDAP (#159771). =20 I don't think this is a good idea.=20 I'll not move the libraries because it is the wrong thing for sure.=20 But I'll add a comment to the README.Debian of libldap2 which tells=20 how to solve the problem, namely using /bin/dash as the default shell. Apart from that I just changed the severity of the bug to normal,=20 reassigned it to bash and merged it with #120340. I wonder why bash really uses getpwuid to get information about the current user, probably the bash developers are a bit paranoid about having the right user data. Are you serious? You're considering bash's use of a published interface to obtain user information to be a bug in bash because it conflicts with how debian wants to organize its file system? Bash doesn't have anything to do with how libc (and ultimately libldap) implements getpwuid. There's nothing in POSIX that says that any file descriptors must be kept open. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.cwru.edu/~chet/
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
At Tue, 11 Nov 2003 22:26:25 +0900, Kenshi Muto wrote: At Tue, 11 Nov 2003 11:59:24 +0100, Martin Schulze wrote: Preparation of Debian GNU/Linux 3.0r2 = An up-to-date version is at http://master.debian.org/~joey/3.0r2/. I am preparing the second revision of the current stable Debian distribution (woody) which will probably be released soon. This report is to allow people to comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. Please, please wait. Before you release r2, we must solve Japanese Watanabe font problem. See http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00142.html Yes, good catch up. ttf-kochi-mincho and ttf-kochi-mincho-naga10 (Bug#214402) aren't reassigned to ftp.debian.org. These package can be replaced by new kochi font (kochi-subst), but if Goto-san hasn't any time for this work, they must be removed. Please answer, Goto-san. This problem affects for: ttf-kochi-mincho, ttf-kochi-mincho-naga10, ttf-kochi-gothic, ttf-kochi-gothic-naga10. I've just uploaded these newer version which has no license problem. Regards, -- gotom
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 11:40:11PM +1100, Jamie Wilkinson wrote: There are already several forks of the Linux kernel in Debian anyway. Robert wishes to attempt to unify them, does that not grant him use of the name 'linux'? No he doesn't. He wants to create a new arbitrary patch set, in a context where arbitrary patch sets have always been given distinct names, and to call it by the vanilla name. It's irresponsible. He doesn't even have the slim excuse of being implicitly the Debian variant, because there would be two. All this can create is confusion. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 12:21:32PM +0100, Robert Millan wrote: How do you propose to do that without changing the package name, and without leaving old System.map junk around for eternity? I don't see how it can be possible. (This is exactly the same question as Matthew asked, of course; but it is an important question relative to this ITP and I want to see it answered.) I don't like turning this ITP into a technical discussion to prove either my dessign is consistent or I'm capable as a maintainer. However I'll respond to your question this time: Place the package files in /usr/lib, and copy them conditionaly (debconf) into /boot. The debconf question would properly explain that if per chooses to update it, then the system must be rebooted promptly. Another option: Place the package files in /boot, but save a backup of them before (preinst). Then prompt the user to reboot through debconf. Or even a combination of the two. So, your solution is to ask Should I break your system now or after the next reboot?. Debconf is not an alternative to fixing the problem. Such questions are still unacceptable bugs. Note that the current kernel packages don't break your system before *or* after rebooting. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 12:45:31PM +0100, Robert Millan wrote: On Mon, Nov 10, 2003 at 07:25:41PM +, Andrew Suffield wrote: On Sun, Nov 09, 2003 at 08:17:58PM +0100, Robert Millan wrote: - I'm not trying to make a package, the package is already made and it works fine. I'm using it right now. Okay, please don't write software or maintain any packages. I can't think of anything more indicative of total inexperience than it works fine. That's subjective. Those are two English words. [Uh. What?] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 02:47:14PM +0100, Robert Millan wrote: However, for the matter of finding out wether there will be much people in that userbase, there's the Popularity Contest. Some people just never learn. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 03:10:14PM +0100, Andreas Metzler wrote: The question was: How do you provide 2.4.x for architecture blah and 2.4.y for architecture foo, which are two versions of the same upstream branch. just to give you a better idea of what we are talking about here, these are the kernel images we provide in unstable: kernel-image-2.2.10-apus | 2.2.10-13 | powerpc kernel-image-2.2.10-powerpc-apus | 2.2.10-13 | source kernel-image-2.2.19-netwinder | 20011109.1| source, arm kernel-image-2.2.19-riscpc | 20011109 | source, arm kernel-image-2.2.20-reiserfs | 2.2.20-4 | i386 kernel-image-2.2.20-reiserfs-i386 | 2.2.20-4 | source kernel-image-2.2.20-sun4cdm| 9 | sparc kernel-image-2.2.20-sun4dm-smp | 9 | sparc kernel-image-2.2.20-sun4u | 9 | sparc kernel-image-2.2.20-sun4u-smp | 9 | sparc kernel-image-2.2.25-amiga | 2.2.25-1 | source, m68k kernel-image-2.2.25-atari | 2.2.25-1 | source, m68k kernel-image-2.2.25-bvme6000 | 2.2.25-1 | source, m68k kernel-image-2.2.25-mac| 2.2.25-1 | source, m68k kernel-image-2.2.25-mac-udeb | 2.2.25-1 | source, m68k kernel-image-2.2.25-mvme147| 2.2.25-1 | source, m68k kernel-image-2.2.25-mvme16x| 2.2.25-1 | source, m68k kernel-image-2.4-386 | 2.4.22-3 | i386 kernel-image-2.4-586tsc| 2.4.22-3 | i386 kernel-image-2.4-686 | 2.4.22-3 | i386 kernel-image-2.4-686-smp | 2.4.22-3 | i386 kernel-image-2.4-generic | 2.4.22-3 | alpha kernel-image-2.4-k6| 2.4.22-3 | i386 kernel-image-2.4-k7| 2.4.22-3 | i386 kernel-image-2.4-k7-smp| 2.4.22-3 | i386 kernel-image-2.4-smp | 2.4.22-3 | alpha kernel-image-2.4.16-lart | 20011222 | source, arm kernel-image-2.4.16-netwinder | 20011222 | source, arm kernel-image-2.4.16-riscpc | 20011222 | source, arm kernel-image-2.4.17-s390 | 2.4.17-3 | source, s390 kernel-image-2.4.17-s390-tape-udeb | 2.4.17-3 | s390 kernel-image-2.4.18-bf2.4 | 2.4.18-6 | i386 kernel-image-2.4.18-i386bf | 2.4.18-6 | source kernel-image-2.4.19-32 | 22.2 | hppa kernel-image-2.4.19-32-smp | 22.2 | hppa kernel-image-2.4.19-64 | 22.2 | hppa kernel-image-2.4.19-64-smp | 22.2 | hppa kernel-image-2.4.19-arm| 2.4.19-6 | source kernel-image-2.4.19-bast | 2.4.19-6 | arm kernel-image-2.4.19-hppa | 22.2 | source kernel-image-2.4.19-ia64 | 020821.2 | source kernel-image-2.4.19-itanium| 020821.2 | ia64 kernel-image-2.4.19-itanium-smp| 020821.2 | ia64 kernel-image-2.4.19-lart | 2.4.19-6 | arm kernel-image-2.4.19-mckinley | 020821.2 | ia64 kernel-image-2.4.19-mckinley-smp | 020821.2 | ia64 kernel-image-2.4.19-netwinder | 2.4.19-6 | arm kernel-image-2.4.19-powerpc| 2.4.19-2 | powerpc kernel-image-2.4.19-powerpc-smp| 2.4.19-2 | powerpc kernel-image-2.4.19-powerpc-udeb | 2.4.19-2 | powerpc kernel-image-2.4.19-r3k-kn02 | 2.4.19-0.020911.7 | mipsel kernel-image-2.4.19-r3k-kn02-udeb | 2.4.19-0.020911.7 | mipsel kernel-image-2.4.19-r4k-ip22 | 2.4.19-0.020911.8 | mips kernel-image-2.4.19-r4k-ip22-udeb | 2.4.19-0.020911.8 | mips kernel-image-2.4.19-r4k-kn04 | 2.4.19-0.020911.7 | mipsel kernel-image-2.4.19-r4k-kn04-udeb | 2.4.19-0.020911.7 | mipsel kernel-image-2.4.19-r5k-ip22 | 2.4.19-0.020911.8 | mips kernel-image-2.4.19-riscpc | 2.4.19-6 | arm kernel-image-2.4.19-riscstation| 2.4.19-6 | arm kernel-image-2.4.19-s390 | 2.4.19-2 | source, s390 kernel-image-2.4.19-s390-udeb | 2.4.19-2 | s390 kernel-image-2.4.20-32 | pa35.3| hppa kernel-image-2.4.20-32-smp | pa35.3| hppa kernel-image-2.4.20-32-udeb| pa35.3| hppa kernel-image-2.4.20-64 | pa35.3| hppa kernel-image-2.4.20-64-smp | pa35.3| hppa kernel-image-2.4.20-64-udeb| pa35.3| hppa kernel-image-2.4.20-amiga | 2.4.20-5 | source, m68k kernel-image-2.4.20-amiga-di | 0.12 | m68k kernel-image-2.4.20-apus | 2.4.20-1 | powerpc kernel-image-2.4.20-atari | 2.4.20-5 | source, m68k kernel-image-2.4.20-bvme6000 | 2.4.20-5 | source, m68k
