[01:03] jbailey: are you handling udev? [01:08] zul: you found a possible fix for my irqpoll issue? [01:09] zul: I've looked through the code a bunch, what do you need? [01:11] mdz: i might have gimme a sec.. [01:12] Hrm. I meant to test the new kernel but went to the pub instead. [01:13] mdz: http://linux.bkbits.net:8080/linux-2.5/gnupatch@41d8ffffTqVUXXYJ_W0XUlqj90uQGg [01:14] mjg59: pub > kernel [01:14] jbailey: could you have a look at #3069? [01:14] zul: I'm happy to test it, since it's in the sound driver and not (as I feared) another general IRQ routing mess [01:14] fabbione: I agree [01:15] mdz: ok...i should have something for you tomorrow [01:15] my fast pc is at work [01:15] zul: That's a closed evo bug. EBUGNUM? [01:16] grr [01:16] btw.. we might need to release -30 pretty soon [01:16] 3609...sorry am a bit dyslexic :) [01:16] fabbione: how come [01:16] so if you have pending stuff, let's get it tested during eastern [01:17] zul: some more security stuff that is all public already [01:17] easter you mean :) [01:17] ah [01:17] ok [01:17] yeah that kind of holidays [01:17] i might as well get -30 out tomorrow if i can manage to [01:17] we need to get these bits tested asap [01:18] sure [01:18] mdz: do you think you can test that patch within the next 5/6 hours? [01:18] zul: please add the bk info to the bugs so i can merge the patch if it works [01:19] fabbione: no problem [01:19] or sync your archive.. or whatever you prefer :-) [01:19] its in my archive already [01:19] ok.. i will merge from you than [01:19] zul: Fine, I can take this. I have another wishlist bug against udev assigned to me that I was planning on nailing anyway (same sort of thing) [01:20] cool...merci buckets [01:21] oki doki [01:21] i am off for the night... === fabbione has to wake up in 4:30 hours [01:21] c ya [01:21] night [01:22] mdz: are you running a 686 kernel? [01:23] i can try to get this started so it might be possible to test tonight [01:28] zul: k7 on the affected system [01:28] zul: 2.6.10-3-k7 in fact ;-) [01:28] I haven't rebooted it in some time [01:28] but I'm happy to do so in order to test if needed [01:29] ok [01:29] ill start a build now === mdz [~mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #ubuntu-kernel === Viper`` [~viperx@200-158-185-63.dsl.telesp.net.br] has joined #ubuntu-kernel === cc [~cc@203-166-233-60.dyn.iinet.net.au] has joined #ubuntu-kernel [06:53] fabbione: you around yet: [07:47] morning [07:47] sorry.. i overslept [07:48] lamont: go ahead :-) [09:57] mjg59: 7377 [09:57] is that some ACPI fucks up? === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel === cc [~cc@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #ubuntu-kernel [11:41] fabbione: I honestly have no idea. It's very, very odd. [11:42] mjg59: do you have any idea on how to debug it? [11:45] The only real hope is to build a kernel with acpi debugging and try to work out where the event is coming from [11:45] It certainly /look/ like the poweroff method is being called [11:51] mjg59: ok.. what do you want me to do to give them a test kernel? [11:51] or can you do it directly? [11:53] Let me take a look at their dsdt first, and see if I can work out what's up [11:53] ok === ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre30--2.6.10 | Get it or http://www.vijaygill.com/pics/stfu.gif | There are no kernel bugs.. only broken hardware | Kernel Team Meeting in this chan: Tue 29th March 20:00 UTC === nowlin [~alex@D40A9ED5.rev.stofanet.dk] has joined #ubuntu-kernel [02:06] Hejsa nowlin === nowlin [~alex@D40A9ED5.rev.stofanet.dk] has joined #ubuntu-kernel === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel === zul [~chuck@198.62.158.205] has joined #ubuntu-kernel [02:40] hey === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel [02:53] -29 is absolutely rocking on my available hardware. Thanks! [02:54] dont thank just him ;) [03:28] I hate writing documentation [03:49] heh..fabbione you have been busy this morning [03:50] or afternoon whatever.. [05:09] T-None, http://kmuto.jp/open.cgi?buildd [05:10] we should set a deadline for kernel changes for the release candidate [05:10] what would you be comfortable with? [05:12] uh...there hasnt been any major changes to the kernel afaik we are just doing major bug fixes right now but fabbione can clarify === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-kernel [05:18] right, but at some point we must lock it down entirely, no more changes [05:18] this should be well in advance of the release candidate [05:18] true...thats fabbione's call since he is doing the uploads [05:19] Mar 09 14:32:28 - get kernel sorted TWO WEEKS BEFORE :-) [05:19] that would be today ;-) [05:19] but we do need to set a cutoff [05:19] i think fabbione is doing one more upload for some security fixes and the snd_via82xx patch as well [05:40] mdz: Jordi and I are looking at the new instance of 1440 as we speak. === jordi [~jordi@81-202-91-238.user.ono.com] has joined #ubuntu-kernel [05:41] jbailey: jordi has hardware which exhibits the problem? [05:41] plop! [05:41] speaking of the jordevil... [05:41] mdz: He has the matching pci:id and reported the problem. I had him check the array6 first for the known working config. [05:41] We're just about to try a nightly from a couple days ago. [05:42] jbailey: ok, dmesg sent. [05:42] jbailey: should I wipe it and install the nightly now? [05:43] I think if you get as far as wiping it that you don't have the problem from what I understand. [05:43] I was just wondering whether or not I should have you move from the 686 kernel to the 386 one first, since that's what you'll actually be running on the installer. [05:43] nod, ie, I should just check that d-i likes the cd [05:43] jbailey: good idea. [05:43] Yup, please. It's a quick enough test. [05:45] scsi1 : ata_piix [05:46] piix 0wnz the cd drives and they work [05:46] kernel 2.6.10-5-386 [05:46] inside the daily d-i system. it looks good [05:46] Luvly. Do you have the other CD burned? [05:47] array6 and the daily, which is what I just booted. [05:47] Ugh. [05:47] So I wonder what's different? [05:47] I haven't tried with the 386 image on the installed system yet. [05:47] No, that should be enough. [05:47] It's not happening on your hardware then. =( You have matching PCI id's though. [05:48] jbailey: what's different where? All my three tests worked: array6 d-i, installed system old 386 kernel, installed system new 686 kernel and now daily d-i 386 kernel [05:48] nod [05:48] jordi: Between you and the original reporter. [05:48] it does happen with debian's 2.6.8 though. [05:48] AFAIK, not with Debian's 2.6.10. [05:48] Right, we've got a patch in our kernel to tell it to cope. [05:48] I wonder if it's in debian too [05:50] so jordi has the right PCI IDs but can't reproduce the bug? [05:50] apparently [05:50] gaah [05:51] is there any /proc bit that I can send to you guys that gives you more info about my ide stuff? [05:52] lunch time [05:52] jordi: lspci -v, I supopse [05:52] suppose [05:53] k [05:59] fabbione: we are going to need to freeze the BOF list now; I am making the schedule [05:59] I'll add a note to the page [05:59] actually it already says "do not edit", only I mean it now ;-) [06:00] jbailey: sent lspci === cc [~cc@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #ubuntu-kernel [06:28] jbailey! [06:31] jordi: Heya! [06:31] jbailey: anything else? [06:31] got lspci? [06:31] I did thanks. [06:31] ok [06:32] I need to run off for a bit soon. I've emailed the guy who originally reported the problems. Thanks for the help. [06:37] ok [06:37] I'll be gone in a short while too. [06:37] And won't be back in office for a week. === jordi [~jordi@81-202-91-238.user.ono.com] has left #ubuntu-kernel [] === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-kernel [06:46] mdz: yes we planned to freeze the kernel with -29, but we have 5 security fixed on the way (4 already committed and one we are still waiting for the patch) [06:47] and the only other thing is the via fix for you. [06:47] let me check... [06:47] I will test the via fix shortly [06:47] mdz: there is a very trivial bug fix (comment out one printk()) === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-kernel [06:47] and one change for d-i requested by Mithandir and KAmion (7800) [06:48] there is only one last thing left to do, to make pitti's life easier for security, but it is nothing that will affect the kernel itself. it's an extra target in debian/rules to automatically prepare changelog and 00list-* files for point releases. [06:49] zul: btw.. we need to talk about a couple of things when you have time [06:50] mdz: all of the above (excluding the via thing) has been already tested and verified [06:55] mdz: for the BOF schedule i am ok with what is on the wiki. I did ping kernel-team and no answers, so i want to believe that it is ok [06:55] fabbione: sure now would be good [06:56] zul: i did merge from you the via patches... [06:56] 3 things: [06:56] 1) check that the patch actually applies. the DPATCH header was broken [06:56] yeah i realized that last night and i didnt check it in [06:56] 2) the * dummy entry can be removed as soon as there is the first commit. it is there just to make dpkg-buildpackage happy [06:57] ok [06:57] 3) please try to follow the same rules for the changelog [06:57] Example: [06:57] * Fix foo bar in driver X: [06:57] - Add patch .dpatch. [06:57] writing the way you do imho is redundant [06:58] ok will do in the future [06:58] * Added patch foobar to fix X. [06:58] - Add patch blabla [06:58] see? :) [06:58] :) [06:59] btw.. it's just that i am farly anal on the changelog :-) [06:59] heh i noticed :) [06:59] because a good changelog is a big help to track down stuff [07:00] i always did it a different way in gentoo [07:00] that's something i learned from the good branden robinson [07:01] so are you going to upload -30 today? [07:02] i am waiting for mdz to confirm that it fixes the bug [07:02] ah [07:02] but we also have 2 security things without patch yet [07:02] so if i upload today there will be for sure another upload [07:03] what scares me is the possibility of an ABI change.... [07:03] that's why i am slightly more happy to wait and see [07:04] ola === cc [~cc@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #ubuntu-kernel [07:06] fabbione: ah ok thx for the hint. Anything special the CurrentlyBuilding file should contain? [07:06] T-Bone: yes. but don't bother for now. [07:06] it's not worth the pain [07:06] well [07:07] speeding up the kernel build would be quite a gain [07:07] T-Bone: just touch the file for now... [07:07] ah ok [07:07] cool [07:07] it really depends on how you created the chroot [07:08] debootstrap [07:08] did you use the buildd version? [07:08] yeah [07:08] s/version/variant? [07:08] well just touch that file for now... [07:08] done [07:08] though i suppose it'll only work for next build? [07:09] yeps and only for the kernel [07:09] ok [07:09] no other packages makes use of it for that [07:09] ok [07:09] otherwise you can still mark the kernel as "Not-for-US" [07:09] and build it manually [07:09] well, next time ones upload a kernel, it'll build faster on hppa :) [07:09] i'd rather have it mostly automated [07:16] mdz: i am off for dinner.. i will be back pretty soon [07:22] fabbione: kernel build is using /CurrentlyBuilding???? === T-Bone guesses lamont doesn't like that :) [07:23] given that it only exists in the data center, and would therefore be an FTBFS if such source were shipped, yeah... [07:23] I'd hate to have to file an ftbfs bug against the kernel... [07:24] actually it's not exactly that [07:24] fabbione told me that the build process would use concurrency *only* if that file existed [07:25] fabbione: no abi change on hppa [07:25] ah, I suppose that's OK [07:26] but it still feels wrong [07:46] lamont: i only check if the file exists. afaik there is no other way to determine if we are at the datacenter or not [07:46] fabbione: and we check because we don't want builds to go fast outside the data center??? [07:47] lamont: the use of -j is quite delicate [07:47] heh [07:47] people might have SMP and don't want the kernel compilation to fork and blabla [07:47] that's why there is a line debian/rules to override what is autodetected [07:47] right [07:48] # DO NOT UNCOMMENT THIS LINE WITHOUT READING make-kpkg man page. [07:48] # export CONCURRENCY_LEVEL := 15 [07:48] and later: [07:48] if [ -e /CurrentlyBuilding ] && [ -z "$(CONCURRENCY_LEVEL)" ] ; then \ [07:49] so basically the check of CurrentlyBuilding is harmless [07:49] it will never produce a FTBFS [07:50] fabbione: nonetheless, I find myself reminded of the 'if [ $(uid -un) = "buildd" ] " in oo.o [07:50] yeah i remember that :-))) [07:51] but does exist a more clean way to know if we are in a DC buildd? [07:51] no [07:51] the "feature" doesn't kill other buildds or stop producing _all.deb packages.. [07:51] probably because we didn't design one in [07:51] that's why i was comfortable to use it [07:51] yeah, yeah. I understand. it just makes me a little sick [07:52] yes and i understand your point :-) [07:52] i recog is a hack... [07:52] heh ubuntu actualy made slashdot [07:52] for the worst kernel? [07:52] for being created by a single person? (mako) [07:52] fabbione: if you're running as uid 'buildd', i guess you can reasonnably assume that concurrency is *wanted* [07:52] nah...userlinux and ubuntu [07:53] T-Bone: i run my buildd as sparcbuildd user... [07:53] tssks [07:53] ;) [07:53] if /buildd/ then (perlish) :) [07:54] didn't your mother tell you slashdot rots your brain? [07:55] kylem: ahaha [07:55] kylem: yes slashdot bad mmkay? [07:56] T-Bone: checking user id in the build will get you hurt [07:57] oh piss. i didn't know about CONCURRENCY_LEVEL [07:57] kylem: CONCURRENCY_LEVEL + ccache + distcc > * [07:57] fabbione, it takes me 7 hours to build the debian hppa images, heh. === T-Bone wonders if there's a way to change the Real name in a gpg key uid without revoking/recreating [07:58] and that's on a /fast/ machine with gobs of ram. [07:58] kylem: wel... you know what i did? [07:58] i just RTFM :) [07:58] ;-) [07:58] sorry.. i couldn't resist === kylem bearhugs fabbione [07:59] oh behave 8) [07:59] oh hey T-Bone [07:59] kylem: /topic [07:59] http://www.vijaygill.com/pics/stfu.gif <- [07:59] meh ^^T-Bone [07:59] fabbione: yeah showed that to a bunch of people you got me into trouble [07:59] :) [07:59] zul: how? ;) [08:00] fabbione: bastard! [08:00] fabbione: i knew that one :) [08:01] fabbione: in case you haven't noticed, I'm still getting to the meeting announcement [08:01] likewise the kernel stuff you sent me last night [08:02] lamont: i did the security stuff today [08:02] thansk [08:02] lamont: usually if i see you don't manage across my night, i do the morning after :-) [08:02] it's just that i didn't feel very happy to start security at 8pm [08:02] mdz: if you want -30 out today, can you please test the via fix? [08:02] heh [08:03] fabbione: I will [08:03] http://www.vijaygill.com/pics/give_a_damn_progress.gif [08:03] ahahha [08:03] glad I said something before digging into it [08:03] lamont: do always a baz update :-) [08:03] I need about 10 minutes to finish what I am doing before I shut down and reboot [08:03] that's how i know if it has been done or not ;) [08:03] mdz: ok thanks [08:03] it is my primary desktop which has the issue [08:03] roger that [08:04] (btw some pics on that website are really NOT nice) [08:04] fabbione: "done" != "in progress", fwiw [08:05] fabbione: hmm, forgot we had a kubuntu meeting scheduled for right now; it will have to wait until after [08:05] mdz: ok.. i might not be online, but everything is committed to baz [08:05] fabbione: can someone else do the upload? [08:06] mdz: sure.. lamont can.. otherwise i can do it tomorrow morning [08:06] fabbione: also another meeting in one hour [08:06] 12 hours won't make any difference [08:06] depending on how long the kubuntu meeting runs, I may not have time until after lunch [08:06] mdz: did i miss any meeting call? [08:06] fabbione: no [08:06] ok [08:07] mdz: anyway i wouldn't panic too much. i am pretty sure there will be another upload of the kernel before release [08:07] (if not 2) [08:08] fabbione: but this time, lets do the final upload at least 24 hours before release, eh>? [08:09] lamont: it's not up to me :( [08:09] we don't even have patches for a public security issue.... [08:09] becuase there is none [08:09] we should freeze the kernel this week [08:09] for the RC [08:09] mdz: RC can go with -29 [08:10] fabbione: RC means RELEASE CANDIDATE [08:10] or -30 [08:10] not 'mostly release candidate' [08:10] lamont: yes.. i know that :-) [08:10] once you plan to replace something in the build, it's no longer release candidiate [08:10] I would like to get the via fix in if it works; that means no more boot options on any of my test systems [08:10] so if we're planning on -30 being in the release, it really needs to be in before they build the RC isos [08:11] mdz: ok.. just take your time [08:11] lamont: yes i get that. but if i upload -30 now or tomorrow morning, it will still make it for RC [08:12] the relevant changes are only the security stuff and the via fix [08:12] if the via fix is go now [08:12] than it's all done [08:12] we only need Kamion to upload a new d-i to build on top of the new kernel [08:12] end of the story [08:13] i am sure we can manage easily :-) [08:17] are there actual d-i changes, or just needs a new daily-build? [08:18] lamont: just a rebuild like the daily [08:19] no changes are required === T-Bone notices that glibc produces a _all.deb [08:27] T-Bone: tell jbailey :) [08:27] hehe [08:31] T-Bone: s/deb$/deb in binary-arch target/ [08:31] true [08:31] hmm [08:31] [08:31] fabbione: gah, your trick seems not to work [08:31] binutils_2.15-5ubuntu2: not registered yet. [08:31] :( [08:32] T-Bone: for messing with setting things in w-b, it's best if it actually gets fed the right packages file to begin with [08:32] ? [08:32] T-Bone: i get that warning too once in a while [08:32] afaik it's harmless [08:33] fabbione: is error [08:33] at least on take [08:33] --take [08:33] fabbione: afaict, it discarded all other packages sent to the line [08:33] lamont: hmm i get that when i mark a package in Uploaded [08:33] lamont: that's on -u [08:33] well, it's an error it'll abort processing [08:33] gosh --merge-* is taking ages [08:34] and you get it because w-b doesn't know about that version of the package [08:34] yeah [08:34] lamont: but w-b gave me that version :-) [08:34] lamont: which is rather stange given w-b gave that package to buildd... [08:34] as fabbione said :) [08:34] exactly [08:34] actually, takes next to no time for me... but I don't have universe..... [08:35] interesting === T-Bone will definitely not schedule it more than once a day [08:35] lamont: i call that a bug, but that's my 2cents ;) [08:35] T-Bone: the DC does it every 30 min, x5 architectures [08:35] well [08:36] either having a flat archive makes things awfully slow [08:36] ah we might have a fix for the av_dc thingy that sucks 100% of the CPU [08:36] or you have hell of machines [08:36] it's been running for 8+ minutes here already [08:36] truth told it's the first time it's that long [08:36] i wonder if i have fucked up something [08:37] i should have run it -v [08:37] ah hell.. the patch is big === lamont works on the meeting announcement [08:37] yay! [08:37] heh [08:38] lamont: any reason why w-b doesn't publish its stats, btw? [08:38] ? [08:38] $web_stats = "/home/buildd/public_html/buildd/stats.txt"; [08:38] fabbione: i saw that it hasnt been proven though [08:38] lamont: ^^ [08:38] lamont: that file isn't created [08:39] zul: the patch is clean, but it changes the ABI afaict === T-Bone considers 10' as much too long to be honest, considers killing w-b [08:39] fabbione: heh.. [08:39] T-Bone: have you run do-merge-quinn? [08:39] no [08:39] it's currently deadlocking on a --failed [08:39] well, that's the only file that references $web_stats.... [08:39] afaict [08:40] err [08:40] do-merge-quinn != w-b --merge-quinn? [08:40] nope [08:40] t [08:40] it's yet more cruft that we don't care about [08:40] erf [08:40] fabbione: i say hoary+1 for it [08:41] zul: let me check something [08:41] i want to see if it is upstream [08:41] i already did and i believe it isnt [08:41] it might be worth extracting only the changes for the acxxx driver, try to build (for the ABI change) and ask him to tetst [08:42] i can do it if you want [08:42] that would be neat [08:42] he uses 686-smp [08:42] ok ill throw one together right now [08:42] ok great [08:43] fabbione: interestingly enough if you pass only 1 changes file to -u at a time, there's no error [08:43] T-Bone: hmm possibly === T-Bone wonders what happen if a package is marked -u twice or more === T-Bone hopes that's harmless [08:44] seems to be [08:45] fabbione, just the scsi stuff no 3com or acpi in that patch correct? [08:47] zul: one sec... [08:47] wow [08:47] seems that touching the file during the build made it work anyway [08:47] cool [08:49] zul: we mostlikely have the acpi changes already. worth to check anyway [08:49] k [08:49] mjg59: ping? [08:50] iirc the 3com drivers are broken with suspend resume and the patch is not intrusive... but hell we are so close to RC [08:50]