=== zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === cc [~cc@byte.fedora] has joined #ubuntu-kernel [05:54] yay [05:57] lamont: should we start branching 2.6.12? [05:58] i have the orig and a few changes ready for it [06:00] fabbione: works for me [06:00] probably should start with --mainline--2.6.10 and branch to --mainline--2.6.12 [06:00] ok.. what policy do you suggest? [06:00] policy? [06:00] sorry.. s/policy/way to proceed/ [06:01] hrm... [06:01] baz switch kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10 [06:01] baz branch kernel-team@ubuntu.com--2005/kernel-debian--pre1--2.6.11.90 [06:02] and make it 2.6.12_2.6.11.90-1 [06:02] then the actual ship of 2.6.11.90-1 becomes a baz branch ....--mainline--2.6.11.90 [06:02] and if we get bulky enough to roll another .orig.tar.gz, it becomes 2.6.11.91, etc. [06:03] hmm sounds about right [06:05] are you going to do it? or should I? [06:05] 2.6.11.90? [06:06] dilinger: aka 2.6.12rc2 [06:06] is that a -bk snapshot or something? [06:06] ah [06:06] just to keep some space before 2.6.12 [06:06] right [06:12] since we are going to switch to gcc4, it is completely pointless to keep working on 2.6.10 [06:12] much better to get ready with .12 [06:12] break it early > * === dilinger nods. hooray for breaking stuff. [06:30] fabbione: either way, if you haven't already done it, I'll do it now [06:30] no i didn't [06:30] doing it now [06:30] i am fixing the last debian/rules glitches [06:30] where are we going to put the orig.tar.gz then? [06:31] major and wrong assumption is that linux-source-$(pkgnameversion) ($(debversion)) are the same [06:31] lamont: i will put it on people as soon as it is ready [06:31] that will take like 20 seconds [06:32] right now i am working on getting debian/rules to understand that there is a difference [06:32] right [06:32] otherwise there is no way you can even get to edit a patch === ..[topic/#ubuntu-kernel:lamont] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre35--2.6.10 playground: kernel-debian--pre1--2.6.11.90 | There are no kernel bugs.. only broken hardware | bk is dead [08:01] dpkg-deb: building package `linux-image-2.6.12-1-386' in `../linux-image-2.6.12-1-386_2.6.11.90-1_i386.deb'. [08:03] and no.. [08:03] it's not .12rc2 yet [08:04] just fixing the debian/rules insanity adding more mess === T-Bone [~varenet@T-Bone.developer.debian] has joined #ubuntu-kernel [10:12] ola! [10:14] fabbione : ping? [10:14] hi T-Bone [10:15] howdy! === dholbach [~daniel@td9091b95.pool.terralink.de] has joined #ubuntu-kernel [10:15] pretty busy [10:16] fabbione : ok, might discuss that later then. Just wanted to let you nkow in case you haven't noticed we've had some discuss with dholbach and lamont yesterday about universe kernel images [10:16] T-Bone: no, i haven't read the scrollback [10:16] and i need to do something for the next hour or so [10:17] ok np [10:17] bbl [10:18] fabbione : btw, i got my hands on a bunch of sparc and ultrasparc systems, i might give a shot at Ubuntu sparc this week end (and maybe provide build power if needed :) [10:18] fabbione : you see, i don't hate you 8) [10:21] T-Bone: there is no way to install sparc atm. sparc.u.c is out of sync (but not due to the buildd). i will explain later [10:21] i have to run [10:22] bye fabbione === Lathiat has several sparcs also === T-Bone watches hppa getting even closer to 94% up-to-date, curses kde-poopie for screwing 1 or 2 more % === Thejeste1 [~sbroeckli@212.184.217.162] has joined #ubuntu-kernel === Thejeste1 [~sbroeckli@212.184.217.162] has left #ubuntu-kernel [] [11:04] re [11:05] re === T-Bone is reading the lengthy article on kerneltrap aboug RCM in Linux [11:06] the problem with sparc are multiple [11:07] shot [11:07] +o [11:07] one I need to able to give you access to w-b [11:07] or move w-b somewhere that all can access [11:07] w-b? [11:07] if you want me to participate to the build effort, yeah [11:07] my sparc is special cased. [11:07] does sparc have trouble keeping up? [11:07] it's the only external buildd allowed to upload binaries [11:07] Mithrandir: not for main [11:07] i have a Ultra30, a SS20 and potentially a U5 [11:08] but for breezy we will need more than one.. that's for sure [11:08] maybe more will come up in the next few days [11:08] the major issue would be to sign the packages and upload them to archive [11:08] since none of you is allowed to [11:08] I have two U5s I could use. [11:08] ? [11:08] fabbione I am [11:08] T-Bone: no, not binaries. [11:08] T-Bone: you are not allowed to upload binaries [11:09] only sources [11:09] Mithrandir : i have a key that is [11:09] s/is/will be soon/ [11:09] for hppa binaries [11:09] the sparcbuildd has a specially blessed for sparc [11:09] T-Bone: yes.. and only hppa [11:09] fabbione: didn't Mark say we would buy buildds for arches which were maintained properly? [11:09] Mithrandir: that's where i was going now [11:09] Mark already agreed on buying sparc buildd's [11:09] fabbione : then if i can do hppa, i guess it's a matter of turning the right knob to do sparc as well :) [11:09] given that there is enough community interest [11:10] so my plan was to get sparc announced immediatly after hoary [11:10] fabbione : tell him to sell ia64 ones and buy sparc/hppa instead ;] === T-Bone ducks swiftly! [11:10] *no comments* [11:10] fabbione : amusingly enough, lamont and I plan to do the same for hppa :} [11:11] if there will be enough hits on sparc.u.c [11:11] than i will ask Mark to give the final green light for the buildds [11:11] fabbione: so we should set up a box to continously reinstall and upgrade and stuff? [11:11] Mithrandir: that would be perfect [11:11] d-i has received only my love [11:12] and it works here [11:12] but i have no idea if X does for example [11:12] since my machine is headless [11:12] i have a monitor for mine [11:12] and i can steal a keyboard from the UCC [11:12] fabbione : if you need help to build hoary's universe, i can probably do something quite similar to what I've done for hppa: build all binaries, make them available for you somewhere and let you do the bad upload thing... [11:12] Lathiat: problem is (as i wrote before) that sparc can't be installed atm [11:12] right [11:12] why is that? [11:13] fabbione : please explain that, you told me the installer was working... [11:13] T-Bone: there is very little point in doing it [11:13] yeah the problem is that the server where sparc.u.c is hosted [11:13] is too overloaded [11:13] fabbione : your call. I'm offering CPU power that's all ;) [11:13] fabbione: you host sparc.u.c home? [11:13] perhaps that can be rectified [11:13] and basically the sparc packages are built, uploaded but not integrated into that archive [11:13] s/home/at &/? [11:13] Mithrandir: no. it's at the DC [11:14] T-Bone: there is more than that. Once sparc is approved, lamont will have to rebootstrap it from scratch anyway [11:14] T-Bone: like for hppa [11:14] ? [11:14] simply because all the binaries must come from the DC [11:14] it's a rule dude... [11:14] a stupid one [11:14] i disagree [11:15] both of you can disagree as much as i did [11:15] (i mean i disagree that its a stupid rule) [11:15] Lathiat: ah ok [11:15] i know why it's there [11:15] *shrug*, it's a rule and we play by it. It's not like it really matters much anyhow. [11:15] there are other ways to achieve what's intended [11:15] thus a stupid rule. My call. [11:15] Mithrandir: well it does to a certain degree [11:16] T-Bone: and what is intended? [11:16] fabbione : security [11:16] i suppose [11:16] that is only one of them. [11:16] fabbione: it matters somewhat security and buildability-wise, but it doesn't matter for the port per se. [11:16] it's just a rebuild. [11:16] the other being buildd system not being exportable yet [11:16] fabbione : that might cahgne at some point [11:16] Mithrandir: our buildd's compile with different options [11:17] lamont had a hope for that, given how we plan to deal with hppa [11:17] T-Bone: whatever.. until that part is not exported, we need to play by the rule [11:17] so the rebuild is mandatoru [11:17] mandatory [11:17] fabbione : maybe you shouldn't try too hard for now then [11:17] fabbione : lamont told me he had good hope to get it changed *soon* [11:18] T-Bone: eh? [11:18] given i host 99% of the hppa build power... [11:18] and given lamont's attachment to hppa ;) [11:18] T-Bone: well.. when it will change we will take appropriate actions.. right now i am happy as it is [11:18] also [11:18] a rebuild at the DC is way faster than what you do at home/uni [11:18] ? [11:18] so if they decide to rebuild sparc i am not going to say no.. [11:18] i simply can't care less :) [11:19] T-Bone: i have one sparc one cpu [11:19] T-Bone: the buildds at the data centre are way faster than any U5s we can muster [11:19] fabbione : ah sure. I was talking about hppa there :) [11:19] if Mark buys the buildd there will be at least 4 boxes with 8 CPU, GIGS of RAM and tons of disks [11:19] yum ;] [11:19] though [11:19] so basically.. rebuilding a port is a breeze [11:20] what's the point of 8CPU when the autobuilder does single threaded build? [11:20] unless... yours do multithreaded ones... :P [11:20] it can run 8 sbuilds [11:20] T-Bone: sbuild can fork.... === T-Bone sighs [11:21] T-Bone: time to RTFM? [11:21] fabbione : i'm sorry, default setup can't simply fork [11:21] for you need several chroots to do that [11:21] T-Bone: yes it can :) [11:21] and it's quite a pain to setup [11:21] and no.. you don't need more than one chroot [11:21] oh? And how do you manage builddeps? [11:22] afaik it doesn't attempt to build packages with build-dep in conflicts [11:22] that's not the point [11:22] what is the point than? [11:22] you have package A with set a of build deps, package B with set b [11:22] you build both packages at the same time [11:22] yes [11:23] if package A uses some in set b without declaring it, it'll build fine anyway [11:23] and that's the least of the worst examplse i can come with [11:23] the cases that something like this will happen is very low [11:23] i think such an example would already be enough to make lamont go nuts [11:24] fabbione : this breaks the whole point of sbuild/chroots [11:24] which is: build package in an isolated environment with the exact set of build-deps they need [11:24] T-Bone: see.. that's why you don't fork always [11:24] that's why you *never* fork [11:25] that's why RTFM won't help. Such a feature, if existing, shouldn't be used :P [11:25] T-Bone: wrong [11:25] T-Bone: sbuild isn't a tool for checking build-deps, pbuilder is. [11:25] Mithrandir : builders don't use pbuilder [11:25] T-Bone: so? [11:25] Mithrandir : we're talking about buildd/sbuild setup here [11:25] T-Bone: I know, but the buildds are there to build packages, not catch all kinds of random errors. [11:25] give me a reference in Debian policy that says that buildd should be used to verify Build-Dep [11:26] and i will agree with you [11:26] anyway, you have your views and i have mines, and unless lamont tells me i'm wrong i wont change my mind, for i'm French and stupid (which is the same, heh? :) [11:26] Mithrandir wrong [11:26] T-Bone: reference? [11:26] fabbione : if it wasn't the case, we would use sources-dependencies on ubuntu, and we don't [11:27] T-Bone: well if you don't even bother to see other people truth.. just wait for lamont next time [11:27] source-dependecies? [11:27] fabbione : lamont made it very clear that we want to *fix* invalid sourcedeps, not *workaround* them [11:27] ok i am not going to discuss this anylonger [11:27] neither do i [11:27] i take my info from the guy running the buildds, i think that's authoritative enough :P [11:28] so back to topic, i can offer sparc cpu, and maybe some help to the extent of my limited time. [11:28] ok thanks [11:28] i will keep that in mind [11:28] i want to see input from the community before start building a big sparc infrastructure [11:29] certainly the best thing to do [11:29] are newer sparcs quieter than the old ones? === Lathiat laughs [11:38] fabbione : on a different topic, i've been reading the posts about patches on the k-t m-l, why would we move away from dpatch? [11:39] because it's hutter crap [11:39] huh? [11:41] can you illustrate? [11:41] dpatch is ok when you handle one source/one build [11:42] in our situation where we might need to start building different sets of packages with different patches, is a royal pain in the ass [11:42] ah [11:42] i thought we aimed at building all kernels from the same source? [11:42] yes we do [11:42] of course if it's no longer the case i understand dpatch is a mess [11:42] but not all kernels get the same set of patches.. like *cough*hppa*cough* [11:43] that should be fixed in breezy [11:43] and when i started working on xen packages [11:43] s/should/will/ [11:43] dpatch could fairly easily be extended to use a arch-specific list of patchs if that exists. [11:43] i realized how bad it is to add per image patches [11:43] Mithrandir: it does already, but not like we need it [11:43] Mithrandir: that would require more work from us [11:43] and it would break "one source to rule them all", if i get it right [11:44] T-Bone: no.. it won't break that, but it gets messy to maintain afterwards [11:44] T-Bone: just checkout the experimental branch i did for xen [11:44] and look at it [11:44] you will understand yourself what i mean [11:44] fabbione : err, so you consider that building different kernels with different patchsets doesn't break "build all on the same source" ? [11:44] ok will do [11:45] we need to redesign the build system from scratch in a more neat way [11:45] like, *again*? ;o) [11:45] T-Bone: no. because you grab one source and build everything out of it [11:45] T-Bone: it is still the same source [11:45] fabbione : ah ok. My understanding was that we wanted all kernels to be exactly the same [11:46] T-Bone: that is not possible due to kernel upstream [11:46] if i had to apply to your concept, hppa wouldn't exist [11:46] so better you accept my view of it :) [11:46] fabbione : well, not really: take for example the hppa mess, if you build everything but hppa on the current package set, then add the hppa patches to build hppa images, hppa kernels have several *major* changes in them [11:47] fabbione : yeah you're right ;) [11:47] T-Bone: that's because hppa is not fully merged upstream [11:47] fabbione : my understanding is that we would only work on fully merged architectures :) [11:47] baz rm debian/*/hppa/* [11:47] but i can see this is wrong in the long run [11:47] ah shit.. wring window [11:47] lol [11:47] fabbione : our current patchset to upstream is <200k now [11:47] uncompressed [11:48] T-Bone: no.. the issue of having one source is for security related reasons [11:48] fabbione : yeah i got that as well [11:48] one upload will trigger the rebuild everywhere [11:48] it is just to be more practical [11:48] fabbione : but then, if we differentiate patches accross kernel builds, it's gonna be quite painful to track this, no? [11:48] s/this/security changes/ [11:48] T-Bone: can you please checkout the branch, look at it and read again what i said? [11:49] security changes go in for everybody [11:49] i'd love to, i'm at work atm... :P [11:49] if there is a security patch specifically for hppa [11:49] it is not my business to get it in... [11:49] there are porters for a reason [11:49] eww [11:49] that should take care of it [11:49] nogood [11:49] + usually security fixes are upstream the same day [11:49] so [11:49] i don't really see this problem you are trying to create [11:50] if there isn't one guy knowning everything about security fixes, this is likely to cause issues in the long run [11:50] really.. this is not a problem [11:50] right [11:50] agreed [11:50] my idea was that some arch-specific patches might introduce security issues. But then again it's a porter's issue [11:50] exactly [11:51] plus.. [11:51] our kernel is already doomed in that direction [11:51] and i bet that with an efficient patching system in the kernel build, this should be easy to track down :) [11:51] so yes, let's have such an efficient patching machine :) [11:51] already the fact that we apply an external patch for an i386 driver, it will make the i386 kenrel different from the others [11:51] right [11:52] introducing a security problem for i386 [11:52] so we don't mind this. Ok, i'll keep that in mind [11:52] so it's take or leave it basically :) [11:52] indeed [11:52] anyone particularly good w/ sparc asm? [11:52] i was really confused by what i thought was an attempt to build all kernels from the exact same bits ;) === T-Bone needs to wander off for food for a while, bbiah === T-Bone is now known as T-Gone [11:53] dilinger: meh.. no [11:53] and i need to grab some food... [11:53] bbl === cc [~cc@byte.fedora] has joined #ubuntu-kernel === Lathiat [~lathiat@gasp.bur.st] has joined #ubuntu-kernel === dholbach [~daniel@td9091b95.pool.terralink.de] has joined #ubuntu-kernel [01:31] what shall i do about the broken powerpc-kernel-2.4? [01:32] if we don't have any alternative, i'll ask elmo to remove it from the archive [01:32] please note: i feel *very* uncomfortable with kernel issues/decisions in universe :-/ [01:36] did we end up with a kernel that supports i2o stuff on amd64 now? === T-Gone is now known as T-Bone [01:38] dholbach : i think this hasn't been discussed enough, unfortunately [01:38] (re kernel in universe issues) [01:38] we should discuss it in the next TB meeting [01:39] hmm, i thought there was none before hoary releases? [01:40] Mithrandir: we did add it a while ago [01:40] yes... but i'm not sure if we can have a complete consensus in the next 15 hours [01:40] fabbione: hm, ok. So it should be in the d-i images? [01:40] dholbach: remove it [01:40] fabbione: thanks [01:40] Mithrandir: yes. in the scsi udeb [01:40] fabbione : what about all other images then? [01:41] T-Bone: they will stay [01:41] fabbione : what for? [01:41] T-Bone: read the backlogs in the channel [01:42] fabbione : is that the "some users need them" argument? [01:42] fabbione : why should i do that when you don't do it yourself, btw? === T-Bone has no handy backlog, being at work as he is [01:43] T-Bone: because it has been discussed to death, and for once that i didn't read the backlog yet, you are making a tragedy [01:43] i'm not [01:43] T-Bone: people.ubuntu.com/~fabbione/irclogs/ [01:43] yeah looking there right now [01:43]

