=== yf-geek is now known as tyf
=== yf-geek is now known as tyf
[03:33] <myhrlin> Hi, this might be the wrong place to point this out but http://kernel.ubuntu.com/ seems to be down, would that be covered here?
[03:38] <stgraber> it's known
[03:39] <stgraber> (from #canonical-sysadmins' topic: Known issues: kernel.ubuntu.com is down)
[03:42] <myhrlin> ah ok
[03:42] <myhrlin> thanks
[08:54] <apw> j #canonical-sysadmins
[09:10] <njin> hallo guys, we have http://kernel.ubuntu.com/~kernel-ppa/mainline/ broken
[09:17] <njin> balloons, up and running ?
[09:26] <njin> can someone tell me who to ask to repair http://kernel.ubuntu.com/~kernel-ppa/mainline/ , thanks
[09:26]  * ppisati -> reboot
[09:27] <bjf> njin, the server is dead. the issue is being worked
[09:27] <njin> bjf, thanks to clarify
[09:27] <bjf> njin, np
=== cking_ is now known as cking
[11:09] <ppisati> brb
[12:12] <ogra-cb> cking, do you happen to know if your power fixes were forward ported to the raring nexus7 kernel ?
[12:13] <ogra-cb> i at most get 2h out of the battery now 
[12:13] <ogra-cb> and wlan got rather unstable with this kernel
[12:13] <cking> ogra-cb, there were no ARM specific kernel fixes, most of the issues are in userspace really
[12:14] <ogra-cb> hmm, k 
[12:14] <cking> ogra-cb, 2 hours on the nexus 7? what are you doing to it?
[12:14] <ogra-cb> well, userspace really freaks out now, i see assively jumpy times in the battery applet
[12:15] <ogra-cb> cking, leaving it idling :P
[12:15] <cking> ogra-cb, I really would not trust the battery to give you any sane idea of power consumption, it's not very accurate
=== lamont` is now known as lamont
[12:16] <ogra-cb> well, i had over 7h with the old kerne;
[12:16] <cking> ogra-cb, run eventstat to check for stupid wakeup events
[12:16] <ogra-cb> and definitely no jumpy times displayed
[12:16] <ogra-cb> it hops from 1h to 17h etc 
[12:16] <ogra-cb> up and down all the way
[12:16] <cking> ogra-cb, yeah, so I was getting 12 hours on idle, 7 hours on fully loaded CPUs
[12:16] <ogra-cb> and afyet 2h it shuts down
[12:17] <ogra-cb> it also seems to get warmer but that might be a subjective impression
[12:17] <ogra-cb> s/afyet/after/
[12:18] <ogra-cb> and when walking through the house it fails to properly roam wlaan APs and goes into re-connects all the time
[12:18] <cking> ogra-cb, perhaps it's wifi that is sucking all the power. turn it off and see what difference that makes
[12:18] <ogra-cb> (it reconnects fine though, just didnt do so many reconnects with the former kernel)
[12:18] <ogra-cb> ah, good idea
[12:19] <ogra-cb> oh, the power manager battery overview doesnt update properly either btw
[12:20] <cking> ogra-cb, well, that is surprising, I will have to install the latest images and see what's borked
[12:20] <ogra-cb> the raring image is a bit tricky to handle but should install fine
[12:20] <ogra-cb> (massive UI bugs atm)
[12:21] <cking> sigh
[12:21] <cking> oh, well, ssh is fine for me
[12:22] <ogra-cb> well, ctrl-alt-t works to get a terminal and onboard works
[12:22] <ogra-cb> so you can indeed instal openssh-server
[12:22] <cking> ogra-cb, that's my modus operandi
[12:22] <ogra-cb> :)
[12:25] <ogra-cb> xnox, bug 1080437
[12:25] <ubot2> Launchpad bug 1080437 in ubiquity (Ubuntu) "no background during the 13.04 daily install" [Undecided,New] https://launchpad.net/bugs/1080437
[12:31] <cking>   PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                               
[12:31] <cking>  2881 king      20   0 1302m  90m  28m S  31.6  1.6   1:12.71 compiz                                                                                                
[12:31] <cking>  9228 king      20   0  713m  96m  29m R  19.6  1.7   3:55.91 plugin-containe     
[12:31] <cking> ouch, my CPU is on fire just rendering
[12:31] <xnox> ogra-cb: bug 1078226
[12:31] <ubot2> Launchpad bug 1078226 in nautilus (Ubuntu) "raring daily: background & lightdm look as if they are in 8bit greyscale mode" [Low,Incomplete] https://launchpad.net/bugs/1078226
[12:32] <xnox> ogra-cb: this is in KVM, not sure about the other bug reporter.
[12:32] <xnox> will test nexus7 and try to see what's going on.
[12:33] <ogra-cb> nexus7 shows a clearly distroted wallpaper during install
[12:33] <ogra-cb> but i assume the framebugger is just not clean at that point, else it would show black
[12:34] <ogra-cb> heh, funny typo ... framebuffer indeed
[12:42] <ogra-cb> err, oops, i though i was in -installer with the last bits, sorry for the noise
[13:02] <asac> http://kernel.ubuntu.com/~kernel-ppa/mainline/ doesnt exist anymore?
[13:02] <asac> or just temporary outage?
[13:09] <fmoreau> hello, I'm trying to retrieve the source code of the kernel for N7 device, but it's failing:
[13:09] <fmoreau> $ LC_ALL=C git clone git://kernel.ubuntu.com/hwe/ubuntu-nexus7.git
[13:09] <fmoreau> kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection refused
[13:09] <fmoreau> could anybody help me please ?
[13:10] <rtg> fmoreau, that server is temporarily down
[13:11] <fmoreau> rtg: ah... thanks. Is there any alternative ?
=== lan3y is now known as Laney
[13:11] <rtg> fmoreau, checking, perhaps github but I'm not sure.
[13:13] <Kano> hi, whats up with your server?
[13:14]  * ogra-cb grins
[13:14] <ogra-cb> Kano, you are the third to ask within 20 min
[13:15] <rtg> apw, are you cloning the N7 kernel on people.c.c ? I don't have it in the github pile.
[13:15] <rtg> Kano, server is down.
[13:15] <Kano> ogra-cb: well then put it into the topic
[13:15]  * ogra-cb has no such powers
[13:16] <apw> rtg checking
[13:19] <apw> rtg, nope, whats your tip commit, so i can see if i at least have the original
[13:20] <rtg> apw, 7377da8f921463728ee8196186dc5b5a997a9fda UBUNTU: Ubuntu-3.1.10-8.14
[13:21] <apw> commit 7377da8f921463728ee8196186dc5b5a997a9fda
[13:21] <apw> nice ... ok so at least i have a valid copy
[13:21] <Kano> 3.1.10?
[13:22] <rtg> apw, looks like I was the last uploader, so that should be right
[13:22] <rtg> Kano, nexus 7 kernel
[13:23] <apw> rtg and it matches the appropriate version
[13:59] <fmoreau> rtg: did you find any alternatives on github (sorry if I missed a previous post but I've been disconnected) ?
[14:03] <rtg> fmoreau, not for the N7 kernel
[14:04] <Kano> N10 later?
[14:05] <rtg> Kano, dunno
=== arges_ is now known as arges
=== davmor2_ is now known as davmor2
[14:27] <apw> fmoreau, ok i think i have managed to push that nexus7 branch to our archive github repo
[14:27] <apw> fmoreau, https://github.com/Canonical-kernel/Ubuntu-kernel/commits/ubuntu-nexus7-master
[14:28]  * henrix -> (late) lunch
[14:29] <fmoreau> apw: thanks !
[15:37] <arges> sforshee, hey. have you had any issues installing 32-bit quantal on macbook airs? i'm looking at bug 1082059 which involves eficross
[15:37] <ubot2> Launchpad bug 1082059 in linux (Ubuntu) "default quantal kernel does not boot my macbook air" [Undecided,Confirmed] https://launchpad.net/bugs/1082059
[15:38] <sforshee> arges, I saw that one. I haven't tried 32-bit in a while, but I'm pretty sure what he's trying to do isn't a supported configuration at this time.
[15:39] <arges> sforshee, ok how would I find out if it is supported or not? is this unsupported in the firmware?
[15:41] <sforshee> arges, what I suspect is unsupported is native EFI boot to a 32-bit kernel. I can't swear to it though. Maybe cjwatson would know?
[15:45] <cking> 32 bit with EFI is not going to fly is it?
[15:47] <rtg> ogasawara, smb, sconklin, apw, bjf, herton, henrix: I would wait until we know zinc is officially back before attempting any git pushes.
[15:47] <ogasawara> rtg: ack
[15:47] <sconklin> ok
[15:47] <apw> rtg, ack
[15:47] <henrix> rtg: ack
[15:49] <bjf> rtg, ack
[15:50] <herton> rtg, ack
[15:50] <sforshee> cking, if you look at the bug there's a patch referenced that's trying to fix problems with that use case, so someone seems to be trying to make it work
[15:51] <rtg> ogasawara, smb, sconklin, apw, bjf, herton, henrix: #is says zinc is officially back, though I'm concerned about the cause.
[15:54] <arges> sforshee, yea working on a cherry-pick building now
[15:54] <arges> not too many conflicts
[15:57] <fmoreau> apw: trying to clone the repository you pointed out: fatal: https://github.com/Canonical-kernel/Ubuntu-kernel/commits/ubuntu-nexus7-master/info/refs not found: did you run git update-server-info on the server?
[15:59] <apw> fmoreau, i don't think that is a cloneable url, it points to something you get get those from
[15:59] <apw> fmoreau, i would also not recommend cloning that as it is massive, make an empty repo, add it as a remote, and fetch just that one branch
[16:00] <fmoreau> apw: stupid me :)
[16:00] <fmoreau> sorry for the noise
[16:00] <fmoreau> apw: will use --reference 
[16:00] <apw> it will still be humungous i am sure
[16:00] <rtg> about 4.5GB
[16:05] <apw> thught it would be indded.  just take the one branch, must smaller
[16:06] <SpamapS> smb`: Nov 24 22:32:43 clint-MacBookAir kernel: [131886.042747] unregister_netdevice: waiting for lo to become free. Usage count = 15
[16:06] <SpamapS> cking: ^^
[16:06] <SpamapS> 3.5.0-18.29
[16:06] <SpamapS> it almost seems *worse* now with 3.5.0-18.29
[16:07] <cking> bah, that's not good news
[16:07] <apw> did we commit a fix for that issue, i didn't realise
[16:07] <cking> it's SRU's
[16:07] <cking> SRU'd even
[16:07] <apw> amazing :)
[16:07] <SpamapS> note, usage count = 15
[16:07] <SpamapS> previously, it was = 1 or = 2
[16:13] <cking> SpamapS, that fix is in master-next but not released yet
[16:15] <apw> rtg, when we made linux-lts-quantal it stopped Provides: linux-image ... is there any good reason for this that you recall
[16:15] <rtg> apw, no
[16:16] <apw> rtg, seems we need it to allow that kernel to be the only kernel one has for the CDs... so i'll fix that then
[16:16] <cking> SpamapS, I believe the ref count badness is due to how fragmented data gets, so it may vary on the unfixed kernel
[16:16] <rtg> apw, except that it _doesn't_ provide linux-image
[16:17] <apw> rtg its linux-images-*'s are linux-image's as much as any other?  arn't they ?
[16:17] <rtg> apw, don't they have lts-quantal in the name ? I can't remember
[16:17] <apw> rtg, not the final binaries i don't think no
[16:18] <rtg> apw, go ahead and fix it then
[16:18] <apw> and whatever they are called, they are 'linux-image' compatible right?  whcih is the point of the provides
[16:18] <apw> linux-image-3.5.0-19-generic | 3.5.0-19.30 | quantal-proposed | amd64, i386
[16:18] <apw> linux-lts-quantal | 3.5.0-18.29~precise1 | precise-updates | source
[16:18] <apw> so either way they are linux-image-*
[16:19] <rtg> apw, seems right
[16:19] <apw> something off with rmadison output there
[16:19] <apw> linux-image-3.5.0-18-generic | 3.5.0-18.29~precise1 | precise-updates | amd64, i386
[16:19] <apw> linux-image-3.5.0-19-generic | 3.5.0-19.30~precise1 | precise-proposed | amd64, i386
[16:19] <apw> linux-lts-quantal | 3.5.0-18.29~precise1 | precise-updates | source
[16:19] <apw> linux-lts-quantal | 3.5.0-19.30~precise1 | precise-proposed | source
[16:19] <apw> better ...
[16:19] <apw> ok goood ... will do
[16:24] <apw> rtg, zinc is still on hold our side rigght ?
[16:25] <apw> i am asking pinky to check the remote power works while they are there
[16:25] <apw> modulo everyone still not using it
[16:27] <rtg> apw, he told me it is officially online, so I assume he's not gonna try power cycling again
[16:27] <SpamapS> cking: ok, I'll try quantal-proposed
[16:27] <apw> rtg, just talking to him now, they think it is configued right, but they haven't tested the remote proceedure
[16:27] <apw> rtg, i think it would be worth doing while they are there in case it is not correct
[16:27] <rtg> apw, seems like they ought to figure that out while he is there
[16:27] <fmoreau> apw: I finally ended up to download a zip containing the head of the nexus branch, it's only 120Mo.
[16:28] <cking> SpamapS, the fix will land after Ubuntu-3.5.0-19.30, so you need to wait a while for the fix 
[16:29] <apw> rtg, ok they are going to test and confirm now
[16:30] <SpamapS> cking: :(
[16:30] <SpamapS> cking: thanks for the info
[16:30] <cking> SpamapS, but if you are stuck, continue to use that debug version I built for you until the fix is released
[16:31] <SpamapS> cking: not stuck, just :( for the users.
[16:32] <rtg> apw, ack
[16:33] <cking> SpamapS,  /me nods, well, the process takes a while for a release because we need to test to ensure all the fixes don't cause regressions
[16:34] <SpamapS> cking: +1000 for that
[16:34] <SpamapS> just :( .. its not a >: at you, or the process. Just a :(
[16:56] <fmoreau> sigh... unzipping the archive: "symlink error: File name too long"
[17:04]  * ppisati_ -> gym
=== smoser` is now known as smoser
[17:20] <rtg> apw, ogasawara: pushed 3.7-rc7 rebase. still doing build and boot tests
[17:20] <ogasawara> rtg: ack
[17:28] <myhrlin> hello, would the kernel packages at http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc1-quantal/ be decent to use for a production server?
[17:28] <apw> myhrlin, test kernels for production, and from an -rc1 at that, no
[17:28] <rtg> myhrlin, emphatically no
[17:28] <myhrlin> oh, sad day
[17:28] <myhrlin> ok
[17:29] <myhrlin> wait, so ubuntu-modified kernel 3.6.7 isn't... oh wait I linked the wrong one
[17:29] <myhrlin> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6.7-raring/
[17:29] <apw> all of the kernels in the mainline archive are there for testing and are unsupported
[17:29] <myhrlin> I was assuming since kernel.org has 3.6.7 as stable that the ubuntu-modified one would also be stable
[17:29] <Kano> what option would disable the .tar.gz build?
[17:33] <jwi> myhrlin: "ubuntu-modified"?
[17:34] <myhrlin> well, isn't it modified when `make menuconfig` has an option for ubuntu specific options?
[17:35] <myhrlin> I thought that was the case, but I'm basing that off a config from... a few version ago, I don't remember the specific version I used at that time
[17:38] <myhrlin> oh, my fault.  Just now checked it for 3.2.31, it's just a menu for " Ubuntu Supplied Third-Party Device Drivers"
[17:39] <myhrlin> I honestly thought ubuntu had a heaviliy modified kernel
[17:42] <jwi> myhrlin: the /mainline kernels are built from {linus',stable} trees - vanilla, no ubuntu toppings.
[18:52] <arges> smb`, hello
[18:53] <arges> just a general xen question... if I boot with a xen dom0 ubuntu kernel, would I expect certain CPU features to be disabled?
[18:57] <rtg> ogasawara, apw, bjf: test kernels at http://kernel.ubuntu.com/~rtg/3.7-rc7.1
[18:57] <bjf> rtg, ack
[18:57] <ogasawara> rtg: ack, I'll throw it on my kit here
[18:58] <apw> rtg ack
[19:03]  * rtg -> lunch
=== yofel_ is now known as yofel
=== Edgan_ is now known as Edgan
[19:18]  * henrix -> EOD
[19:40] <infinity> hggdh: I hear you should be unstuck for armadaxp regression testing?
[19:40] <infinity> arges: That depends on the release, probably.
=== magn3ts_ is now known as magn3ts
[19:46] <arges> infinity, yea trying to verify 979003 and I notice that booting with xen raring kernel avx isn't present (so can't reproduce the bug)
[19:47] <arges> xen raring dom0 that is
[19:49] <infinity> On hardware with AVX?
[19:49] <infinity> That's a mistake, if so...
[19:49] <infinity> smb`: You around?
[19:49] <arges> infinity, i think he has the day off
[19:49] <infinity> Check.  We should bug him later.
[19:49] <arges> infinity, i'll ping him tomorrow
[19:49] <infinity> It may be that he hard disabled AVX to work around the glibc issues, but we should be backing that out (from all releases) if we're fixing glibc.
[19:50] <arges> agreed
=== vmesons is now known as vmeson
[20:08] <rudimeyer> I'm experiencing a problem with the handling of virtual block devices (Xen) in kernels version 3.0 (Ubuntu 11.10) and 3.2 (Ubuntu 12.04 LTS) - but in Ubuntu 10.04 LTS with kernel 2.6.32 the error is not present…   How do I go by reporting this the best?
[20:09] <rudimeyer> Kernel 3.0 and 3.2 does not handle the detachment of a virtual block device that well (hang/freeze)
=== lifeless_ is now known as lifeless
[20:43] <jtb1> hi! is there a way to get the linux-tools for the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
[20:43] <myhrlin> kernel 3.6.8 is out :D
[20:43] <myhrlin> jtb1: linux-tools?
[20:44] <jtb1> myhrlin: perf, turbostat, x86_energy_perf_policy etc
[20:44] <myhrlin> ah ok
[20:44] <myhrlin> I'll leave that for someone else, I have no idea
[20:45] <jtb1> k, thx anyway ;)
[21:56]  * rtg -> EOD
[22:43] <arges> jsalisbury, hey.
[22:44] <arges> jsalisbury, if a linux bugtask is fixed in raring by a patch in upstream, should I mark the raring bugtask as 'Fix Released' or something else?
[22:48] <bjf> arges, is that fix in our currently "released" kernel ?
[22:49] <bjf> arges, or another way to ask ... which rc is it fixed in?
[23:12] <arges> bjf, yes assuming it is. that patch is in a released kernel
[23:12] <arges> bjf, but we didn't actively apply the fix, it was just already in upstream
[23:12] <bjf> arges, then yes, you can mark it "fix released"
[23:13] <bjf> arges, that status isn't meant just for bugs we fix
[23:13] <bjf> arges, it indicates, "this bug has been fixed and is available via a released kernel"
[23:13] <arges> bjf, that's what I figured, just wanted to make sure
[23:13] <bjf> ack
[23:13] <arges> thanks
[23:14] <bjf> np
=== JamesJRH_ is now known as JamesJRH