Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed
[Relayed to d-kernel by Cord Beermann [EMAIL PROTECTED]]
On Thu, Jun 14, 2007 at 08:40:46AM +0200, Raphael Hertzog wrote:
Package: linux-latest-2.6
Version: 2.6.21-4
Severity: wishlist
It would be great if we could have a mechanism to avoid installing a newer
kernel if the packaged modules that the user has installed are not yet
available. A simple example: I have 2.6.18-5 with the corresponding
kqemu-modules 2.6.18-5.
Yesterday I upgraded to sid and linux-image-2.6-686 pulled the new 2.6.21
kernel. However there's no kqemu-modules for 2.6.21 and thus I lost
support during the upgrade even though I have kqemu-modules-2.6-686
installed.
My suggestion to solve this is to use the new Breaks field as soon as
it's introduced in dpkg (it's planned in the next dpkg upload,
apt does already support it).
linux-image-2.6-686 in version 2.6.21+7 would be marked as breaking
the old versions of packages like kqemu-modules-2.6-686.
Package: linux-image-2.6-686
Breaks: kqemu-modules-2.6-686 ( 2.6.21+7), unionfs-modules-2.6-686 (
2.6.21+7), ...
That way the package manager has a clear hint on when it can safely
proceed with the upgrade.
However when you do this, you must also decide to regularly update the
linux-modules-{contrib,extra} packages. Of course, you should only list in
the Breaks field the packages that are autobuilt. Those that are only created
by the user with modules-assistant shouldn't be listed other the upgrade
will never happen (unless the user is clever enough to do it by himself).
This is why i proposed instead to handle the kernel packages otherwise,
outside the normal kernel infrastructure.
We would have a kernel part of the archive, which would be independent
from the normal stable/testing/unstable/experimental setup.
In it, we would have a per kernel-abi version sub hierarchy, which would
contain all modules and other kernel related stuff (even .udebs), so
there would *NEVER* be this kind of breakage, nor a breakage of the
netboot d-i images, since we would always have a given abi available.
Then, we could simply extract from this pools the needed packages to go
in a given distribution, either into unstable (once all dependents are
built, and we are happy with the general non-buggyness), or migrated to
testing, or stable.
This would also make building stable point-release with upgraded kernels
much easier.
If in addition, we separate the d-i image between the kernel-related
part and the non-kernel related part, we can easily, without big
recompilation, produce new images with any of these kernels.
I know that trying to push these ideas is what landed me in the current
mess, but it is what makes the most sense, it is an elegant and clean
solution to all these and related problems, so i ask you to consider it
by itself, instead of rejecting it because it comes from me.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
On Mon, May 28, 2007 at 08:31:00PM +0100, Paweł Krzywicki wrote: On Monday 28 May 2007 19:06, Sven Luther wrote: No, we are volunteers, who do this out of our free time and work. I know this ... But I am saying that you should not be concentrated on some kind of silly fights... What choice do i have ? And it is just not silly fights, the other side of it has chosen to make it serious, engaging in a FUD and caloumny campaign, and using the debian aparatus to punish me. This as a reward for over 8 years of very active participation, ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
On Mon, May 28, 2007 at 12:28:16PM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [070528 12:14]: On Mon, May 28, 2007 at 11:17:39AM +0200, Bastian Blank wrote: On Mon, May 28, 2007 at 08:38:24AM +0200, Joey Schulze wrote: I can understand the latter. However, maybe it was just a mistake and waldi didn't want to remove Sven but accidently removed one line too much or something? He'll probably speak up and explain things. I already said that I can't remember. I know there was something about dilinger and wli but not more. Fine, so can you reactivate my access ? It seems that waldi doesn't want to do it, and also not to give any statement that he wanted to kick you out. I consider this a very bad behaviour, at least. And not acceptable. We had just an IRC-discussion (in German): 12:15 Ganneff waldi: wie siehts aus mit svenl wieder zum alioth kernel zuzufügen nachdem er da wohl ungeplant flog? 12:15 waldi Ganneff: es hat eigentlich keiner lust sich mit ihm abzugeben. ein teil ignoriert ihn komplett 12:15 aba waldi: *du* hast ihn entfernt. Dann bist Du auch fürs aufräumen zuständig. 12:16 Ganneff waldi: dann schreib ihm entweder sowas als entscheidung vom kernel team wenns die gibt oder füg ihn wieder zu. aber ignorieren ist nix gut. 12:16 aba waldi: entweder sagst du offiziell, das du ihn draußen haben willst. Oder du fügst ihn wieder hinzu. 12:17 Ganneff waldi: und es heisst svn zufügen, das muss nit unbedingt wieder admin sein. solang er dran arbeiten kann - oder alternativ halt weiss dass es nix wird weil $grund. 12:21 Ganneff waldi: so? 12:27 Ganneff waldi: im moment siehts eher so aus dass du deinen access zu kernel (zumindest admin) verlieren solltest, nicht sven. (and no answer from waldi up to now) As you can see, there is no need for you to escalate it - other people will take care of that. :) Well, we would not have this kind of problems if debian was a more egalitarian place, where every DD would have a rigth to work on what pleases him, and that the most efficient infrastructure support be given him for that. The only reason for stopping a DD to work on something or giving him access would be serious technical reasons. This is the Debian i believed in, but, now as a year ago when the d-i leadership removed me from the d-i team because 'i was not respectful enough', debian doesn't seem to work this way anymore if it ever did. So, instead of trying to discuss this in the back, as you and Joerg did, with good intentions maybe, why not tackle the issue frontally, and resolve in one go all that which leds to frustration and flamewars in debian. If a few people, who used to do great work maybe, are unwilling to play fairly, and behave like little (or not so little) dictators in the area they have managed to get themselves in a power position, then maybe debian is better off without them, and they can take time off to reflect on what debian means to them. So, again, i ask that my d-i and kernel svn access be restored, and that the suspension be removed. None of those where technically justified, none of them had any impact appart from dragging debian into a year-long flamewar, and in general, none of these decisions where the result of fair or even simply acceptably decent decisions. Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
On Mon, May 28, 2007 at 12:41:59PM +0200, Andreas Barth wrote: * Andreas Barth ([EMAIL PROTECTED]) [070528 12:28]: It seems that waldi doesn't want to do it, and also not to give any statement that he wanted to kick you out. I consider this a very bad behaviour, at least. And not acceptable. After some more pressure on IRC, your commit access has been restored. It is not enough, i want the suspension revoked, since it was a stupid decision, which has achieved nothing except worsen the situation, and was taken contrary to the DAMs procedure, and in a shady and mysterious way. It is not acceptable that debian deals in mafioso politics, and the DAMs, by knowingly hiding most of the evidence, have actively participated in it. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
On Mon, May 28, 2007 at 01:03:29PM +0200, Joey Schulze wrote: Sven Luther wrote: After some more pressure on IRC, your commit access has been restored. It is not enough, i want the suspension revoked, since it was a stupid decision, which has achieved nothing except worsen the situation, and was taken contrary to the DAMs procedure, and in a shady and mysterious way. Oh come on Sven! This thread was about the accidential removal of your kernel team commit access. It has been restored since them. The problem is fixed. The wider problem has been there since marsch last year or so, and it was never fixed. Tell you what, if you continue trolling and ranting here, sooner or later your commit access will be removed *on purpose* with no way for you to get it back. This is not a threat but a warning. Yeah, right, is it so difficult to solve this as it should have been ? Do you really believe there is any valid justification to having me suspended for a year despite the 70:7 strong opposition of the DDs who where asked to express themselves ? What did it gain, and what was the reason that made the DAMs decide this way ? Appart that the expulsers provided more hatefull and agressive quotes than the those opposing the expulsion, and the DAMs chose to put them in value. Do you believe it was correct for the expulsers to ask for my expulsion on the day after i proposed my DPL candidacy, while i had not posted a single post on the debian lists for over a month ? And that the DAMs chose to hide this for whatevr obscure reason ? We know that you're not happy with the situation, but continueing to bring it up will not solve it either. Please don't reply and work on important things instead. Yeah, right, which is what i have been trying to do since over a year, first i worked, and provided over 30 or so patches to d-i despite the d-i access removal, just to get bashed in half the report by a clueless frans who jumped on every little excuse to explode, and finally made some under-hand manipulation with the ftp-masters to remove my upload right of the .udebs. This is what i did when i wrote the wiki page : http://wiki.debian.org/DebianInstaller/FransPopAndOthersVs%2eSvenLutherIssue and got FUCK YOU and the biggest load of self-satisfied and self-centered crap I've ever seen from frans, and abuse from geert and holger (which they removed in shame later on), and blackmail of joeyh in return. This is what i did in february, organizing hardware for the debian booth, passing time to prepare the ps3 debian install, on the ps3 that geert uutyeroven had arranged, and geert stappers or holger found the occasion to bash me when i once posted to the list by mistake while searching for a TV set. I did this while those hateful expulsers secretely where scheming to restart the expulsion procedure, while on saturday evening the DAMs had sent me a mail which got eaten by the debian.org mail greylisting or whatever, and while i spoke to James Troup on sunday afternoon, after having hold a discussion about the future possibilities of the kernel developments, of which nobody from the d-i team assisted except holger, who was forced to film, and frans passed by me without returning my greeting afterward. I did this while the expulsion process was underway and posted only few select mails, and even was mostly silent for the week or two that followed the end of the support mail period, waiting for the DAMs to decide in frustration and trauma, while Frans started agressing me on the lists again. I was doing this when i discovered this latest case. So, for me, now, in debian, the most important thing, is that this continuous agression are stopped, that each party in this is blamed accordying to their responsabilities, in a fair and equitable way, and that the one-sided punishment are lifted, and that we are all allowed to work on the parts of debian that we like and code all happily forever after. Can you tell me a single reason why this should not happen ? Can you tell me a single reason that justifies the DAMs decision to act as they did, and which can be named without shame (i know that one reason of the decision is the fact that the other party threatened to stop all d-i related work if they didn't get their way, just as Joey Hess has written on the wiki and that this would have caused a problem so near the etch release, i also know that Joerg Jaspert (and others) heavily disliked Anthony Towns, and thus it could justify the manipulation of the dates of the expulsers mail, to make it appear as if this was Anthony's action, but these are hardly noble reasons we can approve of, don't we) ? Joey, if you see this kind of attitude in real life, while you really stand by, and counsel the victim to support everything and be silent, especially as you being a pillar of the community, can act to change it ? This is not some unnamed oppression by a state or power we have no access too, this is unfairness
Re: Another level of agression ?
On Mon, May 28, 2007 at 01:33:28PM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [070528 13:23]: [...] Sven, this whole thread is about that your commit access to the kernel This whole thread is about me being stopped from doing meaningful debian technical contribution and punished for not being respectful enough to frans and not meekly having bowed under the repeated punishment which they have dealt to me in order to get me silenced. svn repro was revoked without anyone telling you. What then happened is that the alioth admins published that waldi revoked the access, waldi refused to comment to it, and was finally beaten by Ganneff and me to reenable your access. So, you see, two people jumped up to help you to get your access back, and were successful. Sure, but it is an exact reproduction of what happened last year, when i discovered after coming back to debian work after my mothers funeral, that frans had revoked my d-i svn access. I can understand that you are annoyed/angry at waldi now, but please No, i am not angry at Bastian. Bastian is a good guy, if a bit blunt in his communication. I am angry at Debian, who has handled me unfairly (to use a nice word for it), and have left a select few go into a calumniation and provocation campaign against looking the other way. I am angry at the DAMs for having used the expulsion request in their private warfar against Anthony Towns, i am angry at all DDs because nobody contested the DAMs decision, and thus silently accepted another level of escalation of something that if you think of it, you would never have accepted in any RL condition. consider that some people in Debian did efforts to help you to have your access restored. (And BTW, I still think that waldi needs to send a public apology for removing your access - as far as I can see it, it really seems to me waldi shouldn't have admin access because his behaviour is not how any admin should behave. But please stop muddling everything together. Debian as a project is definitly not responsible for waldis bad behaviour - and there is no correlation between waldis bad behaviour and anything else, waldi is behaving bad to almost all and not only to you.) No, Debian needs to send me a public apology for how it has handled me since over a year, i have little hope that those who where the worst agressors will ever have enough honour and dignity to recognize their part of fault, but the debian project as a whole owes me an apology of how i was handled, and Debian owes me a lifting of all the punishments it has unfairly submitted to me. You all know me, you all know what entusiast and time i devoted to debian, and what i have achieved all over the almost 9 years since i became DD. Everyone who meets me in RL will tell you that i am a nice guy, always helpful and friendly. Is there any justification of the kind of harrasment i have been under since over a year, and any excuse for Debian allowing this to happen ? Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
On Mon, May 28, 2007 at 05:40:26PM +0200, Joey Schulze wrote: Sven, stop it already! why should i ? The times i stopped, i got punished worse without provocation ? We've seen this several times already. Yes, so, what ? I have seen that if i don't make a fuss over this, everyone is pretty happy to let things slide into forgoteness. Never has me being silent helped in any way. You're not bringing up anything new. And i will repeat it as long as people try to ignore me, and until Debian stands up and act in a dign and honourable way in this. You're not helping yourself if you continue. You mean, i am not being meekly silent and accept my fate, right ? Like said, i was silent for longer periods in the past, and it earned me only repeated agression, so no, i will not be silent, and if you guys take it further, and try to censor me on the lists like it was tried, i guess there are other forums where i could export this mess. Why can't you guys understand how easy it would be to solve this ? Why do you think i proposed an in-person meeting at FOSDEM, and why do you think i spoke with Christian Perrier at solution linux in paris, asking him to help prepare such a in-person meeting at FOSDEM. Why do you think i held a technical discussion meeting at FOSDEM over the kernel, so the d-i folk could voice their critics, and we could reconcile all the difference of opinions, and chose the best technical solution for lenny, now, early in the development process ? Why do you think i wrote that positive wiki page, and called for reconciliation ? These are all things i expected from the DPL last year, when *I* went to him for a mediation. So, yes, i am angry and hurt, but i am rightfully angered, and i will not be silenced, except if someone decide to send some goons after me to empty some rounds of amunition into me. Frankly, all those years back, when i meet you in oldenburg, if i had known what a vampirizing beast debian was, and how the DDs would stand aside while a bunch of power-hungry assholes where going on a systematic campaign to hurt me, i would have gone away running, and not sacrificed so much of my time and work to debian. And you ask me to be silent ? Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
On Mon, May 28, 2007 at 06:11:29PM +0100, Paweł Krzywicki wrote: On Monday 28 May 2007 16:19, Sven Luther wrote: Hi ! I'm not involved in your job at all, but I am a member of debian-kernel list because I like to read about : What is new in this area ? What I can see here is only personal issues unfortunately. I am telling You it is not worth it... People you are professionals !!! you should work and think how I should solve this problem or how I should solve out that one... . No, we are volunteers, who do this out of our free time and work. Listen, I know something about C and C++ programming and I have to much free time but even with this nobody probably will not invite me to the team like You have created, so I feel myself very pour reading about things like that... I would have invited you, i was for an open and friendly team and an open and friendly debian, but see what it did bring me. Saddened, 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.
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]
Who removed me from the debian kernel team ?
Hello, While i was fixing a kernel bug, i noticed that i have been removed from the kernel team at alioth, which is quite surprising. I would like to know who did this, who was aware of it and participated in the decision, and why it was done, and what was expected to be achieved by it. The kernel team was supposed to be a place where we all took the decision together, i remember when in helsinki, the debian kernel team was an example of how well a team worked, a friendly place to be, where has this gone ? Should this be how it ends ? Already many of the kernel team joined the expulsion supporters (Manoj, no surprise there, but Martin too, and Frederik, who i thought a friend, and who supported the expulsion without even trying to speak to me first, which was one of the most hurtful things of it). And even if you chose to remove me from the kernel team, it is unacceptable that i was not told so, that it was openly discussed, and that you did not try to speak to me, but that i learned about it while trying to commit a bug fix, in an exact replicate of what happened a year ago, and started all this madness. So, let's all say a stop to shady dealings, and hypocricy, and speak about it honestly and in the open. Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkvmlinuz patches broken
On Fri, May 25, 2007 at 06:17:47PM +0200, Bastian Blank wrote: Hi folks Both mkvmlinuz patches are more or less broken: - ppc: Expects to be run from arch/ppc/boot. - powerpc: Make kbuild call MODPOST only with the vmlinux image and kills all informations about symbols in modules. The first is worked around, the second needs a fix ASAP. If you have some hint on where to look for the right way to do this, i may look at producing a patch. Not sure though as i am kind of busy right now. This is a problem only in your new kernel-package less build infrastructure, or something related to newer upstreams, or something which was present previously and not noted ? $ make mkvmlinuz_support_install INSTALL_MKVMLINUZ=/tmp/blah CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h MODPOST vmlinux mkdir -p /tmp/blah INSTALL mkvmlinuz support files I guess this is the modpost line which is problematic, right ? Bastian, if i understand this right, it worked previously, because the mkvmlinuz_support_install call was done *AFTER* all the installation happened, while you do it earlier ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkvmlinuz patches broken
On Fri, May 25, 2007 at 08:00:30PM +0200, Bastian Blank wrote: On Fri, May 25, 2007 at 06:32:00PM +0200, Sven Luther wrote: This is a problem only in your new kernel-package less build infrastructure, or something related to newer upstreams, or something which was present previously and not noted ? The problem is in upstream. All targets in arch/powerpc/boot depends against vmlinux which produces this modpost call. I guess this is the modpost line which is problematic, right ? Yep. Bastian, if i understand this right, it worked previously, because the mkvmlinuz_support_install call was done *AFTER* all the installation happened, while you do it earlier ? It did not show up as problem as kpkg always did make modules before make modules_install, which trashes a lot of io time. The attached patch seems to fix it by adding a new boot target class which don't depends against vmlinux. Bastian -- First study the enemy. Seek weakness. -- Romulan Commander, Balance of Terror, stardate 1709.2 diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 6238b58..26003cf 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -150,14 +150,19 @@ all: $(KBUILD_IMAGE) CPPFLAGS_vmlinux.lds := -Upowerpc BOOT_TARGETS = zImage zImage.initrd zImage.dts zImage.dts_initrd uImage +BOOT_SPECIAL_TARGETS = mkvmlinuz_support_install PHONY += $(BOOT_TARGETS) +PHONY += $(BOOT_SPECIAL_TARGETS) boot := arch/$(ARCH)/boot $(BOOT_TARGETS): vmlinux $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) +$(BOOT_SPECIAL_TARGETS): + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $@ Why this ARCH=ppc64 ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.21 branched and changes for .22
On Sat, May 19, 2007 at 02:28:29PM -0700, Steve Langasek wrote: On Sat, May 19, 2007 at 10:51:51PM +0200, Bastian Blank wrote: On Sat, May 19, 2007 at 01:31:46PM +0200, Bastian Blank wrote: Changes for .22: - move debian/arch - debian/config. it includes anything. - Replace the term subarch with something else, it is missleading. I only have one new term yes: featureset. - Make it possible to configure whole featuresets at once. (Mostly enable them with one entry, not 6.) - Drop linux-tree. - Drop the ability to get all revisions from the patch. Not an option. This is required for GPL compliance at release time. This is not required for GPL compliance at release time. In the current kernel packaging set, there is no reason to keep the older package around, and in fact, we strongly decourage to keep the older packages around, and keeping them around should be considered RC buggy. Let's finish the work started with the unification of the kernel packages after the sarge release, and drop all legacy/obsolete requirements like this one to help us move into the future. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.21-[23]
On Fri, May 18, 2007 at 04:23:00AM -0700, Steve Langasek wrote: On Fri, May 18, 2007 at 12:18:57PM +0200, Bastian Blank wrote: I'd like to schedule the linux-2.6 2.6.21-[23] upload for today. Yes, please. Fixes: - alpha isa interface - powerpc mkvmlinuz support (waiting for testbuild) - sparc32 deprecation? No fix yet for the cmpxchg problem. Has there been any input from the sparc porters on this last change? I agree with Frans that regardless of the upstream status, this isn't a change to be made without their consent. Well, we are at best a year away from the lenny release, assuredly having the sparc32 kernel dropped for a couple kernel releases now is not a decision of such tremendous impact as an official dropping of the sparc32 support for lenny would be. If later on the sparc32 kernels are fixed, it will be time enough to reactivate it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping sparc32 for Lenny (was: Scheduling linux-2.6 2.6.21-[23])
On Fri, May 18, 2007 at 02:39:41PM +0200, Frans Pop wrote: On Friday 18 May 2007 14:05, Bastian Blank wrote: I have to acknowledge the message from Dave[1]. Until there is a new kernel upstream it may be possible to compile it but it is impossible to fix real problems. Yes, I completely agree with that. However, when you casually propose to _deprecate_ (instead of temporarily disable) sparc32 as part of a kernel upload proposal, then I feel the discussion needs to be moved to a wider audience. Frans, Bastian did write : For now I only want to disable it. in the message you quote. This seems in complete opposition to what you claim he did say. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux plans for the lenny cycle
On Fri, Apr 13, 2007 at 02:20:28PM +0200, maximilian attems wrote: On Thu, 12 Apr 2007, Marc 'HE' Brockschmidt wrote: The release team is currently working on a schedule for the lenny release cycle. For that, we want to gather some data from the bigger software packaging teams in Debian first. We would like to know which major upstream versions of linux are expected to be released in the next 24 months and how much time you expect them to need to get stable enough for a Debian stable release. the current release cycle is 2 weeks for new drivers, subsys changes and then a stabilization phase from 6-12 weeks. so i takes between 2-3 month for each 2.6 release. Our current, very rough plans would mean a release in 18 months with some padding in both directions, which would lead to a lenny release around October 2008. We expect to shuffle this a bit around to fit everyone's needs, so please tell us if this date works for you. currently 2.6.21 is almost out, so that leaves a window of 2.6.26-2.6.30 2.6.28 seems like a good goal, but that is hard to tell in advance about the quality of each release. 2.6.20 seems much better than 2.6.19 and 2.6.18 had also much more testing than 2.6.17. staying in sync with fedora releases helps in that regard. the major upstream user visible lenny changes will be the switch from the ide drivers to ata. much better wireless device support can be expected and upstream integrated paravirtualized solutions (kvm, vmi, ..) dynticks will help on the power saving front. alsa added together with ALSA System on Chip layer lots of new codecs. as bonus for d-i the cmdline size is bigger and dynamic. (plus usual new drivers for new hardware). ext4 has support for fs 16TB. new av32 arch. incomplete ps3 support still. i'm still looking forward to include half way an updated kernel in etch for r1 or r2 release. Also, it would be good if for lenny we made fuller uses of the possibilities offered by initramfs, especially the way you can concatenate various cpio archives together to obtain a single ramdisk. This would be inmensely helpful both for d-i and the non-free firmware issues. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.20 broken on several arches
On Tue, Apr 10, 2007 at 01:27:45PM -0300, Otavio Salvador wrote: Kyle McMartin [EMAIL PROTECTED] writes: What should we do about this topic? As we need the version in testing and linux-libc-dev for use by glibc ASAP, I think about dropping all images for this arches for now until it is fixed (which may correlate with the availability of 2.6.21 ...). The relevant fixes for hppa have been merged into 2.6.21, but I provided a patch for 2.6.20 for Ubuntu. Either option is acceptable to me. What about pushing 2.6.21rc on sid? This may be another solution, we drop 2.6.20, and upload 2.6.21-rcX kernels to unstable until 2.6.21 is reached. Friendly, Sven Luther -- 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]
Re: [RESEND] 2.6.20/2.6.21
On Mon, Apr 09, 2007 at 04:51:59PM +0200, Bastian Blank wrote: Hi folks I think we should upload 2.6.20 to unstable ASAP. It seems to work for most of us, except that the xen patch is not of that good quality. After that we can merge 2.6.21-rc6 and upload it to experimental. Fine with me. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel configuration management tool
On Wed, Apr 04, 2007 at 12:33:07PM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: What's the planned features for it? The idea is to parse the Kconfig, and generate a graph, which represents all the Kconfig dependencies (and conditions), multiplied by each arch/subarch/flavour we have. This would lead to a representation of all the Kconfig related info we have both in the kernel and in debian/arch. Then we can do various things, like building such a graph for the old and new version, and produce a diff, like what kconfig.ml -d does for a single arch/subarch/flavour, or diff different branches of the arch/subarch/flavour tree. We can also check for consistency of the debian config tree, check if there are missed options which are auto-filled by the kernel kconfig tool, and so on. Furthermore, this would lead to the writing of an interactive (ncurse based ?) tool for setting those configuration options, or maybe a pure text oldconfig-like tool. The next step of this process would be to parse the Makefiles, in order to detect the modules which are build from the given config option, so we can detect new modules or removed modules corresponding to Kconfig options which changed. Or in general offer as information in the tool about the modules which are affected by a config option. Finally, if this idea is taken to the end, this mean we can even provide a way for at least providing hint of changed modules from one kernel version to the next, in order to make kernel-wedge / module .udebs management easier. I agree that it's difficult to change any current tool to make this. I like the proposal a lot :-D Would you care to say so on the google SoC page, and eventually become the official mentor, since i cannot be anymore ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel configuration management tool
On Wed, Apr 04, 2007 at 03:47:29PM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: On Wed, Apr 04, 2007 at 12:33:07PM -0300, Otavio Salvador wrote: I agree that it's difficult to change any current tool to make this. I like the proposal a lot :-D Would you care to say so on the google SoC page, and eventually become the official mentor, since i cannot be anymore ? There's no problem to me you just need to give the need pointers to me know where to fulfill it. Which page? How is the process to become the mentoring? http://wiki.debian.org/SummerOfCode2007 http://code.google.com/soc And i guess you need to follow the register mentor login link or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel configuration management tool
On Tue, Apr 03, 2007 at 08:58:45AM -0300, Otavio Salvador wrote: [EMAIL PROTECTED] writes: What do you think about this project ? What would be the main difference between your proposal and the current kernel configuration tool? Why not just improve the current tools? Notice that the nearest match are the kconfig.ml tool i wrote (which can do nice diffs between config files and between config files and arch/subarch/flavour config snipplet in the debian kernel infrastructure), or the older tool Andres wrote in ruby. I am not sure if the actual kernel config tool stuff, as maks suggested, can easily grow up to do what we need. My understanding is that it is written in C, and maybe less easily experimentable as the planned ocaml tool, since ocaml is a language very well adapted for parsers and graph manipulators, like what would be needed here. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel configuration management tool
On Tue, Apr 03, 2007 at 10:27:55AM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: On Tue, Apr 03, 2007 at 08:58:45AM -0300, Otavio Salvador wrote: [EMAIL PROTECTED] writes: What do you think about this project ? What would be the main difference between your proposal and the current kernel configuration tool? Why not just improve the current tools? Notice that the nearest match are the kconfig.ml tool i wrote (which can do nice diffs between config files and between config files and arch/subarch/flavour config snipplet in the debian kernel infrastructure), or the older tool Andres wrote in ruby. I am not sure if the actual kernel config tool stuff, as maks suggested, can easily grow up to do what we need. My understanding is that it is written in C, and maybe less easily experimentable as the planned ocaml tool, since ocaml is a language very well adapted for parsers and graph manipulators, like what would be needed here. So the idea is a tool to help the kernel infrastructure of Debian? I hadn't catch it from Guillaume previous description but then I like the idea. Yes, the description is not so good, also apparently, i cannot be mentor anymore, so someone else is needed, at least as frontend. What's the planned features for it? The idea is to parse the Kconfig, and generate a graph, which represents all the Kconfig dependencies (and conditions), multiplied by each arch/subarch/flavour we have. This would lead to a representation of all the Kconfig related info we have both in the kernel and in debian/arch. Then we can do various things, like building such a graph for the old and new version, and produce a diff, like what kconfig.ml -d does for a single arch/subarch/flavour, or diff different branches of the arch/subarch/flavour tree. We can also check for consistency of the debian config tree, check if there are missed options which are auto-filled by the kernel kconfig tool, and so on. Furthermore, this would lead to the writing of an interactive (ncurse based ?) tool for setting those configuration options, or maybe a pure text oldconfig-like tool. The next step of this process would be to parse the Makefiles, in order to detect the modules which are build from the given config option, so we can detect new modules or removed modules corresponding to Kconfig options which changed. Or in general offer as information in the tool about the modules which are affected by a config option. Finally, if this idea is taken to the end, this mean we can even provide a way for at least providing hint of changed modules from one kernel version to the next, in order to make kernel-wedge / module .udebs management easier. 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]
Re: 2.6.21-rc5
On Sat, Mar 31, 2007 at 07:22:38PM +0200, maximilian attems wrote: any voices against basing trunk on latest upstream? have an i386 working tree to commit. should 2.6.20 first be copied to sid? The etch kernel is frozen, right, and will never be updated, so there is nothing stopping us from uploading 2.6.20 to unstable now, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SoC kernel configuration proposal and the expulsion request ...
Hi fellow kernel team member, Well, given the DAMs judgement on the expulsion process, it is clear i won't be around during the year to come and i am unsure if i will ever wish to come back after that, only time will tell, i wish you all good luck and hope you make good work on the debian kernel in the future. Now, i had proposed a SoC project, and have had various students interested in it. The one i had more hopes with was Guillaume Lopez, which did various email exchanges with me, and has the needed background and knowledge to put the various ideas i had about this issue into practice. The project can be found here : http://code.google.com/soc/debian/app.html?csaid=PwYNHwdQRiwANBwUFhhxWy4RNRINH0VSXCxfYEABEV0BAHVfbhABQlgIAXM%3D%0A I know some of you don't like me anymore, or don't want to work with me, but do you think it is fair to the student, that for chosing unknowingly a topic i was involved with, his project gets shuned by you guys because of that ? So, i am temporarily expulsed, i wonder what this may do to the mentoring of the SoC project, and just to be on the sure side, it would be nice if someone else could actually mentor or co-mentor the project, or at least takes some interest in it, and actually ask questions to the student to help him clarify the issue. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Sat, Mar 17, 2007 at 03:23:39PM -0300, Otavio Salvador wrote: Frans Pop [EMAIL PROTECTED] writes: On Thursday 15 March 2007 21:32, dann frazier wrote: Given this, I believe anyone on the kernel team should be permitted an entry in the Uploaders field. I also do not believe that the presence of a maintainer's name in the Uploaders field grants them any additional privileges. Uploads still need to be coordinated on the mailing list, etc. In the D-I team we treat the Uploaders field differently. Uploaders are people who actually coordinate the package or do frequent uploads because of their role in the project (e.g. the release manager). I personally like the way the uploaders field has been use on d-i and think it would fulfill nicely the kernel team way of doing things. Notice that Frans decided on this way of using the uploader field, and used it as weapon against me in his war against me. I remember perfectly the older days of the d-i team, where you could add yourself as uploader, when you where actually working on a d-i package. But as d-i moved away from the do-ocracy that many believe is what debian should be, into a strong tyrany of a few, things changed, and most of those changes where in reaction to needs in their fight against me. I am not entirely sure that this is what is most wanted here, this is defitively not how the kernel team used to work, when it was most succesfull, where those actually doing the work could add themselves to the Uploader field, and actually do the upload. Sure, this worked in a coordinated way, but as we where a friendly group, and worked together, and there wass no real need of hierarchies and strong order of control, this worked out well enough. But it is sure, that in the recent days, i see mostly Bastian doing uploads, and only a few active people, so things have changed indeed, and not for the best. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Fri, Mar 16, 2007 at 09:43:03AM +0100, Marc Haber wrote: On Fri, Mar 16, 2007 at 09:09:48AM +0100, Sven Luther wrote: So, Frans has the right to speak here, while i have not ? Frans' message was on topic and useful, while you were basically telling him to shut up, which is neither on topic nor useful. Do you see the difference? Yes, i am just basically reproducing how he is behaving against me instead of letting past issues be past, and work for the greater good of debian. I mean, i have played nice and all, have made numerous reconciliation offers, all to no avail, so, if he really don't want to deal with me, and want to refuse to normalize relations, and refuse me to be work on d-i, fine, but he should then avoid showing up in areas i am interested in. madduck fucking hell, fjp. i really disagree. he's been quite alright lately and deserves another chance. madduck and he said stuff that was totally on topic fjp madduck: I don't give a shit. He's not welcome on the d-boot team. madduck that's really immature. fjp See my mail to private early Jan. Makes it perfectly clear. So, i played nice, to no avail, so i will try to be an asshole for a week or two now, and see how people like it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Fri, Mar 16, 2007 at 12:18:13PM +0200, Jurij Smakov wrote: On Fri, Mar 16, 2007 at 09:15:55AM +0100, Sven Luther wrote: I do agree with this interpretation. I also think it's really sad that we have to invoke policy to regulate the use of the Uploaders field. There is no reason whatsoever (other than Bastian's anti-social tendencies) to keep people out of Uploaders if they think/feel that they should be there. So, will you try to expulse him too, like Frederik and Andres did to me ? No, I will not try to expell him. However, if a person repeatedly fails to follow simple guidelines, to which the majority of kernel team agrees (in this case, mailing the list and waiting for replies for a reasonable amount of time before reverting svn commits made by other team members), I think some action (for example, temporary suspension of svn write access) should be taken. My point is that there is no heart to the kernel team anymore, and before we go in all against one, or whatever, it is important to reconstruct our identity again, and this includes discussing things. What i noticed, is that the kernel team today is mostly limited to a few people right now, mostly Bastian and Maximilian as far as i could see, but i didn't check in detail. The irc channel is mostly silent, and we don't have anymore the camaraderie we used to have before. I know that my behaviour of last year contributed to this, but i am not the only responsible. So, before going into he forcing-people overgear, we should have some irc meeting or something, and see how we want to work in our team, and what the future of the participation of each of us is going to be, and if i am still wanted or not, especially after Frederik's seconding of my expulsion and the extremely hurting words he had then, and his silence on this topic since then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [kernel] r8361 - in dists/trunk/linux-2.6/debian: . templates
On Thu, Mar 15, 2007 at 05:47:00PM +0100, maximilian attems wrote: On Thu, Mar 15, 2007 at 03:29:17PM +, Bastian Blank wrote: Author: waldi Date: Thu Mar 15 15:29:17 2007 New Revision: 8361 Modified: dists/trunk/linux-2.6/debian/changelog dists/trunk/linux-2.6/debian/templates/control.source.in Log: Revert r8360. i don't respect that revert given without any reason, unless some sourced objections come in i will restate previous state. Hi fellow members of the kernel team. I see with sadness these kind of disputes. I also saw Frederik seconding the expulsion process, claiming i was cause of all the troubles of the kernel team, but it seems that you don't need me at all for picking up fights. So, can't we all be civil with each others ? and try to bring the kernel team in a state like it was in fall 2005, when we reached the hights of fun, cooperation and niceness ? If it really is my fault that it all degenerated so, then i am very sorry and ask your forgiveness for it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Thu, Mar 15, 2007 at 10:43:49PM +0100, Bastian Blank wrote: On Thu, Mar 15, 2007 at 02:32:29PM -0600, dann frazier wrote: Does this match other people's interpretations? Let's please use this thread to achieve consensus on Uploaders usage. No. Hi Bastian, Would you be so kind as to give a bit more information about your interpretation and the reasons for it ? I think i can see both your point, and their point. We have a bunch of people in the kernel team who have not been active for months, and some i don't even know, so they should not be uploaders. On the other hand, there should not be any upload without a full consensus of all the team, but then with the disintegration of the kernel team which has been happening since the non-free affair, this could be more problematic than what it seems. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Fri, Mar 16, 2007 at 02:19:11AM +0100, Frans Pop wrote: On Thursday 15 March 2007 21:32, dann frazier wrote: Given this, I believe anyone on the kernel team should be permitted an entry in the Uploaders field. I also do not believe that the presence of a maintainer's name in the Uploaders field grants them any additional privileges. Uploads still need to be coordinated on the mailing list, etc. In the D-I team we treat the Uploaders field differently. Uploaders are people who actually coordinate the package or do frequent uploads because of their role in the project (e.g. the release manager). Frans, you are not of the kernel team, and as you have played dirty tricks in these areas yourself, you are absolutely not qualified to give your opinion here. Friendly, Sven Luther -- 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#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#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]
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]
Re: 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]
Re: 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]
retiring from debian for two months ...
Hi, ... well, most of you followed the disgusting events on debian-private, let me just give a little summary for those who didn't : Some months ago Fabio agreed to mediate between me and Frans. Last week he asked for my banning from the debian lists, which i found extremely surprising, since things had gone rather well. I agreed instead to a self-imposed removal from lists, so this will be my last post until end of februrary, i wish you all good luck until then. Our DPL was most insistent that i accept this ban, on the other hand, he said nothing on Frans's reply, where he mostly told he would not be hold by the mediation, and that i would never, whatever effort i would ever make, be accepted inside d-i again. Manoj too was extremely aggressive in his comments in those threads. Not all agreed to this though, and many heavily condemned the proposal by Fabio, but our DPL was not moved by this, and reiterated this morning that i stop all debian posts, putting my honour and word in question. So, given all this, and how Maximilian recently did a huge and agressive ranting against me on irc, i will not leave until end of february, and see afterward what my involvement will be. I plan to prepare a FOSDEM talk about my ideas concerning d-i, the kernel, the kernel .udebs, the oportunities the initramfs format and its cpio concatenation offers us and d-i, and probably other stuff concerning handling of the non-free firmware and so on. I invite everyone of an open mind to attend there, and discuss issues, but these are nothing but the ideas i have been proposing since years, and which gave me the enemity of the d-i leadership, so we will see, i just hope i will not be stoned at FOSDEM or so by angry DDs. Anyway, here is my post-reply to Anthony : http://lists.debian.org/debian-project/2007/01/msg1.html and since i am respecting this self-imposed ban, i will be without pity for those of the opposing party who don't do so, and to Anthony Towns if he fails to make them respect their part, not that i hope much in fairness and sense from Anthony, though. Anyway, it has been fun working with you all, i hope i see you in marsch. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [kernel] r8040 - in dists/trunk/modules/unicorn/unicorn: . adsl_status/m4 adsl_status/src adsl_status/src/.deps arch/i386 unicorn_usb
On Fri, Dec 29, 2006 at 11:21:55AM +0100, Bastian Blank wrote: On Thu, Dec 28, 2006 at 03:53:24PM +0100, Sven Luther wrote: On Thu, Dec 28, 2006 at 11:47:27AM +0100, Bastian Blank wrote: On Thu, Dec 28, 2006 at 12:34:11AM +0100, Philippe COVAL wrote: Log: forgotten missing objects (closed source) WTF? This is the non-free unicorn driver for the Bewan ADSL modem. I have hosted them in the kernel svn repo, under trunk/modules. Philippe is working on it now, and i believe did check in a new version or something. Please remove the source and only have the debian directory in the repository. Whyever that ? The files are perfectly distributable, and the licencing has been clarified early on so there is absolutely no problem in redistributing it. It is a non-free package, so maybe you would like to move it under modules/non-free or something ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [kernel] r8040 - in dists/trunk/modules/unicorn/unicorn: . adsl_status/m4 adsl_status/src adsl_status/src/.deps arch/i386 unicorn_usb
On Thu, Dec 28, 2006 at 11:47:27AM +0100, Bastian Blank wrote: On Thu, Dec 28, 2006 at 12:34:11AM +0100, Philippe COVAL wrote: Log: forgotten missing objects (closed source) WTF? This is the non-free unicorn driver for the Bewan ADSL modem. I have hosted them in the kernel svn repo, under trunk/modules. Philippe is working on it now, and i believe did check in a new version or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#404143: Fans unreliable under load, permanent memory leak
On Sun, Dec 24, 2006 at 03:07:55AM +0100, Frederik Schueler wrote: Hi *, this is indeed a severe issue which requires all our attention and care to solve or circumvent in order for nobodies boxes to get any harm, you know how expensive these laptops are. I basically see 3 solutions/workarounds: 1. the brutal one: deactivate ACPI in 2.6.18, have the bios keep control of the fans - better a noisy laptop until I upgrade the kernel than a fried box. 2. port 2.6.19 ACPI - noop because way too much work, unless someone crazy enough to accomplish this task. 3. go for 2.6.19 As said, i can imagine another solution. 4. Provide both a stable 2.6.18, and a easily usable backported 2.6.19 (or newer) kernel, which would be built for etch, but built out of our trunk/unstable/testing archive. Then we can add a bit of logic into d-i's base-installer, so that the kernel installation step detects the laptops which have this problem (do we know how to detect them ?), and inform the user and install the newer kernel. Alternatively, we can go 1, create a -noacpi flavour usable on those laptops, and install that flavour in d-i. This would probably be the easiest solution. Documenting arbitrary breakage in the release notes is not a solution, just consider how well manuals are usually read (if at all). Users will end with damaged hardware and blame us for it. /me agrees. We released woody with disabled ide dma due to somewhat similar issues (boxes hanging), so disabling ACPI in 2.6.18 and going for a 2.6.19 based 4.0r1 ASAP seems the best thing to me personally, but this is of course up for discussion. I have been thinking of another solution, but since i am kind of ignored or this is a subject a certain amount of the powers-who-be don't want me to mention, i doubt it will be gaining much momentum. I am going to propose a talk at fosdem about these ideas, where issues and everything else can be discussed. The idea goes as follows : 1) We take the kernel out of the main debian archive, into a separate kernel pool. This pool would hold the kernel and all assorted modules or abi-depending packages. This pool would hold per-abi subpools (dists/kernel/2.6.18-3, dists/kernel/2.6.19-1, etc). 2) Eventually, we have some symlink or mirroring logic which would allow the chosen kernel to be accesible from the main archives. This means we can prepare kernels in this kernel pool, test it, and once it is ready, do a one-pule moving of those packages (without rebuild) into the main pools. 3) This pool will include both kernel .debs and .udebs. A further improvement would allow to split the d-i initramfs into two, having a single copy of the non-kernel specific stuff, and a per-flavour copy of the kernel initramfs stuff. This way, we move together the kernel and the module .udebs, and can easily switch d-i to change kernel version, or even build various d-i for various kernel versions. Furthermore this would avoid d-i trying to import 2.6.18-3 modules when you build a local 2.6.19-1 kernel, and simplify the whole .udeb version checking and downloading logic. Well, there is more to it, and i will present that at fosdem, but i hope this already gave you all a taste of what could be, and that these ideas will not be rejected out of hand, just because they come from me. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Sun, Dec 24, 2006 at 02:48:27PM +0100, Frans Pop wrote: On Sunday 24 December 2006 03:07, Frederik Schueler wrote: 2. port 2.6.19 ACPI - noop because way too much work, unless someone crazy enough to accomplish this task. Did you see that Bas Zoetekouw managed [1, #400488] to solve the problem for his box by applying some selected patches from upstream? Wouldn't that be an option? I thought i saw Maximilian say that there are indeed some patches, but that the risk to destabilize the whole ACPI subsystem was too great this near to the etch release. This is exactly the same kind of argument you are using in d-i, don't you think ? I'd suggest asking other people that see the same issues to also test a kernel with these patches and decide based on the results. No, what we would need is huge testing of these patches by people *WHO DIDN'T SEE THE SAME ISSUES* to make sure there is no regression. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#404143: Fans unreliable under load, permanent memory leak
On Sun, Dec 24, 2006 at 03:42:46PM +0100, maximilian attems wrote: On Sun, Dec 24, 2006 at 03:31:15PM +0100, Frederik Schueler wrote: Hello, On Sun, Dec 24, 2006 at 02:02:58PM +0100, Moritz Muehlenhoff wrote: Do you intent to disable ACPI entirely for all systems? It appears to me that the affected HP models could be disabled on a per-case basis using drivers/acpi/blacklist.c This looks like a good idea to me, do we know which models are affected? OTOH, I doubt we have a complete list of affected models, and who knows what problems may arise for yet to be released laptops... indeed this is a good way. acpi patches have known side-effects so i would nack any hand-picking of those. do we have a report from an affected laptop that booting with noacpi solves the thermal issues? Ah, neat, there is the noacpi option. We could simply add this flag to affected laptops by d-i. No need to touch the kernel or otherwise. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Sat, Dec 23, 2006 at 11:50:40AM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [061222 05:42]: On Fri, Dec 22, 2006 at 12:53:09PM +0100, Marc 'HE' Brockschmidt wrote: maximilian attems [EMAIL PROTECTED] writes: On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: Fix it or document it, I don't care. But the current state is not releasable. we are not talking about a patch. what you need is an backport of the 2.6.19 acpi release to 2.6.18. Read again what I wrote. I will not allow Debian to release with a Kernel that may damage hardware without even a notice in the release notes. If you are not able to fix it, note that you have provided a broken kernel. Cool, let's delay etch a couple of weeks and move to a (now released) 2.6.19 kernel, to solve this issue. Sven, stop this! Why ? /me guesses that even though debian is about free software, there are many who feel that freedom of speach is to be banned. Do you also follow that line of thought ? Was it not enough that some people felt that i should be burned on the stack for having send mails while i was not at my best ? Really, this kind of behavior is disgusting. I can remember well how you promised that moving to 2.6.18 will magically solve almost all of our issues - 6 (or more) release critical bugs against 2.6.18 don't show that this has worked so well. Please try helping us on solutions rather then breaking things again. I did not promise anything such. I simply stated at that time, that there where many RC issues which where already fixed in the 2.6.18 tree, and which would be a pain to backport to the 2.6.17 tree. Quite a different thing, don't you think ? I personally will need to maintain 2.6.19+ backports to etch, because there is no sane way to get Efika support in 2.6.18 without lot of work. Please try to look at it from another perspective: Consider you have bought such a laptop, and you install Debian. You have even read the release notes first. Everything works well. Until one day you notice your laptop gets too warm, and eventually even breaks because of this. On deeper research, you notice that this issue was well-known to Debian, but they refused to deal with it at all. How would you feel as a user? I think this is an unacceptable perspective. Bah. hardware which can be broken by software is broken. That said, if in fact this is not a bug of the bios as was first mentioned here, but that the linux support is not able to cope with some not usual but legal features of acpi, then it is another matter. But you should *NEVER* try to stop discussion about the subject, or bash on someone for writing a single sentence as i did. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Fri, Dec 22, 2006 at 10:54:50AM +0100, Andreas Barth wrote: severity 404143 critical thanks * Bastian Blank ([EMAIL PROTECTED]) [061222 01:27]: On Fri, Dec 22, 2006 at 01:51:36AM +0100, [EMAIL PROTECTED] wrote: Consequence: linux-image-2.6.18-3-amd63 (=2.6.18-7) is unsuitable for release. Failing for you don't makes it unsuitable. That is a true statement by itself. This bug however has the potential to damage hardware. Which is a critical bug. Euh, it seems to me more that the hardware has a bug which causes normal operation to damage it. As thus, i think that any damage done would be under the responsability of the manufacturer to repare or fix. This seems to be both the position of Bastian and Maximilian, and it seems reasonable. So, users of such hardware, please bother your vendor to either exchange it for a not broken one, or at least provide a bios upgrade which fixes the brokeness. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Fri, Dec 22, 2006 at 12:09:45PM +0100, maximilian attems wrote: On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: Bastian Blank [EMAIL PROTECTED] writes: On Fri, Dec 22, 2006 at 10:30:57AM +0100, Marc 'HE' Brockschmidt wrote: Sorry, I don't accept this. We are talking about an *overheating* problem, which means *broken* hardware. There needs to be at least a fix documented in the release-notes. Garbage-in, garbage-out. The BIOS of that machines is broken. Do you really expect that an interpreter (in this case the ACPI interpreter) accepts any garbage? Other OSes don't destroy the hardware. There is a patch for Linux not to - I don't see why Debian should release with a kernel that destroys hardware, without even giving users a warning. Not everyone who buys a notebook is aware of ACPI problems, and we shouldn't expect all users to do so. Fix it or document it, I don't care. But the current state is not releasable. we are not talking about a patch. what you need is an backport of the 2.6.19 acpi release to 2.6.18. acpi linux releases are tested as one release and you open a can of worm once you start picking acpi patches. only mjg59 is insane enough to do that. anyway the fix for those broken aml tables has a big dependency so the backport is insane. i looked at it 2 month ago and dropped the case, we are shortly before release. i restate those broken hardware needs a newer kernel fullstop. Well, this would mean that we could provide a semi-official set of newer kernels for etch. We would, once etch is released, provide a backportet kernel of the new unstable kernel, as well as a etch-installing d-i for them. This would allow users to install a stable etch, but including a newer kernel, which is what probably most of us are doing anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
On Fri, Dec 22, 2006 at 12:53:09PM +0100, Marc 'HE' Brockschmidt wrote: severity 404143 critical thanks maximilian attems [EMAIL PROTECTED] writes: On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: Fix it or document it, I don't care. But the current state is not releasable. we are not talking about a patch. what you need is an backport of the 2.6.19 acpi release to 2.6.18. Read again what I wrote. I will not allow Debian to release with a Kernel that may damage hardware without even a notice in the release notes. If you are not able to fix it, note that you have provided a broken kernel. Cool, let's delay etch a couple of weeks and move to a (now released) 2.6.19 kernel, to solve this issue. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402762: debian-installer dosen't detect Broadcom BCM5704 Gigabit LAN
On Thu, Dec 21, 2006 at 05:46:56PM +0100, Serge Koganovitsch wrote: Hi, This seems to be solved with the latest version of the kernel (2.6.18). I installed a custom sarge iso, then upgraded to etch with the K7 version of the 2.6.18 kernel. It works ! The one shipped with Debian Installer rc1 is 2.6.17. Probably, the daily build installer already incorporates the 2.6.18 kernel. It does indeed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Wed, Dec 20, 2006 at 09:35:56AM -0600, Manoj Srivastava wrote: What architecture line are we talking about here? Is there a bug report number I can refer to to refresh my memory on this issue? ... Again, what is broken about EXTRAVERSION? Which bug reports are we talking about? ... I'd be happy to look at why bits of the build process take longer than a raw build without make-kpkg -- which bug number was this reported under? Manoj, you see, this is part of the problem. Nearer integration of the kernel-package maintainer and kernel team, or you being part of the kernel team, doesn't necessarily mean communicating via bug reports. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Wed, Dec 20, 2006 at 06:26:57PM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Wed, Dec 20, 2006 at 09:35:56AM -0600, Manoj Srivastava wrote: What architecture line are we talking about here? Is there a bug report number I can refer to to refresh my memory on this issue? ... Again, what is broken about EXTRAVERSION? Which bug reports are we talking about? ... I'd be happy to look at why bits of the build process take longer than a raw build without make-kpkg -- which bug number was this reported under? Manoj, you see, this is part of the problem. Nearer integration of the kernel-package maintainer and kernel team, or you being part of the kernel team, doesn't necessarily mean communicating via bug reports. What's wrong with filing bugreports? You seem to argue that keeping record of bugs is wrong is replaceable with coordination on a mailinglist, spiced up with IRC conversations. Nope, i am saying that if the only communication channel between such important pieces of related debian infrastructure like the linux kernel package and the kernel-package package is plain wrong. I disagree. Teaming up is great, but does not replace the core routines in Debian. It just glues them better together. IMHO. Teaming up is all about communication. If some guys want to play it solo for such inter-related packages, that is a problem. I agree that this problem exists on both side in this case, but Bastian is at least part of the team. And bug reports are only so useful as the maintainers make them, as you well know, who left a pretty damaging RC bug open for months, rejected help in investigating it, and highly contributed to the near-desintegration of the kernel team in march by such behaviour (of which i also contributed i admit). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401384: fixed in mkvmlinuz 28
On Tue, Dec 19, 2006 at 05:17:45PM +, Colin Watson wrote: found 401384 29 thanks On Fri, Dec 15, 2006 at 11:17:03PM +, Sven Luther wrote: mkvmlinuz (28) unstable; urgency=low . * Added support for 2.6.19 kernels. * Added portuguese translation. (Closes: #401384) pt.po doesn't actually appear to be in the tarball (I'm looking at mkvmlinuz_29.tar.gz); did you maybe forget to 'svn add' it? Possibly, damn, i will investigate and make a new upload. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 10:47:56AM +0100, Marc Haber wrote: On Mon, Dec 18, 2006 at 09:31:22AM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Well, the real problem is that Manoj could be part of the kernel team, and to a point even is, since he has svn access to the repo. But there is a problem, in that Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought (not mentioning memories of when he was the debian kernel maintainer all those years ago and whatnot), while Bastian handles most of the official kernel infrastructure, and obviously doesn't care much about self-built ones. And Bastian is decidetly anti make-kpkg and wants to remove all make-kpkg use from linux-2.6 as stated several times now. You can see beginings of that in the xen kernels. Further one result of this dislike of kernel-package seems to be that you can't build proper custom kernels on mips, mipsel, s390 and ppc and no xen or vserver flavours anywhere. The debian patch is not make-kpkg compatible and again Bastian spoke against fixing the patch to work with kernel-package. I consider kernel-package one of the best things in Debian and it is a real pity that it is not being used to build the Debian kernel. Not It is used by the debian kernel team. The problem is as said one of communication and pride, with Bastian seeing it as a tool which breaks often in obscure ways, and hindering his work on the infrastructure build, while Manoj is still somewhat recentful of the kernel team, even though he won't admit such publicly, i remember perfectly his i was already packaging kernels in the early 90s and other such prideful issues last year. And jonas, who used this as a reason to explain to me in RL during half an hour why he should not even look at an RC bug. BTW, jonas, i notice also : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403203 And how you have been rather inactive on yaird over this past year. being able to use Debian's kernel build tool to build a Debian kernel is depressing. This is just plain FUD. Now, what is really needed, is that a few people like Jonas and Manoj, who are working on tools vital to the kernel team developments, actually join the kernel team, and so we can all work together in the same direction. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 12:09:09PM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: BTW, jonas, i notice also : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403203 Yes. I was slightly baffled about that bugreport fork, and is still wondering what to do about it: To me is seems like a report against the packager rather than the package itself... Yeah, right. I want yaird to be a _generic_ tool for building initial ramdisks, without favoring the specific kernels maintained by the Debian kernel team. The reality is that yaird has fallen aside during this whole year, because of little activity on your part (and i must say that i stopped pushing yaird after you explained to me why you should not take the 10 minutes to investigate the RC bug report in erkelenz). Have you heard of yaird's upstream since last year ? I remember you telling me that you didn't understand yaird enough to do stuff yourself, and there was no sign of upstream. Has this situation improved ? what are your plans regarding to this ? I believe that maintaining yaird separately from debian-kernel helps avoid interest conflicts. Well, this is where you are wrong, there is no conclict of interest. The kernel-team++ should take responsability from building the official kernels, but also from letting users build their own kernels, which integrate perfectly with the whole kernel stuff. It is you (and to a lesser degree Manoj), who, by not integrating the kernel team, are making this separation, and that is not a good thing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-9
On Sun, Dec 17, 2006 at 01:53:03PM +0100, Max Vozeler wrote: Hi all, On Sun, Dec 17, 2006 at 02:43:57AM -0800, Steve Langasek wrote: On Fri, Dec 15, 2006 at 06:08:08PM +0100, Frederik Schueler wrote: This update bears 3 ABI breaking changes. While the vserver patch might be adaptable, the PAE migration of i386 Xen is not. But we need this change as a workaround for #399113, otherwise the i386 Xen kernels will be broken in the release, and require an immediate update. And since we are already planning an ABI bump, we can add the missing changeset of 2.6.18.5, too. The first two ABI changes are specific to extra kernel flavors that aren't relevant to the installer and have few (if any?) extra modules built for them. Actually, quite a few modules packages are being built for the vserver and xen flavours : main: spca5xx (linux-modules-extra-2.6) redhat-cluster (linux-modules-extra-2.6) squashfs(linux-modules-extra-2.6) loop-aes(loop-aes) contrib: ipw2100 (linux-modules-contrib-2.6) ipw2200 (linux-modules-contrib-2.6) ipw3945 (linux-modules-contrib-2.6) non-free: kqemu (linux-modules-nonfree-2.6) Unless I missed some, I think this concerns four source packages. I'm not sure if it would be possible to binNMU / force rebuild of those, but since linux-modules-* are maintained by the kernel team and loop-aes by myself, I think we could react quickly and rebuild them via normal sourceful uploads as well. Why is loop-aes not part of the official module packages ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 12:30:28AM -0600, Manoj Srivastava wrote: On Sun, 17 Dec 2006 22:50:04 +0100, Jonas Smedegaard [EMAIL PROTECTED] said: Sven Luther wrote: Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought This is a egregious mischaracterization of my stance. Well, this may not be your stances, but you have in the past strongly communicated that way. Go look for the web archive of your post of this past year if you don't believe me. Now, all i was saying, is that everyone would benefit if you worked more closely with the kernel team, and in the same way, if Bastian was more open, and if ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#387767: Installation Failure
On Sun, Dec 17, 2006 at 02:43:49PM -0600, Keith Parkansky wrote: Sven Luther wrote: On Wed, Nov 15, 2006 at 02:19:51AM -0600, Keith Parkansky wrote: FYI The new Debian Installer using the 2.6.17 kernel does NOT fix the CD drive problem that is covered by bug 387767. I just downloaded the Net Install image and tried to install from it and had the same problem. Please try it with the new 2.6.18 kernels, which are scheduled for the etch release, and should enter d-i soon. There where some CD related fixes which where applied recently. Friendly, Sven Luther Was etch frozen with 2.6.17 or 2.6.18 ? If frozen with 2.6.17, was this bug resolved some other way ? Etch will have 2.6.18, and the 2.6.18 kernels are in etch rigth now. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Fri, Dec 15, 2006 at 04:40:16PM +0100, Goswin von Brederlow wrote: From personal experience I must say that bugs reported against kernel-package get manojs attention fast and get fixed fast. Bugs against the linux-2.6 source get ignored or you get comments like breaks cross building and any request of the error or a build log gets ignored. ... I think the blame is much more on the kernel team than manoj. He doesn't have a crystal ball to see linux-2.6 problems relevant to kernel-package. The team has to report them first. Only then can you have a discussion about the problems and find solutions. Well, the real problem is that Manoj could be part of the kernel team, and to a point even is, since he has svn access to the repo. But there is a problem, in that Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought (not mentioning memories of when he was the debian kernel maintainer all those years ago and whatnot), while Bastian handles most of the official kernel infrastructure, and obviously doesn't care much about self-built ones. So, basically, the problem is of two infrastructure people, both proud and head-strong, and both pulling the stuff in their own separate direction. I don't think pointing the fingers about responsability will help in any way here, but more cooperacion on both sides would be helpful. Let's all have a kernel-team meeting somewhere post-etch, and try to work together or something ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403309: initramfs-tools: [powerpc] 2.6.19/efika kernels need the pata_mpc52xx module.
Package: initramfs-tools Severity: wishlist Hi Maximilian. The new efika board i am working with, need the pata_mpc52xx ide driver for mounting the disk. This module is not included in the initramfs-tools most target, which has as consequence, as you can imagine, that the kernel+ramdisk won't boot on those boards. Since this module is not present in older kernels, or in other flavours, i wonder if it can just be added or something ? -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390862: Needs a new source to build?
On Tue, Dec 12, 2006 at 03:46:03PM +0100, Loïc Minier wrote: Hi, ISTR that when I discussed this on #debian-kernel, I was told that one of the problem is that linux-2.6 is already very long to build on x86 (due to the numerous flavors). So what ? Or maybe this is an excuse for asking for a donation of a more powerful x86 autobuilder hardware, maybe one that could handle arch-all packages too, and thus allow for discarding the binaries uploaded and have everything autobuilt. Perhaps it makes sense to build one type of kernels in a separate source package, for example all bigmem flavors in a linux-bigmem source? Plase don't, this would only complicate issues more for future security builds. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up - unbootable
On Sun, Dec 10, 2006 at 10:39:45AM +0100, maximilian attems wrote: On Wed, 06 Dec 2006, Sven Luther wrote: Package: initramfs-tools Severity: critical Justification: breaks the whole system hmm yes i know of that situation it affects a certain range of roots. Today i went to the datacenter to reboot the xserve G5 i have there, for some random reason, and what was not my surprise to notice that the box didn't come up anymore. After some dmesg examination, i noticed that the sata disks did come up only after i-t tried to bring up the RAID and LVM stuff, which is really not nice. the trouble is that udevsellte exists to early that mean when the scsi/usb discs are not up yet. hitting raid/lvm2 roots on those devices and more general lilo boots as there you have no root dev to wait for. i notified udev upstream for it, but got no response i'll reask privately. http://marc.theaimsgroup.com/?l=linux-scsim=116189244404693w=2 Yeah, please do, we really need to fix this before etch is out, i don't think that having a server who cannot reboot sometimes is something we want to ship in etch. Furthermore, playing offline without any info with the box, i was not able to convince i-t to mount the partition and investigate, but well, i guess i would have been able to do so if i had the code available, or more time to investigate. you should have rerun the early initramfs-tools stages, see init. than it works. Ah, that was the missing info. I searched a bit, but didn't find easily what to do, and then i had to leave. I will be at the box on thursday again. Now, as a temporary workaround, maybe one solution, if RAID/LVM was not found is to delay for a given time (1/2 minute ? a configurable time ?), and then try again. Another nice thing would be able to rerun the early initramfs-tools stages, or maybe even have a stamp of each completed stage, and a single command which allow to restart the detection from there ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up - unbootable
Package: initramfs-tools Severity: critical Justification: breaks the whole system Sorry maks for this RC bug, but i think the severity is deserved. Today i went to the datacenter to reboot the xserve G5 i have there, for some random reason, and what was not my surprise to notice that the box didn't come up anymore. After some dmesg examination, i noticed that the sata disks did come up only after i-t tried to bring up the RAID and LVM stuff, which is really not nice. on this machine, root is on a LVM, inside a RAID1 on two physical disks. Furthermore, playing offline without any info with the box, i was not able to convince i-t to mount the partition and investigate, but well, i guess i would have been able to do so if i had the code available, or more time to investigate. The box is currently switched off until i can come back with a fix to this issue (oh, and it refused to eject the CDROM i put in it to try to boot the debian-installer in resuce mode :). Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 10:37:01AM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [061201 20:30]: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. If one of the release managers uses the force-hint, nothing from the first stage (RC-bugs, date, out-of-date, ...) will block the testing migration anymore. However, in the second stage, installability is checked. According to todays output, these packages are broken by the transition: trying: linux-2.6 skipped: linux-2.6 (15 - 32) got: 115+0: i-115 * i386: kernel-image-2.6-386, kernel-image-2.6-686, kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, linux-headers-2.6-k7, linux-headers-2.6-vserver-686, linux-headers-2.6-vserver-k7, linux-headers-2.6-xen-686, linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, linux-image-2.6-xen-686, linux-image-2.6-xen-k7, linux-image-486, linux-image-686, linux-image-686-bigmem, linux-image-k7, linux-image-vserver-686, linux-image-vserver-k7, linux-image-xen-686, linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, loop-aes-2.6.17-2-vserver-686, loop-aes-2.6.17-2-vserver-k7, nvidia-kernel-legacy-2.6-486, nvidia-kernel-legacy-2.6-686, nvidia-kernel-legacy-2.6-686-smp, nvidia-kernel-legacy-2.6-k7, nvidia-kernel-legacy-2.6-k7-smp, redhat-cluster-modules-2.6-486, redhat-cluster-modules-2.6-686, redhat-cluster-modules-2.6-686-bigmem, redhat-cluster-modules-2.6-k7, redhat-cluster-modules-2.6-vserver-686, redhat-cluster-modules-2.6-vserver-k7, redhat-cluster-modules-2.6-xen-686, redhat-cluster-modules-2.6-xen-k7, redhat-cluster-modules-2.6.17-2-486, redhat-cluster-modules-2.6.17-2-686, redhat-cluster-modules-2.6.17-2-686-bigmem, redhat-cluster-modules-2.6.17-2-k7, redhat-cluster-modules-2.6.17-2-vserver-686, redhat-cluster-modules-2.6.17-2-vserver-k7, redhat-cluster-modules-2.6.17-2-xen-686, redhat-cluster-modules-2.6.17-2-xen-k7, spca5xx-modules-2.6-486, spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, squashfs-modules-2.6-vserver-k7, squashfs-modules-2.6-xen-686, squashfs-modules-2.6-xen-k7, squashfs-modules-2.6.17-2-486, squashfs-modules-2.6.17-2-686, squashfs-modules-2.6.17-2-686-bigmem, squashfs-modules-2.6.17-2-k7, squashfs-modules-2.6.17-2-vserver-686, squashfs-modules-2.6.17-2-vserver-k7, squashfs-modules-2.6.17-2-xen-686, squashfs-modules-2.6.17-2-xen-k7, unionfs-modules-2.6-486, unionfs-modules-2.6-686, unionfs-modules-2.6-686-bigmem, unionfs-modules-2.6-k7, unionfs-modules-2.6.17-2-486, unionfs-modules-2.6.17-2-686, unionfs-modules-2.6.17-2-686-bigmem, unionfs-modules-2.6.17-2-k7 I could use a force-hint on linux-modules-extra-2.6 as well, but as long as it is out-of-date on so many architectures, that won't improve the picture. And also, why do e.g. linux-image-2.6-vserver-k7 get uninstallable (hm, that could be a bug in britney though). Ok, this is the linux-modules-extra-2.6 problem, which should be solved by removing the module which is broken. not sure which one it was. The -k7 issue, i don't know, can it be a flavour that was dropped or something ? - What are our plans for 2.6.19 ? Will we have it enter unstable, and maintain the etch kernel through testing-proposed-updates ? I heard this mentioned some time back. Will we fork a linux-2.6.19 package in unstable
Bug#401269: [powerpc] Apple G5 windfram based fan control modules not included or loaded in initramfs-tools generated ramdisks.
Package: initramfs-tools Severity: Important On Sat, Dec 02, 2006 at 05:45:52PM +0900, Charles Plessy wrote: Le Thu, Nov 30, 2006 at 04:12:56PM +0100, Holger Levsen a écrit : On Thursday 30 November 2006 12:20, Charles Plessy wrote: On the other hand, I recommend to test wether they also stay silent on the installed system as well. Could you do this? Hi, The problem with the fan control is solved for the installer, but /etc/modules does not contain the necessary entries to start the fan control at boot time on the installed system. Hi Charles, the problem is not with /etc/modules, but with initramfs-tools. Mmm, i think i cannot find this bug, so opening a new one with this message. Max, can you add somethign to initramfs-tools, as we discussed numerous times, to load the fan control modules ? At worst, you can load the same modules as is done in d-i. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378344: [powerpc,prep] On PReP boxes, root should be autodetected, since there is no bootloader.
severity 378344 grave # Upping severity, since this bug makes a PReP d-i install not being able to # boot in the resulting system. Furthermore, this is a general regression from # sarge and initrd-tools. Thanks Max, ... When playing with initramfs-tools Motorola Powerstack PReP box, i noticed that the machine didn't find the root device on reboot. I had chosen a LVM setup, not sure if this influence the issue. I had to give the root=/dev/powerstack/root argument by hand on the kernel command line, which is less than optimal. I booted into the system, and added ROOT=/dev/powerstack/root, but it would be nice if this was autodetected, as it is done in both yaird and initrd-tools. Furthermore, it would be nice if the ROOT= option would be documented, and an empty entry would be present in the default config file, like the other options. Does ROOT=probe also work in initramfs-tools, like it did for initrd-tools ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 11:36:30AM +0100, Bastian Blank wrote: On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: linux-2.6: - Some small security fixes. - Fix for internal posix types support for s390. - Conflict with too old initramfs generators, the fallback entry matches them also. - Don't longer disable serial drivers in xen images. linux-modules-extra-2.6: - Disable squashfs on arm, does not work. Ok, do we have a plan for this ? - latest info from Bastian was that the 2.6.19-rc6 experimental packages in experimental failed to build because of some kernel-package problem which caused silent bugs. Bastian, do you have any additional info to provide which may give a light to the problem ? Manoj, can you have a look at this, and maybe help us fix the issue ? I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. Well, we can : 1) Revert the infrastructure changes to the 2.6.18 one. 2) You could give as much information as you can about the problem, so that someone else (well, probably not me, because Manoj will not speak with me as far as i know), can follow up on this with him. In particular, one issue which remains open in the current situation, is that some could argue that it is not a k-p bug, but one in the infrastructure code, and as very few people apart from you have an oversight of what is really happeneing. I guess the more satisfying solution is 2), you provide a bit of info about what the problem is, and someone else goes to manoj and or to kernel-package, and resolve the problem. Thanks for your reply, Bastian, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 02:41:08AM -0800, Steve Langasek wrote: On Sat, Dec 02, 2006 at 10:51:57AM +0100, Sven Luther wrote: The -k7 issue, i don't know, can it be a flavour that was dropped or something ? linux-latest-2.6 is not a candidate because not yet uploaded on sparc. That's the easy part; linux-modules-extra-2.6 is the harder part, currently failing to build on both arm and s390 (c.f. bug #400220). Can we not just scratch l-m-e-2.6 until those issues are fixed, and migrate linux-2.6 andl-l-2.6 into testing asap ? We need to get more testing done for it. - What are our plans for 2.6.19 ? Will we have it enter unstable, and maintain the etch kernel through testing-proposed-updates ? I heard this mentioned some time back. Will we fork a linux-2.6.19 package in unstable ? Will we keep 2.6.19 in experimental for now ? I hope you can keep 2.6.19 in experimental for now - it doesn't take so long to release Etch anymore. Bah, we where told this for sarge, and it took over a year back then. I don't see us releaseing etch anytime soon, since we don't have had a single release candidate of d-i with the 2.6.18 kernels in it yet, so moving 2.6.19 to unstable (maybe with a linux-2.6.19 source package) should be nice enough. We did this already for 2.6.16, so, we know how to do this. Frankly, 2.6.16 was a total cock-up. Aside from all the extra work it made for the release team, I even found patches I had to reapply for alpha because they were dropped on the floor when 2.6.16 was merged to trunk. I am very much opposed to having two kernel versions in unstable at the same time. Well, the idea is to continue working on 2.6.19 in a separate package, but keeping 2.6.18 linux-2.6 as the main package, with linux-2.6.19 being a separate package which will be worked on as separatedly for those peopel who want. But you are right, if we want to do more than one kernle, we need an automated better way to do synchronizations. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19 patches
On Sat, Dec 02, 2006 at 03:46:58PM +0100, Bastian Blank wrote: Hi folks I intend to drop old patches from 2.6.19, this includes: - Anything not categorized (debian/patches/*.patch). There is one problematic one: alpha-prctl.patch, which is not upstream; the alpha maintainer have to check that and fix the category. Please don't drop the powerpc patches, they were all checkd and updated for 2.6.19-rc6. - Anything not debian specific and not submitted within the last 6 months. (I only know one: asfs, which can be easily built as external module.) Let's keep it for now, if i don't get it resubmitted before 2.6.20, we can drop it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19 patches
On Sat, Dec 02, 2006 at 03:52:59PM +0100, maximilian attems wrote: On Sat, Dec 02, 2006 at 03:46:58PM +0100, Bastian Blank wrote: Hi folks I intend to drop old patches from 2.6.19, this includes: - Anything not categorized (debian/patches/*.patch). There is one problematic one: alpha-prctl.patch, which is not upstream; the alpha maintainer have to check that and fix the category. - Anything not debian specific and not submitted within the last 6 months. (I only know one: asfs, which can be easily built as external module.) Bastian ack for - modular-ide-pnp.patch never accepted upstream and ata is the way forward. - fbdev-radeon-noaccel.patch one of those ppc patches that don't get forwarded, why? Huh, it had not powerpc in the name so i haven't looked at it for ages. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19 patches
On Sat, Dec 02, 2006 at 04:18:39PM +0100, Bastian Blank wrote: On Sat, Dec 02, 2006 at 03:46:58PM +0100, Bastian Blank wrote: I intend to drop old patches from 2.6.19, this includes: - Anything not categorized (debian/patches/*.patch). There is one problematic one: alpha-prctl.patch, which is not upstream; the alpha maintainer have to check that and fix the category. - Anything not debian specific and not submitted within the last 6 months. (I only know one: asfs, which can be easily built as external module.) - Any unused patch. (The output of debian/bin/check-patches.sh) well, how many of those are not unused but where simply disabled when the first 2.6.19-rcX builds were tried. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19 patches
On Sat, Dec 02, 2006 at 05:23:42PM +0100, Bastian Blank wrote: On Sat, Dec 02, 2006 at 05:03:51PM +0100, Sven Luther wrote: Please don't drop the powerpc patches, they were all checkd and updated for 2.6.19-rc6. Than fix the categories. fix the categories ? Let's keep it for now, if i don't get it resubmitted before 2.6.20, we can drop it. It does not build at all and it is long enough in this state. Who needs this anyway? Lot of people i have to do support for. Well, i intent to fix the build problem, once i have the 2.6.19 package building myself. Can you give me the svn url for the branch where you fixed the stuff ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 12:43:06PM -0600, Manoj Srivastava wrote: On Sat, 2 Dec 2006 11:36:30 +0100, Bastian Blank [EMAIL PROTECTED] said: On Fri, Dec 01, 2006 at 08:26:10PM +0100, Sven Luther wrote: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. We need another upload of linux-2.6 and linux-modules-extra-2.6 to fix the following issues: linux-2.6: - Some small security fixes. - Fix for internal posix types support for s390. - Conflict with too old initramfs generators, the fallback entry matches them also. - Don't longer disable serial drivers in xen images. linux-modules-extra-2.6: - Disable squashfs on arm, does not work. - latest info from Bastian was that the 2.6.19-rc6 experimental packages in experimental failed to build because of some kernel-package problem which caused silent bugs. Bastian, do you have any additional info to provide which may give a light to the problem ? Manoj, can you have a look at this, and maybe help us fix the issue ? I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. And none of which you report. If you can't put together a Notice that this is the same problem as the guy with 2.6.11 reported. coherent bug report, you can't expect issues to get resolved. Frankly, k-p works fine when used as expected -- linux-2.6 tries to mould it in a fashion which is not exactly supported, by overriding bits and pieces, and I am not surprised when things do not work as you try to force them to. The real problem is that you don't really integrate well with the kernel team, and have your own agenda. This is also true from the other side though. What we really need is a strategy where you work better with the kernel team, where we have more communication (also applies to Bastian), and where the stated goal of kernel-package is to build both older kernel and the kernel packages. This would be a good starting point to take Jonas idea again, and move the postinst scripts out of kernel-package and the linux-images, and into separate package ? Even then, I would respond to bug reports which show misbehavior by kernel-package -- which have not exactly been forthcoming, have they? manoj tired of people trying to bend k-p into doing things it is not supposed to do, and then complaining when they fail Well, to be honest, it goes both way. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397942: g5 imacs now silent?
On Thu, Nov 30, 2006 at 04:24:07PM +0100, Holger Levsen wrote: Hi, this bug was originally about building certain windfarm drivers into the kernel instead of modules, but it seems, that this was a red herring and the current kernel in sid now includes working modules to turn the G5 fans silent. If this is correct, this bug can be closed. Is it correct? The bug should be retitled and reassigned to initramfs-tools, if it is not already. Or merged with other similar bugs if already present. Holger: thanks for the work you are doing. Can you also comment on : #397973: [powerpci/mac] partman-md appears to not write back the raid flag to partitions. Maybe it would be worth to raise the severity of this bug, but i can hardly do this, or i will be seen as whiner who ups the severity of his pet bugs, can i ask you to have a look at them ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398962: ircgate
On Wed, Nov 22, 2006 at 08:50:21AM -0500, Joey Hess wrote: Md joeyh: I remember talking about #398962 with waldi, IIRC platform devices in recent kernels provide $MODALIAS while they should not. so udev will always try loading again the driver after it has been loaded Md I suppose I could add a workaround in udev since I do not know about any platform driver which provides a meaningful $MODALIAS fjp Md: Has there been a discussion with kernel developers about that? Will/has it been fixed in later kernels? Md fjp: no clue. somebody should ask greg k-h but I am too much busy these days joeyh Md: afaics, there's no way udev can autoload that pcmcia bridge driver .. would just blacklisting it in udev make sense? Is there a way to blacklist it that doesn't blacklist it from modprobe? Md joeyh: try adding in hotplug.rules, as the third line: SUBSYSTEM==platform, GOTO=hotplug_driver_loaded Md IIRC it uses SUBSYSTEM==platform, double check the log if needed joeyh ok, that works, tested in d-i Md I will add the workaround to the next upload joeyh I imagine a more targeted rule that also matches the driver would also work joeyh at least for this one module.. dunno about other platform modules.. Md all platform drivers have this problem, the bug is in the drivers core Notice that the pegasos marvell gigabit ethernet port is such a platform device. We currently have a hacked patch in our kernel with makes it masquarade as a pci device, listening on the northbridge pci id, but when i tried to push this patch upstream, i was told it was not needed because of the platform device modalias support. There are probably other devices which gained hotplug and thus automatically loaded modules, in this way. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399768: mkvmlinuz script fails with command not found error
On Tue, Nov 21, 2006 at 10:05:22PM +0100, Sebastian Heutling wrote: Package: mkvmlinuz Version: 26 Severity: normal The output is: Running depmod. Finding valid ramdisk creators. Using mkinitrd.yaird to build the ramdisk. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.18-5 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.18-5 was configured last, according to dpkg) Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/mkvmlinuz /usr/sbin/mkvmlinuz: line 149: prep: command not found The line that is refered to looks like this: if dpkg --compare-versions $release ge 2.6.18 $arch != prep; then as you can see the test command is missing for the second comparison. Argh, indeed. Fixing ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399813: linux-image-2.6.17-2-686: SATA failure after 2.6.16 - 2.6.17 upgrade
On Wed, Nov 22, 2006 at 09:17:09AM +0200, [EMAIL PROTECTED] wrote: Package: linux-image-2.6.17-2-686 Version: 2.6.17-9 Severity: important Please try the 2.6.18-6 kernels currently in unstable. 2.6.18 is scheduled to be the etch kernel. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
On Sat, Nov 18, 2006 at 09:53:28AM +, Oleg Verych wrote: On 2006-11-16, Sven Luther wrote: Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? I have patch. Will be 2.6.20, as i was too late for .19. http://permalink.gmane.org/gmane.linux.usb.devel/48353 What does it do ? Just new id for an usb tool ? The description says : usb-serial: ti_usb, TI ez430 development tool ID Can it be included, it's not stable stuff, as i was told? Id of the patch is [EMAIL PROTECTED]. Well, can you post the full patch ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391626: Please include mol into linux-modules-extra before etch
On Fri, Nov 17, 2006 at 10:10:37AM +0100, Gaudenz Steinlin wrote: Hi On Thu, Nov 09, 2006 at 09:48:21AM +0100, Sven Luther wrote: On Thu, Nov 09, 2006 at 09:20:52AM +0100, Sven Luther wrote: On Thu, Nov 09, 2006 at 01:41:17AM +0100, Gaudenz Steinlin wrote: tags 391626 +patch Hi As the mol maintainer I would really appreciate it if you could include my patch before the etch release. The patch is already in the bug log since about a month. AFAICS a new upload of linux-modules-extra is needed anyway for linux-image-2.6.18-2-*. Please contact me if you need additional information or assistance. If you are busy with other things I can also prepare an NMU. Installing linux-support-2.6.18-2 and building the debian/control with it fails with : Ok, i applied it with the gencontrol.py patch excluded and without mol in the main defines. Gaudenz/Bastian, can you look over the gencontrol.py failure and fix the patch ? It seems that Bastian already applied the patch in SVN. The current SVN builds without problems for me (and the resulting mol modules work). As there needs to be another upload for 2.6.18-2 anyway I hope that the mol modules will be included. There will be an upload for -3, and mol should be included then. But my test build failed in unionfs due to sioq.h missing, so there will be need of some work for 2.6.18-2 anyway. unionfs is currently deactivated in SVN. Indeed. We solved this quickly after i wrote that mail. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
On Fri, Nov 17, 2006 at 08:23:34AM +0100, Christian T. Steigies wrote: Moin, On Thu, Nov 16, 2006 at 11:36:48PM +0100, Sven Luther wrote: Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? I'd like to re-enable building atari images for m68k, 2.6.18 with some patches is working on atari again and we might even haven two new drivers for network hardware (one of those is working on our uberfast Falcons already, they other one might, but we are still waiting for the hardware, that's how new it is). Unfortunately I am a little handicapped right now and I also managed to shoot down my atari, so it might be a little difficult to test, once I have the patches sorted out. This would not change anything with the existing m68k images, it would just (re-)add another one, which means we have to go through new, but we have to anyhow because of the abi change? Well, if you can send the patches, and they build, they can be included, and tested at a later time, and fixed if fixing is needed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
On Fri, Nov 17, 2006 at 10:20:09PM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Fri, Nov 17, 2006 at 06:32:54AM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? Friendly, Sven Luther 64bit i386 kernels even if that adds time to the build. Live with it. Please provide patches to our svn packages that enable it. Just demanding stuff and expecting others to do the work is not nice :) Friendly, Sven Luther Check the BTS. Its been there for ages now. Bug number ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
On Fri, Nov 17, 2006 at 10:52:45PM +0100, Bastian Blank wrote: On Thu, Nov 16, 2006 at 11:36:48PM +0100, Sven Luther wrote: As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. The ABI bump was requested and annonced where? Consider this the announcement. And we all know about this since a week or two, including you :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
On Thu, Nov 16, 2006 at 11:24:00PM +, Martin Michlmayr wrote: * Sven Luther [EMAIL PROTECTED] [2006-11-16 23:36]: Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? I should note that this is hopefully the last time we're changing the ABI for 2.6.18 before the release, so if you have any bigger config changes now's the time (and please test them!). If the abi needs changing in the near future, well, we will change it, obviously. I don't think there is a ny excuse for not going for a late abi bump if a abi-bumping security fix comes in, as we did for sarge. We have very nice infrastructure in place for that, and the rest of the uneeded work that still needs to be done manualy is from folk who resisted further automation, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
On Fri, Nov 17, 2006 at 06:32:54AM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? Friendly, Sven Luther 64bit i386 kernels even if that adds time to the build. Live with it. Please provide patches to our svn packages that enable it. Just demanding stuff and expecting others to do the work is not nice :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#387767: Installation Failure
On Wed, Nov 15, 2006 at 02:19:51AM -0600, Keith Parkansky wrote: FYI The new Debian Installer using the 2.6.17 kernel does NOT fix the CD drive problem that is covered by bug 387767. I just downloaded the Net Install image and tried to install from it and had the same problem. Please try it with the new 2.6.18 kernels, which are scheduled for the etch release, and should enter d-i soon. There where some CD related fixes which where applied recently. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Really 2.6.18?
On Fri, Nov 10, 2006 at 02:13:49PM +0100, maximilian attems wrote: trimmed release again from cc. please do not spam our hard working release manager. On Fri, Nov 10, 2006 at 11:05:20AM -0200, Otavio Salvador wrote: martin f krafft [EMAIL PROTECTED] writes: Are we sure we want 2.6.18 as the kernel for etch? I reported two bugs, #391929 and #391955, the first of which is readily reproducible on 2.6.18 only (including ABI -2), meaning I cannot see the problem with 2.6.17. #391955 is rather sporadic. I know the kernel team has been incredibly busy, but I have received zero reaction to my bug reports, which makes me think that they may not have been seen? After all, I did originally assign them to the kernel packages causing the problems: linux-image-2.6.18-1-amd64 and linux-image-2.6.18-1-686, rather than the linux-2.6 source package; they're reassigned now. At least for XEN 2.6.17 has serious problems. I have three machines that are unable to boot with 2.6.17 and them work fine with 2.6.18. the choice is out of discussion, 2.6.17 is not supported since long. and we focus on a good 2.6.18 release, look at the changelogs.. :) Me supports maks in this. The powerpc 2.6.17 is missing half a dozen fixes prsent in 2.6.18, and worse, i don't even remember all of them. And this is not counting the various fixes which are upstream stuff. It would be a major backporting effort to revert to 2.6.17 now, and would probably mean a delay of the release of a couple of months, if nothing else. As Maks said, 2.6.17 is dead, and the only reason for it to be still in the archive is that we are waiting for the d-i rc1 release to kill it. I personally would not have waited, and released rc1 with 2.6.18 directly, but i am not the d-i release manager, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397942: linux-image-2.6.18-2-powerpc64: Please build windfarm_pm81 in the kernel, not as a module.
On Sat, Nov 11, 2006 at 12:38:44AM +0900, Charles Plessy wrote: Package: linux-image-2.6.18-2-powerpc64 Version: 2.6.18-5 Severity: important Dear Kernel team, The code controlling fan speed on iMac G5 do not work correctly as a module. As a consequence, the fans run full speed with the standard kernel in Debian. This renders the mac unusable: the fans are _very_ loud when they are fullspeed. Is this really the case ? You probably forgot to load the modules, or rather to load i2c-powermac. This is more an initramfs-tools bug than a kernel one, maks, you said you would fix them ? The only solution I know is to build windfarm_pm81 directly in the kernel. This is only doable for experienced users. I hope that you can manage to bring a corrected kernel in Etch, otherwise I am affraid that nobody except developpers will use Debian on iMacs G5. Lastly, is is not impossible that all of this extends to the other windfarm modules (91 and 112). Well, i have discussed the issue with benh, and at least with the therm72 of my XServe G5, the issue is neatly solved by loading the right modules. Please provide us with an lsmod output of your running noisy system. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391626: something broken in the debian/control generation concept ? (Was: Bug#391626: Please include mol into linux-modules-extra before etch)
On Thu, Nov 09, 2006 at 01:41:17AM +0100, Gaudenz Steinlin wrote: tags 391626 +patch Hi As the mol maintainer I would really appreciate it if you could include my patch before the etch release. The patch is already in the bug log since about a month. AFAICS a new upload of linux-modules-extra is needed anyway for linux-image-2.6.18-2-*. Please contact me if you need additional information or assistance. If you are busy with other things I can also prepare an NMU. I did give it a try, but i faced : $ dpkg-buildpackage -rfakeroot -us -uc dpkg-buildpackage: source package is linux-modules-extra-2.6 dpkg-buildpackage: source version is 2.6.18-2 dpkg-buildpackage: source changed by Gaudenz Steinlin [EMAIL PROTECTED] dpkg-buildpackage: host architecture powerpc dpkg-buildpackage: source version without epoch 2.6.18-2 dpkg-checkbuilddeps: error: cannot read control file debian/control: No such file or directory dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: (Use -d flag to override.) [EMAIL PROTECTED]:~/debian/kernel/trunk/build/linux-modules-extra-2.6$ debian/rules debian/control debian/rules:5: /usr/src/linux-support-2.6.18-1/modules/rules.include: No such file or directory make: *** No rule to make target `/usr/src/linux-support-2.6.18-1/modules/rules.include'. Stop. Which seems to indicate that there is something broken in the linux-modules-extra-2.6 concept, since you need to have the dependencies satisfied (i suppose) when building the debian/control, while at the same time you cannot run dpkg-buildpackage to get the missing dependencies without the debian/control file. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391626: Please include mol into linux-modules-extra before etch
On Thu, Nov 09, 2006 at 01:41:17AM +0100, Gaudenz Steinlin wrote:
tags 391626 +patch
Hi
As the mol maintainer I would really appreciate it if you could include
my patch before the etch release. The patch is already in the bug log
since about a month.
AFAICS a new upload of linux-modules-extra is needed anyway for
linux-image-2.6.18-2-*.
Please contact me if you need additional information or assistance. If
you are busy with other things I can also prepare an NMU.
Installing linux-support-2.6.18-2 and building the debian/control with it
fails with :
$ debian/rules debian/control
if [ -f debian/control ] [ -f debian/control.md5sum ] [ -f
debian/rules.gen ]; then \
if md5sum debian/changelog debian/templates/control.modules.in
debian/templates/control.source.in | diff - debian/control.md5sum /dev/null;
then true; else \
/usr/bin/make -f debian/rules debian/control-real; \
fi \
else \
/usr/bin/make -f debian/rules debian/control-real; \
fi
make[1]: Entering directory
`/home/sven/debian/kernel/trunk/build/linux-modules-extra-2.6'
debian/bin/gencontrol.py /usr/src/linux-support-2.6.18-2/modules/..
Traceback (most recent call last):
File debian/bin/gencontrol.py, line 157, in ?
gencontrol(sys.argv[1] + /arch)()
File
/usr/src/linux-support-2.6.18-2/lib/python/debian_linux/gencontrol.py, line
36, in __call__
self.do_main(packages, makefile)
File
/usr/src/linux-support-2.6.18-2/lib/python/debian_linux/gencontrol.py, line
59, in do_main
self.do_arch(packages, makefile, arch, vars.copy(), makeflags.copy(),
extra)
File
/usr/src/linux-support-2.6.18-2/lib/python/debian_linux/gencontrol.py, line
120, in do_arch
self.do_arch_recurse(packages, makefile, arch, vars, makeflags, extra)
File
/usr/src/linux-support-2.6.18-2/lib/python/debian_linux/gencontrol.py, line
136, in do_arch_recurse
self.do_subarch(packages, makefile, arch, subarch, vars.copy(),
makeflags.copy(), extra)
File
/usr/src/linux-support-2.6.18-2/lib/python/debian_linux/gencontrol.py, line
149, in do_subarch
self.do_subarch_recurse(packages, makefile, arch, subarch, vars,
makeflags, extra)
File
/usr/src/linux-support-2.6.18-2/lib/python/debian_linux/gencontrol.py, line
165, in do_subarch_recurse
self.do_flavour(packages, makefile, arch, subarch, flavour, vars.copy(),
makeflags.copy(), extra)
File debian/bin/gencontrol.py, line 46, in do_flavour
self.do_module(module, packages, makefile, arch, subarch, flavour,
vars.copy(), makeflags.copy(), extra)
File debian/bin/gencontrol.py, line 53, in do_module
config_entry = self.config['base', module]
File /usr/src/linux-support-2.6.18-2/lib/python/debian_linux/config.py,
line 37, in __getitem__
return self.get(key)
File /usr/src/linux-support-2.6.18-2/lib/python/debian_linux/config.py,
line 52, in get
raise KeyError, key
KeyError: ('base', 'mol')
make[1]: *** [debian/control-real] Error 1
make[1]: Leaving directory
`/home/sven/debian/kernel/trunk/build/linux-modules-extra-2.6'
make: *** [debian/control] Error 2
Bastian, this is your call.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391626: Please include mol into linux-modules-extra before etch
On Thu, Nov 09, 2006 at 09:20:52AM +0100, Sven Luther wrote: On Thu, Nov 09, 2006 at 01:41:17AM +0100, Gaudenz Steinlin wrote: tags 391626 +patch Hi As the mol maintainer I would really appreciate it if you could include my patch before the etch release. The patch is already in the bug log since about a month. AFAICS a new upload of linux-modules-extra is needed anyway for linux-image-2.6.18-2-*. Please contact me if you need additional information or assistance. If you are busy with other things I can also prepare an NMU. Installing linux-support-2.6.18-2 and building the debian/control with it fails with : Ok, i applied it with the gencontrol.py patch excluded and without mol in the main defines. Gaudenz/Bastian, can you look over the gencontrol.py failure and fix the patch ? But my test build failed in unionfs due to sioq.h missing, so there will be need of some work for 2.6.18-2 anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
