=== smb` is now known as smb
[11:54] <janimo> apw, are there any scripts or docs to help me get started with a config syncup for the nexus7? I am hoping there is a cleverer way than going through the file line by line
[11:59] <apw> janimo, what are you going to sync it to, its a completely different version
[11:59] <janimo> apw, I was hoping to get an answer to that to :)
[11:59] <apw> janimo, but in answer, there are scripts to compare configs indeed and highlight relevant changes; if you have something to compare to
[11:59] <janimo> would a 3.1 based previous Ubuntu mainline kernel be much different from Raring's?
[12:00] <apw> janimo, we use them for our cycle configuration reviews
[12:00] <apw> janimo, yeah, tons different
[12:00] <apw> they change configuration options all the time
[12:00] <apw> i guess you should compare to 3.2 as that is at least close, but that is before we did a lot of the harmonisation work
[12:00] <janimo> so mostly name changes but in spirit our configs are similar across relelases?
[12:01] <janimo> I feel this harmonisation will be painful
[12:01] <apw> in spirit yes, in implementation less so, it has taken us 4-5 cycles to get our configs in good order
[12:02] <apw> janimo, though i think if i was doing it i would only be caring about the common options
[12:02] <janimo> something I hope can be leveraged fir the nexus7 task as I don't think we want to spend quite so much time on it
[12:02] <janimo> apw, common as in those kept in ubuntu.config.common?
[12:02] <apw> janimo, no, as in those pulled out as particularly interesting in the config review: http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/UDS.html
[12:03] <janimo> I was thinking if we had some higer level description like : LXC support, Overlay support, All Webcams Ever, etc. Which would then be used as a source to generate actual config options for various kernels
[12:03] <janimo> does that sound implausible?
[12:03] <apw> we do not have that
[12:03] <apw> we have some slightly lower level rules
[12:04] <ogra-cb_> hmm, did we update the nexus kernel to something newer ?
[12:04] <janimo> would that be something worth having or it was considered and abandoned?
[12:04] <janimo> ogra-cb_, 4.2 android branch
[12:04] <ogra-cb_> there seem to be tons of issues with the latest kernel
[12:04] <janimo> rtg did it
[12:04] <ogra-cb_> under android that is 
[12:04] <apw> we are working towards that, but we do not have it yet
[12:05] <apw> we have components of it, but its not in any useful form you can apply to a system
[12:05] <ogra-cb_> (draining your battery fast, several kernel oppses etc)
[12:05] <apw> ogra-cb_, sounds awsome
[12:05] <janimo> ogra-cb_, you mean Android 4.2 on the nexus has issues because of the new kernel?
[12:05] <ogra-cb_> well, it has issues
[12:05] <ogra-cb_> and if there are ioopses i would blame the kernel, yeah
[12:06] <ogra-cb_> -i
[12:06] <janimo> there were very few changes in the kernel - not that they could not be invasive
[12:06] <ogra-cb_> well, i guess we'll see
[12:06] <apw> ogra-cb_, is that with the android build, or with ours
[12:06] <ogra-cb_> but a battery life cut in half sounds a bit scary
[12:06] <janimo> ogra-cb_, well userland or firmware can cause oopses no?
[12:07] <apw> janimo, anyhow if you get me a config i can get a basic report done for it
[12:07] <janimo> if it manifests on the ubuntu images we should worry I agree
[12:07] <ogra-cb_> apw, android kernel under android 4.2, the google error tracker is ful of nexus7 and 10 probs 
[12:07] <ogra-cb_> i guess a lot are userspace as well
[12:07] <apw> ogra-cb_, nasty nasty
[12:07] <janimo> apw, so if I get you a config file (the current say) you can make a report highlighting what may need to be added?
[12:07] <apw> i can make a report, we can then see if it is useful
[12:07] <ogra-cb_> well, i just flashed mz first raring image to the nexus7, lets see if the even boots at all
[12:07] <janimo> ogra-cb_, since nexus 10 is a different SoC it may indeed be userland
[12:08] <ogra-cb_> janimo, yeah, thats why i mentioned that
[12:08] <janimo> apw, thanks, I'll paste you a config shortly
[12:08] <ogra-cb_> yay
[12:08] <ogra-cb_> it boots !
[12:08]  * ogra-cb_ is in initrd, tarball is being verified
[12:09] <ogra-cb_> heh, and flashing from the chromebook is possible :)
[12:25] <janimo> apw this is the current config http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-nexus7.git;a=blob_plain;f=debian.linaro/config/config.common.ubuntu;h=b4f6b5b5cbf53b8188bb90c3c0d5cceff79362c4;hb=HEAD
[12:44] <apw> smb, cking, ogasawara, a new toy for you: https://launchpad.net/~/+upcomingwork
[12:45] <apw> a _live_ indication of your milestoned workitems and bugs
[12:45] <cking> nice, that's more helpful than burndowns
[12:45] <smb> apw, Damn, that is too useful and makes it kind of hard to claim one did not know...
[12:46] <apw> the only wrinkle is blueprings need to be milestoned correctly for it to show them
[12:46] <apw> i am working through ours now to fix them
[12:46] <cking> +1 for apw
[13:01] <apw> cking, ok your list looks much less well :)
[13:01] <cking> much less?
[13:01] <apw> you have a lot more stuff now
[13:02] <cking> sad trombone sound applies
[13:02] <janimo> apw, is the link I pasted enough?
[13:02] <apw> janimo, i will sort it out
[13:03] <janimo> ok thanks
[13:30] <apw> ogasawara, oh and for you as owner of blueprints see all of the work items you are responsible for even if you arn't the assignee, nice
[13:45] <Kano> hi, why is kernel-wedge not in sync with sid for raring?
=== broder is now known as broder_
[13:46] <Kano> i thought you rebase the system every 6 month on sid
[13:47] <ogra-cb_> janimo, apw, FYI the nexus kernel from teh archive works fine 
[13:47] <apw> ogra-cb_, heh ... thats something
[13:48] <apw> Kano, things which have delta do not automatically sync
[13:48] <ogra-cb_> if only userspace would be so well too 
[13:48] <Kano> apw: then do it manually
[13:48] <Kano> its boring to do that everytime on my own
[13:49] <apw> or perhaps as it does what i need as it is i could not do it
[13:49] <Kano> it is bad when the version is lower than sid
[13:50] <Kano> and you do not even provide a patch file as it is a native package
[13:51] <Kano> ubuntu patches are often down in a very stupid way
[13:51] <Kano> everything in diff
[13:51] <Kano> well in that case there is not even a diff
[13:51] <Kano> efibootmgr is patched without quilt
[13:52] <cking> is that "do it manually so my distro can benefit too" kinda plea?
[13:52] <Kano> no good maintainer would do that
[13:53] <apw> for a native package like that the archive versions are the version control
[13:54] <Kano> and for efibootmgr?
[13:56] <apw> efibootmgr only exists in debian because someone in ubuntu actually maintains it there
[13:56] <Kano> sure and without ubuntu debian would not exist
[13:57] <Kano> or what
[13:57] <apw> my point was more that the delta is minor and to do with the fact that we maintain it there too
[13:57] <apw> so every debian derivative benefit
[13:57] <apw> my point was only that we do what we can to keep debian as the gold standard
[13:57] <apw> and only carry delta like that when we need to to not affect debian
[13:58] <apw> and i am struggling to find your point
[13:58] <Kano> usally the point is to make changes upstream which fix things
[13:58] <apw> right but efibootmgr is different cause we do not have the same list of architecture
[13:59] <Kano> debian never had lpia
[14:00] <Kano> what you changed is pure ubuntu specific
[14:00] <apw> well all i can say is the two packages you picked out have very active debian centric people as their maintainers
[14:01] <Kano> so active that no patch is in debian
[14:02] <apw> for those two packages maybe, but for the 100s of others i can assure you there ar
[14:02] <apw> are, your presumption that we don't care about debian is plain unreasonable
[14:02] <apw> the delts in kernel-wedge is a kernel related issue whering our useage and theirs does not match
[14:03] <apw> as we have differnet kernels, it is not upstreamable
[14:03] <Kano> the -w fix is for upstream
[14:03] <Kano> and should not be in a diff
[14:05] <Kano> http://packages.ubuntu.com/source/raring/kernel-wedge
[14:05] <Kano> why is there no ubuntu git shown?
[14:06] <apw> we don't mantain the delta in version control perhaps
[14:42] <herton> apw, can bug 1075181 can be marked verified for linux-lts-quantal? Just want to make sure the precise package was tested
[14:42] <ubot2> Launchpad bug 1075181 in ubiquity (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,Triaged] https://launchpad.net/bugs/1075181
[14:42] <herton> *precise proposed package
[15:12]  * herton -> lunch
[16:01] <hggdh> infinity: panda tests in progress (one done); armada depends on a bit of hacking, still looking at all the data rbasak gave me
[16:13] <ogasawara> rtg: heading in now
[16:59] <apw> ogasawara, rtg, heads up for the next upload, kernel-wedge has been updated -- should be benign but you never know
[16:59] <ogasawara> apw: ack
=== yofel_ is now known as yofel
[17:20]  * ppisati -> gym
[17:23] <rtg> apw, I upgraded the raring chroots on gomeisa and tangerine. I noticed that kernel-wedge is still the same version as quantal. still building ?
[17:26] <apw> rtg, still briney-ing
[17:27] <rtg> apw, ah
[17:39] <apw> rtg, ogasawara, that reminds me, i have pushed the first stage of the autopkgtest tests we have been asked for by pitti
[17:40] <rtg> apw, saw that
[17:41] <rtg> apw, I'm still busily ripping out duplicate firmware
[17:41] <apw> rtg, i am loving that
[17:41] <apw> rtg, i see a heap of it is hitting mainline too, nice
[17:42] <rtg> apw, there was a surprising amount of resistance to some of those patches. go figure.
[17:48] <apw> rtg its most perlexing and no mistake
[18:38]  * apw moans about the publisher taking _ages_ todayu
[20:56] <apw> rtg, ogasawara, ok i have just built some kernels with the new kernel-wedge, they look within the noise the same to me
[21:07] <ogasawara> apw: ack, thanks
[21:20] <apw> rtg, ogasawara, ok just tested overlayfs and aufs on the 3.7.0-3 kernel (amd64 and i386) and all is well
[21:21] <rtg> apw, ack
[22:29] <infinity> Whoever owns /home/kernel/kteam-bugs/code/reports/auto-reports-mako on lillypilly, it desperately needs locking.  There are a dozen copies running right now.
[22:30] <infinity> herton: ^-- That something you know about?
[22:31] <bryce> infinity, maybe brad or bdmurray?
[22:32] <infinity> bryce: I see no brad, and bdmurray isn't kernel.
[22:50] <herton> infinity, sorry, I don't know about this one
[22:54] <sconklin> infinity: looking. It's brad's but he's on the road, I should have perms to deal with it
[22:55] <sconklin> someone most have already killed them
[22:59] <sconklin> infinity, herton: I see nothing the the logs indicating a problem, and only two copies running (which is still a problem). I'm going to just remove it from the crontab and email brad, as I'm about to bail for the holiday. Probably no one will notice if it doesn't regenerate bug reports until Monday, and Brad may get to it before then
[23:00] <herton> sconklin, ack
[23:01] <infinity> sconklin: Thanks.  I suspect a bit of trivial locking wouldn't be hard.  Or one could ask IS to install run-one on lillypilly, and wrap it with that.
[23:02] <sconklin> infinity: agreed What I suspect happened is that it runs every half hour, and it just reached a runtime of over that.
[23:02] <infinity> sconklin: Well, the desktop team had a script throwing the machine into swap death, so it handily exposed everyone else who had scripts that failed to lock. ;)
[23:02] <sconklin> haha, ok