[12:19] <lamont> so lets see.. do we want to have 00list-25.1* in the 26 upload?
[12:20] <lamont> hrm.. actually, I don't see the atapi patch update either...
[03:00] <zul> hey
[03:01] <zul> so what did i miss?
[04:08] <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...
[04:08] <zul> good idea but we arent redhat
[04:08] <zul> or any rpm based distro
[04:09] <zul> does debian do the same way?
[04:09] <zul> ie how we build our kernel...oh this is channel is logged now isnt it?
[04:30] <lamont> heh
[04:30] <lamont> yeah, should be logged
[04:30] <lamont> t-bone was doing it, I expect fabbione has picked that up and incorporated it into the wiki bound logs
[04:31] <lamont> debian is heading to the same place we are, not sure who is further down the path yet.
[04:31] <zul> it should have big black warning signs
[04:31] <lamont> prior to the 2.6 package, it was actually a kernel-tree and kernel-patch-2.4.27-powerpc type world
[04:31] <zul> eww
[04:44] <zul> nighto
[04:45] <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.
[04:46] <jbailey> mdz: ii  linux-image-2. 2.6.10-25.1    Linux kernel image for version 2.6.10 on PPr
[04:46] <jbailey> iridium:/sys/block/sr0#
[04:46] <jbailey> Sorry, obviously being in the rush to get out caught me. =(
[07:27] <fabbione> lamont:
[07:27] <fabbione> +# this is a hack for Ubuntu buildd's
[07:27] <fabbione> +
[07:27] <fabbione> +if [ -e /CurrentlyBuilding ] ; then
[07:27] <fabbione> +       fork := $(cat /proc/cpuinfo | grep ^processor | wc -l)
[07:27] <fabbione> +       fork := $(expr $fork \* 2)
[07:27] <fabbione> +       export CONCURRENCY_LEVEL := $fork
[07:27] <fabbione> +fi
[07:27] <fabbione> +
[07:27] <fabbione> somethinig like this in debian/rules
[07:27] <fabbione> would speed up the kernel build N times
[07:29] <lamont> fabbione: i386 is 4 way, amd64 2, ppc 1.
[07:29] <lamont> ppc is the blocker
[07:29] <fabbione> lamont: i did test on davis.. -j15 flies
[07:29] <lamont> and the other 2 finish in about 2 hours..
[07:29] <fabbione> still slow but clearly much better than -j1
[07:30] <fabbione> specially if the code is ccached
[07:30] <lamont> yeah - feel free to add the hack...
[07:30] <fabbione> we can give it a shot for 26
[07:30] <fabbione> and see how it goes
[07:30] <fabbione> you get the delta for it, don't you?
[07:30] <lamont> ??
[07:30] <lamont> I get what?
[07:31] <fabbione> delta in build time.. to see if we gain or we lose
[07:31] <lamont> yes] 
[07:31] <fabbione> cool
[07:32] <lamont> last line of the build logs
[07:43] <lamont> lrwxrwxrwx  1 root root 9 Mar 10 06:37 /usr/sbin/sendmail -> /bin/true
[07:45] <fabbione> * committed kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10--patch-26
[07:45] <fabbione> ok 25.2 is up
[07:45] <fabbione> lamont: want to check if the changes to the umask are ok?
[07:47] <lamont> find ~lamont/public_html/Archives ! -user lamont -perm -0200 ! -perm -020
[07:47] <lamont> /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10/patch-26/++revision-lock
[07:47] <lamont> /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10/patch-26/++revision-lock/+contents
[07:48] <fabbione> does sftp actually load .bash_profile?
[07:48] <lamont> dunno
[07:48] <fabbione> because that's where i changed the umask
[07:50] <fabbione> umask 002
[07:50] <fabbione> also in .bashrc now
[07:51] <fabbione> i can try to branch and see if that works
[07:52] <lamont> well, if you go chmod g+w those two files, then _I_ can commit to mainline....
[07:52] <fabbione> sure
[07:54] <fabbione> done.. they are actually 2 dirs..
[07:54] <fabbione> let me try to branch and see if sftp will load .bashrc
[07:55] <fabbione> i can still fix the permissions on the fly
[07:56] <fabbione> looks about right
[08:09] <fabbione> * committed kernel-team@ubuntu.com--2005/kernel-debian--pre26--2.6.10--patch-7
[08:09] <fabbione> lamont: all the syncs/merges should be ok now
[08:09] <lamont> woot
[09:01] <fabbione> lamont, mdz: would i be crossburned if i kill this patch madness for hoary?
[09:02] <T-None> hey fabbione !
[09:02] <fabbione> hi T-None 
[09:02] <mdz> fabbione: not at all
[09:02] <lamont> fabbione: I have yet to see what useful purpose it serves...
[09:02] <T-None> well in my humble opinion i would praise you for doing so ;)
[09:02] <lamont> which is to say, kill away
[09:02] <T-None> lamont: lol
[09:02] <mdz> it should be pretty easy to ensure that it doesn't regress
[09:02] <fabbione> lamont: i am not 100% how make-kpkg will interact with linux-ubuntu-patches
[09:03] <mdz> as long as it still builds and no patches are dropped, it is fine with me
[09:03] <mdz> it should save minutes on the kernel build too :-P
[09:03] <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 :)
[09:03] <fabbione> mdz: minutes? ages!
[09:03] <T-None> hell yes
[09:04] <fabbione> again.. we only build the kernel this way
[09:04] <fabbione> but i am not 100% about the linux-ubuntu-patches
[09:04] <fabbione> and it is used when building from linux-source package
[09:05] <T-None> see yall
[09:11] <Mithrandir> lamont: nah, it's just fine.
[09:19] <fabbione> lamont: i just committed the CONCURRENCY_LEVEL to speed up the build on the kernel
[09:19] <fabbione> on the buildd even
[09:20] <fabbione> that should speed up to Ncpus * 2
[09:20] <fabbione> if the code is ccached we could fork much more
[09:20] <fabbione> but it is dangerous
[09:42] <lamont> heh.. make that a 2-way P3-993MHz box.
[09:49] <lamont> scrollkeepoer
[09:49] <lamont> ECHAN
[10:00] <fabbione> --- orig/rules
[10:00] <fabbione> +++ mod/rules
[10:00] <fabbione> @@ -55,8 +55,7 @@
[10:00] <fabbione> 
[10:00] <fabbione>  .PHONY:                monolith
[10:00] <fabbione>  monolith:      stamp-monolith
[10:00] <fabbione> -stamp-monolith:        stamp-monolith-prepare \
[10:00] <fabbione> -       $(foreach revision,$(revisions),stamp-monolith-$(revision))
[10:00] <fabbione> +stamp-monolith:        stamp-monolith-prepare stamp-monolith-$(revision)
[10:00] <fabbione>         rm -rf $(DIFFDIR)
[10:00] <fabbione>         touch $@
[10:00] <fabbione> if you apply this patch to your debian/rules
[10:00] <fabbione> only the last patch set will be applied
[10:00] <fabbione> killing the patch madness
[10:01] <fabbione> after that this make-substvar is called
[10:01] <fabbione> and it fails
[10:01] <fabbione> debian/make-substvars linux version.Debian debian/monolith/list > debian/substvars.safe
[10:01] <fabbione> Line 1: patch patch-2.6.10-26 is not well-founded
[10:01] <fabbione> Patch for 2.6.10-26 must be listed
[10:02] <lamont> ah, so we need to create the input file that it wants, without bothering to actually apply the patches...
[10:04] <fabbione> kinda
[10:13] <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
[10:13] <fabbione> FUCK
[10:13] <fabbione> FUCK
[10:13] <fabbione> FUCK
[10:13] <fabbione> it uses incremental patches
[10:16] <fabbione> uhuh
[10:16] <fabbione> got it
[10:18] <lamont> feh
[10:18] <fabbione> good night
[10:44] <fabbione> bah
[10:45] <fabbione> i found another bug
[10:45] <fabbione> thanks god it affects only hppa atm
[02:15] <fabbione> baz commit -s'Kill patch madness'
[03:20] <zul> hey
[03:54] <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?
[04:02] <zul> not sure maybe you should ask in -devel
[04:03] <jbailey> Nah, I'll just pull the source and look.
[04:06] <zul> or youo could do that
[04:29] <jbailey> ## DP: Description: restore generic SCSI proc_info function in drivers/scsi/scsi_proc.c
[04:29] <jbailey> That would probably be the one.
[04:35] <zul> oh it was a kernel question...im not awake yet
[04:35] <fabbione> hey
[04:35] <zul> hey fabbione 
[04:38] <jbailey> Heya Fabio =)
[04:38] <jbailey> zul: *lol* =)
[04:39] <zul> fricking palm
[04:40] <fabbione> i am testing the new patch thingy
[04:40] <fabbione> it seems to work fine
[04:40] <zul> which patch thingy?
[04:40] <fabbione> no more 192891821 patch/unpatch
[04:40] <zul> ah good
[04:40] <fabbione> zul: baz update?
[04:41] <zul> ooh you fixed it so it doesnt patch/unpatch a billion times?
[04:41] <fabbione> yup
[04:41] <zul> sweet! 
[04:43] <fabbione> there were several changes to do
[04:43] <fabbione> + an important bug fix
[04:45] <fabbione> hey smurfix 
[04:46] <abelli_> ciao smurfix 
[04:46] <fabbione> smurfix: what was the perfect command to verify the ABI compatibility?
[04:46] <smurfix> fabbione: one sec
[04:47] <fabbione> sure.. also 2 or 3
[04:50] <smurfix> something along these lines ..:
[04:50] <smurfix>  grep vmlinux Module.symvers.old_kernel |sort >/tmp/symvers.old
[04:50] <smurfix> ditto new
[04:50] <smurfix> comm -23 old new
[04:50] <smurfix> must be empty
[04:51] <smurfix> assuming you build with CONFIG_MODVERSIONS
[04:51] <fabbione> where Module.symvers.old_kernel = Systemmap?
[04:52] <fabbione> no
[04:52] <smurfix> fabbione: no, the "Module.symvers" file that's generated by building the kernel
[04:53] <fabbione> yes and we don't ship it
[04:53] <smurfix> Let me check if you can extract that somehow
[04:56] <fabbione> the idea is to automatically check the ABI with the previous kernel at build time
[04:56] <fabbione> previous version
[04:56] <fabbione> now we can also start shipping that file
[04:56] <fabbione> it's not a tragedy
[04:57] <fabbione> if we start shipping it in 26
[04:57] <smurfix> fabbione: The kernel doesn't export that info any more because it now has a built-in relocator
[04:57] <fabbione> from 27 we can add the check at build time
[04:57] <smurfix> so you probably should start shipping it.
[04:57] <fabbione> this would add a Build-
[04:58] <fabbione> this would add a Build-Dep: on the most recent version of the kernel
[04:58] <fabbione> or just on a linux-abi package
[04:58] <fabbione> that can collect all the MOdule.*
[04:58] <fabbione> what do you think?
[04:59] <smurfix> Hmm, better do an abi package.
[05:00] <fabbione> next upload needs to bless a new package anyway
[05:00] <fabbione> so one more or one less won't change much
[05:00] <smurfix> Would be nice to have that available for cross-compiling. You can put the .config files in there too.
[05:01] <fabbione> smurfix: configfiles are in /boot with the images
[05:03] <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.
[05:03] <fabbione> what scares me a bit is how to ensure that we always build against the $previousversion -abi
[05:03] <fabbione> without having to control that manually
[05:04] <fabbione> scenario:
[05:04] <fabbione> upload -1
[05:04] <fabbione> there is no previous -abi
[05:04] <fabbione> so we skip the check
[05:04] <fabbione> and it FTBFS on ppc
[05:04] <fabbione> how do we upload -2 that will check the abi for all arches other than ppc?
[05:05] <fabbione> the code needs to be very smart
[05:07] <smurfix> fabbione: What are you going to do if/when the ABIs don't match?
[05:07] <zul> take a large wooden hammer
[05:07] <smurfix> fabbione: ... or do you decree that any -1 is an ABI change but -2+ isn't?
[05:09] <fabbione> smurfix: FTBFS?
[05:09] <smurfix> fabbione: Well, someties you do need to change the ABI :-/
[05:09] <fabbione> smurfix: clearly the -1 is a new abi
[05:09] <fabbione> yes of course you must change the ABI
[05:09] <fabbione> but an ABI change require also a new control file
[05:10] <fabbione> to reflect that change
[05:10] <fabbione> for example
[05:10] <fabbione> if i start doing heavy patching
[05:10] <fabbione> or security patching to the kernel
[05:10] <fabbione> running a build should be able to tell me if that change will introduce an ABI change
[05:10] <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
[05:11] <smurfix> excluding the -X version of course
[05:11] <fabbione> kinda yes
[05:11] <fabbione> but if for example
[05:11] <fabbione> we are building -1-2.6.10 ver 2.6.10-2
[05:12] <fabbione> i want it to compaer with -1-2.6.10 ver 2.6.10-1
[05:12] <fabbione> if the ABI does not match
[05:12] <fabbione> i want it to FTBFS
[05:12] <fabbione> so that i can prosuce a -2-2.6.10
[05:12] <fabbione> that is the correct way
[05:12] <fabbione> since there is an ABI change
[05:12] <fabbione> i mean.. i know i could do all of this manually
[05:12] <fabbione> but for N arches in N flavours
[05:13] <fabbione> it's a royal pain
[05:13] <smurfix> fabbione: sure, but I fail to see how that differs from what I've been saying
[05:13] <fabbione> than probably i misunderstood you :-)
[05:13] <fabbione> but ok
[05:17] <smurfix> Let's say you create a linux-kernel-abi package
[05:18] <fabbione> yes
[05:18] <smurfix> some file in it contains the magic string "2.6.10-4"
[05:19] <fabbione> it would need to contain the ABI version too
[05:19] <fabbione> ok
[05:19] <smurfix> I thought that is* the abi version
[05:19] <fabbione> yeah i get you now
[05:19] <fabbione> i was thinking in terms of 2.6.10-1 (starting from scratch)
[05:20] <smurfix> Doesn't really matter, you'd get the magic string "2.6.9-5" or whatever
[05:20] <fabbione> yup
[05:20] <smurfix> different, so skip check.
[05:22] <fabbione> right
[05:23] <fabbione> that would solve all the problems
[05:23] <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.
[05:24] <fabbione> it won't match the ABI and therefor skip the test
[05:24] <fabbione> because hte next upload will have a different ABI
[05:24] <fabbione> good idea
[05:26] <smurfix> The only problem I see is how to build-dep on the latest l-k-a package
[05:26] <smurfix> unless you just want to wing it ;-)
[05:26] <smurfix> (probably not a good idea, now that I think about it)
[05:27] <fabbione> well the first upload will create the package
[05:27] <fabbione> from the second one we will build-dep on it
[05:27] <fabbione> in case of troubles we can always remvoe the build-dep
[05:28] <fabbione> and unroll the loop
[05:28] <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
[05:29] <fabbione> that shouldn't be a problem
[05:29] <smurfix> so a mistaked ABI change from 2->3 might be missed
[05:29] <fabbione> the ABI is supposed to be the same between first, second and third
[05:30] <smurfix> Umm, it's supposed to be the same from -2 to -3, but I wan't talking about that
[05:30] <fabbione> oh you mean if there is an ABI change between -1 and -2
[05:30] <fabbione> and we upload -3
[05:31] <fabbione> and there can still be abi from -1 in the buildd
[05:31] <fabbione> at that point the ABI check should be skipped
[05:31] <fabbione> and it will due to the magic file
[05:32] <fabbione> but yes.. that can actually skip a test that should be done
[05:33] <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
[05:33] <smurfix> Dunno whether you'd want to go that far.
[05:34] <fabbione> well preparing the source package is still manual
[05:34] <fabbione> and we can still hack on it
[05:35] <smurfix> OK, then you need to remember never to forget to update the dependency when you prepare a new version. ;-)
[05:35] <smurfix> or write a script that does it. Good enough I'd say.
[05:35] <fabbione> smurfix: that is why we have a control.stub that we can mangle as we like :-)))))
[05:39] <fabbione> smurfix: the next question would be.. are you for this challenge?
[05:39] <fabbione> ;)
[05:40] <smurfix> fabbione: gah  ;-)   I need to fix the keyboard chooser first
[05:40] <fabbione> ehhehe
[05:40] <fabbione> fair enough
[05:40] <smurfix> fabbione: it needs a confirmation dialog
[05:42] <fabbione> i think we can postpone this feature to hoary+1
[05:42] <fabbione> even if it would make pitti's life 1029292 times simpler
[05:42] <fabbione> also for us that will have to maintain this kernel for 18 months
[05:57] <fabbione> last script to test the anti-patch-madness fix
[05:57] <fabbione> s/to/for
[05:59] <smurfix> fabbione: If for hoary, when would you need it?
[05:59] <fabbione> within monday
[05:59] <fabbione> but i guess i can try to work on it
[05:59] <fabbione> i will have the weekend free!
[05:59] <fabbione> YEAH YEAH
[06:00] <fabbione> wife -> her sisterm
[06:00] <fabbione> sister even
[06:12] <fabbione> lamont: don't worry
[06:12] <fabbione> i won't upload very soon
[06:12] <fabbione> not with these big changes
[06:12] <fabbione> i am still testing some stuff
[06:12] <lamont> fabbione: it means that you're baz bitch for a few days... :-)
[06:12] <fabbione> i might get up -26 to get the ATAPI thingy in again
[06:13] <fabbione> and the new idiotify patch
[06:13] <fabbione> and the antipatchmadness
[06:13] <fabbione> the ABI stuff can come later
[06:27] <fabbione> ok confirmed 100%.. the patch madness is gone
[06:27] <fabbione> all the scripts are working
[07:00] <zul> heh im almost always here
[07:13] <zul> whoa...224 changes in the last day
[07:45] <mdz> changes?
[07:46] <zul> in linus bk tree
[07:52] <lamont> busy boy
[07:53] <zul> well with the g5 he must be :)