#ubuntu-kernel 2005-03-20 * #ubuntu-kernel [freenode-info] help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup <fabbione> anybody alive? * fabbione sighs <fabbione> guy the enable-inotify patch is kinda of horrible <fabbione> it would have been enough to modify the inotify-*-optional patch <fabbione> instead of adding a 3rd one on top <fabbione> YAYAYAAYYA <fabbione> inotify doesn't crash anymore! <fabbione> it will be in 2.6.10-26 and no ABI change :P <fabbione> FUCK NO <fabbione> it crashed on the second removal <fabbione> hmmmm <zul> hey <fabbione> hey zul <zul> hey fabbione how is it going? <fabbione> good and bad <zul> oh? <fabbione> i merged inotify 0.20 from 2.6.11-3 into 2.6.10 <zul> and? <fabbione> and i managed to unplug my usb device without crashing the kernel once <fabbione> it dies the second time <zul> lol <zul> i think we should take out rml <fabbione> now i am cleaning up the patch mess from inotify-*-optional and enable-inotify <fabbione> so that there is one good patch <fabbione> and that's it <zul> good <fabbione> and leave inotify disabled by default <zul> ill have to see the patch once its done so i know what to do next time if this pops up again <fabbione> well it's pretty simple <zul> did you get the inode error when compiling? <fabbione> see the original inotify patch <fabbione> it changes the dnotify entries in fsnotify entries <fabbione> zul: no but that's becaused i used a more recent patch and the error is easily fixable <zul> yeah <fabbione> parse the calls to fsnotify to see what are the inotify_ calls <fabbione> that leads to 5 functions <fabbione> inotify_inode_queue_event <fabbione> inotify_dentry_parent_queue_event <fabbione> inotify_inode_is_dead <fabbione> inotify_super_block_umount <fabbione> inotify_get_cookie <fabbione> so basically inside inotify.c in these 5 functs <fabbione> you add the check <fabbione> if (!inotify) <fabbione> return; <zul> ah ok <zul> so no need to push my inotify stuff to you in the next patchset from me <fabbione> nope <fabbione> i am going to commit it to baz in a few minutes <fabbione> i only need to do a test build <fabbione> and see if it works as expected <zul> btw when do you want my stuff by <fabbione> asap? <zul> sure <zul> i can put them up when i get home tonight am at work right now <fabbione> ok <fabbione> we are not going to upload today <fabbione> preview release is still ongoing <zul> yeah thats what i thought <zul> alsa is messing some people up when they upgrade because of the alsa driver for their winmodem <fabbione> i know... <fabbione> atleast <fabbione> i heard <zul> heh its the kamion kult <lamont> zul: the question is, does alsa provide a working modem then?? <zul> lamont: i think i dont have a modem havent had one in the past 10 years :) <lamont> ah sure you do... it's just not plugged into a phone line... any semi-modern laptop will do... :-) <zul> if i had a phone line...i just have a cell phone <lamont> ah,opk * lamont can accept that. :-) <zul> i like making things dificult for you lamont :) * lamont throws things <fabbione> there are serial cables for cell phones <lamont> fabbione: if you can tell me how to make the DKU-5 work with linux and my nokia phone, I will buy you _3_ beers <lamont> (no linux driver last I knew) <fabbione> i have an ericsson phone that has an internal modem <fabbione> i just plug the serial cable and do ATZ <lamont> DKU-5 is a usb cable <lamont> and vendor id isn't recognized. <lamont> OTOH, the last time I tried was 2.6.8 timeframe... <fabbione> hmmm <fabbione> i have the usb version too <fabbione> and i see the cell phone as a usb-serial <fabbione> same story.. minicom -> ATZ * lamont will play with his phone today <zul> *sigh* why do people have to use cheap kvm switches <lamont> zul: because they're _poor_, of course. <zul> heh...duh...it was rhetorical <lamont> heh <fabbione> http://x3.putfile.com/videos/669-615-7011.wmv <fabbione> AHAHHA <fabbione> it's work/wife safe :) * lamont tries to think of something that's not canonical-work safe... <fabbione> well if you have some emploies watching your shoulders ;) <lamont> heh <zul> lol!!! <lamont> fabbione: heh <lamont> but you notice he had it pointed in a safe direction... <fabbione> he still managed to hurt himself <lamont> yeah - had on the slide while you pull the trigger is kinda stupid... <lamont> note also that "accidents" like that always involve empty guns <lamont> first rule is: it's always loaded until I see the inside of the chamber <fabbione> yeah <lamont> that's like when people ask if a concealed-carry gun is loaded. duh! <zul> hey jbailey <lamont> morning jbailey <fabbione> hey jb <jbailey> Heya Chuck <jbailey> G'morning Lamont, G'd afternoon Fabio. <fabbione> T-None: <fabbione> debian/ext3-modules-2.6.10-4-itanium-smp-di lib/modules/2.6.10-4-itanium-smp/kernel/fs/mbcache.ko <fabbione> debian/ext2-modules-2.6.10-4-itanium-smp-di lib/modules/2.6.10-4-itanium-smp/kernel/fs/mbcache.ko <fabbione> some modules are in more than one package <fabbione> command exited with status 255 <fabbione> make: *** [binary-udebs] Error 2 <zul> gah? * lamont wonders what an mbcache is <fabbione> wth is that module? <fabbione> these errors are coming out after we fixed the build system <fabbione> i386/amd64 are ok <fabbione> ppc is building <fabbione> ia64 dies with that error <lamont> at least one of those builds with either ext2 or 3 =y <fabbione> it means that eitehr there is an error in kernel-wedge <lamont> or both <fabbione> or that module needs to be shared <fabbione> lamont: right... <fabbione> which one should we compile in? ext2 is my best bet <zul> lowest common demoniator <lamont> yeah <lamont> ext2 is what's on the livecd, so we know we need it. :0) <lamont> and it's small <lamont> ish <fabbione> ok <fabbione> but i also rememeber that changing to y has other implications <lamont> hrm.. <lamont> no clue <fabbione> i need to figure what <fabbione> like updating some d-i/ stuff <lamont> the other alternative is a shared package or something <fabbione> yes <fabbione> if there is a fs-common something <fabbione> anyway that's T-Bone decision <zul> yay perl is almost done <zul> crap more changes <zul> wtf? <fabbione> dude.. i am not kidding <fabbione> that machine is IDE <fabbione> and it has been until yesterday <fabbione> nobody here was in my office other than me <fabbione> either i updated it in my sleeps <fabbione> or something is really WEIRD <zul> *sigh* could it be hotplug? <fabbione> no <zul> grr...i hate it when something breaks <fabbione> read #u-d <fabbione> either i misread partitioner <fabbione> or it did change <fabbione> in the latter case it IS an issue <zul> ok if that is the case how can we fix it mandrake has libata_enable_atapi <fabbione> i need to check again first <zul> ok <zul> time for lunch <zul> yay...i was having a little heartattack <zul> ok lunch <zul> ok what the hell is going on? <fabbione> zul: libata_enable_atapi is broken <zul> fuck.. <zul> it was ripped straight from mandrake and when we tested it worked <fabbione> ok the problem is not the ATAPI <fabbione> but the PATA change <fabbione> static struct pci_device_id piix_pci_tbl[] = { <fabbione> #ifdef ATA_ENABLE_PATA <fabbione> { 0x8086, 0x7111, PCI_ANY_ID, PCI_ANY_ID, 0, 0, piix4_pata }, <fabbione> { 0x8086, 0x24db, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich5_pata }, <fabbione> { 0x8086, 0x25a2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich5_pata }, <fabbione> #endif <fabbione> this means grabbing old IDE controllers and treat them as SATA <fabbione> sorry PATA <zul> oh crap.. <fabbione> the fact that a patch is taken directly from Mandrake or Suse or Gentoo means nothing <fabbione> if they did apply other patches on top to fix this stuff <fabbione> or have older code than us <fabbione> so now we have 2 options <zul> ok im sorry it wont hapen again <fabbione> either we kill the PATA and we see how it goes <fabbione> or we figure if in newer libata versions it works as it should <fabbione> clearly this has very very high priority <jbailey> Is this undoing the SATA fix? <jbailey> SATA CDrom fix, rather? <fabbione> zul: nothing to be sorry.. it could have happen to me <zul> jbailey: yes <fabbione> jbailey: now it's giving I/O corruption on piix chipsets <jbailey> Oh. Joy. <fabbione> so either we get the fix NOW <fabbione> or we revert the change <zul> rever the change on pata <jbailey> In the face of corruption definetly revert. <fabbione> zul: let's divide the tasks instead <jbailey> But we'll have to reopen the bug with an explanation as to why. <fabbione> zul: do you have such chipset somewhere? <fabbione> or jbailey ? <zul> fabbione: no i dont but jbailey does i think <fabbione> (it's 12 hours and more than i am here and i need to rest) <jbailey> I do, yes. <fabbione> jbailey: i urge you to test and see if you can reproduce the problem <fabbione> it's enough to boot the live cd <jbailey> It's in a data centre three time zones from here. <fabbione> the installer will fail <fabbione> jbailey: well.. when i ask if you have it.. i mean handy :) <jbailey> sabdfl also has hardware to match it. <fabbione> yeah but he quite not around <fabbione> and i can't ask him to build/test kernels <fabbione> what i don't understand is why a kernel upgrade didn't show the problem <zul> i can build a kernel without the pata enabled <jbailey> It's handy in the sense that I can test kernels if we're somewhat confident it won't eat the system, and I can get all sorts of status information about the box. <fabbione> why on an upgrade it didn't switch to sda? <fabbione> jbailey: the problem seems to affect only cdrom * T-Bone whispers 'douglassanchez@example.org... :) <fabbione> since i could boot from such machine <zul> T-Bone: not a good time <T-Bone> fabbione: WTF is that mbcache crap in the backlog? :P <fabbione> T-Bone: not a good time <T-Bone> oh <T-Bone> because there is such a thing as a "good time" ? <fabbione> jbailey: but i can't ask you to risk on a machine that far <jbailey> fabbione: Is it any piix driver or just the ata_piix driver? <jbailey> fabbione: The laptop I'm on has piix. <fabbione> jbailey: for what i can see is any <fabbione> i have 2 machine with piix and both fails <fabbione> jbailey: using the livecd is ok <fabbione> it won't touch your hd at all <fabbione> it will stop much earlier than that * T-Bone is trying to figure out what's going on... <fabbione> T-Bone: I/O corruption from cdrom with the new libata changes <jbailey> Hmm, I wonder if I have a CD here. <jbailey> Ugh, teenagers. Looks like the local school is having a field trip to the local coffee shop. <jbailey> (first time I looked around) <fabbione> cdrom only *APPARENTLY* <T-Bone> fabbione: sweet, how comes this made it in? <lamont_r> jbailey: I was here for one of those too. <T-Bone> s/this/this shit/ <fabbione> T-Bone: the same way people are already complaining about the ppc LED turned on <lamont_r> well, time to go retrieve my latin scholar <T-Bone> i see <jbailey> fabbione: Is there anything I can test from my running system <fabbione> patch -p1 < somefancystuff.diff <T-Bone> we've been too laxist on the mergein policy <lamont_r> so who checked in the ppc changes, anyway? <fabbione> jbailey: no. you need to boot the livecd <fabbione> not me <T-Bone> part my fault <fabbione> i was approx 20000KM or 12000NM from any pc <T-Bone> but otoh i must blame zul for that one <fabbione> NO TIME TO BLAME <fabbione> we need a fix <T-Bone> disable it <fabbione> and who can test the fix <jbailey> fabbione: Lemme pull down a livecd then. Lesse how good the net connection at this web caf really is. =) <fabbione> jbailey: ok. <T-Bone> revert to pre-25 <fabbione> jbailey: to verify: <fabbione> boot on the liveCD <fabbione> and the installer should fail with "unable to load installer components" or something like that <fabbione> check dmesg <fabbione> and /proc/partition to verify that your hardware is actually recognized as scsi <lamont_r> T-Bone: need -25 for kickstart for kamion. Don't think we can revert <fabbione> probably checking the PCI id from above should be enough to know if it will happen or not <lamont_r> and I'm inclined to call this 25.1, since we already have -26 in the works... thoughts? <T-Bone> lamont_r: how comes we couldn't revert the libpata diff (which is 2 lines btw), since it was working just fine before except for a few users with specific hardware?? <lamont_r> T-Bone: that's what we need to do. <fabbione> few = a lot dude <fabbione> piix is quite common intel hw * lamont_r read 'revert to pre-25' to mean 'use -24 on the preview'. which is much different than reverting that patch <T-Bone> fabbione: hell, your call. If you prefer more supported user with broken implementation... <T-Bone> lamont_r: yeah sorry i wasn't clear enough <jbailey> fabbione: array6 is fine for the livecd, right? <jbailey> Or do I need something more recent? <fabbione> jbailey: dunno.. it needs to have -25 <T-Bone> if we need a minute-made fix, the only solution is reverting that patch <lamont_r> I prefer some unusable implementations to silent data corruption anywhere <jbailey> Do you have the URL for a mor recent snapshot handy? <T-Bone> we wouldn't have enough time to test any other invasive change <T-Bone> and would introduce potential new bugs that way * lamont_r really must run and fetch the kid - back online in about 40-45 minutes <T-Bone> lamont_r: same here, hence my comment. Trying to fix both 'support more users' and 'fix data corruption' would go against our safe commit policy <T-Bone> but that's just my 2 cents <jbailey> fabbione: I'm getting 60k per second to cdimage.ubuntu.com 3 hours to download at this rate. =( <T-Bone> ouch * T-Bone can't help. No x86 hw around <zul> i have a pentium 3 where i can build a 686 kernel if you want to test <jbailey> The question got missed in #u-devel, Is this only for cases where ata-piix intead of piix gets loaded for pure pata systems? * T-Bone needs to run out <T-Bone> i'll be back in ~30' <zul> im building a kernel for 686 that disables undef pata again <T-Gone> zul: that's a no-go alas. We don't have time to rebuild a full set of kernels... * T-Gone runs off anyway <zul> im only building 686 <jbailey> zul: Do you know whether it's only for cases where ata-piix gets loaded instead of piix? <zul> im not sure <jbailey> I've been running that kernel on my laptop for a while with no problem, and I've been using that kernel on a sata system that does a couple emails a second with no problem. <jbailey> I'm still sitting at 40k/sec for this livecd download, though. <jbailey> My laptop does the cdrom no problem. <jbailey> So I'm not sure where he's seeing the issue. <zul> do a hdparm on the cdrom <jbailey> 16 bit, a pile of offs, readahead 256, HDIO_GETGEO failed. <jbailey> afk a sec. <jbailey> back <zul> fabbione: is that the same message that jbaileiy got? <jbailey> zul: I think thats' pretty normal for hdparm'ing a CDROM. I don't htin it provides the geometry info. <zul> k <jbailey> My guess is that what he's seeing is that the controller is being detected as ata_piix intead of piix. <jbailey> It wouldn't affect upgrades because initrd-tools isn't that bright. <jbailey> Is that PCI ID add that you pasted here the only change with that patch? <fabbione> no <fabbione> it also enables another thing <jbailey> fabbione: Is my assumptions right so far? That you're running off of ata_piix instead of running off of piix? <fabbione> i need dinner <fabbione> bbl <jbailey> Mm, lunch sounds like a good idea too. <jbailey> I'll finish this first. * lamont_r sits on the "neighbor"'s front porch, leeching bandwidth <lamont_r> "neighbor" is about 3.5 miles away <T-Bone> lol <T-Bone> would that mean anything good for me? :} <lamont_r> fabbione: from a logistical standpoint, whatever fix we do should probably just happen on mainline, and then we can merge it over to -pre26, and then think about renaming said branch... :0) * T-Bone ducks <zul> ok im building the linux headers for 2.6.10 with #undef pata <T-Bone> zul: what are you trying to do? <zul> im trying to get a test kernel going <zul> or...trying to help out <T-Bone> zul: actually, any solution involving a kernel rebuild is mostly ruled out, afaict <T-Bone> zul: actually it turns out that I just said crap. Forget it :P <zul> i have a linux-image with pata turned off again if you want to test <T-Bone> zul: i'd love to. Don't have the hw :P <jbailey> zul: Did you revert the whole patch or just the extra PCI ids? <zul> just the pci ids <jbailey> I could test the kernel here just to make sure it doesn't load both anymore. <zul> -#undef ATA_ENABLE_ATAPI /* define to enable ATAPI support */ <zul> +#define ATA_ENABLE_ATAPI /* define to enable ATAPI support */ <zul> #undef ATA_ENABLE_PATA /* define to enable PATA support in some <zul> * low-level drivers */ <T-Bone> zul: tel kamion/fabbione what you're doing on #u-devel, seems they're not aware... <T-Gone> dinner time, bbiab <fabbione> i am preparing 25.1 <zul> ok <T-Bone> lamont: how are you going to integrate 25.1 into the baz archive? * T-Bone tries to return to the adequate channel <lamont> T-Bone: simple. grab source, apply diff, commit to mainline <lamont> then branch it to -2,6,10-25,1 <lamont> merge to --pre26, and commit there <T-Bone> woot <T-Bone> seems so simple :) <lamont> T-Bone: that's why we don't work on the mainline branch... :-) <lamont> alternatively (if we had already checked in -26 on mainline), then it would go in as a patch on the -25 version branch <T-Bone> ic <T-Bone> btw. what about the issue that would possibly be solved today? Will it have to be postponed? (just asking, mind you :) <lamont> which issue is that? <lamont> oh. that. nfc <T-Bone> heh <T-Bone> i feared such an answer :| <zul> right ill be back later tonight...going to go play some soccer and ill be in pain later :) <lamont> step 1: preview release ships. step 2: figure out status of everything else, act accordingly <T-Bone> heh * T-Bone has gone for a 'nobody cares' policy on ia64 <zul> later <T-Bone> zul: have fun <zul> oh i will <T-Bone> hehe <Mithrandir> T-Bone: nobody (read HP) has cared enough to send me an ia64 yet, so.. ;P <T-Bone> Mithrandir: heh. Otoh you've got full access to mine... <Mithrandir> T-Bone: true enough. <T-Bone> Mithrandir: more access would be "physical" at that point :) <Mithrandir> I could use one, it's cold up here in Norway. <T-Bone> lol <T-Bone> Mithrandir: btw if you need it right wrt lib32gcc1... I can let it on 24/7 if needed :) <Mithrandir> T-Bone: I'm going home now. If gf is sleepy, I might fix it now so it's ready when preview freeze is over. <Mithrandir> I'll let you know in 30-ish minutes <T-Bone> perfect <T-Bone> thx alot :) <Mithrandir> T-Bone: ok, home, Karianne is already in bed, so I can hack the ia32-libs stuff. <T-Bone> hehe ok <T-Bone> hold on, booting the beast <T-Bone> there it goes. Give it 2' and it'll be all yours :) <T-Bone> feel free to dist-upgrade if needed <Mithrandir> shouldn't need to <T-Bone> whatever you want :) * lamont notes that t-bone has turned into the 'willy switch' <T-Bone> lamont: huh? :) <lamont> I used to have willy walk over and power-cycle my A500 in my cube in 5L. <lamont> hence, willy switch. <lamont> far better than X10. :-)( <lamont> more expensive, too <T-Bone> lol <T-Bone> damn you :) <lamont> oh where oh where is fabbione... <T-Bone> to bed <T-Bone> not necessarily sleeping, mind you ;) * T-Bone ducks #ubuntu-kernel 2005-03-21 <lamont> so lets see.. do we want to have 00list-25.1* in the 26 upload? <lamont> hrm.. actually, I don't see the atapi patch update either... * lamont will pester fabbione tomorrow morning his time <zul> hey <zul> so what did i miss? <lamont> you know, we could break up the kernel into a package that just builds the -doc and -source packages, and then others that just build-depend: -source, have nothing in them except maybe config files, and then do the build... that'd let the buildd's spread the load of a new source tree out a bit... * lamont waits to get pummeled <zul> good idea but we arent redhat <zul> or any rpm based distro <zul> does debian do the same way? <zul> ie how we build our kernel...oh this is channel is logged now isnt it? <lamont> heh <lamont> yeah, should be logged <lamont> t-bone was doing it, I expect fabbione has picked that up and incorporated it into the wiki bound logs <lamont> debian is heading to the same place we are, not sure who is further down the path yet. <zul> it should have big black warning signs <lamont> prior to the 2.6 package, it was actually a kernel-tree and kernel-patch-2.4.27-powerpc type world <zul> eww <zul> nighto <jbailey> mdz: I made a bad on 1440 - It looks like scd0 *is* there. I had windows open to both SATA machines. I did the kernel upgrade on one and looked at the other afterwards. <jbailey> mdz: ii linux-image-2. 2.6.10-25.1 Linux kernel image for version 2.6.10 on PPr <jbailey> iridium:/sys/block/sr0# <jbailey> Sorry, obviously being in the rush to get out caught me. =( <fabbione> lamont: <fabbione> +# this is a hack for Ubuntu buildd's <fabbione> + <fabbione> +if [ -e /CurrentlyBuilding ] ; then <fabbione> + fork := $(cat /proc/cpuinfo | grep ^processor | wc -l) <fabbione> + fork := $(expr $fork \* 2) <fabbione> + export CONCURRENCY_LEVEL := $fork <fabbione> +fi <fabbione> + <fabbione> somethinig like this in debian/rules <fabbione> would speed up the kernel build N times <lamont> fabbione: i386 is 4 way, amd64 2, ppc 1. <lamont> ppc is the blocker <fabbione> lamont: i did test on davis.. -j15 flies <lamont> and the other 2 finish in about 2 hours.. <fabbione> still slow but clearly much better than -j1 <fabbione> specially if the code is ccached <lamont> yeah - feel free to add the hack... <fabbione> we can give it a shot for 26 <fabbione> and see how it goes <fabbione> you get the delta for it, don't you? <lamont> ?? <lamont> I get what? <fabbione> delta in build time.. to see if we gain or we lose <lamont> yes] <fabbione> cool <lamont> last line of the build logs <lamont> lrwxrwxrwx 1 root root 9 Mar 10 06:37 /usr/sbin/sendmail -> /bin/true * lamont takes a large bo-staff to debootstrap <fabbione> * committed douglassanchez@example.org/kernel-debian--mainline--2.6.10--patch-26 <fabbione> ok 25.2 is up <fabbione> lamont: want to check if the changes to the umask are ok? <lamont> find ~lamont/public_html/Archives ! -user lamont -perm -0200 ! -perm -020 <lamont> /douglassanchez@example.org/kernel-debian--mainline--2.6.10/patch-26/++revision-lock <lamont> /douglassanchez@example.org/kernel-debian--mainline--2.6.10/patch-26/++revision-lock/+contents * lamont grumbles <fabbione> does sftp actually load .bash_profile? <lamont> dunno <fabbione> because that's where i changed the umask * lamont sets it in .bash_profile and .bashrc <fabbione> umask 002 <fabbione> also in .bashrc now <fabbione> i can try to branch and see if that works <lamont> well, if you go chmod g+w those two files, then _I_ can commit to mainline.... <fabbione> sure <fabbione> done.. they are actually 2 dirs.. <fabbione> let me try to branch and see if sftp will load .bashrc <fabbione> i can still fix the permissions on the fly <fabbione> looks about right <fabbione> * committed douglassanchez@example.org/kernel-debian--pre26--2.6.10--patch-7 <fabbione> lamont: all the syncs/merges should be ok now <lamont> woot <fabbione> lamont, mdz: would i be crossburned if i kill this patch madness for hoary? <T-None> hey fabbione ! <fabbione> hi T-None <mdz> fabbione: not at all <lamont> fabbione: I have yet to see what useful purpose it serves... <T-None> well in my humble opinion i would praise you for doing so ;) <lamont> which is to say, kill away <T-None> lamont: lol <mdz> it should be pretty easy to ensure that it doesn't regress <fabbione> lamont: i am not 100% how make-kpkg will interact with linux-ubuntu-patches <mdz> as long as it still builds and no patches are dropped, it is fine with me <mdz> it should save minutes on the kernel build too :-P <T-None> the only purpose i see is finding out which kernel rev introduced a borkage. Since we take care not to uplaod before builds (do we), it's obviously the last one :) <fabbione> mdz: minutes? ages! <T-None> hell yes <fabbione> again.. we only build the kernel this way <fabbione> but i am not 100% about the linux-ubuntu-patches <fabbione> and it is used when building from linux-source package * T-None will look at that later, already much too late at work, have to run <T-None> see yall * lamont tries to decide if 2.25GB of ram is overkill on a dual P3-1.2GHz machine <Mithrandir> lamont: nah, it's just fine. <fabbione> lamont: i just committed the CONCURRENCY_LEVEL to speed up the build on the kernel <fabbione> on the buildd even <fabbione> that should speed up to Ncpus * 2 <fabbione> if the code is ccached we could fork much more <fabbione> but it is dangerous <lamont> heh.. make that a 2-way P3-993MHz box. <lamont> scrollkeepoer <lamont> ECHAN <fabbione> --- orig/rules <fabbione> +++ mod/rules <fabbione> @@ -55,8 +55,7 @@ <fabbione> <fabbione> .PHONY: monolith <fabbione> monolith: stamp-monolith <fabbione> -stamp-monolith: stamp-monolith-prepare \ <fabbione> - $(foreach revision,$(revisions),stamp-monolith-$(revision)) <fabbione> +stamp-monolith: stamp-monolith-prepare stamp-monolith-$(revision) <fabbione> rm -rf $(DIFFDIR) <fabbione> touch $@ <fabbione> if you apply this patch to your debian/rules <fabbione> only the last patch set will be applied <fabbione> killing the patch madness <fabbione> after that this make-substvar is called <fabbione> and it fails <fabbione> debian/make-substvars linux version.Debian debian/monolith/list > debian/substvars.safe <fabbione> Line 1: patch patch-2.6.10-26 is not well-founded <fabbione> Patch for 2.6.10-26 must be listed <lamont> ah, so we need to create the input file that it wants, without bothering to actually apply the patches... * lamont can work on that <fabbione> kinda <fabbione> ( cd /home/fabbione/linux-source-2.6.10-2.6.10/debian/diffdir; diff -Nur linux-source-2.6.10-2.6.10-25.2 linux-source-2.6.10-2.6.10-26 || true ) > debian/monolith/patch-2.6.10-26 <fabbione> FUCK <fabbione> FUCK <fabbione> FUCK <fabbione> it uses incremental patches <fabbione> uhuh <fabbione> got it <lamont> feh * lamont sleeps <fabbione> good night <fabbione> bah <fabbione> i found another bug <fabbione> thanks god it affects only hppa atm <fabbione> baz commit -s'Kill patch madness' <zul> hey <jbailey> Heya. Waldi filed a bug against initrd-tools in Debian which propagated its way into Ubuntu. Apparently on his systems /proc/scsi isn't populated, and on ours it is. His claim is that 2.6.10 did away with that. Have we tweaked it so that ours still has that info? <zul> not sure maybe you should ask in -devel <jbailey> Nah, I'll just pull the source and look. <zul> or youo could do that <jbailey> ## DP: Description: restore generic SCSI proc_info function in drivers/scsi/scsi_proc.c <jbailey> That would probably be the one. <zul> oh it was a kernel question...im not awake yet <fabbione> hey <zul> hey fabbione <jbailey> Heya Fabio =) <jbailey> zul: *lol* =) <zul> fricking palm <fabbione> i am testing the new patch thingy <fabbione> it seems to work fine <zul> which patch thingy? <fabbione> no more 192891821 patch/unpatch <zul> ah good <fabbione> zul: baz update? <zul> ooh you fixed it so it doesnt patch/unpatch a billion times? <fabbione> yup <zul> sweet! <fabbione> there were several changes to do <fabbione> + an important bug fix <fabbione> hey smurfix <abelli_> ciao smurfix <fabbione> smurfix: what was the perfect command to verify the ABI compatibility? <smurfix> fabbione: one sec <fabbione> sure.. also 2 or 3 <smurfix> something along these lines ..: <smurfix> grep vmlinux Module.symvers.old_kernel |sort >/tmp/symvers.old <smurfix> ditto new <smurfix> comm -23 old new <smurfix> must be empty <smurfix> assuming you build with CONFIG_MODVERSIONS <fabbione> where Module.symvers.old_kernel = Systemmap? <fabbione> no <smurfix> fabbione: no, the "Module.symvers" file that's generated by building the kernel <fabbione> yes and we don't ship it <smurfix> Let me check if you can extract that somehow <fabbione> the idea is to automatically check the ABI with the previous kernel at build time <fabbione> previous version <fabbione> now we can also start shipping that file <fabbione> it's not a tragedy <fabbione> if we start shipping it in 26 <smurfix> fabbione: The kernel doesn't export that info any more because it now has a built-in relocator <fabbione> from 27 we can add the check at build time <smurfix> so you probably should start shipping it. <fabbione> this would add a Build- <fabbione> this would add a Build-Dep: on the most recent version of the kernel <fabbione> or just on a linux-abi package <fabbione> that can collect all the MOdule.* <fabbione> what do you think? <smurfix> Hmm, better do an abi package. <fabbione> next upload needs to bless a new package anyway <fabbione> so one more or one less won't change much <smurfix> Would be nice to have that available for cross-compiling. You can put the .config files in there too. <fabbione> smurfix: configfiles are in /boot with the images <smurfix> fabbione: true. Doesn't hurt to also ship them in an -abi package, people like me who still habitually build their own kernels would like that. But, your call. <fabbione> what scares me a bit is how to ensure that we always build against the $previousversion -abi <fabbione> without having to control that manually <fabbione> scenario: <fabbione> upload -1 <fabbione> there is no previous -abi <fabbione> so we skip the check <fabbione> and it FTBFS on ppc <fabbione> how do we upload -2 that will check the abi for all arches other than ppc? <fabbione> the code needs to be very smart <smurfix> fabbione: What are you going to do if/when the ABIs don't match? <zul> take a large wooden hammer <smurfix> fabbione: ... or do you decree that any -1 is an ABI change but -2+ isn't? <fabbione> smurfix: FTBFS? <smurfix> fabbione: Well, someties you do need to change the ABI :-/ <fabbione> smurfix: clearly the -1 is a new abi <fabbione> yes of course you must change the ABI <fabbione> but an ABI change require also a new control file <fabbione> to reflect that change <fabbione> for example <fabbione> if i start doing heavy patching <fabbione> or security patching to the kernel <fabbione> running a build should be able to tell me if that change will introduce an ABI change <smurfix> OK, so you check the old linux-abi package's version number, and skip the ABI check if it doesn't match what you're building <smurfix> excluding the -X version of course <fabbione> kinda yes <fabbione> but if for example <fabbione> we are building -1-2.6.10 ver 2.6.10-2 <fabbione> i want it to compaer with -1-2.6.10 ver 2.6.10-1 <fabbione> if the ABI does not match <fabbione> i want it to FTBFS <fabbione> so that i can prosuce a -2-2.6.10 <fabbione> that is the correct way <fabbione> since there is an ABI change <fabbione> i mean.. i know i could do all of this manually <fabbione> but for N arches in N flavours <fabbione> it's a royal pain <smurfix> fabbione: sure, but I fail to see how that differs from what I've been saying <fabbione> than probably i misunderstood you :-) <fabbione> but ok <smurfix> Let's say you create a linux-kernel-abi package <fabbione> yes <smurfix> some file in it contains the magic string "2.6.10-4" <fabbione> it would need to contain the ABI version too <fabbione> ok <smurfix> I thought that is* the abi version <fabbione> yeah i get you now <fabbione> i was thinking in terms of 2.6.10-1 (starting from scratch) <smurfix> Doesn't really matter, you'd get the magic string "2.6.9-5" or whatever <fabbione> yup <smurfix> different, so skip check. <fabbione> right <fabbione> that would solve all the problems <smurfix> same when you FTBFS, the failed arch would keep its old l-k-a package which still has the old magic string in it. <fabbione> it won't match the ABI and therefor skip the test <fabbione> because hte next upload will have a different ABI <fabbione> good idea <smurfix> The only problem I see is how to build-dep on the latest l-k-a package <smurfix> unless you just want to wing it ;-) <smurfix> (probably not a good idea, now that I think about it) <fabbione> well the first upload will create the package <fabbione> from the second one we will build-dep on it <fabbione> in case of troubles we can always remvoe the build-dep <fabbione> and unroll the loop <smurfix> Yeah, but if the second build installed the package from the first run on the autobuilder, but changes the ABI, then the third build may still see the first package if it happens not to be cleared out <fabbione> that shouldn't be a problem <smurfix> so a mistaked ABI change from 2->3 might be missed <fabbione> the ABI is supposed to be the same between first, second and third <smurfix> Umm, it's supposed to be the same from -2 to -3, but I wan't talking about that <fabbione> oh you mean if there is an ABI change between -1 and -2 <fabbione> and we upload -3 <fabbione> and there can still be abi from -1 in the buildd <fabbione> at that point the ABI check should be skipped <fabbione> and it will due to the magic file <fabbione> but yes.. that can actually skip a test that should be done <smurfix> Exactly. I don't know how to guard against that other than asking the archives for the current version when you prepare the source package <smurfix> Dunno whether you'd want to go that far. <fabbione> well preparing the source package is still manual <fabbione> and we can still hack on it <smurfix> OK, then you need to remember never to forget to update the dependency when you prepare a new version. ;-) <smurfix> or write a script that does it. Good enough I'd say. <fabbione> smurfix: that is why we have a control.stub that we can mangle as we like :-))))) <fabbione> smurfix: the next question would be.. are you for this challenge? <fabbione> ;) <smurfix> fabbione: gah ;-) I need to fix the keyboard chooser first <fabbione> ehhehe <fabbione> fair enough <smurfix> fabbione: it needs a confirmation dialog <fabbione> i think we can postpone this feature to hoary+1 <fabbione> even if it would make pitti's life 1029292 times simpler <fabbione> also for us that will have to maintain this kernel for 18 months <fabbione> last script to test the anti-patch-madness fix <fabbione> s/to/for <smurfix> fabbione: If for hoary, when would you need it? <fabbione> within monday <fabbione> but i guess i can try to work on it <fabbione> i will have the weekend free! <fabbione> YEAH YEAH <fabbione> wife -> her sisterm <fabbione> sister even * lamont will be offline from sometime this weekend until sometime tuesday or so <fabbione> lamont: don't worry <fabbione> i won't upload very soon <fabbione> not with these big changes <fabbione> i am still testing some stuff <lamont> fabbione: it means that you're baz bitch for a few days... :-) <fabbione> i might get up -26 to get the ATAPI thingy in again <fabbione> and the new idiotify patch <fabbione> and the antipatchmadness <fabbione> the ABI stuff can come later <fabbione> ok confirmed 100%.. the patch madness is gone <fabbione> all the scripts are working * T-Bone reads 3 lines back and ^5s fabbione ! * T-Bone wonders if lamont is around and has some "good" news... (who knows ;o) <zul> heh im almost always here <zul> whoa...224 changes in the last day <mdz> changes? <zul> in linus bk tree <lamont> busy boy <zul> well with the g5 he must be :) #ubuntu-kernel 2005-03-22 <jbailey> Is there a sane way to tell if NOEXEC is enabled or not on a given system? <zul> hey <lamont> hay <zul> how now brown cow <lamont> nah, hay is for horses * lamont just fed, you see... <zul> heh i just fed the guinea pig <zul> so kind of same thing <lamont> heh <lamont> hrm.. I'm on major lagtime today <fabbione> morning <fabbione> i guess nobody has been tracking the Debian kernel while i was away... right? <dilinger> i have! <dilinger> ;) <fabbione> yeah i know you do :) <fabbione> nobody did here <fabbione> and i can see a few hunderd tons of SECURITY and other important bug fixes <dilinger> i actually am about to release 2.6.10-6 <dilinger> i have an i386 image compiling <fabbione> is there any abi breakage between debian 2.6.10-4 and -6? <dilinger> there shouldn't be <dilinger> i dropped the netfilter private frag queue stuff <dilinger> there's an amd64 fix that touches a header file, but it's a static inline function, so it shouldn't break stuff <dilinger> i'm also reenabling CONFIG_PREEMPT on i386, so as to avoid an ABINAME bump <dilinger> no point fixing that stuff in 2.6.10, and having it rot in NEW while we do the same thing in 2.6.11 <fabbione> but that's in the kernel-image.... <dilinger> right <dilinger> which you don't care about. but i figured i'd mention for completeness <fabbione> yes.. i am not going to munge too much around with configs at this point in time <dilinger> i have a half written ruby script that does abi checking <dilinger> wrote it in an airport <dilinger> i should finish it tonight <fabbione> yeah but we were considering build-time checks <dilinger> right <dilinger> bounty it, and i'll have it done in a day or two :) <fabbione> in 99.9% of the cases we always pre-build on porting boxes <dilinger> in something other than ruby <fabbione> for bounties = mdz ;) * dilinger pokes mdz <fabbione> the point isn't ruby or python or shell script <dilinger> well, if you're going to run it at build-time, it's an added build-dep <fabbione> <mdz> sleep now <fabbione> yes.. but that isn't an issue <fabbione> just read all the irclogs :-) <fabbione> i need to go for a few minutes.. mother nature is calling me badly <dilinger> heh <dilinger> i need to start this i386 build anyways <fabbione> eheh <fabbione> jbailey: CONFIG_LOGO=n on all arches <fabbione> just committed <fabbione> HMMM <fabbione> there is something really unclear to me.... * fabbione needs to dig into this madness <dilinger> fabbione: just checking vmlinux symbols doesn't work <dilinger> modules ABI need to be checked as well <fabbione> yeah i have been thinking about it... <dilinger> modules' <dilinger> my way is running nm on modules <fabbione> and i had the same idea.. <dilinger> ie, nm /lib/modules/2.6.10/kernel/drivers/ide/ide-core.ko <dilinger> 3b97ad98 A __crc_ide_undecoded_slave <dilinger> 00007fa0 T ide_undecoded_slave <dilinger> that's 0x3b97ad98 ide_undecoded_slave drivers/ide/ide-core in Module.symvers <dilinger> an abi checker needs to report any modules that are missing, and any changed symbols within modules <fabbione> first 2 things to do after hoary: <fabbione> - clean up the packing <fabbione> - allign the configs <fabbione> - abi checker if we cannot get it in hoary <fabbione> IT IS PURE MADNESS! <fabbione> we could have a kernel-config builder.. similar to kernel-wedge <dilinger> how about <dilinger> - synch packaging w/ debian <dilinger> since i think we both want the same things; the only place we seem to differ is w/ ubuntu's d-i stuff right in the source package <dilinger> differ in goals, that is <fabbione> and a bunch of extra modules compiled in <fabbione> but yes <fabbione> we need a common source <dilinger> yea, but that's not a packaging issue <dilinger> it'd make everyone's life easier, i think <fabbione> but we can't achive it until debian will not kill at least the kernel-source -> kernel-image madness <fabbione> i fully agree <dilinger> right * fabbione is very close to send ia64 to hell <fabbione> it's snowing <fabbione> damn <Mithrandir> slushing here. <fabbione> the only thing that pisses me off about snow is that i need to go out and clean the road <Mithrandir> it'll clean itself eventually. Called summer. <fabbione> Mithrandir: here by law we must clean it, because it's a private road <Mithrandir> oh, ok <fabbione> and if the postman falls <fabbione> it's my responsability <fabbione> now.. it is fucking lame <fabbione> because they could learn to fly <fabbione> or eventually buy better snow shoes <fabbione> but apparently they love to make easy things more complex via the useless <fabbione> T-None: fix to the ia32 memcpy is done <fabbione> -26 is going up * fabbione starts the baz magic <fabbione> <fabbione> T-None: fix to the ia32 memcpy is done <jbailey> fabbione: Thanks! <T-Bone> seen that, thx <fabbione> jbailey: no problem <fabbione> it took me fucking 4 hours to unfuck ia64 build <T-Bone> unfuck? <fabbione> well yes. <Mithrandir> T-Bone: does the new ia32-libs in the archive make you happy? <fabbione> the problem is that we were calling kernel-wedge || true <fabbione> that was hiding some problems <fabbione> and ia64 was one in the worst situation <fabbione> with dup mods allover <T-Bone> Mithrandir: haven't checked yet but they certainly will! We need to sync with kamion for the language support deps, as soon as you'll upload ooo :) <T-Bone> fabbione: wasn't aware of that <T-Bone> fabbione: nobody complained <fabbione> T-Bone: yup.. i did paste here when you were around :-))) <fabbione> and you said: "Uhuh?" <fabbione> so i just went forward and fixed it <T-Bone> <fabbione> debian/ext3-modules-2.6.10-4-itanium-smp-di lib/modules/2.6.10-4-itanium-smp/kernel/fs/mbcache.ko <T-Bone> <fabbione> debian/ext2-modules-2.6.10-4-itanium-smp-di lib/modules/2.6.10-4-itanium-smp/kernel/fs/mbcache.ko <T-Bone> <fabbione> some modules are in more than one package <fabbione> i tought you were busy somehow <T-Bone> yesterday <fabbione> yes that one <Mithrandir> T-Bone: I would be very happy if you checked it out and closed the bugs if appropriate <T-Bone> well given i get back from work at 1900 localtime on every week days except friday, I don't have much time to dig that kind of stuff <T-Bone> Mithrandir: the only bug i know of is the ldd one, You fixed it, you close it? :) <fabbione> that's why i went forward and fixed it <T-Bone> which is cool <Mithrandir> T-Bone: please verify it's fixed. <T-Bone> besides, I don't have much insight on kernel build process <T-Bone> Mithrandir: sure, hold on <T-Bone> Mithrandir: give me 5mn to get something on fire for me to eat, i'm starving <Mithrandir> sure <Mithrandir> T-Bone: I hate to close bugs if I can't verify that they are fixed. <T-Bone> well you can... :) <T-Bone> what am i supposed to check? apt-get removing and install ia32-libs is enough? <Mithrandir> also lib32gcc1 <Mithrandir> and that ooo works afterwards <T-Bone> (btw, i dunno what you did with ssh yesterday but nc didn't like it. I have 12 process running and the same number of open connex between nekkid and my box :) <T-Bone> pl <T-Bone> err, 'ok' <Mithrandir> just kill the nc prosesses <T-Bone> done * T-Bone curses french out-of-sync-mirror, edits sources.list <T-Bone> ls /usr/bin/ld <T-Bone> ld ldd ldd.amd64 lddlibc4 <T-Bone> root@Nekkid:/home/varenet/ooo # ls /usr/bin/ld <T-Bone> root@Nekkid:/home/varenet/ooo # dpkg -S ldd.amd64 <T-Bone> diversion by ia32-libs from: /usr/bin/ldd <T-Bone> diversion by ia32-libs to: /usr/bin/ldd.amd64 <T-Bone> *PLONK* <T-Bone> the RTLDLIST is correct though <T-Bone> only the naming looks wrong <T-Bone> dunno if that's such a big problem * ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | douglassanchez@example.org/kernel-debian--pre27--2.6.10 <fabbione> no log on people... <fabbione> that's good.. <fabbione> it means that buildds didn't fail... YET <T-Bone> Mithrandir: ooo works as a charm <T-Bone> fabbione: wrt the m-l, i wasn't the one who set it up, i hope you're subscribed to it, it's used for bugreports actually. <Mithrandir> T-Bone: great, thanks. <T-Bone> Mithrandir: what do you think about the ldd.amd64 thingy? <T-Bone> in my taste it should be corrected, but as long as it works... <fabbione> T-Bone: i didn't want a ml from the beginning and i know you have no power to sub people <T-Bone> ? <fabbione> and now it is a very high traffic ml that nobody is going to read <T-Bone> i didn't want bugreports to be sent to that m-l <fabbione> since i get the same bug messages in 3 inbox now <T-Bone> i didn't push forward for that m-l <fabbione> T-Bone: read above please.. i didn't say you did something anywhere <fabbione> i know you did not create it <fabbione> but you were one pushing for it <T-Bone> i thought that if we were to have a decently sized team, it would be useful <Mithrandir> T-Bone: I'm somewhat inclined to ignore it, or rather, I'm probably going to fix it for ia32-libs in Debian and we'll sync what they have. <T-Bone> but I clearly stated (and the logs on that channel will show it) that having bugreports sent to it was a *bad idea*, since it would turn up the same shit as debian-kernel which I unsubscribed for that very reason <fabbione> i agree to that :-) <fabbione> we shoud remove the bugs from the list <fabbione> i think lamont has to do it <T-Bone> Mithrandir: ok. Maybe you want to add some README entry somewhere about that, so that confused users can see it before posting irrelevant bugreports <fabbione> i am not sure even who did it in the beginning <T-Bone> fabbione: i would more than thank you for doing that <fabbione> i don't know it has been done in the beginning <fabbione> so i am not sure HOW to revert it * T-Bone doesn't know: went to bed one day, woke up the next and the m-l was there <T-Bone> OTOH you can blame *me* for creating this channel :P <Mithrandir> T-Bone: sure, but it's a 200-odd MB upload, so I try not to upload it too often. <fabbione> i am off until the meeting <fabbione> i need some relax <fabbione> pleaase keep an eye on the build logs <fabbione> and try to grep for -j to see if it has been set properly <T-Bone> Mithrandir: heh roger that <fabbione> we should have a huge build speed up with this upload <T-Bone> Mithrandir: care to close the bug btw? <mjg59> Ok, new HP laptops need the reboot=b paramater on boot to reboot <mjg59> We can work round that with a DMI entry in reboot.c <Mithrandir> T-Bone: done <T-Bone> thx <lamont> actually, removing bugs from the mailing list is a change in the default assignment in bz... <T-Bone> hey lamont! <T-Bone> issaishiburidane?! ;) * T-Bone obfuscates the output a bit more not separating logical entities ;) <zul> heylo <T-Bone> heya <zul> when is that meetinga again? <T-Bone> in 3 hours <zul> ok <zul> dang thats when i have lunch <T-Bone> heh * T-Bone wanders off re-stringing his guitar <zul> heh in theory i could test out ppc stuff with pearpc <T-Bone> lol <T-Bone> you *really* are a masochist, indeed :) * T-Bone is done with the stringing <zul> thats why i said in theory <jbailey> What's a pearpc? <zul> its a powerpc emulator <jbailey> Cool. <jbailey> Hmm, now that I'm on PPC I should track down an old MacOS emulator and some abandonware games. <T-Bone> jbailey: tssks tssks, You should read /. There's been stories about PearPC and CherryOS ;) <jbailey> There was one I really like to play. CAn't for the life of me remember what it was called. <T-Bone> Monkey Island? <jbailey> T-Bone: I've managed to get my /. reading down to once every couple of days. <T-Bone> jbailey: hehe ;) <T-Bone> jbailey: syndicate. Much easier to read :) <jbailey> No, it was a game where you wake up in a spaceship and you're the only one alive and the computer has lost most of its memory. <T-Bone> huh <jbailey> You have to help it reconstruct its memories in order to find out what happened. <T-Bone> that rings something, but i can't tell what <T-Bone> ;) <zul> jbailey: roger wilco? <zul> by sierra wasnt it? * T-Bone spent endless nights on Monkey Island, the best adventure game ever ;) <jbailey> zul: You're thinking space quest, I think. <zul> yeah <jbailey> zul: And I play that under dosemu occasionally. =) <zul> ah sweet i found to play that game again i never completed it <jbailey> On the other machine I have a nice abandonware site bookmarked. <zul> the-underdogs.org <T-Bone> jbailey: please hand over the URL :) <jbailey> Huh, annoying. my susv3 package in Debian isn't in multiverse. <jbailey> T-Bone: The machines not on right now, I'll grab it when I stop for lunch. <T-Bone> cool thx :) <jbailey> T-Bone: It's a French Abandonware site, too. =) <jbailey> A bunch of the games are in French only. Good practice for me. <zul> anyone played nobunaga's ambition? <T-Bone> jbailey: i think i've hit that one once, but i don't recall the name <T-Bone> most of my bookmarks went away with my dead HD :P <T-Bone> zul: doesn't ring a bell * jbailey waits for susv3 to install. <zul> its an awesome game you are shogun and you are trying to become emperor of japan <T-Bone> lol <lamont> T-Bone: hisashiburi da. <zul> lamont: hey <T-Bone> daijobu deska? :) <lamont> t-bone: shindoi da <lamont> morning zul <T-Bone> heh ;) <zul> yes you have entered the twiligh zone <lamont> zul: we'll be operating in japanese today, ok? :-) <T-Bone> lol <lamont> tonycrackers, I should read my email about the dev meeting, eh? <T-Bone> 'tonycrackers' ! LOL <T-Bone> that one is a quote I'm probably the only one to understand, but it's rather *fun* 8) <T-Bone> lamont: dooso <zul> i might miss the first bit of the meeting <T-Bone> same here <zul> but you guys dont need me do you? <T-Bone> same here <T-Bone> ;) <lamont> T-Bone: there's also narufrigginghodo <T-Bone> LOL <zul> i so much hate this program * T-Bone wonders what trick elmo used to
{'channel': 'ubuntu-kernel', 'month': 3}