=== broder_ is now known as broder [07:07] ~280 pkgs to upgrade [07:07] but X is still stuck [07:08] Unless it gets replaced by xXx [07:09] :) [07:43] lol [07:43] my indicator changed position [07:44] i've (from left right) volume, settings, calendar, skype, hph systray, multiload, printer, messaging and network [07:55] and after another reboot [07:55] my indicator are back to their position === fmasi_afk is now known as fmasi [08:21] * apw yawns === fmasi is now known as fmasi_afk [08:26] 544 pkgs to be upgraded on my laptop [08:26] oh yeah... [08:26] and i just noticed that my weather indicator on my saucy laptop it's actually the 'old' weather indicator [08:26] that was not removed during my transition from Q to S === fmasi_afk is now known as fmasi [08:47] ppisati, yeah the weather inditcator is currnetly only in a PPA i think === fmasi is now known as fmasi_afk [08:49] the only one I seem to find is for China... [08:54] * ppisati wonders what's thw weather in China ATM... === fmasi_afk is now known as fmasi [10:09] * smb is glad that software-center is such a well tested package... [10:10] * apw finds it to be as well tested ... sigh ... bug filed [10:11] smb, the reboot button works at least [10:12] apw, Mostly not using that one as "sudo reboot" performs sooo much quicker on this doomsbro device [10:12] smb, that good huh (the h/w) [10:13] smb, when i say reboot works, i should mention that booting up doesn't work now [10:13] oh dear [10:13] oh that might be tims kernel [10:13] apw, Yeah, just accidentally bought it... unfortunately its not openly sold as poulsbro but just another gmaxxxx number [10:14] oh when did you get this one [10:14] When I thought I might fill in some mini-itx case with something I could use as a media-box... [10:15] oh no [10:15] you should have sent it back [10:15] and saved yourself some pain, or frankly open the bin and shove it in [10:15] unless it becomes a firewall or router with no screen [10:17] That might be its destination. Meanwhile I use it to remind me every day on how great of an idea it is to only support 3D and use llvm-pipe to make the cpu do the rendering... on an Atom... Beside there was no "I am stupid" tick-box on the return form. :-P [10:18] heh [10:19] smb: sadface, I have the same thing sort of problem with a media box I wanted to use. [10:19] smb: about to give my rpi a spin, if I can find it,w ith openelec [10:21] lifeless, Yeah, there is the unfortunate small gap between success and fail when buying Intel mini-itx boards with atom. Got one success and now this fail. But well, as said it may end up becoming some sort of server when I get too fed up [10:21] smb: I bough t mine 5 years or so ago as a few [10:21] s/few/f\/w/ [10:22] smb: it has video acceleration - it was sold as a media box for pubs - no moving parts to get dust in them [10:22] smb: but XMBC wants opengl. WTF. [10:24] lifeless, Yeah, it is sold as that and if Intel would be more serious it could have video acceleration. But one has to be glad there is modeset support at all now. [10:25] indeed [10:27] smb, so you can have plymouth during boot, wooo [10:29] apw, Yeah for that short period of time in between the gma500_gfx driver spewing out it not feeling happy. :) [10:29] (incorrect EDIDs and disabled pipes and such) [10:31] zequence: Do I get new metas to go with those kernels? [10:33] smb, always the way [10:58] hello [10:58] do we have a perf build available for the touch images? [10:59] tvoss_: There should be a linux-tools-$(uname -r) for all the touch kernels now, I believe. [10:59] tvoss_: Pretty sure rtg fixed all that up. [11:00] At least, I vaguely recall NEWing a lot of linux-tools packages in the last few months. :P [11:01] infinity, cool :) so greyback just joined, he had problems installing perf [11:01] infinity: hi! [11:01] infinity, mind giving him a hand? [11:01] I didn't know your question was a trap. :P [11:01] greyback: What's up? [11:01] Define "problems". [11:02] infinity, ;) [11:02] * tvoss_ notes beer_counter[infinity]++ [11:02] infinity: sorry! :) I want to run "perf" on a phablet image. So I install linux-tools, which I think pulled in linux-tools-3.10.0-2 [11:02] tvoss_: I think we're on to fine wine at this point. [11:02] greyback: Yeah, don't do that. [11:02] infinity, fair point :) red or white? [11:02] infinity: but kernel of phablet image is 3.0.0-3.. so it won't match [11:03] greyback: You want linux-tools-$(uname -r), the "linux-tools" metapackage is just for -generic. [11:03] infinity: sure, but there's no linux-tools package matching the kernel on phablet image that I know of [11:04] Hrm. I *thought* rtg fixed all that. [11:04] * infinity looks. [11:04] infinity: maybe a PPA with it exists somewhere? [11:04] Hah. No, he just named them wrong. [11:05] greyback: Which kernel is that? [11:05] Maguro, I'm assuming, from your version. [11:05] greyback: linux-maguro-tools-3.0.0-3 [11:05] greyback: And we'll yell at rtg for the broken naming scheme. [11:05] apw: Or you can fix ^^ [11:06] infinity: yep that's it [11:06] apw: That should so be linux-tools-3.0.0-3-maguro [11:06] greyback: linux-maguro-tools is the metapackage that matches, also wrongly-named. [11:06] apw: And the meta should be linux-tools-maguro, not linux-maguro-tools [11:07] it cirtainly should mate the linux-image one, and that is linux-image-generic ... so linux-tools-maguro sounds right [11:07] infinity: magic, trying.. [11:07] i'll have a peek at them [11:07] apw: I suspect rtg got confused by the common packages using $stem-$src-$thing, while the flavour-specific ones should be $stem-$thing-$flavour [11:07] do we have a linux-tools-generic, we really shoudl [11:07] a full review would not go amis [11:08] * apw adds it to his todo, but he is not going to be derailed from uploading this lowlatency [11:09] apw: See linux-headers-3.0.0-3-maguro versus linux-maguro-headers-3.0.0-3 (correct), tools should match the scheme. So linux-maguro-tools-common and linux-tools-3.0.0-3-maguro [11:09] (it has happened toooo many times) [11:09] Or, at lease, some approximation thereof. :) [11:09] s/lease/least/ [11:09] makes sense... within the not making a lot of sense framekwork we live in [11:11] apw: I'm not sure who to blame for the source/flavour confusion, but I imagine it's either you or rtg originally. [11:11] apw: Since this comes from either lowlatency or ppc, or a combination of the two. [11:11] well the names with the prefix being linux-- regardless of source package, that comes from d-i's needs [11:12] apw: But the sane rule of thumb would seem to be, if it's a source-common package, refer to the source, if it's flavour-specific, use the proper ABI-FLAVOUR, and done. [11:12] linux-image-*-generic linux-headers-*-generic etc is all 'd-i' [11:12] right and that should be the plan [11:12] i'll go through them later and see [11:12] * infinity nods. [11:13] I think I still need to push a patch to Ben to fix tools in PPC too. [11:13] Not only has it been turned off all this time, but it still claims to build an arch:all common package, which confuses LP a tiny bit. [11:17] infinity, perhaps i can look at that once i have fixed up maguro et al, as they should be a good approved form by the time we get there [11:22] infinity: linux-maguro-tools working perfectly, thank you for the help [11:22] greyback: NP. [12:00] infinity, red or white? :) [12:01] tvoss_: A nice shiraz would make me happy right about now. Perhaps a Penfolds Grange. [12:01] infinity, noted down :) [12:01] tvoss_: (Or a St Henri or Bin 28, if you're feeling cheap) [12:07] infinity, do we have kernel symbols available for the touch images? [12:08] Should do. [12:08] tvoss_: For the kernel greyback was using, http://ddebs.ubuntu.com/pool/universe/l/linux-maguro/ === jdstrand_ is now known as jdstrand [12:17] rtg, fyi i booted up unstable and it works ok on i386, amd64 here is blamoming on one box at least [12:17] rtg, also aufs looks to be working on i386 at least [12:18] really? I booted amd64 yesterday just fine. any idea where its croaking ? [12:18] apw, and what is 'blamoming' ? [12:18] exactly ? [12:19] rtg, blammo'ing implies exploding, though in this case it is seemingly hanging pretty early [12:19] google ain't finding it [12:19] apw, so, its like an aborted bloom ? [12:19] i am about to test a second amd64 machine to see if that is ok, one which is simpler than the original [12:20] no i think i have typo'd an m into it. blammo [12:20] ah, now that parses [12:23] rtg, ok amd64 boots ok on this non-efi machine, so its likely machine or efi specific ... fun [12:23] apw, great, I just f*%king love EFI problems [12:23] yeah so very easy to diagnose [12:24] apw, bbiab [12:35] rtg, replied confirming applied [12:36] * apw pops out [12:36] apw, thatnkyou sir [12:51] cking, have you ever messed with CONFIG_DYNAMIC_DEBUG ? [12:52] rtg, you're testing my memory on that one [12:52] cking, I think its a newer feature. you might find it of interest [12:52] that's the pr-debug() stuff isn't it?, so yes, reckon so [12:53] it's been around sincd 2.6.30 hasn't it? [12:54] cking, really ? I wonder why we haven't had it enabled. [12:54] http://cateee.net/lkddb/web-lkddb/DYNAMIC_DEBUG.html [12:54] 2% overhead? [12:55] cking, only for the subsystems that use it. I wonder if anyone will notice ? [12:55] rtg, i meant 2% overhead in size, the execution overhead may be peanuts [12:56] cking, size is no object :) [12:56] we all have giant PCs [12:56] rtg, is it for phablets ;-) [12:56] cking, well, I've only enabled it for the distro kernel [12:57] rtg, ok, then that's good then [13:15] * cking reboots [14:02] apw, so, you think the saucy daily ought to work for UEFI ? [14:05] infinity: Yeah, let me get those. Got to be kind of late yesterday [14:06] rtg, saucy daily i would expect it to, whether it has been tested i dunno ... i can test it pretty easy [14:06] apw, thats what I'm up to right now on a tiano core box [14:07] oh heh, then roughtly the same box as here [14:07] ls -l [14:32] ppisati, linux-generic-lts-raring [14:41] jdstrand: thanks for the attempt for bug #1197484. the issue did not go away though, but /sbin/dhclient-script permission denied message has disappeared [14:41] Launchpad bug 1197484 in isc-dhcp (Ubuntu) "Connection requests to saucy server VMs from a hosts fail after fresh VM installs" [High,Fix released] https://launchpad.net/bugs/1197484 [14:41] yeah, I saw your new bug [14:41] sorry it didn't work out [14:42] thanks for the attempt :) though, i understand reproducing is very tedious in that [14:50] apw, cking: how _does_ one get a tunnel mountain tiano core machine to boot from DVD when fastboot mode is enabled. [14:53] rtg, i believe if fastboot is enabled you have to boot windows and turn it off don't you ? [14:53] apw, we didn't ever develop a UI that runs from Linux ? [14:53] no wonder I hate this machine [14:54] rtg, i don't think so, cause to boot linux you need to have already turned it ogff i think [14:55] something dumb like that [14:55] shit, I don't have windoze. [14:55] hmmm how did that happen [14:55] there may be a button you hold but no idea what it would be [14:55] cking might if he was here [14:55] manjo happened.... [14:56] and he might know too ... that manjo [14:56] maybe _you_ shuold test the UEFI daily, and I'll go work on enabling armhf in LTS Raring. [14:57] apw, ^^ [14:58] rtg, ok, i did start it syncing some time back [14:58] apw, I could upgrade mine, but if it doesn't work then I'm hosed [14:58] rtg np will do mine [15:05] fastboot disables keyboard so there might be a way to get to bios [15:07] so last UDS we talked about setting env var that says boot to bios on next boot using a menu option at reboot [15:07] [15:07] I brought this up several times at UDS [15:08] manjo, its kind of a foundation issue [15:08] right [15:20] psivaa: do you have a way to test a package that is not in the archive? [15:21] jdstrand: i am doubtful since this appear to happen on the first boot when the installation finishes [15:22] psivaa: are you able to stop the tests before the reboot? [15:22] psivaa: or, do you see it after subsequent reboots? [15:22] jdstrand: i dont see that on the subsequent reboots [15:23] jdstrand: i could stop the tests after the reboots but the reboot will have happened then and if that's ok then i could try [15:24] psivaa: what we want to do is modify the apparmor policy before it is applied in the next reboot [15:24] jdstrand: can that be done using preseed? [15:24] and by next, I of course mean, 'first' [15:24] rtg: is linux-generic-lts-raring part of backports? [15:25] psivaa: we can't modify policy in preseed no [15:25] ppisati, no, should be precise main [15:25] rtg: uhm [15:25] ubuntu@c16:~$ apt-cache search linux-generic-lts-raring [15:25] ubuntu@c16:~$ [15:26] psivaa: if you can stop the machine before networking comes up, modify the policy, then resume boot, that would work [15:26] ppisati, rtg@gomeisa:~$ rmadison linux-generic-lts-raring [15:26] linux-generic-lts-raring | 3.8.0.23.22 | precise-security | amd64, i386 [15:26] linux-generic-lts-raring | 3.8.0.26.25 | precise-updates | amd64, i386 [15:26] linux-generic-lts-raring | 3.8.0.27.26 | precise-proposed | amd64, i386 [15:26] psivaa: another alternative is disabling appamor. are you able to adjust the kernel command line? [15:27] rtg: ah wait [15:27] rtg: amd64, i386 [15:27] ppisati, right now it is. I am working on producing an armhf version, so you can't test for awhile [15:27] rtg: ok [15:27] jdstrand:ok, i dont think so, i'm asking the utah dev team to see if that's possible. but i think i can pause the vm before modifying the apparmor policy [15:27] I forgot the LTS was only x86 [15:34] jdstrand: so it appears that we could modify the kernel command line args using preseeds. [15:37] psivaa: if you add this to the kernel command line: "apparmor=0" it should disable apparmor [15:37] psivaa: you'll know it worked by running 'sudo aa-status' after rebooting [15:38] jdstrand: ok, thanks, ill try and report back how it goes [15:41] ogasawara, can you verify bug 1196658 ? [15:41] Launchpad bug 1196658 in linux (Ubuntu Raring) "Add support for Intel Avoton SoC" [Medium,In progress] https://launchpad.net/bugs/1196658 [15:41] smb, can you verify bug 1191726 ? [15:41] Launchpad bug 1191726 in linux (Ubuntu Raring) "dm-snapshot should be in the installer environment" [Undecided,New] https://launchpad.net/bugs/1191726 [15:42] bjf, probably as for previous kernels only up to that it is in the udeb [15:49] bjf, To that degree -> done [15:49] smb, thanks [16:09] zequence: Thanks. [16:09] zequence: I'll double-check the lot and get things in proposed later tonight, if I don't get lost in a pub, tomorrow morning if I do. ;) [16:14] infinity: Thanks. Hot days like these can really turn you into an alcoholic [16:15] zequence: Yeah, it's pretty unpleasant out there. === chuck_ is now known as zul [17:07] jsalisbury, how long should it take for a raring kernel to go from -proposed into -updates? [17:07] ref: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1180419 [17:07] Ubuntu bug 1180419 in linux (Ubuntu Saucy) "Ringtail on Hyper-V causes BUG: scheduling while atomic" [High,Fix released] [17:08] med_, I believe it's about 3 weeks. bjf may know for sure. [17:08] bjf ^ [17:08] oh, okay [17:08] * med_ thought it was 7 days... [17:09] med_, approx. 3 weeks from start to finish. the ones in -proposed right now should hit -updates by friday of next week [17:09] bjf, danke. [17:09] jsalisbury, thanks === fmasi is now known as fmasi_afk [17:10] med_, np [17:21] * rtg -> lunch [17:23] jsalisbury: hey should bug 1180419 be marked Fix Committed instead of Released ? [17:23] Launchpad bug 1180419 in linux (Ubuntu Saucy) "Ringtail on Hyper-V causes BUG: scheduling while atomic" [High,Fix released] https://launchpad.net/bugs/1180419 [17:23] not sure why somebody marked it released [17:26] tx arges. [17:32] arges, yes, someone whas just being "helpful" [17:33] : ) [18:22] bjf, please have a look at the Raring LTS pull request. We should get that in the pipeline pretty soon. I also need to add armhf support to the meta package [18:22] rtg, will do right away. is it worth respinning what we have in the pipeline? [18:23] bjf, thats what the pull request does, e.g., I repackaged with a new version [18:24] bjf, though I noticed the changelog could use a tweak to include the LP bug number [18:25] and tracking number too I suppose [18:33] rtg, ack'd [18:33] bjf, you want it uploaded to the non-virt kernel PPA ? [18:34] yup [18:34] bjf, ok, I'll fix tha changelog first [18:34] rtg, new tracking bug please, and we'll dupe the old one to this one [18:35] yup [18:55] hi, will the package always use 3.10.0 name or change the .0 to something higher? [18:57] Kano, its gonna change to 3.11.0 sometime around -rc3 [18:57] but i mean when you rebase to 3.10.1 why do you keep the 0? [18:58] the '0' in the package name is pretty much constant for packaging reasons [18:58] also you still dont use .orig [18:58] not yet [18:58] we will when 3.11 is released [18:59] at least the firmware is updated now [19:00] for now... [19:00] i had to do my own package update with uvd, but for 3.11 you need other files, are those in there already? [19:01] Kano, I think linux-firmware is rebased against tip of the upstream repo (as of a few days ago) [19:09] did the one who asked to make ahci as module ever provide a link to an updated driver? [19:09] i would revert it until he shows his code [19:10] now i always have to patch the kernel back [19:10] because some users boot without initrd on uefi systems for max bootspeed [19:13] btw. i would prefer nvidia/fglrx patches which are NOT activated via dkms, because you can adopt them more easy on debian packages when the kernel version checks are in the patch code and not in dkms.conf [19:14] what is the option to disable _amd64.tar.gz? [19:43] does 3.10.0-3.12 really compile?? [19:49] i really think there is a race condition [20:21] jsalisbury, any progress on bug 1173423 ? [20:21] Launchpad bug 1173423 in linux (Ubuntu) "Kernel fails to update EFI vars, rendering system unbootable [P8P67 PRO REV 3.1, BIOS 1904 08/15/2011]" [Critical,In progress] https://launchpad.net/bugs/1173423 [20:24] bjf, I never did hear back from upstream. Let me ping em again. [20:24] mjg59, any thoughts on this bug? ^ [20:25] bjf, even easier :-) [20:25] jsalisbury, i've no clue what timezone he is in [20:29] bjf, I'll send email again, but also use [RESEND] in the subject. [20:39] bjf: Yeah, fixed by f8b8404337de4e2466e2e1139ea68b1f8295974f [20:40] mjg59, thanks [20:41] mjg59, bjf, thanks. I'll build a test kernel for the bug. [20:41] jsalisbury, i think that is in the next 3.8 stable update [20:41] jsalisbury, this is the efi patch we were discussing two weeks ago [20:42] bjf, great [20:42] jsalisbury, we got possitive testing from cking so i think kamal has it all queued up [20:42] bjf, is it already in proposed? [20:42] jsalisbury, no, next proposed [20:43] bjf, cool. I'll request testing of proposed instead of building a kernel [20:43] jsalisbury, it will probably land in the master-next branch shortly [20:44] bjf, ok thanks. [20:44] mjg59, I resent an earlier email. I'll respond that you replied. thanks again. [20:48] bjf, jsalisbury, mjg59: I did apply that that UEFI fix f8b8404 to ubuntu-raring, but somehow missed it for 3.8.y-stable ... I'll sort that out. [20:49] bjf, updated bug [20:49] kamal: Thanks! [20:49] kamal, thanks [20:59] bjf, jsalisbury, mjg59: minor correction ... I didn't actually apply that fix to ubuntu-raring either :-(. I just *planned* to do so. I'll do so. [21:25] bjf: Argh. Tim's lts-raring wasn't built against an orig. [21:26] bjf: I wish we had a better way to notice that regression other than me whining. [21:27] infinity, agreed [21:28] bjf: Not that it's world ending for one upload to miss the orig, but it makes the diffs a lot harder to audit. [22:38] bjf, thanks for correcting status of 1180419. I was really confused (and had assumed Lemberger was part of the kernel team) [22:38] "Nicholas Lemberger is not an active member of any Launchpad teams." [23:01] bjf, jsalisbury, mjg59: ok, the UEFI fix f8b8404 now really is queued up for 3.8.13.5 stable, which I will release on Monday. we've decided that ubuntu-raring will just pick it up from there.