[01:03] <zul> jbailey: are you handling udev?
[01:08] <mdz> zul: you found a possible fix for my irqpoll issue?
[01:09] <jbailey> zul: I've looked through the code a bunch, what do you need?
[01:11] <zul> mdz: i might have gimme a sec..
[01:12] <mjg59> Hrm. I meant to test the new kernel but went to the pub instead.
[01:13] <zul> mdz: http://linux.bkbits.net:8080/linux-2.5/gnupatch@41d8ffffTqVUXXYJ_W0XUlqj90uQGg
[01:14] <fabbione> mjg59: pub > kernel
[01:14] <zul> jbailey: could you have a look at #3069?
[01:14] <mdz> 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] <mjg59> fabbione: I agree
[01:15] <zul> mdz: ok...i should have something for you tomorrow
[01:15] <zul> my fast pc is at work
[01:15] <jbailey> zul: That's a closed evo bug.  EBUGNUM?
[01:16] <zul> grr
[01:16] <fabbione> btw.. we might need to release -30 pretty soon
[01:16] <zul> 3609...sorry am a bit dyslexic :)
[01:16] <zul> fabbione: how come
[01:16] <fabbione> so if you have pending stuff, let's get it tested during eastern
[01:17] <fabbione> zul: some more security stuff that is all public already
[01:17] <zul> easter you mean :)
[01:17] <zul> ah
[01:17] <zul> ok
[01:17] <fabbione> yeah that kind of holidays
[01:17] <fabbione> i might as well get -30 out tomorrow if i can manage to
[01:17] <fabbione> we need to get these bits tested asap
[01:18] <zul> sure
[01:18] <fabbione> mdz: do you think you can test that patch within the next 5/6 hours?
[01:18] <fabbione> zul: please add the bk info to the bugs so i can merge the patch if it works
[01:19] <zul> fabbione: no problem
[01:19] <fabbione> or sync your archive.. or whatever you prefer :-)
[01:19] <zul> its in my archive already
[01:19] <fabbione> ok.. i will merge from you than
[01:19] <jbailey> 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] <zul> cool...merci buckets
[01:21] <fabbione> oki doki
[01:21] <fabbione> i am off for the night...
[01:21] <zul> c ya
[01:21] <fabbione> night
[01:22] <zul> mdz: are you running a 686 kernel?
[01:23] <zul> i can try to get this started so it might be possible to test tonight
[01:28] <mdz> zul: k7 on the affected system
[01:28] <mdz> zul: 2.6.10-3-k7 in fact ;-)
[01:28] <mdz> I haven't rebooted it in some time
[01:28] <mdz> but I'm happy to do so in order to test if needed
[01:29] <zul> ok
[01:29] <zul> ill start a build now
[06:53] <lamont> fabbione: you around yet:
[07:47] <fabbione> morning
[07:47] <fabbione> sorry.. i overslept
[07:48] <fabbione> lamont: go ahead :-)
[09:57] <fabbione> mjg59: 7377
[09:57] <fabbione> is that some ACPI fucks up?
[11:41] <mjg59> fabbione: I honestly have no idea. It's very, very odd.
[11:42] <fabbione> mjg59: do you have any idea on how to debug it?
[11:45] <mjg59> 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] <mjg59> It certainly /look/ like the poweroff method is being called
[11:51] <fabbione> mjg59: ok.. what do you want me to do to give them a test kernel?
[11:51] <fabbione> or can you do it directly?
[11:53] <mjg59> Let me take a look at their dsdt first, and see if I can work out what's up
[11:53] <fabbione> ok
[02:06] <fabbione> Hejsa nowlin 
[02:40] <zul> hey
[02:53] <mjg59> -29 is absolutely rocking on my available hardware. Thanks!
[02:54] <zul> dont thank just him ;)
[03:28] <zul> I hate writing documentation
[03:49] <zul> heh..fabbione you have been busy this morning
[03:50] <zul> or afternoon whatever..
[05:09] <zul> T-None, http://kmuto.jp/open.cgi?buildd
[05:10] <mdz> we should set a deadline for kernel changes for the release candidate
[05:10] <mdz> what would you be comfortable with?
[05:12] <zul> uh...there hasnt been any major changes to the kernel afaik we are just doing major bug fixes right now but fabbione can clarify
[05:18] <mdz> right, but at some point we must lock it down entirely, no more changes
[05:18] <mdz> this should be well in advance of the release candidate
[05:18] <zul> true...thats fabbione's call since he is doing the uploads
[05:19] <mdz> Mar 09 14:32:28 <sabdfl>         - get kernel sorted TWO WEEKS BEFORE :-)
[05:19] <mdz> that would be today ;-)
[05:19] <mdz> but we do need to set a cutoff
[05:19] <zul> i think fabbione is doing one more upload for some security fixes and the snd_via82xx patch as well
[05:40] <jbailey> mdz: Jordi and I are looking at the new instance of 1440 as we speak.
[05:41] <mdz> jbailey: jordi has hardware which exhibits the problem?
[05:41] <jordi> plop!
[05:41] <mdz> speaking of the jordevil...
[05:41] <jbailey> 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] <jbailey> We're just about to try a nightly from a couple days ago.
[05:42] <jordi> jbailey: ok, dmesg sent.
[05:42] <jordi> jbailey: should I wipe it and install the nightly now?
[05:43] <jbailey> I think if you get as far as wiping it that you don't have the problem from what I understand.
[05:43] <jbailey> 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] <jordi> nod, ie, I should just check that d-i likes the cd
[05:43] <jordi> jbailey: good idea.
[05:43] <jbailey> Yup, please.  It's a quick enough test.
[05:45] <jordi> scsi1 : ata_piix
[05:46] <jordi> piix 0wnz the cd drives and they work
[05:46] <jordi> kernel 2.6.10-5-386
[05:46] <jordi> inside the daily d-i system. it looks good
[05:46] <jbailey> Luvly.  Do you have the other CD burned?
[05:47] <jordi> array6 and the daily, which is what I just booted.
[05:47] <jbailey> Ugh.
[05:47] <jbailey> So I wonder what's different?
[05:47] <jordi> I haven't tried with the 386 image on the installed system yet.
[05:47] <jbailey> No, that should be enough.
[05:47] <jbailey> It's not happening on your hardware then. =(  You have matching PCI id's though.
[05:48] <jordi> 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] <jordi> nod
[05:48] <jbailey> jordi: Between you and the original reporter.
[05:48] <jordi> it does happen with debian's 2.6.8 though.
[05:48] <jordi> AFAIK, not with Debian's 2.6.10.
[05:48] <jbailey> Right, we've got a patch in our kernel to tell it to cope.
[05:48] <jordi> I wonder if it's in debian too
[05:50] <mdz> so jordi has the right PCI IDs but can't reproduce the bug?
[05:50] <jordi> apparently
[05:50] <mdz> gaah
[05:51] <jordi> is there any /proc bit that I can send to you guys that gives you more info about my ide stuff?
[05:52] <zul> lunch time
[05:52] <mdz> jordi: lspci -v, I supopse
[05:52] <mdz> suppose
[05:53] <jordi> k
[05:59] <mdz> fabbione: we are going to need to freeze the BOF list now; I am making the schedule
[05:59] <mdz> I'll add a note to the page
[05:59] <mdz> actually it already says "do not edit", only I mean it now ;-)
[06:00] <jordi> jbailey: sent lspci
[06:28] <jordi> jbailey!
[06:31] <jbailey> jordi: Heya!
[06:31] <jordi> jbailey: anything else?
[06:31] <jordi> got lspci?
[06:31] <jbailey> I did thanks.
[06:31] <jordi> ok
[06:32] <jbailey> 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] <jordi> ok
[06:37] <jordi> I'll be gone in a short while too.
[06:37] <jordi> And won't be back in office for a week.
[06:46] <fabbione> 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] <fabbione> and the only other thing is the via fix for you.
[06:47] <fabbione> let me check...
[06:47] <mdz> I will test the via fix shortly
[06:47] <fabbione> mdz: there is a very trivial bug fix (comment out one printk())
[06:47] <fabbione> and one change for d-i requested by Mithandir and KAmion (7800)
[06:48] <fabbione> 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] <fabbione> zul: btw.. we need to talk about a couple of things when you have time
[06:50] <fabbione> mdz: all of the above (excluding the via thing) has been already tested and verified
[06:55] <fabbione> 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] <zul> fabbione: sure now would be good
[06:56] <fabbione> zul: i did merge from you the via patches... 
[06:56] <fabbione> 3 things:
[06:56] <fabbione> 1) check that the patch actually applies. the DPATCH header was broken
[06:56] <zul> yeah i realized that last night and i didnt check it in
[06:56] <fabbione> 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] <zul> ok
[06:57] <fabbione> 3) please try to follow the same rules for the changelog
[06:57] <fabbione> Example:
[06:57] <fabbione> * Fix foo bar in driver X:
[06:57] <fabbione>   - Add patch <fullpatchname>.dpatch.
[06:57] <fabbione> writing the way you do imho is redundant
[06:58] <zul> ok will do in the future
[06:58] <fabbione> * Added patch foobar to fix X.
[06:58] <fabbione>   - Add patch blabla
[06:58] <fabbione> see? :)
[06:58] <zul> :)
[06:59] <fabbione> btw.. it's just that i am farly anal on the changelog :-)
[06:59] <zul> heh i noticed :)
[06:59] <fabbione> because a good changelog is a big help to track down stuff
[07:00] <zul> i always did it a different way in gentoo
[07:00] <fabbione> that's something i learned from the good branden robinson
[07:01] <zul> so are you going to upload -30 today?
[07:02] <fabbione> i am waiting for mdz to confirm that it fixes the bug
[07:02] <zul> ah
[07:02] <fabbione> but we also have 2 security things without patch yet
[07:02] <fabbione> so if i upload today there will be for sure another upload
[07:03] <fabbione> what scares me is the possibility of an ABI change....
[07:03] <fabbione> that's why i am slightly more happy to wait and see
[07:04] <T-Bone> ola
[07:06] <T-Bone> fabbione: ah ok thx for the hint. Anything special the CurrentlyBuilding file should contain?
[07:06] <fabbione> T-Bone: yes. but don't bother for now. 
[07:06] <fabbione> it's not worth the pain
[07:06] <T-Bone> well
[07:07] <T-Bone> speeding up the kernel build would be quite a gain
[07:07] <fabbione> T-Bone: just touch the file for now...
[07:07] <T-Bone> ah ok
[07:07] <T-Bone> cool
[07:07] <fabbione> it really depends on how you created the chroot
[07:08] <T-Bone> debootstrap
[07:08] <fabbione> did you use the buildd version?
[07:08] <T-Bone> yeah
[07:08] <fabbione> s/version/variant?
[07:08] <fabbione> well just touch that file for now...
[07:08] <T-Bone> done
[07:08] <T-Bone> though i suppose it'll only work for next build?
[07:09] <fabbione> yeps and only for the kernel
[07:09] <T-Bone> ok
[07:09] <fabbione> no other packages makes use of it for that
[07:09] <T-Bone> ok
[07:09] <fabbione> otherwise you can still mark the kernel as "Not-for-US"
[07:09] <fabbione> and build it manually
[07:09] <T-Bone> well, next time ones upload a kernel, it'll build faster on hppa :)
[07:09] <T-Bone> i'd rather have it mostly automated
[07:16] <fabbione> mdz: i am off for dinner.. i will be back pretty soon
[07:22] <lamont> fabbione: kernel build is using /CurrentlyBuilding????
[07:23] <lamont> given that it only exists in the data center, and would therefore be an FTBFS if such source were shipped, yeah...
[07:23] <lamont> I'd hate to have to file an ftbfs bug against the kernel...
[07:24] <T-Bone> actually it's not exactly that
[07:24] <T-Bone> fabbione told me that the build process would use concurrency *only* if that file existed
[07:25] <lamont> fabbione: no abi change on hppa
[07:25] <lamont> ah, I suppose that's OK
[07:26] <lamont> but it still feels wrong
[07:46] <fabbione> 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] <lamont> fabbione: and we check because we don't want builds to go fast outside the data center???
[07:47] <fabbione> lamont: the use of -j is quite delicate
[07:47] <lamont> heh
[07:47] <fabbione> people might have SMP and don't want the kernel compilation to fork and blabla
[07:47] <fabbione> that's why there is a line debian/rules to override what is autodetected
[07:47] <lamont> right
[07:48] <fabbione> # DO NOT UNCOMMENT THIS LINE WITHOUT READING make-kpkg man page.
[07:48] <fabbione> # export CONCURRENCY_LEVEL := 15
[07:48] <fabbione> and later:
[07:48] <fabbione>                 if [ -e /CurrentlyBuilding ]  && [ -z "$(CONCURRENCY_LEVEL)" ] ; then \
[07:49] <fabbione> so basically the check of CurrentlyBuilding is harmless
[07:49] <fabbione> it will never produce a FTBFS
[07:50] <lamont> fabbione: nonetheless, I find myself reminded of the 'if [ $(uid -un) = "buildd" ] " in oo.o
[07:50] <fabbione> yeah i remember that :-)))
[07:51] <fabbione> but does exist a more clean way to know if we are in a DC buildd?
[07:51] <lamont> no
[07:51] <fabbione> the "feature" doesn't kill other buildds or stop producing _all.deb packages..
[07:51] <lamont> probably because we didn't design one in
[07:51] <fabbione> that's why i was comfortable to use it
[07:51] <lamont> yeah, yeah.  I understand.  it just makes me a little sick
[07:52] <fabbione> yes and i understand your point :-)
[07:52] <fabbione> i recog is a hack...
[07:52] <zul> heh ubuntu actualy made slashdot
[07:52] <fabbione> for the worst kernel?
[07:52] <dilinger> for being created by a single person?  (mako)
[07:52] <T-Bone> fabbione: if you're running as uid 'buildd', i guess you can reasonnably assume that concurrency is *wanted*
[07:52] <zul> nah...userlinux and ubuntu 
[07:53] <fabbione> T-Bone: i run my buildd as sparcbuildd user...
[07:53] <T-Bone> tssks
[07:53] <T-Bone> ;)
[07:53] <T-Bone> if /buildd/ then (perlish) :)
[07:54] <kylem> didn't your mother tell you slashdot rots your brain?
[07:55] <fabbione> kylem: ahaha
[07:55] <zul> kylem: yes slashdot bad mmkay?
[07:56] <lamont> T-Bone: checking user id in the build will get you hurt
[07:57] <kylem> oh piss. i didn't know about CONCURRENCY_LEVEL
[07:57] <fabbione> kylem: CONCURRENCY_LEVEL + ccache + distcc > *
[07:57] <kylem> fabbione, it takes me 7 hours to build the debian hppa images, heh.
[07:58] <kylem> and that's on a /fast/ machine with gobs of ram.
[07:58] <fabbione> kylem: wel... you know what i did?
[07:58] <fabbione> i just RTFM :)
[07:58] <kylem> ;-)
[07:58] <fabbione> sorry.. i couldn't resist
[07:59] <T-Bone> oh behave 8)
[07:59] <zul> oh hey T-Bone 
[07:59] <fabbione> kylem: /topic
[07:59] <fabbione>  http://www.vijaygill.com/pics/stfu.gif <-
[07:59] <fabbione> meh ^^T-Bone
[07:59] <zul> fabbione: yeah showed that to a bunch of people you got me into trouble
[07:59] <kylem> :)
[07:59] <fabbione> zul: how? ;)
[08:00] <zul> fabbione: bastard!
[08:00] <T-Bone> fabbione: i knew that one :)
[08:01] <lamont> fabbione: in case you haven't noticed, I'm still getting to the meeting announcement
[08:01] <lamont> likewise the kernel stuff you sent me last night
[08:02] <fabbione> lamont: i did the security stuff today
[08:02] <lamont> thansk
[08:02] <fabbione> lamont: usually if i see you don't manage across my night, i do the morning after :-)
[08:02] <fabbione> it's just that i didn't feel very happy to start security at 8pm
[08:02] <fabbione> mdz: if you want -30 out today, can you please test the via fix?
[08:02] <lamont> heh
[08:03] <mdz> fabbione: I will
[08:03] <fabbione> http://www.vijaygill.com/pics/give_a_damn_progress.gif
[08:03] <fabbione> ahahha
[08:03] <lamont> glad I said something before digging into it
[08:03] <fabbione> lamont: do always a baz update :-)
[08:03] <mdz> I need about 10 minutes to finish what I am doing before I shut down and reboot
[08:03] <fabbione> that's how i know if it has been done or not ;)
[08:03] <fabbione> mdz: ok thanks
[08:03] <mdz> it is my primary desktop which has the issue
[08:03] <fabbione> roger that
[08:04] <fabbione> (btw some pics on that website are really NOT nice)
[08:04] <lamont> fabbione: "done" != "in progress", fwiw
[08:05] <mdz> fabbione: hmm, forgot we had a kubuntu meeting scheduled for right now; it will have to wait until after
[08:05] <fabbione> mdz: ok.. i might not be online, but everything is committed to baz
[08:05] <mdz> fabbione: can someone else do the upload?
[08:06] <fabbione> mdz: sure.. lamont can.. otherwise i can do it tomorrow morning
[08:06] <mdz> fabbione: also another meeting in one hour
[08:06] <fabbione> 12 hours won't make any difference
[08:06] <mdz> depending on how long the kubuntu meeting runs, I may not have time until after lunch
[08:06] <fabbione> mdz: did i miss any meeting call?
[08:06] <mdz> fabbione: no
[08:06] <fabbione> ok
[08:07] <fabbione> mdz: anyway i wouldn't panic too much. i am pretty sure there will be another upload of the kernel before release
[08:07] <fabbione> (if not 2)
[08:08] <lamont> fabbione: but this time, lets do the final upload at least 24 hours before release, eh>?
[08:09] <fabbione> lamont: it's not up to me :(
[08:09] <fabbione> we don't even have patches for a public security issue....
[08:09] <fabbione> becuase there is none
[08:09] <mdz> we should freeze the kernel this week
[08:09] <mdz> for the RC
[08:09] <fabbione> mdz: RC can go with -29
[08:10] <lamont> fabbione: RC means RELEASE CANDIDATE
[08:10] <fabbione> or -30
[08:10] <lamont> not 'mostly release candidate'
[08:10] <fabbione> lamont: yes.. i know that :-)
[08:10] <lamont> once you plan to replace something in the build, it's no longer release candidiate
[08:10] <mdz> 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] <lamont> 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] <fabbione> mdz: ok.. just take your time
[08:11] <fabbione> lamont: yes i get that. but if i upload -30 now or tomorrow morning, it will still make it for RC
[08:12] <fabbione> the relevant changes are only the security stuff and the via fix
[08:12] <fabbione> if the via fix is go now
[08:12] <fabbione> than it's all done
[08:12] <fabbione> we only need Kamion to upload a new d-i to build on top of the new kernel
[08:12] <fabbione> end of the story
[08:13] <fabbione> i am sure we can manage easily :-)
[08:17] <lamont> are there actual d-i changes, or just needs a new daily-build?
[08:18] <fabbione> lamont: just a rebuild like the daily
[08:19] <fabbione> no changes are required
[08:27] <fabbione> T-Bone: tell jbailey :)
[08:27] <T-Bone> hehe
[08:31] <lamont> T-Bone: s/deb$/deb in binary-arch target/
[08:31] <T-Bone> true
[08:31] <T-Bone> hmm

