=== smb` is now known as smb === henrix_ is now known as henrix [09:56] apw, did you get my pm the other day (updated the bug too) [09:57] lantizia, oss bug ? if so the patches went out today for review [09:58] oh cool you did get my message then :D [10:00] not any pm, but i saw an email [10:11] 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] What's up with 3.9-rc1 mainline build? [11:14] trailblazerz11, what is wrong with it from your point of view [11:19] 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] 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] sorry, thanks for the reply === rsalveti_ is now known as rsalveti [12:35] apw, whats up with the repeated mainline build emails ? 'Mainline Build v3.9-rc1' [12:38] rtg_, I suppose outfall of attempts to fix the new dependency on bc [12:41] smb, indeed, guess I'd better get that in the control file [12:41] rtg_, hm, yeah, would not completely rule out apw working on that too... [12:42] rtg_, i already added it [12:42] rtg_, yes it is about doing the builds till they work, which i think this final time they will [12:43] (it == build-dep: bc) [12:43] apw, just saw that. guess I'd better get that package added to the chroots [12:43] 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] s/them/bc [12:44] apw, ack. I'll prolly just do it in general === ara_ is now known as ara [13:22] hey everyone, I seem to have found a regression in the kernel [13:22] 3.8.0-5 works [13:22] beyond that I get hangs on boot [13:22] and unable to mount /sys/firmware/efivars [13:23] I'm checking which of the three kernels that I have actually boots [13:23] -10 does not boot to desktop [13:23] nor does -11 [13:25] how should I proceed / file a bug? [13:25] I seem to be able to boot into the recovery mode [13:26] the actual filesystem that fails to mount is "/sys/firmware/efi/efivars" [13:26] booting hangs on [S]kip or [M]anual [13:28] so known good is 3.8.0-5, known bad is -10 [13:28] with equally bad -11 [13:28] * zyga waits around for someone to show up [13:28] and pressing "s" probably continues the boot... [13:28] smb: yes [13:28] but yeah, filing a bug would be appreciated [13:29] smb: but it does not finish normally, other errors show up and all I get is console in vt1 [13:29] smb: note: that's from _recovery_ boot [13:29] normal boot just hangs [13:29] smb: ubuntu-bug linux-image [13:30] zyga, just ubuntu-bug linux [13:30] k [13:30] on -5 now, apport found some bugs, let's see if that's it [13:31] wondering whether normal boots would continue by pressing s and just not show the message [13:31] smb: ubuntu-bug does not work, claims that -5 is not an official package [13:31] (bogus obviously) [13:31] zyga, think it does that if its not the latest one [13:32] smb: I have the latest one installed [13:32] which probably only boots in recovery... if I ccould remember, there is a way to only save the report files... [13:33] 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] smb: let me see if -11 works with recovery (I tried -10) [13:35] ok, on -11, reporting the bug in text mode [13:35] zyga, think "ubuntu-bug --save=file linux" should allow to write the data to file [13:35] oh, wireless crashed the kernel while I was doing that [13:36] or just semi-crashed, the report is still going [13:36] that's one crappy day for having UDS sessions [13:36] I keep getting screen full of kernel backtraces [13:39] I keep seeing dots printed, is that still apport? [13:39] 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] smb: it's not that bad, I have a desktop that I'm using now but it's distracting from the sessions [13:40] (20 minutes left) [13:40] 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] smb: I suspended ubuntu-bug [13:40] smb: then did ps aux [13:40] and that hanged? [13:40] I keep getting kernel backtraces everywhere [13:41] certainly not a very good state [13:41] what kind of hw is that? [13:42] (just wondering since it looks somewhat related to uefi changes) [13:43] smb: core i7 (latest one, I guess that's ivy bridge) [13:43] smb: broadcom wireless crap (wl), atheros ethernet (alx) [13:44] smb: the build is from lenovo, similar to ideapad but more 'value' market [13:44] zyga, not any samsung by chance... well iirc some people had fun with lenovo too [13:44] ok [13:44] hehe, no :) [13:45] cking, do you remember... I thought someone had efi pain with some x something... [13:45] (it's running efi + signed kernel) [13:45] ubuntu-bug keeps printing dots [13:46] smb, I'm trying to recall, but I can't think of it at the mo [13:46] I can suspend that and poke around in /sys/ if you want [13:46] well if its done in a seperate thread it can do that for a while... [13:48] zyga, Right now I could not say what to look for. [13:48] ok [13:48] I'll let it finish [13:48] and get ready for the first session [13:49] afaik none of the team was having similar issues... except ... cking I think your sdp completely imploded for other reasons [13:49] smb, yep, it lost it's mind and disabled auto CSM for some reason [13:50] 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] is that a bug in ubuntu-bug that needs reporting against ubuntu-bug? [13:51] cking, I'd rather not... the world may recurse for eternity [13:51] -ETOOMANYLEVELSOFINDIRECTION [13:53] -ETOOMANYWORDSMAKESITHARDTOREAD [13:53] although CamelCase doesn't look unix enough [13:53] heh [13:54] yeah [13:54] I think it's dead jim === kentb-out is now known as kentb [15:53] bjf, is the proposed kernel cadence going to be discussed in the rolling release session coming up? [15:54] brendand, which cadence are you referring to? the sru cadence (not changing) or the daily, rolling cadence? [15:56] 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] Moving here from the room channel: would a "return true" autopkgtest in OpenAFS be reasonable, just to check compilability? [16:42] Will it get run against the PPA, and is there a way to sign up for notifications of test failures? [16:46] 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] I think my question is more "how does that test run against the PPA kernel before it gets pushed to production" [16:54] (I'm talking with the folks who did the most recent OpenAFS SRU) [17:31] 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] 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] 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] apw: but it seems like half of all new kernel updates make it not build [17:54] geofft, indeed, but the logical thing is to be aware of when it changes and to test it at those times [17:55] apw: OpenAFS itself doesn't change. It's the lack of stable kernel API that breaks it [17:55] (It's GPL-incompatible free software, the situation sucks all around) [17:55] geofft, right the kernle doesn't offer one of those, never has [17:55] yeah [17:55] apw: I'm not asking for the kernel to start offering one [17:55] 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] and approximately no chance of breaking it in a way that it compiles but doesn't run. [17:56] 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] geofft, if you had one of those you could run it against the kernels automatically as they appear in the PPA [17:58] and be apprised if there were issues [17:58] sure, I can happily set up a local VM or something to do this. [17:59] 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] or adding more load to my organization's buildserver, or whatnot [18:00] it seems like the right place to do this test is with autopkgtest infrastructure, since it exists. [18:01] 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] geofft, well if it was approved to hold the kernle for that that the britney runs would nominally hold it in -proposed [18:27] i am unsure that britney yet holds for autotest failures, but that is the plan [18:27] geofft, though if someone was activly maintaining openafs against the unstable kernel PPA we should never hit this issue [18:28] 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] 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] 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] 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] But occasionally things fall through the cracks. [18:38] 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] 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] sure [18:39] geofft, though you need a VM or similar to install the kernel for dkms packages annoyingly [18:40] there is packaging for building a module-assistant kernel, so maybe that can be abused to do a PPA test compile. [18:40] something which did that on a regular (weekly perhaps) and reported back would be pretty easy to put together i recon [18:40] Can I set up a PPA that will automatically rebuild when the kernel PPA gets changed? [18:41] geofft, for dkms that doesn't help cause building the package does not trigger dkms to run [18:41] acdtually you just want a machine which has the kernle ppa attached and then just updates regularly [18:41] if the update fails that is likely cause of openafs failing to build [18:41] yeah... is that what other people who care about DKMS do? I guess that's fine. [18:42] i am unsure if they do it automatically, but that is the process in large part [18:55] 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] I was under the impression that even SLUB uses slab structs, so I was really confused that this was the case [18:56] is that an expected omission? [20:06] * ppisati -> real life [20:26] * rtg_ -> EOD === henrix is now known as henrix_ [20:48] smaresca, it is not clear that it does use it [20:59] apw, i agree..I've been trying to find some sort of confirmation one way or the other [21:00] check include/linux/mm_types.h [21:00] there is shows the slub info overlaying the slab_page pointer, the slab * type pointer [21:00] you don't use both at once [21:08] 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] smaresca, right they are 'slabs' in the sense they are typed memory pools [21:09] smaresca, they are not slabs as in controlled by struct slab. they do i believe have a slab_info associated with them [21:18] apw, thanks for clearing that up for me [22:38] 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] sorry for disappearing, had a system restart to put through [23:22] 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] 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 === kentb is now known as kentb-out === kamalmostafa is now known as kamal