=== cmagina is now known as cmagina-away
=== smb` is now known as smb
[07:19]  * smb thinks ppisati just fell from his chair... or mumble died on some end
[07:27] <apw> which is more reliable mumble or the chair
[07:27] <apw> i suspect the chair by some margin
[07:27] <apw> smb, moin
[07:28] <smb> apw, Possibly. Though he did not react on the irc nudging either...
[07:28] <smb> apw, moin. Man did we all fall out of bed this morning?
[07:28] <RAOF> apw: How are the firebees today?
[07:45] <apw> RAOF, they are going to be toasty again for sure
=== fmasi_afk is now known as fmasi
=== ghostcube_ is now known as ghostcube
[08:54] <psivaa> bjf: jjohansen: I'm planning to release the regression testing task for bug #1199285 based on your feedback to the bug #1201530 as to whether it's a real regression, if that's OK
[08:54] <ubot2`> Launchpad bug 1199285 in Kernel SRU Workflow security-signoff "linux-lts-quantal: 3.5.0-37.58~precise1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1199285
[08:54] <ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,New] https://launchpad.net/bugs/1201530
[08:56] <jjohansen> psivaa: can you rerun the regression tests and see if it shows up in the QA env, we have had bugs in the past where they would only surface in a given env because of how the env is set up (eg. QA env setting the dump location)
[08:58] <psivaa> jjohansen: not sure if i understand correctly, but this was run in QA env. Do you want me to see if it's occurring again?
[08:58] <jjohansen> psivaa: yes please
[08:59] <jjohansen> I am trying to determine whether its a repeatable failure in the QA env
[08:59] <psivaa> jjohansen: ack, will do in a bit, i have started to run something else in that machine
[10:29] <ppisati> brb
[12:05]  * ppisati -> out for lunch
[13:33] <arges> is there a meta-package for linux-source for linux-image-lts-quantal / raring? linux-source just installs the 3.2 kernel on my 12.04.2 install
[13:35] <rtg> arges, I don't think there _is_ a linux-source package for the LTS kernels, is there ?
[13:35] <psivaa> jjohansen: so, I could not see the failure when re-running the apparmor tests a few times. 
[13:35] <Sarvatt> not seeing one in the lts-quantal packaging at least
[13:35] <psivaa> i.e. could not reproduce bug 1201530
[13:35] <ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,Incomplete] https://launchpad.net/bugs/1201530
[13:36] <arges> rtg: well what i'm looking for is... i did a fresh 12.04.2 install.I want to have the 3.5 sources installed, which package do I need
[13:36] <arges> instead of apt-get source linux-image-`uname -r`
[13:37] <rtg> arges, I'm not sure you can.
[13:38] <arges> is there a way to make a linux-sources-lts-quantal package to pull that in perhaps?
[13:39] <rtg> arges, not without extending the LTS packaging to actually produce a linux-sources binary package.
[13:39] <arges> ok. thanks
[13:52] <psivaa> sbeattie: jjohansen: I am able to reproduce a security test failure issue though, bug #1201781 when testing linux-ti-omap4: 3.2.0-1435.46
[13:52] <ubot2`> Launchpad bug 1201781 in ubuntu-kernel-tests "test_010_proc_maps fails on panda-es with 3.2.0-1435-omap4 #46" [Undecided,New] https://launchpad.net/bugs/1201781
=== cmagina-away is now known as cmagina
[14:24] <bjf> psivaa, i'm ok with you adding a note saying that you were not able to reproduce the failure and release the kernel from testing
[14:25] <apw> psivaa, ok that signage issue should be gone in any new images made after 'now'
[14:25] <bjf> brendand, per your question from yesterday, there has been no change in the schedule. When kernels are available for testing (marked as such via the tracking bug) is not based on the schedule but on when the associated bugs have been verified
[14:26] <bjf> brendand, the point of the kernel-sru-announce mailing list is to send out notifications if / when there are changes to the schedule
[14:26] <psivaa> bjf: ack
[14:28] <psivaa> apw: ack, ill release the qa testing task  for the precise omap4 kernel as well
[14:29] <brendand> bjf, should the backport kernels be considered verified before their parent kernels have been though? that's what was confusing
[14:29] <psivaa> apw, ohh i assume you did not talk about bug #1201781?
[14:29] <ubot2`> Launchpad bug 1201781 in ubuntu-kernel-tests "test_010_proc_maps fails on panda-es with 3.2.0-1435-omap4 #46" [Undecided,New] https://launchpad.net/bugs/1201781
[14:30] <apw> brendand, they can be verified if all their branch specific bugs are complete, though they are subject to the parent branch passing as well
[14:30] <bjf> brendand, it wasn't what i was expecting and in the future that's less likely to happen
[14:30] <apw> psivaa, i am referring to bug #1201444
[14:30] <ubot2`> Launchpad bug 1201444 in linux-signed (Ubuntu Raring) "linux and linux-signed may becomes skewed due to loose dependancy (was Secure boot signature verification of linux kernel is failing with today's images)" [Medium,Fix committed] https://launchpad.net/bugs/1201444
[14:30] <psivaa> apw: ack, just realised it, thanks :)
[14:33] <psivaa> bjf: Would like to know how to proceed with the precise omap4 kernel because the security test failure ^(1201781) is reproducible
[14:33] <bjf> psivaa, looking
[14:34] <bjf> psivaa, i don't see any comments from any of the security dudes. have you pointed them at it?
[14:35] <psivaa> bjf: i did jjohansen and sbeattie , not sure if they are the only ones to point at :)
[14:36] <bjf> psivaa, that's good enough. did they have anything to say about it?
[14:36] <psivaa> bjf: not yet, waiting though. 
[14:37] <psivaa> bjf: ok i must have rushed a bit, i'll wait 
[14:37] <bjf> psivaa, ack. nothing i can really add then. i depend on them to let me know if it's the kernel or an issue with the test.
[14:37] <psivaa> bjf: ack
=== cmagina is now known as cmagina-away
[15:08] <jsalisbury> **
[15:08] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:08] <jsalisbury> **
[15:10] <rtg> apw, any prgress on overlayfs ? I see that file_operations.readdir has morphed into file_operations.iterate with more complex semantics.
[15:21] <ppisati> brb
[15:28] <apw> rtg, i was just about to start looking at those, i had just pulled up my aufs tree to see if that was available
[15:28] <rtg> apw, aufs changed his repository location, didn't he ?
[15:29] <apw> yeah
[15:29] <rtg> where to ?
[15:30] <apw> rtg, working on that, cause i followed his last move, and now i don't have the latest still so something is amiss, give me a sec
[15:33] <apw> rtg, seems he since has had sf.net shit itself on his repos and lose them, oh the joy
[15:34] <rtg> apw, that doesn't say much for SF disk management
[15:34] <apw> rtg in theory git://git.code.sf.net/p/aufs/aufs3-standalone is his latest ...
[15:34] <apw> rtg, i suspect it was finger trouble as much as anything
[15:34] <apw> rtg i will look at updating it and see
[15:36] <rtg> apw, looks like he has a July 15 update
[15:36] <apw> yeah i'll give it a tug and see
[15:47] <apw> rtg, well it 
[15:47] <apw> rtg, well it builds at least (aufs) standalone, so will see if it links to the kernel and test it
[16:14] <apw> rtg, have you booted unstable at all ?
[16:15] <bjf> that doesn't sound like a good question
=== cmagina-away is now known as cmagina
[16:21] <apw> heh, not looking good on one of my boxes for sure, on either of the ones i normally test
[16:21] <apw> rtg, i am seeing hard hangs during boot on amd64 and panics with splash on i386
[16:23] <rtg> apw, thats before aufs is in use ?
[16:24] <apw> well before indeed, during early boot in both cases
[16:24] <apw> for i386 i am seeing oopses in addrconf_notify out of what looks like a network address update
[16:25] <apw> rtg, does it boot ok for you, i wonder if this is ipv6 related as they are temporary addresses it is changing
[16:25] <apw> oh i feel a nice cider coming on
[16:25] <rtg> apw, I haven't actually tried it since -rc1
[16:26] <apw> rtg, so it could be bust anyhow ... ok
[16:27] <rtg> apw, I'm working on booting the daily on a tunnel mountain UEFI system
[16:28] <apw> heh what could possibly go wrong
[16:28] <rtg> apw, well, it could completely wreck that system, for starters
[16:28] <apw> rtg, there is only ext4 changes in linus' tree isnce -rc1
[16:29] <rtg> apw, have you tried mainline -rc1 ?
[16:29] <apw> </sarcasm>
[16:30] <apw> rtg nope, will do so now
[16:39] <jjohansen> psivaa: okay, thanks we may need to access a QA machine to narrow down why its failing. I will try again here first though
[16:39] <jjohansen> psivaa: as for 1201781 that sounds like a race
[16:39] <jjohansen> in the test
[16:40] <psivaa> jjohansen: ack, i ran the test locally on a pandaboard though
[16:42] <jjohansen> psivaa: for bug 1201530?
[16:42] <ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,Incomplete] https://launchpad.net/bugs/1201530
[16:42] <psivaa> jjohansen: no, that was run on a machine in the lab, sorry. it's the other 1201781 that i ran locally
[16:43] <jjohansen> psivaa: okay, thanks
[16:43] <psivaa> jjohansen: so if the race is in the test, what's the next step? 
=== cmagina is now known as cmagina-away
=== cmagina-away is now known as cmagina
[16:47] <jjohansen> psivaa: as bjf said for 1201530 add a note that you where unable to reproduce the failure and release the kernel from testing
[16:47] <jjohansen> for 1201781 if its the test, you add a note that the test has been confirmed to have a race and release the kernel from testing
[16:48] <psivaa> jjohansen: i have released the testing task that was held up by bug  1201530
[16:48] <ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,Incomplete] https://launchpad.net/bugs/1201530
[16:48] <jjohansen> psivaa: I am assuming 1201781 is a race but haven't looked into it yet
[16:49] <jjohansen> psivaa: ack
[16:49] <psivaa> jjohansen: ok, i'll wait for your verdict then?
[16:49] <psivaa> re 1201781
[16:53] <apw> rtg, ok i've arbitrarily pushed the aufs update to unstable, give it builds and unstable is a heap anyhow
[16:53] <apw> i'll look at overlayfs in the morning
[16:53] <rtg> apw, ack.
[16:54] <rtg> apw, I'll work on figuring out the boot problem
[16:54] <apw> sounds good to me, i fancy a beer in the garden
[16:54] <rtg> apw, hmm, you said cider before, so which is it ?
[16:54] <apw> beer can mean either in the context of a garden :)
[16:55]  * smb is getting thirsty
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[16:55] <apw> smb, it is night time where you are, you might not get one before closing
[16:56] <smb> apw, My fridge is open 24/7
[16:56] <smb> Well not literally
[17:16]  * ppisati -> gym
[17:27]  * rtg -> lunch
=== vanhoof_ is now known as vanhoof
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 23rd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:43] <infinity> zequence: You need to update your configs.
[17:43] <infinity> apw: There's a magic thing for that, right?  updateconfigs or something?
[17:57] <bjf> infinity, yes, fdr updateconfigs
[17:58] <infinity> zequence: ^
[18:17] <zequence> infinity: oh, something has changed?
[18:18] <zequence> Where is updateconfigs and which configs does it update?
[18:18] <zequence> Sorry to be so late with uploading the kernels, btw
[18:22]  * apw isn't sure i'd expect you to need to updateconfigs on lowlatency cause it has only overlays
[18:22] <apw> infinity, where is the failure
[18:24] <rtg> apw, it looks like a sysctl is being written when 3.11-rc1 burns in. Is that what you saw ?
[18:25] <infinity> apw: https://launchpad.net/~ubuntustudio-kernel/+archive/linux-lowlatency-sru/+build/4799579
[18:25] <apw> rtg it was a config variable, being changed via procfs i think
[18:25] <apw> rtg but very similar
[18:25] <infinity> zequence: "debian/rules updateconfigs" is what bjf implied.
[18:25] <rtg> apw,  right, I meant procfs
[18:26] <apw> rtg, tmpaddr somethign in the stack
[18:27] <apw> zequence, i don't expect updateconfigs to work on lowlatecy
[18:27] <zequence> apw: ok
[18:27] <apw> because of the way it works
[18:27] <apw> zequence, i assume yours is pushed to the normal place
[18:27] <zequence> apw: I've changed the repo now..
[18:27] <apw> zequence, so i can test against it and tell you how to fix it yourself next time
[18:28] <apw> and this is all quantal yes 
[18:28] <zequence> quantal only so far
[18:29] <zequence> https://github.com/ubuntustudio-kernel/ubuntu-quantal-lowlatency.git
[18:29] <zequence> apw: ^
[18:29] <apw> zequence, thanks, i'll sort out why this is happeneing and get you the info shotrly
[18:30] <rtg> apw, addrconf_notify
[18:30] <zequence> apw: Greatly appreciated
[18:30] <apw> rtg, the self same one then
[18:30] <apw> tmaddr is one up i think from teh eip there
[18:31] <apw> anyhow, the same signature for sure
[18:43] <rtg> apw, this is likely our fault: 'UBUNTU: SAUCE: (no-up) ipv6: make the net.ipv6.conf.all.use_tempaddr sysctl propagate to interface settings'
[18:43] <apw> rtg, ooops
[18:44] <rtg> addrconf_use_tempaddr() calls dev_tempaddr_change((struct inet6_dev *)table->extra1), but table->extra1 is NULL I think
[18:44] <rtg> lemme have a look at 3.10
[18:45] <apw> rtg, rip it out i say and if that fixes it send it back to the submitter
[18:46] <rtg> apw, I'll rip it out to make certain that is indeed what is causing the crash.
[18:46] <rtg> I think xnox write it
[18:58] <nessita> hello! is this the proper channel to ask about what it looks a kernel bug in raring?
[18:58] <nessita> bug is LP: #1201528
[18:58] <ubot2`> Launchpad bug 1201528 in alsa-driver (Ubuntu) "[Realtek ALC889] - Audio Playback Unavailable" [Undecided,New] https://launchpad.net/bugs/1201528
[19:00] <bjf> nessita, right channel. our sound expert is in the EU. he will probably see your bug tomorrow
[19:01] <nessita> bjf, great, shall I do anything else about this?
[19:01] <bjf> nessita, not at the moment. see if diwic takes a look at your bug. he's quite responsive.
[19:02] <nessita> bjf, ack, will do, thanks
[19:03] <rtg> apw, that appears to have been the problem.
[19:20] <apw> rtg, ok good
[19:20] <rtg> apw, I think I found the fix. am testing now
[19:21] <rtg> building, rather. will test soon thereafter
[19:21] <rtg> they were playing some games with void *, so the compiler could not detect the change.
[19:32] <rtg> apw, fix made and pushed
[19:32] <apw> rtg great
[19:44] <xnox> rtg: me?! i am not the usual suspect for ubuntu:sauce: kernel patches.....
[19:44] <xnox> =)
[19:45] <rtg> xnox, wrong nick, sorry
[19:46] <rtg> I was thinking of Mathieu Trudel-Lapierre
[19:46] <apw> zequence, infinity, ok what is wrong here is that the tree wasn't clean enough; if you git clean -x -f d; fdr clean; fdr prepare-lowlatency; then you avoid the issue
[19:47] <rtg> cyphermox is whom I should have mentioned.
[19:47] <cyphermox_> yes?
[19:47] <rtg> cyphermox_, just pushed a patch to saucy unstable to fix a SAUCE patch that you wrote.
[19:48] <rtg> UBUNTU: SAUCE: (no-up) ipv6: make the net.ipv6.conf.all.use_tempaddr sysctl propagate to interface settings
[19:48] <rtg> cyphermox_, no action required on your part
[19:48] <cyphermox_> ok
[19:56] <zequence> apw: I did the update from clean trees, so I don't think that was the issue, unless I screwed something up
[19:56] <zequence> Ah, or did I really miss a step there - sorry if that is the case
[19:57] <zequence> No, it was clean before I started
[20:01]  * rtg -> EOD
[20:02] <zequence> Can't be another faulty RAM issue?
[20:08] <zequence> I'm building again to see
=== thomi_ is now known as thomi
[20:21] <zequence> infinity: new upload, so perhaps this one will work
=== fmasi is now known as fmasi_afk
[20:22] <infinity> zequence: Definitely wasn't a faulty RAM issue, no, it was clearly fallout from the config change in master.
[20:24] <apw> zequence, infinity, ok what is wrong here is that the tree wasn't clean enough; if you git clean -x -f d; fdr clean; fdr prepare-lowlatency; then you avoid the issue
[20:24] <infinity> zequence: If that upload really was "no change", it'll fail all the same.
[20:26] <zequence> apw: infinity: I'm definately sure that the tree was clean this time, but it should have been last time too, since I hadn't done any work previously. 
[20:27] <infinity> zequence: Did you debdiff your old and new uploads before uploading to see if anything had changed?
[20:27] <zequence> nope, let me do that
[20:27] <infinity> And if it did, indeed, change, a changelog better than "no change" would have been nice. :P
[20:28] <infinity> https://launchpadlibrarian.net/145114059/linux-lowlatency_3.5.0-37.38_3.5.0-37.39.diff.gz
[20:28] <infinity> Definitely not "no change".
[20:31] <apw> yeah i have fallen for this one before, it being prepared for another release even can trigger issues
[20:31] <zequence> ah, maybe that is it
[20:32] <zequence> it's the wrong version
[20:32] <apw> infinity, you should find and fdr clean; fdr updateconfigs will just run if it is right
[20:33] <infinity> You people and your "fdr"...
[20:33] <infinity> I do sincerely hope that updateconfigs doesn't actually need (fake)root. :)
[20:35] <hrw> hi
[20:36] <hrw> does someone know why 3.10.2/saucy does not bring up cpu1-7 on my i7?
[20:36] <zequence> apw: infinity: sorry, now I see it. I did miss to clean, so the debdiff showed the result of that then?
[20:37] <hrw> I got something broken with grub so boot drops me to grub console. Loading kernel with "linux /boot/vmlinux-3.10.2" + "initrd /boot/initrd-3.10.1" + "boot" == only cpu0 booted and machine reboots few seconds later
[20:38] <hrw> any ideas?
[20:40]  * zequence really needs to script the maintenance procedure to avoid this kind of stuff
[20:45] <infinity> zequence: If you want to knock that last revision out of git to remove the silly changelog entry and give me a clean 37.38, I can push it directly to the kernel PPA and bypass yours.
[20:46] <infinity> zequence: (That is, the current state of the package looks good, you can just remove that changelog entry and move your tags)
[20:48] <zequence> infinity: Sure. give me moment
[20:50] <zequence> infinity: Ah, right. But you can just take the tag that was for the first build, no? And I just delete the last commit (and tag 37.39)
[20:51] <infinity> Deleting commits doesn't work so well in git, does it?
[20:51] <infinity> But you can revert it, sure.
[20:51] <hrw> shit.
[20:52] <infinity> Well, moving tags doesn't work so well either, but meh. :)
[20:52] <hrw> looks like I have to dig in recycle bin to find ubuntu livecd and hope it will boot
[20:53] <infinity> zequence: Where's the git for lowlatency?  I'll clone this and roll my own while you sort out what you want to do to it. :)
[20:53] <zequence> infinity: https://github.com/ubuntustudio-kernel/ubuntu-quantal-lowlatency.git
[20:54] <zequence> infinity: Why not just keep the commit as it is? It's just a line in the changelog after all
[20:54] <zequence> or a few, I mean
[20:55] <infinity> Because I'm anal about unprofessional looking changelogs.  But your call.
[20:55] <infinity> If it were in main, I'd probably reject it outright, as the changelog is both uninformative and a lie. :)
[20:55] <zequence> infinity: Should it have been: UBUNTU: Lowlatency-3.5.0-37.39?
[20:56] <infinity> No, it should have not said "no change", when clearly there was a change, or the upload would have been unnecessary. :)
[20:56] <infinity> But, the point of testing in PPAs is that we can undo these things, not keep piling on top, so meh.  Let's just undo it.
[20:56] <infinity> (And learn a valuable lesson about local testbuilds before uploading)
[20:58] <zequence> infinity: ok, sorry for the trouble. lesson learned
[20:59]  * zequence is getting some more cores for his server next week so he doesn't need to do this stuff on his client machine
[20:59] <infinity> zequence: Bah, I do it on my laptop. :)
[21:00] <infinity> And I do linux-ppc on an 8-year-old machine...
[21:00] <infinity> (Probably not a fair comparison, given how fast that machine was 8 years ago, but it's finally feeling it's age)
[21:00]  * hrw starts to hate ubuntu^W kernel
[21:01] <infinity> Oh god, cloning a kernel tree over hotel wireless is like shaving your junk with a cheese grater.
[21:01] <infinity> hrw: Would you like me to mail you a livecd? :P
[21:02] <hrw> infinity: 12.10 livecd just went to trashcan for not booting
[21:02] <infinity> hrw: I'm not entirely sure how you expect a mismatched kernel and initrd to like each other.  Though, I'm not sure that's the root of whatever problem you're having either.
[21:03] <hrw> infinity: that line was typo - I have kernel+initrd matching
[21:03] <infinity> And I assume by "3.10.2", you mean "3.10.0-2"?
[21:04] <hrw> infinity: ~latest saucy one
[21:04] <infinity> Well, there's a -3 now, it might love you more.
[21:05] <infinity> If you can boot...
[21:05] <infinity> Surely, you still have the previous kernel?
[21:05] <hrw> -3 was in proposed last time I saw
[21:05] <hrw> infinity: no, I remove old kernels
[21:05] <hrw> infinity: and 3.10.0-2 was running perfectly fine
[21:05] <infinity> Tsk, tsk.
[21:05] <infinity> Our autoremoval magic intentionally keeps at least one more around for this sort of thing.
[21:06] <hrw> then oopsed/hang and after reboot I got to lain grub console and kernel is unable to smpboot
[21:06] <infinity> If you boot with nosmp does it work?
[21:08] <hrw> infinity: this time I end with unable to mount root
[21:08] <hrw> how to tell which fslabel is root for kernel?
[21:08] <hrw> uuid is too long to type ;d
[21:09] <infinity> Is your grub config buggered and no longer sane?
[21:10] <infinity> You can always use root=/dev/sda2 or whatever, like an old skooler.  UUID isn't required.
[21:10] <hrw> "linux /boot/vmlinux-3.10.0-2 nosmp rescue single debug" (+ initrd + boot) == 'unable to mount root'
[21:10] <hrw> sure, but I always forget which sdX my ssd is
[21:12] <hrw> and list of all partitions is empty anyway ;(
[21:12] <hrw> time to start bake own kernels like in old times...
[21:12] <hrw> and have kernel which boots to hdd without any modules
[21:56] <hrw> uf. booted
=== maxb_ is now known as maxb