=== mxpxpod [n=bryan@unaffiliated/mxpxpod] has left #ubuntu-kernel ["Leaving"] [06:09] morning === fabbione starts unfucking the baz repo === JaneW [n=JaneW@196.36.161.235] has joined #ubuntu-kernel [07:43] Mithrandir: so.. why do we need unionfs udebs? [07:44] for the live cd [07:44] https://wiki.ubuntu.com/LiveCDFeatures [07:45] ok [07:45] i am unfucking the baz repo now [07:45] to resync with the last 2 kernel uploads [07:46] and after that we can open devel dances again === fabbione powers up the sodomotron and points it towards baz --'s === JaneW [n=JaneW@196.36.161.235] has joined #ubuntu-kernel === Mithrandir [n=tfheen@c5100BC63.inet.catch.no] has joined #ubuntu-kernel === Mithrandir [n=tfheen@c5100BC63.inet.catch.no] has joined #ubuntu-kernel [08:44] fabbione: so you've added unionfs now? [08:44] or should I? [08:45] Mithrandir: i am still branching and merging... [08:45] ok [08:46] Mithrandir: but i can do it.. so don't worry about it [08:47] cheers === ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,11--2.6.12 [08:50] there [08:50] baz resynced [08:54] is there anything explaining what the logic in the version string is? :-) [08:54] pre <- prerelease [08:54] X <- hidden abi number [08:55] ,11 <- next deb version [08:55] prerelease as in "not yet uploaded", not "prerelease from kernel.org"? [08:55] not uploaded yet [08:55] and what do you mean by hidden abi number? Might break multiple times before next public breakage? [08:56] hidden abi is a trick to avoid more than a devel branch... [08:56] example: [08:56] when we upload 6,10 it means ABI =6 ver 10 [08:56] but during the devel cycle of 11 [08:57] we don't know if the abi is going to break [08:57] so you can't name the pre branch as 6,11 [08:57] so we hide it [08:57] ok [08:57] because it might easily land as 7,11 [08:57] look at preX,Y as HEAD [08:58] where we all commit [08:58] mm [08:58] once it's ready we merge it mainline--2.6.12 [08:58] from there we branch the tag release and the next pre [08:58] don't ask me why this schema [08:58] lamont did create it in early stage :) [08:58] but clearly merging from other repos is ok [08:59] it makes some kind of sense, I guess. [08:59] if I'm touching stuff, do you prefer me to commit into the kernel-team repo directly or work in my own space and then later merge it when it's ready? [09:00] Mithrandir: i don't care either way [09:00] if you keep your repo, you need to ping me manually for merge or merge yourself [09:01] but kernel-team@ is supposed to be kept "working at all times" or are temporary breakages ok? (I presume the former) [09:01] but if you commit directly, in most of the cases your changes will be test-builded by me each time i do a change [09:01] well the former is better, but if it breaks it's not a tragedy [09:02] ok [09:02] let say that i don't mind "it did break by mistake" [09:02] but breaking it on purpose i am a bit less happy [09:02] ok [09:02] or at least tell me in advance :) [09:03] I'm fine with doing on-purpose breakages in my own space. :-) [09:04] Mithrandir: btw.. unionfs is/should be available on all arches [09:04] when you have one module only in a list, mark it as ? is pointless [09:04] because kernel-wedge will fail later with an empty udeb [09:05] so either is everywhere, or you need to create a per arch list [09:05] ok [09:05] if there is more than one module and one is available everywhere, than it makes sense to have other optionals [09:05] but iirc unionfs is available on all our kernel images [09:05] 'k [09:11] is there a bug assigned for unionfs udebs? [09:16] not to my knowledge [09:16] ok [09:17] * update pristine tree (kernel-team@ubuntu.com--2005/kernel-debian--preX,11--2.6.12--patch-1 => kernel-debian--preX,11--2.6.12--patch-2) [09:17] this is the commit you want to look at [09:21] Jeg er s travlt og der kun i frst dag p arbejde === fabbione shows that he is going to danish class now ;) === chmj [n=chmj@196.36.161.235] has joined #ubuntu-kernel [09:25] thanks [10:02] should (udeb) modules call depmod -a in their postinst? [10:02] no idea.. kernel-wedge takes care of creating that stuff [10:03] oh well, apparently it doesn't. I'll add a workaround in casper, then [10:04] i think depmod -a is executed after all kernel modules have been downloaded [10:04] but i dunno about casper... [10:04] that's anna taking care of that [10:04] or at least it should [10:10] I've added a workaround and I'll speak with Colin once he's back again [10:43] live cd testing takes tiiiiime [10:43] eheheh [10:43] i am doing a test build to create the unionfs udeb [10:44] is unionfs supposed to be the slowest thing since sliced bread? [10:45] no idea [10:46] I think something I did made debconf unhappy [10:58] that's not difficult :) [10:59] I need to find something to generate Release files for me. [11:23] apt-ftparchive release seems to work [11:27] yup.. i use it here :) [11:48] (breezy-chroot)fabbione@davis:~ $ dpkg -c unionfs-modules-2.6.12-6-powerpc64-smp-di_2.6.12-6.11_powerpc.udeb [11:49] -rw-r--r-- root/root 1718210 2005-08-15 09:41:53 ./lib/modules/2.6.12-6-powerpc64-smp/kernel/fs/unionfs/unionfs.ko [11:57] cheers [12:48] fabbione: when can we have that in the archive? [12:49] fabbione: I would really like to have it in quickly so we can get some unionfs testing [12:50] since I just uploaded a casper which needs it. [01:01] Mithrandir: meh... in a few days :/ [01:02] you should have told me it was urgent :/ [01:02] fabbione: can I push a new version up with just that small change? [01:03] Mithrandir: let me see a couple of things... [01:03] i might be able to upload today... [01:03] that'd be great. :-) [01:03] sorry about the miscommunication [01:03] yeah but it means pushing a big bunch of security fixes for the next upload... [01:08] we also need elmo/mdz for NEW love... [01:08] the new udeb will stall buildd -> archive movement [01:09] argh, true :-( [01:10] can we see when mdz gets around in a few hours? [01:10] i have no problems with it, but i must leave around 3:30 pm [01:10] (our time) [01:11] so i can upload.. (untested) but you need to follow up with mdz [01:14] anyway.. food now :) [01:16] ok, cheers [01:18] fabbione: I'm going to have patches to feed you from laptop testing [01:18] Need to do a bit more back and forth with upstream on a couple first, though [01:32] mjg59: ok, but don't wait too long [02:03] we need to update heaps load of stuff in the kernel [02:03] TheMuso: [02:03] bah [02:03] SO : [02:03] 1) i am going to upload -6,11 basically untested... [02:03] 2) NOBODY please plan to push URGENT stuff for a few days that needs an upload yesterday [02:05] push but wait... === swarm [n=swarm@host124-43.pool8253.interbusiness.it] has joined #ubuntu-kernel [02:15] fabbione: actually, you don't need to hurry with the kernel, my casper upload got rejected. [02:17] Mithrandir: ok! [02:17] perfect [02:17] that will give me the time to break it in unreasonable new ways :) === zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [02:18] morning [02:18] hey zul [02:20] hey fabbione good vacation? [02:22] fabbione: I'd love it if you can get it in a couple of days, though. [02:22] Mithrandir: 2/3 days should be fine.. [02:22] zul: more or less [02:23] zul: i saw you missed me :) [02:31] heh... [02:31] at little...but not much [02:31] heh [02:32] zul: do you have anything that i need to merge? [02:32] yeah a couple of bug fixes from bugzilla [02:33] its in my arch under ,9 [02:33] uh...we are at ,11 now? [02:33] zul: mind to update to ,11 ? [02:33] yes. [02:33] .11 [02:34] zul: i did import this morning the 2 uploads that have been done outside baz [02:34] ok [02:35] sigh gimme a sec [02:35] take your time [02:35] i will leave in less than one hour [02:35] so i will defenetely not upload today [02:36] ok good because im at work right now [02:36] fabbione: the i386 biarch compilers are in the archive, hint, hint ... [02:37] doko: are you hinting me that you just offered volunteer to build the kernel? [02:37] since you got biarch done, you must have more spare time now :) [02:39] is lrm in baz? [02:39] doko: more seriously.. i need to build an amd64 kernel on i386.. [02:39] right? [02:39] Mithrandir: nope.. lrm is crap.. we don't want it :) [02:39] doko: if so.. what is the usecase for it? [02:40] fabbione: ok, since I need to fix it up a bit. It's br0ken. [02:41] Mithrandir: eheh ok [02:41] fabbione: i just branced and merged my stuff in my arch so my changes are in X,9 in my arch [02:41] zul: ok... can you just branch to ,11 ? [02:42] so we work on same versions? [02:42] it's already confusing enough :/ [02:43] ok..will do on my break [02:45] zul: thanks [02:46] fabbione: use case is: install i386 on amd64 to have better 32bit compatibility, and be able to do things for 64bit as well, i.e. a chroot === fabbione scratches his head... [02:47] you mean installing a 64bit kernel with a 32bit userland? [02:47] yes [02:47] is that possible ? [02:47] chmj: yes [02:48] doko: i *THINK* i can do it... [02:48] but i won't make more than one flavour... [02:48] only a generic kernel [02:48] that also means bloating the i386 CD with udebs... [02:48] fabbione: sure, that should be sufficient [02:48] did you mention that to Kamion? [02:48] because it's another kernel to ship... [02:49] no, not yet. how much is that in size? [02:49] but at least it's mentioned on our ToolchainRoadmap [02:49] doko: a bunch of MB [02:49] changes that needs to be done in the installer [02:49] and several other things... [02:50] it's not exactly trivial to do all of the above [02:50] ouch [02:51] and for sure i am not going to do that in the installer while Kamion is away [02:51] i...dislike...sybase === JaneW [n=JaneW@196.36.161.235] has joined #ubuntu-kernel [03:11] YAY for the ABI change! [03:14] -+#define OCFS2_BUILD_VERSION "0.99.17" [03:14] ++#define OCFS2_BUILD_VERSION "1.1.0" [03:17] Mithrandir: whatever fix you have for lrm, better you upload it asap [03:17] next kernel upload will bump the ABI [03:17] fabbione: it's already uploaded. [03:17] ah cool [03:19] let see in which wonderful ways the kernel is going to break :) [03:19] i already noticed a target that goes banana with the debian version made of 2 digits :) [03:20] heh [03:21] impressive... [03:21] the force is strong in the bumpabi target... === doko_ [n=doko___@dsl-084-059-072-034.arcor-ip.net] has joined #ubuntu-kernel [03:31] later fellas... === fabbione -> danish class === lamont-away returns [04:43] fabbione: I did it that way because I sometimes forget to tag... But I almost always remember to branch for the new version [04:43] or rather, I'm far less likely to release from non-mainline than I am to forget to tag from mainline === Seveaz [n=seveas@seveas.demon.nl] has joined #ubuntu-kernel === BenC [n=bcollins@206.246.247.150] has joined #ubuntu-kernel [05:39] fabbione: "x86_64 kernel on i386 system" on u-u ml [05:46] hey BenC [05:46] hey [09:03] hey BenC [09:04] welcome to the team [09:04] BenC: i am going to have dinner and i will be back later (if wife will allow me ;)) [09:04] so we can talk a bit [09:12] you are so whipped [09:12] but thats ok so am i [09:15] ok === lamont [n=lamont@15.238.5.9] has joined #ubuntu-kernel [09:21] hey lamont [09:21] hey zul [09:22] /win goto #ubuntu-devel [09:22] Hrngh. [10:19] re [10:21] BenC: still around? [10:23] lamont-away: ping? [10:23] bah something is wrong with this client === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-kernel [10:26] sup> [10:26] lamont: did you read my email about util-linux patch? [10:27] not yet === lamont is still burried [10:27] ok [10:28] generally, I've tried to not deviate from upstream unless there was good cause. I haven't really looked at the 200+ line patch, but it seems to be relatively isolated in it's changes... something as invasive as the hurd patch won't be in until upstream takes it. [10:29] lamont: the patch is much smaller than it looks like [10:29] right [10:29] due to static int foo it needs to move a function a few lines above [10:29] it looks to be like it just calls the helper for the fs type if said beast exists [10:29] ah, even better [10:29] exactly [10:30] so it's pretty simple in itself [10:30] let me look at it tonight and I'll upload to both [10:30] and fire it upstream [10:30] sure... [10:30] i think Manish did try to get it upstream with no success [10:30] or no response from upstream.... [10:31] right - upstream has bounced around a bit... [10:31] who is upstream? [10:31] vietse? [10:31] it might be semi-stable, esp since there's a new upstream version now as well [10:31] adrian bunk, iirc [10:31] ah... [10:31] the debian maintainer before me took it over upstream recently [10:31] ok [10:32] btw.. we are bumping ABI for the next kernel upload [10:32] so if you have something intrusive to push, it's the right time [10:33] AH GREAT.. the second sparc buildd managed to die in less than 12 hours === fabbione sighs [10:36] mtg === lamont needs to isolate the ia64 acpi issue, but that will be later this week at the earliest. likelihood of an ABI bump is >0 [10:40] just because acpi seems to be intrusive [10:40] lamont: if you build with ACPI disable, does it boot? [10:40] bah i come back to talk with Ben and he disappeared :) === fabbione will teach BenC the way of the dark side of the force === BenC [n=bcollins@206.246.247.150] has joined #ubuntu-kernel [10:48] fabbione: ping [10:59] BenC: pong [10:59] i tought you left... [10:59] and i was close to go away :) [11:01] sent you an email [11:01] yeah i just saw it... [11:01] i think there are 2 groups of bugs we are interested in.. [11:01] USB and ACPI related [11:01] USB seems to be a royal pain [11:01] yeah, I saw a lot of ACPI related bugs [11:01] ACPI is well.. mjg59 crack [11:02] but it still needs extra love... [11:02] on the other side we are already in Feature Freeze for Breezy [11:03] so we need to avoid extra breakage if we can [11:03] right [11:03] .10 was a crappy release [11:03] too many patches coming from too many upstreams [11:03] .12 is looking quite good compared [11:03] are there any show stoppers, or are the issued mainly non-regression things we want fixed? [11:03] show stoppers none that i am aware of... [11:03] any serious regressions? [11:04] there is a Serial PATA patch that is sort of a problem [11:04] PATA? [11:04] or did you mean SATA? [11:04] we had a patch in hoary pulled from atadev for a mistake [11:04] #13298 [11:04] (and other related bugs) [11:05] PATA... [11:05] zul: you need to learn to write Subjects in the email.. see.. i can't even copy paste without looking stupid :) [11:05] hehe [11:06] the issue is that jgarzik almost crossburned me for inclusion of that patch [11:06] because it can cause data corruption [11:06] now everybody is including it and we are not.... [11:06] have the libata head patches been tested? [11:06] and tbh i have no fucking clue who to trust [11:06] they have been in hoary.... [11:07] right now they are not in breezy [11:07] because i did expected to find them in .12 [11:07] while they are not... [11:07] anyone besides the submitter able to test things? [11:07] not from our team [11:08] hardware specific testing....the downside to all this :) [11:08] ok, I'll put that on my list [11:08] ehhe no shit! [11:08] anything else? [11:08] btw, I have my G4 installed with ubuntu now [11:08] so I can test some ppc32 things [11:09] ah nice [11:09] it looks like Jeff didn't make too much noise on redhat bugzilla... [11:09] but the bug explains that: [11:09] it's UP and only 512megs of ram, which is the stable type system that doesn't seem to show in most reports about ppc [11:09] a) ghetto pulled the patch from jgarzik HEAD [11:10] b) we pulled from ghetto [11:10] c) fedora and redhat did pull it from us [11:10] d) jgarzik that works for RH got pissed [11:10] GO FEDORA! [11:10] who/what is ghetto? [11:10] gentoo [11:10] ah, ok [11:10] dude.. you should know that by amok ;) [11:11] lol [11:11] Amok, the wiki of IRC [11:11] so true :) [11:12] haven't worked with ATA much, but libata is a kernel driver library right? (not userspace) [11:12] yup [11:12] the patch is much much cleaner than the old one [11:13] it seems safe to me [11:13] BenC: did you manage to strech your wings on baz? [11:14] http://sourceware.org/ml/binutils/2005-08/msg00190.html <- (from doko [11:15] BenC: but if you feel lucky i have a few tons of security bugs for hoary :) [11:17] you can dump as much on me right now as you like...haven't been here long enough to be "busy" :) [11:17] BenC: ahahah [11:17] enjoy it till you can [11:19] BenC: get a bit familiar with the kernel build.. we have a bunch of extra features that debian does not have [11:19] like the ABI checker.. [11:20] and some extra madness in debian/rules... [11:20] like we build all from one source... [11:20] including udebs [11:24] fabbione: debian now builds all from one source, btw.. but not udebs. [11:25] dilinger: uh yeah... [11:25] sorry forgot about that [11:33] To: bcollins@kernel.org [11:33] sweet [11:34] ehehhe [11:35] i have the BAD feeling i just managed to fuck up the sparc buildd.... [11:35] impossible, sparc is unfuckable [11:35] i can manage.. [11:35] :) [11:36] ah here it is [11:39] no shit it doesn't show anything on console.. [11:39] the cable is disconnected.... [11:42] dists/breezy/main/binary-sparc/:Bus error [11:42] i guess sid is sort of broken... [11:47] what command caused a bus error? [11:51] apt-ftparchive [11:51] after a glibc upgrade... === fabbione attempts a downgrade [11:53] c++ [11:54] dpkg: /lib/libc.so.6: version `GLIBC_2.3.4' not found (required by dpkg) [11:54] AH CRAP [11:55] i should have downgraded dpkg first.... [11:55] SEE I CAN MANAGE TO DESTROY SPARC! :) === fabbione tries to remember how to unfuck that [11:58] ar/tar [11:58] maybe dpkg-deb will work [11:59] yeah.. [11:59] ar x === fabbione heads to bed [12:02] night guys [12:02] cya tomorrow