Bug#543740: quark: should this package be removed?
On Thu, Aug 27, 2009 at 08:50:30AM +0200, Lucas Nussbaum wrote: On 26/08/09 at 20:38 +0200, Sven Luther wrote: On Wed, Aug 26, 2009 at 06:43:21PM +0200, Lucas Nussbaum wrote: Package: quark Version: 3.21-3.3 Severity: serious User: debian...@lists.debian.org Usertags: proposed-removal Dear Maintainer, While reviewing some packages, your package came up as a possible candidate for removal from Debian, because: * Last maintainer upload in 2005 * 3 NMUs since then * package of limited usefulness (alternatives available, low popcon) Hi Lucas, ... Notice that i am unable to upload quark packages, since i was kicked out of debian like so much dirt, as you well know. The fact that other people have done NMUs as well as the fact that there are no RC bug on the package seems to indeicate that there should be no need to remove it. Of the 3 important bugs : #455803 : contains a patch, and awaits a debian maintainer willing to upload it. #200288 : is normal upstream behaviour. #501168 : i have no clue on this one, maybe one should look at the dependencies. A quick browse at them doesn't show anything triggering this behaviour directly. As for the usefullness, i find it more usable than any of the other possible alternatives, since it does what it needs to do well, with minimal desktop cluttering. The facts that: * #455803 has been waiting for a sponsor for more than a year * you write: As for orphaning it, well, as said, i called for replacer-maintainer when you guys kicked me out, and you can believe that i am not particularly interested in doing anything more, until debian takes a more reasonable stance with regard to me and how debian messed up this whole affair back then. Make me thing that you no longer want to maintain it, and that the package should be orphaned. Is that true ? Whatever. If yes, I will orphan it. It is not going to be removed very soon, but if nobody picks it up, it will be removed from Debian. Alternatively, you could advocate for the end of the email ban, and allow me to feel motivated to do this kind of maintenance again, even though i cannot upload. The punishment i suffer has lived past any kind of usefullness anyway, it has been years, and i think it is past time that you guys forgive the mistakes i made all that time ago. (But since this probably means realizing that it was not fully my fault and that others probably messed up as well, i doubt this will happen). Notice though, that as i am willing to do the maintainership, but not under the current situation where debian has officially said it doesn't want to have anything to do with me, if nobody picks the package up, i think you are all in violation of the social contract :) Sadly, Sven Luther -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543740: quark: should this package be removed?
On Wed, Aug 26, 2009 at 06:43:21PM +0200, Lucas Nussbaum wrote: Package: quark Version: 3.21-3.3 Severity: serious User: debian...@lists.debian.org Usertags: proposed-removal Dear Maintainer, While reviewing some packages, your package came up as a possible candidate for removal from Debian, because: * Last maintainer upload in 2005 * 3 NMUs since then * package of limited usefulness (alternatives available, low popcon) Hi Lucas, ... Notice that i am unable to upload quark packages, since i was kicked out of debian like so much dirt, as you well know. The fact that other people have done NMUs as well as the fact that there are no RC bug on the package seems to indeicate that there should be no need to remove it. Of the 3 important bugs : #455803 : contains a patch, and awaits a debian maintainer willing to upload it. #200288 : is normal upstream behaviour. #501168 : i have no clue on this one, maybe one should look at the dependencies. A quick browse at them doesn't show anything triggering this behaviour directly. As for the usefullness, i find it more usable than any of the other possible alternatives, since it does what it needs to do well, with minimal desktop cluttering. As for orphaning it, well, as said, i called for replacer-maintainer when you guys kicked me out, and you can believe that i am not particularly interested in doing anything more, until debian takes a more reasonable stance with regard to me and how debian messed up this whole affair back then. Sadly, Sven Luther -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#394465: remove unicorn ?
On Sat, Sep 06, 2008 at 04:46:19PM +0200, Thomas Viehmann wrote: Hi, unicorn (binary unicorn-source) is a kernel driver for a DSL adapter. Unfortunately, if fails to build (with the bug being from 2006) with recent kernels, see #394465. About month ago, Nick Leverton got it to compile with 2.6.24 (but not to link with 2.6.25), but could not test whether it works beyond not crashing the kernel upon loading the module. Moreover, no work seems to have been done with 2.6.26 which has been available in Debian since the end of July. As such, I think we should remove unicorn from lenny for now. Well, if you kick out the maintainer out of the debian project, no wonder the package is then left in a bad state. I think elementary decency would have one of those having asked for my expulsion take over the package, and take the responsability of their actions. But somehow i doubt this will happen. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472800: uptades (Re: Bug#472800: gnome-power-manager: same behaviour on sony vaio tz21mn)
On Mon, Jul 21, 2008 at 10:11:01PM +0200, Sven Arvidsson wrote: On Sat, 2008-07-19 at 05:15 +0200, alberto maurizi wrote: I noticed recently that the problem has gone. My laptop hibernated when battery power is critically low. If you do not have any other bug report on this problem you may close this bug. Sven Luther reported the same problem, is it fixed for you also Sven? Sorry, but no, it is not fixed, i let the battery run out, and instead of hibernating, the laptop just died. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472800: uptades (Re: Bug#472800: gnome-power-manager: same behaviour on sony vaio tz21mn)
On Mon, Jul 21, 2008 at 10:11:01PM +0200, Sven Arvidsson wrote: On Sat, 2008-07-19 at 05:15 +0200, alberto maurizi wrote: I noticed recently that the problem has gone. My laptop hibernated when battery power is critically low. If you do not have any other bug report on this problem you may close this bug. Sven Luther reported the same problem, is it fixed for you also Sven? Mmm, i don't know, let me tell you in 50 minutes, when my battery runs out. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412950: Processed: info that it has *not* been dealt with
On Sat, May 17, 2008 at 12:30:58AM +0200, Robert Millan wrote: On Sat, May 17, 2008 at 12:03:39AM +0200, Robert Millan wrote: On Fri, May 16, 2008 at 08:31:40PM +0300, Markus Laire wrote: I'm not a maintainer, but I did have info that bug had not been dealt with, so I reopened the bug with that info. I see that you sent info, but only to the BTS control bot, which prevents it from being reflected in the bug log. I suggest you re-send it. Btw, as for this BTS ping-pong game, Max asked that you file separate bugs instead of reopening this one. This doesn't sound like an unreasonable request, so why not just do that? Robert, i don't really see the reason why this should be done. It's probably helpful to the maintainers to have a separate bug for each violation. I can imagine that working with one [1] huge report while trying to actually fix stuff can be a PITA. Well, i suppose that callign the reporter stupid, as max did is not helpful also. Nor threatenenign me to be blacklisted from the BTS. Max should really calm down, i know he is not agreeing with the firmware split, but this doesn't allow him to be impolite and threatening. I suppose the right way would be to split the bug report, and retitle it for each actual violation case, but hey ... [1] well, actually a few merged reports, but it amounts to the same. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383403: Processed: info that it has *not* been dealt with
On Sat, May 17, 2008 at 11:21:18AM +0200, Robert Millan wrote: On Sat, May 17, 2008 at 09:13:34AM +0200, Sven Luther wrote: On Sat, May 17, 2008 at 12:30:58AM +0200, Robert Millan wrote: On Sat, May 17, 2008 at 12:03:39AM +0200, Robert Millan wrote: On Fri, May 16, 2008 at 08:31:40PM +0300, Markus Laire wrote: I'm not a maintainer, but I did have info that bug had not been dealt with, so I reopened the bug with that info. I see that you sent info, but only to the BTS control bot, which prevents it from being reflected in the bug log. I suggest you re-send it. Btw, as for this BTS ping-pong game, Max asked that you file separate bugs instead of reopening this one. This doesn't sound like an unreasonable request, so why not just do that? Robert, i don't really see the reason why this should be done. But the maintainer does, and for a change this request doesn't conflict with the Social Contract. Why are we discussing on whether we prefer one bug or multiple bugs when we have actual SC violations right now that need fixing? What does it gain to close the bug that contains the history of the problem ? It's probably helpful to the maintainers to have a separate bug for each violation. I can imagine that working with one [1] huge report while trying to actually fix stuff can be a PITA. Well, i suppose that callign the reporter stupid, as max did is not helpful also. Nor threatenenign me to be blacklisted from the BTS. Max should really calm down, i know he is not agreeing with the firmware split, but this doesn't allow him to be impolite and threatening. IIRC he was threatening Markus, not you. 15:22:53 maks svenl: don't fuck with the bts or get your email blacklisted kthx Anyway, I suppose by now he realises that was completely inappropiate, and actually counterproductive. Nice of you to have such good faith in the socialness of the members of the kernel team. I have learned not to have such faith myself though. Now can we please get this over with? fine with me, but then, as always, the other side will never forget, and issues will not improve until they recognize that their behaviour is not appropriate, which i have some serious doubt they have the strength of character to do. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412950: bug still seems to be present, so it should stay open, even if you tag it as wont-fix.
reopen 412950 thanks Hi Max, This bug has not been fixed, so please keep it open, and tag it as wont-fix or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242866: Closure
On Fri, May 16, 2008 at 02:29:10AM -0700, Steve Langasek wrote: On Fri, May 16, 2008 at 09:26:03AM +0200, Jonas Smedegaard wrote: Rest assured that max speaks on behalf of the Debian _kernel_ team, not all of Debian. No, he speaks on behalf of himself. Well, together with waldi, he is the kernel team, or what is left of it. And since waldi doesn't speak much, ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412950: closed by maximilian attems [EMAIL PROTECTED] (Re: drivers containing firmware blobs)
On Thu, May 15, 2008 at 02:57:06PM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the linux-2.6 package: #242866: linux-2.6: [legal] the current kernel tarball doesn't respect the GR 2006-007 It has been closed by maximilian attems [EMAIL PROTECTED]. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact maximilian attems [EMAIL PROTECTED] by replying to this email. -- 242866: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=242866 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems Date: Thu, 15 May 2008 16:44:56 +0200 From: maximilian attems [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: drivers containing firmware blobs Message-ID: [EMAIL PROTECTED] Version: 2.6.24-1 The Debian Kernel Team is guilty of uploading a disjointed kernel. For the record Bastian Blank [EMAIL PROTECTED] coded the infrastructure for the stripping and the stripping itself. The FTP masters threatened to block any future Linux uploads or alternatively would launch an NMU (non maintainer upload) stripping the affected drivers. So, the firmware have been removed and the kernel is now conformant to the decision of the developpers, expressed in the GR ? Or conformant to the stretched interpretation the Release Managers held back then in order to not lose face ? I very strongly disagreed with that decision, but the Debian Developer made their position clear in the General Resolution 2006-007, which is No, the Debian Developers where mislead and the vote was manipulated, so that it doesn't represent the true opinion of the DDs. Most of them voted because they where sick of the flamewars, and didn't really look at the content of the GR. binding for us. In the long run it might be a win for Free Software - history will tell. In the short term this is an annoyance for existing hardware driver support. As expected none of the vocal minority, aka Mr. Nerode and Mr. Doolittle, Don't forget Manoj, who threatened to fork the kernel package if we didn't remove the non-free firmware. demanding DFSG freeness helped to work out this transition nor to cleanup the created mess. The stripping presents an additional maintenance burden. But I'm sick of the arguments. Rather then fighting I'd like to see people working together to make things work, both on the licensing side (BSD firmware) and on the code side (firmware_request()), neither is easy. I proposed to help do this myself, and had a hard time pushing a conciliatory position which would satisfy everyone, but with the result that we know. Too sad. Hopefully you can someday forget the past, and we can again work together on this and other debian stuff. I'm thus closing the bug reports regarding firmware blobs and pointing the reporters to the following wiki page in order to finaly help a bit - http://wiki.debian.org/KernelFirmwareLicensing Possible DFSG violations in current and future linux-2.6 uploads should be filed seperately. Why was it not closed in the kernel upload which resolved all issues mentioned in that GR ? I disagree about this bug being closed if the issue has not been fixed. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478478: gnome-terminal: copy/paste using the middle mouse button is broken.
Package: gnome-terminal Version: 2.22.1-1 Severity: grave Justification: renders package unusable When copy pasting using from a gnome terminal, selecting a bit of text, and using the middle mouse button to paste does not work. Doing the same from xfce4-terminal or plain xterm does work, and even pasting to gnome-terminal does work. Using the right-mousr-button contextual menu copy/paste usually works though, but i also had cases where it didn't work. Don't remember exactly the details though. When pasting with the middle mouse button, the previous selection is kept and pasted. The reason for the severity, is dual, i consider a terminal without proper copy/paste support barely useable, and more importantly, there is a risk of security leaks or plain destructive error through bad copy/pasting. It may seem a bit exagerated though, so ... Friendly, Sven Luther -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-terminal depends on: ii gnome-control-center 1:2.22.0-2utilities to configure the GNOME d ii gnome-terminal-data2.22.1-1 Data files for the GNOME terminal ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libbonobo2-0 2.22.0-1 Bonobo CORBA interfaces library ii libc6 2.7-10GNU C Library: Shared libraries ii libgconf2-42.22.0-1 GNOME configuration database syste ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.1-2 The GLib library of C routines ii libgnome2-02.20.1.1-1The GNOME 2 library - runtime file ii libgnomeui-0 2.20.1.1-1The GNOME 2 libraries (User Interf ii libgtk2.0-02.12.9-2 The GTK+ graphical user interface ii liborbit2 1:2.14.12-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.20.2-2 Layout and rendering of internatio ii libstartup-notification0 0.9-1 library for program launch feedbac ii libvte91:0.16.13-1 Terminal emulator widget for GTK+ ii libx11-6 2:1.0.3-7 X11 client-side library ii libxrender11:0.9.4-1 X Rendering Extension client libra ii scrollkeeper 0.3.14-16 A free electronic cataloging syste Versions of packages gnome-terminal recommends: ii yelp 2.20.0-2 Help browser for GNOME 2 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382658: Not building for powerpc any more
On Mon, Apr 14, 2008 at 10:09:38PM -0400, Rick Thomas wrote: Don't panic! I believe this is about a program called xaralx. The clue is in the bug report http://bugs.debian.org/cgi-bin/bugreport.cgi? bug=382658 This is still referenced in the first member of this thread to appear in debian-powerpc, but has somehow been dropped from followups. The debian-powerpc thread is a continuation of a thread that originated in a list having to do with xalarax. If I understand correctly, endian problems prevent xalarax from running correctly on PowerPC (and, presumably any other big-endian processor, such as Sparc or S/370). So they are talking abut not building xalarax for PowerPC (and presumably...) at least until somebody gets around to constructing the necessary patches to xalarax to make it endian independent. Notice that the description speaks about a mature system, i don't think that something so endian-buggy that it won't build on powerpc, and probably not also on the other bigendian arches, should use the term mature in its description. Please forward to the list, as i can't post for obvious reasons. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472800: gnome-power-manager: same behaviour on sony vaio tz21mn
Package: gnome-power-manager Version: 2.20.2-3 Followup-For: Bug #472800 I am seeing the same behaviour on my sony vaio laptop. Historically, this laptop had an etch system installed and at FOSDEM in late february, i migrated to lenny. With etch, gnome-power-manager was rather limited, it didn't catch the power button press, and suspend-to-ram didn't work, even though doing it by hand in /sys/power worked (well, it doesn't wake up, but you can at least put it to sleep). When i upgraded to lenny, i first had the dialog open when pressing the power button, but there is something else which powers down the laptop even without interacting with the dialog after a couple of seconds. I remember having the low-battery dialog appear, but i don't know if it was before or after the switch to lenny, but it has been broken since some weeks now. I attach a log containing both the dmesg output as well as the lspci info. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-vserver-powerpc64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) LSPCI OUTPUT === 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit Ethernet Controller (rev 13) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 09:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba) 09:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04) 09:04.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11) 09:04.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11) DMESG OUTPUT Linux version 2.6.24-1-686 (Debian 2.6.24-4) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080114 (prerelease) (Debian 4.1.2-19)) #1 SMP Mon Feb 11 14:37:45 UTC 2008 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 3f68 (usable) BIOS-e820: 3f68 - 3f70 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed0 - fed00400 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed9 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff00 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f6ba0 Entering add_active_range(0, 0, 259712) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 259712 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 259712 On node 0 totalpages: 259712 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 237 pages used for memmap HighMem zone: 30099 pages, LIFO batch:7 Movable zone: 0 pages used for memmap DMI
Bug#472800: gnome-power-manager: same behaviour on sony vaio tz21mn
On Fri, Mar 28, 2008 at 09:10:07AM +0100, Josselin Mouette wrote: On ven, 2008-03-28 at 08:44 +0100, Sven Luther wrote: I am seeing the same behaviour on my sony vaio laptop. This bug looks unrelated to me. Hi Josselin, I am unsure from the above if the unrelated is the total bug, or the below info, which i provided only in an informative way, since it may be related to the event handling (but then i am rather clueless in x86 hardware and acpi). Anyway, i suppose you meant the power button info here. When i upgraded to lenny, i first had the dialog open when pressing the power button, but there is something else which powers down the laptop even without interacting with the dialog after a couple of seconds. I remember having the low-battery dialog appear, but i don't know if it was before or after the switch to lenny, but it has been broken since some weeks now. Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') It looks like you didn’t upgrade everything to lenny. The acpi package Well, i did an apt-get dist-upgrade, if not everything got upgraded, this may be a migration bug ? from stable will happily shutdown your computer when it detects some events instead of letting policy daemons do the jobs. This should not be the case if you upgrade this package as well. $ dpkg -l | grep acpi ii acpi 0.09-4 displays information on ACPI devices ii acpi-support 0.103-5 scripts for handling many ACPI events ii acpi-support-base 0.103-5 scripts for handling base ACPI events such as the power button ii acpid 1.0.4-7.1 Utilities for using ACPI power management This seems to be the latest version, accordying to the pts. Friendly, Sven Luther
Bug#472417: gcompris: doesn't start because of missing XF86VidMode, -x doesn't help
Package: gcompris Version: 8.4.2-1 Severity: grave Justification: renders package unusable gcompris fails to start on an uptodate lenny i386 (today's apt-get upgrade doesn't show anything needing upgrading). The error message is the following : gcompris exec_prefix NULL XF86VidMode: Compiled with XF86VidMode. If you have problems starting GCompris in fullscreen, try the -x option to disable XF86VidMode. ** (process:30857): WARNING **: Binary relocation disabled package_data_dir = /usr/share/gcompris/boards package_locale_dir = /usr/share/locale package_plugin_dir = /usr/lib/gcompris package_python_plugin_dir= /usr/share/gcompris/python Config file migration '/home/sven/.gcompris/gcompris.conf' - '/home/sven/.config/gcompris/gcompris.conf' Database migration '/home/sven/.gcompris/shared/profiles/gcompris_sqlite.db' - '/home/sven/.config/gcompris/gcompris_sqlite.db' Logs migration '/home/sven/.gcompris/gcompris.log' - '/home/sven/.config/gcompris/gcompris.log' Infos: Config dir '/home/sven/.config/gcompris' Users dir '/home/sven/My GCompris' Database '/home/sven/.config/gcompris/gcompris_sqlite.db' But the xorg package is complete. This system was originally an etch system, and gcompris worked just fine on it, but it has been having this problem ever since i did a lenny upgrade during the FOSDEM time. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-vserver-powerpc64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426262: linux-2.6: mkvmlinuz support is broken.
Package: linux-2.6 Version: 2.6.21-4 Severity: critical Justification: breaks the whole system The following patch is needed to include the wrapper in the mkvmlinuz support files. Without this, the kernel is not bootable on hardware which support mkvmlinuz, thus causing a risk of breaking the whole system. I tried to apply the attached patch directly to the kernel svn, but someone removed me from the kernel team, in another act of agression against me, so i am forced to attach it here. Sad that even the kernel team is joining the witch hunt against me, Sven Luther -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-powerpc64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Index: debian/patches/debian/powerpc-mkvmlinuz-support-powerpc-2.patch === --- debian/patches/debian/powerpc-mkvmlinuz-support-powerpc-2.patch (révision 8806) +++ debian/patches/debian/powerpc-mkvmlinuz-support-powerpc-2.patch (copie de travail) @@ -35,6 +35,6 @@ +quiet_cmd_mkvmlinuz = INSTALL mkvmlinuz support files + cmd_mkvmlinuz = cp -f $(filter-out FORCE,$^) $(INSTALL_MKVMLINUZ) + -+mkvmlinuz_support_install: $(wrapperbits) ++mkvmlinuz_support_install: $(wrapperbits) $(wrapper) + @mkdir -p $(INSTALL_MKVMLINUZ) + $(call cmd,mkvmlinuz) Index: debian/patches/series/5 === --- debian/patches/series/5 (révision 0) +++ debian/patches/series/5 (révision 0) @@ -0,0 +1,3 @@ +- debian/powerpc-mkvmlinuz-support-powerpc-1.patch ++ debian/powerpc-mkvmlinuz-support-powerpc-2.patch + Index: debian/changelog === --- debian/changelog(révision 8806) +++ debian/changelog(copie de travail) @@ -1,3 +1,10 @@ +linux-2.6 (2.6.21-5) UNRELEASED; urgency=low + + [ Sven Luther ] + * [powerpc] fixed the mkvmlinuz patch, don't forget the wrapper script. + + -- Sven Luther [EMAIL PROTECTED] Sun, 27 May 2007 16:26:58 +0200 + linux-2.6 (2.6.21-4) unstable; urgency=low * [powerpc] Fix mkvmlinuz support.
Bug#426262: linux-2.6: mkvmlinuz support is broken.
On Sun, May 27, 2007 at 05:51:40PM +0200, Bastian Blank wrote: On Sun, May 27, 2007 at 05:00:10PM +0200, Sven Luther wrote: The following patch is needed to include the wrapper in the mkvmlinuz support files. Without this, the kernel is not bootable on hardware which support mkvmlinuz, thus causing a risk of breaking the whole system. The wrapperbits spec includes wrapper, so this change is a NOP: | wrapper :=$(srctree)/$(src)/wrapper | wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \ | $(wrapper) FORCE Bastian So, why is the wrapper not present in the package : $ dpkg -L linux-image-2.6.21-1-powerpc ... /usr/lib/linux-image-2.6.21-1-powerpc /usr/lib/linux-image-2.6.21-1-powerpc/crt0.o /usr/lib/linux-image-2.6.21-1-powerpc/wrapper.a /usr/lib/linux-image-2.6.21-1-powerpc/of.o /usr/lib/linux-image-2.6.21-1-powerpc/empty.o /usr/lib/linux-image-2.6.21-1-powerpc/zImage.lds /usr/lib/linux-image-2.6.21-1-powerpc/zImage.coff.lds /usr/lib/linux-image-2.6.21-1-powerpc/addnote /usr/lib/linux-image-2.6.21-1-powerpc/hack-coff /usr/lib/linux-image-2.6.21-1-powerpc/mktree ... $ dpkg -L linux-image-2.6.21-1-powerpc ... Version: 2.6.21-4 ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421052: ocaml-sqlite3 - FTBFS: ocamlopt: Command not found
On Thu, Apr 26, 2007 at 07:32:21AM +0200, Bastian Blank wrote: Package: ocaml-sqlite3 Version: 0.16.0-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of ocaml-sqlite3_0.16.0-1 on debian-31.osdl.marist.edu by sbuild/s390 98 [... ] make[1]: Entering directory `/build/buildd/ocaml-sqlite3-0.16.0' ocamlc -pp camlp4o -c sqlite3.mli ocamlopt -pp camlp4o -c sqlite3.ml make[1]: ocamlopt: Command not found make[1]: *** [sqlite3.cmx] Error 127 make[1]: Leaving directory `/build/buildd/ocaml-sqlite3-0.16.0' make: *** [install] Error 2 ** Build finished at 20070425-0516 FAILED [dpkg-buildpackage died] s390 doesn't support the native code compiler, so ocamlc should have been chosen. I suppose ocaml-sqlite3 does not support proper ocamlopt checking, is thus violating the ocaml policy, and will fail on other non-native arches (m68k, ...) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
On Sat, Mar 31, 2007 at 03:11:09PM +0200, Andreas Barth wrote: * Steve Langasek ([EMAIL PROTECTED]) [070331 12:59]: On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote: I would say (although I'm by any means not kernel expert) that your patch looks good and I _strongly_ recommend to include it in etch r0 (!!)... You're the release manager,... so you should get managed this :-) It wouldn't be appropriate for me to push this without the consent of the rest of the kernel team just because I'm the release manager; I'm not even an amd64 porter, this should be signed off on by the folks who are actually responsible for the amd64 kernel first. But regardless, there are no plans for another kernel update before etch r0, and including one is likely to delay the release. I'm of the opinion that this bug does not justify a delay at this point. With the consent of the kernel team and the stable release managers, I'm happy to commit this patch to the queue for the next kernel update though, so it can be included in etch r1. BTW, we intended to have frequent kernel uploads to proposed-updates, and frankly speaking, I personally don't mind to already have a newer kernel in proposed-updates during the release, but that's something I want to have signed-off by Martin. The ideal would have been a framework where we could build new kernels and have it integrated within a few days only. I gave a speach about this at FOSDEM, of how we could use the initramfs incremental nature, to separate fully the kernel module .udebs from the rest of d-i, and have actual d-i images which are daily built, and usable independently of the kernel used. This is already the second release where such problems happen, so let's hope that people get more reasonable about trying to solve this through the available technical solution for lenny. Because *IT IS POSSIBLE* :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
On Sat, Mar 31, 2007 at 08:18:26PM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [070331 16:03]: The ideal would have been a framework where we could build new kernels and have it integrated within a few days only. I gave a speach about this at FOSDEM, of how we could use the initramfs incremental nature, to separate fully the kernel module .udebs from the rest of d-i, and have actual d-i images which are daily built, and usable independently of the kernel used. Sven, sorry but this doesn't have anything to do with the installer now. But that we refrain from making new uploads of the kernel less than a week prior to release - for the simple reason the kernel *is* a central component. So what ? The reality is that all progress in this direction was stoped cold one year ago, with the consequences that we know, and that we face again the exact same situation we had for sarge, which wwas released with a known security hole. Hurt, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Mon, Mar 12, 2007 at 11:25:13PM -0700, Steve Langasek wrote: So regrettably, this bug went more or less unnoticed on the 'kernel' pseudopackage until now, and it does appear (based on the upstream discussion) to affect the etch kernels. And in addition to it being noticed after the upload of 2.6.18.dfsg.1-11, there also doesn't seem to be a real upstream fix available for the problem yet. There does seem to be a workaround available though, which is iommu=soft. At the moment, I'm doubtful that we could change the kernel to force this setting on only the nvidia chipsets in time for etch. Should we instead tag this bug etch-ignore, and refer the iommu=soft workaround to the release notes? Could this also be related to my #414580 problems ? Will try the iommu=soft option now. Mmm, ... No, iommu=soft doesn't seem to help there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413184: [Parted-maintainers] Bug#413184: [powerpci/mac] partman-md appears to not write back the raid flag to partitions.
On Tue, Mar 06, 2007 at 02:55:11AM -0800, Steve Langasek wrote: I've found some time to confirm for myself that this patch fixes the problem of not being able to set the RAID flag in partman. I've tweaked the patch slighly to tighten it up; the final version is attached. I'll upload this NMU to incoming shortly. nice catch. I am still curious that this issue if present in libparted was seen from partman and not from parted itself. No wonder i didn't find anything in the partman code himself. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412950: linux-2.6: [legal] the current kernel tarball doesn't respect the GR 2006-007
Package: linux-2.6 Severity: serious Justification: http://www.debian.org/vote/2006/vote_007 Well, in http://www.debian.org/vote/2006/vote_007, we voted about the kernel firmwares, and among others claimed : 3. We assure the community that there will be no regressions in the progress made for freedom in the kernel distributed by Debian relative to the Sarge release in Etch and : 4. ... as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. Both of these restrictions are not respected by the current linux-2.6 source tarball, and the tg3 firmware driver in particular. The tg3 firmware was stripped from the sarge kernel, it is a non-free but redistributable binary blob, and this is thus a regression with regard to the sarge release. Secondly, the tg3 firmware licence is : * Firmware is: * Derived from proprietary unpublished source code, * Copyright (C) 2000-2003 Broadcom Corporation. * * Permission is hereby granted for the distribution of this firmware * data in hexadecimal or equivalent format, provided this copyright * notice is accompanying it. which would never pass the DFSG in any way. The licence clearly state it is a binary derived from unpublished source code, and neither the source code is available, nor is there any right of modification involved in it. It is astounding how, Steve Langasek as the lead RM, specifically asked for a GR on the subject in order to know how to act as RM, and then, even before the vote finished, claimed he would not respect it. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397973: Bug still present
tags 397973 + confirmed thanks I just confirmed that this bug is still present in today's d-i (daily built from the SVN, r45447). We booted the Xserve on the serial console, did the installation normally, and in partman created the RAID partition on a mac partition table. This failed to create the RAID flag, and thus partman-md failed to detect the disks, with the error message shown in earlier reports. Going into a shell, setting the flag by hand, and then going back to partitioning and it works fine, so maybe this could be added to the erratas. Notice again that there is absolutely nothing in reproducing this which needs powermac hardware to test, and i am sure that i can even be reproduced in quemu or vmware. You just need to chose a mac partition table, and you will face this bug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412723: yaboot-installer: yaboot sets wrong partition number in LVM/RAID situations.
Package: yaboot-installer Version: 1.1.9 Severity: critical Tags: d-i Justification: breaks the whole system When doing an LVM over RAID install on an apple XServe, we have three partitions : sd[ab]2 - the yaboot partition, sd[ab]3 - /boot and sd[ab]4 the LVM partition, which holds the root. But / is on a LVM device, and /boot on a RAID1 device, which yaboot knows how to read, since a RAID1 partition will be seen as a normal partition individually. The problem is due to the fact that our /boot is in /dev/md0, and that we want yaboot to look at the partitions containing this RAID1 partition, namely /dev/sd[ab]3. This leaves the system unbootable on a reboot, thus the severity of this bug report. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
tags 403136 + d-i tags 403136 + needhelp thanks Well, After speaking some with various folks, and someone else testing the same d-i which failed here on other XServe's, altough maybe not from the same generation (mine is from september 2005 i was told), i became suspicious, and brang the machine to an apple technical center, for defect testing. The machine came back today, and it was working perfectly, passed all apple hardware diagnostic tests, and ran full tests of mac-os-x during various days without problems. Furthermore, YDL 4.1 installs fine, and also has no problems whatsoever with the (somewhat older) udev installation there, and since this is an issue which surfaced around november rather suddenly (it was in a datacenter a couple of weeks, then upgraded, and at the first reboot, everything broke), i suspect it is indeed some strange udev issue. Let's again summarize the situation : 1) udev does not create the /dev/sd* device nodes, either in initramfs-tools or in d-i. Probably other nodes are affected. 2) the udev d-i scsi-devfs.sh scripts, which is in charge of creating that node, dies when writing to stdout, which is piped to udevd. 3) ubuntu (of late november) exhibited the same problem. 4) yaird did not work, but for some other reason (not recognizing a given node, didn't investigate more). This makes the box fully unusable and unsuported both in d-i and in normal debian, thus the RC status, furthermore something very strange is going on with udev. Next step would be : 1) write a program writing to stdout and dropping the actual error message somewhere. 2) contact udev author and ask for his help, since Marco said he didn't have a further clue, and this may be an upstream problem. 3) fix yaird to work on it, and see if the machine is stable with yaird and without udev. More to this once i have the box back, and am back from the Solution Linux show in paris. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Fri, Jan 26, 2007 at 11:11:45AM +0100, Marco d'Itri wrote: On Jan 26, Sven Luther [EMAIL PROTECTED] wrote: 1) write a program writing to stdout and dropping the actual error message somewhere. Just add something like this to the top of the affected scripts: exec /dev/xxx.log 21 It tells me that the pipe was closed by the other side, not very helpful, the other side being udevd. The idea was to try to find out more about the exact error, but i guess maybe adding explicit debugging to udevd is the only way out here. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Fri, Jan 26, 2007 at 11:52:12AM +0100, David Härdeman wrote:
On Fri, Jan 26, 2007 at 10:52:39AM +0100, Sven Luther wrote:
Next step would be :
1) write a program writing to stdout and dropping the actual error message
somewhere.
How about this:
#include stdio.h
#include stdlib.h
#include errno.h
#include string.h
#define LOGFILE /stdouttest.log
#define TESTMSG This is a test string\n
int
main(int argc, char **argv, char **envp)
{
FILE *logfile;
int printerrno;
char *printerror;
int retval = EXIT_FAILURE;
int result;
/* Setup a log file */
logfile = fopen(LOGFILE, a);
if (!logfile)
exit(retval);
fprintf(logfile, Program %s started\n, argv[0]);
/* Print to stdout */
result = fprintf(stdout, TESTMSG);
/* Log results */
if (result 0) {
printerrno = errno;
printerror = strerror(printerrno);
fprintf(logfile, Printing failed (%i): %s\n,
printerrno, printerror);
} else if (result strlen(TESTMSG)) {
fprintf(logfile, Printing was truncated to %i bytes\n,
result);
} else {
fprintf(logfile, Printing successful\n);
retval = EXIT_SUCCESS;
}
/* We're done */
fclose(logfile);
exit(retval);
}
Thanks, i will try, but i won't have time until i am back from solution linux
next thursday.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407925: evolution: when out of disk space, create dialog storm which freezes the box
Package: evolution Version: 2.6.3-3 Severity: critical Justification: causes serious data loss While i was compiling stuff, i got a call and was updating an apointment i had in the evolution calendar. The compilation caused my /home to be full, and as thus, evolution was unable to update the apointment. But instead of opening a dialog informing me about the issue, and let me free some space, it created a dialog storm, which left the box fully frozen (it was a 1Ghz powerbook, with 512MB of ram), leaving me unable to move away from evolution, unable to switch to a VT console, unable to even kill X with the ctr-alt-del combo (well, maybe due to apple thinking there is no need for both backspace and del, not sure), leaving me no choice but to reboot the machine. This caused the loss of all the not-yet-saved data, thus the severity. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages evolution depends on: ii dbus 1.0.2-1simple interprocess messaging syst ii evolution-common 2.6.3-3architecture independent files for ii evolution-data-server 1.6.3-3evolution database backend server ii gconf22.16.0-3 GNOME configuration database syste ii gnome-icon-theme 2.14.2-2 GNOME Desktop icon theme ii gtkhtml3.83.12.1-2 HTML rendering/editing library - b ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.12.4-1 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6Open-source version of SGI's audio ii libavahi-client3 0.6.15-2 Avahi client library ii libavahi-common3 0.6.15-2 Avahi common library ii libavahi-glib10.6.15-2 Avahi glib integration library ii libbonobo2-0 2.14.0-3 Bonobo CORBA interfaces library ii libbonoboui2-02.14.0-5 The Bonobo UI library ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libcamel1.2-8 1.6.3-3The Evolution MIME message handlin ii libdbus-1-3 1.0.2-1simple interprocess messaging syst ii libdbus-glib-1-2 0.71-3 simple interprocess messaging syst ii libebook1.2-5 1.6.3-3Client library for evolution addre ii libecal1.2-6 1.6.3-3Client library for evolution calen ii libedataserver1.2-7 1.6.3-3Utility library for evolution data ii libedataserverui1.2-6 1.6.3-3GUI utility library for evolution ii libegroupwise1.2-10 1.6.3-3Client library for accessing group ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared ii libexchange-storage1.2-1 1.6.3-3Backend library for evolution cale ii libfontconfig12.4.1-2generic font configuration library ii libfreetype6 2.2.1-5FreeType 2 font engine, shared lib ii libgconf2-4 2.16.0-3 GNOME configuration database syste ii libgcrypt11 1.2.3-2LGPL Crypto library - runtime libr ii libglade2-0 1:2.6.0-4 library to load .glade files at ru ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgnome-keyring0 0.6.0-3GNOME keyring services library ii libgnome-pilot2 2.0.15-0.1 Support libraries for gnome-pilot ii libgnome2-0 2.16.0-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeprint2.2-02.12.1-7 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.12.1-4 GNOME 2.2 print architecture User ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-02.14.2-4 GNOME virtual file-system (runtime ii libgnutls13 1.4.4-3the GNU TLS library - runtime libr ii libgpg-error0 1.4-1 library for common error values an ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user interface ii libgtkhtml3.8-15 3.12.1-2 HTML rendering/editing library - r ii libhal1 0.5.8.1-6 Hardware Abstraction Layer - share ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libldap2 2.1.30-13.2OpenLDAP libraries ii libnm-glib0 0.6.4-6network management framework (GLib ii libnotify1
Bug#407795: libxklavier: Error during activation of the XKB configuration - only USA keymap available.
is a RC bug in my opinion, and need to be fixed before the release of etch. This may be related to : 5) #399974: libxklavier -unable to switch to national keyboard not sure, but he made no mention of the dialog, so it may be another issue, thus filing a separate bug report. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397973: #397973 [powerpci/mac] partman-md appears to not write back the raid flag to partitions.
On Fri, Jan 12, 2007 at 07:51:40PM +0100, Frans Pop wrote: This issue may possibly be fixed by partman-base (101). Please test. I will, will need to see if i can manually work around #403136 to reach the partitioning step. If i create the sd* devices by hand it usually works, but dies horribly during base-install, but this should be enough to test this fix. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397973: #397973 [powerpci/mac] partman-md appears to not write back the raid flag to partitions.
On Fri, Jan 12, 2007 at 07:51:40PM +0100, Frans Pop wrote: This issue may possibly be fixed by partman-base (101). Please test. Well, i have done an d-i install, created the devices by hand, chosen in expert mode unstable, which i suppose will pull in the above version, but haven't really found out a way to test it (please add the version to syslog when they get installed, this would be very helpful), and have to say that the problem still persists. I create two 1GB raid partitions, and try to create a RAID1 device, and find the No RAID partitions available dialog. When i go into parted, i notice that the raid flag has gone, replaced with a swap flag, which seems strange. Both of them used to be swap partitions prior to the test though. I set the raid flags back, go back to partman, who mentions me a dialog please make sure you are happy with the partitions table and commit it (paraphrased i forgot to copy, but you get the meaning), and the raid flags are gone again. To work around this, you have to go into parted, after the first partman-md dialog, and set the raid flags. The funny thing is that the raid flag is shown in the main partman manual partitioning dialog, so i suppose it is in the database, unless these flags are detected and not taken from the partman datas or something. Without this, i would have thought that partman had the non-raid stored in its data, and when doing the write to disk, did write the non-raid flag (well, erased the flag i guess). It would be really helpful if this could be reproduced on an x86 box, with a mac partition table (expert mode, chose pmac as partition table format for the disk). So, unless i made a mistake, i confirm that this bug is still present. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: Further investigation : The stdout pipe gets killed for some reason ...
On Thu, Dec 28, 2006 at 02:38:47PM +0100, Marco d'Itri wrote: Can you provide more info about this alleged bug? What more information do you want ? I think you said this was in the camp of upstream now ? And you asked me to contact them. Which admitelly i have not yet done, but which i also believe is somehow the job of the package maintainer. If not then it should be downgraded or closed. I strongly object to this. As said, i installed Yellow Dog Linux, and it had no such problem, so i think we can exclude any kind of hardware problem, and this is a serious regression. If you need more help with debugging you can find me on IRC. Yeah, just right now i don't have time for this, i need to find it though, i need the box to go into production again ASAP. But any hint about how to find out why udevd kills the pipe would be welcome, i was told to write a C program which writes to stdout, and reports the exact error message. Also, another idea would be to debug the problem on the udevd side, but the quick glance i had was not enough to allow me to do this in a meaningful way. Like always, time is missing to further investigate this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404855: kernel-package ability to chose the ramdisk generator in kernel-img.conf seems to have dissapeared.
Package: kernel-package Version: 10.065 Severity: serious Justification: kernel policy It seems that the configurable choice of the ramdisk generator, which we discussed a year ago, has dissapeared. We reached the conclusion that it would be configurable in kernel-img.conf, but i have looked at the man pages as well as the source code, and could not find any way to do this. Since when has this feature dissapeared in kernel-package, and if it has not, why is it so undocumented ? I notice : initrd.mk: This snippet uses hard coded version based heuristics to determine which set of tools would be viable for providing an initrd or initramdisk for the kernel being built, if initrd's are selected by the user as desired. which doesn't seem to make any sense to me, especially the last sentence, and which in general hints to me that this is not configurable anymore, but hard-coded. The last sentence is contradictory, and may mean exactly the contrary though. In any case, no obvious documentation of this feature was found, and since the kernel team in conjunction with the kernel-package maintainer and the various ramdisk-generator maintainers decided that this should be configurable in /etc/kernel-img.conf, this missing feature represents a serious violation of the kernel packaging policy, thus the severity. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages kernel-package depends on: ii dpkg 1.13.24package maintenance system for Deb ii dpkg-dev 1.13.24package building tools for Debian ii file 4.17-5 Determines file type using magic ii gcc [c-compiler] 4:4.1.1-13 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-13 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.1-19 The GNU C compiler ii gettext 0.16.1-1 GNU Internationalization utilities ii make 3.81-2 The GNU version of the make util ii perl 5.8.8-7Larry Wall's Practical Extraction ii po-debconf1.0.8 manage translated Debconf template Versions of packages kernel-package recommends: ii bzip21.0.3-6 high-quality block-sorting file co ii libc6-dev [libc-dev] 2.3.6.ds1-8 GNU C Library: Development Librari -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Sun, Dec 24, 2006 at 03:07:55AM +0100, Frederik Schueler wrote: Hi *, this is indeed a severe issue which requires all our attention and care to solve or circumvent in order for nobodies boxes to get any harm, you know how expensive these laptops are. I basically see 3 solutions/workarounds: 1. the brutal one: deactivate ACPI in 2.6.18, have the bios keep control of the fans - better a noisy laptop until I upgrade the kernel than a fried box. 2. port 2.6.19 ACPI - noop because way too much work, unless someone crazy enough to accomplish this task. 3. go for 2.6.19 As said, i can imagine another solution. 4. Provide both a stable 2.6.18, and a easily usable backported 2.6.19 (or newer) kernel, which would be built for etch, but built out of our trunk/unstable/testing archive. Then we can add a bit of logic into d-i's base-installer, so that the kernel installation step detects the laptops which have this problem (do we know how to detect them ?), and inform the user and install the newer kernel. Alternatively, we can go 1, create a -noacpi flavour usable on those laptops, and install that flavour in d-i. This would probably be the easiest solution. Documenting arbitrary breakage in the release notes is not a solution, just consider how well manuals are usually read (if at all). Users will end with damaged hardware and blame us for it. /me agrees. We released woody with disabled ide dma due to somewhat similar issues (boxes hanging), so disabling ACPI in 2.6.18 and going for a 2.6.19 based 4.0r1 ASAP seems the best thing to me personally, but this is of course up for discussion. I have been thinking of another solution, but since i am kind of ignored or this is a subject a certain amount of the powers-who-be don't want me to mention, i doubt it will be gaining much momentum. I am going to propose a talk at fosdem about these ideas, where issues and everything else can be discussed. The idea goes as follows : 1) We take the kernel out of the main debian archive, into a separate kernel pool. This pool would hold the kernel and all assorted modules or abi-depending packages. This pool would hold per-abi subpools (dists/kernel/2.6.18-3, dists/kernel/2.6.19-1, etc). 2) Eventually, we have some symlink or mirroring logic which would allow the chosen kernel to be accesible from the main archives. This means we can prepare kernels in this kernel pool, test it, and once it is ready, do a one-pule moving of those packages (without rebuild) into the main pools. 3) This pool will include both kernel .debs and .udebs. A further improvement would allow to split the d-i initramfs into two, having a single copy of the non-kernel specific stuff, and a per-flavour copy of the kernel initramfs stuff. This way, we move together the kernel and the module .udebs, and can easily switch d-i to change kernel version, or even build various d-i for various kernel versions. Furthermore this would avoid d-i trying to import 2.6.18-3 modules when you build a local 2.6.19-1 kernel, and simplify the whole .udeb version checking and downloading logic. Well, there is more to it, and i will present that at fosdem, but i hope this already gave you all a taste of what could be, and that these ideas will not be rejected out of hand, just because they come from me. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Sun, Dec 24, 2006 at 02:48:27PM +0100, Frans Pop wrote: On Sunday 24 December 2006 03:07, Frederik Schueler wrote: 2. port 2.6.19 ACPI - noop because way too much work, unless someone crazy enough to accomplish this task. Did you see that Bas Zoetekouw managed [1, #400488] to solve the problem for his box by applying some selected patches from upstream? Wouldn't that be an option? I thought i saw Maximilian say that there are indeed some patches, but that the risk to destabilize the whole ACPI subsystem was too great this near to the etch release. This is exactly the same kind of argument you are using in d-i, don't you think ? I'd suggest asking other people that see the same issues to also test a kernel with these patches and decide based on the results. No, what we would need is huge testing of these patches by people *WHO DIDN'T SEE THE SAME ISSUES* to make sure there is no regression. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Sun, Dec 24, 2006 at 03:42:46PM +0100, maximilian attems wrote: On Sun, Dec 24, 2006 at 03:31:15PM +0100, Frederik Schueler wrote: Hello, On Sun, Dec 24, 2006 at 02:02:58PM +0100, Moritz Muehlenhoff wrote: Do you intent to disable ACPI entirely for all systems? It appears to me that the affected HP models could be disabled on a per-case basis using drivers/acpi/blacklist.c This looks like a good idea to me, do we know which models are affected? OTOH, I doubt we have a complete list of affected models, and who knows what problems may arise for yet to be released laptops... indeed this is a good way. acpi patches have known side-effects so i would nack any hand-picking of those. do we have a report from an affected laptop that booting with noacpi solves the thermal issues? Ah, neat, there is the noacpi option. We could simply add this flag to affected laptops by d-i. No need to touch the kernel or otherwise. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Sat, Dec 23, 2006 at 11:50:40AM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [061222 05:42]: On Fri, Dec 22, 2006 at 12:53:09PM +0100, Marc 'HE' Brockschmidt wrote: maximilian attems [EMAIL PROTECTED] writes: On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: Fix it or document it, I don't care. But the current state is not releasable. we are not talking about a patch. what you need is an backport of the 2.6.19 acpi release to 2.6.18. Read again what I wrote. I will not allow Debian to release with a Kernel that may damage hardware without even a notice in the release notes. If you are not able to fix it, note that you have provided a broken kernel. Cool, let's delay etch a couple of weeks and move to a (now released) 2.6.19 kernel, to solve this issue. Sven, stop this! Why ? /me guesses that even though debian is about free software, there are many who feel that freedom of speach is to be banned. Do you also follow that line of thought ? Was it not enough that some people felt that i should be burned on the stack for having send mails while i was not at my best ? Really, this kind of behavior is disgusting. I can remember well how you promised that moving to 2.6.18 will magically solve almost all of our issues - 6 (or more) release critical bugs against 2.6.18 don't show that this has worked so well. Please try helping us on solutions rather then breaking things again. I did not promise anything such. I simply stated at that time, that there where many RC issues which where already fixed in the 2.6.18 tree, and which would be a pain to backport to the 2.6.17 tree. Quite a different thing, don't you think ? I personally will need to maintain 2.6.19+ backports to etch, because there is no sane way to get Efika support in 2.6.18 without lot of work. Please try to look at it from another perspective: Consider you have bought such a laptop, and you install Debian. You have even read the release notes first. Everything works well. Until one day you notice your laptop gets too warm, and eventually even breaks because of this. On deeper research, you notice that this issue was well-known to Debian, but they refused to deal with it at all. How would you feel as a user? I think this is an unacceptable perspective. Bah. hardware which can be broken by software is broken. That said, if in fact this is not a bug of the bios as was first mentioned here, but that the linux support is not able to cope with some not usual but legal features of acpi, then it is another matter. But you should *NEVER* try to stop discussion about the subject, or bash on someone for writing a single sentence as i did. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Fri, Dec 22, 2006 at 10:54:50AM +0100, Andreas Barth wrote: severity 404143 critical thanks * Bastian Blank ([EMAIL PROTECTED]) [061222 01:27]: On Fri, Dec 22, 2006 at 01:51:36AM +0100, [EMAIL PROTECTED] wrote: Consequence: linux-image-2.6.18-3-amd63 (=2.6.18-7) is unsuitable for release. Failing for you don't makes it unsuitable. That is a true statement by itself. This bug however has the potential to damage hardware. Which is a critical bug. Euh, it seems to me more that the hardware has a bug which causes normal operation to damage it. As thus, i think that any damage done would be under the responsability of the manufacturer to repare or fix. This seems to be both the position of Bastian and Maximilian, and it seems reasonable. So, users of such hardware, please bother your vendor to either exchange it for a not broken one, or at least provide a bios upgrade which fixes the brokeness. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404191: libxklavier: changing keymap in gnome dies
Package: libxklavier Version: 2.2-4 Severity: serious Well, i am not fully sure that this is the right place to report this bug too. When using the gnome applet to change keymaps, i get (sorry for french) : Erreur lors de l'activation de la configuration XKB. Cela peut arriver pour plusieurs raisons : - un bogue dans la bibliothèque libxklavier - un bogue dans le serveur X (xkbcomp, utilitaires xmodmap) - serveur X avec une implémentation de libxkbfile incompatible Données de version du serveur X : The X.Org Foundation 70101000 Si vous rapportez cette situation comme une anomalie, veuillez inclure : - Le résultat de xprop -root | grep XKB - Le résultat de gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd And the two commands yield : $ xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = xorg, macintosh, us, , _XKB_RULES_NAMES(STRING) = xorg, macintosh, us,us, ,intl, grp:alts_toggle $ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd layouts = [us intl,us] model = options = [grp grp:alts_toggle] overrideSettings = true This make it impossible to switch keymap, which is something which is needed for cases such as myself where i have an US keyboard, but need to use the deadkeys keymap to get the french accented letters. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Fri, Dec 22, 2006 at 12:09:45PM +0100, maximilian attems wrote: On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: Bastian Blank [EMAIL PROTECTED] writes: On Fri, Dec 22, 2006 at 10:30:57AM +0100, Marc 'HE' Brockschmidt wrote: Sorry, I don't accept this. We are talking about an *overheating* problem, which means *broken* hardware. There needs to be at least a fix documented in the release-notes. Garbage-in, garbage-out. The BIOS of that machines is broken. Do you really expect that an interpreter (in this case the ACPI interpreter) accepts any garbage? Other OSes don't destroy the hardware. There is a patch for Linux not to - I don't see why Debian should release with a kernel that destroys hardware, without even giving users a warning. Not everyone who buys a notebook is aware of ACPI problems, and we shouldn't expect all users to do so. Fix it or document it, I don't care. But the current state is not releasable. we are not talking about a patch. what you need is an backport of the 2.6.19 acpi release to 2.6.18. acpi linux releases are tested as one release and you open a can of worm once you start picking acpi patches. only mjg59 is insane enough to do that. anyway the fix for those broken aml tables has a big dependency so the backport is insane. i looked at it 2 month ago and dropped the case, we are shortly before release. i restate those broken hardware needs a newer kernel fullstop. Well, this would mean that we could provide a semi-official set of newer kernels for etch. We would, once etch is released, provide a backportet kernel of the new unstable kernel, as well as a etch-installing d-i for them. This would allow users to install a stable etch, but including a newer kernel, which is what probably most of us are doing anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Fri, Dec 22, 2006 at 12:53:09PM +0100, Marc 'HE' Brockschmidt wrote: severity 404143 critical thanks maximilian attems [EMAIL PROTECTED] writes: On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: Fix it or document it, I don't care. But the current state is not releasable. we are not talking about a patch. what you need is an backport of the 2.6.19 acpi release to 2.6.18. Read again what I wrote. I will not allow Debian to release with a Kernel that may damage hardware without even a notice in the release notes. If you are not able to fix it, note that you have provided a broken kernel. Cool, let's delay etch a couple of weeks and move to a (now released) 2.6.19 kernel, to solve this issue. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: udev bug ... (d-i fails to create /dev/sd* devices)
On Sun, Dec 17, 2006 at 02:48:24PM +0100, Marco d'Itri wrote: On Dec 16, Sven Luther [EMAIL PROTECTED] wrote: Well, i never dealt with udev, i have not even the faintest idea where to start, and the initramfs-tools or d-i environment i have to play with is really not all that user friendly, so please help me or give me guidance on how to further investigate ? OTOH looks like you were really quick to blame udev for this. Can you tell me how i can make udev log all received events, or something such. Once i get the hand, it is usually already too late, and everything happened. Uncomment the last line of /etc/udev/hotplug.rules . Well, in the d-i context, or probably even the initramfs-tools context, this is probably not going to do us much good. I did build a modified udev-udeb, in which i added a hotplug.rules which includes only the : # Log every event to /dev/hotplug.log (for debugging). RUN+=logger.agent lines, and i added /lib/udev/logger.agent to it too. I am unsure if this will be enough though, because lot of stuff are missing from the udev-udeb, and possibly also whatever is used to run the hotplug.rules. Would a udev-dbg-udev make sense ? It would make debugging this kind of stuff much easier. Now, i wonder if it is udev related, since the udev-udeb is much more lightweight than the full udev, is d-i using something else to create the devices ? Anyway, thanks for your help. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: further investigation shows the udev scripts are not even started ...
Package: udev Version: 0.103-1 Followup-For: Bug #403136 Hi, ... I have experimented a bit, thanks to Marco's hints. And we narrowed this done to the scsi-devfs.sh script not even being launched. A udevtrigger showed that all those scripts are : Jan 12 22:14:07 udevd[347]: udev_done: seq 2161, pid [7002] exit with 1, 0 seconds old exiting with return status 1. I have checked by adding an echo at the start of scsi-devfs.sh, and adding set -x too, but it seems to me that it doesn't even get called at all, which is rather strange. Marco, can you give me some information about how to further investigate this, i have narrowed the problematic code to udevd.c, and probably to the udev_done/reap_sigchilds/udev_event_process, but i am not sure how to further continue from there. It may be that for some obscure reason, the scripts are being killed, and this triggers the return status of 1, but as said, running those scripts by hand is perfectly fine. Most baffling. Friendly, Sven Luther -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 8 lrwxrwxrwx 1 root root 39 2006-12-09 08:15 020_libgphoto2_generic-ptp_support.rules - ../libgphoto2_generic_ptp_support.rules lrwxrwxrwx 1 root root 20 2006-02-13 19:26 020_permissions.rules - ../permissions.rules lrwxrwxrwx 1 root root 19 2006-08-28 16:23 025_libgphoto2.rules - ../libgphoto2.rules lrwxrwxrwx 1 root root 16 2006-08-28 16:45 025_libsane.rules - ../libsane.rules lrwxrwxrwx 1 root root 13 2006-02-13 19:26 udev.rules - ../udev.rules lrwxrwxrwx 1 root root 25 2006-08-28 16:10 z20_persistent-input.rules - ../persistent-input.rules lrwxrwxrwx 1 root root 19 2006-08-28 16:10 z20_persistent.rules - ../persistent.rules -rw-r--r-- 1 root root 599 1970-10-03 14:05 z25_persistent-cd.rules -rw-r--r-- 1 root root 602 2006-09-19 08:12 z25_persistent-net.rules lrwxrwxrwx 1 root root 33 2006-08-28 16:10 z45_persistent-net-generator.rules - ../persistent-net-generator.rules lrwxrwxrwx 1 root root 12 2006-08-28 16:10 z50_run.rules - ../run.rules lrwxrwxrwx 1 root root 16 2006-08-28 16:10 z55_hotplug.rules - ../hotplug.rules lrwxrwxrwx 1 root root 19 2005-08-15 17:31 z60_alsa-utils.rules - ../alsa-utils.rules lrwxrwxrwx 1 root root 15 2006-08-28 00:32 z60_hdparm.rules - ../hdparm.rules lrwxrwxrwx 1 root root 33 2006-08-28 16:12 z60_xserver-xorg-input-wacom.rules - ../xserver-xorg-input-wacom.rules lrwxrwxrwx 1 root root 17 2006-08-28 16:10 z70_hotplugd.rules - ../hotplugd.rules lrwxrwxrwx 1 root root 29 2006-08-28 16:10 z75_cd-aliases-generator.rules - ../cd-aliases-generator.rules lrwxrwxrwx 1 root root 12 2006-11-23 08:14 z99_hal.rules - ../hal.rules -- /sys/: /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hda/hda4/dev /sys/block/hda/hda5/dev /sys/block/hda/hda6/dev /sys/block/hdc/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/block/sda/dev /sys/block/sdb/dev /sys/block/sdc/dev /sys/block/sdd/dev /sys/class/drm/card0/dev /sys/class/graphics/fb0/dev /sys/class/input/input0/event0/dev /sys/class/input/input0/mouse0/dev /sys/class/input/input0/ts0/dev /sys/class/input/input3/event1/dev /sys/class/input/input4/event2/dev /sys/class/input/input4/mouse1/dev /sys/class/input/input4/ts1/dev /sys/class/input/mice/dev /sys/class/misc/device-mapper/dev /sys/class/misc/nvram/dev /sys/class/misc/psaux/dev /sys/class/misc/rtc/dev /sys/class/misc/snapshot/dev /sys/class/printer/lp0/dev /sys/class/sound/audio/dev /sys/class/sound/controlC0/dev /sys/class/sound/dsp/dev /sys/class/sound/mixer/dev /sys/class/sound/pcmC0D0c/dev /sys/class/sound/pcmC0D0p/dev /sys/class/sound/seq/dev /sys/class/sound/sequencer2/dev /sys/class/sound/sequencer/dev /sys/class/sound/timer/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev1.3/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_device/usbdev3.1/dev /sys/class/usb_device/usbdev4.1/dev /sys/class/usb_device/usbdev5.1/dev /sys/class/usb_device/usbdev5.2/dev /sys/devices/pci:00/:00:05.0/usb3/3-0:1.0/usbdev3.1_ep81/dev /sys/devices/pci:00/:00:05.0/usb3/usbdev3.1_ep00/dev /sys/devices/pci:00/:00:05.1/usb4/4-0:1.0/usbdev4.1_ep81/dev /sys/devices/pci:00/:00:05.1/usb4/usbdev4.1_ep00/dev /sys/devices/pci:00/:00:05.2/usb5/5-0:1.0/usbdev5.1_ep81/dev /sys/devices/pci:00/:00:05.2/usb5/5-2/5-2:1.0/usbdev5.2_ep02/dev /sys/devices/pci:00/:00:05.2/usb5/5-2/5-2:1.0/usbdev5.2_ep81/dev /sys/devices/pci:00/:00:05.2/usb5/5-2/usbdev5.2_ep00/dev /sys/devices/pci:00/:00:05.2/usb5/usbdev5.1_ep00/dev /sys/devices/pci:00/:00:0c.2/usb1/1-0:1.0/usbdev1.1_ep81/dev /sys/devices/pci:00
Bug#403136: Further investigation : The stdout pipe gets killed for some reason ...
Hi Marco, ... After further investigation, and thanks to David Härdeman who helped me in getting the right shell log information out of the scripts, it seems that the the scsi-devfs.sh script dies (see the attached log) with : ... + echo scsi/host0/bus0/target0/lun0/disc discs/disc0/disc notice how the echo to standard output is done but doesn't come back. So, it is most probably that the process get killed from the other side, in some way, and since the other side is udevd ... So, to sumarise, the script gets killed once it tries to write to stdout, which is the pipe used to communicate with udevd. Friendly, Sven Luther + SCSI_ID=0:0:0:0 + HOST=0 + SCSI_ID=0:0:0 + BUS=0 + SCSI_ID=0:0 + TARGET=0 + SCSI_ID=0 + LUN=0 + [ ] + NAME=disc + get_next_number sda disk + local num=0 + local dev + get_ide_offset disk + local num=0 + local dev + echo /proc/ide/hda/media + [ /proc/ide/hda/media = /proc/ide/hd*/media ] + cat /proc/ide/hda/media + [ cdrom = disk ] + echo 0 + local offset=0 + [ disk = disk ] + local DRIVE=sda + local DEVLIST=/sys/block/sd* + [ sda = sda ] + break + echo 0 + LINK=discs/disc0/disc + echo scsi/host0/bus0/target0/lun0/disc discs/disc0/disc
Bug#403136: more info.
Well, after a bit more playing ... ubuntu 6.10 (edgy), does have a similar problem. It cannot find the cdrom device (our netinst isos have the same problem). I tried then a Yellow Dog 4.1 install, and it worked fine, and even was using udev, altough probably an antiquated version (2.6.15-rc5 based kernel, and udev 071). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: udev bug ...
On Sun, Dec 17, 2006 at 02:48:24PM +0100, Marco d'Itri wrote: On Dec 16, Sven Luther [EMAIL PROTECTED] wrote: Well, i never dealt with udev, i have not even the faintest idea where to start, and the initramfs-tools or d-i environment i have to play with is really not all that user friendly, so please help me or give me guidance on how to further investigate ? OTOH looks like you were really quick to blame udev for this. Well, i blamed i-t first, but when i saw the problem in both d-i and i-t, i guess the common denominator is udev. It could be the kernel too, ubt i did give 2.6.17 a try, and the same problem happened there, and maks saw something similar with md/raid on usb-storage. Can you tell me how i can make udev log all received events, or something such. Once i get the hand, it is usually already too late, and everything happened. Uncomment the last line of /etc/udev/hotplug.rules . Ok, thanks. This is really driving me crazy. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380226: [Parted-maintainers] Bug#380226: NTFS (partition) not recreated correctly after resize: incorrect start sector
On Sat, Dec 16, 2006 at 05:20:02PM +0100, Kurt Roeckx wrote: Bas Zoetekouw [EMAIL PROTECTED] writes: The problem here is how to decide if we should or not align it. That's the most difficult question... If the partition is merely being resized, the begin sector should _never_ be changed, I think. I guess it wouldn't be a bad thing to only change the end sector if that's the only thing you tried to do. I just wonder what constraints the end sector should have in that case, looking at the bug report, the end cylinder also seem to be a multiple of 2048 - 1, so it seem to me that Microsoft is using 2048 sectors/track instead of 63. Vista might not like it that we let the partition stop on a sector that's a multiple of 63 - 1, and might be unable to use the last track. I think the best thing we can do is make it think parted think that there are 2048 sectors/track. Is there some kind of version or something for those NTFS partitions, which will enable us to detect them ? If i remember the code well, it would be trivial enough to modify the sectors-per-cylinder value if we detect a NTFS partition table which needs it, i think this was already done for the legacy systems, and i know that the amiga filesystems (ffs, sfs, etc), also have some such constraints, and the individual cylinder size of them is hold in the main partition table, so i think i already did something similar. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380226: [Parted-maintainers] Bug#380226: NTFS (partition) not recreated correctly after resize: incorrect start sector
On Sat, Dec 16, 2006 at 06:46:47PM +0100, Frans Pop wrote: On Saturday 16 December 2006 17:57, Sven Luther wrote: Is there some kind of version or something for those NTFS partitions, which will enable us to detect them ? This seems like the wrong thing to do. (lib)parted should not touch the starting sector for an *existing* partition of _any_ file system type. This bug is not NTFS or Vista specific, even though it was first detected for a Vista partition. We are speaking about th end sector here though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380226: [Parted-maintainers] Bug#380226: NTFS (partition) not recreated correctly after resize: incorrect start sector
On Sat, Dec 16, 2006 at 07:33:38PM +0100, Kurt Roeckx wrote: On Sat, Dec 16, 2006 at 05:57:04PM +0100, Sven Luther wrote: On Sat, Dec 16, 2006 at 05:20:02PM +0100, Kurt Roeckx wrote: I just wonder what constraints the end sector should have in that case, looking at the bug report, the end cylinder also seem to be a multiple of 2048 - 1, so it seem to me that Microsoft is using 2048 sectors/track instead of 63. Vista might not like it that we let the partition stop on a sector that's a multiple of 63 - 1, and might be unable to use the last track. Is there some kind of version or something for those NTFS partitions, which will enable us to detect them ? Afaik, the version is still 3.1, same as for XP. I think they have something in d-i now that detects vista based on some files in the fs or something. Frans probably knows more about this. If i remember the code well, it would be trivial enough to modify the sectors-per-cylinder value if we detect a NTFS partition table which needs it, i think this was already done for the legacy systems, and i know that the amiga filesystems (ffs, sfs, etc), also have some such constraints, and the individual cylinder size of them is hold in the main partition table, so i think i already did something similar. That would be one of the resize_contraints (and copy) in libparted/fs/ntfs/ I guess, not sure yet how those work. But that would still leave the question on how to not change the start sector without breaking something else. You can set constraints on both the start and the end, if i remember well. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: udev bug ...
Hi Marco, Well, i never dealt with udev, i have not even the faintest idea where to start, and the initramfs-tools or d-i environment i have to play with is really not all that user friendly, so please help me or give me guidance on how to further investigate ? Can you tell me how i can make udev log all received events, or something such. Once i get the hand, it is usually already too late, and everything happened. Do you also know of some documentation explaining the functioning of udev, which would help me along the way. I am very interested in solving this issue ASAP, and doing the work for it, but i am totally lost in how to handle this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403136: scsi subsystem udev events are broken, leaves system with lvm/raid unbootable and breaks d-i.
Package: udev Version: 0.103-1 Severity: critical Tags: d-i Justification: breaks the whole system Hi, a week ago i did go to reboot an Apple XServe G5, which was in a datacenter. What was not my surprise to see that it didn't come back online. The machine had an sata_svw based sata controller, and is using a 2.6.18 debian kernel, and has a LVM on RAID setup. After some infuriating wait time and initramfs-tools archeology, i found out that the problem was due to initramfs-tools trying to bring up the RAID/LVM before the disks finished mounting, and thus failed to find the devices. I discussed the issue with Maximilian Attems, and he said he had also seen a similar issue, with a LVM/RAID on usb disks setup, and mentioned it was caused by : udevsettle has a buggy kernel-userspace seqnum interface with the scsi code. Today i went to the datacenter again, and tried a clean install, and the same problem happens in d-i. The module is loaded, but the /dev/sd* devices are not created. Creating them by hand work, but then the system freezes during base-installation, and i don't really know why. I took the system home, for easier investigation, so let's take this oportunity to fix this issue now. Friendly, Sven Luther -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 8 lrwxrwxrwx 1 root root 39 2006-12-09 08:15 020_libgphoto2_generic-ptp_support.rules - ../libgphoto2_generic_ptp_support.rules lrwxrwxrwx 1 root root 20 2006-02-13 19:26 020_permissions.rules - ../permissions.rules lrwxrwxrwx 1 root root 19 2006-08-28 16:23 025_libgphoto2.rules - ../libgphoto2.rules lrwxrwxrwx 1 root root 16 2006-08-28 16:45 025_libsane.rules - ../libsane.rules lrwxrwxrwx 1 root root 13 2006-02-13 19:26 udev.rules - ../udev.rules lrwxrwxrwx 1 root root 25 2006-08-28 16:10 z20_persistent-input.rules - ../persistent-input.rules lrwxrwxrwx 1 root root 19 2006-08-28 16:10 z20_persistent.rules - ../persistent.rules -rw-r--r-- 1 root root 599 1970-10-03 14:05 z25_persistent-cd.rules -rw-r--r-- 1 root root 602 2006-09-19 08:12 z25_persistent-net.rules lrwxrwxrwx 1 root root 33 2006-08-28 16:10 z45_persistent-net-generator.rules - ../persistent-net-generator.rules lrwxrwxrwx 1 root root 12 2006-08-28 16:10 z50_run.rules - ../run.rules lrwxrwxrwx 1 root root 16 2006-08-28 16:10 z55_hotplug.rules - ../hotplug.rules lrwxrwxrwx 1 root root 19 2005-08-15 17:31 z60_alsa-utils.rules - ../alsa-utils.rules lrwxrwxrwx 1 root root 15 2006-08-28 00:32 z60_hdparm.rules - ../hdparm.rules lrwxrwxrwx 1 root root 33 2006-08-28 16:12 z60_xserver-xorg-input-wacom.rules - ../xserver-xorg-input-wacom.rules lrwxrwxrwx 1 root root 17 2006-08-28 16:10 z70_hotplugd.rules - ../hotplugd.rules lrwxrwxrwx 1 root root 29 2006-08-28 16:10 z75_cd-aliases-generator.rules - ../cd-aliases-generator.rules lrwxrwxrwx 1 root root 12 2006-11-23 08:14 z99_hal.rules - ../hal.rules -- /sys/: /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hda/hda4/dev /sys/block/hda/hda5/dev /sys/block/hda/hda6/dev /sys/block/hdc/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/block/sda/dev /sys/block/sdb/dev /sys/block/sdc/dev /sys/block/sdd/dev /sys/class/drm/card0/dev /sys/class/graphics/fb0/dev /sys/class/input/input0/event0/dev /sys/class/input/input0/mouse0/dev /sys/class/input/input0/ts0/dev /sys/class/input/input1/event1/dev /sys/class/input/input2/event2/dev /sys/class/input/input2/mouse1/dev /sys/class/input/input2/ts1/dev /sys/class/input/mice/dev /sys/class/misc/device-mapper/dev /sys/class/misc/nvram/dev /sys/class/misc/psaux/dev /sys/class/misc/rtc/dev /sys/class/misc/snapshot/dev /sys/class/printer/lp0/dev /sys/class/sound/audio/dev /sys/class/sound/controlC0/dev /sys/class/sound/dsp/dev /sys/class/sound/mixer/dev /sys/class/sound/pcmC0D0c/dev /sys/class/sound/pcmC0D0p/dev /sys/class/sound/seq/dev /sys/class/sound/sequencer2/dev /sys/class/sound/sequencer/dev /sys/class/sound/timer/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev1.2/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_device/usbdev3.1/dev /sys/class/usb_device/usbdev4.1/dev /sys/class/usb_device/usbdev5.1/dev /sys/class/usb_device/usbdev5.2/dev /sys/devices/pci:00/:00:05.0/usb3/3-0:1.0/usbdev3.1_ep81/dev /sys/devices/pci:00/:00:05.0/usb3/usbdev3.1_ep00/dev /sys/devices/pci:00/:00:05.1/usb4/4-0:1.0/usbdev4.1_ep81/dev /sys/devices/pci:00/:00:05.1/usb4/usbdev4.1_ep00/dev /sys/devices/pci:00/:00:05.2/usb5/5-0:1.0/usbdev5.1_ep81/dev /sys/devices/pci:00/:00:05.2/usb5/5-2/5-2:1.0/usbdev5.2_ep02/dev /sys/devices/pci:00/:00:05.2/usb5/5-2/5-2:1.0
Bug#401916: initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up - unbootable
On Sun, Dec 10, 2006 at 10:39:45AM +0100, maximilian attems wrote: On Wed, 06 Dec 2006, Sven Luther wrote: Package: initramfs-tools Severity: critical Justification: breaks the whole system hmm yes i know of that situation it affects a certain range of roots. Today i went to the datacenter to reboot the xserve G5 i have there, for some random reason, and what was not my surprise to notice that the box didn't come up anymore. After some dmesg examination, i noticed that the sata disks did come up only after i-t tried to bring up the RAID and LVM stuff, which is really not nice. the trouble is that udevsellte exists to early that mean when the scsi/usb discs are not up yet. hitting raid/lvm2 roots on those devices and more general lilo boots as there you have no root dev to wait for. i notified udev upstream for it, but got no response i'll reask privately. http://marc.theaimsgroup.com/?l=linux-scsim=116189244404693w=2 Yeah, please do, we really need to fix this before etch is out, i don't think that having a server who cannot reboot sometimes is something we want to ship in etch. Furthermore, playing offline without any info with the box, i was not able to convince i-t to mount the partition and investigate, but well, i guess i would have been able to do so if i had the code available, or more time to investigate. you should have rerun the early initramfs-tools stages, see init. than it works. Ah, that was the missing info. I searched a bit, but didn't find easily what to do, and then i had to leave. I will be at the box on thursday again. Now, as a temporary workaround, maybe one solution, if RAID/LVM was not found is to delay for a given time (1/2 minute ? a configurable time ?), and then try again. Another nice thing would be able to rerun the early initramfs-tools stages, or maybe even have a stamp of each completed stage, and a single command which allow to restart the detection from there ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402267: PowerPC Netinst CD Invalid Release File
On Sat, Dec 09, 2006 at 01:01:54AM -0500, Rick Thomas wrote: Package: installation-reports Installing from the netinst CD on a PowerMac G4, I get the following error: [!!] Install the base system Debootstrap Error Invalid Release file: no entry for main/binary-powerpc/Packages. This is the netinst CD from: Notice that last thursday, in order to investigate an initramfs-tools bug which left the xserve unbootable, i tried booting d-i from the daily netboot mini-iso, and yaboot refused to take it, i don't really know why though. Need to go to the datacenter to investigate more. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380226: NTFS alignement problem ...
Hi, ... On Xavier Oswald's proding, i had a look at the history of this bug. I don't really know much about NTFS and other windowy filesystems, so i cannot really give much info, which is why i didn't help investigate these bugs. Now, one of the recomendation was to change the alignement issues, and there was a note of the current way of things being so for pre-LBA compatibility issues, which brang into memory the whole huge set of problems which where present 1-2 years ago with windowy filesystem resizing. As such, i strongly urge you (Maybe otavio or xavier are the best candidates for that), to take contact with upstream, and not to try to solve the issue alone in debian, and possibly do something which may break the other compatibility issue affecting older hardware, which we may or not be able to detect before the etch release. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up - unbootable
Package: initramfs-tools Severity: critical Justification: breaks the whole system Sorry maks for this RC bug, but i think the severity is deserved. Today i went to the datacenter to reboot the xserve G5 i have there, for some random reason, and what was not my surprise to notice that the box didn't come up anymore. After some dmesg examination, i noticed that the sata disks did come up only after i-t tried to bring up the RAID and LVM stuff, which is really not nice. on this machine, root is on a LVM, inside a RAID1 on two physical disks. Furthermore, playing offline without any info with the box, i was not able to convince i-t to mount the partition and investigate, but well, i guess i would have been able to do so if i had the code available, or more time to investigate. The box is currently switched off until i can come back with a fix to this issue (oh, and it refused to eject the CDROM i put in it to try to boot the debian-installer in resuce mode :). Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395259: nobootloader: [powerpc/pegasos] bad sed invocation breaks devfs style paths (division by zero)
On Wed, Nov 22, 2006 at 09:32:27AM +, Colin Watson wrote: On Thu, Oct 26, 2006 at 03:25:33AM +0200, Frans Pop wrote: On Wednesday 25 October 2006 23:12, Sven Luther wrote: It seems that nobootloader uses still devfs paths for some reason. The following line : That is not so strange as that line is using the exact same variable $bootfs_devfs as its base that the old code did... Should it be using something different instead? What is the value of $bootfs_disk_syspath and $bootfs_disk if you run the code with 'set -x'? For now I've added a comment that that should probably be changed at some point. (To be very honest, I don't see the point of the code added in 1.10 at all as the devfs path is still used as the base for the whole piece of code; I guess it is in preparation of a further future transition.) Don't be misled by the variable name. It's called $bootfs_devfs because it's the path before calling mapdevfs; if you aren't using devfs paths then $bootfs_devfs and $bootfs are identical. What $bootfs_devfs really means is the version of this path that can be used within d-i. I've just committed an IMHO better fix which will work for both devfs and non-devfs paths. Sven, thanks for the report. Hehe, i suppose i will now need to build and test your new version, or will you be able to test it on your pegasos machine ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398962: ircgate
On Wed, Nov 22, 2006 at 08:50:21AM -0500, Joey Hess wrote: Md joeyh: I remember talking about #398962 with waldi, IIRC platform devices in recent kernels provide $MODALIAS while they should not. so udev will always try loading again the driver after it has been loaded Md I suppose I could add a workaround in udev since I do not know about any platform driver which provides a meaningful $MODALIAS fjp Md: Has there been a discussion with kernel developers about that? Will/has it been fixed in later kernels? Md fjp: no clue. somebody should ask greg k-h but I am too much busy these days joeyh Md: afaics, there's no way udev can autoload that pcmcia bridge driver .. would just blacklisting it in udev make sense? Is there a way to blacklist it that doesn't blacklist it from modprobe? Md joeyh: try adding in hotplug.rules, as the third line: SUBSYSTEM==platform, GOTO=hotplug_driver_loaded Md IIRC it uses SUBSYSTEM==platform, double check the log if needed joeyh ok, that works, tested in d-i Md I will add the workaround to the next upload joeyh I imagine a more targeted rule that also matches the driver would also work joeyh at least for this one module.. dunno about other platform modules.. Md all platform drivers have this problem, the bug is in the drivers core Notice that the pegasos marvell gigabit ethernet port is such a platform device. We currently have a hacked patch in our kernel with makes it masquarade as a pci device, listening on the northbridge pci id, but when i tried to push this patch upstream, i was told it was not needed because of the platform device modalias support. There are probably other devices which gained hotplug and thus automatically loaded modules, in this way. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399260: debian-installer: [powerpc] Please apply attached patch, adding prep and 2.6.18-2 support.
Package: debian-installer
Severity: grave
Justification: d-i powerpc daily builds need to be upgraded to 2.6.18-2 kernel
.udebs
Please apply the attached patch.
It adds support for the 2.6.18-2 kernel .udebs currently in unstable, as well
as the prep support (needs mkvmlinuz 26 though, which was uploaded today).
It also includes adding the Apple G5 fancontrol modules in the ramdisk.
This patch is RC, because without it, the d-i daily builds are probably not
building
anymore, now that the 2.6.18-2 kernel .udebs are in unstable.
Friendly,
Sven Luther
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-powerpc
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Index: config/powerpc/prep.cfg
===
--- config/powerpc/prep.cfg (revision 0)
+++ config/powerpc/prep.cfg (revision 0)
@@ -0,0 +1,19 @@
+MEDIUM_SUPPORTED = cdrom netboot hd-media
+
+# The version of the kernel to use.
+KERNELVERSION = 2.6.18-2-prep
+KERNEL_FLAVOUR = di
+KERNELNAME = vmlinux
+KERNELIMAGEVERSION = $(KERNELVERSION)
+
+SUBARCHES = prep
+
+cd_content: cd_content_common
+
+netboot_content: netboot_content_common
+
+arch_miniiso: arch_miniiso_common
+
+arch_boot_screens:
+
+#arch_boot: arch_boot_initrd
Index: config/powerpc/prep/hd-media.cfg
===
--- config/powerpc/prep/hd-media.cfg(revision 42615)
+++ config/powerpc/prep/hd-media.cfg(working copy)
@@ -0,0 +1,18 @@
+# Not really a floppy, this is a 239 mb image, large enough to put a
+# netinst iso in, and small enough to fit on a mid-range memory stick,
+# such as those advertised as being 256 mb in size.
+FLOPPY_SIZE = 244736
+
+DISK_LABEL = bootable drive
+MEDIA_TYPE = bootable drive
+
+GZIPPED = .gz
+EXTRANAME = hd-media/
+
+TARGET = $(KERNEL) $(INITRD) $(BOOT)
+
+MANIFEST-BOOT = 256 mb image (compressed) for USB memory stick
+MANIFEST-INITRD = for use on USB memory sticks
+MANIFEST-KERNEL = for use on USB memory sticks
+
+arch_boot: hd_media_common
Index: config/powerpc/prep/cdrom.cfg
===
--- config/powerpc/prep/cdrom.cfg (revision 42615)
+++ config/powerpc/prep/cdrom.cfg (working copy)
@@ -0,0 +1,9 @@
+MEDIA_TYPE = CD-ROM
+
+# cd booting does not need floppy images on powerpc
+TARGET = $(INITRD) $(KERNEL) builtin_initrd
+EXTRANAME = $(MEDIUM)/
+
+MANIFEST-BOOT = CDROM image for most PowerPC CPUs
+MANIFEST-INITRD = initrd for use with powerpc CDROM
+MANIFEST-KERNEL = kernel for use with powerpc CDROM
Index: config/powerpc/prep/netboot.cfg
===
--- config/powerpc/prep/netboot.cfg (revision 42615)
+++ config/powerpc/prep/netboot.cfg (working copy)
@@ -0,0 +1,9 @@
+MEDIA_TYPE = netboot image
+
+TARGET = $(INITRD) $(KERNEL) $(MINIISO) builtin_initrd netboot_content
+EXTRANAME = $(MEDIUM)/
+
+MANIFEST-BOOT = tftp boot image for most PowerPC CPUs
+MANIFEST-INITRD = initrd for use with powerpc netboot
+MANIFEST-KERNEL = kernel for use with powerpc netboot
+MANIFEST-MINIISO = small bootable CD image for powerpc netboot
Index: config/powerpc/powerpc64.cfg
===
--- config/powerpc/powerpc64.cfg(revision 42615)
+++ config/powerpc/powerpc64.cfg(working copy)
@@ -1,7 +1,7 @@
MEDIUM_SUPPORTED = cdrom netboot gtk-miniiso
# The version of the kernel to use.
-KERNELVERSION = 2.6.17-2-powerpc64
+KERNELVERSION = 2.6.18-2-powerpc64
KERNEL_FLAVOUR = di
KERNELNAME = vmlinux
KERNELIMAGEVERSION = $(KERNELVERSION)
Index: config/powerpc/powerpc.cfg
===
--- config/powerpc/powerpc.cfg (revision 42615)
+++ config/powerpc/powerpc.cfg (working copy)
@@ -1,7 +1,7 @@
MEDIUM_SUPPORTED = cdrom netboot hd-media floppy gtk-miniiso # monolithic
# The version of the kernel to use.
-KERNELVERSION = 2.6.17-2-powerpc
+KERNELVERSION = 2.6.18-2-powerpc
KERNEL_FLAVOUR = di
KERNELNAME = vmlinux
KERNELIMAGEVERSION = $(KERNELVERSION)
Index: config/powerpc.cfg
===
--- config/powerpc.cfg (revision 42615)
+++ config/powerpc.cfg (working copy)
@@ -1,4 +1,4 @@
-SUBARCH_SUPPORTED = powerpc powerpc64 # apus
+SUBARCH_SUPPORTED = powerpc powerpc64 prep # apus
KERNELMAJOR = 2.6
Index: pkg-lists/cdrom/powerpc.cfg
===
--- pkg-lists/cdrom/powerpc.cfg (revision 42615)
+++ pkg-lists/cdrom/powerpc.cfg (working copy)
@@ -28,3 +28,4 @@
# IBM Power hypervisor modules, only available on powerpc64.
hypervisor-modules-${kernel:Version} ?
+fancontrol-modules-${kernel:Version} ?
Index: pkg-lists/netboot/powerpc.cfg
Bug#398773: [etch-upgrade] upgrade makes nano the default editor, while vim was in sarge.
Package: nano Version: 1.9.99pre3-1 Severity: serious Justification: etch upgrade bug, RC on Andreas Barth's advice. 14:38 svenl mmm, sarge-etch upgrade make nano the default editor while i had it set to vim previously, did you know about that ? 14:38 aba no, and please file an RC-bug about it to ..., hm, I don't know where 14:38 aba (you can cite me with that, though, if you want) 14:38 svenl indeed, good question. 14:38 aba general? 14:38 aba nano? 14:39 svenl i don't think there is such a thing, is there a editor metapackage ? 14:39 svenl let's file it as nano. Detail: i upgraded my powerbook from sarge to etch yesterday. Before i had vim as the default editor, and after the upgrade, it seems nano seems to be the default editor, and there is no obvious way for an end user to change that. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages nano depends on: ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libncursesw5 5.5-5 Shared libraries for terminal hand nano recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395889: possible fix for the version test ...
Hello, I did experience a bit more, and this one should work : --- /var/lib/dpkg/info/udev.postinst2005-05-29 19:36:20.0 +0200 +++ udev.postinst 2006-11-09 19:25:28.118104583 +0100 @@ -68,7 +68,8 @@ return 0 fi - if [ ! -r /proc/1/root ]; then + version=`uname -r` + if `dpkg --compare-versions $version ge 2.6.18` [ $(stat -c %d/%i /) = $(stat -Lc %d/%i /proc/1/root) ]; then echo A chroot environment has been detected, udev not started. return 0 fi Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395889: udev cannot be set up in a chrooted environment on 2.6.18
Hello, ... Well, i gave this bug a bit of a test. on a 2.6.18 powerpc/pegasos system, which is mostly etch with sid kernels, i tested both proposed fixes : if ! [ -r /proc/1/root -a /proc/1/root/ -ef /proc/self/root/ ] returned FALSE in both cases (Well, i think i forgot the !, so it probably did return TRUE in both cases). So, this solution is not working. On the other hand this check : [ $(stat -c %d/%i /) = $(stat -Lc %d/%i /proc/1/root) ] works fine (returning TRUE on the real system and FALSE in the chroot). Given the critic Christoph had (warnings on pre-2.6.18, altough we hardly care for this in etch, which will have 2.6.18), mayeb something like this : if [ `uname -r` -ge 2.6.18 ] [ $(stat -c %d/%i /) = $(stat -Lc %d/%i /proc/1/root) ]; then # WE ARE IN THE REAL SYSTEM else # WE ARE IN THE CHROOT fi Should be best. Well, this will not work, since uname -r will return something like 2.6.18-2-powerpc which is not test friendly, but you get the idea. Finding the right comparison is left as an exercice for the one which is going to fix this bug. Let's fix this ASAP, so we can get a fixed version uploaded to unstable, and do some widespread tests, and then move the fixed udev and 2.6.18 kernels into testing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392767: [Parted-maintainers] Bug#392767: Fixed RC bug in frozen parted : #392767: [mac] parted is unable to reread partition tables created by d-i/partman.
On Wed, Nov 15, 2006 at 12:14:27AM +, Colin Watson wrote: On Tue, Nov 07, 2006 at 08:14:45PM +0100, Sven Luther wrote: On Tue, Nov 07, 2006 at 08:08:26PM +0100, Robert Millan wrote: I'm sorry. Please feel free to disable the patch; I'm thinking it was not a good idea to apply it in the package before it was merged upstream (as it was about to, last time I visited this). Apologises for the hassle. No problem, i am happy we found it before the release though. Will you be able to work out a better/cleaner patch ? And work with us to merge it upstream ? I filed a bug with the correct fix for this problem two months ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386973 I highly recommend applying that instead. He, nice. I will test this one, and see if it doesn't cause the breakage. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396055: unionfs-source: sioq missing upstream too ...
Package: unionfs-source Version: 1.3.20061029.0124+debian-1 Followup-For: Bug #396055 Hi, ... Almost two weeks since this RC bug is open, without any activity. Also, it seems to me this module was never built, or the failure would have been noticed. A quick google shows : http://www.mail-archive.com/unionfs-cvs@mail.fsl.cs.sunysb.edu/msg00585.html Which is a CVS commit message with the log : Forgot to add the sioq.h file and dated : Wed, 23 Aug 2006 15:52:11 -0700 So, i wonder why this was not fixed in the : * New upstream snapshot: (Dated 20061029) The plan is to disable unionfs module builds until these issues are fixed. Friendly, Sven Luther -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392767: parted/d-i bug : vanishing print output, bug traced to table.c code.
On Thu, Nov 02, 2006 at 02:12:40PM +0100, Sven Luther wrote: Hi, ... it seems this bug is also affecting i386 and s390. Ah, i found one hint on this. I found that : printf (%s\n, LSTRING); Doesn't print anything, and that the L-strings are used with ENABLE_NLS, which seems to be set by default. I suppose that somehow the d-i environment, or the chroot into the installed system from d-i does some funny stuff with relation to NLS. Help on this topic is very welcome. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392767: Fixed RC bug in frozen parted : #392767: [mac] parted is unable to reread partition tables created by d-i/partman.
reopen 363381
# kfreebsd support patch broke parted in a RC way.
thanks
Hi Robert, debian-release, debian-boot folk.
The patch in 363381, and particularly this hunk :
diff -urNad parted-1.7.0~/parted/table.c parted-1.7.0/parted/table.c
--- parted-1.7.0~/parted/table.c2006-05-19 03:54:01.0 -0300
+++ parted-1.7.0/parted/table.c 2006-05-19 03:54:36.0 -0300
@@ -197,7 +215,11 @@
len += wcslen(COLSUFFIX);
newsize = (wcslen(*s) + len + 1) * sizeof(wchar_t);
+ oldsize = (wcslen(*s) + 1) * sizeof(wchar_t);
+
+ temps = *s;
*s = realloc (*s, newsize);
+ memcpy(*s, temps, oldsize);
for (i = 0; i ncols; ++i)
{
Caused the bug in #392767: [mac] parted is unable to reread partition tables
created by d-i/partman, which was visible on s390 and x86 also accordying to
Bastian Blank, and thus caused parted to randomly not show the partition table
on a print command, thus breaking the lvm/raid support, which used
command-line parted in order to detect lvm/raid partitions.
The problem seems related to the ENABLE_NLS case, and the use of wide-chars,
which the memcpy trick failed to copy over properly, leaving garbage in the
string to be outputed.
I remember (but am not anymore 100% sure, so a reply from frans/joeyh would
be nice), that frans told me last week or so, that an upload of parted was ok
with regard to d-i RC1, since parted is not in the image, and not migrated to
testing, but i would like confirmation on this, and also advice from the
debian-release folk, thus posting here.
I propose to upload parted 1.7.1-3, which includes the two following changes :
parted (1.7.1-3) unstable; urgency=low
* parted-print-name.dpatch : Fix bug in parted print, when there are no
extended partitions, but partition names.
* disabled kfreebsd-gnu.dpatch, which added kfreebsd support, because the
the patch caused parted to have trouble in a d-i environment to print the
partition table, thus causing tools relying on parted -s print to find
information about the partition table to break, like the one checking for
RAID partitions in d-i. (Closes: #392767)
-- Sven Luther [EMAIL PROTECTED] Tue, 7 Nov 2006 17:45:28 +0100
#392767 being one of the two parted related RC bugs still open, but the other
patch is also nice to have, since it allows to have partitions actually named
something else than primary, which may (or not) break some tools also.
Robert, we will upload a parted version without kfreebsd support, but it would
be nice if you could revisit the patch, and clean up this problem. Maybe
documenting the hacks like the one above a bit better, and/or adding *BSD
specific #ifdefs to limit this kind of problems would be nice.
Special thanks go to Bastian Blank, who helped me in the last step of
investigating this issue, and finding the responsible patch.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392767: Fixed RC bug in frozen parted : #392767: [mac] parted is unable to reread partition tables created by d-i/partman.
On Tue, Nov 07, 2006 at 08:08:26PM +0100, Robert Millan wrote: I'm sorry. Please feel free to disable the patch; I'm thinking it was not a good idea to apply it in the package before it was merged upstream (as it was about to, last time I visited this). Apologises for the hassle. No problem, i am happy we found it before the release though. Will you be able to work out a better/cleaner patch ? And work with us to merge it upstream ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392767: Fixed RC bug in frozen parted : #392767: [mac] parted is unable to reread partition tables created by d-i/partman.
On Tue, Nov 07, 2006 at 10:37:17PM +0100, Petr Salinger wrote: On Tue, 7 Nov 2006, Sven Luther wrote: No problem, i am happy we found it before the release though. Will you be able to work out a better/cleaner patch ? And work with us to merge it upstream ? Please, would you mind to retest #392767 with truncated kfreebsd-gnu.dpatch. Please leave only first 1407 lines and drop changes to parted/strlist.h and parted/table.c. They are not needed on GNU/kFreeBSD, they are probably needed only on plain FreeBSD. I can do that, removing only the patches under parted (strlist.h and table.c). The rest seems unoffensive enough. But i would much rather prefer that you guys worked with upstream to get those changes integrated properly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392767: [Parted-maintainers] Bug#392767: parted and GNU/kFreeBSD (Re: Fixed RC bug in frozen parted : #392767: [mac] parted is unable to reread partition tables created by d-i/partman.)
On Wed, Nov 08, 2006 at 07:48:35AM +0100, Robert Millan wrote: On Tue, Nov 07, 2006 at 08:14:45PM +0100, Sven Luther wrote: On Tue, Nov 07, 2006 at 08:08:26PM +0100, Robert Millan wrote: I'm sorry. Please feel free to disable the patch; I'm thinking it was not a good idea to apply it in the package before it was merged upstream (as it was about to, last time I visited this). Apologises for the hassle. No problem, i am happy we found it before the release though. Will you be able to work out a better/cleaner patch ? And work with us to merge it upstream ? The patch isn't mine; I grabbed it from upstream while it was in the process of being merged. Its author was already working with upstream for a merge at that time, and I sent him my input to ensure the patch works on GNU/kFreeBSD as well as FreeBSD. Who is upstream about this ? For the debian side, I think it's safer to pull it from upstream when it's time to. I don't want to risk having further problems. Well, i reviewed and applied the freebsd only part of it, which seems pretty safe, and it was in debian since may anyway, so ... Upload will go to unstable today. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392767: parted/d-i bug : vanishing print output, bug traced to table.c code.
Hi, ... it seems this bug is also affecting i386 and s390. I CCed bug-parted@gnu.org, since it probably concerns upstream too. For info, the bug is that in some cases (triggered in my case by running inside the debain-installer) print shows no output, which is pretty much damaging for tools which parse the parted output. Here is the original bug report : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392767 I also CCed debian-boot@lists.debian.org, since this affects d-i, and doesn't seem to be something only for powerpc, and someone with d-i image and mklibs knowledge may have a clue of why this appears for me inside the d-i image, but never in the installed system. That said, i also sometime see it inside the d-i image, but in a chroot of the installed system. Frans and Joeyh, this affects the RAID/LVM code, i am not sure if this is rc-critical, or may affect the upcoming rc1, but i will try to fix this as fast as i can. We may think about removing the dependency on parted output parsing, and replace that with a little libparted program instead. Colin, it would be nice if you could comment on this, i believe this bit of code may be yours. I traced the bug to the table.c:table_render call in do_print, where the printf of the rendered table starts, but then suddenly is stopped. This may well mean that there is probably a extraneous \0 inside that string, for some obscure reason, i will do some further checking of the string result later today. The most strange thing is that this happens some times, and some other times it does not, some time it is consistent, and others it gets triggered around 50% of the times. And enabling PED_DEBUG printing seems to make it appear less often. Here is attached irc log between waldi and me, which made me realize this issue is more generic than i first thought. Bastian if you happen to remember more information about when you faced this bug and described it, it would be welcome. 13:48 svenl waldi: do you have a clue about the parted-in-d-i bug ? 13:48 waldi svenl: which bug? 13:48 svenl waldi: how can it be possible that parted works perfectly fine in the installed system, while in d-i, it dies when trying to print the string. 13:49 svenl waldi: you launch d-i on a powermac, then go into the console, and run parted, it will not show the partitions, or sometimes will show them and otherwise not. 13:49 waldi that is not a d-i problem 13:49 waldi i've described that problem months ago without any outcome 13:50 svenl oh. 13:50 svenl do you have a link of the description ? 13:50 waldi not here 13:50 svenl waldi: why does it show up in d-i, and not in the installed system then ? 13:50 waldi unknown 13:50 svenl do you vaguely remember something about the issue, where you saw it ? 13:51 waldi no 13:51 svenl what box / arch you where running. 13:51 waldi i386 and s390 AFAIK 13:51 svenl waldi: the bug is : 392767 13:51 svenl oh. 13:51 svenl so it doesn't touch only powerpc. 13:52 svenl can you comment something on bug 392767 about this ? Include this log or something. 13:52 svenl waldi: i was wondering if a mklibs-copy'ed d-i image may not show this bug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392818: sorry, was meant for bug 393451 :/
sorry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392818: Is this also the case in 2.6.18 in sid ?
Hi, ... Please install the sid 2.6.18-3 kernel, and confirm the issue is still present in it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393451: Is this issue still present in the sid 2.6.18-3+ kernel ?
Hi, As subject says, 2.6.18 is the etch target kernel, so it would be nice to have information about the presence of this bug in 2.6.18. In any case, this is probably not going to stop the migration of the 2.6.18 kernel to etch, since the bug is present in etch. Furthermore, it only affects xen systems, so critical severity may be a bit overkill. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396471: linux-image-2.6.18-1-parisc64-smp: fails to install
On Tue, Oct 31, 2006 at 11:54:09PM +0100, Frans Pop wrote: Package: linux-image-2.6.18-1-parisc64-smp Version: 2.6.18-3 Severity: serious This issue has been reported several times before, but I've not yet seen any real response from the kernel team. Preconfiguring packages ... Selecting previously deselected package linux-image-2.6.18-1-parisc64-smp. (Reading database ... 28539 files and directories currently installed.) Unpacking linux-image-2.6.18-1-parisc64-smp (from .../linux-image-2.6.18-1-parisc64-smp_2.6.18-3_hppa.deb) ... Done. Selecting previously deselected package linux-image-2.6-parisc64-smp. Unpacking linux-image-2.6-parisc64-smp (from .../linux-image-2.6-parisc64-smp_2.6.18+3_hppa.deb) ... Setting up linux-image-2.6.18-1-parisc64-smp (2.6.18-3) ... Hmm. The package shipped with a symbolic link /lib/modules/2.6.18-1-parisc64-smp/source However, I can not read the target: No such file or directory Therefore, I am deleting /lib/modules/2.6.18-1-parisc64-smp/source Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Other valid candidates: mkinitramfs-kpkg mkinitrd.yaird Missing Required paramater 'Old' at /var/lib/dpkg/info/linux-image-2.6.18-1-parisc64-smp.postinst line Thanks Frans for pointing out this bug, which is exactly the same we already had some discussion a few weeks ago when it was discovered in the powerpc packages, and where i was flammed by you and Manoj. Another occasion where you do exactly the things you are continuously reproaching me. I hope you remember that next time you want to write some bashing of me in bug reports. This bug is closed by the new kernel-package version, and linux-2.6 only needs to be rebuilt with it, which is scheduled for -4, and amply discussed here previously. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Tue, Oct 31, 2006 at 09:06:50PM +0100, Ola Lundqvist wrote: Hi Sven On Tue, Oct 31, 2006 at 07:32:02PM +0100, Sven Luther wrote: ...CUT... Will all reverse engineered drivers with hardcoded values be considered as closed source? Must you always release everything that you know when you release somehting as open source? Must we release the instructions on how to paint an image, how to move the arm while painting if we release an image as open source? I think this is worth considering. Personally I think this bug can be closed. But your thinking are giving us an excellent way out. We could simply take all those binary blobs that are in the kernel, and try to take a guess about the instruction set which they are designed for, and disasemble them, and provide the dissasembled version under the GPL, as well as a instructions to re-assemble them into the actual binary blob. If we were to achieve that, i would be more than happy to consider these blobs and their corresponding reverse-engineered asm codes as actual source. One may argue that in this case, the actual documentation of the registers may be more of a source for such binary blobs, but it would in any case be no worse than any other reverse-engineering effort out there. I fully agree that this kind of work would be a good thing. Such improvements would most problably be a benifit for the open source community and maybe would give us better functionality in the end. Patches are welcome :) The question is if it is a violation or not to release as is. I doubt that there is any more sense in (re-)discussing this. The other good (or bad?) thing is that we would need cross-compilers for most major instruction-sets as reassembling probably mean compiling for a different architecture. Nope, because you can ship the source code and the object file if you wanted. Already now, major parts of debian/main are not cleanly buildable out of the box, due to cyclic bootstraping dependencies. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396471: linux-image-2.6.18-1-parisc64-smp: fails to install
On Tue, Oct 31, 2006 at 03:59:57PM -0800, Steve Langasek wrote: On Wed, Nov 01, 2006 at 12:21:56AM +0100, Sven Luther wrote: This bug is closed by the new kernel-package version, and linux-2.6 only needs to be rebuilt with it, which is scheduled for -4, and amply discussed here previously. Is linux-2.6 binNMU-safe? Could we binNMU linux-2.6 to fix this bug on the affected architectures? (How many archs are known to be affected?) Why is it so urgent to fix this, that you cannot wait the few days until -4 is uploaded, which fs announced here earlier, and will have a lot more fixes ? There sure seemed no hurry to fix this when it was encountered on powerpc. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Wed, Nov 01, 2006 at 12:55:45AM +0100, Francesco Poli wrote: On Tue, 31 Oct 2006 23:59:18 +0100 Sven Luther wrote: [...] Nope, because you can ship the source code and the object file if you wanted. Already now, major parts of debian/main are not cleanly buildable out of the box, due to cyclic bootstraping dependencies. But those major parts of debian/main are cleanly buildable using an already functioning installation of debian/main, aren't they? No, not always. At least I *hope* those major parts are buildable using only packages from debian/main, otherwise they would Build-Depend on out-of-main components, which is a Policy violation for a package in main, AFAIK. Well, It is not so much that you have to depend on out-of-main components, but that you have to hand-build some of them and stop in the middle and stuff like that. If what I have just said is true and confirmed, then *that* is the difference: one thing is having cyclic bootstrapping dependencies that make an already compiled and installed system necessary, a completely different beast is something that needs an out-of-main compiler in order to be compiled... Well, the cross compiler would be built from the same gcc source in main. There is just no binary package provided for those. Or am I completely off track?!? Not completely, but a bit yes. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395110: linux-image-2.6.18-1-powerpc: uninstallable
On Sun, Oct 29, 2006 at 01:13:20PM +0100, Santiago Vila wrote: Same problem here: mac:~# apt-get install linux-image-2.6-powerpc Reading package lists... Done Building dependency tree... Done linux-image-2.6-powerpc is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 2 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up linux-image-2.6.18-1-powerpc (2.6.18-3) ... Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Missing Required paramater 'Old' at /var/lib/dpkg/info/linux-image-2.6.18-1-powerpc.postinst line 393. dpkg: error processing linux-image-2.6.18-1-powerpc (--configure): subprocess post-installation script returned error exit status 2 dpkg: dependency problems prevent configuration of linux-image-2.6-powerpc: linux-image-2.6-powerpc depends on linux-image-2.6.18-1-powerpc; however: Package linux-image-2.6.18-1-powerpc is not configured yet. dpkg: error processing linux-image-2.6-powerpc (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-2.6.18-1-powerpc linux-image-2.6-powerpc E: Sub-process /usr/bin/dpkg returned an error code (1) I'm surprised that it's only reported once, but I'm glad to see it's already reported... Yeah, but it is a kernel-package issue, and Manoj made some haughty comment when i re-assigned it to kernel-package, that he was glad that he didn't see already closed bugs. Manoj is blacklisting me anyway, so it would be useful for someone else (you maybe), to follow up on bugs like this one, maybe he does also ignore the bug just because i am affected by it, or something else so unproffesional. I already pinged him twice on irc about this, and redirected the bug to kernel-package. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395110: linux-image-2.6.18-1-powerpc: uninstallable
On Sun, Oct 29, 2006 at 02:28:24PM +0100, Santiago Vila wrote: On Sun, 29 Oct 2006, Sven Luther wrote: [ snipped paragraph about Manoj ] Quoting Julian Gilbey in the logs for this bug: According to Manoj in the logs to bug#394661, which was blocking this bug and has since been closed, the bug was fixed in kernel-package 10.063. So I guess that all that is needed is a rebuild of the kernels with a Build-Depends on a sufficiently recent kernel-package. So, apparently, Manoj has already fixed his part, and the issue seems to be now in your hands, kernel people, if the plan by Julian is correct (rebuild kernels using a recent enough kernel-package). Nice to know, but it would have been nice for Manoj to tell us about it, especially as the issue surfaced within days of the -3 upload. We really need a better way to handle bug reports which affect more than one package, since cloning and merging is not the best way to go for those. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395110: linux-image-2.6.18-1-powerpc: uninstallable
On Sun, Oct 29, 2006 at 03:09:32PM +0100, Santiago Vila wrote: On Sun, 29 Oct 2006, Sven Luther wrote: We really need a better way to handle bug reports which affect more than one package, since cloning and merging is not the best way to go for those. In the past, the BTS allowed things like this: Package: foo, bar I'm not sure if this is still supported. I have seen those too, but never saw them documented, and never understood when the bug is closed or not. Ideally, the bug would be closed only if it was closed on all packages, and ideally too we could set severity and tags per-package, but the bug still remained the same for all packages. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395259: nobootloader: [powerpc/pegasos] bad sed invocation breaks devfs style paths (division by zero)
On Thu, Oct 26, 2006 at 03:25:33AM +0200, Frans Pop wrote:
On Wednesday 25 October 2006 23:12, Sven Luther wrote:
It seems that nobootloader uses still devfs paths for some reason. The
following line :
That is not so strange as that line is using the exact same variable
$bootfs_devfs as its base that the old code did...
Yeah, i suppose this should have gone, but the patch that got applied back
then is not the one i wrote and tested, but the one you or more probably
Colin Watson adapted.
Should it be using something different instead? What is the value of
$bootfs_disk_syspath and $bootfs_disk if you run the code with 'set -x'?
I suppose that the code should be rewritten to remove all devfs information, i
am not sure how to do this because i didn't look at the devfs-removal code,
and Colin was handling that.
For now I've added a comment that that should probably be changed at some
point.
(To be very honest, I don't see the point of the code added in 1.10 at all
as the devfs path is still used as the base for the whole piece of code;
I guess it is in preparation of a further future transition.)
Well, my old patch was supposed to check for the version of the pegasos
firmware, and then substract 1 for older firmwares for the disk number.
That said, please also apply the first hunk of the attached patch, which bumps
the check to 1.4, as my colegues released a 1.3 firmware from an older tree,
and i had to bump the version of the version with the correct disk numbering.
P.S. Your patch left the old line in the code instead of replacing it...
Yeah, sorry. Would still have worked though :)
Friendly,
Sven Luther
Index: postinst
===
--- postinst(revision 42226)
+++ postinst(working copy)
@@ -39,12 +39,12 @@
rest=${rest#*.}
fv3=${rest%%.*}
if [ $fv1 -eq 1 ]; then
- if [ $fv2 -eq 2 ] [ $fv3 -ge 99 ]; then
+ if [ $fv2 -eq 3 ] [ $fv3 -ge 99 ]; then
partition_offset=0
- elif [ $fv2 -ge 3 ]; then
+ elif [ $fv2 -ge 4 ]; then
partition_offset=0
fi
- elif [ $fv1 -ge 2 ]; then
+ elif [ $fv1 -ge 3 ]; then
partition_offset=0
fi
fi
@@ -74,14 +74,14 @@
lun=$(echo $bootfs_disk | cut -d:
-f4)
;;
esac
- part=$(($(echo $bootfs_devfs | sed 's/[^0-9]*//') -
$partition_offset))
+ part=$(($(echo $bootfs_devfs | sed 's%^.*part%%') -
$partition_offset))
else
kind=`echo $bootfs_devfs | sed -e 's%/dev/%%' -e
's%/host.*$%%'`
host=`echo $bootfs_devfs | sed -e 's%^.*host%%' -e
's%/bus.*$%%'`
bus=`echo $bootfs_devfs | sed -e 's%^.*bus%%' -e
's%/target.*$%%'`
target=`echo $bootfs_devfs | sed -e 's%^.*target%%' -e
's%/lun.*$%%'`
lun=`echo $bootfs_devfs | sed -e 's%^.*lun%%' -e
's%/part.*$%%'`
- part=$(($(echo $bootfs_devfs | sed -e 's%^.*part%%') -
$partition_offset))
+ part=$(($(echo $bootfs_devfs | sed -e 's%^.*part%%')
- $partition_offset))
fi
# We don't know how to map non ide or scsi disks
Index: changelog
===
--- changelog (revision 42226)
+++ changelog (working copy)
@@ -1,3 +1,10 @@
+nobootloader (1.13) UNRELEASED; urgency=low
+
+ [ Sven Luther ]
+ * Fixed bad sed invocation, which failed on devfs-style paths.
+
+ -- Sven Luther [EMAIL PROTECTED] Wed, 25 Oct 2006 22:59:00 +0200
+
nobootloader (1.12) unstable; urgency=low
[ Updated translations ]
@@ -31,7 +38,7 @@
partitions at 0.
[ Sven Luther ]
- * Update template for Genisi systems. Closes #388591.
+ * Update template for Genesi systems. Closes #388591.
[ Christian Perrier ]
* Avoid splitting a sentence in two parts which can make translations
Bug#395259: nobootloader: [powerpc/pegasos] bad sed invocation breaks devfs style paths (division by zero)
On Thu, Oct 26, 2006 at 01:33:55PM +0200, Frans Pop wrote:
On Thursday 26 October 2006 09:10, Sven Luther wrote:
That said, please also apply the first hunk of the attached patch,
which bumps the check to 1.4, as my colegues released a 1.3 firmware
from an older tree, and i had to bump the version of the version with
the correct disk numbering.
No idea what you're talking about here. I see nothing regarding that in
your patch.
Did you see the new version i attached :
Index: postinst
===
--- postinst(revision 42226)
+++ postinst(working copy)
@@ -39,12 +39,12 @@
rest=${rest#*.}
fv3=${rest%%.*}
if [ $fv1 -eq 1 ]; then
- if [ $fv2 -eq 2 ] [ $fv3 -ge 99 ]; then
+ if [ $fv2 -eq 3 ] [ $fv3 -ge 99 ]; then
partition_offset=0
- elif [ $fv2 -ge 3 ]; then
+ elif [ $fv2 -ge 4 ]; then
partition_offset=0
fi
- elif [ $fv1 -ge 2 ]; then
+ elif [ $fv1 -ge 3 ]; then
partition_offset=0
fi
fi
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395259: nobootloader: [powerpc/pegasos] bad sed invocation breaks devfs style paths (division by zero)
Package: nobootloader Version: 1.12 Severity: grave Tags: patch Justification: renders package unusable It seems that nobootloader uses still devfs paths for some reason. The following line : part=$(($(echo $bootfs_devfs | sed 's/[^0-9]*//') - $partition_offset)) will fail on paths like this one : /dev/ide/host0/bus0/target0/lun0/part4 Since : $ echo /dev/ide/host0/bus0/target0/lun0/part4 | sed 's/[^0-9]*//' 0/bus0/target0/lun0/part4 which causes the calculation to result in a division by zero, thus making it impossible to create a bootable pegasos system. Please apply the below patch to fix this problem. Friendly, Sven Luther -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Index: nobootloader/debian/postinst === --- nobootloader/debian/postinst (revision 42226) +++ nobootloader/debian/postinst (working copy) @@ -75,13 +75,14 @@ ;; esac part=$(($(echo $bootfs_devfs | sed 's/[^0-9]*//') - $partition_offset)) + part=$(($(echo $bootfs_devfs | sed 's%^.*part%%') - $partition_offset)) else kind=`echo $bootfs_devfs | sed -e 's%/dev/%%' -e 's%/host.*$%%'` host=`echo $bootfs_devfs | sed -e 's%^.*host%%' -e 's%/bus.*$%%'` bus=`echo $bootfs_devfs | sed -e 's%^.*bus%%' -e 's%/target.*$%%'` target=`echo $bootfs_devfs | sed -e 's%^.*target%%' -e 's%/lun.*$%%'` lun=`echo $bootfs_devfs | sed -e 's%^.*lun%%' -e 's%/part.*$%%'` - part=$(($(echo $bootfs_devfs | sed -e 's%^.*part%%') - $partition_offset)) + part=$(($(echo $bootfs_devfs | sed -e 's%^.*part%%') - $partition_offset)) fi # We don't know how to map non ide or scsi disks Index: nobootloader/debian/changelog === --- nobootloader/debian/changelog (revision 42226) +++ nobootloader/debian/changelog (working copy) @@ -1,3 +1,10 @@ +nobootloader (1.13) UNRELEASED; urgency=low + + [ Sven Luther ] + * Fixed bad sed invocation, which failed on devfs-style paths. + + -- Sven Luther [EMAIL PROTECTED] Wed, 25 Oct 2006 22:59:00 +0200 + nobootloader (1.12) unstable; urgency=low [ Updated translations ] @@ -31,7 +38,7 @@ partitions at 0. [ Sven Luther ] - * Update template for Genisi systems. Closes #388591. + * Update template for Genesi systems. Closes #388591. [ Christian Perrier ] * Avoid splitting a sentence in two parts which can make translations
Bug#392774: Not been able to reproduce this on a powerpc/pegasos/radeon92xx ...
Hi As Eddyp asked me, i have tested wormux on a sid powerpc pegasos machine, and i was not able to reproduce this bug. The machine runs womrux 0.7.4-1, xorg 7.1.0-1, and has a radeon 9200 graphic card. I played some in the goodandevil map, and used the gnu launcher, and was not able to bring the system to a halt. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390994: linux-2.6: e100 microcode: distributable with BSD license, but license not in Linux source
On Wed, Oct 04, 2006 at 04:08:02AM -0400, Nathanael Nerode wrote: Package: linux-2.6 Severity: serious Justification: copyright OK. So the e100 microcode situation isn't as bad as we expected -- thanks entirely to OpenBSD. Can you check that those binary blobs are indeed bit-to-bit identic ? I'm opening this bug to track this issue because I expect it will be resolved relatively quickly, and because the 'big bug' is getting to be way too much. There are three different bundles of microcode: /* Micro code for 8086:1229 Rev 8 */ ... #define D101M_B_RCVBUNDLE_UCODE \ This is present in OpenBSD, in http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2content-type=text/plain under a 3-clause BSD license. Under the same name. /* Micro code for 8086:1229 Rev 9 */ ... #define D101S_RCVBUNDLE_UCODE \ This is present in OpenBSD, in http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2content-type=text/plain under a 3-clause BSD license. Under the same name. /* Micro code for the 8086:1229 Rev F/10 */ ... #define D102_E_RCVBUNDLE_UCODE \ This is present in OpenBSD, in http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2content-type=text/plain under a 3-clause BSD license. Under the same name. It's worth noting that OpenBSD has substantial additional downloadable microcode in that file. The copyright problem will be fixed as soon as the proper copyright notice and license from OpenBSD's copy is added to Debian's copy. Simple and excellent. :-) Thanks OpenBSD! However, the microcode is still non-free (lack of source). Conversion to userland firmware loading should be done (and I might even get around to it myself). If this is done, I strongly advise that the *same format* and *same filenames* be used as in OpenBSD, so that the firmware files are interchangable; no point in deliberate incompatibility. Indeed. Do you agree that we can do this post-etch, as the current GRs propose ? Fact is d-i will not have support for non-free firmware in etch, which means qlogic will be unsupported, and any such firmware we move out is in the same case. Frans's No way and corresponding statement from Joey Hess make this rather a definitive situation. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390347: linux-2.6: [powerpc64] XServe G5 fails to boot with Invalid memory access
The g5_defconfig .config works fine, so there is something wrong with the debian config on those machines. I will investigate this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390347: linux-2.6: [powerpc64] XServe G5 fails to boot with Invalid memory access
Package: linux-2.6 Version: 2.6.18-2 Severity: grave Justification: renders package unusable Debian's 2.6.18 kernel on an apple XServe G5 powermac (dual cpu) dies with : done copying OF device tree ... Building dt srrings... Building dt structure... Device tree strings 0x0211 - 0x02111466 Device tree struct 0x02112000 - 0x02134000 Calling quiesce ... returning from prom_init Invalid memory access at SRR0: .0140399c SRR1: 1000.00083030 Apple RackMac3,1 5.1.7f2 BootROM built on 12/09/04 at 10:58:45 ... Friendly, Sven Luther -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375035: [EMAIL PROTECTED]: Re: Bug#366620: 2.6.16-1-powerpc fails to mount rootfs, 2.6.15-1-powerpc works]
Christian, see BenH's reply to this.
BenH, this is by booting an oldworld with quik, and it certainly solves a
problem for Christian, and there have been various bug reports about quik
being broken since 2.6.16.
Christian, benh mentioned :
09:01 benh but basically, you should add some printk to the code in
setup-common that reads the property back from the device-tree
09:02 benh in check_for_initrd()
Friendly,
Sven Luther
On Mon, Sep 18, 2006 at 04:51:14PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2006-09-18 at 08:40 +0200, Sven Luther wrote:
Hi benh, can you have a look at this patch ? It fixes the oldworld initramfs
problem in newer kernels.
Sounds all bogus claims to me. It's certainly shall not be storing the
address of val. prom_setprop() takes a pointer to the data to be stored.
Data is thus first copied to val, then a pointer to val is passed to
prom_setprop. Is the patch actually fixing anything ? Also is this a 32
or 64 bits kernel and is this booting with BootX or open firmware (there
is a separate problem with bootx_init.c that has been fixed upstream
where it failed to add the initrd to the reserve map).
Ben.
Friendly,
Sven Luther
- Forwarded message from Christian Aichinger [EMAIL PROTECTED] -
Date: Sun, 17 Sep 2006 17:17:40 +0200
From: Christian Aichinger [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], debian-kernel@lists.debian.org
Subject: Re: Bug#366620: 2.6.16-1-powerpc fails to mount rootfs,
2.6.15-1-powerpc works
Message-ID: [EMAIL PROTECTED]
Mail-Followup-To: Christian Aichinger [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
debian-kernel@lists.debian.org
On Fri, Sep 15, 2006 at 11:21:33AM +0200, Christian Aichinger wrote:
The kernel somehow loses the information where the initrd image is
placed in memory. The correct data is there in
arch/powerpc/kernel/prom_init.c:prom_check_initrd(), but in
init/initramfs.c:populate_rootfs() it's wrong, initrd_{start,end}
are both 0.
arch/powerpc/kernel/prom_init.c:prom_check_initrd() is broken. The
relevant part of the code is:
,--
| unsigned long val;
| ...
| val = RELOC(prom_initrd_start);
| prom_setprop(_prom-chosen, /chosen, linux,initrd-start,
|val, sizeof(val));
| val = RELOC(prom_initrd_end);
| prom_setprop(_prom-chosen, /chosen, linux,initrd-end,
|val, sizeof(val));
`--
As you can see it tries to store pointers to initrd start/end in the
/chosen node, however in reality it stores the address of val, a
local variable. Since that's long gone invalid when the values are
read out from /chosen again, the result is undefined.
The attached is a patch fixing the problem. It would be nice if the
bug submitters could test it to see if it fixes their problems too.
Cheers,
Christian Aichinger
PS: arch/powerpc/platforms/powermac/bootx_init.c does something
similar, though it looks saner, as it copies *val into it's own
permanent memory block AFAICS.
--- a/arch/powerpc/kernel/prom_init.c 2006-09-15 18:33:50.0
+0200
+++ b/arch/powerpc/kernel/prom_init.c 2006-09-15 18:33:44.0
+0200
@@ -2141,17 +2141,17 @@
struct prom_t *_prom = RELOC(prom);
if (r3 r4 r4 != 0xdeadbeef) {
- unsigned long val;
+ unsigned long *ptr;
RELOC(prom_initrd_start) = is_kernel_addr(r3) ? __pa(r3) : r3;
RELOC(prom_initrd_end) = RELOC(prom_initrd_start) + r4;
- val = RELOC(prom_initrd_start);
+ ptr = RELOC(prom_initrd_start);
prom_setprop(_prom-chosen, /chosen, linux,initrd-start,
-val, sizeof(val
Bug#375035: Bug#366620: 2.6.16-1-powerpc fails to mount rootfs, 2.6.15-1-powerpc works
On Sun, Sep 17, 2006 at 05:17:40PM +0200, Christian Aichinger wrote:
On Fri, Sep 15, 2006 at 11:21:33AM +0200, Christian Aichinger wrote:
The kernel somehow loses the information where the initrd image is
placed in memory. The correct data is there in
arch/powerpc/kernel/prom_init.c:prom_check_initrd(), but in
init/initramfs.c:populate_rootfs() it's wrong, initrd_{start,end}
are both 0.
arch/powerpc/kernel/prom_init.c:prom_check_initrd() is broken. The
relevant part of the code is:
Thanks for the patch. I have tentatively added it to trunk (well, once i do a
test build, and thus check it doesn't break), and it should be in tomorrow's
or more probably the day after's snapshot builds. I will probably upload a
package to http://people.debian.org/~luther once the build finishes.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366620: kernel-image-2.6.16-2 on oldworld (success with a small change in config)
On Fri, Sep 08, 2006 at 03:20:58PM +0200, Hans Ekbrand wrote: Hi! Hi, please make sure you CC debian-kernel too on issues like this. The official debian kernels for powerpc stopped working for me with 2.6.16 (2.6.15 works fine). The 2.6.16 ones fail to mount root fs at boot, which I have reported in bug #366620 I compiled my own 2.6.16 with a minimal change in .config, and that was it, 2.6.16 now boots on my oldworld mac. The needed change in config was the following: (diff against ./boot/config-2.6.16-2-powerpc in the package linux-image-2.6.16-2-powerpc_2.6.16-18_powerpc.deb) 4c4 # Sat Aug 19 00:42:57 2006 --- # Fri Sep 8 09:14:38 2006 772c772 CONFIG_BLK_DEV_IDEDISK=m --- CONFIG_BLK_DEV_IDEDISK=y 2317c2317 CONFIG_EXT2_FS=m --- CONFIG_EXT2_FS=y 2328c2328 CONFIG_FS_MBCACHE=m --- CONFIG_FS_MBCACHE=y I think this shows that there is some problem with loading the proper modules for ide and ext2 from the initrd. As stated in the bugreport of #366620 I have tried both yaird and the other initrd creator. I don't know about the FS_MBCACHE=y thing, that must have been set automatically. Will you consider appling this patch to the config? While it is not the right solution in the long term, it would make oldworld macs run with official debian kernels again (at least the ones with IDE-drives). No, please get the ramdisk creator packages to get fixed for this one, if it is that the issue. Also, can you please try the 2.6.18-rc6 packages from : http://kernel-archive.buildserver.net/debian-kernel/pool/main/l/linux-2.6/ and see if your problem persists there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376771: remove unused 2.4 images
On Sun, Aug 20, 2006 at 04:12:06AM +0200, Jeroen van Wolffelaar wrote: And I have no idea about: kernel-patch-2.4.27-apus This one can go too. Actually, i believe it is part of the kernel-source-2.4.27-powerpc or whatever its name was source package, which can go also. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383403: closed by maximilian attems [EMAIL PROTECTED] (Re: Bug#383403: linux-2.6: includes nondistributable and non-free binary firmware)
On Thu, Aug 17, 2006 at 06:05:30PM +0200, maximilian attems wrote: On Thu, Aug 17, 2006 at 08:57:52AM -0700, [EMAIL PROTECTED] wrote: your thrown away grepping is the bad start. Maks, please don't pick up a fight with larry so quickly, this is something that you know was coming, which all the kernel team knew was coming, and the release team also was aware of as shown with the past hints from Andreas Barth, wearing his RM hat, about this. anyway if you want to improve the legal situtation use: http://wiki.debian.org/KernelFirmwareLicensing dilinger succeeded in various firmware relicensing thanks to his quest to the vendors. feel free to pick up. Notice that i was the first who started this and contacted broadcom, but then Andres did most of the follow up work on this, and as said, it makes those firmware again distributable, but not free enough to enter main. I am dubious though that the wiki page can easily be modified to look as nicely as the page larry provided, but then i am no wiki expert, so i will let others comment who are more wiki experts (jonas maybe ?). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383403: closed by maximilian attems [EMAIL PROTECTED] (Re: Bug#383403: linux-2.6: includes nondistributable and non-free binary firmware)
On Thu, Aug 17, 2006 at 11:43:52PM +0200, Jonas Smedegaard wrote: On Thu, 17 Aug 2006 21:39:00 +0200 Sven Luther wrote: I am dubious though that the wiki page can easily be modified to look as nicely as the page larry provided, but then i am no wiki expert, so i will let others comment who are more wiki experts (jonas maybe ?). Beautification of wiki done! Euh, i meant, would it be possible to include the nice table larry had done into the wiki, sorry for not being clear enough. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383403: closed by maximilian attems [EMAIL PROTECTED] (Re: Bug#383403: linux-2.6: includes nondistributable and non-free binary firmware)
On Fri, Aug 18, 2006 at 12:10:40AM +0200, Jonas Smedegaard wrote:
On Thu, 17 Aug 2006 23:54:09 +0200 Sven Luther wrote:
On Thu, Aug 17, 2006 at 11:43:52PM +0200, Jonas Smedegaard wrote:
On Thu, 17 Aug 2006 21:39:00 +0200 Sven Luther wrote:
I am dubious though that the wiki page can easily be modified to
look as nicely as the page larry provided, but then i am no wiki
expert, so i will let others comment who are more wiki experts
(jonas maybe ?).
Beautification of wiki done!
Euh, i meant, would it be possible to include the nice table larry
had done into the wiki, sorry for not being clear enough.
Ah.
Add that text from Larry yourself to the wiki page, please. Just copy
as is, at the bottom of the page, surrounded by triple curly quotes -
like this:
{{{
Bla bla
yada yada
}}}
Then I might find time to beautify it later (or others might...)
Done, i tried to do a little bit with the tables, but i guess the {{{ }}} goes
in the way.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383403: closed by maximilian attems [EMAIL PROTECTED] (Re: Bug#383403: linux-2.6: includes nondistributable and non-free binary firmware)
On Fri, Aug 18, 2006 at 12:10:40AM +0200, Jonas Smedegaard wrote:
On Thu, 17 Aug 2006 23:54:09 +0200 Sven Luther wrote:
On Thu, Aug 17, 2006 at 11:43:52PM +0200, Jonas Smedegaard wrote:
On Thu, 17 Aug 2006 21:39:00 +0200 Sven Luther wrote:
I am dubious though that the wiki page can easily be modified to
look as nicely as the page larry provided, but then i am no wiki
expert, so i will let others comment who are more wiki experts
(jonas maybe ?).
Beautification of wiki done!
Euh, i meant, would it be possible to include the nice table larry
had done into the wiki, sorry for not being clear enough.
Ah.
Add that text from Larry yourself to the wiki page, please. Just copy
as is, at the bottom of the page, surrounded by triple curly quotes -
like this:
{{{
Bla bla
yada yada
}}}
Then I might find time to beautify it later (or others might...)
Will this not cause problem with the table ? This is the one which worries me.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382788: [Yaird-devel] Bug#382788: yaird does not uses the kernel command like to find out the root partition
On Mon, Aug 14, 2006 at 01:58:47PM +0200, maximilian attems wrote: severity 382788 serious stop see justification below On Mon, Aug 14, 2006 at 02:39:09AM +0200, Jonas Smedegaard wrote: On Sun, 13 Aug 2006 13:17:55 +0200 Pierre Habouzit wrote: Instead, it uses a hardcoded value he takes from /etc/fstab presumably, that makes a system where you rearraged the partition completely impossible to boot, if you didn't faked the next /etc/fstab and regenerated the initrd. Since I use grub, and if I do forget to change the menu.lst it has a console to do so, I can always boot. the preliminary extraction of the initrd then works, but the switch root just fails because it does not finds the correct root, whereas it on the damn kernel command line ! Correct. That's a limitation in the yaird design: An abolute minimal initrd image is composed, based on your current setup. Only kernel modules required to access your root filesystem is included on the image, and only the devices needed are created. even initrd-tools parses the boot cmdline. initrd-tools allowed to hardcode the root, but a different root bootarg would override that. ignoring /proc/cmdline root bootarg is a critical rc bug for any init of an initrd/initramfs generator. filed at severity serious to raise awareness of that bug. Jonas, i agree on this with maks and pierre, being able to override root= is a very essential feature. Furthermore, it is not all that difficult to implement (just check for an existing root= command line before providing your own copy), probably 3 lines of perl or so, since the comand line is available as /proc/cmdline. I am no perl expert though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382788: [Yaird-devel] Bug#382788: yaird does not uses the kernel command like to find out the root partition
On Mon, Aug 14, 2006 at 04:03:31PM +0200, Jonas Smedegaard wrote: On Mon, 14 Aug 2006 14:57:21 +0200 Sven Luther wrote: Jonas, i agree on this with maks and pierre, being able to override root= is a very essential feature. Furthermore, it is not all that difficult to implement (just check for an existing root= command line before providing your own copy), probably 3 lines of perl or so, since the comand line is available as /proc/cmdline. I am no perl expert though. There's a difference between being able to read the root option provided on commandline and actually supporting it. Well, once you can read the root options, you can easily enough make an initial effort to support it, even with the below caveats. You just need to use this value instead of the detected at build time one, i have not looked, but i can't imagine it is anything but trivial. The fundamental design of yaird causes it to not be able to support changing root at boot time. It may happen to work for some specific cases, but not in general. * Only kernel modules specifically needed to reach the default root is included with the image. Sure, but even with the same modules, it is still good to be allowed to override root, be it only to be able to boot into the system and rerun yaird or something. Imagine you moved the disk around on the same controler, or inserted a new disk and the ordering changed. Imagine too you used a tool like partimage to move the whole system to another partition of the same disk or of a similar machine. * Only device files specifically needed to reach the default root is created while in the pre-root boot stage. Indeed, but it would be trivial to create the command-line passed root instead of the build-time detected one. I consider it a pretty damn good feature to have. But not essential. Ok. Please provide pointers to official statements supporting the claim that this is a release-critical issue. I will let Maxs reply to this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380028: closed by Bastian Blank [EMAIL PROTECTED] (Re: Bug#380028: mkvmlinuz requires -fno-stack-protector with gcc-4.1)
On Sun, Jul 30, 2006 at 10:35:15AM -0700, Matt Zimmerman wrote: On Sun, Jul 30, 2006 at 06:50:10PM +0200, Sven Luther wrote: On Thu, Jul 27, 2006 at 09:51:40AM +0200, Emanuel Steen wrote: Please, don't ignore the bug report just because I'm using Ubuntu. It's the same package, version 23 of mkvmlinuz in Debian. I just found it better to report it to Debian too so you also know about the problem. The ubuntu kernel maintainers removed the mkvmlinuz support i provided to their kernel package with a nobody should be using oldworld [pmacs] kind of clueless message, and provided insulting when i subsequently complained about this fact. That isn't true any more now than it was the first time you asserted it, and I've corrected you several times in other forums. Please define the definition of 'now', and i have not seen any instance of you correcting me on other forums. I know that as of ubuntu/dapper, the current stable ubuntu, mkvmlinuz support is not included, and *I* had to provide a upgraded mkvmlinuz so people where able to install ubuntu on the pegasos and other zImage using boxes (like the PReP ones and some IBM CHRPs). Also, even if the patch was readded or some other solution was found, the above assertion is still true, as it clearly describe what happened, and unless you have a time machine, it will remain true. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380028: closed by Bastian Blank [EMAIL PROTECTED] (Re: Bug#380028: mkvmlinuz requires -fno-stack-protector with gcc-4.1)
On Sun, Jul 30, 2006 at 08:47:19PM +0200, Emanuel Steen wrote: The ubuntu kernel maintainers removed the mkvmlinuz support i provided to their kernel package with a nobody should be using oldworld [pmacs] kind of clueless message, and provided insulting when i subsequently complained about this fact. I know, that sucks... but that's the way it is (was?). Now we need to aim for the future. Indeed, Matt Zimermann made some claims that it is already fixed, but gives no real detail. What i see is that mostly patches i send to the ubuntu BTS for pegasos support got ignored until it was too late, and this probably happened for breezy and dapper, which are the two last releases. I have no real interest to continue losing my time with them, so others (you?) are welcome to follow up on this and make sure they won't make this mistake the next time. As such, mkvmlinuz 23 added a copy of the mkvmlinuz support files, taken from the 2.6.17 debian kernel (mostly upstream though), which may or not work for ubuntu kernels, but are a best effort solution. In any case, if you want to use mkvmlinuz with ubuntu kernels, it is recomended that you rebuild the mkvmlinuz package on an ubuntu system, which would take care of this problem. I recompiled mkvmlinuz with -fno-stack-protector and it worked. The new kernel booted just fine and everything seems good. But the fact is that mkvmlinuz in Ubuntu is a plain copy from Debian, so I figured that it would be wise to fix it upstream. The thing is that I saw that gcc-4.1 had stack-protector enabled by default but gcc-4.0 didn't (in Ubuntu that is). I just assumed that was a change upstream in the gcc tree, but seems I was wrong about that. Ok. I don't know about the current version of gcc in Debian, I just have a server using Debian which I haven't updated in a while so it doesn't have the latest version of all packages - I just works ;) Yep, the problem is an ABI change in gcc between the version used to build mkvmlinuz and the one used to build the kernel. If they had not removed the mkvmlinuz support patch in such an insulting way, you would not have this problem, so you know where to complain. Furthermore, Matt Zimermann wrote above in a message without evidence that this issue is fixed, and i am now very curious to know how it is fixed. But after Martin Michlmayr comment that Debians gcc didn't have stack-protector enabled I updated and checked my Debian system and saw I was wrong. Didn't want to create any Ubuntu vs Debian stuff, just thought it would be better for the greater good to change it in Debian too. Anyway, sorry about that. Well, the ubuntu folk kernel folk are the cause of this one. But it is clear that it would be best to educate the ubuntu speople so they are more clueless about this issues. I think i can say that the debian kernel team at large regret the times when Fabbionne was the ubuntu kernel maintainer, and useed to cooperate more actively with the debian kernel team, rather than the void that is the current communication situation. And then they make noise at conferences about ways to unifying the debian based kernels. Yeah, but I'm not that involved in the kernel team and don't know anyone there... but we will see in the future. Just go ahead, their BTS is usually a lose of time anyway, as it gets ignored, but i am sure that if you complain enough to the right people, they will move themselves or something. I just don't have enough patience for this, especially as some of the ubuntu folk participated in the witch-hunt against me earlier this year, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380028: closed by Bastian Blank [EMAIL PROTECTED] (Re: Bug#380028: mkvmlinuz requires -fno-stack-protector with gcc-4.1)
On Thu, Aug 03, 2006 at 03:19:25PM -0700, Matt Zimmerman wrote: On Thu, Aug 03, 2006 at 10:50:56PM +0200, Sven Luther wrote: On Sun, Jul 30, 2006 at 10:35:15AM -0700, Matt Zimmerman wrote: That isn't true any more now than it was the first time you asserted it, and I've corrected you several times in other forums. Please define the definition of 'now', and i have not seen any instance of you correcting me on other forums. The previous instance was in March, on debian-devel, in the removal of svenl from the project thread. Message-ID: [EMAIL PROTECTED] Sorry, no easy message-id to real message mapping handy. I apologize if you missed it, but I did send it. Ah, so you are not saying, contrary to appareances, that the mkvmlinuz support was recently readded to the ubuntu kernels. I know that as of ubuntu/dapper, the current stable ubuntu, mkvmlinuz support is not included, and *I* had to provide a upgraded mkvmlinuz so people where able to install ubuntu on the pegasos and other zImage using boxes (like the PReP ones and some IBM CHRPs). That may be true, and unfortunate, but that does not excuse your characterization of this situation as malicious. Please do not do that anymore. Err, i clearly informed the ubuntu kernel folk about this problem lot of month ago, and not only did they ignore this, but where also rude to me. Well, if this is not malicious, it is at least careless. Also, even if the patch was readded or some other solution was found, the above assertion is still true, as it clearly describe what happened, and unless you have a time machine, it will remain true. I have no objection to you stating the facts of what is and what was supported, only to you attributing malice and misrepresenting what was said (especially when you put quotation marks around it as if it is a quotation). Oh well, you where not there, so you cannot judge, this is how it happened in my perspective and i am not misrepresenting it. Just one point, the quotations marks where there because it was a from-memory quotation, which may not be 100% percent exact, but the general idea stays. If you claim it is not true, i would love to know the real reason the patch was removed (which i guess are because at one point it didn't apply cleanly, and was removed unthinkingly). If the ubuntu kernel folk had more communication with the debian kernel folk, as it used to be in the fabbione times, it would be less of an issue, but things being as they are ... Now, the issue is mostly moot, you only need to upgrade mkvmlinuz to the latest debian version in a dapper point release or upgrade, and import the newer mkvmlinuz in your dapper+1 version, and all will be fine. I created mkvmlinuz 23 especially in order to be able to run mkvmlinuz-support-less kernel packages like the ubuntu one, and it has been tested on the released dapper kernel, so it should be rather painless for you to solve this issue, but as bugs i submit against the ubuntu kernel usually get forgotten and only end up rotting in the BTS, without a single comment, ... Friendly, Sven Luther -- - mdz --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
