| poolie | tjaalton: hello? | 00:50 |
|---|---|---|
| poolie | did you want me to try all of http://kernel.ubuntu.com/git?p=lexical/lexical-natty.git;a=shortlog;h=refs/heads/lp788026 or bisect through it or ...? | 00:51 |
| jk- | poolie: we've got you hacking the kernel now huh? :) | 00:54 |
| poolie | as i said on status.c.c getting away from rebuilding the kernel to work around hardware bugs is why i installed ubuntu in the first place :-P | 00:55 |
| * jk- hands poolie a typewriter | 00:55 | |
| poolie | ? | 00:55 |
| jk- | no bugs! | 00:56 |
| jk- | :) | 00:56 |
| poolie | heh | 00:56 |
| poolie | i bet they do these days | 00:56 |
| jburkholder | hi folks | 02:20 |
| melkor | good evening. I just tried the 3.0 kernel, and my wireless doesn't work. I'm using the ath9k drivers normally. | 02:59 |
| melkor | I am not so worried about it, I will just go back to my previous kernel, but I thought you might like to know. I got warnings about missing firmware when I installed it. | 03:04 |
| lamont | Generating grub.cfg ... | 05:09 |
| lamont | /usr/sbin/grub-probe: error: raid5rec is not loaded. | 05:09 |
| lamont | wtf? | 05:09 |
| tjaalton | poolie: \o/ | 05:31 |
| poolie | tjaalton: :-( | 05:54 |
| poolie | it's better but it's not all the way | 05:54 |
| poolie | but, it's better :) | 05:54 |
| tjaalton | ah | 05:56 |
| poolie | i replied | 05:56 |
| poolie | i'm going to stop futzing with it, unless you have things you specifically want me to test, in which case i'm happy to do that | 05:56 |
| tjaalton | oh damn, I didn't read that comment | 05:56 |
| tjaalton | poolie: ok, we'll see | 05:57 |
| tjaalton | poolie: would be nice to see if some of the other commits from .39-rc1 to drm/i915 would fix these (if they are all absent in -rc3). also, could you clarify if they are regressions from .38 or not | 06:06 |
| poolie | so that is to say: | 06:07 |
| poolie | which of these problems are in 39-rc1? and which are in current 38? | 06:07 |
| tjaalton | right | 06:08 |
| === _LibertyZero is now known as LibertyZero | ||
| tjaalton | well, just rc1 wouldn't cut it, there are a couple of fixes from rc2 that's included in the branch, but if you feel comfortable building kernels, then you could try cherry-picking stuff from rc1 (that touched drivers/gpu/drm/i915, ~71 commits left to test :), that would be great | 06:11 |
| === michael is now known as Guest91471 | ||
| === Quintasan_ is now known as Quintasan | ||
| poolie | it's going to be hard to tell which are regressions because they're masked by the more fundamental bugs | 06:20 |
| poolie | like, if the external display just doesn't work, i don't get the chance to see if it doesn't work from suspend | 06:21 |
| poolie | but i can try cherrypicking more stuff, probably | 06:21 |
| tjaalton | ah, right, of course.. | 06:37 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| ppisati | morning | 08:09 |
| * apw yawns | 08:10 | |
| apw | moin ppisati | 08:10 |
| smb | morning | 08:22 |
| apw | smb, moin | 08:23 |
| abogani | morning all | 08:31 |
| smb | abogani, morning | 08:33 |
| apw | [ 129.102338] wlan%d: authenticate with 00:0f:b5:b3:4c:ca (try 1) | 09:17 |
| * ppisati back in 20mins | 10:19 | |
| * apw giggles | 10:46 | |
| * smb thinks apw does think strangle sometimes... But then he can think of what he thinks of... | 11:06 | |
| arun_mittal | hey guys i upgraded my system from 9.04 to 10.04, but now i am getting an error and i can not login to my system , error "init: rc-default main process terminated with status 127" | 11:24 |
| arun_mittal | any help with this !!! | 11:24 |
| apw | arun_mittal, that doesn't sound like a kerenel error, possibly something upstart might day | 11:25 |
| apw | say | 11:26 |
| apw | have you asked on #ubuntu ? | 11:26 |
| amitk | 9.04 -> 10.04 update (is that even tested?) | 11:26 |
| ogra_ | -neither tested nor supported | 11:26 |
| apw | arun_mittal, how did you do the upgrade? direct one release to the one two later ? | 11:26 |
| ogra_ | and likely the cause of the above | 11:26 |
| arun_mittal | apw, they asked me to go on ubuntu-kernel | 11:26 |
| ogra_ | arun_mittal, tell them #ubuntu-kernel isnt a support channel next time ;) | 11:27 |
| apw | arun_mittal, how did you do the upgrade? direct one release to the one two later ? | 11:27 |
| arun_mittal | direct from 9.04 to 10.04 | 11:27 |
| arun_mittal | apw, direct from 9.04 to 10.04 | 11:27 |
| apw | ok and using what commands | 11:28 |
| apw | cirtainly an upgrade like that isn't tested so it not working does not supprise me | 11:28 |
| arun_mittal | apw, apt-get upgrade | 11:28 |
| apw | ok and that isn't the way to upgrade from one release to another either | 11:28 |
| apw | you should have used upgrade manager to update via the intermediate release (for next time) | 11:29 |
| ogra_ | whoever told you to upgrade like that should actually fix your issue ;) | 11:29 |
| arun_mittal | apw, before that i set sources.list to 10.04 rep | 11:29 |
| Tommeh | arun_mittal: that's why it broke. | 11:29 |
| arun_mittal | :) | 11:29 |
| apw | and if do it by hand you would use dist-upgrade not upgrade | 11:29 |
| Tommeh | You did something silly. ;) | 11:29 |
| amitk | (ouch!) | 11:29 |
| apw | and now you are in a huge hole | 11:29 |
| apw | arun_mittal, are you able to get to a prompt with working network ? | 11:29 |
| arun_mittal | apw, No | 11:29 |
| apw | ouch | 11:30 |
| arun_mittal | apw, i was in middle of my work and done this shit | 11:30 |
| Tommeh | Hahaha | 11:30 |
| apw | do you have a livecd or bootable memory stick ? | 11:30 |
| * amitk would back up my data using boot disk and reinstall | 11:30 | |
| Tommeh | Or you could try booting the 10.04 livecd and see if you can fix it via a chroot. | 11:31 |
| arun_mittal | i ahve live Cd but no cd drive :P | 11:31 |
| Tommeh | long-shot though. | 11:31 |
| apw | amitk, in theory they can do apt-get install ubuntu-desktop^ and it will sort out the mess | 11:31 |
| apw | _if_ they can get to a prompt with network | 11:31 |
| arun_mittal | now i am getting a CD drive first | 11:31 |
| amitk | apw: true | 11:31 |
| apw | so once you are booted from a cd you can mount up your root, bind mount /dev into it, chroot in, mount up /sys and /proc, and then try apt-get install ubuntu-desktop^ | 11:32 |
| apw | and the trailing ^ is critical | 11:32 |
| apw | and then write 200 lines "i will use upgrade-manager to upgrade my system next time" | 11:33 |
| smb | possibly do-release-upgrade when you don't have X (like a server) | 11:44 |
| * ogra_ wonders how installing the ubuntu-desktop task would fix your upstart configuration | 11:50 | |
| smb | ogra_, It does sort of force pull in anything that desktop dependson , hope is to catch things that might got missed/not upgraded before | 11:52 |
| smb | maybe a slight hope only... | 11:52 |
| ogra_ | smb, you are still missing the 9.10 upstart version | 11:52 |
| ogra_ | which very likely has transition bits that are missing in the system now | 11:52 |
| smb | could well be... | 11:53 |
| smb | I guess it could end in "backup everything or at least all /home" and do a fresh install now | 11:55 |
| ogra_ | yeah | 12:01 |
| Kano | hi, could somebody fix the 32 build buils of 3.0 kernel? | 12:16 |
| apw | Kano, why are they fialing | 12:39 |
| Kano | look into the log | 12:39 |
| apw | you have such a way with words, so encouraging to people who you want things from | 12:40 |
| Kano | you dont want to test the kernel? | 12:40 |
| apw | i don't use the mainline builds to test the kernel | 12:41 |
| apw | i use the ubuntu kernel to test the ubuntu kerenl, it is a more appropriate test | 12:41 |
| Kano | i use u style kernel only for live mode. for testing i think mainline is better because it does not add extra patches | 12:41 |
| apw | apw@dm$ cat /proc/version_signature | 12:42 |
| apw | Ubuntu 3.0-0.1~apwv1-generic 3.0.0-rc2 | 12:42 |
| apw | that may be true for you, for the ubuntu kernel team tesing the ubuntu kernle is clearly the most appropriate kernel to test | 12:42 |
| apw | looking at why the mainline builds are not building on 32 bit is on my list, but not high on it right now | 12:43 |
| apw | if someone tells me whats wrong then thats a smaller job and it may get done earlier | 12:43 |
| Kano | dont they use the same config like your other builds? | 12:43 |
| apw | yes they use the same configs, thats how i know its not a conig issue | 12:43 |
| amitk | apw: you guys have an offline tool to mass-manipulate several LP blueprints at once? | 13:00 |
| apw | amitk, nothing for mnipulaitng blueprints in my toolbox sadly | 13:05 |
| apw | amitk, i know how to consume them, not change them | 13:05 |
| amitk | apw: consume them? I need something to make mass changes to a group of blueprints (subscribe a group, set milestones, priorities, etc.) | 13:08 |
| amitk | dunno how much of my life is wasted going through the slow web frontend | 13:09 |
| apw | amitk, no i don't really have that many, i think there may be launchpad lib interfaces though | 13:16 |
| tgardner | apw please take a moment to review https://lists.ubuntu.com/archives/kernel-team/2011-May/015693.html so I can get it out of my inbox | 13:58 |
| apw | tgardner, replied, not sure the changes work mind | 14:05 |
| tgardner | apw, I'm fine with that. just wanted to be sure kees was getting some attention. | 14:06 |
| apw | tgardner, yep guessed as much | 14:09 |
| tgardner | apw, looks like I should update the chroots for m-i-t ? | 14:09 |
| apw | tgardner, yes please | 14:10 |
| * apw watches the weather take a vile turn ... i can hardly see out the window its raining so hard | 14:10 | |
| apw | tgardner, when i looked yesterday maverick didn't have the compiler installed, only the -base package -- meant to mention it | 14:12 |
| apw | (on tangerine) | 14:13 |
| tgardner | apw, the cross compiler ? | 14:13 |
| apw | tgardner, indeed | 14:13 |
| apw | in natty there are two packages foo and foo-base iirc, and on maverick only the latter | 14:13 |
| tgardner | apw, gcc-arm-linux-gnueabi g++-arm-linux-gnueabi | 14:14 |
| tgardner | apw, those are the 2 packages that get installed for either chroot | 14:14 |
| apw | in maverick-i386 we have: | 14:15 |
| apw | ii gcc-4.5-arm-linux-gnueabi-base 4.5.1-7ubuntu1cross1.38 The GNU Compiler Collection (base package) | 14:15 |
| apw | and in natty we have: | 14:15 |
| apw | ii gcc-4.5-arm-linux-gnueabi 4.5.2-8ubuntu3cross1.47 The GNU C compiler | 14:15 |
| apw | ii gcc-4.5-arm-linux-gnueabi-base 4.5.2-8ubuntu3cross1.47 The GNU Compiler Collection (base package) | 14:15 |
| apw | and i found yesterday i could only build in the natty one ... | 14:16 |
| apw | (i meant to mention it when i was talking to you about crosses then) | 14:16 |
| apw | tgardner, ^^ | 14:16 |
| tgardner | apw, (maverick-i386)rtg@tangerine:~/kteam-tools/chroot-setup$ dpkg -l|grep "gcc.*arm" | 14:19 |
| tgardner | ii gcc-4.4-arm-linux-gnueabi 4.4.4-14ubuntu4 The GNU C compiler | 14:19 |
| tgardner | ii gcc-4.4-arm-linux-gnueabi-base 4.4.4-14ubuntu4 The GNU Compiler Collection (base package) | 14:19 |
| tgardner | ii gcc-4.5-arm-linux-gnueabi-base 4.5.1-7ubuntu1cross1.38 The GNU Compiler Collection (base package) | 14:19 |
| tgardner | ii gcc-arm-linux-gnueabi 4:4.4.4-9 The GNU C compiler for armel architecture | 14:19 |
| tgardner | ii libgcc1-armel-cross 1:4.5.1-7ubuntu2cross1.52 GCC support library | 14:19 |
| apw | tgardner, note the version numbers, 4.5 is missing | 14:20 |
| tgardner | ah | 14:20 |
| * apw notes they have used 4 epochs on gcc-arm-linux-gnueabi ! | 14:21 | |
| tgardner | apw, this looks like a meta package problem. lemme keep drilling. | 14:23 |
| tgardner | apw, I've fixed both Maverick chroots by hand. | 14:26 |
| apw | tgardner, i suspect that is why ppisati wants to use natty chroots | 14:26 |
| tgardner | apw, nah, I think he's just being lazy (like the rest of us) | 14:34 |
| * smb reboots | 14:36 | |
| ppisati | tgardner: yes, i am :) | 14:42 |
| ppisati | i never use chroot, it' | 14:42 |
| ppisati | 's simpler | 14:42 |
| tgardner | ppisati, 'echo "debuild -B -us -uc -aarmel"|schroot -c maverick-amd64 | 14:43 |
| tgardner | apw, the installation of the gcc-arm-linux-gnueabi meta package appears to have a generic problem. oneiric chrrots have the same version issues, only its 4.5 and 4.6 instead of 4.4 and 4.5 | 14:48 |
| apw | tgardner, interesting ... | 14:49 |
| sforshee | tgardner, do you continue to pull in compat-wireless updates for as long as a given release is supported? | 14:50 |
| tgardner | sforshee, generally. I usually do all the updates when the next major release comes out. I started on 2.6.39 yesterday, but haven't finished it yet | 14:51 |
| sforshee | tgardner, so do you think we should update the rt2800 firmware in maverick/lucid/hardy so that RT307x can be supported? | 14:51 |
| tgardner | sforshee, as long as it doesn't create regressions for existing RT devices, though it would be hard to tell since they are all lousy. | 14:52 |
| tgardner | sforshee, but yes, I think its worth doing. | 14:53 |
| sforshee | tgardner, I have one tester who has tested existing RT devices in lucid at least and found that they work better with the newer firmware | 14:53 |
| tgardner | sforshee, that seems like sufficient reson then | 14:53 |
| tgardner | reason* | 14:53 |
| sforshee | tgardner, ack | 14:53 |
| === BenC__ is now known as BenC | ||
| sforshee | tgardner, how is wireless firmware handled in hardy? There doesn't seem to be any linux-firmware package. | 15:15 |
| tgardner | sforshee, IIRC its in the LBM package | 15:16 |
| tgardner | or the kernel. | 15:16 |
| apw | tgardner, ogasawara, just looking at this upload, i am wondering what the documentation and source packages should be called previously we called them -2.6, by that rules they would be come -3 ... thoughts? | 15:19 |
| apw | tgardner, or LUM? | 15:19 |
| tgardner | apw, LUM might be it. sforshee ^^ | 15:20 |
| sforshee | tgardner, apw: thanks, I'll dig through those and see what I find | 15:21 |
| ogasawara | apw: I was thinking about it a bit, and I think going with -3.x seems more appropriate to me | 15:21 |
| tgardner | apw, I think thats another of those cases where the 2 v.s. 1 digit version is gonna give us problems. | 15:21 |
| apw | ogasawara, the downside is that we may end up with multiple version numbers on the machine if we call it 3.0, before we had just -2.6 now we'd have 3.0 and 3.1 | 15:22 |
| tgardner | ogasawara, 3.x is lexicographically inferior | 15:22 |
| apw | tgardner, well having 3 digits doesn't help here as we have the equivalent of the 6 in 2.6 changing | 15:22 |
| apw | ogasawara, oh did you literally mean -3.x with a letter x ? | 15:23 |
| ogasawara | apw: I didn't, but we could do that | 15:23 |
| ogasawara | apw: I meant 3.0, 3.1, 3.2 ... | 15:23 |
| apw | ogasawara, ok thats what i thought you meant first time | 15:23 |
| tgardner | a literal '3.x' might work as well. | 15:24 |
| ogasawara | apw: indeed that does mean you would get multiple packages on the machine though, how much space do those consume? | 15:24 |
| apw | ogasawara, looking | 15:26 |
| apw | ogasawara, tgardner ok they are 91MB however i see they have clever conflicts replaces in them | 15:29 |
| apw | so that they replace each other | 15:29 |
| ogasawara | apw: that's nice then, that was going to be my next question | 15:30 |
| apw | and indeed they are actually called l-s-2.6.38 in full so we do not need to think about those | 15:30 |
| tgardner | apw, as long as we're just replacing versions, right? the package name doesn't change with ABI does it? | 15:30 |
| apw | there is a small bug in our changes which prevents the bump from | 15:30 |
| apw | tgardner, no indeed, and actually it conflicts/replaces on a virtual name linux-source-2.6 which keeps us with just one | 15:31 |
| apw | and rather madly i think those actually should remain as -2.6 | 15:31 |
| apw | so that we replace ourselves correctly, ie we should conflict/replace l-s-2.6 and l-s-3 | 15:32 |
| apw | which will then do the right thing going forward | 15:32 |
| apw | tgardner, one other issue ... | 15:32 |
| apw | if we chose 3.0 as the package we can widen the version later to 3.0.0 as 3.0 < 3.0.0 and all is well | 15:32 |
| tgardner | apw, as you've mentioned... | 15:33 |
| apw | however for the linux-meta 3.0.0.1 (3.0 + abi 0 + upload 0) it > 3.0.0.0.1 (3.0.0-0.1) | 15:33 |
| apw | so either way we chose we are in for issues changing them later | 15:33 |
| ogasawara | bah, I didn't think about meta borking like that | 15:33 |
| apw | ogasawara, its a pain in the botty for sure | 15:34 |
| apw | of course we can bodge the meta to widen its 3.0 -> 3.0.0 during package generation | 15:35 |
| apw | but its something to consider | 15:35 |
| apw | and visa-versa for that matter | 15:35 |
| smb | bjf, For the new lucid-ec2 package I opened bug 794420 as new tracking bug. I removed the tracking bug for the main package from the rebase logs as that seemed giving wrong leads (hope that is correct). Remind me what I have to do with the previous tracking bug for lucid-ec2? Mark it a duplicate of the new one? | 15:35 |
| ubot2 | Launchpad bug 794420 in linux-ec2 "linux-ec2: 2.6.32-317.34 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/794420 | 15:35 |
| apw | so perhaps the logical thing to do is upload the kernel using 3.0, and meta using 3.0.0 but with a frig to drop the .0 | 15:35 |
| apw | and then when we decide for sure, we can get out of it | 15:36 |
| apw | tgardner, ogasawara ^^ | 15:36 |
| ogasawara | apw: that sounds like a good idea | 15:36 |
| brendand | bjf - are the going to be new -proposed kernels? are the current tracking bugs still valid? | 15:48 |
| bjf | brendand, will be updating trackers soon | 15:48 |
| sforshee | tgardner, afaict hardy doesn't currently have any rt28xx firmware files. LUM has a ubuntu-firmware/rt2x00 directory -- do I just drop the firmware files in there? | 15:51 |
| tgardner | sforshee, is there a firmware directory in Hardy LBM? | 15:52 |
| sforshee | tgardner, yes | 15:52 |
| tgardner | sforshee, thats likely where it should go. | 15:53 |
| apw | tgardner, isn't lbm elective? arn't be aiming these new firmwares for all users ? | 15:53 |
| tgardner | apw, not necessarily. doesn't the RT driver only come through compat-wireless in Hardy ? | 15:54 |
| apw | tgardner, fair point, if so then you are correct it should go with the driver | 15:54 |
| tgardner | sforshee, see how iwlwifi firmware is treated. the munge file changes the name so there are no conflicts. | 15:55 |
| sforshee | tgardner, thanks, I'll take a look at that | 15:55 |
| tgardner | sforshee, hardy, as usual, is a bit of an abomination. | 15:56 |
| jpiche | does anyone have documentation on compiling (or installing a pre-build) a vanilla 2.6.39 or 3.0-rc kernel in natty? I'm struggling with bug 775950 and want to test if it was already fixed upstream | 15:58 |
| ubot2 | Launchpad bug 775950 in linux "fixing recursive fault but reboot is needed! upon boot (always reproducible on battery only, but sometimes on AC too)" [Undecided,Confirmed] https://launchpad.net/bugs/775950 | 15:58 |
| brendand | bjf - thanks | 15:58 |
| jburkholder | are you guys doing arm work on target or cross compiling packages for distribution? | 16:01 |
| apw | jburkholder, our packages in the archive are native built | 16:01 |
| jburkholder | what target hardware do you use? | 16:01 |
| jburkholder | I mean host, as in what arm platform or board? | 16:04 |
| apw | jburkholder, i guess when i say native, i mean on armel hardware, on a freescale board | 16:04 |
| jburkholder | ah I see | 16:04 |
| jburkholder | is beagleboard usable? | 16:04 |
| apw | jburkholder, beagleboard is one of those that the arm people pay attnetion to, IIRC its not officially something we prioritise, but its still watched closly ... you should ask in #ubuntu-arm, the'd know better | 16:06 |
| jburkholder | ok, thanks | 16:06 |
| jburkholder | gotta move to a different computer and watch the kids | 16:07 |
| hggdh | bjf, I do not have EC2 kernels to test for Hardy proposed | 16:19 |
| hggdh | bjf, as such, I am marking the QA tests done | 16:19 |
| smb | hggdh, For Hardy the -xen kernels would be the ones to use under ec2. But I am not sure how well that is integrated (server-team used to have some package in a ppa but the kernel config and level was the same as -xen) | 16:21 |
| hggdh | smb, we need a specific image generated for the -proposed kernel; we cannot dist-upgrade | 16:22 |
| hggdh | smb, Hardy does not support upgrading the kernel like the newer releases | 16:23 |
| smb | hggdh, Well you can but the word is not spread that much | 16:23 |
| hggdh | (for EC2) | 16:23 |
| smb | hggdh, If you take current amis from http://uec-images.ubuntu.com/hardy/current/ and the pv-grub akis from | 16:24 |
| smb | https://lists.ubuntu.com/archives/ubuntu-cloud/2010-December/000466.html | 16:24 |
| BenC | Hey guys, what's the current state of powerpc in ubuntu? I notice there's a 10.10, but no 11.04 | 16:26 |
| BenC | (and even the 10.10 iso is too big to actually burn to a CD) | 16:27 |
| BenC | And I'm speaking more from a server standpoint than desktop | 16:27 |
| hggdh | smb, I understood Hardy did not have pv-grub support | 16:28 |
| smb | hggdh, Not officially. Its more thanks to lots of work by smoser | 16:29 |
| hggdh | smb, still confused... the link you provided shows AKIs for Lucid | 16:29 |
| smoser | hggdh, right... there is a stub /boot/grub/menu.lst there really just as an unsupported mechanism to launch with pv-grub and get its beneifits. | 16:30 |
| smb | hggdh, Yes, but basically those aki are not kernels but pv-grub loaders | 16:30 |
| tgardner | BenC, AFAIK powerpc works in 11.04, though its mostly still community supported. Luke uses it on his old G4 I think. | 16:30 |
| smoser | but i do not intend on backporting the rest of the stuff that manages that file | 16:30 |
| smoser | basically the /boot/grub/menu.lst that is there just boots /vmlinuz and /initrd.img | 16:30 |
| smoser | so whatever those links are is what you get | 16:30 |
| BenC | tgardner: Ok, it looks like I'll be giving it a lot of love here soon | 16:30 |
| BenC | definitely not in the Mac area, just generic powerpc work | 16:31 |
| tgardner | 11.04 love? | 16:31 |
| smoser | so the hardy dailies are good if you boot with the pv-grub loaders, but by default hey do not use them. | 16:31 |
| hggdh | smoser, so I can dist-upgrade, as long as I use AKI, correct? | 16:31 |
| smoser | you can, as log as you run-instances with the --kernel flag | 16:31 |
| hggdh | yes. Doing it now | 16:31 |
| BenC | tgardner: probably more for 11.10, but starting with 11.04 as a base | 16:37 |
| apw | BenC, sounds intereiting | 16:39 |
| BenC | Any if you guys happen to be going to the Freescale Technology Forum in two weeks? | 16:40 |
| BenC | *of | 16:41 |
| tgardner | BenC, nope, Dublin in a couple of weeks | 16:41 |
| apw | BenC, where is it ? ... oh in that case likely we're not | 16:41 |
| BenC | It's in San Antonio | 16:41 |
| * amitk waves to BenC | 16:42 | |
| BenC | Hey Amit | 16:42 |
| amitk | tgardner: you guys get better beer than we do - we're going to cambridge in aug (skipping dublin) | 16:43 |
| bjf | ogasawara, apw, at a point where you want to mumble about bug scripts? | 16:44 |
| tgardner | amitk, bummer dude :) | 16:44 |
| ogasawara | bjf: sure | 16:44 |
| amitk | bjf: do you know of any magic to mass-modify blueprints? (like your bug tool) | 16:45 |
| amitk | (I already asked andy this morning) | 16:45 |
| apw | bjf sure ... yank me | 16:45 |
| bjf | amitk, i've not tried that before, so no, i'd think pitti might | 16:45 |
| tgardner | bjf, I have an LBM for Natty ready with compat-wireless-2.6.39. Shall I just upload to the c-k-t PPA ? bug #794633 | 17:10 |
| ubot2 | Launchpad bug 794633 in linux-backports-modules-2.6.38 "Add compat-wireless-2.6.39" [Undecided,In progress] https://launchpad.net/bugs/794633 | 17:10 |
| bjf | tgardner, yes, make it so | 17:11 |
| tgardner | bjf, it appears someone (i.e., sconklin) neglected to push Natty LBM 2.6.38-10.4 to the repo | 17:14 |
| bjf | hmmm | 17:14 |
| tgardner | bjf, s'ok, I'll just skip to 10.5 | 17:14 |
| apw | presumably that was just an abi bumper | 17:17 |
| apw | so you can put the missing changelog entry in | 17:18 |
| tgardner | apw, yep, I noted it in the changelog | 17:18 |
| ppisati | so, during a rebase, what's the procedure to get the changelog updated? fdr printchanges doesn't show anything | 17:18 |
| ppisati | and the release looks correctly closed to me | 17:18 |
| apw | ppisati, | 17:18 |
| apw | you first startnewrelease | 17:18 |
| bjf | ppisati, how did you do your rebase? did you use the maint script? | 17:18 |
| ppisati | manually | 17:19 |
| ppisati | and i guess i have to use this script | 17:19 |
| ppisati | ... | 17:19 |
| apw | then commit use ubuntu-insert-changes previous-base new-base | 17:19 |
| apw | then commit that as 'rebase to ...' | 17:19 |
| ppisati | ah ok | 17:19 |
| apw | hopefully thats roughtly what the script does :) | 17:19 |
| bjf | ppetraki, you don't have to use the script, what apw said | 17:19 |
| ppisati | so it's doable even manually | 17:19 |
| ppisati | cool | 17:19 |
| bjf | apw, yes, i believe so | 17:20 |
| ppisati | and i've a couple pf patches too | 17:20 |
| ppisati | shall i shove it together with the rebase? | 17:20 |
| ogasawara | bjf: http://pastebin.ubuntu.com/621856/ so that's what I used to use to for my launchpadlib scripts to run as different users. you'd only have to authenticate the first time, and subsequent runs would use the stored credentials file | 17:20 |
| ppisati | ok | 17:20 |
| ppisati | nevermind | 17:20 |
| ppisati | i'll do a separate pull req | 17:20 |
| ogasawara | bjf: I've not used that in a while though so no clue if it's still valid. And I think you had actually moved a lot of that into a lp_login class | 17:20 |
| bjf | ppisati, also, remember to add the tracking bug, look at https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePatchApplication steps 6 and 7 | 17:21 |
| ppisati | bjf: ok | 17:22 |
| bjf | ogasawara, thanks, will look that over, think most is in the library now | 17:22 |
| bjf | ppisati, also step #11 | 17:22 |
| bjf | ppisati, actually, everything after step #6 | 17:23 |
| ogasawara | bjf: I'll try to dig up the username and password for the kernel janitor we'd made up in case you want to use that for anything | 17:23 |
| bjf | ogasawara, thanks | 17:23 |
| apw | ogasawara, yeah i forgot to ask about her | 17:23 |
| tgardner | apw, ogasawara: do you remember if there was a reason that the Natty meta package names were shortened from compat-wireless to cw ? | 17:33 |
| tgardner | though they are not published yet | 17:33 |
| ogasawara | tgardner: hrm, no idea here | 17:33 |
| apw | tgardner, yes the CD filenames are too long and you have to use some | 17:34 |
| apw | option which makes the CDs non-standard to make them | 17:34 |
| tgardner | apw, ah, OK | 17:34 |
| apw | i think it was 64 character overall for the .deb name | 17:35 |
| ppisati | i get a stack trace using create-release-tracker --staging | 17:38 |
| ppisati | lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized | 17:38 |
| ppisati | but i authorized my box on the launchpad page that the script opens | 17:39 |
| tgardner | bjf ^^ | 17:39 |
| bjf | ppisati, can you pastebin the stacktrace? | 17:40 |
| ppisati | yep | 17:40 |
| ppisati | http://pastebin.ubuntu.com/621874/ | 17:41 |
| bjf | looking | 17:41 |
| bjf | ppisati, did it give you a url to the bug it created? | 17:42 |
| ppisati | nope | 17:42 |
| ppisati | it opened a web page | 17:42 |
| ppisati | asked for permission to access my profile | 17:42 |
| ppisati | gave it one hour permission | 17:42 |
| ppisati | and then it hanged there | 17:42 |
| broder | out of curiosity, does anybody know if the interface between module-init-tools and the kernel is arch-specific? i.e., could i use an arm insmod to load i386 modules into an i386 kernel (assuming i could get said insmod to run at all)? | 18:09 |
| lifeless | broder: ---meeeeepppppp----- | 18:11 |
| broder | i'm trying to figure out whether module-init-tools can be multi-arch: foreign or needs to be multi-arch: allowed :) | 18:11 |
| lifeless | yeah | 18:12 |
| lifeless | I can see that. Still made my brain implode as I imagined a dash implementation. | 18:12 |
| apw | lifeless, erm, that would never make sense it hink | 18:19 |
| lifeless | apw: thus the brain implosion | 18:20 |
| apw | it seems utterly unreasonable to use a version of the tools which doesn't match the kernel | 18:21 |
| broder | yeah, i can buy an unreasonableness argument | 18:22 |
| apw | cirtainly you couldn't load a i386 kernel module into an amd64 kernel, whether an i386 modprobe could load it | 18:22 |
| apw | is i guess the real question | 18:22 |
| broder | looking at an strace of insmod, it seems like it *might* work | 18:22 |
| apw | i suspect it mmaps the file and then passes the buffer to the kernel | 18:22 |
| hggdh | bjf, smb hardy ec2 tests run, failure on QRT test-kernel-security. I have pinged kees on -hardened. I also cannot change the status on the tracking bug | 18:22 |
| broder | apw: yeah, that appears to be correct | 18:23 |
| apw | so in theory you could do it, but it seem utterly not something you'd ever want to do | 18:23 |
| apw | broder, as i am playing with m-i-t at the moment is this something i should worry about? | 18:23 |
| broder | multi-arch: allowed it is, then | 18:23 |
| smb | hggdh, I am not utterly sure. Do we have a qrt test run without failure before and is the new one probably a newer test? | 18:24 |
| broder | apw: probably not. i'm trying to figure out the concrete changes that would need to be done to allow installing an arch: amd64 kernel on an i386 userland using multiarch | 18:24 |
| apw | broder, oh i see, that is a valid use case of multi-arch, there i think you would want the amd64 binaries really | 18:25 |
| apw | though if the 32bit ones work that is easier | 18:25 |
| hggdh | smb, not to my knowledge, no hardy xen ran before (I did run a m1.large on the current yesterday, but this seems to be i386 only) | 18:25 |
| apw | actually given i know of people who slam on the 64bit kernel overriding the screaming alarms | 18:25 |
| apw | and they boot ok, i assume the 32bit modprobe does work there | 18:25 |
| broder | apw: right, so you'd set multi-arch: allowed in m-i-t, then in things like acpid and bluez that just depend on it for a modprobe binary, we'd change the dependency to m-i-t:any | 18:25 |
| apw | broder, ^^ | 18:25 |
| hggdh | smb, http://reports.qa.ubuntu.com/reports/kernel-sru/home/ubuntu/sru-kernel-test/hardy-2.6.24-29.90/m1.small-i386/qrt-kernel-security.txt | 18:26 |
| broder | yeah, i've seen 32-bit and 64-bit work. i'm wondering if that assumption breaks down when the skew between m-i-t and the kernel is more than just bittedness | 18:26 |
| broder | but i think likely not | 18:26 |
| apw | i t | 18:26 |
| === bjf is now known as bjf-afk | ||
| kees | hggdh: whoooa, yeah, no. CONFIG_COMPAT_VDSO _must_ stay disabled | 18:29 |
| broder | apw: you know, even if such a modprobe could theoretically work, you probably have no hope of bootstrapping enough binfmt-misc-related stuff to get that modprobe to work | 18:29 |
| kees | hggdh: if that's what /proc/version_signature shows, that's what you're running, afaik | 18:29 |
| apw | broder, i suspect not | 18:30 |
| apw | kees, yep /proc/version_signature is burnt into the binary | 18:30 |
| apw | kees, you'll be glad to know: !exists CONFIG_COMPAT_VDSO | value CONFIG_COMPAT_VDSO n | 18:31 |
| hggdh | kees, http://pastebin.ubuntu.com/621903/ | 18:31 |
| kees | apw: yeah, that's what I thought. I was pretty sure it was impossible to build a kernel with that disabled. | 18:32 |
| apw | hggdh, but thats xen, arn't the domU kernels outside the domU ? | 18:32 |
| kees | hggdh: I don't know what to tell you; you're not running the right kernel. | 18:32 |
| apw | if memory serves you start a xen instance from a kernel file in the dom0 ? | 18:32 |
| apw | smb, ^^ ? | 18:32 |
| smb | apw, gah why all people start asking at the same time | 18:33 |
| apw | smb, so ignore me for a bit :) | 18:33 |
| smb | apw, the hardy kernel can be dom0 and domu | 18:33 |
| smb | but for ec2 its domu | 18:33 |
| apw | smb, but the image you boot you say like 'xen make instance using this kernel' | 18:33 |
| apw | so the physical binary for the kernel is 'outside' the domU image space in the dom0 image | 18:34 |
| smb | apw, No you can freely define what kernel you start inside domu | 18:34 |
| smb | it can be but does not has to | 18:34 |
| apw | ok thansk :) | 18:34 |
| hggdh | in this case I ran the instances with the AKI pointed to by both smb and smoser | 18:35 |
| smb | which looks inside the disk image and boots a kernel found there | 18:36 |
| apw | smb, even on hardy ? | 18:36 |
| apw | even on a hardy image ? | 18:36 |
| hggdh | which puts us back to the beginning. There is no -generic installed | 18:37 |
| apw | hggdh, anything lurking in /boot ? seems unlikely | 18:37 |
| smb | apw, It depends on the image | 18:37 |
| smoser | hggdh, and there will not be *ever* on ec2. | 18:37 |
| smoser | you want the -xen kernel on ec2. | 18:37 |
| smb | but the ones from from current builds suport it | 18:37 |
| smoser | for hardy | 18:37 |
| apw | ubuntu@domU-12-31-39-16-A8-2A:~$ cat /proc/version_signature | 18:37 |
| apw | Ubuntu 2.6.24-4.6-generic | 18:37 |
| hggdh | <sigh/> | 18:38 |
| apw | and his domU whereever it is running is picking up an older kernel | 18:38 |
| smb | I'd need to see menu.lst | 18:38 |
| smb | on the domu | 18:38 |
| smoser | are you talking about hardy image? | 18:38 |
| smb | IT would not be generic though | 18:39 |
| smb | but -xen | 18:39 |
| smoser | hardy ami's have a very simple menu.lst | 18:39 |
| apw | ii linux-image-xen 2.6.24.29.31 Real time Linux kernel image | 18:40 |
| apw | smb ^^ :) i think our meta package has problems | 18:40 |
| smoser | see lines 250-259 at http://bazaar.launchpad.net/%7Eubuntu-on-ec2/vmbuilder/automated-ec2-builds/annotate/head%3A/vmbuilder-uec-ec2-fixes | 18:40 |
| smoser | basically, it wil boot whatever is at /vmlinuz | 18:40 |
| smb | apw, why exactly. bear with me not spotting what you mean | 18:41 |
| apw | hggdh, and what does /vmlinuz look like/point at | 18:41 |
| smoser | if you install a bad kernel, it will update the symlink, and when you reboot you'll be hosed. | 18:41 |
| apw | smb, -xen -> -rt description | 18:41 |
| smoser | it points to the last installed kernel | 18:41 |
| smb | apw, Oh, probably noboday cared enough | 18:41 |
| apw | smoser, thats what its supposed to point at, what does his actually point at | 18:41 |
| smb | apw, That would we need from hggdh | 18:42 |
| smb | or acces to the domu | 18:43 |
| * tgardner --> lunch | 18:43 | |
| hggdh | smb, I am starting a new m1.small instance | 18:43 |
| apw | FINALLY 3.0-rc2 mainline kernels built right | 18:43 |
| hggdh | smb, smoser, apw well, a hardy current m1.small reports itself as a -generic on /proc/version_signature | 18:48 |
| apw | hggdh, runing on ec2? or running on uec | 18:49 |
| hggdh | apw, AWS EC2 | 18:49 |
| smb | Hm, I have never looked close. I think I start one myself just for the fun of it | 18:50 |
| * smoser is curious too | 18:51 | |
| smoser | it *can't* be right | 18:51 |
| smb | I had been assuming something somewhere with xen in its name, either form the uec ppa or the custom-binary | 18:52 |
| hggdh | http://pastebin.ubuntu.com/621917/ | 18:53 |
| * smb has some deja-vu | 18:55 | |
| smb | I think its the bodged version_signature of the xen kernel... | 18:55 |
| smb | It tells you lies | 18:55 |
| smb | hggdh, look in dmesg | 18:56 |
| apw | smb, OH now that rings a bell | 18:56 |
| apw | somethign like someone has committed a version into VERSION_SIGNTURE on the xen bits | 18:56 |
| apw | didn't we fix that ever? | 18:56 |
| hggdh | not really sure it will help :-) | 18:56 |
| hggdh | [ 0.000000] Linux version 2.6.24-29-xen (buildd@vernadsky) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Thu Apr 21 20:44:30 UTC 2011 (Ubuntu 2.6.24-4.6-generic) | 18:56 |
| apw | if not that is lame of us | 18:56 |
| smb | apw, Yeah, either that or not changing the right bits and ending up with the wrong one | 18:57 |
| apw | debian/config/i386/config.generic:CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-4.6-generic" | 18:57 |
| smb | apw, It is pretty lame. We should have changed it a while ago but without it hurting usually and that oteher piles... :( | 18:57 |
| apw | yeah look its in the damn config, that is utterly broken | 18:57 |
| apw | smb, but it correctly gets fixed for non-xen | 18:58 |
| apw | cat $^ | sed -e 's/.*CONFIG_VERSION_SIGNATURE.*/CONFIG_VERSION_SIGNATURE="Ubuntu $(release)-$(revision)-$*"/' > $(builddir)/build-$*/.config | 18:58 |
| apw | so the other build thingy must miss that step | 18:58 |
| smoser | ok... | 18:58 |
| smoser | hggdh, which ami did you run? | 18:59 |
| smoser | latest released version? | 18:59 |
| * apw sees if he can FIX that | 18:59 | |
| smb | It was something only hitting that custom-binary-build | 18:59 |
| smoser | wait, apw you dont have anything to fix | 18:59 |
| apw | hggdh, that dmesg looks like a sane version | 18:59 |
| smoser | hggdh ran latest released version of hardy ami. | 18:59 |
| apw | smoser, yeah i do, the /proc/version_signature is _wrong_ | 18:59 |
| smoser | that runs a kernel from a ppa | 18:59 |
| smoser | its crap | 18:59 |
| smoser | the latest dailies use a kernel from the archive | 18:59 |
| apw | the version in dmesg is right, but /proc/version_signature is not | 18:59 |
| apw | and i think its still broken | 18:59 |
| smoser | the reason hggdh is in this excercise of frustration is so that we can release an updated ami with an archive kernel | 19:00 |
| smoser | which does not show the bug | 19:00 |
| smb | smoser, actually the 2.6.24-29-xen looks like from the archive | 19:00 |
| smoser | $ dpkg -S /boot/vmlinuz-2.6.24-29-xen | 19:00 |
| smoser | linux-image-2.6.24-29-xen: /boot/vmlinuz-2.6.24-29-xen | 19:00 |
| smoser | $ uname -r | 19:00 |
| smoser | 2.6.24-29-xen | 19:00 |
| smb | I get the same running current daily with pv-grub | 19:00 |
| apw | smb, do you have recent kernels in your xen setup could you see if its busted | 19:00 |
| apw | hggdh, yeah can you get uname -r and cat /proc/version_signature at the same time | 19:00 |
| * apw best v_s is crap | 19:00 | |
| smb | apw, It surely is still busted, cause I remember not to have fixed anything there | 19:00 |
| hggdh | certainly | 19:00 |
| smoser | ah. | 19:00 |
| smoser | sorry. | 19:00 |
| apw | smb, whars your version_sig look like | 19:00 |
| apw | smoser, even | 19:01 |
| smoser | yeah, version_signature is foobarred | 19:01 |
| smoser | but uname -r is not | 19:01 |
| smoser | sorry, missed that. | 19:01 |
| hggdh | oh bloody hell, I stopped the instannce | 19:01 |
| apw | ok ... i am sick of having this same error | 19:01 |
| * hggdh starts Yet Another EC2 instance | 19:01 | |
| apw | i am going to damn well fix it | 19:01 |
| smb | ubuntu@domU-12-31-39-0E-A4-E2:~$ uname -a | 19:01 |
| smb | Linux domU-12-31-39-0E-A4-E2 2.6.24-29-xen #1 SMP Thu Apr 21 20:44:30 UTC 2011 i686 GNU/Linux | 19:01 |
| smb | ubuntu@domU-12-31-39-0E-A4-E2:~$ cat /proc/version_signature | 19:01 |
| smb | Ubuntu 2.6.24-4.6-generic | 19:01 |
| smoser | yeah | 19:01 |
| * smoser has never looked at version_signature before | 19:01 | |
| smb | Well apw and me did at some point, shook heads, said this needs a fix and forgot | 19:02 |
| hggdh | ubuntu@ip-10-36-7-174:~$ uname -a && cat /proc/version_signature | 19:02 |
| hggdh | Linux ip-10-36-7-174 2.6.24-29-xen #1 SMP Thu Apr 21 20:44:30 UTC 2011 i686 GNU/Linux | 19:02 |
| hggdh | Ubuntu 2.6.24-4.6-generic | 19:02 |
| apw | smb, no we wasted several hours before realising it was ver_sig which was ass | 19:02 |
| apw | then we said we should fix it, and we nearly did it again | 19:03 |
| apw | so i am going to fix it NOW | 19:03 |
| apw | so i don't waste any more of my life | 19:03 |
| smoser | another reason for us to get to an archive kernel for hardy amis | 19:03 |
| smoser | apw, and i am willing to wait on that fix to re-release. | 19:03 |
| smoser | since its been quite a while since the last anyway | 19:03 |
| smoser | but i'd like to have hggdh work though and see if it generally otherwise smells good. | 19:04 |
| hggdh | smoser, already did -- last two lines: https://wiki.ubuntu.com/QATeam/kernelSRU-hardy-2.6.24-29.90 | 19:04 |
| smb | smoser, hggdh So currently it would probably be abi and build time as a rough indicator one has the proposed kernel | 19:05 |
| hggdh | smb, that and what linux-image\* you have installed | 19:05 |
| smb | hggdh, right | 19:06 |
| smoser | hggdh, so what does that say there ? | 19:06 |
| smoser | FAILEd | 19:06 |
| smoser | ? | 19:06 |
| hggdh | well, yes | 19:07 |
| hggdh | and the logs show it | 19:07 |
| hggdh | but it seems it is an error on the test script, kees knows more | 19:07 |
| kees | smoser: so is the hardy xen kernel built wrong for the VDSO_COMPAT? | 19:26 |
| * smoser knows not of such a thing | 19:27 | |
| smoser | but, to re-iterate, all released Ubuntu hardy AMIs are from a ppa kernel build | 19:28 |
| smoser | (yuck) | 19:28 |
| kees | so what hggdh is testing isn't the real thing? | 19:28 |
| apw | kees, from a -xen i just built from the tip: CONFIG_COMPAT_VDSO=y | 19:28 |
| smoser | we are trying to get to the archive build of -xen kernel | 19:28 |
| smoser | kees, i believe that hggdh is testing the -xen kernel from the archive... thats what we're trying to move to. | 19:29 |
| kees | apw: I thought it was enforced to be unset? | 19:29 |
| smoser | so, in regard to your question,i believe the answer is "yes, it is the real thing" | 19:29 |
| apw | kees, in 'modern' versions yes | 19:30 |
| smb | kees, I am currently running the tests again with current proposed -xen kernel | 19:30 |
| apw | kees, i think lucid and above, the AAs refused the update to hardy to take the build checks | 19:30 |
| apw | kees, but it seems that just the -xen flavour is out of kilter for this | 19:30 |
| apw | debian/binary-custom.d/xen/config.i386:CONFIG_COMPAT_VDSO=y | 19:30 |
| kees | so we can fix that for the future? | 19:31 |
| apw | kees, unless its on for some reason for that flavour ? | 19:32 |
| smb | kees, If we make sure we do not accidentally break our builders with that | 19:32 |
| apw | smb, can you recall anything about hardy xen needing COMPAT_VDSO turned on | 19:32 |
| === bjf-afk is now known as bjf | ||
| smb | apw, Not specifically | 19:33 |
| smb | apw, ubuntu@ip-10-2-19-128:~$ cat /proc/version_signature | 19:34 |
| smb | Ubuntu 2.6.24-29.90masternext201106081915-xen | 19:34 |
| apw | smb, now that looks better doesn't it | 19:34 |
| smb | much | 19:35 |
| apw | smb, ok i'll get that out for review | 19:35 |
| smb | apw, ack | 19:35 |
| * jjohansen -> lunch | 19:40 | |
| apw | smb, smoser, patch to fix that stupid error is out for review | 19:47 |
| smb | kees, So yes, there are these two failures on ec2 hardy. But then I have that feeling we never really cared much there and those have been present forever. IF we want to change we need at least make sure the builders still work (using that as dom0 kernel) as well as ec2 using it as domU | 19:48 |
| ogasawara | bjf: looks like bug 789982 is fixed in 2.6.38.8. Do you guys use a specific tag so you know what bug #'s to shove in the changelog? | 19:57 |
| ubot2 | Launchpad bug 789982 in linux "SRU: Fix kswapd 100% cpu usage in common scenerios" [Undecided,Confirmed] https://launchpad.net/bugs/789982 | 19:57 |
| ogasawara | bjf: or do you just dupe it to the stable update tracking bug? | 19:57 |
| jburkholder42 | I'm getting someone's weather | 19:57 |
| bjf | ogasawara, i'd just mark if fix released probably | 19:58 |
| apw | yeah i've tended to cut-n-paste the changelog in and fix release it myself | 19:58 |
| ogasawara | bjf: we haven't pulled in the 2.6.38.8 update yet as far as I can tell | 19:58 |
| apw | oh heh :) | 19:59 |
| bjf | ogasawara, oh, sorry was thinking of our -8 | 19:59 |
| tgardner | ogasawara, I started on it but ran into the xhci issues | 19:59 |
| bjf | ogasawara, yes, i guess just dupe it against the tracking bug | 19:59 |
| ogasawara | tgardner: did you open a tracking bug yet? | 20:00 |
| tgardner | yep | 20:00 |
| ogasawara | cool, I'll just dupe it then | 20:00 |
| tgardner | bug #793702 | 20:00 |
| ubot2 | Launchpad bug 793702 in linux "Natty update to 2.6.38.8 stable release" [Undecided,In progress] https://launchpad.net/bugs/793702 | 20:00 |
| tgardner | ogasawara, ^^ | 20:02 |
| ogasawara | thanks | 20:02 |
| hggdh | OK. kess, smb: do we consider the hardy kernel passed or not? | 20:10 |
| apw | hggdh, i suspect its in flux still. i think smb is going to test the VDSO change to see if we need t | 20:11 |
| smb | hggdh, kees, apw yep, I try to see whether a dom0 is ok with it (and maybe ec2 as well). But in general I would only consider a failure a fail if it ever worked before | 20:12 |
| hggdh | kees, smb: I am tagging it a failure then | 20:13 |
| smb | hggdh, Which kernel version did pass that test with hardy on ec2? | 20:14 |
| apw | hggdh, is this for the current proposed kernel testing ? | 20:14 |
| apw | as i think this has been this way forever, so i'd not think it should hold up a -propsoed release | 20:15 |
| apw | as the current one is just as bad, so they are no worse off with the update | 20:15 |
| apw | smb, ^^ | 20:15 |
| * smb agrees | 20:15 | |
| bjf | apw, hggdh, that will make it perfect, regressions for every kernel in -proposed | 20:15 |
| apw | bjf, wtf | 20:15 |
| apw | more new regressions? | 20:15 |
| hggdh | apw, yes, current hardy-proposed | 20:17 |
| hggdh | smb, I have no record on a m1.small before | 20:17 |
| kees | hggdh: if the prior hardy kernel didn't fail, it's a regression. I think it's always been this way, though for the hardy domU. | 20:17 |
| hggdh | kees, I will launch a -89 test on m1.small then | 20:18 |
| kees | smb: the two failures are the same thing. the compat vdso config results in an unrandomized vdso address | 20:18 |
| apw | hggdh, although this is a test failure, i think you'll find if you test whats in -updates is the same we should count the -proposed as 'good' but get high bugs filed for the failures in the test suite | 20:18 |
| smb | hggdh, Right, I am pretty sure those where this way all the way back | 20:18 |
| apw | hggdh, if you can test -updates that would be excellent | 20:18 |
| hggdh | apw, running it now. I will hold on, then on tagging the bug qa-testing-failed | 20:19 |
| apw | yeah sounds good | 20:20 |
| apw | but do file bugs against hardy listing hte failures so we don't forget to fix them | 20:20 |
| hggdh | apw, bugs 794714 794715 reported | 20:31 |
| ubot2 | Launchpad bug 794714 in linux "Hardy Xen DomU: /proc/version_signature wrongly reports -generic kernel" [Undecided,New] https://launchpad.net/bugs/794714 | 20:31 |
| smb | hggdh, actually there is already bug 794698 | 20:32 |
| ubot2 | Launchpad bug 794698 in linux "hardy custom binary kernels have incorrect version reported in /proc/version_signature" [High,Fix committed] https://launchpad.net/bugs/794698 | 20:32 |
| hggdh | smb, heh. I will dup mine, then | 20:32 |
| tgardner | bjf, Ubuntu 2.6.32-33.66-generic 2.6.32.41+drm33.18 | 20:43 |
| bjf | tgardner, cool | 20:43 |
| tgardner | bjf, had some grub 1 problems. guess I should reinstall this 'ol dev box | 20:44 |
| apw | bjf, can you let kees know when lts-backport-natty finally gets into -proposed so he can add it to the cve tracker | 20:44 |
| bjf | tgardner, was beginning to worry when you went away for so long | 20:44 |
| bjf | apw, ack | 20:44 |
| * tgardner is shifting locations | 20:45 | |
| kees | bjf: you sent mail about the workflow tool having issues at the moment. when it's back online, it'll update 788843 for promote-to-security, etc? I noticed it hadn't done that yet. | 20:48 |
| bjf | kees, you can update that anytime, thanks | 20:48 |
| kees | bjf: I didn't want to, since the workflow doc says the bot will do it. | 20:49 |
| kees | (i.e. step 12) | 20:49 |
| kees | afaict, 788843 is ready for an archive admin | 20:50 |
| bjf | kees, heh, i'll look, can't remember how all this is supposed to work for each step | 20:50 |
| bjf | kees, ok, looking into an issue with that bug | 20:50 |
| kees | bjf: cool, let me know if I can help | 20:51 |
| tgardner | ogasawara, received NICs via UPS today | 20:52 |
| ogasawara | tgardner: cool | 20:52 |
| * bjf goes to read the wiki page on how the new process is supposed to work | 20:52 | |
| === yofel_ is now known as yofel | ||
| apw | herton, i see you pulled in the mvl-dove update for lucid, are you also doing the roll forward to maverick for that one | 21:06 |
| herton | apw: nope, just bjf asked be to take mvl-dove | 21:08 |
| herton | *asked me | 21:08 |
| bjf | apw, we are finishing up what ppisati started | 21:08 |
| apw | herton, ok the mvl-dove lucid branch is replicated into maverick via a script | 21:09 |
| bjf | apw, i expect him to do the maverick | 21:09 |
| apw | bjf, ok will talk to him tommorrow and get that done | 21:09 |
| bjf | apw, thanks | 21:09 |
| bjf | kees, bug 788843 is now ready (i think) | 21:17 |
| ubot2 | Launchpad bug 788843 in linux "linux: 2.6.24-29.90 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/788843 | 21:17 |
| === Quintasan_ is now known as Quintasan | ||
| sforshee | tgardner, could you accept the appropriate nominations on bug #762987 (tyring to nominate maverick/lucid for linux-firmware and hardy for lbm, but all nominations showed up for both packages, let me know if I should have done something differently) | 21:39 |
| ubot2 | Launchpad bug 762987 in linux-firmware "RT2870 WLAN Stick (D-Link DWA 140) not working. firmware does not support detected chipset" [Medium,Fix committed] https://launchpad.net/bugs/762987 | 21:40 |
| bjf | has everyone / anyone seen http://pad.lv ? | 21:42 |
| hggdh | apw, smb: 2.6.24-29.89 EC2 m1.small fails the same with CONFIG_COMPAT_VDSO | 21:43 |
| tgardner | sforshee, done | 21:44 |
| sforshee | tgardner, thanks | 21:45 |
| jwi | sforshee: since you're working on funky firmware issues right now - i think bug 597068 was merged into oneiric recently. not sure whether it really qualifies for any SRU though ... | 22:02 |
| ubot2 | Launchpad bug 597068 in linux-firmware "Missing Myricom 10GigE firmware" [Medium,In progress] https://launchpad.net/bugs/597068 | 22:02 |
| sforshee | jwi, I'll take a look at it | 22:06 |
| sforshee | jwi, I see myri10ge firmware files in oneiric's linux-firmware package | 22:14 |
| jwi | sforshee: right, afair they were merged into upstream linux-firmware just after natty had been freezed | 22:21 |
| sforshee | jwi, sorry, I misread your message. I thought you were saying the bug was still present in oneiric. | 22:23 |
| jwi | sforshee: ah, no. it's really just about maybe getting the commit into natty and maverick (since that's what the bug was filed against originally). not sure if it's worth the hassle (and whether there's any testers around) though | 22:29 |
| kees | bjf: cool, thanks | 22:40 |
| === 31NAAJ7K3 is now known as sunnydrake | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!