lamont | soren: you around>? | 00:56 |
---|---|---|
pitti | hi | 01:18 |
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:19 |
pitti | ah, I checked upstream, it's not a bug there | 01:28 |
pitti | seems to be an Ubuntu-introduced bug | 01:28 |
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 | 01:29 |
=== chuck_ is now known as zul | ||
soren | lamont: What's up? | 06:47 |
tjaalton | are there plans to build multipath-modules for the installer? | 07:52 |
Kano | hi BenC , are you working on 2.6.28-rc7? | 12:09 |
NCommander | hey BenC, do we have any plans to move madwifi from LRM to the ubuntu folder now that its HAL is open? | 12:10 |
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:12 |
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:15 |
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:16 |
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 | 12:17 |
rtg | apw: I responded re LP 302888 and 303711. | 13:20 |
apw | rtg cool | 13:20 |
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:21 |
BenC | Kano: As usual we are working on it as quickly as possible, without concern for outside questining | 13:22 |
BenC | questioning | 13:22 |
* 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:23 |
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:24 |
smb_tp | That clue with dummy seemed good | 13:25 |
BenC | apw: we had an ubuntu driver called snd-aloop? | 13:25 |
BenC | apw: if it was in alsa proper, best bet is to check alsa history | 13:26 |
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:27 |
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:28 |
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:29 |
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:34 |
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:36 |
BenC | mmmm...italian | 13:39 |
smb_tp | rtg, Need COIP ;-) | 13:39 |
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:41 |
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:42 |
rtg | BenC: can do. amitk - you promised a discussion for why you added -ub to package names. | 13:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:50 |
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:51 |
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:52 |
BenC | rtg: because it is in mainline now | 13:53 |
rtg | uh, I guess that makes sense :) | 13:53 |
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:54 |
amitk | BenC: they don't care unless it is tainted | 13:55 |
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:56 |
BenC | amitk: it's always been in oops and /proc/version | 13:57 |
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:00 |
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:01 |
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:02 |
BenC | apw: for our official kernels, that would be sweet | 14:07 |
BenC | apw: where can I find the patch? | 14:07 |
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:08 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
BenC | as long as they get added to .git-ignore, I wont complain :) | 14:23 |
apw | BenC, i cannot argue with that | 14:23 |
BenC | It might be best to keep them though...we've always assumed that git tags hold the exact source we uploaded | 14:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 | |
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:31 |
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:32 |
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:33 |
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:35 |
apw | BenC, patch for the #NN -> #21-Ubuntu is in the pipe | 14:46 |
=== lamont` is now known as lamont | ||
rtg | apw: you didn't push it, right? 'cause I'm gonna clobber stuff when I push Jaunty. | 14:52 |
apw | rtg, it ? | 14:53 |
rtg | apw: ' patch for the #NN -> #21-Ubuntu is in the pipe' | 14:53 |
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:54 |
rtg | apw: I have the __u32 fix, and my chrome9 patch is still top of the gitweb. | 14:56 |
apw | rtg all sounds good to me | 14:57 |
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:00 |
rtg | amitk: iop32xx FTBS'd on the last upload. do you expect that it will succeed this time? | 15:08 |
amitk | rtg: 2.6.28-1.1? | 15:10 |
rtg | amitk: yes | 15:10 |
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:11 |
rtg | amitk: getabi failed, so I assumed.... lemme go look closer | 15:12 |
lamont | OH HAI. I CAN HAZ MY ETHERNET BACK PLS? | 15:12 |
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:13 |
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:15 |
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:16 |
lamont | I realize it's not like anyone is actually using it or anything.... :-( | 15:17 |
rtg | amitk: the problem is the package name, e.g., iop32x v.s. iop32xx | 15:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
amitk | rtg: it should've been iop32x | 15:35 |
BenC | sweet, lrm builds without problems under 2.6.28 | 15:38 |
BenC | rtg: let me know when you get -2.2 uploaded and I'll follow with an lrm to match it | 15:47 |
rtg | BenC: still test building. I ran into a problem getting ABI files, etc. also had some background distractions with Intrepid LBM. | 15:50 |
rtg | fabbione: I've been meaning to ask you if we still need gfs? Is fs/gfs2 sufficient? | 16:03 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
* 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:13 |
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:14 |
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:15 |
fabbione | anyway.. kill gnbd | 16:17 |
fabbione | I'll make userland disappear soonish | 16:17 |
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:18 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
zul | fabbione: nice | 16:47 |
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:48 |
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:49 |
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:50 |
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:51 |
rtg | BenC: why not? I _always_ check to make sure I know what origin is first. | 16:52 |
rtg | BenC: also, you do your LRM thing now. | 16:54 |
rtg | s/you/you can/ | 16:54 |
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:56 |
BenC | rtg: ack on lrm, thanks | 16:57 |
apw | BenC, how do i figure out what head you started from when you rebased to .28 for the first time? | 17:19 |
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:20 |
apw | we should probabally tag that in future | 17:21 |
apw | and i'll try and figure it out too | 17:21 |
mnemo | is there any 2.6.28-rcX kernel packaed for jaunty yet? | 17:39 |
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:42 |
BUGabundo | can some on help me debug my system ? | 17:43 |
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:44 |
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:45 |
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:47 |
amitk | best wait a day or so if you need update-manager support | 17:48 |
BUGabundo | yeah amitk... it looks like it | 17:48 |
=== mdz_ is now known as mdz | ||
BenC | lrm on its way up | 19:10 |
* 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:11 |
fabbione | yeps | 20:12 |
BenC | fabbione: I claim lack of need for usb-serial | 20:12 |
fabbione | i claim I need it :) | 20:12 |
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:13 |
* 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:14 |
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:22 |
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:23 | |
fabbione | smb_tp: ^^^ | 20:24 |
fabbione | brb | 20:24 |
smb_tp | fabbione, ok, so I have some time to read context :) | 20:24 |
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:30 |
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:43 |
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:44 |
apw | bug #193970 | 20:45 |
apw | bah stupid ubotto | 20:46 |
rtg | ubotto sleeps with the fishes | 20:46 |
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:47 |
apw | yeah, will investigate further tommorrow | 20:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!