[09:56] <lantizia> apw, did you get my pm the other day (updated the bug too)
[09:57] <apw> lantizia, oss bug ?  if so the patches went out today for review
[09:58] <lantizia> oh cool you did get my message then :D
[10:00] <apw> not any pm, but i saw an email
[10:11] <lantizia> all it said was (sent a few hours before that email)... "Off to bed (as I'm sure you already are) - finally got back and home and finished testing... I'm basically reporting that it works very well indeed now using the osspd package from raring on precise and quantal"
[11:10] <trailblazerz11> What's up with 3.9-rc1 mainline build?
[11:14] <apw> trailblazerz11, what is wrong with it from your point of view
[11:19] <apw> trailblazerz11, a more useful question would have been. "Does anyone know why the mainline build for 3.9-rc1 has no binary packages?"
[11:19] <apw> which would have triggered my memory of cking asking me to add bc into the chroots for builds to allow 3.9-rc1 to build for him
[11:51] <trailblazerz11> sorry, thanks for the reply
[12:35] <rtg_> apw, whats up with the repeated mainline build emails ? 'Mainline Build v3.9-rc1'
[12:38] <smb> rtg_, I suppose outfall of attempts to fix the new dependency on bc
[12:41] <rtg_> smb, indeed, guess I'd better get that in the control file
[12:41] <smb> rtg_, hm, yeah, would not completely rule out apw working on that too...
[12:42] <apw> rtg_, i already added it
[12:42] <apw> rtg_, yes it is about doing the builds till they work, which i think this final time they will
[12:43] <apw> (it == build-dep: bc)
[12:43] <rtg_> apw, just saw that. guess I'd better get that package added to the chroots
[12:43] <apw> rtg_, yeah i've been putting that off, can you add them to precise as well as we build test kernels in the 'previous lts'
[12:43] <apw> s/them/bc
[12:44] <rtg_> apw, ack. I'll prolly just do it in general
[13:22] <zyga> hey everyone, I seem to have found a regression in the kernel
[13:22] <zyga> 3.8.0-5 works
[13:22] <zyga> beyond that I get hangs on boot
[13:22] <zyga> and unable to mount /sys/firmware/efivars
[13:23] <zyga> I'm checking which of the three kernels that I have actually boots
[13:23] <zyga> -10 does not boot to desktop
[13:23] <zyga> nor does -11
[13:25] <zyga> how should I proceed / file a bug?
[13:25] <zyga> I seem to be able to boot into the recovery mode
[13:26] <zyga> the actual filesystem that fails to mount is "/sys/firmware/efi/efivars"
[13:26] <zyga> booting hangs on [S]kip or [M]anual
[13:28] <zyga> so known good is 3.8.0-5, known bad is -10
[13:28] <zyga> with equally bad -11
[13:28]  * zyga waits around for someone to show up
[13:28] <smb> and pressing "s" probably continues the boot...
[13:28] <zyga> smb: yes
[13:28] <smb> but yeah, filing a bug would be appreciated
[13:29] <zyga> smb: but it does not finish normally, other errors show up and all I get is console in vt1
[13:29] <zyga> smb: note: that's from _recovery_ boot
[13:29] <zyga> normal boot just hangs
[13:29] <zyga> smb: ubuntu-bug linux-image
[13:30] <smb> zyga, just ubuntu-bug linux
[13:30] <zyga> k
[13:30] <zyga> on -5 now, apport found some bugs, let's see if that's it
[13:31] <smb> wondering whether normal boots would continue by pressing s and just not show the message
[13:31] <zyga> smb: ubuntu-bug does not work, claims that -5 is not an official package
[13:31] <zyga> (bogus obviously)
[13:31] <smb> zyga, think it does that if its not the latest one
[13:32] <zyga> smb: I have the latest one installed
[13:32] <smb> which probably only boots in recovery... if I ccould remember, there is a way to only save the report files...
[13:33] <zyga> smb: but the error message is bogus, this _is_ an official package, I _have_ installed it, unless it's checking the one I'm running now
[13:33] <zyga> smb: let me see if -11 works with recovery (I tried -10)
[13:35] <zyga> ok, on -11, reporting the bug in text mode
[13:35] <smb> zyga, think "ubuntu-bug --save=file linux" should allow to write the data to file
[13:35] <zyga> oh, wireless crashed the kernel while I was doing that
[13:36] <zyga> or just semi-crashed, the report is still going 
[13:36] <zyga> that's one crappy day for having UDS sessions
[13:36] <zyga> I keep getting screen full of kernel backtraces 
[13:39] <zyga> I keep seeing dots printed, is that still apport?
[13:39] <smb> zyga, usually the common rule is not to rely on the latest release (or update) while something important (conference, travel) goes on. But I know that is not very helpful
[13:40] <zyga> smb: it's not that bad, I have a desktop that I'm using now but it's distracting from the sessions
[13:40] <zyga> (20 minutes left)
[13:40] <smb> zyga, might be... not sure there. If submitting the report directly is too problematic, try the --save and then I think apport-cli to upload the saved file
[13:40] <zyga> smb: I suspended ubuntu-bug
[13:40] <zyga> smb: then did ps aux
[13:40] <zyga> and that hanged?
[13:40] <zyga> I keep getting kernel backtraces everywhere
[13:41] <smb> certainly not a very good state
[13:41] <smb> what kind of hw is that?
[13:42] <smb> (just wondering since it looks somewhat related to uefi changes)
[13:43] <zyga> smb: core i7 (latest one, I guess that's ivy bridge)
[13:43] <zyga> smb: broadcom wireless crap (wl), atheros ethernet (alx) 
[13:44] <zyga> smb: the build is from lenovo, similar to ideapad but more 'value' market
[13:44] <smb> zyga, not any samsung by chance... well iirc some people had fun with lenovo too
[13:44] <smb> ok
[13:44] <zyga> hehe, no :)
[13:45] <smb> cking, do you remember... I thought someone had efi pain with some x something... 
[13:45] <zyga> (it's running efi + signed kernel)
[13:45] <zyga> ubuntu-bug keeps printing dots
[13:46] <cking> smb, I'm trying to recall, but I can't think of it at the mo
[13:46] <zyga> I can suspend that and poke around in /sys/ if you want
[13:46] <smb> well if its done in a seperate thread it can do that for a while... 
[13:48] <smb> zyga, Right now I could not say what to look for. 
[13:48] <zyga> ok
[13:48] <zyga> I'll let it finish
[13:48] <zyga> and get ready for the first session
[13:49] <smb> afaik none of the team was having similar issues... except ... cking I think your sdp completely imploded for other reasons
[13:49] <cking> smb, yep, it lost it's mind and disabled auto CSM for some reason
[13:50] <smb> zyga, as said I would not be sure whether printing the dots is done while waiting for a background process. If those are seperate thread and the other one hangs, there could be a lot of dots,,,
[13:50] <cking> is that a bug in ubuntu-bug that needs reporting against ubuntu-bug?
[13:51] <smb> cking, I'd rather not... the world may recurse for eternity
[13:51] <cking> -ETOOMANYLEVELSOFINDIRECTION
[13:53] <diwic> -ETOOMANYWORDSMAKESITHARDTOREAD
[13:53] <diwic> although CamelCase doesn't look unix enough
[13:53] <zyga> heh
[13:54] <zyga> yeah
[13:54] <zyga> I think it's dead jim
[15:53] <brendand> bjf, is the proposed kernel cadence going to be discussed in the rolling release session coming up?
[15:54] <bjf> brendand, which cadence are you  referring to? the sru cadence (not changing) or the daily, rolling cadence?
[15:56] <brendand> bjf - well, maybe i should ask this in the session, but e.g. will raring be included in the -proposed cadence after it's released?
[16:42] <geofft> Moving here from the room channel: would a "return true" autopkgtest in OpenAFS be reasonable, just to check compilability? 
[16:42] <geofft> Will it get run against the PPA, and is there a way to sign up for notifications of test failures? 
[16:46] <bjf> geofft, i think you are asking how to get a test integrated into the testing for the OpenAFS package. I think you'd want to discuss that with the maintainer.
[16:53] <geofft> I think my question is more "how does that test run against the PPA kernel before it gets pushed to production" 
[16:54] <geofft> (I'm talking with the folks who did the most recent OpenAFS SRU) 
[17:31] <apw> geofft, i don't think we know how the autopackage tests integrate well enough to answer that.  pitti likely would knowb
[17:46]  * rtg_ -> early lunch
[17:51] <apw> geofft, i also query your 'compilability' is the only thing we care about, if you don't care if it works why install it at all
[17:53] <geofft> apw: What I mean is that in the last like 5-6 years I've been using OpenAFS, I've never seen it build and not work right 
[17:54] <geofft> apw: but it seems like half of all new kernel updates make it not build 
[17:54] <apw> geofft, indeed, but the logical thing is to be aware of when it changes and to test it at those times
[17:55] <geofft> apw: OpenAFS itself doesn't change. It's the lack of stable kernel API that breaks it 
[17:55] <geofft> (It's GPL-incompatible free software, the situation sucks all around) 
[17:55] <apw> geofft, right the kernle doesn't offer one of those, never has
[17:55] <geofft> yeah 
[17:55] <geofft> apw: I'm not asking for the kernel to start offering one 
[17:55] <geofft> apw: I'm just saying, based on experience, new kernel minor versions have a good chance of breaking it in a way that it just won't compile 
[17:55] <geofft> and approximately no chance of breaking it in a way that it compiles but doesn't run. 
[17:56] <geofft> apw: I'm happy to write a more serious test that loads the module in a VM, but I don't think it'd be worth the overhead -- it wouldn't find anything 
[17:57] <apw> geofft, if you had one of those you could run it against the kernels automatically as they appear in the PPA
[17:58] <apw> and be apprised if there were issues
[17:58] <geofft> sure, I can happily set up a local VM or something to do this. 
[17:59] <geofft> I guess I'm just wondering if there's a way to do this on Ubuntu-run infrastructure, instead of a desktop in my living room 
[18:00] <geofft> or adding more load to my organization's buildserver, or whatnot 
[18:00] <geofft> it seems like the right place to do this test is with autopkgtest infrastructure, since it exists. 
[18:01] <geofft> so the question is where to hook in infrastructure so we can say "hey hold up, we need another ./configure check in OpenAFS to handle this kernel API change" before you guys push a new kernel to rolling 
[18:27] <apw> geofft, well if it was approved to hold the kernle for that that the britney runs would nominally hold it in -proposed
[18:27] <apw> i am unsure that britney yet holds for autotest failures, but that is the plan
[18:27] <apw> geofft, though if someone was activly maintaining openafs against the unstable kernel PPA we should never hit this issue
[18:28] <apw> geofft, as although it seems good to add lots of infrastructe for these things, simply being informed there are new kernels and testing with them in advance is probabally a lot less work, especially as you already indicated it will fail half the time
[18:29] <apw> as the time we want to find out this is going to fail is not when we shove a kernel into -proposed then be slaves to when someone fixes openafs, we want to know it is going to fail during the early -rcs and have it fixed by the itme we shove it in -proposed
[18:37] <geofft> apw: Yeah, testing against earlier RCs is the right answer, and much of the time upstream is on the ball about adapting to the API change in master 
[18:38] <geofft> Most of the time of that, upstream remembers to backport those to stable; most of the time of _that_, the stable fix goes into Debian 
[18:38] <geofft> But occasionally things fall through the cracks. 
[18:38] <apw> geofft, our current minimal process is to announce kernels on kernel-team@ and to tell specific individuals with key requirements, currently the binary video drivers and the server folk who have a few
[18:39] <apw> geofft, with any new kerenl being in a test PPA it is trivial to make your own PPA for testing which depnds on our kernel PPA leading you to be testing against the said kernel
[18:39] <geofft> sure 
[18:39] <apw> geofft, though you need a VM or similar to install the kernel for dkms packages annoyingly
[18:40] <geofft> there is packaging for building a module-assistant kernel, so maybe that can be abused to do a PPA test compile. 
[18:40] <apw> something which did that on a regular (weekly perhaps) and reported back would be pretty easy to put together i recon
[18:40] <geofft> Can I set up a PPA that will automatically rebuild when the kernel PPA gets changed? 
[18:41] <apw> geofft, for dkms that doesn't help cause building the package does not trigger dkms to run
[18:41] <apw> acdtually you just want a machine which has the kernle ppa attached and then just updates regularly
[18:41] <apw> if the update fails that is likely cause of openafs failing to build
[18:41] <geofft> yeah... is that what other people who care about DKMS do? I guess that's fine. 
[18:42] <apw> i am unsure if they do it automatically, but that is the process in large part
[18:55] <smaresca> in the linux-image-3.2.0-* debs from http://ddebs.ubuntu.com, I've noticed that 'struct slab' seems to be missing from debug type data
[18:56] <smaresca> I was under the impression that even SLUB uses slab structs, so I was really confused that this was the case
[18:56] <smaresca> is that an expected omission?
[20:06]  * ppisati -> real life
[20:26]  * rtg_ -> EOD
[20:48] <apw> smaresca, it is not clear that it does use it
[20:59] <smaresca> apw, i agree..I've been trying to find some sort of confirmation one way or the other
[21:00] <apw> check include/linux/mm_types.h
[21:00] <apw> there is shows the slub info overlaying the slab_page pointer, the slab * type pointer
[21:00] <apw> you don't use both at once
[21:08] <smaresca> apw, so even though a lot of SLUB code references slabs, it's more a question of overlapping terminology, and i've gotten myself confused unnecessarily?
[21:08] <apw> smaresca, right they are 'slabs' in the sense they are typed memory pools
[21:09] <apw> smaresca, they are not slabs as in controlled by struct slab.  they do i believe have a slab_info associated with them
[21:18] <smaresca> apw, thanks for clearing that up for me
[22:38] <BarkingFish> Hello guys :)  I know it's a pain, but I don't suppose any of you would happen to have the main files for kernel 3.8.0-2-generic floating around at all, please?  I've been given source to compile it myself, but my system doesn't seem to like that - next option is to search for someone with the headers, image-extra, and the image & -generic files please :)
[23:11] <BarkingFish> sorry for disappearing, had a system restart to put through
[23:22] <Sarvatt> BarkingFish: on https://launchpad.net/ubuntu/+source/linux you can click view full publishing history up top, scroll down to the version you want https://launchpad.net/ubuntu/raring/+source/linux/3.8.0-2.6 then click on the architecture under Builds to get the debs
[23:24] <Sarvatt> the main headers package (not generic) is built on i386 for everything though so will need to get it from there if you're on amd64