fabbione : why should i do that when you don't do it yourself, btw? [01:43] could you just point me a the right date please? [01:44] T-Bone: it has been discussed 2/3 times.. i can't remember the date [01:44] fabbione : if you happen to find yourself some time to read yesterdays backlog, you'll notice signficant concern has been raised, not only by me, for a change [01:45] one of the biggest being "these kernel are in the hands of MOTUs, and won't be supported" [01:45] anyway, i guess i'm lacking crucial elements, reading the logs [01:47] T-Bone: at what time you and lamont had the talk? [01:47] fabbione : just a 2cents btw, when such a decision is made, it'd be nice to state it on k-t, so that everyone involved is aware of it. Not everybody can follow irc, you see... [01:47] was i here in logged in the chan? [01:48] T-Bone: clearly you miss 2 points here [01:48] 1) kernel-packages -> universe [01:48] 2) MOTU's are searching advice [01:48] i expressed my wishes [01:48] motivating them [01:48] at the time your logger was mostly offline. I only see the end of the discussion at 8:16 in april 06's log [01:49] i don't rule MOTU's decisions [01:49] and universe is not kernel-team problem [01:49] fabbione : your "wishes" are blessed as god's decision, in case you haven't noticed [01:49] and i'm glad you're giving us the advices, it's just i'm not clever enough to judge [01:49] T-Bone: yes, i was offline, together with ubuntulog [01:49] T-Bone: i am not god.. [01:49] i never stated to be.. probably joking... [01:49] but that's it [01:50] i expressed my wishes, have been significantly backed up by lamont and kyle, dholbach agreed to some of my concerns, yet *you* rule... (not that i'm bitter) :P [01:50] ok if everybody has agreed to kill 2.4 [01:50] go ahead [01:50] i will gladly put in universe what people want and what works [01:50] it's fine with me [01:50] dholbach: kill them [01:50] NO [01:50] KILL THEM ALL! [01:50] KILL THEM ALL! [01:50] KILL THEM ALL! [01:50] that's not what i said [01:50] ! [01:50] fabbione : look at 08:45 [01:50] YEAH BURN THEM IN THE FLAMES OF HELL! [01:50] fabbione: calm down :-) [01:51] dholbach: i am kidding man :))) [01:51] i know :-) [01:51] fabbione : actually you may have the most interesting part in the logs, between 08:22 and 08:45 [01:51] it's just: i feel VERY uneasy about judging kernel stuff [01:51] T-Bone: yes i read that bit, and still users can't claim support from us, if the packages are in universe [01:51] i hope our MOTU team will grow soon and much cleverer people can work on that [01:52] fabbione : my point is that 1) i see no reason of keeping these in universe (on the ground of point 08:45) and 2) they will confuse our users (same grounds) and 3) if we don't need them let's remove them. Including 2.6 btw [01:52] dholbach: once we kill 2.4 there will be almost nothing left of kernel stuff in universe [01:52] now i'm really open to suggestions, it's just bad that question rises 24h before the release [01:52] T-Bone: i told dholbach to kill 2.6 the same morning [01:53] MorgueCandidates is what elmo is processing atm [01:53] fabbione : well, then we all agree, what the fuck are we fighting for then? ;o)) === T-Bone cheers fabbione ;) [01:53] T-Bone: my point one and simple. some users (like me btw) can't run 2.6 everywhere [01:53] leaving a couple of packages in universe might be handy for the user [01:53] fabbione : i tend to think that kind of user will build their own kernel anyway [01:53] and give him time to evaluate transition to 2.6 [01:53] T-Bone: not really [01:53] T-Bone: alot of people don't anymore [01:54] fabbione : in that view, leaving just source is enough, my guess [01:54] T-Bone: that's a bad assumption [01:54] fabbione : ok describe why youo can't run 2.6? [01:54] T-Bone: yes, but in out archive there cannot be source without binary afaik [01:54] ah [01:54] i agree: keeping the images might be handy [01:54] sure that's a problem :P [01:54] T-Bone: lvm/lvm2 issues [01:54] dholbach : this is a *bad* idea for the reason i explained yesterday... [01:54] fabbione : that's a server issue, right? [01:55] fabbione : on servers, usually you want fine tuned kernels, don't you? [01:55] T-Bone: yes, that is my specific problem [01:55] T-Bone: you are assuming again [01:55] look at RH [01:55] fabbione : in every company i've been working at, as well as univ, on sensitive servers, home brewed kernels are being run [01:55] if you touch the kernel, they don't provide support anymore [01:55] fabbione : ok you got a point. Yet we're not RH :) [01:56] T-Bone: i didn't run home made kernels at work [01:56] i couldnt [01:56] fabbione : that's irrelevant for us (support): we don't support universe anyway... [01:56] T-Bone: i really don't understand why you need to assume what people wants [01:56] i have a tech issue upgrading to 2.6 [01:56] other people might have to [01:56] i'm not assuming. I'm hypothetising [01:57]