[08:31] <T-Bone> fabbione: gah, your trick seems not to work
[08:31] <T-Bone> binutils_2.15-5ubuntu2: not registered yet.
[08:31] <T-Bone> :(
[08:32] <lamont> 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] <T-Bone> ?
[08:32] <fabbione> T-Bone: i get that warning too once in a while
[08:32] <fabbione> afaik it's harmless
[08:33] <lamont> fabbione: is error
[08:33] <lamont> at least on take
[08:33] <lamont> --take
[08:33] <T-Bone> fabbione: afaict, it discarded all other packages sent to the line
[08:33] <fabbione> lamont: hmm i get that when i mark a package in Uploaded
[08:33] <T-Bone> lamont: that's on -u
[08:33] <lamont> well, it's an error it'll abort processing
[08:33] <T-Bone> gosh --merge-* is taking ages
[08:34] <lamont> and you get it because w-b doesn't know about that version of the package
[08:34] <lamont> yeah
[08:34] <fabbione> lamont: but w-b gave me that version :-)
[08:34] <T-Bone> lamont: which is rather stange given w-b gave that package to buildd...
[08:34] <T-Bone> as fabbione said :)
[08:34] <fabbione> exactly
[08:34] <lamont> actually, takes next to no time for me... but I don't have universe.....
[08:35] <lamont> interesting
[08:35] <T-Bone> lamont: i call that a bug, but that's my 2cents ;)
[08:35] <lamont> T-Bone: the DC does it every 30 min, x5 architectures
[08:35] <T-Bone> well
[08:36] <T-Bone> either having a flat archive makes things awfully slow
[08:36] <fabbione> ah we might have a fix for the av_dc thingy that sucks 100% of the CPU
[08:36] <T-Bone> or you have hell of machines
[08:36] <T-Bone> it's been running for 8+ minutes here already
[08:36] <T-Bone> truth told it's the first time it's that long
[08:36] <T-Bone> i wonder if i have fucked up something
[08:37] <T-Bone> i should have run it -v
[08:37] <fabbione> ah hell.. the patch is big
[08:37] <zul> yay!
[08:37] <zul> heh
[08:38] <T-Bone> lamont: any reason why w-b doesn't publish its stats, btw?
[08:38] <lamont> ?
[08:38] <T-Bone> $web_stats = "/home/buildd/public_html/buildd/stats.txt";
[08:38] <zul> fabbione: i saw that it hasnt been proven though
[08:38] <T-Bone> lamont: ^^
[08:38] <T-Bone> lamont: that file isn't created
[08:39] <fabbione> zul: the patch is clean, but it changes the ABI afaict
[08:39] <zul> fabbione: heh..
[08:39] <lamont> T-Bone: have you run do-merge-quinn?
[08:39] <T-Bone> no
[08:39] <T-Bone> it's currently deadlocking on a --failed
[08:39] <lamont> well, that's the only file that references $web_stats....
[08:39] <T-Bone> afaict
[08:40] <T-Bone> err
[08:40] <T-Bone> do-merge-quinn != w-b --merge-quinn?
[08:40] <lamont> nope
[08:40] <lamont> t
[08:40] <lamont> it's yet more cruft that we don't care about
[08:40] <T-Bone> erf
[08:40] <zul> fabbione: i say hoary+1 for it
[08:41] <fabbione> zul: let me check something
[08:41] <fabbione> i want to see if it is upstream
[08:41] <zul> i already did and i believe it isnt
[08:41] <fabbione> 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] <zul> i can do it if you want
[08:42] <fabbione> that would be neat
[08:42] <fabbione> he uses 686-smp
[08:42] <zul> ok ill throw one together right now
[08:42] <fabbione> ok great
[08:43] <T-Bone> fabbione: interestingly enough if you pass only 1 changes file to -u at a time, there's no error
[08:43] <fabbione> T-Bone: hmm possibly
[08:44] <T-Bone> seems to be
[08:45] <zul> fabbione, just the scsi stuff no 3com or acpi in that patch correct?
[08:47] <fabbione> zul: one sec...
[08:47] <T-Bone> wow
[08:47] <T-Bone> seems that touching the file during the build made it work anyway
[08:47] <T-Bone> cool
[08:49] <fabbione> zul: we mostlikely have the acpi changes already. worth to check anyway
[08:49] <zul> k
[08:49] <fabbione> mjg59: ping?
[08:50] <fabbione> 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] <zul> they are broken with suspend resume
[08:50] <fabbione> zul: skip the generic scsi stuff and push him only the ahc driver changes
[08:51] <zul> ok 
[08:51] <fabbione> we should ask mjg59 if the patch looks sane
[08:51] <fabbione> plus i have a 3com to test on
[08:51] <zul> but the generic scsi stuff contain some CONFIG_PM stuff
[08:51] <fabbione> yes htat is correct, but that's a more intrusive change
[08:52] <zul> ok
[08:52] <fabbione> it's the driver we really care about
[08:52] <zul> i understand
[08:52] <fabbione> i am ok to fix a driver, but not to change an entire subsystem
[08:53] <fabbione> + the scsi change is an ABI change
[08:53] <fabbione> it adds 4 more functions around
[08:53] <fabbione> atleast it looks like
[08:53] <T-Bone> lamont: btw, do you want to be posted about the kind of message i've mailed you?
[08:55] <fabbione> zul: apparently none of the changes in the driver require the changes to the scsi layer
[08:55] <fabbione> and they shouldn't change the ABI afaict
[08:55] <zul> ah ok...i made the patch starting it right now
[08:55] <fabbione> all the changes are confined inside the module
[08:56] <fabbione> let me check an extra thing...
[08:56] <fabbione> -
[08:56] <zul> 686-smp
[08:57] <lamont> topic changed in #ubuntu-meeting, guess I should email kernel-team, eh>?
[08:57] <lamont> T-Bone: kdelibs has no love quite yet, in my mirrror
[08:57] <lamont> but it will soon
[08:57] <T-Bone> kdelibs is in main?
[08:58] <fabbione> lamont: ehhe
[08:58] <T-Bone> lamont: no need, it'll be built here
[08:58] <T-Bone> just rsync it when it's there
[08:58] <lamont> kdelibs is in main
[08:58] <T-Bone> urg
[08:58] <lamont> T-Bone: quicker to just build it here...
[08:58] <lamont> since the source is already here, I think
[08:58] <fabbione> zul: yes.. all the changes are confined inside the modules. in any case the modules seem not to depend on each other. that means that we are ok with it
[08:59] <lamont> fabbione: you saw that -29's hppa is no change from -28 (abi), right?
[08:59] <T-Bone> lamont: well, much slower to upload from your place :P
[08:59] <fabbione> lamont: yeps.. the abi files for hppa are there already
[09:00] <lamont> T-Bone: yeah. and equally slow to upload
[09:00] <lamont> s/up/down/.
[09:00] <zul> fabbione: that is what im going with http://zulinux.homelinux.net/ubuntu/kernel/aic7xx-sleep.dpatch 
[09:00] <T-Bone> lamont: if you don't need it you don't have to download it, otoh :)
[09:00] <fabbione> zul: looks sane
[09:01] <zul> nifty...building now
[09:01] <T-Bone> lamont: just for you http://archive.slashdirt.org/incoming/
[09:01] <T-Bone> that's the unsigned archive
[09:01] <zul> should take about 45 minutes for it to build since i removed everything except for 686-smp
[09:02] <T-Bone> lamont: rsync'able at rsync://rsync.slashdirt.org/incoming
[09:02] <fabbione> zul: no ccache?
[09:02] <zul> nope
[09:02] <fabbione> zul: time to install it...
[09:02] <fabbione> it's easy and very fast
[09:02] <zul> i know cc=ccache gcc
[09:03] <zul> or something ;)
[09:03] <fabbione> zul: even simpler than that
[09:03] <zul> eh?
[09:03] <fabbione> if [ -d /usr/lib/ccache ] ; then
[09:03] <fabbione>     export PATH=/usr/lib/ccache:"${PATH}"
[09:03] <fabbione>     export CCACHE_DIR=/usr/src/.ccache
[09:03] <fabbione>     export CCACHE_NLEVELS=8
[09:03] <fabbione> fi
[09:03] <fabbione> given that you want your ccache in /usr/src/.ccache
[09:04] <fabbione> ccache -s to see the stats
[09:04] <fabbione> ccache to see what you can configure
[09:04] <zul> hmmm...ill have to try that tonight
[09:04] <fabbione> i use that in my .bashrc
[09:04] <fabbione> so it is always there and i don't need to bother
[09:04] <fabbione> just make sure that .ccache is somewhere on a fast disk :-)
[09:05] <fabbione> the first time you will not notice any difference
[09:05] <zul> .ccache can be in your home directory correct?
[09:05] <fabbione> but check the build time the second run :-)
[09:05] <fabbione> zul: it can be everywhere
[09:05] <fabbione> it's just a VAR you set
[09:05] <fabbione> for me ~ would be a loss
[09:05] <fabbione> since it's nfs shared.. so i prefer local disk
[09:06] <zul> its not nfs shared for me though so no biggy
[09:06] <zul> bzImage is ready
[09:07] <T-Bone> fabbione: ccache wants loads of diskspace/mem, right?
[09:08] <fabbione> nop
[09:08] <fabbione> only a bit of diskspace that you can configure
[09:08] <T-Bone> i wonder if it'd be quite a gain on a buildd
[09:08] <T-Bone> honestly i doubt it
[09:09] <fabbione> to be a real gain on a buildd the ccache storage must be big
[09:10] <T-Bone> i guess so
[09:10] <T-Bone> currently i can't afford it
[09:10] <fabbione> but for example vlc takes 1:30 hours to build on sparc without ccache
[09:10] <fabbione> ccached less than 20 minutes
[09:10] <T-Bone> that'll cahnge once i'll get my hands on the disk arrays that are coming my way :)
[09:10] <fabbione> make your numbers...
[09:10] <T-Bone> doh
[09:10] <T-Bone> how can that be?
[09:11] <fabbione> because ccache stores the objects on the disk at the first compilation and re-use them at the second run?
[09:11] <fabbione> catching all the changes?
[09:11] <fabbione> and recompiling only what is really needed?
[09:12] <T-Bone> err
[09:12] <fabbione> a lookup is faster than recompiling the entire code ;)
[09:12] <T-Bone> sure
[09:12] <T-Bone> but it's only useful upon consecutive builds. ie: for it to be worthwhile on a buildd, it'd have to cache the *entire archive's objects*
[09:12] <T-Bone> something so big I'd rather don't know how big it is :)
[09:13] <fabbione> T-Bone: that's why i wrote that you need a big cache in a buildd
[09:13] <T-Bone> heh
[09:13] <fabbione> but take into account that you have some limitations
[09:13] <T-Bone> eg?
[09:13] <fabbione> each time libc or gcc gets updated the entire ccache becomes garbage
[09:14] <T-Bone> yum
[09:14] <fabbione> so it is pointless to make the cache too big to contain everything
[09:14] <fabbione> + you will notice that some huge packages like X that takes like 5GB of disk to build, only uses a few hundred Megs of ccache
[09:15] <fabbione> even the kernel is ccache is like 100MB or something
[09:15] <fabbione> T-Bone: because X builds heaps load of extra crap, twice and non-cacheable?
[09:15] <fabbione> like spending litteraly hours processing fonts in perl?
[09:16] <T-Bone> schweet
[09:21] <lamont> ccache -F 2000000 -M 100.0G
[09:21] <lamont> that's what the buildd's in the DC (that can handle it) have
[09:21] <lamont> the others use somewhat less - only 10GB of cache
[09:21] <fabbione> yeah.. except that my sparc buildd is struggling with 2,5GB of ccache
[09:21] <lamont> roughly 20% of the available disk space
[09:21] <fabbione> lamont: why do you force -F ?
[09:22] <zul> whee...buuilding scsi modules
[09:22] <fabbione> there is no limit to file nums by default..
[09:22] <lamont> files in cache                    224153
[09:22] <lamont> cache size                           8.7 Gbytes
[09:22] <lamont> max files                        2000000
[09:22] <lamont> max cache size                      10.0 Gbytes
[09:22] <lamont> that's on my hppa machine
[09:22] <lamont> fabbione: because the default is way too small :-)
[09:22] <fabbione> if i don't set -F i don't have max files at all
[09:23] <lamont> hrm.. ISTR that wasn't always the case... dunno
[09:23] <fabbione> i really have no idea :-)
[09:23] <fabbione> but i remember only setting the size
[09:24] <fabbione> ehhehe
[09:24] <fabbione> you all suck
[09:25] <T-Bone> sure :)
[09:25] <fabbione> i need an external SCSI disk array for my sparc
[09:25] <fabbione> and i did get none
[09:25] <T-Bone> i can give you a pile of 4GB disks ;)
[09:25] <fabbione> T-Bone: i don't really care the size of the HD
[09:25] <T-Bone> you'll have to build the array by yourself, tho :)
[09:25] <fabbione> do they have an external disk array?
[09:25] <T-Bone> alas no
[09:25] <fabbione> ok
[09:25] <fabbione> that sucks
[09:26] <T-Bone> these are raw IBM scsi disks
[09:27] <T-Bone> if they had an array, i'd have used them :)
[09:27] <fabbione> http://www.anysystem.com/storedge-t3-660gb.html
[09:27] <fabbione> something like this would do
[09:27] <fabbione> :)
[09:28] <T-Bone> wow
[09:28] <T-Bone> that's kinda cool indeed :)
[09:28] <fabbione> yeah
[09:28] <fabbione> i think i can host both differential and non differential scsi stuff
[09:28] <fabbione> but i can't remember what is the default in my sparc
[09:29] <fabbione> in the worst case i have a scsi controller hanging somewhere in a box.. and i am sure it is differential
[09:29] <fabbione> and.. actually....
[09:29] <fabbione> hmmmm
[09:29] <fabbione> it's an ADAPTEC!
[09:29] <fabbione> i wonder if the ahc_dv process starts without any device connected....
[09:29] <T-Bone> lol
[09:31] <T-Bone> i wonder what that bitch has been doing all the time then :)
[09:31] <fabbione> ok i am off for the evening
[09:31] <fabbione> lamont, mdz: please drop me a mail if you are going to upload -30 or you want me to do it tomorrow when i wake up
[09:31] <zul> fabbione: ok ill put the .ko on my webpage for the users to test
[09:31] <fabbione> zul: fine by me
[09:32] <zul> and if they are ok ill put it in my archive or you can just grap the copy on the page as well
[09:32] <fabbione> ok thanks
[09:32] <fabbione> zul: make my life simpler.. merge from branch so that i can easily merge from you
[09:33] <zul> pl
[09:33] <zul> doh..ok
[09:33] <fabbione> all this merging is a bit work of work for everybody, but it makes everything simpler at the end
[09:33] <fabbione> good night everybody
[09:33] <zul> night
[09:33] <zul> whee...its linking now
[09:35] <T-Bone> kylem: Finished at 20050323-2132
[09:35] <T-Bone> Build needed 05:23:49, 909288k disk space
[09:35] <T-Bone> that was linux-source
[09:35] <kylem> hate you so much. :)
[09:36] <kylem> i need to compare our .config
[09:36] <T-Bone> ;)
[09:36] <T-Bone> i told you I/O were *fast* on that machine :)
[09:36] <kylem> i just started build-64-smp
[09:37] <T-Bone> you just can't fight :)
[09:37] <T-Bone> kylem: they'll be available soon at the incoming URL i posted before
[09:37] <kylem> i think my /home disk is only FAST-20 for some reason.
[09:38] <kylem> T-Bone, heh, mine is a dual 550MHz too...
[09:38] <T-Bone> here it's FAST-20 WIDE 40MB/s
[09:38] <T-Bone> two 9GB disks. RAID-0, XFS
[09:38] <T-Bone> and it's dual 440MHz
[09:39] <T-Bone> so you *really* suck 8)
[09:39] <T-Bone> and most of the build happened single threaded too :)
[09:40] <T-Bone> err
[09:40] <T-Bone> i can't believe there's been *yet another glibc upload today*
[09:41] <T-Bone> sigh
[09:41] <zul> yay ers use somewhat less - only 10GB of cache
[09:41] <zul> fabbione yeah.. except that my sparc buildd is struggling with 2,5GB of ccache
[09:41] <zul> lamont roughly 20% of the available disk space
[09:41] <zul> doh..
[09:41] <kylem> T-Bone, my build is entirely single threaded.
[09:42] <mjg59> fabbione: Yo?
[09:42] <jbailey> T-Bone: Careful.  It's the fact that I did the source build on glibc that caused the need for the second upload...
[09:42] <T-Bone> glibc takes about 3h to build. I wonder why it's not "-j" enabled
[09:42] <jbailey> err.
[09:42] <jbailey> ia64, I mean.
[09:42] <jbailey> T-Bone: It is.
[09:43] <T-Bone> /usr/bin/make -C build-tree/hppa-libc -j 1 2>&1 | tee -a /bu
[09:43] <T-Bone> jbailey: "-j1" heh? :)
[09:43] <T-Bone> how threaded is that?
[09:43] <T-Bone> ;)
[09:45] <jbailey> NJOBS:=$(shell getconf _NPROCESSORS_ONLN 2>/dev/null || echo 1)
[09:45] <T-Bone> jbailey: next time you do a glibc upload, remove the arch indep files from binary arch :)
[09:46] <T-Bone> ~$ getconf _NPROCESSORS_ONLN
[09:46] <T-Bone> 2
[09:46] <jbailey> Then trace the setup in your chroot or something.
[09:46] <T-Bone> $ sudo chroot-hoary getconf  _NPROCESSORS_ONLN
[09:46] <T-Bone> sudo: chroot-hoary: command not found
[09:46] <T-Bone> err
[09:46] <T-Bone> my bad
[09:46] <T-Bone> $ sudo chroot chroot-hoary getconf  _NPROCESSORS_ONLN
[09:46] <T-Bone> 2
[09:47] <T-Bone> with 2 online CPUs, i can lart you in parallel :)
[09:48] <zul> right i have to go move furniture back tonight
[09:48] <jbailey> T-Bone: *lol*
[09:48] <jbailey> T-Bone: So why is it detecting only one processor for you? =)
[09:48] <T-Bone> jbailey: building glibc was threaded on warty chroot, so something's fucked up
[09:49] <T-Bone> jbailey: if you want to look at the ongoing build log to figure out: http://buildd.slashdirt.org/logs/glibc_2.3.2.ds1-20ubuntu12_20050323-2133
[09:49] <jbailey> There's nothing a build log would tell me - It's all what variables are set when.
[09:50] <T-Bone> well
[09:50] <T-Bone> # How many makes to run at once?
[09:50] <T-Bone> NJOBS = 1
[09:50] <T-Bone> from glibc-2.3.2.ds1/debian/rules
[09:51] <T-Bone> i guess that answers the question?
[09:51] <jbailey> T-Bone: Right, but the various things from debian/sysdeps are pulled in after that.
[09:51] <jbailey> NJOBS has to have a default, since we can't use this getconf on non-Linux
[09:51] <jbailey> If you look in sysdeps/linux.mk, you'll see the detection code.
[09:52] <T-Bone> NJOBS:=$(shell getconf _NPROCESSORS_ONLN 2>/dev/null || echo 1)
[09:52] <T-Bone> ifeq ($(NJOBS),-1)
[09:52] <T-Bone>  NJOBS:=1
[09:52] <T-Bone> endif
[09:52] <T-Bone> ifeq ($(NJOBS),0)
[09:52] <T-Bone>  NJOBS=1
[09:52] <T-Bone> endif
[09:52] <T-Bone> NJOBS:=1
[09:52] <T-Bone> somehow i have the feeling that this is *utterly* stupid :)
[09:52] <T-Bone> note the ending "NJOBS:=1"
[09:53] <T-Bone> jbailey: i guess *that* answers the question :)
[09:53] <jbailey> wtf?
[09:53] <kylem> get shuttleworth to buy a superdome and just run make -j ;-)
[09:53] <T-Bone> kylem: lol
[09:53] <lamont> T-Bone: you do have /proc mounted in the chroot, yes?
[09:53] <lamont> (and /dev/pts)
[09:53] <T-Bone> jbailey: that's exactly what i'm asking you :)
[09:53] <T-Bone> lamont: yes
[09:53] <T-Bone> lamont: i just pointed that the build will never be threaded anywhere, no matter what
[09:54] <T-Bone> btw i'm doubtful about the "NJOBS=1" in the second if case
[09:54] <jbailey> T-Bone: Sure, but only -j 1 apparently. =)
[09:54] <jbailey> You mean if it comes back as 0?
[09:55] <jbailey> Given that you're unlikely to have 0 processors online and still succesfully execute the instruction, 1 seems like a safe fallback. =)
[09:55] <T-Bone> jbailey: i think it should be "NJOBS:=1" instead of "NJOBS=1" for consistency reason. But that's not the cause of what we're seeing
[09:56] <T-Bone> though i wonder if someone fucked up willing to change exactly what I just said, and wrote the change *outside* the if case
[09:56] <T-Bone> jbailey: so for ubuntu13, remove arch indep from binary arch target and GET IT TO BUILD THREADED, dammit :o)
[09:57] <jbailey> First I want to know why that NJOBS:=1 is in there.  I don't see a refernece to it in the changelog.
[09:57] <T-Bone> i'm pretty sure that's someone's local change that went into mainline :)
[09:57] <T-Bone> anyway, off for dinner, bbiab
[10:47] <T-Bone> gah
[10:47] <T-Bone> so you guys just uploaded glibc again :P
[10:48] <jbailey> Right with the bug fixed.
[10:48] <jbailey> Current build?
[10:49] <T-Bone> ubuntu12 on my builder
[10:50] <jbailey> ia64?
[10:50] <T-Bone> hppa
[10:50] <T-Bone> why would i build ia64?
[10:50] <jbailey>  thought you ran the autobuilder for it.
[10:50] <T-Bone> hell
[10:50] <T-Bone> no
[10:50] <T-Bone> it's in DC
[10:50] <jbailey> Is hppa a target for Breezy?
[10:50] <T-Bone> my business is hppa you see
[10:50] <T-Bone> i don't know
[10:50] <T-Bone> hppa is a target for me, that's a good beginning :)
[10:51] <jbailey> If it is, it's incentive for me to setup the hppa box here.
[10:51] <T-Bone> dude
[10:51] <T-Bone> have you been sleeping on this chan and #parisc lately?
[10:51] <T-Bone> ;P
[10:51] <jbailey> #parisc, yes.
[10:51] <T-Bone> we've discussed at length that topic on #parisc
[10:51] <jbailey> This channel?   Maybe. =)
[10:51] <T-Bone> it eventually gave birth to http://ubuntu-hppa.pateam.org/
[10:52] <T-Bone> (which is currently rather empty, but I'm trying to improve it as much as possible. Contribution welcome)
[10:53] <jbailey> I remember the Vancouver proposal coming up in #parisc, but it doesn't look like there's nay reason why it shouldn't be a full arch, so I didn't follow it after that.
[10:53] <T-Bone>    * debian/rules.d/control.mk: Mark debian/control target as phony.
[10:54] <T-Bone> that's supposed to fix the parallel build issue?
[10:54] <T-Bone> jbailey: then you haven't read your mails carefully enough
[10:54] <T-Bone> hppa is planed for removal from etch
[10:54] <jbailey> On what grounds?
[10:54] <T-Bone> not enough builders
[10:54] <T-Bone> not enough downloads
[10:54] <T-Bone> and all kind of crap alike
[10:55] <jbailey> Hmm, not enough downloads I can see, I guess.
[10:55] <jbailey> No, the issue wasn't parallel build, the issues was fubar depends from a race condition.
[10:55] <kylem> i think "not worth the release teams time"
[10:55] <T-Bone> jbailey: if you've looked at the requisite for an arch to be part of etch, you'd noticed that *only* i386 can make it
[10:55] <kylem> don't worry, if nobody else does, i will do stable releases for etch for hppa.
[10:55] <T-Bone> amd64 and ia64 have been "exempted" of a few prerequisites
[10:55] <jbailey> Since I did the original build on ia64, libc6-i686 depended on libc6.1 =)
[10:56] <T-Bone> jbailey: ok. So it will still build single threaded?
[10:56] <jbailey> T-Bone: Yes, dear.
[10:56] <T-Bone> schit
[10:56] <jbailey> T-Bone: The issue -j issue isn't important enough to have me risk breaking it when I don't know why the change went in in the first palce.
[10:56] <T-Bone> i can imagine
[10:57] <T-Bone> kylem: you're into self-inflicted pain, aren't you? :)
[10:57] <kylem> no.
[10:58] <T-Bone> doing QA release of etch looks much to me like you're in it, tho :)
[10:58] <kylem> meh.
[10:59] <jbailey> T-Bone: Perhaps it's inflicted by others. =)
[10:59] <kylem> jbailey, i don't work at all.
[10:59] <T-Bone> he's a darn student :)
[11:00] <jbailey> Ah, lucky.
[11:00] <kylem> not really. i work full time and get nothing out of it. :)
[11:00] <jbailey> I'm going to spend a bunch of this weekend on my universitiy stuff.  I'm so behind. =)
[11:00] <kylem> "work" rather.
[11:00] <jbailey> kylem: I'm doing my degree by distance ed, and wish I could afford to take the time off to go to school.
[11:01] <kylem> jbailey, *nod* i was thinking about finishing part time, but it would just take too long.
[11:11] <T-Bone> mv: cannot stat `chroot-hoary/build/buildd/linux-headers-2.6.10-5_2.6.10-29_hppa.deb': No such file or directory
[11:20] <mdz> the snd-via82xx change does not resolve my problem
[11:20] <mdz> well, not entirely
[11:20] <mdz> I don't seem to be getting the crash I was getting before, but that didn't always happen anyway
[11:21] <mdz> but it still behaves in the same way
[11:21] <T-Bone> Build daemon statistics from 19700101-0100 to 20050322-2050 (12864.83 days) <- must be the oldest buildd ever run ;)
[11:21] <mdz> when I play a sound, it repeats indefinitely
[11:21] <mdz> any information I should collect before I go back to irqpoll mode?
[11:23] <mdz> ok
[11:31] <T-Bone> ok ok
[11:31] <T-Bone> well, it's time for me to say goodbye
[11:32] <T-Bone> i'll have a quick look at the backlog tomorrow morning but then I won't be back until next wednesday. Will read email tomorrow until 1700 CET, then no net access. Vacation rulez! :)
[11:34] <mjg59> I need to go out - can someone point mdz at http://seclists.org/lists/linux-kernel/2005/Mar/6078.html ?