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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453121: gnome-randr-applet: 453121: new upstream maintainer
On Thu, Apr 09, 2009 at 01:10:39PM +0800, Paul Wise wrote: Looks like grandr_applet/gnome-randr-applet has been adopted by a new maintainer and given some updates: http://freshmeat.net/projects/grandr_applet http://kdekorte.googlepages.com/grandr_applet There is also a useful patch for it here: http://ubuntuforums.org/showthread.php?t=700270 As you may know, i have been summarily expulsed from debian and it has been made clear that my contribution is not wanted, so you would be better off making a sponsored upload yourself. Sadly, Sven Luther -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514055: debian still not working on PS3
On Fri, Feb 27, 2009 at 07:53:33PM +0100, Martin Michlmayr wrote: * Geoff Levand geoffrey.lev...@am.sony.com [2009-02-26 09:43]: I just tried the latest testing CD (2000.02.12), and it still fails with the same problem I reported for Lenny DI RC2. The installer fails on mounting the CD-ROM. The PS3 ps3_gelic network and PS3 ps3rom and ps3disk storage drivers are missing from the installer's initrd. I entered a bug report that went unanswered here: The short answer is that there isn't really an active powerpc porter working on the installer. That's why your bug report is unanswered. I'm copying Wouter Verhelst who indicated some interest in helping with the powerpc port. And you have only yourself to thank for this. Martin, don't you think that after three year, it is not time that you tried to make up for the damage you have caused ? Sadly, Sven Luther -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509979: linux-image-2.6.27-1-686: SD/MMC/MS card not supported on sony vaio (ricoh driver)
Package: linux-image-2.6.27-1-686
Version: 2.6.27-1~experimental.1~snapshot.12406
Severity: normal
Please enable the CONFIG_MMC_SDRIVOH_CS driver in the experimental
2.6.27 kernels, since it may help making the builtin ricoh card
controller work on ony laptops :
config MMC_SDRICOH_CS
tristate MMC/SD driver for Ricoh Bay1Controllers (EXPERIMENTAL)
depends on EXPERIMENTAL MMC PCI PCMCIA
help
Say Y here if your Notebook reports a Ricoh Bay1Controller PCMCIA
card whenever you insert a MMC or SD card into the card slot.
To compile this driver as a module, choose M here: the
module will be called sdricoh_cs.
config-2.6.27-1-686:# CONFIG_MMC_SDRICOH_CS is not set
lspci gives :
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)
09:04.0 0607: 1180:0476 (rev ba)
09:04.1 0c00: 1180:0832 (rev 04)
09:04.3 0880: 1180:0843 (rev 11)
09:04.4 0880: 1180:0592 (rev 11)
And the driver says :
pci_get_device(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_RL5C476, pci_dev))) {
so this is indeed the same device.
Sadly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#439006: Scheduling linux-2.6 2.6.22-4
On Fri, Oct 31, 2008 at 04:46:46PM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [070830 06:16]: I would like to know if this upload would include the efika patches that where included in the subversion repository after the 2.6.22-3 upload, or if you will silently disable them, after you kicked me out of the debian-kernel team without reasonable justification or even trying to speak to me. Sorry for following up so late on this bug report. I just asked on IRC: 16:25 aba can someone comment on http://bugs.debian.org/439006 16:25 aba (Efika and sony PS3 patches in linux-2.6) 16:49 waldi aba: both efika and ps3 support is maintained in the linus tree since a long time. so it is possible to fix serious problems with the linux upstream stable updates and don't need to duplicate the work. ps3 support was enabled by me for 2.6.26, so sven tried to fix not enabled things 16:49 aba waldi: so, are the issues reported there now already resolved? or are they not relevant anymore? or ...? 16:50 waldi sven did not further try to push massive patch sets, which was just about to be submitted to the ppc maintainer, for inclusion into linux-2.6 16:51 waldi the support is upstream and from what I know working, so: not relevant anymore Is this correct? If so, I would like to close this bug report now. Sorry for the late response. I have no clue, i have not looked into this in ages, and the fact that even if i am silence and forbidden to post on debian lists, there are some people who still find it funny to try to hurt me, as holger did by asking the DPL to stop me from going to the emdebian extremadura meeting, or Daniel Stone or Martin Shulze disfamating me on public lists, i don't really care what debian does or not, for me you can all go to hell, and you assuredly will end there, given how evil you behaved in this matter. And there are still people around claiming with a straigth face that i am not being censored ... You all disgust me, and i don't understand how you guys can look into a mirror and not be sick of what you did. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439006: Scheduling linux-2.6 2.6.22-4
On Fri, Oct 31, 2008 at 04:46:46PM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [070830 06:16]: I would like to know if this upload would include the efika patches that where included in the subversion repository after the 2.6.22-3 upload, or if you will silently disable them, after you kicked me out of the debian-kernel team without reasonable justification or even trying to speak to me. Sorry for following up so late on this bug report. I just asked on IRC: 16:25 aba can someone comment on http://bugs.debian.org/439006 16:25 aba (Efika and sony PS3 patches in linux-2.6) 16:49 waldi aba: both efika and ps3 support is maintained in the linus tree since a long time. so it is possible to fix serious problems with the linux upstream stable updates and don't need to duplicate the work. ps3 support was enabled by me for 2.6.26, so sven tried to fix not enabled things 16:49 aba waldi: so, are the issues reported there now already resolved? or are they not relevant anymore? or ...? 16:50 waldi sven did not further try to push massive patch sets, which was just about to be submitted to the ppc maintainer, for inclusion into linux-2.6 16:51 waldi the support is upstream and from what I know working, so: not relevant anymore Is this correct? If so, I would like to close this bug report now. Sorry for the late response. And for info, after trying to submit those patches, i was expulsed from the kernel team, without any try at communication, and later i heard that the kernel team told other persons that those patches would be acceptable, provided they don't come from Sven Luther. And then, some random asshole says i should just stay technical, and shut up, and debian has not yet made ammends for all the FUD and lies it talked about me. Really, Andreas, you that silently support the current evil status quo, you should know better than aslk me this kind of things. And waldi is particularly disgusting, because he reverted all my work on this issue *WITHOUT* addressing any of my technical comments, and had me expulsed, and the technical committee did ignore the corresponding request to it, so totally falied to do its duty and should be dismissed. Debian acted evily on this, and all those of you who silently let it happen share the fault. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499953: known upstream problem of the r5u870 driver, which seems not well maintained.
This seems to be a common problem with this driver. Upstream bugtracker has this issue open : http://bugs.mediati.org/r5u870/issue28 which is the exact same issue. (supersedes the issue19 and issue23, maybe there are more comments in those). It seems like the upstream maintainer of the r5u870 driver is not very active though, so not sure if we will see a a quick resolution to this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499953: another insightfull link
Another link to the upstream mailing list : http://lists.mediati.org/archives/r5u870-list/2008-September/46.html I don't really plan on fixing this any time soon, since I'm working on a userspace version of the driver, which should work nicely with uvcvideo hopefully. Stay tuned for updates, or follow the other thread on the list! Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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#437842: lists.debian.org: request creation of a debian-mediation mailing list
MJ, please forward this to the mailing list, as i am being censored. On Tue, Sep 02, 2008 at 11:56:04AM +0100, MJ Ray wrote: Lucas Nussbaum [EMAIL PROTECTED] wrote: Context: the creation of a debian-mediation@ mailing list is requested in #437842. I support the proposal. [...reasons...] I support the proposal if:- exempt of banning and other abuse commonly seen in when these issues are handled in other debian list, and allow is replaced by where banning only happens after with-reason warnings from two different debian developers, that allows; and This poses another problem. Who is responsible for putting in place such a ban, and what would be the criterias for putting it in place ? Your above condition, 2 different DDs, seems really slow to me, if you want to put a bottom limit, i would maybe chose the quorum of debian votes or something such meaningful. Furthermore, I believe that any person who is actually willing to participate in a debian-mediation mailing lists, will probably be able to configure procmail or another filtering software to avoir reading unwanted posts, or simply ignore them in their mail reader. That said, this brings another proposal. I believe that for the sake of transparency, we should set up a debian-censorship, where all banned or censored mails would automatically go, for all to see, instead of just being put into oblivion, so our fellow DD can check from time to time what they are stopped from reading, and maybe intervene in case of abuse of power of the list-masters, or whoever currently takes the decision to censor someone. I think also that the list of such censorship should be made publicly available, so all debian developers can see them, and judge if authority who handle this have indeed done so within the mandate given them by the whole Debian Developper body. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#256900: Ocaml compiled programs cannot be stripped
On Wed, Aug 20, 2008 at 01:51:20PM +0200, Sylvain Le Gall wrote: Hello, On Mon, Aug 18, 2008 at 05:46:50PM +0200, Xavier Leroy wrote: First, a few reminders: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900 http://caml.inria.fr/pub/ml-archives/caml-list/2004/07/181268104b59b10ed1624cb92ed996c4.fr.html Is there any news on this issue? It seems it is still on topic in OCaml 3.10.2... The plan of action that Sylvain Le Gall discussed with me a while ago was to track down the OCaml packages that use ocamlc -custom and fix them to use shared libraries instead. Many mature Caml sources still use the -custom option although it is no longer necessary. I can provide assistance tracking down the mixed bytecode/native executables that are a problem. To summarize, my take on this issue is: 1- ocamlc -custom is deprecated and packages that use it should be fixed. If this option is deprecated, i think we should handle it so for all debian package. See at the end of the mail for a proposed way of doing thing. One question though which comes to mind while reading this thread. When was the -custom version deprecated, and what does this imply for the version of ocaml in debian which will ship with lenny. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#256900: Ocaml compiled programs cannot be stripped
On Wed, Aug 20, 2008 at 05:19:17PM +0200, Xavier Leroy wrote: Hello Sven, 1- ocamlc -custom is deprecated and packages that use it should be fixed. If this option is deprecated, i think we should handle it so for all debian package. See at the end of the mail for a proposed way of doing thing. One question though which comes to mind while reading this thread. When was the -custom version deprecated, and what does this imply for the version of ocaml in debian which will ship with lenny. OK, maybe deprecated isn't the right word. :) The -custom option is not deprecated in the sense of it will be removed at some point in the future. We Caml people take backward compatibility very very seriously. This option is here to stay, but not to be improved, because: Well, let's rephrase this, since when is the shared stub way recomended over the -custom version. This was the first time that i really heard about this, altough i have been trying to do away with the -custom flag in projects since some time. Often folk only use -custom to do away with the dependencies, and kind of create a static version of the binary, which is easier to install standalone, which is not the debian use-case. The -custom option is deprecated in the sense that, since the introduction of dynamic loading of stub libraries in the bytecode interpreter circa 2001, there exists a much better alternative: put the native stubs into shared libraries and produce pure bytecode executables that dynamically load these libraries. This is better than -custom for several reasons: - smaller executables; - bytecode executables can be shared across different platforms; - it is possible to use such mixed Caml/native libraries from the toplevel. Indeed :) So, I think everyone should be gently encouraged to use shared libs instead of -custom. Especially since, as I mentioned earlier, some Caml projects that started before 2001 still force -custom when linking with standard libraries like unix.cma or str.cma, while this is now entirely unnecessary. Hope this addresses your concerns. So, are you officially gently encouraging ? Is the community really aware of your position ? 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? 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#491692: initramfs-tools: udev not copied to ramdisk as hookscript is skipped
On Tue, Jul 22, 2008 at 05:48:43PM +0200, Philipp Sternberg wrote: On Tuesday, 22. July 2008, you wrote: what is your default shell? ls -l /bin/sh Hi.. oh it's dash actually... Ah... that looks much better!!! I purged dash so that ls -l /bin/sh gave /bin/sh - bash afterwards. That solved it! (The ramdisk image now contains udev!) Maybe there should be a package dependency forbidding dash to be installed or (if that is possible to be set as default shell... Where is that configured anyway??) Anyway thanks a lot for your help and sorry for trying to set you on the wrong track (that function-script thing) I did obviously not interpret the doings of that stuff correctly... Mmm, is bash-dependency not supposed to be a bug, which we want to get ride of for lenny ? I remember mass-bug-filling for bashism or something. 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#487202: gnome-randr-applet if external monitor is unplugged
On Sat, Jun 21, 2008 at 11:03:22AM +0200, Franklin PIAT wrote: Package: gnome-randr-applet Version: 0.2-2.1 Followup-For: Bug #487202 * I could reproduce this bug with my T60, with a 1280x1024 screen. * I could also reproduce this bug on another laptop (T61/Lenny) As i have been expulsed from debian like so much garbage, gnome-randr-applet is currently unmaintained, you are welcome to take it over, and help fix this bug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462529: linux-2.6: Add config file support for efika and PS3 (preliminary)
On Wed, May 28, 2008 at 04:22:45PM -0700, Geoff Levand wrote: Bastian Blank wrote: +CONFIG_FB_PS3=y Yeah, everyone wants its favorite fb built-in. We can make this a module, the trouble is that PS3 No, not in the current state of affairs, at least. Both the serial consoles and the framebuffer devices need to be builtin, as they are vital for early output. This is also the politic that Linus Torvalds had taken, when he insisted on having visible screen feedback as early as possible in the kernel. Doing anything else here will not do anyone a favour, and will make debugging more complicated, which will cost us in the end. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483489: linux-2.6: Optional powerpc64 patches for PS3
On Thu, May 29, 2008 at 09:13:25AM +0200, Bastian Blank wrote: tags 483489 wontfix thanks On Wed, May 28, 2008 at 05:26:37PM -0700, Geoff Levand wrote: Attached are two patches against the debian linux-2.6-2.6.25 sources that would be nice to apply for the PS3. Please send them to [EMAIL PROTECTED] Also you have to use that way to fix the following error, after it have been applied to Linus' tree: | ERROR: fb_mode_option [drivers/ps3/ps3av_mod.ko] undefined! Tagging as wontfix for now. Bastian, what justification is there for not applying at lease the second patch ? Its a damn memory leak, how can you not accept it, when it is the upstream of those patches who propose them. Note that Geoff didn't just send you the whole patchset, but cherry picked two patches he considered important for the useability of the PS3, which is already memory starved, so limiting it further to 80MB and not fixing a memory leak is *NOT* acceptable. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439006: [EMAIL PROTECTED]: Bug#483489: linux-2.6: Optional powerpc64 patches for PS3]
Hi technical comittee, .. I write to you again about this topic, to show you another case of disfunctioning of the kernel team politic regarding patches, and one i am not even involved with, so you have no excuse to ignore this issue because i am involved. Geoff Levand, who is one of the sony upstream developers of the sony PS3 linux port, recently did the work to provide a configuration file to the kernel team for adding PS3 support to our kernels, which is the first step in proper debian support on PS3, since d-i work kind of depends on this. Furthermore, he proposed two patches which seems to be important, as you can see below, and bastian blank refused them asking him to go upstream first. Well, this is not some random guy providing some patch he got from some random location, but the sony team is actively bringing those patches upstream. Furthermore, the nature of those patches, which i would consider vital for the useability of the memory starved PS3, doesn't justify not applying them. One is there to allow the PS3 to make use of the full memory of the PS3, and not be limited to 80MB, the second fixes a memory leak. It is clear that the kernel team is not able to have a rationale decision on this topic, and is blocked unthinkingly because of some send upstream first discourse who is too rigid and arrogant. If they don't have enough manpower to handle this correctly, then maybe they should not expulse people of their team without any reasonable justification, and i would gladly be handling this. So, i hope that the technical committee will have the decency and basic politeness to at least aknowledge this bug report now that it hurts others than just me, and take this very serious issue in its hand, and take a decision, as its responsabilities dictate. Sadly, Sven Luther - Forwarded message from Geoff Levand [EMAIL PROTECTED] - Subject: Bug#483489: linux-2.6: Optional powerpc64 patches for PS3 Message-ID: [EMAIL PROTECTED] Date: Wed, 28 May 2008 17:26:37 -0700 From: Geoff Levand [EMAIL PROTECTED] To: [EMAIL PROTECTED] Package: linux-2.6 Version: 2.6.25 Severity: normal Tags: patch Attached are two patches against the debian linux-2.6-2.6.25 sources that would be nice to apply for the PS3. - debian-powerpc64-vmemmap-variable-page-size.diff This patch changes vmemmap to use a different region (region 0xf) of the address space whose page size can be dynamically configured at boot. The problem with the current approach of always using 16M pages is that it's not well suited to machines that have small amounts of memory such as small partitions on pseries, or PS3's. In fact, on the PS3, failure to allocate the 16M page backing vmmemmap tends to prevent hotplugging the HV's additional memory, thus limiting the available memory even more, from my experience down to something like 80M total, which makes it really not very useable. - debian-powerpc64-ps3-gelic-wireless-fix-memory-leak.patch This fixes the bug that the I/O buffer is not freed at the driver removal. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Kernel: Linux 2.6.25-3-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Add the patch powerpc-vmemmap-variable-page-size.diff to the debian linux-2.6-2.6.25 source tree. This is a backport of the patch merged into 2.6.26. --- debian/patches/bugfix/powerpc/powerpc-vmemmap-variable-page-size.diff | 214 ++ debian/patches/series/1 |1 2 files changed, 215 insertions(+) --- /dev/null +++ b/debian/patches/bugfix/powerpc/powerpc-vmemmap-variable-page-size.diff @@ -0,0 +1,214 @@ +ps3-linux-stable-2.6.25 + o Backported to 2.6.25.4 + o Removed DEBUG's + +Subject: [RFC] [PATCH] vmemmap fixes to use smaller pages + +From: Benjamin Herrenschmidt [EMAIL PROTECTED] + +This patch changes vmemmap to use a different region (region 0xf) of the +address space whose page size can be dynamically configured at boot. + +The problem with the current approach of always using 16M pages is that +it's not well suited to machines that have small amounts of memory such +as small partitions on pseries, or PS3's. + +In fact, on the PS3, failure to allocate the 16M page backing vmmemmap +tends to prevent hotplugging the HV's additional memory, thus limiting +the available memory even more, from my experience down to something +like 80M total, which makes it really not very useable. + +The logic used by my match to choose the vmemmap page size is: + + - If 16M pages are available and there's 1G or more RAM at boot, use that size. + - Else if 64K pages are available, use that + - Else use 4K pages + +--- + arch/powerpc/mm/hash_utils_64.c | 28 ++-- + arch/powerpc/mm/init_64.c |8 + arch/powerpc
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#462529: linux-2.6: Add config file support for efika and PS3 (preliminary)
On Thu, May 15, 2008 at 04:25:40PM +0200, Robert Millan wrote: On Fri, Feb 22, 2008 at 02:53:52PM +0100, Geert Uytterhoeven wrote: While Efika support is included in 2.6.24-1, PS3 support is still not enabled in 2.6.24-4. As upstream 2.6.24 has full support for PS3 (except for wireless), it would be very easy to add support for it in the Debian kernel package by enabling it in config.powerpc64, or by adding a new config.ps3. Geert, I missed the enabling it in config.powerpc64 part (actually, I think everyone missed it). If no new build needs to be added, I guess the maintainers would be fine with it? Please provide a patch if you can. I already provided a patch, which is smoledring in the BTS, since months now. Sadly, 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#462529: linux-2.6: Add config file support for efika and PS3 (preliminary)
On Thu, May 15, 2008 at 05:35:51PM +0200, Robert Millan wrote: retitle 462529 please enable PS3 support in -powerpc64 build thanks On Thu, May 15, 2008 at 04:46:10PM +0200, Sven Luther wrote: On Thu, May 15, 2008 at 04:25:40PM +0200, Robert Millan wrote: Please provide a patch if you can. I already provided a patch, which is smoledring in the BTS, since months now. Thanks Sven. I just updated your patch to the latest version of the package (moving the definitions to the pre-existing PS3 section), but I cannot check if it still works. Is it safe to assume it does? It is is safe to assume that it doesn't break other powerpc64 machines, since all the config options are machine specific. But for it to work, it would need to be tested, maybe aurelien can have a try on the PS3 ? I CC him, but otherwise, it would be nice to just apply the patch, so that kernels are built with it, and we can test them. There is i think some bootwrapper issue which needs to be solved, but the same vmlinux elf kernel should be used for both. This is the kind of things that mkvmlinuz was designed to do. In any case, would be nice if someone could test. Indeed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462529: linux-2.6: Add config file support for efika and PS3 (preliminary)
On Thu, May 15, 2008 at 05:35:51PM +0200, Robert Millan wrote: retitle 462529 please enable PS3 support in -powerpc64 build thanks On Thu, May 15, 2008 at 04:46:10PM +0200, Sven Luther wrote: On Thu, May 15, 2008 at 04:25:40PM +0200, Robert Millan wrote: Please provide a patch if you can. I already provided a patch, which is smoledring in the BTS, since months now. Thanks Sven. I just updated your patch to the latest version of the package (moving the definitions to the pre-existing PS3 section), but I cannot check if it still works. Is it safe to assume it does? In any case, would be nice if someone could test. BTW, for completeness, the following option : CONFIG_TUNE_CELL Is interesteing since the cell ppc core is not able to do opcode dynamic scheduling, or whatever it is called, and thus there is a performance hit by not enableing it. Enabling this option slows down the other powerpc64 cpus though, so it can't be enabled by default. But even without it we should have a kernel who boots on the PS3, which is more already than what we have currently. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383481: nvidiafb contains obfuscated source code, DFSG violation?
On Wed, Apr 30, 2008 at 08:09:23AM +0300, Sami Liedes wrote: Revisiting a bit old issue, as I haven't seen this specific point discussed, although related points have been: On Fri, Nov 10, 2006 at 05:03:49AM -0800, Steve Langasek wrote: severity 383481 important thanks When Kyle cloned this bug, his comment was: Wow. Looks a lot like copying register bank settings. Much like the drivers listed in Bug#383403. I don't believe there's any prevailing sentiment that the DFSG requires non-numeric source in the case of register settings being changed; indeed, various discussions on debian-vote and the like have explicitly acknowledged that in cases when we *know* we're dealing with registers rather than code compiled for an embedded processor, no source code is needed. I'm going to go out on a limb then and downgrade this bug; it is arguably still a bug since there is room for improvement to the source, but it's not an RC bug. We're talking about Linux kernel in this bug, and Linux is GPL, so for the code to be distributable, it definitely needs to be in preferred form for modification as per GPL, right (or alternatively we need permission from every GPL code contributor to the kernel)? Although I don't know if Debian makes exceptions for the kernel in this issue since upstream doesn't treat it with so much care... Notice that if the obfuscate code is just a firmware or register setting copied to an external component (the graphic core), then it is a separate work embedded in the the main linux source, and not a derivative work linked in the source code. See discussion on the topic on debian-legal a couple of years ago, but the analogy is a free zip-like tool which create executable-auto-unzip binaries containing non-free code. Remember that the obfuscated code does not run on the same CPU as the linux kernel, not even in a SMP-like way, and thus there is a clear delimitation between the two works, which confirms the above analysis. That said, this means there is no legal problem in the obfuscated code being in the linux kernel, but : 1) the obfuscated code needs to be clearly identified as such in the licensing info of the file containing it, and not placed by default under the GPL as it is often done. IF it is under the default GPL, it is indeed undistributable. 2) the fact that we can distribute it, does not mean that the we debian consider it as free, and we should remove non-free code as stated per the DFSG and the messed-up vote on the topic two years ago. Finally, one last point to clarify here. Not all code is copyrighteable, and it has to be of a size suitable for copyright. This excludes for example api header files (.h) for well defined interfaces, and containing no comment (opinion of the FSF when asked about using the amiga partition table header files when adding support for them in parted), but probably also just a bunch of register written to a chip. Please bounce this to the list, as i am being censored. Friendly, 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#392015: [Debian] Re: Bug#478208: linux-patch-openvz asks for kernel version 2.6.18 while default kernel on lenny is 2.6.24
On Tue, Apr 29, 2008 at 06:47:27PM +0400, Kir Kolyshkin wrote: As for mainstream integration, I can say OpenVZ is committed to merging containers functionality to mainstream. I have just checked the number of changesets submitted by OpenVZ and Linux-VServer guys, using up-to-date Linus' kernel git tree. For the last 365 days (i.e. a year) there were 818 changesets from OpenVZ guys and only 14 patches from VServer guys. These numbers could be wrong (maybe I'm missing someone) but not totally wrong. Also, IMHO the document http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines is not applicable to this case because it describes patches that are [not] welcome to standard Debian kernel, while OpenVZ, Linux-VServer, Xen etc. provide flavored kernels. In other words, these all are special kernels with special use cases. So, either this policy is not applicable, or linux-image-vserver and linux-image-xen are all not conforming to the policy. As for 2.6.26, OpenVZ team plans to start porting to that kernel as soon as 2.6.26-rc1 is released. http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines?action=fullsearchvalue=linkto%3A%22DebianKernelPatchAcceptanceGuidelines%22context=180 Thanks for this analysis of ports. Just to mention that i believe the current rules or at least the current position concerning patches are too restrictive and rigid. I tried to move about this concerning architecture support patches, see in : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439006 Maybe you should post something there about what you write above, and we can retitle this bug or something, but there needs to be some discussion to happen about this above policy, and the debian kernel team need to losen a bit about this. Friendly, Sven Luther -- 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#474648: seccomp is zero runtime overhead
On Thu, Apr 10, 2008 at 04:53:16AM +0200, Andrea Arcangeli wrote: Hello, The story about seccomp is that as long as there are users CPUShare will support it because it's a more efficient and more secure computing model. About the seccomp overhead, that is zero. It adds zero overhead to the fast path of the scheduler. It never added any overhead on x86-64. For x86 I added a tsc_disable feature that wasn't zero overhead initially and so that was used as argument against seccomp (despite it really had little to do with the seccomp core), it is zero overhead now that I optimized that little tsc_disable feature. So you can always enable seccomp on x86-64 without performance worries (I guess it only adds an hundred byte of .text). On x86 you can enable seccomp as safely as on x86-64 if you find a TIF_NOTSC implemented in your x86 32bit kernel. TIF_NOTSC is zerocost and so after implementing TIF_NOTSC, I changed seccomp to use it to avoid any overhead in all archs. In the latest kernels the only overhead generated by seccomp is a bit larger .text image, everything else is false or obsolete. What about non-x86 architectures, well i guess ia64 and powerpc/powerpc64 are the most interesting candidates. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474966: ACPI seems to have changed interface
On Tue, Apr 08, 2008 at 10:23:50AM +0200, Andreas Tille wrote: Package: linux-image-2.6.24-1-686 Version: 2.6.24-5 Severity: normal Hi, since I started using linux-image-2.6.24-1-686 xfce-battery-plugin just reports 0% load of my laptop battery even if fully charged. This does not happen with linux-image-2.6.22-1-686. I tried several versions of xfce-battery-plugin package that worked in the past with every other kernel. That's why I'm guessing something changed in ACPI or any other related things that report battery status. I know that this report is a little bit vague and I'd be happy to report more details if you tell me what might be helpful. Kind regards and thanks for maintaining Debian Linux kernel See also my followup to : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472800 Summarized: i have the same problem with my sony vaio, altough i think i saw it notifying me that the battery was low again yesterday. It did not hibernate the machine though, as i configured it. 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
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#469030: debian ppc64 not booting after install
On Thu, Mar 06, 2008 at 04:22:46AM +0100, Frans Pop wrote: On Sunday 02 March 2008, Ulrich Enslin wrote: I installed debian 40r3 on a IBM Power 620 (7025-f0). The install was successful, but the system did not boot from the scsi disc, with the output shown below. Hi Ulrich, ... Please forward the below to the debian-powerpc and debian-boot mailign list, since i am censored and banned from posting on those lists. Welcome to yaboot version 1.3.13 Enter help to get some basic usage information boot: Linux old boot: Linux Please wait, loading kernel... Elf32 kernel loaded... Loading ramdisk... ramdisk loaded at 0220, size: 5264 Kbytes OF stdout device is: /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] command lineo: root=/dev/sda4 ro console=ttyS0 console=ttyS0 looks wrong, you should either have /dev/hvsi0 or /dev/hvc0 (or something such), depending if you are installing in an LPAR or on the bare metal. To verify this, please check the /proc/cmdline in the d-i rescue system. memory layout at init: alloc_bottom : 02724000 alloc_top: alloc_top_hi : rmo_top : ram_top : Looking for displays alloc_down() called with mem not initialized EXIT called ok 0 So the installation went OK, but the reboot failed. This looks like a kernel issue to me, although it could also be something related to the bootloader or the initrd. Unfortunately there is very little powerpc knowledge inside the debian-installer team at the moment. Thanks very much, Frans and the rest of the d-i team, if you could be made to forget your old grudges, i am more than willing to help out with things like this, altough i have little time at this moment. I wanted to speak with you at FOSDEM, but you where not interested it seems. If the above doesn't solve it, you should check what kernel you have installed, boot into d-i rescue mode, and check in the target system /boot what kernel you have and compare it with the uname -a output. Also, please look at the lsmod output in rescue mode, and send it here. One thing you could try is to boot the installer again in rescue mode and rebuild the initrd (using update-initramfs -u) from a chroot of the installed system. You should also check that the kernel that was installed is the correct one for your system. I don't thinkg this is meaningful, since we are not yet at a point where the kernel loads the ramdisk, so my above diagnostic makes more sense. Maybe someone on the powerpc mailing list can help further. If that does not work, I'd suggest contacting the powerpc kernel developers. Please let us know if you find out anything. Alternatively, you could help lobby the d-i team and debian governane to stop their old grudges and welcome again the debian powerpc port leader. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469030: debian ppc64 not booting after install
On Thu, Mar 06, 2008 at 04:19:29PM +0200, Ulrich Enslin wrote: I installed debian 40r3 on a IBM Power 620 (7025-f0) from CD (debian-40r3-powerpc-netinst.iso). The install was successful, but the system did not boot from the scsi disc, with the output shown below. Boot messages: Welcome to yaboot version 1.3.13 Enter help to get some basic usage information boot: Linux old boot: Linux Please wait, loading kernel... Elf32 kernel loaded... Loading ramdisk... ramdisk loaded at 0220, size: 5264 Kbytes OF stdout device is: /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] command line: root=/dev/sda4 ro console=ttyS0 memory layout at init: alloc_bottom : 02724000 alloc_top: alloc_top_hi : rmo_top : ram_top : Looking for displays alloc_down() called with mem not initialized EXIT called ok 0 I booted with the rescue option 'rescue64 conlose=ttyS0), booting into a chroot of the installed environment. Frans Pop suggested rebuilding the rebuild the initrd (using update-initramfs -u), but that did not work. He also suggested looking at what kernel was installed. Here is what I see when I look in the boot directory: sh-3.1# ls -la /boot total 10550 drwxr-xr-x 3 root root1024 Mar 6 15:27 . drwxr-xr-x 22 root root4096 Mar 2 17:47 .. -rw-r--r-- 1 root root 745419 Feb 12 05:05 System.map-2.6.18-6-powerpc-smp -rw-r--r-- 1 root root 57120 Feb 11 11:14 config-2.6.18-6-powerpc-smp lrwxrwxrwx 1 root root 31 Mar 2 17:48 initrd.img - initrd.img-2.6.18-6-powerpc-smp -rw-r--r-- 1 root root 5384155 Mar 6 15:27 initrd.img-2.6.18-6-powerpc-smp drwx-- 2 root root 12288 Mar 2 17:42 lost+found lrwxrwxrwx 1 root root 28 Mar 2 17:48 vmlinux - vmlinux-2.6.18-6-powerpc-smp -rw-r--r-- 1 root root 4551303 Feb 12 05:04 vmlinux-2.6.18-6-powerpc-smp Should the kernel not have a 64 somewhere in the name. Steve Luther suggested looking at '/proc/cmdline' to see which console Its Sven, not Steve :) the system has. I was using 'conlose=ttyS0'. In the rescue system the whole /proc is empty. This seems very odd, am I doing something wrong here? You should mount -t proc proc /proc and then do it. Alternatively, the begining of the dmesg output should do it. Can you please suggest how I can get the booting to work. What I have found is that the SMS menu does not list a disk if partitioned with the normal debian install tool, even with a prep partition in the beginning. I tried openSuse, and it seems to do the petitioning correctly. Mmm, strange. Any suggestions welcome, and thanks for those who have already given me some pointers. Let's see what the above brings. Note: please forward this mail to debian-powerpc and maybe debian-boot, as i am censored and banned from posting there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468164: vmware-package: modules fail to build with 2.6.24 kernel.
On Wed, Feb 27, 2008 at 10:00:57AM -0500, Robert Edmonds wrote: forcemerge 462620 468164 thanks Sven Luther wrote: I am trying to install vmware using a lenny install with sid 2.6.24 kernels. This fails with the below log, while building modules. make-vmpkg -rsudo -b ./vmware_deb -k VMware-workstation-6.0.2-59824.i386.tar.gz hi, vmware upstream is not particularly good about keeping their kernel modules up to date with kernel upstream. people using the latest kernels generally use the vmware any-any kernel modules instead (which vmware-package will package), but in the case of 2.6.24 unfortunately the 'official' vmware any-any hasn't been kept up to date. please build vmware workstation without -k and see #462620 for the solution on building vmware modules for 2.6.24. Ok, thanks this worked, i had tried building the any-any modules, but missed the -k option to get the module package to build. BTW, would it make sense to add a notice to the effect above into the README.Debian.gz file ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468164: vmware-package: modules fail to build with 2.6.24 kernel.
Package: vmware-package
Version: 0.21
Severity: normal
I am trying to install vmware using a lenny install with sid 2.6.24 kernels.
This fails with the below log, while building modules.
Sven Luther
Installation :
==
ii vmware-package 0.21 utility
for building VMware Debian packages
ii linux-image-2.6.24-1-686 2.6.24-4 Linux
2.6.24 image on PPro/Celeron/PII/PIII/P4
ii linux-headers-2.6-6862.6.24+13 Header
files for Linux 2.6 on PPro/Celeron/PII/PIII/P4
ii linux-headers-2.6.24-1-686 2.6.24-4 Header
files for Linux 2.6.24 on PPro/Celeron/PII/PIII/P4
ii linux-headers-2.6.24-1-common2.6.24-4 Common
header files for Linux 2.6.24
ii linux-kbuild-2.6.24 2.6.24-1 Kbuild
infrastructure for Linux 2.6.24
Log:
make-vmpkg -rsudo -b ./vmware_deb -k VMware-workstation-6.0.2-59824.i386.tar.gz
=== debianizing
/home/sven/Desktop/Divers/vmware/VMware-workstation-6.0.2-59824.i386.tar.gz
=== detected product workstation
=== detected upstream version 6.0.2.59824
=== md5sum check passed
=== vmware-package 0.21 build starting in
./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0
=== creating source package from /usr/share/vmware-package/vmware
mkdir -p ./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0
cp -a /usr/share/vmware-package/vmware/*
./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0
cp /usr/share/doc/vmware-package/copyright
./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0/debian
cp /usr/share/vmware-package/changelog
./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0/debian
cp /usr/share/vmware-package/vmware.mk
./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0/debian
=== populating template values
sed -i -e [EMAIL PROTECTED]@%workstation%g -e [EMAIL
PROTECTED]@%/home/sven/Desktop/Divers/vmware/VMware-workstation-6.0.2-59824.i386.tar.gz%g
-e [EMAIL PROTECTED]@%vmware-workstation%g -e [EMAIL
PROTECTED]@%6.0.2.59824%g -e [EMAIL PROTECTED]@%6.0.2.59824.0.21.0%g
-e [EMAIL PROTECTED]@%0.21%g -e [EMAIL
PROTECTED]@%UNRELEASED%g -e [EMAIL PROTECTED]@%Sven Luther [EMAIL
PROTECTED]%g -e [EMAIL PROTECTED]@%`date -R`%g `find
./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0 -type f`
=== installing control files
cd ./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0/debian
ln -sf control.workstation control
=== symlinking distributed tarball
ln -sf
/home/sven/Desktop/Divers/vmware/VMware-workstation-6.0.2-59824.i386.tar.gz
./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0
=== starting package build
cd ./vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0
dpkg-buildpackage -B -b -uc -rsudo
dpkg-buildpackage: paquet source vmware-workstation
dpkg-buildpackage: version source 6.0.2.59824.0.21.0
dpkg-buildpackage: source changé en Sven Luther [EMAIL PROTECTED]
dpkg-buildpackage: architecture hôte i386
sudo debian/rules clean
sudo: unable to resolve host tael
dh_testdir
dh_clean
rm -rf vmware-distrib build-stamp debian/vmware-common.init
debian/vmware-server.init vix-perl vmware-vix-distrib
debian/rules build
dh_testdir
tar zxf
/home/sven/Desktop/Divers/vmware/VMware-workstation-6.0.2-59824.i386.tar.gz
--exclude=lib/modules/binary
ln -sf vmware-distrib vmware-distrib
find vmware-distrib/lib/help -type f -exec chmod 0644 '{}' \;
for file in Thumbs.db vmware-config.pl vmware-install.pl vmware-uninstall.pl
vmware-config-mui.pl vmware-uninstall-mui.pl; do \
find vmware-distrib -name $file -delete; \
done
tar -zxf vmware-distrib/vmware-vix/vmware-vix.tar.gz
tar -zxf vmware-distrib/vmware-vix/api/vix-perl.tar.gz
cd vix-perl perl Makefile.PL INSTALLDIRS=vendor \
/usr/bin/make OPTIMIZE=-O2 -g -Wall
Writing Makefile for VMware::VixBinding
make[1]: entrant dans le répertoire «
/home/sven/Desktop/Divers/vmware/vmware_deb/vmware-workstation/vmware-workstation-6.0.2.59824.0.21.0/vix-perl
»
cp lib/API/Constants.pm blib/lib/VMware/Vix/API/Constants.pm
cp lib/API/Job.pm blib/lib/VMware/Vix/API/Job.pm
cp lib/API/API.pm blib/lib/VMware/Vix/API/API.pm
cp lib/API/Host.pm blib/lib/VMware/Vix/API/Host.pm
cp VixBinding.pm blib/lib/VMware/VixBinding.pm
AutoSplitting blib/lib/VMware/VixBinding.pm (blib/lib/auto/VMware/VixBinding)
cp lib/API/VM.pm blib/lib/VMware/Vix/API/VM.pm
cp lib/Simple.pm blib/lib/VMware/Vix/Simple.pm
cp lib/API/Snapshot.pm blib/lib/VMware/Vix/API/Snapshot.pm
/usr/bin/perl /usr/share/perl/5.8/ExtUtils/xsubpp -typemap
/usr/share/perl/5.8/ExtUtils/typemap -typemap typemap VixBinding.xs
VixBinding.xsc mv VixBinding.xsc VixBinding.c
cc -c -I
Bug#467266: kvm package is missing the README file
Package: kvm Version: 61+dfsg-1 Severity: minor Hi, ... I installed kvm this morning, and was reading its documentation. I found the README.Debian, as well as the TODO.Debian, but could not find the README file mentioned in the README.Debian file, which supposedly contains the kvm documentation. 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#436937: [Debootloaders-yaboot] Bug#436937: New version needed for grub2
On Thu, Jan 31, 2008 at 04:15:33PM +0100, Jordi Mallach wrote: Package: powerpc-ibm-utils Version: 1.0.2-1 Followup-For: Bug #436937 Hi, The grub2 maintainers recently uploaded a grub2 snapshot which should finally work on much of the usual powerpc hardware, including PowerMac. However, this version relies on ppc-utils 1.0.5 or greater, as requested in this bug report. This makes grub2 for powerpc uninstallable right now, so I plan to NMU this package in the next few days unless there's some reaction from the powerpc-utils maintainers. Aurelien was this week at the Solution Linux show in Paris, please wait until he has time to come back to onliness, and make the upload. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462529: Acknowledgement (linux-2.6: Add config file support for efika and PS3 (preliminary))
I See that Bastian Blank claims to have added efika support, but these options : +CONFIG_PPC_BESTCOMM=y +CONFIG_PPC_BESTCOMM_ATA=m +CONFIG_PPC_BESTCOMM_FEC=m +CONFIG_PPC_BESTCOMM_GEN_BD=m +CONFIG_FEC_MPC52xx=m +CONFIG_FEC_MPC52xx_MDIO=m +CONFIG_SND_PPC_MPC52xx_AC97=m +CONFIG_SPI_MPC52xx_PSC=m are missing This means we will get no ethernet at least. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462529: linux-2.6: Add config file support for efika and PS3 (preliminary)
Package: linux-2.6 Version: 2.6.24-rc6 Severity: normal Tags: patch Add support for the Genesi Efika support, now that the patches are merged in 2.6.24. Also, some preliminary work for PS3 support, it didn't quite work on 2.6.24-rc6, but then it may be due to initramfs generation, or to the fact that most of the patches are still missing, but it cannot hurt to have those configuration options applied already. 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-5-vserver-powerpc64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) diff -ur linux-2.6-2.6.24~rc6/debian/changelog linux-2.6-2.6.24~rc6.2/debian/changelog --- linux-2.6-2.6.24~rc6/debian/changelog 2008-01-25 14:10:55.0 +0100 +++ linux-2.6-2.6.24~rc6.2/debian/changelog 2008-01-04 17:38:30.0 +0100 @@ -1,3 +1,15 @@ +linux-2.6 (2.6.24~rc6-1~experimental.1~powerdebian.1) powerdebian; urgency=low + + * Added Sony PS3 and Genesi Efika support. + + -- Sven Luther [EMAIL PROTECTED] Fri, 4 Jan 2008 17:37:42 +0100 + +linux-2.6 (2.6.24~rc6-1~experimental.1~snapshot.10024) kernel-dists-trunk; urgency=low + + * changelog + + -- Sven Luther [EMAIL PROTECTED] Fri, 4 Jan 2008 17:16:39 +0100 + linux-2.6 (2.6.24~rc6-1~experimental.1~snapshot.10023) kernel-dists-trunk; urgency=low * Snapshot. diff -ur linux-2.6-2.6.24~rc6/debian/config/powerpc/config.powerpc linux-2.6-2.6.24~rc6.2/debian/config/powerpc/config.powerpc --- linux-2.6-2.6.24~rc6/debian/config/powerpc/config.powerpc 2008-01-25 14:10:55.0 +0100 +++ linux-2.6-2.6.24~rc6.2/debian/config/powerpc/config.powerpc 2008-01-04 17:15:57.0 +0100 @@ -12,11 +12,22 @@ CONFIG_FB_IMSTT=y # CONFIG_PPC64 is not set CONFIG_CLASSIC32=y -CONFIG_SERIAL_MPC52xx=y -CONFIG_SERIAL_MPC52xx_CONSOLE=y -CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD=115200 CONFIG_MII=y -CONFIG_PATA_MPC52xx=m CONFIG_SENSORS_AMS=m CONFIG_SENSORS_AMS_PMU=y CONFIG_SENSORS_AMS_I2C=y + +CONFIG_PPC_EFIKA=y +CONFIG_PPC_MPC52xx=y +CONFIG_SERIAL_MPC52xx=y +CONFIG_SERIAL_MPC52xx_CONSOLE=y +CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD=115200 +CONFIG_PATA_MPC52xx=m +CONFIG_PPC_BESTCOMM=y +CONFIG_PPC_BESTCOMM_ATA=m +CONFIG_PPC_BESTCOMM_FEC=m +CONFIG_PPC_BESTCOMM_GEN_BD=m +CONFIG_FEC_MPC52xx=m +CONFIG_FEC_MPC52xx_MDIO=m +CONFIG_SND_PPC_MPC52xx_AC97=m +CONFIG_SPI_MPC52xx_PSC=m diff -ur linux-2.6-2.6.24~rc6/debian/config/powerpc/config.powerpc64 linux-2.6-2.6.24~rc6.2/debian/config/powerpc/config.powerpc64 --- linux-2.6-2.6.24~rc6/debian/config/powerpc/config.powerpc64 2008-01-25 14:10:55.0 +0100 +++ linux-2.6-2.6.24~rc6.2/debian/config/powerpc/config.powerpc64 2008-01-04 17:15:57.0 +0100 @@ -99,3 +99,29 @@ CONFIG_CMDLINE=console=hvsi0 console=hvc0 console=ttyS0,9600 console=tty0 # CONFIG_MV643XX_ETH is not set CONFIG_BLK_DEV_AMD74XX=m + +CONFIG_PPC_PS3=y +# CONFIG_PS3_ADVANCED is not set +CONFIG_PS3_HTAB_SIZE=20 +# CONFIG_PS3_DYNAMIC_DMA is not set +CONFIG_PS3_USE_LPAR_ADDR=y +CONFIG_PS3_VUART=y +CONFIG_PS3_PS3AV=y +CONFIG_PS3_SYS_MANAGER=m +CONFIG_PS3_STORAGE=y +CONFIG_PS3_DISK=y +CONFIG_PS3_ROM=y +CONFIG_PS3_FLASH=y +CONFIG_FB_PS3=y +CONFIG_FB_PS3_DEFAULT_SIZE_M=18 +CONFIG_SND_PS3=y +CONFIG_SND_PS3_DEFAULT_START_DELAY=2000 +CONFIG_GELIC_NET=m +CONFIG_GELIC_WIRELESS=y +CONFIG_PPC_CELL=y +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PPC_IBM_CELL_BLADE is not set +CONFIG_SPU_FS=y +CONFIG_SPU_BASE=y +# CONFIG_OPROFILE_CELL is not set +
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#426262: linux-2.6: mkvmlinuz support is broken.
severity 426262 critical thanks 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 2.6.22-rc3 doesn't show the problem, while it is present in 2.6.21. Where did you check the above code ? I guess it is 2.6.22-rc3, since 2.6.21 has : wrapper :=$(srctree)/$(src)/wrapper wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) But then, 2.6.21 is the sid kernel, thus making the original severity justified. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Wed, May 16, 2007 at 12:41:18PM -0500, Rolf Brudeseth wrote: I tested the script with the console attached to serial port 1 and 2 (hvsi0 and hvsi1). I had to make some minor changes to the script to get it to work. I don't know, but you may want to implement the changes differently. Regardless, before you submit the final 90console script, I assume I need to figure out how to detect whether a graphics monitor is used as the console, as well as how the ATX workstation behaves. Hi Rolf, ... I have a question here. Is this a safe way to handle this ? The options contain the variables of the OF, set by the user, but it is also possible to boot directly from the OF command line, bypassing the values found in options, or have special values passed from yaboot. On the pegasos, but i suppose the same holds true for IBM power boxes, i know it is even possible to pass these special values by the DHCP server. This would typically be done in a d-i install, where you want to over-ride the defaults, without changing the real values. I know i have done so myself. So, all in all, it is much better to do the same using the chosen properties, which is what should be used on CHRP for this kind of things, and is also said to be so in the CHRP spec. If you don't believe me, or otherwise ignore me, just ask someone with a clue on this and they will tell you so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Thu, May 17, 2007 at 10:44:41AM -0500, Rolf Brudeseth wrote: On Wed, May 16, 2007 at 12:41:18PM -0500, Rolf Brudeseth wrote: I tested the script with the console attached to serial port 1 and 2 (hvsi0 and hvsi1). I had to make some minor changes to the script to get it to work. I don't know, but you may want to implement the changes differently. Regardless, before you submit the final 90console script, I assume I need to figure out how to detect whether a graphics monitor is used as the console, as well as how the ATX workstation behaves. Hi Rolf, ... I have a question here. Is this a safe way to handle this ? The options contain the variables of the OF, set by the user, but it is also possible to boot directly from the OF command line, bypassing the values found in options, or have special values passed from yaboot. On the pegasos, but i suppose the same holds true for IBM power boxes, i know it is even possible to pass these special values by the DHCP server. This would typically be done in a d-i install, where you want to over-ride the defaults, without changing the real values. I know i have done so myself. So, all in all, it is much better to do the same using the chosen properties, which is what should be used on CHRP for this kind of things, and is also said to be so in the CHRP spec. If you don't believe me, or otherwise ignore me, just ask someone with a clue on this and they will tell you so. I am not ignoring you, just slow at responding. I am getting input from folks that are not adding their comments to this bug, and I am no Open Firmware expert so it is taking me some time to wrap my head around this. But I am happy to change the script if you think I am not implenting the changes in the optimum way. $ ls -l /proc/device-tree/chosen/ total 16 -r--r--r-- 1 root root 19 2007-05-17 10:23 bootargs -r--r--r-- 1 root root 58 2007-05-17 10:23 bootpath -r--r--r-- 1 root root 4 2007-05-17 10:23 cpu -r--r--r-- 1 root root 40 2007-05-17 10:23 ibm,rpa-client-config -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,initrd-end -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,initrd-start -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,kernel-end -r--r--r-- 1 root root 4 2007-05-17 10:23 linux,phandle -r--r--r-- 1 root root 4 2007-05-17 10:23 linux,stdout-package -r--r--r-- 1 root root 22 2007-05-17 10:23 linux,stdout-path -r--r--r-- 1 root root 4 2007-05-17 10:23 memory -r--r--r-- 1 root root 4 2007-05-17 10:23 mmu -r--r--r-- 1 root root 7 2007-05-17 10:23 name -r--r--r-- 1 root root 4 2007-05-17 10:23 nvram -r--r--r-- 1 root root 4 2007-05-17 10:23 stdin -r--r--r-- 1 root root 4 2007-05-17 10:23 stdout I see that the following two files report the node, so changing the script to use 'chosen' instead, and testing it on my hardware is no problem. $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] $ cat /proc/device-tree/chosen/linux,stdout-path /vdevice/[EMAIL PROTECTED] But I can not find an equivalent method in 'chosen' to determine whether the console is mapped to hvsi0 or hvc0. $ cat /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible hvterm-protocol Well once you have seen that chosen/linux,stdout-path points to [EMAIL PROTECTED], then you can revert to using the normal device tree for the compatible function. The main point is to use chosen to know what was done at boot time, since chosen is set either by the OF or thebootloader to inform the client program (in this case linux) about the different choices which where made at boot time. The options entry is no guarantee whatsoeve, just information about what the default option can be, but it can be overriden. Notice also, that stdin and stdout, should be two devices wxhich can be used to actually output and input information, altough i am not sure how this is supposed to work. Normally you could just ignore any of these choices, and simply have the chosen/stdin and cvhosen stdout used. Friendly, Sven Luther Let me know what I should use. I can either modify the script myself or if you prefer you can send me a new one. Either way I can test it. Friendly, Sven Luther --- 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]
Bug#420820: no console set IBM p5 server
On Mon, May 14, 2007 at 09:38:25PM +0200, Frans Pop wrote: (No need to CC me. I see your replies on the debian-boot mailing list.) On Monday 14 May 2007 21:09, Rolf Brudeseth wrote: ~ # /usr/lib/finish-install.d/90console [...] + readlink /proc/1560/fd/0 + rawconsole=/dev/console Thanks. So the debian-installer process thinks a regular console is being used. That means that we do indeed need that redirection information you referred to. So, how do we determine which device is actually being used as console? The information of which console is used is available from the CHRP device tree. Probably something like : /proc/device-tree/chosen/stdout or /proc/device-tree/chosen/linux,stdout-path (This is from my Apple XServe G5, i don't have the p505 online right now, and cannot access it until next week), so Rolf, if you could share the content of your /proc/device-tree/chosen directory, and the content of those nodes actually of interest ? The stdout seems to be a pointer to a node of some kind, while the linux,stdout-path actually contains the path of the OF device used as stdout. This means that you would need something like ofpath or ofpathname to map it back to the actual /dev/hvc*|hvsi*. Notice also, that later linuces are able to auto-discover the actual output device used, and keep it as console, without the need of specifying console=/dev/*, altough i am not fully sure how this works. This is rather nice, especially as the actual name of the serial devices changes for the same hardware depending on how you use it, and the virtualized ones may even have a phantom /dev/ttyS or /dev/tty somewhere, since adding /dev/hvc0 in addition to both /dev/ttyS and /dev/tty on the kernel command line does desactivate the hvc output. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Tue, May 15, 2007 at 08:03:13AM +0200, Frans Pop wrote: On Monday 14 May 2007 23:55, Rolf Brudeseth wrote: On Monday 14 May 2007 22:29, Rolf Brudeseth wrote: - Step 1: $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi0 or hvc0 $ cat /proc/device-tree/options/output-device /vdevice/[EMAIL PROTECTED] == hvsi1 Do these pseudo files always exist, or just if a serial console is used? These three device files should always be present in /dev. It is just a matter of specifying the correct one in /etc/inittab, regardless of how the console is accessed. If they do always exist, what is their value if the other device is used, or if a regular console is used? I am not sure I understand the question so let me try to explain it as follows. IBM System p5 servers can be configured in two mutually exclusive ways as far as consoles are concerned. You misunderstand me. I'm not concerned about the device files in /dev, but about the files in /proc. We are going to be using the presence/content of the files /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED], /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] and /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible to determine which type of console is being actually used, right? My question is: if hvsi1 is being used, what is the output of cat /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] or does that file just not exist in that case? Frans, forget about those existential questions. /proc/device-tree/chosen is what you want. It will contain a copy of all the relevant information used during booting, provided to you by the underlying firmware. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394970: /420820: no console set IBM p5 server
On Mon, May 14, 2007 at 12:28:20PM -0500, Rolf Brudeseth wrote: Is it understood how one determines which device file (hvsi0, hvsi1 or hvc0) Open Firmware associates with the console as it pertains to IBM System p servers? This can be determined by looking at properties under /proc/device-tree. Please let me know if this is needed and I will find the documentation. I know how it is accomplished, I just need to make sure that I point to documentation already released by IBM. ofpath or ofpathname (from yaboot or the ibm-power-utils or whatever that package is named) are the one doing the OF path from linux path mapping. Not sure it supports the other way around, but that would be the right way to handle this. 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#419177: www.debian.org: network installation does not show netboot etch images.
Package: www.debian.org Severity: important There is no evident way to do a netboot (PXE on x86) installation listed on : http://www.debian.org/distrib/netinst IT only list the floppies, and the netinst isos, but not the netboot (PXE on x86) images, while this would be the obvious location for them. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-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#418339: initramfs-tools: dist-upgrade runs update-initramfs twice, once for udev, and once for initramfs-tools
Package: initramfs-tools Severity: normal I did an dist-upgrade to etch, now that etch is released, and noticed that the ramdisk is updated twice for the udev and the initramfs-tools upgrade. possibly three times, when the kernel is upgraded as well. This is a less than ideal situation, especially given how long the initramfs-tools ramdisk generation takes, and it would be better if in some way there could be a detection that it will have to run multiple times, and the upgrade be queued for running once only at the end of install. I don' t know how this is possible, though. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-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#415194: libextlib-ocaml-dev: No debugging information
On Mon, Apr 09, 2007 at 11:58:03AM +0200, Stefano Zacchiroli wrote: [ Ob: debian-ocaml-maint, look at the end of this mail ] tags 415194 + wontfix thanks On Fri, Mar 16, 2007 at 06:55:27PM -0400, Ivan Jager wrote: The bytecode files are currently compiled without debugging support. This makes it hard to debug other code that might be called by it. Eg, a function passed to List.iter. In the Debian folklore of libraries (at large, not OCaml-specific) that's a feature, not a bug. Indeed usually libraries do not contain debugging symbols and where is deemed appropriate an extra -dbg library package is built containing debugging information. Since the standard libraries are compiled with debugging support it seems like it would make sense to do the same for others. Yes, it might be slightly slower, but anyone who cares about speed will probably be compiling native code anyways. In the specific case of OCaml libraries I think we never discussed the issue and therefore I think the standard libraries just happen to be compiled that way (probably because they are compiled that way upstream) without any particular reason. So, at the moment I'm tagging this bug report as wontfix, but diverting the more general question of should we mandate inclusion of debugging symbols in OCaml bytecode libraries? to the debian-ocaml-maint mailing list. On one hand we should be consistent with the general library philosophy of not including debugging symbols in packages other than -dbg. On the other it is true that a user willing to have performances will use native code libraries, but is still true that native code libraries are not available everywhere ... One interesting question here, is what is the cost of adding those debugging symbols ? Is this cost a performance hit, or only a size increase ? Is anyone familiar with how debugging is implemented in ocaml ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417871: debian-installer: On a system without ide disks and floppy, d-i takes forever in disk discovery.
Package: debian-installer Severity: normal On an x86 system (actually two different boards, and older athlon 1.2Ghz based via board, and a newer tyan nforce based opteron board, when there are no ide disks (except the cdrom drive), nor floppy driver connected, but only scsi or sata disks, the disk discovery phase takes forever (like a couple of minutes in the worst case). -- 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-4-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#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
On Thu, Apr 05, 2007 at 08:46:08AM +0200, Florian Weimer wrote: * Sven Luther: As said, i see this on both an x86 box and my powerbook, but the complete code is more involved, having a pselect, as well as a SIGALRM handler, which both trigger the localtime_r, as well as a postgresql access and files access. localtime_r is not async-signal-safe, so this could be a bug in your program. Ok, i will give a try of using just localtime. I thought it may be something such, but maybe the error message could be made something more explicit ? I guess the assertion is to check if more than one version of localtime_r is working then ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
On Thu, Apr 05, 2007 at 01:35:22PM +0200, Florian Weimer wrote: * Sven Luther: On Thu, Apr 05, 2007 at 08:46:08AM +0200, Florian Weimer wrote: * Sven Luther: As said, i see this on both an x86 box and my powerbook, but the complete code is more involved, having a pselect, as well as a SIGALRM handler, which both trigger the localtime_r, as well as a postgresql access and files access. localtime_r is not async-signal-safe, so this could be a bug in your program. Ok, i will give a try of using just localtime. localtime is not async-signal-safe, either. A full list of such functions is contained in the POSIX standard and probably the GNU libc documentation as well. The documentation which was stripped from debian because of GFDL issues, right ? I thought it may be something such, but maybe the error message could be made something more explicit ? You are asking for a general detection mechanism for race conditions, which is not really feasible for production code. I guess the assertion is to check if more than one version of localtime_r is working then ? If you invoke a function which is not async-signal-safe from a signal handler, all bets are off. That sanity check doesn't check for the race condition, it merely catches the inconsistency caused by it (from time to time). (All this assumes that your bug is caused by improper use of a signal handler. Keep in mind that this is not necessarily the case. But you should fix that aspect of your code nevertheless.) Yes, i use localtime / getoftime / time from the signal handler, yes, i guess that is causing the problem i m seeing. Need to find another way to find the time from a handler. maybe using the timer_create thingy, but it is also undocumented. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
Package: libc6 Version: 2.3.6.ds1-13 Severity: important I was writing a program using localtime, and i noticed some crashes every so often (a call every 50ms or so, a crash every 1-2 minutes), which yielded the following message : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed which brings us to the code : /* This should only happen if there are no transition rules. In this case there should be only one single type. */ assert (num_types == 1); __tzname[0] = __tzstring (zone_names); The code yielding to this was of the kind of : struct tm tm; time_t t; t = time(NULL); localtime (t, tm); This is in a fr_FR.utf8 locale, on a powerpc box. The same code on an x86 box just segfaults without error message. 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-4-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages libc6 depends on: ii tzdata2007b-1Time Zone and Daylight Saving Time libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
On Wed, Apr 04, 2007 at 07:50:02PM +0100, Stephen Gran wrote:
This one time, at band camp, Sven Luther said:
The code yielding to this was of the kind of :
struct tm tm;
time_t t;
t = time(NULL);
localtime (t, tm);
This is in a fr_FR.utf8 locale, on a powerpc box. The same code on an x86
box
just segfaults without error message.
That doesn't even compile here:
yeah, it's localtime_r i used.
#include time.h
#include stdlib.h
int main (void) {
struct tm tm;
time_t t;
t = time(NULL);
localtime (t, tm);
exit(0);
}
[EMAIL PROTECTED]:~$ gcc -Wall t.c
t.c: In function ‘main’:
t.c:8: error: too many arguments to function ‘localtime’
[EMAIL PROTECTED]:~$
This code works fine, though:
#include time.h
#include stdlib.h
int main (void) {
struct tm *tm;
time_t t;
t = time(NULL);
tm = localtime (t);
exit(0);
}
[EMAIL PROTECTED]:~$ gcc -Wall t.c
[EMAIL PROTECTED]:~$ LC_ALL=fr_FR.utf8 ./a.out
[EMAIL PROTECTED]:~$
And indeed, like i said, it worked fine 100s of times, and then died. Try :
int main (void) {
struct tm tm;
time_t t;
while (1) {
t = time(NULL);
localtime_r (t, tm);
}
exit(0);
}
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
On Thu, Apr 05, 2007 at 12:00:01AM +0100, Stephen Gran wrote:
This one time, at band camp, Sven Luther said:
And indeed, like i said, it worked fine 100s of times, and then died. Try :
int main (void) {
struct tm tm;
time_t t;
while (1) {
t = time(NULL);
localtime_r (t, tm);
}
exit(0);
}
[EMAIL PROTECTED]:~$ cat t.c
#include time.h
#include stdlib.h
int main (void) {
struct tm tm;
time_t t;
while (1) {
t = time(NULL);
localtime_r (t, tm);
}
exit(0);
}
[EMAIL PROTECTED]:~$ gcc -Wall t.c
[EMAIL PROTECTED]:~$ time LC_ALL=fr_FR.utf8 ./a.out
real1m21.381s
user1m1.716s
sys 0m18.985s
No crash. This is x86, but ppc is the same.
As said, i see this on both an x86 box and my powerbook, but the complete code
is more involved, having a pselect, as well as a SIGALRM handler, which both
trigger the localtime_r, as well as a postgresql access and files access.
I will try to provide a minimal program which exhibits the problem, but i
needed a quick solution today, since the work goes into pre-production testing
today.
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#396193: [Yaird-devel] Bug#396193: Patch to recognize openfirmware drivers
On Fri, Mar 30, 2007 at 09:24:25PM +0200, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernhard R. Link wrote: Attached patch teaches yaird to recognize openfirmware devices, as they appear in linux 2.6.18. This makes my sparc with sbus devices work again with yaird and in theory it should also make it not choke on ebus devices the bugreport I'm sending this to is about. Thanks alot for your work - and sorry for my late response. Unfortunately, it seems to me that your patch will interfere with PowerPC machines, that also use OpenFirmware. Looking briefly on a Macintosh at hand, it contains devspec files in sysfs too, but not the modules.ofmap that your patch seems to rely on. Could anyone check if I am right - and perhaps figure out a sane way to deal with the different openfirmware implementations? The future of powerpc plateform drivers, with the move to arch=powerpc, and everything relying on an openfirmware-like device tree, is to go the plateform_of way. This does include the powermacs, which is the primary development plateform of benjamin herrenschmidt, among others, who was involved in the openfirmware driver move. As thus, adding support for the openfirmware plateform devices is needed to continue to have hotplug support for those devices, and vital for yaird. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396193: [Yaird-devel] Bug#396193: Patch to recognize openfirmware drivers
On Fri, Mar 30, 2007 at 10:53:37PM +0200, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Fri, Mar 30, 2007 at 09:24:25PM +0200, Jonas Smedegaard wrote: Bernhard R. Link wrote: Attached patch teaches yaird to recognize openfirmware devices, as they appear in linux 2.6.18. This makes my sparc with sbus devices work again with yaird and in theory it should also make it not choke on ebus devices the bugreport I'm sending this to is about. Thanks alot for your work - and sorry for my late response. Unfortunately, it seems to me that your patch will interfere with PowerPC machines, that also use OpenFirmware. Looking briefly on a Macintosh at hand, it contains devspec files in sysfs too, but not the modules.ofmap that your patch seems to rely on. Could anyone check if I am right - and perhaps figure out a sane way to deal with the different openfirmware implementations? The future of powerpc plateform drivers, with the move to arch=powerpc, and everything relying on an openfirmware-like device tree, is to go the plateform_of way. This does include the powermacs, which is the primary development plateform of benjamin herrenschmidt, among others, who was involved in the openfirmware driver move. As thus, adding support for the openfirmware plateform devices is needed to continue to have hotplug support for those devices, and vital for yaird. Thanks for the detailed info, Sven. I did notice shortly after firing off that email that indeed the ofmap file is present for a 2.6.18 kernel, only not for that ancient 2.6.8 kernel I was looking at at first. This raises another question: It seems to me that this patch will fail for kernels that offers devspec in sysfs but does not ship with a modules.ofmap file. If so, applying this patch will cause yaird to stop working on older kernels that worked before. Well, you may disagree, and we almosted fighted in erkelenz over this, but if someone is using an ancient kernel not in current etch or lenny, then he should use the version of yaird which goes with it, namely the sarge version. It is very probably that the absence of this patch will break yaird in lenny even, or also the etch upgrade kernel at mid-live we have planned. Furthermore, ancient kernels are no more supported in debian/etch anyway, due to udev if nothing else, and the upgrade path does recomend upgrading the kernel early on. So, if you want to use a pre-etch kernel, then you should use the accompanying pre-etch yaird. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396193: [Yaird-devel] Bug#396193: Patch to recognize openfirmware drivers
On Sat, Mar 31, 2007 at 12:35:36AM +0200, Jonas Smedegaard wrote: Well, you may disagree, and we almosted fighted in erkelenz over this, but if someone is using an ancient kernel not in current etch or lenny, then he should use the version of yaird which goes with it, namely the sarge version. It is very probably that the absence of this patch will break yaird in lenny even, or also the etch upgrade kernel at mid-live we have planned. Furthermore, ancient kernels are no more supported in debian/etch anyway, due to udev if nothing else, and the upgrade path does recomend upgrading the kernel early on. So, if you want to use a pre-etch kernel, then you should use the accompanying pre-etch yaird. I do not want to argue with you the relevancy of non-distributor-provided kernels. As said, this is already the discourse which got us in trouble in erkelenz, and caused debian a year long of strife and hate, please reconsider your stubborn stance on this. I do want to understand if in fact applying this patch causes problems for any kernels that works without this patch. Well, also consider that upstream linux/powerpc developpers are unlikely to be willing to support in anyway a kernel as old as 2.6.8 is, please ask for their advice if you cannot believe the information i give you gathered from my active involvement with that community. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414248: evince should have an option for double-page view starting with a single page
On Sun, Mar 25, 2007 at 03:23:08PM +0200, Sven Arvidsson wrote: On Sat, 2007-03-10 at 11:25 +0100, Sven Luther wrote: As discussed on irc, evince 0.6.0, which is part of gnome 2.18, and currently in experimental, could fix this. It is currently not easily possible to test it without bringing in the whole experimental gnome 2.18 suite though. Hi, Can you check the attached screenshot of evince 0.8 in dual view and see if this is the behaviour you want? Yep, this is it exactly, you have the odd pages on the right, and the even page on the left, and the first page being odd (1) is on the right, with no facing page. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414839: mkvmlinuz fails with undefined reference to zlib_inflate_blocks* against 2.6.18-4-powerpc
On Tue, Mar 13, 2007 at 08:25:29PM -0400, Daniel Kahn Gillmor wrote: Subject: mkvmlinuz fails with undefined reference to zlib_inflate_blocks* against 2.6.18-4-powerpc Package: mkvmlinuz Version: 32 Severity: normal i'm not using mkvmlinuz as my sole bootloader: i am considering it as an alternate. However, running it by hand with a stock kernel and an initrd fails with linker errors: This is due to building on a powermac, which usually uses yaboot for booting, i believe. This seems a strange error, because the same kernel is building nicely in the daily builds of d-i (but for chrp) : === Building for sub-architecture chrp. === Using kernel image file ./tmp/powerpc_netboot/vmlinux. === Using initrd image file ./tmp/powerpc_netboot/initrd.gz. === Release version seems to be 2.6.18-4-powerpc. === Using object files from ./tmp/powerpc_netboot/lib. === Building a bootable compressed kernel image in ./dest/powerpc/netboot/vmlinuz-chrp.initrd. === Doing build in /tmp/tmp.HCLCw14930. === Creating compressed initrd image initrd.gz... cp -p ./tmp/powerpc_netboot/initrd.gz /tmp/tmp.HCLCw14930/initrd.gz === Creating compressed kernel image vmlinux.gz... strip -s -R .comment ./tmp/powerpc_netboot/vmlinux -o /tmp/tmp.HCLCw14930/vmlinux gzip --force --best /tmp/tmp.HCLCw14930/vmlinux === Putting everything into ELF image file image.o... objcopy ./tmp/powerpc_netboot/lib/mkvmlinuz-kernel-vmlinux.strip.o /tmp/tmp.HCLCw14930/dummy_kernel.o --add-section=.kernel:vmlinux.strip=/tmp/tmp.HCLCw14930/vmlinux.gz --set-section-flags=.kernel:vmlinux.strip=contents,alloc,load,readonly,data objcopy ./tmp/powerpc_netboot/lib/mkvmlinuz-kernel-initrd.o /tmp/tmp.HCLCw14930/dummy_initrd.o --add-section=.kernel:initrd=/tmp/tmp.HCLCw14930/initrd.gz --set-section-flags=.kernel:initrd=contents,alloc,load,readonly,data === Creating bootable kernel image file vmlinuz.chrp... ld -m elf32ppc -T ./tmp/powerpc_netboot/lib/zImage.lds -o /tmp/tmp.HCLCw14930/vmlinuz.chrp ./tmp/powerpc_netboot/lib/crt0.o ./tmp/powerpc_netboot/lib/string.o ./tmp/powerpc_netboot/lib/prom.o ./tmp/powerpc_netboot/lib/stdio.o ./tmp/powerpc_netboot/lib/main.o ./tmp/powerpc_netboot/lib/div64.o ./tmp/powerpc_netboot/lib/inffast.o ./tmp/powerpc_netboot/lib/inflate.o ./tmp/powerpc_netboot/lib/inftrees.o /tmp/tmp.HCLCw14930/dummy_kernel.o /tmp/tmp.HCLCw14930/dummy_initrd.o ./tmp/powerpc_netboot/lib/addnote /tmp/tmp.HCLCw14930/vmlinuz.chrp === Moving bootable kernel image file to ./dest/powerpc/netboot/vmlinuz-chrp.initrd... === Cleaning up... I guess the pmac way of building is somehow broken for whatever reason, or there is another problem. I am afraid builds on pmac where rarely tested, and not since the big ARCH=powerpc changes. That said, it is true that the do_cmd needs a bit better error checking, the whole stuff needs a full reimplementation post-etch anyway, since it can now mostly just call the ARCH=powerpc new wrapper which does much of what mkvmlinuz does. Friendly, Sven Luther 0 clam:/home/debirf# mkvmlinuz -o /foo.mkvmlinuz -k /boot/vmlinux-2.6.18-4-powerpc -i /boot/initrd.img-2.6.18-4-powerpc -v -d /usr/lib/mkvmlinuz 21 === Building for sub-architecture pmac. === Using kernel image file /boot/vmlinux-2.6.18-4-powerpc. === Using initrd image file /boot/initrd.img-2.6.18-4-powerpc. === Release version seems to be 2.6.18-4-powerpc. === Using object files from /usr/lib/mkvmlinuz. === Building a bootable compressed kernel image in /foo.mkvmlinuz. === Doing build in /tmp/tmp.AJsdy17607. === Creating compressed initrd image initrd.gz... cp -p /boot/initrd.img-2.6.18-4-powerpc /tmp/tmp.AJsdy17607/initrd.gz === Creating compressed kernel image vmlinux.gz... strip -s -R .comment /boot/vmlinux-2.6.18-4-powerpc -o /tmp/tmp.AJsdy17607/vmlinux gzip --force --best /tmp/tmp.AJsdy17607/vmlinux === Putting everything into ELF image file image.o... objcopy /usr/lib/mkvmlinuz/mkvmlinuz-kernel-vmlinux.strip.o /tmp/tmp.AJsdy17607/dummy_kernel.o --add-section=.kernel:vmlinux.strip=/tmp/tmp.AJsdy17607/vmlinux.gz --set-section-flags=.kernel:vmlinux.strip=contents,alloc,load,readonly,data objcopy /usr/lib/mkvmlinuz/mkvmlinuz-kernel-initrd.o /tmp/tmp.AJsdy17607/dummy_initrd.o --add-section=.kernel:initrd=/tmp/tmp.AJsdy17607/initrd.gz --set-section-flags=.kernel:initrd=contents,alloc,load,readonly,data === Creating bootable kernel image file vmlinuz.pmac... ld -m elf32ppc -T /usr/lib/mkvmlinuz/zImage.lds -o /tmp/tmp.AJsdy17607/vmlinuz.pmac /usr/lib/mkvmlinuz/crt0.o /usr/lib/mkvmlinuz/string.o /usr/lib/mkvmlinuz/prom.o /usr/lib/mkvmlinuz/stdio.o /usr/lib/mkvmlinuz/main.o /usr/lib/mkvmlinuz/div64.o /usr/lib/mkvmlinuz/inffast.o /usr/lib/mkvmlinuz/inflate.o /usr/lib/mkvmlinuz/inftrees.o /tmp/tmp.AJsdy17607/dummy_kernel.o /tmp/tmp.AJsdy17607/dummy_initrd.o /usr/lib/mkvmlinuz/inffast.o:(.got2+0x0): undefined reference to `zlib_inflate_mask' /usr/lib/mkvmlinuz/inflate.o: In function `zlib_inflate': /home/sven/debian/kernel/trunk
Bug#414839: mkvmlinuz fails with undefined reference to zlib_inflate_blocks* against 2.6.18-4-powerpc
On Wed, Mar 14, 2007 at 10:38:57AM -0400, Daniel Kahn Gillmor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the quick response, Sven. On Wed 2007-03-14 08:28:38 -0400, Sven Luther wrote: This is due to building on a powermac, which usually uses yaboot for booting, i believe. This seems a strange error, because the same kernel is building nicely in the daily builds of d-i (but for chrp) : snip So it does. odd. Yes, i usually do use yaboot on the powermac in question. But i'd like to try an alternate bootloading strategy, if possible. It would help me out on another project i'm working on. Ok. You made me curious now, but one use of the -a pmac option is to do powermac netboot images. I guess the pmac way of building is somehow broken for whatever reason, or there is another problem. I am afraid builds on pmac where rarely tested, and not since the big ARCH=powerpc changes. Anything i can do to debug this further? I'd really like to try using mkvmlinuz instead of yaboot if it's possible. It was offered as a bootloader option during a recent sarge-to-etch upgrade on this machine, so it would be nice if i could get it to work. Well, we have to understand why these symbols are missing. Can you try building with -a chrp, just to check that it works ? Then we can investigate why these symbols are missing. That said, it is true that the do_cmd needs a bit better error checking, the whole stuff needs a full reimplementation post-etch anyway, since it can now mostly just call the ARCH=powerpc new wrapper which does much of what mkvmlinuz does. Do you have an experimental branch i should try? Or even a high-level theoretical explanation of what my other options are? i'm happy to experment, debug, and report back if you'll point me in the right direction. The mkvmlinuz dev tree lives in the kernel subversion repo on alioth. There is not much more than what is uploaded right now though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414580: still present in 2.6.20 snapshots -- linux-2.6: nVidia Corporation MCP55 SATA Controller [10de:037f] broken (thyan thunder n3600b)
On Mon, Mar 12, 2007 at 06:06:13PM +0100, Sven Luther wrote: Package: linux-2.6 Version: 2.6.18.dfsg.1-11 Severity: important I build a d-i monolithic mini-iso with the current 2.6.20 snapshot, and the problem is still present there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414574: debian-installer web site is missing links to the non-iso d-i images.
Package: debian-installer Severity: normal I wanted to test a d-i daily build netboot image on this tyan motherboard, which seems to have some sata driver troubles, but was unable to find the netboot images on the web site anymore. Only iso links remain, please fix this. 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#414580: linux-2.6: nVidia Corporation MCP55 SATA Controller [10de:037f] broken (thyan thunder n3600b)
Package: linux-2.6 Version: 2.6.18.dfsg.1-11 Severity: important With todays d-i daily build, on a thyan thunder n3600b board, i get loads of sata errors. See attached d-i syslog as well as hardware-summary for details. r 13 00:36:53 kernel: NFORCE-MCP55: IDE controller at PCI slot :00:04.0 Mar 13 00:36:53 kernel: NFORCE-MCP55: chipset revision 161 Mar 13 00:36:53 kernel: NFORCE-MCP55: not 100% native mode: will probe irqs later Mar 13 00:36:53 kernel: NFORCE-MCP55: :00:04.0 (rev a1) UDMA133 controller Mar 13 00:36:53 kernel: ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio Mar 13 00:36:53 kernel: Probing IDE interface ide0... Mar 13 00:36:53 kernel: SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB) Mar 13 00:36:53 kernel: sda: Write Protect is off Mar 13 00:36:53 kernel: sda: Mode Sense: 00 3a 00 00 Mar 13 00:36:53 kernel: SCSI device sda: drive cache: write back Mar 13 00:36:53 kernel: SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB) Mar 13 00:36:53 kernel: sda: Write Protect is off Mar 13 00:36:53 kernel: sda: Mode Sense: 00 3a 00 00 Mar 13 00:36:53 kernel: SCSI device sda: drive cache: write back Mar 13 00:36:53 kernel: sda:hda: LG CD-ROM CRD-8522B, ATAPI CD/DVD-ROM drive Mar 13 00:36:53 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Mar 13 00:36:53 kernel: hda: ATAPI 52X CD-ROM drive, 128kB Cache, DMA Mar 13 00:36:53 kernel: Uniform CD-ROM driver Revision: 3.20 Mar 13 00:36:53 kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Mar 13 00:36:53 kernel: ata1.00: (BMDMA stat 0x20) Mar 13 00:36:53 kernel: ata1.00: tag 0 cmd 0xc8 Emask 0x9 stat 0x51 err 0x40 (media error) Mar 13 00:36:53 kernel: ata1: EH complete Mar 13 00:36:53 kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Mar 13 00:36:53 kernel: ata1.00: (BMDMA stat 0x20) Mar 13 00:36:53 kernel: ata1.00: tag 0 cmd 0xc8 Emask 0x9 stat 0x51 err 0x40 (media error) Mar 13 00:36:53 kernel: ata1: EH complete Mar 13 00:36:53 kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Mar 13 00:36:53 kernel: ata1.00: (BMDMA stat 0x20) Mar 13 00:36:53 kernel: ata1.00: tag 0 cmd 0xc8 Emask 0x9 stat 0x51 err 0x40 (media error) Mar 13 00:36:53 kernel: ata1: EH complete The disk is ok, it was used fine on another board before we switched 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#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#414248: evince should have an option for double-page view starting with a single page
Package: evince Version: 0.4.0-5 Severity: minor Evince should have an option for a double-page view, where the first page is in a single page, for documents like those produced by the twoside pdflatex option, and in general most two-sided documents will have a single first page, followed by a set of double pages. 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) Versions of packages evince depends on: ii gconf2 2.16.1-1GNOME configuration database syste ii gs 8.54.dfsg.1-5 Transitional package ii gs-esp [gs] 8.15.3.dfsg.1-1 The Ghostscript PostScript interpr ii gs-gpl [gs] 8.54.dfsg.1-5 The GPL Ghostscript PostScript int ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libatk1.0-0 1.12.4-2The ATK accessibility toolkit ii libaudiofile00.2.6-6 Open-source version of SGI's audio ii libavahi-client3 0.6.16-2Avahi client library ii libavahi-common3 0.6.16-2Avahi common library ii libavahi-glib1 0.6.16-2Avahi glib integration library ii libbonobo2-0 2.14.0-3Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-5The Bonobo UI library ii libc62.3.6.ds1-13GNU C Library: Shared libraries ii libcairo21.2.4-4 The Cairo 2D vector graphics libra ii libdbus-1-3 1.0.2-1 simple interprocess messaging syst ii libdjvulibre15 3.5.17-3Runtime support for the DjVu image ii libesd0 0.2.36-3Enlightened Sound Daemon - Shared ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libgconf2-4 2.16.1-1GNOME configuration database syste ii libgcrypt11 1.2.3-2 LGPL 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-2The GLib library of C routines ii libgnome-keyring00.6.0-3 GNOME keyring services library ii libgnome2-0 2.16.0-2The GNOME 2 library - runtime file ii libgnomecanvas2-02.14.0-2A powerful object-oriented display ii libgnomeprint2.2-0 2.12.1-7The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.12.1-4GNOME 2.2 print architecture User ii libgnomeui-0 2.14.1-2The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.14.2-6 GNOME virtual file-system (runtime ii libgnutls13 1.4.4-3 the GNU TLS library - runtime libr ii libgpg-error01.4-1 library for common error values an ii libgtk2.0-0 2.8.20-7The GTK+ graphical user interface ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libjpeg626b-13 The Independent JPEG Group's JPEG ii libkpathsea4 3.0-30 path search library for teTeX (run ii libnautilus-extension1 2.14.3-9libraries for nautilus components ii liborbit21:2.14.3-0.1libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.14.8-5Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-1 PNG library - runtime ii libpoppler0c20.4.5-5.1 PDF rendering library ii libpoppler0c2-glib 0.4.5-5.1 PDF rendering library (GLib-based ii libpopt0 1.10-3 lib for parsing cmdline parameters ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.1.1-21The GNU Standard C++ Library v3 ii libtasn1-3 0.3.6-2 Manage ASN.1 structures (runtime) ii libtiff4 3.8.2-7 Tag Image File Format (TIFF) libra ii libx11-6 2:1.0.3-5 X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxml2 2.6.27.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii zlib1g 1:1.2.3-13
Bug#414248: evince should have an option for double-page view starting with a single page
On Sat, Mar 10, 2007 at 10:43:27AM +0100, Marc 'HE' Brockschmidt wrote: Sven Luther [EMAIL PROTECTED] writes: Evince should have an option for a double-page view, where the first page is in a single page, for documents like those produced by the twoside pdflatex option, and in general most two-sided documents will have a single first page, followed by a set of double pages. Erm, I'm not sure what bug you are reporting. There is a Dual View in evince (in the menu, go to View, pick Dual). When it comes to Yes. displaying the first page, evince should usually just do the right thing, though there are some bugs in that area that were fixed in the No, it just does the wrong thing, which is what i filled the bug report. A typical two sided document is as follows : Cover Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 ... (Well, The Cover would be the first page of the pdf, and Page 1 would be the second, but this is a detail). The two-sided view of evince does : Cover Page 1 Page 2 Page 3 Page 4 Page 5 ... Which does the wrong thing, having the facing pages in the two-sided view, being not the facing sides of the document, but both opposite sides of a page. new version in experimental. You may want to test if it does what you expect, but please report back so that I understand what's missing from your POV. I hope this clarifies it, feel free to ping me on irc if more is needed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414248: evince should have an option for double-page view starting with a single page
On Sat, Mar 10, 2007 at 10:45:04AM +0100, Sven Luther wrote: On Sat, Mar 10, 2007 at 10:43:27AM +0100, Marc 'HE' Brockschmidt wrote: Sven Luther [EMAIL PROTECTED] writes: Evince should have an option for a double-page view, where the first page is in a single page, for documents like those produced by the twoside pdflatex option, and in general most two-sided documents will have a single first page, followed by a set of double pages. Erm, I'm not sure what bug you are reporting. There is a Dual View in evince (in the menu, go to View, pick Dual). When it comes to Yes. displaying the first page, evince should usually just do the right thing, though there are some bugs in that area that were fixed in the No, it just does the wrong thing, which is what i filled the bug report. A typical two sided document is as follows : Cover Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 ... (Well, The Cover would be the first page of the pdf, and Page 1 would be the second, but this is a detail). The two-sided view of evince does : Cover Page 1 Page 2 Page 3 Page 4 Page 5 ... Which does the wrong thing, having the facing pages in the two-sided view, being not the facing sides of the document, but both opposite sides of a page. new version in experimental. You may want to test if it does what you expect, but please report back so that I understand what's missing from your POV. I hope this clarifies it, feel free to ping me on irc if more is needed. As discussed on irc, evince 0.6.0, which is part of gnome 2.18, and currently in experimental, could fix this. It is currently not easily possible to test it without bringing in the whole experimental gnome 2.18 suite though. 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#411446: installation-reports
On Tue, Feb 20, 2007 at 03:26:33PM +0100, Frans Pop wrote: reassign 411446 clock-setup 0.13 retitle 411446 [powerpc] Should not select UTC for iBooks thanks On Monday 19 February 2007 08:12, Todd Partridge wrote: Comments/Problems: Used both the x86 and PPC Install Guide. The PPC Guide isn't entirely updated for PPC. Yes, we're aware of that. However, it is up to the Debian PowerPC community to update that and unfortunately so far nobody has stepped up to work on that. Frans, There is no wonder of that if you keep insulting the powerpc community, like you did at the start of january, while i was banned and not posting [0]. Please, let's put the past behind us, and put again the debian project as our top priorities, and all work together to make debian the best distribution out there, instead of loosing so much time with hate and in-fighting. I was sad that you chose not to meet with me at FOSDEM, and that when i greeted you in the hall outside the debian room, you chose to ignore me and pass by me looking the other was, as well as the way you chose to refuse to participate in the discussion concerning my ideas for the kernel and d-i, and the possibilities initramfs-tools offers to us. We have done ourself a lot of hurt since last year, where we were both at extremadura and at FOSDEM, and we had a good time together, let us go back to this time, and put aside the dispute which riped us in between. I am sure we will all have a hard time forgetting what happened, but it is a sign of maturity to be able to put it aside for the greater good. I still have faith in you and the others involved in this, that you will be able to grasp this, and that we can all work in harmony and go back to hacking happily ever after. [0] - http://lists.debian.org/debian-powerpc/2007/01/msg00068.html 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#412640: linux-image-2.6.18-3-prep: kernel fails to boot on IBM 7248 / Carolina
merge 412639 412640 thanks On Tue, Feb 27, 2007 at 08:15:06AM +0100, marvin wrote: Package: linux-image-2.6.18-3-prep Version: 2.6.18-3 Severity: normal this kernel stops after the uncompressing linux booting linux ... lines. Machine is IBM 7248 / Carolina. I needed to enable CONFIG_PREP_RESIDUAL in the config to make it boot. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21-rc1 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] --- 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]
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#280738: xserver-xfree86: [ati] wrapper doesn't recognize Radeon 9200 SE (1002:5964) as requiring the radeon driver
On Tue, Feb 13, 2007 at 02:20:34AM +0100, Brice Goglin wrote: Hi Sven, Did you have a chance to look at this bug as you said you would about 3 weeks ago? Nope, sorry, ... 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 :/
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#408385: linux-image-2.6.18-4-prep: installation fails with Missing utility in object directory
On Thu, Jan 25, 2007 at 04:00:29PM +0200, Meelis Roos wrote: Package: linux-image-2.6.18-4-prep Version: 2.6.18.dfsg.1-9 Severity: important Setting up linux-image-2.6.18-4-prep (2.6.18.dfsg.1-9) ... Hmm. The package shipped with a symbolic link /lib/modules/2.6.18-4-prep/source However, I can not read the target: No such file or directory Therefore, I am deleting /lib/modules/2.6.18-4-prep/source Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/mkvmlinuz Missing utility in object directory. run-parts: /etc/kernel/postinst.d/mkvmlinuz exited with return code 1 Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.18-4-prep.postinst line 1205. dpkg: error processing linux-image-2.6.18-4-prep (--configure): subprocess post-installation script returned error exit status 2 2.6.18-3-prep worked fine here, the bug is new to -4- Can you provide the output of dpkg -L linux-image-2.6.18-4-prep | grep /usr/lib/linux-image-2.6.18-4-prep ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408385: linux-image-2.6.18-4-prep: installation fails with Missing utility in object directory
On Thu, Jan 25, 2007 at 06:44:41PM +0200, Meelis Roos wrote: dpkg -L linux-image-2.6.18-4-prep | grep /usr/lib/linux-image-2.6.18-4-prep /usr/lib/linux-image-2.6.18-4-prep /usr/lib/linux-image-2.6.18-4-prep/boot /usr/lib/linux-image-2.6.18-4-prep/boot/ld.script /usr/lib/linux-image-2.6.18-4-prep/lib /usr/lib/linux-image-2.6.18-4-prep/lib/lib.a /usr/lib/linux-image-2.6.18-4-prep/lib/ppc.a /usr/lib/linux-image-2.6.18-4-prep/lib/common.a /usr/lib/linux-image-2.6.18-4-prep/lib/of.a /usr/lib/linux-image-2.6.18-4-prep/obj /usr/lib/linux-image-2.6.18-4-prep/obj/simple /usr/lib/linux-image-2.6.18-4-prep/obj/simple/dummy.o /usr/lib/linux-image-2.6.18-4-prep/obj/simple/head.o /usr/lib/linux-image-2.6.18-4-prep/obj/simple/misc.o /usr/lib/linux-image-2.6.18-4-prep/obj/simple/misc-prep.o /usr/lib/linux-image-2.6.18-4-prep/obj/simple/mpc10x_memory.o /usr/lib/linux-image-2.6.18-4-prep/obj/simple/prepmap.o /usr/lib/linux-image-2.6.18-4-prep/obj/simple/relocate.o /usr/lib/linux-image-2.6.18-4-prep/utils /usr/lib/linux-image-2.6.18-4-prep/utils/mkbugboot /usr/lib/linux-image-2.6.18-4-prep/utils/mkprep /usr/lib/linux-image-2.6.18-4-prep/utils/mktree Same list as corresponding -3- has. Strange... maybe mkzmlinuz has changed meanwhile. After some strace the culprit has surfaced: stat64(/usr/lib/linux-image-2.6.18-4-prep/utils/addnote, 0x7facd470) = -1 ENOENT (No such file or directory) This was due to a small mistake from Aurelien Gerome, who is helping with the mkvmlinuz package. The situation should be cleared in mkvmlinuz 32, which i will upload now. Going back to mkvmlinuz 29 should work around the issue. addnote is a chrp thingy, which was erroneously required for prep installations, while mkprep is enough fro you. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408385: linux-image-2.6.18-4-prep: installation fails with Missing utility in object directory
On Thu, Jan 25, 2007 at 07:40:51PM +0100, Aurélien GÉRÔME wrote: Hi Meelis, On Thu, Jan 25, 2007 at 06:44:41PM +0200, Meelis Roos wrote: Same list as corresponding -3- has. Strange... maybe mkzmlinuz has changed meanwhile. After some strace the culprit has surfaced: stat64(/usr/lib/linux-image-2.6.18-4-prep/utils/addnote, 0x7facd470) = -1 ENOENT (No such file or directory) Exactly, I did not test *exhaustively* what I have done to fix #381787. There was more than meets the eye in that matter. Anyway, I modified the fix and *this time* I ensured that this is fine. This is will be fixed in -32 as soon as Sven also double-checks it. In the mean time, you can grab and rebuild it from the kernel SVN repository located at [1]. Its already in incoming since yesterday, not sure if i missed dinstall or not but supposedly they are two dinstall runs per day now, and if not, it will be in the archive this evening. In the meantime, look at incoming for it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392764: Can't reproduce on PowerStack, MAC partition issue only?
On Sun, Jan 21, 2007 at 07:58:47PM +0100, Ulrich Teichert wrote: Hi, I tried to reproduce this bug on my Motorola PowerStack II (PPC prep), but did not succeed. I've used the d-i daily build from 2007-01-19, netinst iso and booted the netinst kernel over TFTP (yes, I know this isn't supported, but my bandwith doesn't allow a full netinstall). During manual partitioning, I created two RAID partitions: [EMAIL PROTECTED]:~$ cat /proc/partitions major minor #blocks name 8 08891556 sda 8 1 16033 sda1 8 2 489982 sda2 8 34184932 sda3 8 44192965 sda4 9 04184832 md0 Which is a brain-dead setup with only one disk and a RAID1 on two partitions: [EMAIL PROTECTED]:~$ df -h FilesystemSize Used Avail Use% Mounted on /dev/md0 4.0G 390M 3.4G 11% / tmpfs 62M 0 62M 0% /lib/init/rw udev 10M 44K 10M 1% /dev tmpfs 62M 0 62M 0% /dev/shm I haven't seen any failure, which suggests that the problem only shows up on MAC partition types (the PowerStack uses PC-style partitions). Sorry, but it looks like I don't have the hardware to track this down, yes, it is a mac partition table issue. There where actually two bugs, one which i fixed, and was long fixed in ubuntu but the fix didn't go back to debian until i investigated, and the other which is not in parted, but in partman, and is still open. It is possible to test this on any hardware, but you would need a second disk if your firmware/bios is not able to boot from mac partition tables, like i believe is the case for PReP boxes. This can also be tested on plain x86 boxes with a second disk. My believe is that since mac partitions used to not have the RAID flag, that partman somewhere has some explicit test for x86 partitions, and sets the RAID flag only in those cases, or something. I will try to reproduce his on pegasos and its amiga partition tables, which are in the same case as the mac partitions. partman actually *ERASES* the raid flag set by hand by parted, which is rather strange, and hints strongly at some problem in partman-md (but also possibly mirrored in partman-lvm, which has a similar flag setup). 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#352914: reopen, until the issues mentioned in the Fri, 8 Sep 2006 11:13:59 +0200 mail have been checked.
reopen 352914 thanks Reopening this bug report. There are a couple of issues mentioned in : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352914;msg=130 Which have not been fully confirmed to be fixed. Not sure if this is the best way, or if opening a new bug report for them would be best. I will investigate this first chance in february, and provide feedback in the bug report. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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#280738: xserver-xfree86: [ati] wrapper doesn't recognize Radeon 9200 SE (1002:5964) as requiring the radeon driver
On Fri, Jan 19, 2007 at 11:58:07PM +0100, Brice Goglin wrote: Hi Sven, About 2 years ago, you reported a bug to the Debian BTS regarding a Radeon 9200 SE not being recognized by the ATI X driver. This board should be very well supported nowadays. Somebody reported a successfully install of Sarge on this board, except a slightly too small resolution. Did you reproduce this problem recently? If not, I will close this bug in the next weeks. I will check today, but the problem was that the board second head was detected, and not the first one, and since X didn't know about the pci id of ther second head, there where problems. This may be linked to the special situation of the pegasos board, which used agp cards in pci mode only. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245541: closed by Brice Goglin [EMAIL PROTECTED] (Bug#245541: xfree86: package XFree86 DDK)
On Sat, Jan 20, 2007 at 06:48:03PM -0800, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #245541: xfree86: package XFree86 DDK, which was filed against the xfree86 package. It has been closed by Brice Goglin [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Brice Goglin [EMAIL PROTECTED] by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) --- 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. Message-ID: [EMAIL PROTECTED] Date: Sun, 21 Jan 2007 03:39:55 +0100 From: Brice Goglin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug#245541: xfree86: package XFree86 DDK Closing since Xorg is modular now, you may install only the drivers that you need. Yeah, the bug got ignored so long for it to be irrelevant, certainly this leaves me a bitter taste of working on X in debian, but i hope the new X team is now a bit more reactive than it used to be in those times. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392764: closed by Frans Pop [EMAIL PROTECTED] (#392764 partman: [powerpc] RAID support is broken on powermac hardware (64bit, XServe G5))
reopen 392764 # Clueless closing of this bug, probably due to a confusion with another, # separate, but similar bug. thanks Frans, you know that i did open two bugs, because those where two separate issues, right ? Friendly, Sven Luther On Fri, Jan 12, 2007 at 07:03:46AM -0800, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #392764: partman: [powerpc] RAID support is broken on powermac hardware (64bit, XServe G5), which was filed against the partman package. It has been closed by Frans Pop [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Frans Pop [EMAIL PROTECTED] by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) --- 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. Date: Fri, 12 Jan 2007 15:07:58 +0100 From: Frans Pop [EMAIL PROTECTED] Subject: #392764 partman: [powerpc] RAID support is broken on powermac hardware (64bit, XServe G5) To: [EMAIL PROTECTED] Message-id: [EMAIL PROTECTED] Closing this bug report as the issue was traced to a bug in parted (#392767) which has been solved in the mean time. If there is still a remaining issue with RAID flags, that is probably already covered by #397973, and so this can still be closed as it is a duplicate. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397973: Processed: upping severity, as discussed with Steve ...
severity 397973 serious # 12:18 vorlon fjp: I would think that not being able to do a RAID install # should be considered RC these days, do you disagree? thanks On Fri, Jan 12, 2007 at 03:08:21PM +0100, Frans Pop wrote: On Friday 12 January 2007 10:33, Debian Bug Tracking System wrote: Bug#397973: [powerpci/mac] partman-md appears to not write back the raid flag to partitions. Severity set to `serious' from `important' I don't agree that this issue is RC. It does not match any of the criteria. 1) This issue does not actually break anything. It just makes it impossible to make use of an optional feature (software RAID) during installation. 2) The issue affects only a limited group of users as it is architecture specific: software RAID support in partman works just fine on at least i386, amd64, sparc and hppa. I'm not sure about other architectures, but at least we have no reports of breakage there. 3) There is no regression, or at least, I do not see how there can be as software RAID support and general partman code has not been touched at that level during Etch development. This rather looks like an incomplete implementation of software RAID support for this particular architecture. As such, and since there currently (unfortunately) is no lead partman maintainer, it is primarily the responsibility of the PowerPC community to provide the missing bits and pieces needed to implement the support. So, IMO as D-I RM, this issue does not make partman-md unsuitable for release. 12:18 vorlon fjp: I would think that not being able to do a RAID install should be considered RC these days, do you disagree? What else is there to say ... Note for future reference: this BR is possibly related to: http://bugs.debian.org/392764 Unrelated, this was, to the best of my knowledge, a separate bug, which i investigated and fixed, and colin had already fixed for ubuntu and commented on it later on. It is unrelated to this bug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392764: closed by Frans Pop [EMAIL PROTECTED] (#392764 partman: [powerpc] RAID support is broken on powermac hardware (64bit, XServe G5))
On Fri, Jan 12, 2007 at 06:02:06PM +0100, Frans Pop wrote: On Friday 12 January 2007 17:10, Sven Luther wrote: reopen 392764 # Clueless closing of this bug, probably due to a confusion with another, # separate, but similar bug. thanks Frans, you know that i did open two bugs, because those where two separate issues, right ? Did you even bother to READ the main reason that I closed this BR: Closing this bug report as the issue was traced to a bug in parted (#392767) which has been solved in the mean time. I don't see _any_ evidence in the report that there is still an issue after #392767 was solved. _You_ identified #392767 as the root cause of this BR after all. I opened both bugs, didn't i ? I investigated both of them, i found a fix to the previous bug, and applied it, and provided a patch, and tested it and discussed it upstream. The second issue was still there, which is why i opened the second and separate bug report, and mentioned the issue to you and holger and others numerous times, asking for help, since despite me looking into the partman code at some length, i couldn't find any obvious source of this bug. Also, the fact that, as described in the original bug report, and the installing raid on mac thread i started on debian-boot/debian-powerpc, using the parted tool allows one to set the raid flag, which is then removed by partman-md again when first invoked. This is definitively an obscure partman bug. Please, don't let your hatred of me, or past disagrement, or whatever you want to call it cloud your judgement, and let's all honestly try together to make debian the best technical distribution out there. I have gladly accepted to stay away from debian lists if it can help this, and i hope that you and others can also learn to put arrogance and remembrance of past hurts aside and all work together. Maybe you should have taken *GOOD* resolutions for new year instead of what you have done, i know i did :) 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. 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]
