[00:56] <lamont> soren: you around>?
[01:18] <pitti> hi
[01:19] <pitti> rtg, BenC: argh, after hal the serial.h header bug now struck cups
[01:19] <pitti> would you guys consider bug 302888 as something which needs to be fixed, or something which is intended and needs to be changed in hal/cups/etc.?
[01:28] <pitti> ah, I checked upstream, it's not a bug there
[01:28] <pitti> seems to be an Ubuntu-introduced bug
[01:29] <rtg> pitti: hi, its on my todo list. I'll check it first thing in the morning.
[01:29] <pitti> rtg: great, thanks; so I 
[01:29] <pitti> 'll just let the FTBFS sit there
[06:47] <soren> lamont: What's up?
[07:52] <tjaalton> are there plans to build multipath-modules for the installer?
[12:09] <Kano> hi BenC , are you working on 2.6.28-rc7?
[12:10] <NCommander> hey BenC, do we have any plans to move madwifi from LRM to the ubuntu folder now that its HAL is open?
[12:12] <Kano> NCommander: i dont think the madwifi code changed
[12:12] <NCommander> Kano, no, they released the HAL for it
[12:12] <Kano> there the blob still exists
[12:12] <NCommander> aka, the closed source blob
[12:15] <amitk> it would probably make more sense to get rid of madwifi completely if ath5k and ath9k work for a majority of the users.
[12:16] <NCommander> As long as madwifi is maintained, it should still be an option
[12:16] <NCommander> People get kinda pissed when their hardware stops working all of a sudden
[12:17] <NCommander> i.e. Windows Vista
[12:17] <Kano> well kanotix users have got no complains against ath5k, i enabled it - as little diff to your config
[12:17] <Kano> so eee pc and co works out of the box
[13:20] <rtg> apw: I responded re LP 302888 and 303711.
[13:20] <apw> rtg cool
[13:21] <Kano> hi rtg , how about 2.6.28-rc7
[13:21] <rtg> Kano: I take it from your question that it must be out :)
[13:21] <apw> rtg, will sort it out now
[13:22] <BenC> Kano: As usual we are working on it as quickly as possible, without concern for outside questining
[13:22] <BenC> questioning
[13:23]  * apw had something to ask benc ... what was it ... oh yeah, did you do the roll forward from Hardy to Intrepid?
[13:23] <Kano> BenC: well i did not see any new commits ;)
[13:23] <Kano> i want nfs working, did anybody else that that
[13:23] <BenC> apw: Hmm....I think so, but that was awhile ago :)
[13:23] <apw> benc, we lost an unbutu driver, specifically 
[13:24] <apw> benc, we lost an ubuntu driver, specifically the snd-aloop one, and wondered if you remebered the history
[13:24] <smb_tp> apw, are you sure we lost it or is that just a rename?
[13:24] <rtg> apw: was it in the ALSA directory?
[13:24] <rtg> sound, rather
[13:25] <smb_tp> That clue with dummy seemed good
[13:25] <BenC> apw: we had an ubuntu driver called snd-aloop?
[13:26] <BenC> apw: if it was in alsa proper, best bet is to check alsa history
[13:27] <apw> BenC, no it was in l-u-m
[13:27] <BenC> apw: but the sound drivers in lum were just a tarball of upstream
[13:27] <smb_tp> apw, It was in lum but under sound which is alsa
[13:27] <BenC> apw: so we didn't really pay attention to individual drivers in it
[13:28] <apw> hmmm ... ok then will go look at it from that point of view
[13:28] <BenC> except maybe snd-hda-intel
[13:28] <smb_tp> well that should be upstream as well. maybe even more upstream than the rest
[13:29] <apw> rtg, that header file fix is pushed up to jaunty
[13:29] <BenC> rtg: Can you get me a cup of coffee too :)
[13:29] <smb_tp> oh you referred to paying attention
[13:29]  * apw salivates ... and has to go make one
[13:29] <BenC> My brain is only at about 70% right now...need that extra caffeine kick to get to 71%
[13:34] <smb_tp> apw, snd-dummy really looks alike snd-aloop beside of having everything renamed from loopback to dummy...
[13:34] <rtg> BenC: I've got time to rebase and test build Jaunty this morning. OK?
[13:34] <apw> smb_tp, interesting ... i did see one commit which talked about dummy which sounded like it do something
[13:34] <apw> will do compare them
[13:36] <BenC> rtg: Have at it :)
[13:36] <rtg> BenC: will do. coffee is almost ready. bought a new 5lb bag of Italian roast just yesterday.
[13:39] <BenC> mmmm...italian
[13:39] <smb_tp> rtg, Need COIP ;-)
[13:41] <amitk> Anybody working on LRM/meta for Jaunty?
[13:41] <BenC> amitk: I was going to do that since rtg had the rebase, but if you are already started, it's yours
[13:42] <amitk> BenC: not started. I'll be busy this week with ARM.
[13:42] <BenC> amitk: do you have the linux-meta armel portion?
[13:42] <BenC> amitk: Ok, I'll get lrm forward ported then
[13:42] <amitk> BenC: not yet. Since I was waiting for the fallout from the -ub- version_signature discussion
[13:42] <BenC> rtg: When you do the rebase, can you remember to remove the via chrome9 drivers from ubuntu/?
[13:43] <rtg> BenC: can do. amitk - you promised a discussion for why you added -ub to package names.
[13:44] <BenC> rtg: basically to help identify ubuntu machines with upstream bug reporting and oops reporting
[13:44] <apw> rtg, while we are on the subject of version, i got that patch to put the ubuntu upload+changelog into the /proc/version #N field
[13:44] <amitk> rtg: yes. As soon as I am done with the spec here.
[13:44] <BenC> apw: that would be nice
[13:44] <apw> Linux version 2.6.27-10-generic (root@dm) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #21~lp276943apw1 SMP Mon Dec 1 17:56:07 GMT 2008
[13:45] <apw> note the 
[13:45] <apw> note the #21~... in there where we always have #1
[13:45] <apw> also note that in theory this would also be in the oops output
[13:45] <BenC> what is the ~lp... ?
[13:45] <apw> that is a local change tree i have installed, and i added that to the changelog
[13:46] <amitk> BenC: with apw's patch to /proc/version and in the oops patch, we should be able to revert the -ub change
[13:46] <BenC> apw: can you paste "head -1 " of changelog so I can see what it is parsing into it?
[13:46] <apw> ie. what i put in there is everything after the abi number
[13:46] <BenC> ok
[13:46] <rtg> BenC: adding -ub to the package name does't have anything to do with kerneloops, does it? I thought it was all in /proc/signature
[13:46] <apw> linux (2.6.27-10.21~lp276943apw1) UNRELEASED; urgency=low
[13:46] <apw> so normally we would expect it to be #21 or maybe #21ubuntu1 
[13:47] <BenC> rtg: well changing the package name made things easier in the build scripts, since it is assumed that the package name matches the kernel version name
[13:47] <apw> this is a local build for testing so i bung that into the changelog too
[13:47] <apw> yeah you don't have much choice but to change the name if you add it to the real version
[13:48] <apw> the other options were to just change the ooops output, to add a marker
[13:48] <apw> though logically it would be better for mainline to add a CONFIG_DISTRO
[13:48] <apw> and default that to mainline
[13:48] <BenC> amitk: so how does kerneloops tell that it is an ubuntu proper kernel and not just a kernel built on an ubuntu machine?
[13:48] <apw> so all oopses had mainline <version>, or Ubuntu <version>
[13:50] <BenC> apw: that was kind of the idea behind version_signature, but I wasn't prepared to push it hard enough to send it to linux-kernel@
[13:51] <apw> well it would be sensible enough, we just need it in the oops output
[13:51] <rtg> BenC: why am I ripping out via_chrome9  (which appears to be enabled) ? Is there an LP report?
[13:51] <amitk> BenC: it scans dmesg for oopses
[13:52] <amitk> BenC: here is a sample first line from Fedora
[13:52] <amitk> Linux version 2.6.24-0.77.rc4.git4.fc9 (kojibuilder@) (gcc version 4.1.2 2007112
[13:52] <amitk> 4 (Red Hat 4.1.2-35)) #1 SMP Thu Dec 6 16:50:13 EST 2007
[13:53] <BenC> rtg: because it is in mainline now
[13:53] <rtg> uh, I guess that makes sense :)
[13:54] <BenC> amitk: right, but how is our kernel going to look different than a kernel a user built, or do they not care about that?
[13:55] <amitk> BenC: they don't care unless it is tainted
[13:56] <BenC> amitk: that sucks, because I care :)
[13:56] <amitk> BenC: you want to differentiate official kernels from user-compiled ones?
[13:56] <BenC> amitk: then why couldn't they just check for Ubuntu in the kernel oops already...that's always been there
[13:57] <BenC> amitk: it's always been in oops and /proc/version
[14:00] <amitk> BenC: our /proc/version in intrepid is
[14:00] <amitk> Linux version 2.6.27-10-generic (buildd@crested) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Fri Nov 21 19:19:18 UTC 2008
[14:00] <amitk> The first part has no mention of ubuntu
[14:01] <amitk> The only Ubuntu in there is related to the gcc toolchain use
[14:01] <amitk> *used
[14:01] <apw> and oopsen only use that first version field
[14:01]  * amitk nods
[14:01] <apw> well thats not quite true, they also include the #1 field
[14:02] <apw> one of my alternative patches put -Ubuntu in there,  #1-Ubuntu
[14:02] <apw> we could combine that with my other patch to make it like #12-Ubuntu
[14:07] <BenC> apw: for our official kernels, that would be sweet
[14:07] <BenC> apw: where can I find the patch?
[14:08] <apw> we can probabally even key that off the whether we are under an autobuilder
[14:08] <apw> BenC, want me to send it out?
[14:08] <BenC> apw: that's easy to do, see debian/rules.d/0-*, there's a check for CurrentlyBuilding or something similar
[14:08] <BenC> apw: that means we are under a build daemon
[14:08] <BenC> apw: yes, please
[14:08] <apw> i'll poke it so it adds the -Ubuntu on autobuilder and send it to the kernel team list
[14:16] <rtg> BenC: have you ever considered removing debian/control, debian/control.stub, and debian/d-i/kernel-versions from git ? All of these files are generated and often cause rebase conflicts.
[14:16] <apw> i often wonder why we have the abi files in there either
[14:17] <apw> other than the getabi thing being very slow cause it gets the whole kernel package
[14:17] <rtg> apw: well, the ABI for the previous version really needs to be there.
[14:17] <BenC> rtg: odd, I've never had a rebase conflict with them
[14:17] <apw> we need to know it for the build right, but not necessary in the source tree itself?
[14:18] <BenC> apw: it needs to be there so we can easily go back through history
[14:18] <apw> are they not in the pacakges we released too tho?
[14:18] <BenC> apw: they are pertinent to the state of the tree
[14:18] <rtg> BenC: I'm having a rebase conflict with the -ub additions in debian/d-i/kernel-versions.in, and I'm not quite sure why.
[14:18] <BenC> apw: they packages we released will disappear sooner then the end of the development cycle :)
[14:18] <apw> fair point
[14:19] <BenC> rtg: easy enough to just ignore those...I've never had issue with that before
[14:19] <BenC> regen at the end of the rebase
[14:19] <rtg> BenC: well, I can't exactly ignore kernel-versions.in, that one I have to resolve. the rest are no problem.
[14:20] <amitk> rtg: just delete those files before you start the rebase and regen them at the end
[14:20] <BenC> rtg: I suspect that it more to do with armel and -ub- clashes rather than just normal stuff
[14:20] <amitk> rtg: .in versions for the generated versions?
[14:20] <apw> BenC, actually the given the abi cannot change within an -N abi stream and given the each abi is a differnt package, then all the abis should be available always
[14:20] <rtg> BenC: isn't that what I said?
[14:20] <amitk> s/for/or
[14:21] <BenC> apw: as I said though, the abi files are very pertinent to the state of the tree, so they should be there
[14:21] <BenC> apw: we shouldn't have to download the abi files to go back through history...easier to just use git
[14:21] <apw> fair enough, just usual to have generated stuff in there
[14:22] <BenC> rtg: oh, I thought you just said -ub-....I was just remembering a bit of merging I had to do with amitk's -armel stuff and -ub- changes
[14:22] <BenC> apw: abi files aren't generated in the tree though...we have to fetch them
[14:22] <BenC> you can probably make the case for control,control.stub,kernel-versions though
[14:23] <BenC> as long as they get added to .git-ignore, I wont complain :)
[14:23] <apw> BenC, i cannot argue with that
[14:24] <BenC> It might be best to keep them though...we've always assumed that git tags hold the exact source we uploaded
[14:25] <amitk> BenC: until we rebase, that is.. Then the tags are meaningless
[14:25] <apw> well no the old tags are still there, they don't move
[14:26] <amitk> BenC has a retag script :)
[14:26] <apw> he is a bad bad man
[14:26] <BenC> I keep the original tags though
[14:27] <BenC> like Ubuntu-2.6.28-1.1.orig
[14:27] <apw> why would we move them ever?  don't they correspond to something specific?
[14:27] <BenC> and they never get overwritten after they are created
[14:27] <BenC> apw: we move them so they correspond to git history
[14:27] <BenC> apw: it's good to have the original and the retag
[14:28] <apw> why do we need the new ones?  the old ones tell you how to get the source as it was for that release
[14:28] <BenC> apw: because if they don't correspond to the new line of history, we can't git-bisect
[14:28] <apw> what do the new ones on the rebase tell us
[14:28]  * apw mulls that over
[14:28] <BenC> if you rebase, you can't bisect from HEAD back to 2.6.28-1.1
[14:29] <BenC> unless you use the updated tag that corresponds to the new line of history
[14:29] <BenC> and the old tags make it so we can keep a link back to the actual upload
[14:29] <rtg> BenC: debian/scripts/misc/retag before you startnewrelease, right?
[14:29] <apw> although the fact it worked in 2.6.28-1.1 means nothing in the new kernel
[14:30] <BenC> rtg: you can run it at any time
[14:30] <apw> as the new kernel has new stuff 'older than' 2.6.28-1.1
[14:30] <apw> so its not obvious a known good point on an older branch means anything int eh new tree
[14:30] <BenC> apw: it's very subtle, but I did write the script because our process demanded it at a few points during development :)
[14:30] <amitk> these tags are useful for bisecting only inside Ubuntu's patches
[14:30]  * BenC doesn't add scripts for no particular purpose
[14:31] <apw> heh, not doubting there is a use case for them
[14:31] <apw> just my 'perfection' beeper is going off at the thought of ever changing the tags
[14:31] <BenC> apw: the reason we rebase here instead of merge is because when we bisect, we want to be sure we are bisecting ubuntu patches and not upstream
[14:32] <BenC> apw: when we bisect upstream, we don't want to be bisecting ubuntu patches in the middle of it
[14:32] <BenC> apw: if you want, rtg and I can rehash our old arguments for and against this at UDS :)
[14:32] <apw> yeah am happy we rebase, that helps keep our delta contained and minimised, even if it is painful
[14:33] <apw> i had not expected the tags to move, and i can see why they might, not sure they are entirly valid given a good result on a kernel with an older version of the tag, but i can see how it does help to have the split on the current set too
[14:33]  * apw adds 'if there is a .orig for a tag, its the master' to his mental model
[14:33] <BenC> apw: after the kernel goes stable, we don't rebase anymore, so the moving target is usually only during development cycle
[14:35] <apw> BenC, i can see i would have done something similar (now i have all the facts) though i would probabally have kept the original tags unchanges and made like a Ubuntu-2.6.27-10-2, -3 etc for each of their new positions, but the effect is the same
[14:46] <apw> BenC, patch for the #NN -> #21-Ubuntu is in the pipe
[14:52] <rtg> apw: you didn't push it, right? 'cause I'm gonna clobber stuff when I push Jaunty.
[14:53] <apw> rtg, it ?
[14:53] <rtg> apw: ' patch for the #NN -> #21-Ubuntu is in the pipe'
[14:54] <apw> nope, that means 'on the way to the mailing list'
[14:54] <apw> i did push the other fix, but i assume you have done your thing since then
[14:54] <apw> if not i'll do it again
[14:56] <rtg> apw: I have the __u32 fix, and my chrome9 patch is still top of the gitweb.
[14:57] <apw> rtg all sounds good to me
[15:00] <rtg> hmm, looks like the biking season has come to an abrupt end. in the last 2 hours 2 inches of snow has accumulated.
[15:08] <rtg> amitk: iop32xx FTBS'd on the last upload. do you expect that it will succeed this time? 
[15:10] <amitk> rtg: 2.6.28-1.1?
[15:10] <rtg> amitk: yes
[15:11] <amitk> rtg: I see it successfully built
[15:11] <amitk> https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-1.1/+build/798103
[15:12] <rtg> amitk: getabi failed, so I assumed.... lemme go look closer
[15:12] <lamont> OH HAI.  I CAN HAZ MY ETHERNET BACK PLS?
[15:13] <rtg> lamont: ARE YOU DEEF?
[15:13] <lamont> I did a dist-upgrade, intrepid-security kernel, and *poof* no BCM4401-B0 agaiin
[15:13] <rtg> lamont: you have LBM installed, right?
[15:15] <lamont> linux-backports-modules-2.6.27-9-generic is already the newest version.
[15:15] <rtg> lamont: you'll likely have to pull from -propsed
[15:15] <rtg> -proposed, even
[15:16] <lamont> so when does intrepid release then?
[15:16] <rtg> early Q1 probably
[15:16] <lamont> yeah - please to quit breaking
[15:16] <lamont> kthx
[15:16] <rtg> lamont: bitch and moan
[15:17] <lamont> I realize it's not like anyone is actually using it or anything.... :-(
[15:19] <rtg> amitk: the problem is the package name, e.g., iop32x v.s. iop32xx
[15:20] <lamont> rtg: 2.6.27-10?
[15:20] <rtg> lamont: that should be the version in -proposed
[15:20] <lamont> yeah, but no way in hell I'm dist-upgrading from -proposed --> cherrypick
[15:21] <rtg> lamont: why not? its your laptop. ots not like its a production server
[15:21] <lamont> my laptop
[15:21] <lamont> == production lifeblood
[15:21] <rtg> lamont: what model?
[15:22] <lamont> inspiron 1520
[15:22] <rtg> lamont: I think I have one of those. I'll test it, but I think -proposed is working pretty good.
[15:23] <rtg> I know for sure the b44 issue is resolved.
[15:23] <lamont> which still brings up the question of how -updates got the b0rked one.  again.
[15:24] <Kano> maybe remove the backport modules
[15:24] <rtg> 'cause we has a -security kernel update which necessitated an ABI bump.
[15:24] <rtg> LBM has not been promoted to -updates in awhile
[15:24] <rtg> Intrepid LBM, that is.
[15:25] <lamont> rtg: one would expect that we'd rev lbm at the same time...
[15:25] <lamont> and the currently running kernel is -9
[15:25] <rtg> lamont: I did, but only the ABI number. I'll bug pitti, its probably time to push LBM to -updates
[15:35] <amitk> rtg: it should've been iop32x
[15:38] <BenC> sweet, lrm builds without problems under 2.6.28
[15:47] <BenC> rtg: let me know when you get -2.2 uploaded and I'll follow with an lrm to match it
[15:50] <rtg> BenC: still test building. I ran into a problem getting ABI files, etc. also had some background distractions with Intrepid LBM.
[16:03] <rtg> fabbione: I've been meaning to ask you if we still need gfs? Is fs/gfs2 sufficient?
[16:05] <fabbione> rtg: you still need gfs for at least another 3/4 years I guess
[16:05] <fabbione> rtg: you can drop gnbd
[16:05] <fabbione> rtg: gnbd has been deprecated upstream
[16:05] <rtg> fabbione: thanks, consider it gone.
[16:06] <fabbione> rtg: do you need a newer gfs for .28?
[16:06] <rtg> fabbione: yep
[16:06] <fabbione> rtg: remember that now gfs doesn't need any extra patches to kernel like it used to
[16:06] <rtg> fabbione: I think BenC just forward ported Intrepid gfs to Jaunty
[16:06] <fabbione> rtg: old versions of gfs required some exported symbols from gfs2. This is not the case anymore since .27
[16:07] <fabbione> rtg: I dunno.. I'd like to see the patches tho so we can actually apply them upstream
[16:07] <fabbione> rtg: also.. you guys should really stop doing that forward port without upstream..
[16:07] <fabbione> or at least talk to us
[16:08] <fabbione> it's bad for you as you lack tons of bug fixes
[16:08] <fabbione> and your gfs doesn't go through QA
[16:08] <fabbione> so if it breaks you keep the pieces :)
[16:08] <rtg> fabbione: I agree with everything you're saying. its a matter of resources.
[16:09] <fabbione> rtg: if you have the time to port gfs, you have the time to send me an email, same as you can ping me on IRC :)
[16:09] <rtg> fabbione: well, I was still busy with Intrepid while BenC was doing Jaunty, so the stink is on him.
[16:10] <fabbione> rtg: i didn't blame you.. just that the resource thing doesn't hold with me as I have been there before :P
[16:11] <apw> fabbione, i suspect he did a git rebase, and it 'worked' so its wasn't any effort
[16:11] <apw> (other for the computer)
[16:11] <BenC> fabbione: gfs didn't build right away, so I just disabled it for the first upload
[16:11] <BenC> fabbione: intentions were to download the newer version for next upload
[16:12] <fabbione> BenC: ok. we don't have a version for .28 yet
[16:12] <BenC> fabbione: I did no porting to gfs at all
[16:12] <fabbione> BenC: ok :)
[16:12] <fabbione> BenC: i'll ping you as usual to do a pull when it's ready
[16:12] <fabbione> no panic
[16:12] <BenC> s/GFS=m/GFS is not enabled/
[16:13]  * apw senses an effort shift to fabbione ... excellent for us :)
[16:13] <fabbione> Juanty barely started
[16:13] <fabbione> apw: you have no idea who I am, do you?
[16:13] <BenC> fabbione: sure thing...I can do the pull whenever it's ready
[16:14] <BenC> apw: fabbione is the godfather that brought me into canonical as the "kernel team"
[16:14] <fabbione> BenC: absolutely.. usual stuff, or I'll make sure that your shrink will be rich out of your money for the next 100 sessions
[16:14] <apw> heh nope no clue ...
[16:14] <fabbione> apw: I used to be the kernel team alone for about 2 releases
[16:14] <fabbione> apw: :)
[16:14] <BenC> fabbione: My shrink is named beer, and he's pretty cheap
[16:14] <apw> that i don't envy you :)
[16:14] <fabbione> and at the time there were more arches to support than you do
[16:15] <fabbione> BenC: should I really really remind you about me trying to grab your ass at night??
[16:15] <apw> yeah that must have been at best 'mad' ... 
[16:15] <BenC> fabbione: but you weren't the OEM's little mistress back then :)
[16:15] <BenC> fabbione: it took several weeks of beer and jaegar bombs to get over that night
[16:15]  * BenC shivers
[16:15] <fabbione> BenC: ehheeh true that...
[16:15] <fabbione> haha
[16:17] <fabbione> anyway.. kill gnbd
[16:17] <fabbione> I'll make userland disappear soonish
[16:18] <BenC> fabbione: I think clan now has a 3 foot minimum spacing between beds in shared rooms requirement because of my complaints about that
[16:18] <fabbione> apw: and btw.. now I am release manager for gfs :)
[16:18] <fabbione> BenC: ROFL
[16:18] <fabbione> apw: for me it's a no brain to do it for ubuntu
[16:20] <BenC> fabbione: especially because I don't think jono is any safer than you are even though he is married now
[16:20] <BenC> fabbione: when do you think a gfs pull will be ready?
[16:21] <fabbione> BenC: end of next week maybe
[16:21] <fabbione> BenC: I am rebuildnig the whole datacenter here
[16:21] <fabbione> BenC: and I had too many issues before I could start reinstalling the community clusters (fedora, ubuntu etc)
[16:22] <fabbione> BenC: i need to show you pictures of what I have done here :)
[16:22] <apw> fabbione, nice to know :)  i am a lowly pleb
[16:22] <fabbione> BenC: a 8 heads workstation ;)
[16:23] <fabbione> BenC: 5000x2300 resolution.. given or taken :)
[16:23]  * amitk thinks of forwarding the irc log to clan to push for separate rooms
[16:23] <fabbione> amitk: ahah you have my blessing!
[16:23] <fabbione> HI CLAN!
[16:23] <fabbione> :)
[16:23] <BenC> amitk: either that, or we should have a mental anxiety reimbursement :)
[16:24] <amitk> fabbione: sweet... played flight simulator on that?
[16:24] <fabbione> amitk: not yet.. i just installed it 2 days ago :)
[16:24] <fabbione> amitk: but the CPU is not a gaming one
[16:24]  * BenC imagines fabbione playing frets of fire and having the biggest video crowd ever!
[16:24] <fabbione> BenC: try to imagine something more useful than gaming
[16:25] <fabbione> this is the best Porn machine ever
[16:25] <BenC> hehe
[16:25] <fabbione> 8 porn movies at the same time!
[16:25] <fabbione> (welcome to quote me ;))
[16:25] <BenC> 2girls1cup, mr hands, pain olympics, and all their glory
[16:25] <Nafallo> AltGr+e ftw? ;-)
[16:47] <zul> fabbione: nice
[16:48] <apw> rtg did you push the tags for this new jaunty?
[16:48] <apw> i have a -2.2 tag, but the 1.1 and 0.0 are missing
[16:48] <rtg> apw: I did
[16:49] <rtg> apw: it says everything is up to date
[16:49] <apw> hmmm ... they are still in their originals on my fetch
[16:49] <apw> you have to explicitly push tags
[16:49] <apw> iirc
[16:50] <rtg> 'git push --tags origin master' is what I just did
[16:50] <apw> oh hmmm i had to explicitly fetch the tags ... oddness
[16:51] <rtg> I've run into that before
[16:51] <BenC> rtg: git-push --tags
[16:51] <apw> i am pretty sure its not meant to do that... 
[16:51] <BenC> err, nm
[16:51] <BenC> rtg: you shouldn't really explicitly push origin, fyi :)
[16:52] <rtg> BenC: why not? I _always_ check to make sure I know what origin is first.
[16:54] <rtg> BenC: also, you do your LRM thing now.
[16:54] <rtg> s/you/you can/
[16:56] <BenC> rtg: just the nature of origin is local to the repo...I don't think it will hurt anything, just that master is the one that matters
[16:57] <BenC> rtg: ack on lrm, thanks
[17:19] <apw> BenC, how do i figure out what head you started from when you rebased to .28 for the first time?
[17:20] <BenC> apw: hard to tell, but you can get an idea from the changelog as to where it was when I cloned it
[17:20] <BenC> the entry before 2.6.28-1.1 is the last upload before I cloned, so that + maybe-some-other-commits
[17:21] <apw> we should probabally tag that in future
[17:21] <apw> and i'll try and figure it out too
[17:39] <mnemo> is there any 2.6.28-rcX kernel packaed for jaunty yet?
[17:42] <amitk> mnemo: 2.6.28-1.1 available from https://edge.launchpad.net/ubuntu/jaunty/+source/linux/2.6.28-1.1
[17:42] <amitk> and if you wait a day you might get a -2.2 that based on the latest -rc
[17:43] <BUGabundo> can some on help me debug my system ?
[17:44] <BUGabundo> I'm getting kernel locks on shutdown (halt)
[17:44] <BUGabundo> and suspend stop working last week
[17:44] <BUGabundo> I'm on jaunty
[17:45] <mnemo> amitk: when I did "update-manager -d" it left me with 2.6.27-something, is that normal? do I need to do something explicit to switch over to the new kernel?
[17:47] <BUGabundo> mnemo: I got stuck on the .27 kernel until I manually installed it via synaptics
[17:47] <amitk> mnemo: 2.6.28 is not installable through update-manager yet. Some meta packages are missing
[17:48] <amitk> best wait a day or so if you need update-manager support
[17:48] <BUGabundo> yeah amitk... it looks like it
[19:10] <BenC> lrm on its way up
[20:11]  * fabbione larts BenC for not building usb-serial in sparc hardy kernel!
[20:11] <BenC> fabbione: was hardy sparc still built from linux proper source?
[20:12] <fabbione> yeps
[20:12] <BenC> fabbione: I claim lack of need for usb-serial
[20:12] <fabbione> i claim I need it :)
[20:13] <fabbione> i just plugged my backup adsl line in my new (sparc) firewall and zack
[20:13] <fabbione> <- owner
[20:13] <fabbione> owned
[20:13] <BenC> fabbione: become a sparc community kernel maintainer :)
[20:14]  * fabbione larts BenC with a pci2usb card ;)
[20:14] <fabbione> BenC: i am going to test it.. if it works, can you just flip it on the next build?
[20:14] <fabbione> it's sparc only, doesn't affect main arches yada yada
[20:22] <BenC> fabbione: bug report, SRU request, kernel-team@
[20:22] <fabbione> SRU?
[20:22] <fabbione> for a config option on a non supported arch?
[20:23] <BenC> Stable Release Update
[20:23] <fabbione> yeah i know what SRU is.. i mean all the paper work for non supported arch?
[20:23] <BenC> fabbione: I don't handle stable, best to talk to smb_tp
[20:23] <fabbione> ok.......
[20:23]  * smb_tp comes over
[20:24] <fabbione> smb_tp: ^^^
[20:24] <fabbione> brb
[20:24] <smb_tp> fabbione, ok, so I have some time to read context :)
[20:30] <smb_tp> fabbione, Ah ok, well if it works, at least write a mail asking and explaining why to kernel-team@. You will help greatly if you could do a simple bug report as well, but since it is so simple I can do it this time. ;-)  It is hard but it helps remembring why things were done. Especially since team now is >1
[20:43] <fabbione> smb_tp: ok.. but remember a good git entry in the log and debian/changelog is also as useful :)
[20:43] <fabbione> smb_tp: anyway first testing... then everything else
[20:44] <fabbione> smb_tp: if i am bored i´ll just give you a tree to pull :)
[20:44] <smb_tp> fabbione, Heh, for sure
[20:44] <bdmurray> apw: Is the fix for bug 193970 only for the iwl4965 driver?
[20:44] <smb_tp> fabbione, Even better. :)
[20:45] <apw> bug #193970
[20:46] <apw> bah stupid ubotto
[20:46] <rtg> ubotto sleeps with the fishes
[20:47] <apw> bdmurray, yes the fix ascribed to that bug seems to only help the higher level iwl4965 driver
[20:47] <apw> its on my list to find out if there is another fix out there for the older driver
[20:47] <rtg> apw: it applies to both iwl 4K and 5K drivers.
[20:56] <apw> yeah, will investigate further tommorrow