[00:23] apw: this was on the chromebooks I am hearing if the machine has 2G or under [00:24] so yeah not that low [03:00] apw: Finally, a build we can all be proud of === smb` is now known as smb [09:47] * ppisati feels a bit sick today... [10:14] ppisati, sounds bad ... your football team lose ? [10:14] apw: yes, last weekend, but i don't think it's related [10:15] normal flu, i think i'll survive.. hopefully... :) [10:21] cking, I tested lxc with kernel 3.5.0-18.29-lp1065434, transfered data over different links, shutdown/restarted the container multiple times successfully while I can reproduce the bug reliably with the version of the kernel in 12.10 [10:22] cking, it sound like it resolves the "waiting for lo to become free" issue [10:22] jibel, so that looks like a reasonable fix then :-) [10:23] bug #1065434 [10:23] Launchpad bug 1065434 in linux (Ubuntu) ""unregister_netdevice: waiting for lo to become free. Usage count = 1" after LXC container shutdown" [High,Incomplete] https://launchpad.net/bugs/1065434 [10:24] jibel, if you can update the bug report and I will SRU it [10:25] cking, sure, I'll update it with the tests I did. thanks for the fix! [10:43] infinity, still awake? [11:19] I am seeing video/graphics degradation in kvm on raring-host&guest https://launchpadlibrarian.net/122917285/lightdm-grey-boxes.png [11:20] * xnox ponders of any good ways troubleshooting that [11:29] henrix, hey ... i assume it is you doing the puloads for the current SRU cycle ? when might i see a linux-lts-quantal [11:29] apw: yep, i am working on that. [11:29] henrix, great indeed [11:30] apw: the quantal packages are pretty much ready for -proposed [11:30] apw: after they are in proposed, the bot should create the bug for the -lts. [11:31] henrix, gotcha [11:31] apw: i may start working on the -lts today [11:31] henrix, cool, if you could start with the Q backport out of all the derivatives, as it will help expedite secure-boot testing in P [11:32] apw: ack [11:32] apw: ah! problem is that we still have a few kernels pending from previous cycle. and linux-lts-quantal is one of them [11:33] henrix, what is holding it back ? [11:51] jodh, Would you know from the top of your head how I would make an upstart job depend on a certain device? "tty-device-add DEVICE=hvc0" is not complaining, but neither really seems to not work if I change the name to something that does not exist... [11:54] smb: that should be "tty-device-added DEVNAME=hvc0" I think. [11:54] jodh, Ah ok, likely DEVNAME to be what udevadm test prints out [11:55] smb: correction, it should be "tty-device-added DEVNAME=*hvc0" (asterisk added) [11:59] smb: the need for the asterisk being show by the output of... [11:59] smb: awk 'BEGIN{RS="";ORS="\n\n"}; /UDEV.*\[/ && /ACTION=add/ && /SUBSYSTEM=tty/ { print; }' /var/log/udev [12:00] jodh, Ah there is that log already. I suppose it is the same ass the adevadm call shows. I think it is working now. Thanks. [12:06] apw: did you already create a config diff matrix among flavours for R? [12:08] ppisati, hmmm, not refreshed it since UDS, but which flavour you interested in [12:08] apw: ah, the uds one is good [12:08] apw: where is it? [12:09] jodh, What confused me was some statement that the format would be something like -device-. (Or I did not read well enough) And then not realizing that "service x start" probably overrides any start on magic [12:09] ppisati, http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/UDS.html [12:10] but bear in mind it has not derivates as we do not have any at even a slightly similar level [12:10] * apw will try and get a 'current' one done in a bit [12:13] smb: good catch! The man pages are incorrect on that point! I'll get them fixed... [12:14] infinity, So just to let you know that I have a newer version of the xen package for raring in zinc:~smb/4review which is adding some of the things agreed to at uds and some cves. If you would review and sponsor that you may ignore the currently uploaded one in proposed. [12:14] jodh, Ah, then at least something good came from my failure. :) [12:21] apw, I see that linux 3.7.0-0.5 was accepted finally. I presume that means ppc et al are now consistent and we can upload at will ? [12:22] rtg, indeed it should mean exactly that ... phew [12:24] apw, the regression I was chasing yesterday (PERCPU allocation failure) was actually introduced between 3.5-rc1 and 3.5-rc2, so I think we're clear to upload 3.7-rc5 later today. Do you have anything you want in the upload ? [12:25] ogasawara is working on some haswell crack, but I don't think its ready. [12:25] and it might be for Quantal anyways [12:26] rtg, i think everything i wanted is on there, just be aware there are changes in there for the common headers package (for ppc) which should not change a think on master, but just be aware [12:26] s/think/thing [12:26] apw, this one ? "UBUNTU: [Config] Use SRCPKGNAME as prefix for indep linux headers package" [12:27] rtg, yeah, in theory it is a noop on master, and a quick review still looks ok, and i have tested it, but it was ported to your cleanup of that code [12:28] but just worth checking those in your test build [12:28] apw, yeah, I looked at it yesterday. seems fine [12:44] * henrix -> lunch [13:59] apw, please review ubuntu-raring-signed. Is there anything one needs to do besides just uploading it ? [14:06] rtg, that looks fine, other than tagging it, uploading it should do the trick; it will depwait on the main binaries [14:07] apw, OK. I was waiting to tag it until after your review [14:07] rtg, guessed as much indeed [14:07] literally making sure the version number is right, you found 'update-version' i assume [14:08] apw, um, no. I used 'dch -i' [14:08] there is a scripty to copy the right version from the master repo: ./update-version ../ubuntu-raring stylee [14:10] apw, I backed up one commit and ran update-version. It did the same as I did )by hand), so I guess I got it right. [14:10] rtg, indeed, it looked similar enough i assumed you had used it :) [14:11] it does emit the tag commands etc for you to make life easier [14:11] apw, oh well, I'm used to doing those by hand anyways. tagged, pushed and uploaded. [14:11] rtg, thanks [14:11] * rtg will be back on in a bit [14:48] smb, hey [14:48] arges, hi [14:49] smb, I see that you fixed pad.lv/322737 a long time ago. I think bug 1070182 might be related since it is the same network driver. [14:49] Launchpad bug 1070182 in linux (Ubuntu) "8086:10f5 Can't connect to the network through a wired connection - Network dialog shows "Wired Cable unplugged"" [Medium,Confirmed] https://launchpad.net/bugs/1070182 [14:49] I did... must be a longer while [14:49] smb, I think you made a sauce patch to fix this then, should I try and reapply the sauce to the newer version to see if it fixes the issue? [14:50] arges, maybe you also could just refresh my memory with the subject of the patch I did and a release [14:51] smb, sure * SAUCE: Add support in e1000e for a couple of ICH10 PCI IDs [14:51] smb, added support for intel 82567LM [14:51] That probably was hardy... [14:51] oh yea 8.04 [14:51] and usually just adding pci ids [14:53] smb, so do I need to fix this in linux-ubuntu-modules? or is this in linux ? [14:53] I think back there it was lum, which do not exist for any recent kernel [14:54] yes [14:54] And remember that only adds pci ids [14:54] not sure whether that matches the problem of that other bug [14:54] smb, the error seen in dmesg is exactly the same [14:56] Ok, so might be just not attaching then... [14:57] arges, Though the e1000e driver is loading. [14:58] henrix, I assigned bug #1072163 to you. Please see if you can drive it to some sort of conclusion. [14:58] Launchpad bug 1072163 in linux (Ubuntu Raring) "Lack of fsam7400 kernel module in quantal" [Medium,In progress] https://launchpad.net/bugs/1072163 [14:58] So it looks like the pci id would be causing the probe but some checksum is not what is expected. [14:58] rtg: ack. i've seen it before, but couldn't find too much time to dig into it [14:59] rtg: basically, we don't want to fix it, i.e., we don't need that driver [14:59] rtg: there's an upstream driver with same functionality (actually, there are 2), and with the same prob [15:00] smb, #define E1000_DEV_ID_ICH9_IGP_M_AMT 0x10F5 <--- yea its in the driver [15:00] henrix, I'm fine with that. mark it invalid or won't fix with an appropriate explanation. [15:00] rtg: ack. i'll try to focus on that bug later today (or, more likely, tomorrow) [15:18] rtg, http://patchwork.ozlabs.org/patch/197479/ [15:21] smb: hey, could you give your opinion on whether bug 1078305 should be deemed a kernel (bridging) bug, or just a legitimate quirk which libvirt should work around? [15:21] Launchpad bug 1078305 in libvirt (Ubuntu) "source IP address of broadcast packets gets rewritten when using NAT" [Undecided,New] https://launchpad.net/bugs/1078305 [15:25] hallyn, not quickly I'd need some time to understand the thing [15:38] smb: ok. i just don't want to work around something in libvirt if it's actually a kernel bug. i'll comment in the bug for nwo. [15:52] hallyn, ok ... we really need to have confirmation of the network topology, and the iptables rules in use here [15:53] 337 20220 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 [15:54] 31 2296 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 [15:54] 1 40 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24 [15:54] hallyn, so if his setup is default (ie matches mine) then i think it is doing what these rules tell it [15:58] apw: for some reason i'm having a really hard time reasoning about this bug this morning [16:00] hallyn, could we rewrite these instead of using !192.168.122.0 ... so like -out !virbir0 -in virbir0 or something [16:01] smb, iptables -vnL -t nat [16:06] hallyn, have you got a test rig for this ? [16:06] apw: no [16:06] apw: been out a few days, just saw this bug sitting there today [16:06] apw: but, his observatiosn seem actually backward, right? [16:07] the values are NOT masqueraded when usin 192.168.122.0, but are when using 0.0.0.0 [16:07] uh, s/0/255/g [16:07] hallyn, well from what i can see the kernel is doing what was asked, if you use 255.255.255.255 as a destination then it must be rewritten [16:08] hallyn, right and that matches his complaint, that if you send to 192.168.122.255 then no rewrite occurs [16:08] and if you use 255.255.255.255 then you need to do masquerade whcih will rewrite the source address [16:08] the rules are just not right in that sense [16:09] rtg: you have a 'start new release' commit on ubuntu-precise-meta. was there something you wanted to get into this package? [16:10] rtg: ah, its a commit from 19th oct, so you probably don't remember about it anymore :) [16:11] rtg: actually, it was on precise-lbm, not -meta [16:12] apw: ok, thx. i'm not sure how easy it is to fix the way you suggest (as it's somewhat hardcoded in libvirt), but i'll mark as not affecting kernel :) [16:12] hallyn, am playing with some rules now to see if i can even write what we want written [16:13] hallyn, well in theory you can make the bridge outside of libvirt and use that prebuilt one [16:13] hallyn, and it is possible they are just wrong and should be fixed for everyone [16:17] apw: yes, i think it's wrong upstream, if that's what you mean. [16:17] sudo iptables -t nat -I POSTROUTING 1 -s 192.168.122.0/24 -d 255.255.255.255 -j RETURN [16:17] hallyn, i would be interested to know if the above also sorts it out [16:18] i'll ask in the bug [16:28] apw, what model N7 did we get? the 16GB one ? [16:29] rtg, i believe so yes [16:29] its on the end of the box if that helps [16:29] apw, you mean the box I left in Denmark ? [16:29] yeah that one. mine cirtainly is 16 [16:38] rtg, ok ... i am seriously considering reinstating the common headers package for -lowlatency so disconnect it from master ... else lack of updates for it prevent linux from moving to -updates [16:38] rtg, now that we have the template with ppc its pretty easy to do [16:39] apw, so that would make it the same as ppc , right ? [16:39] fully decoupled ? [16:39] yes, that indeed [16:39] go for it [16:39] apw, the N7 rootfs image is giant. I'll likely be at it for awhile [16:40] rtg, that sucks [16:53] rtg your -1.6 upload is dropping depwait on libaudit-dev [16:53] apw, which is a tools build dependency [16:54] what do you mean 'dropping' ? [16:54] rtg, i mean it doesn't exist so linux is not building [16:54] E: Unable to locate package libaudit-dev [16:55] apw, ugh, wtf ? I'm sure I installed it. [16:55] Raringreleaseon 2012-10-18universelibs [16:56] if you could read that you'd see its universe, so needs an MIR for the build to succeed [16:56] apw, ah, shit [16:57] apw, I think x86 perf tools will build without it. lemme check [16:57] * apw muses as to why all his pastes get shafted like that [17:20] * ppisati -> EOD [17:30] is there some reason there are no mainline kernel builds for precise past 3.4 on http://kernel.ubuntu.com/~kernel-ppa/mainline/ ? [17:37] SpamapS, 'cause we started using the quantal config for 3.5, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-quantal/ [17:43] rtg: ah ok, so you'd expect the latest 3.6.6 to work on precise? [17:43] SpamapS, I see no reason why it wouldn't [17:43] rtg: I had thought there were firmware changes in quantal [17:44] SpamapS, there were for some devices. I've packaged those updates with the distro backport, but mainline doesn't have them [17:44] gotchya [18:02] smb: I can poke at that today, sure. [18:33] * rtg -> lunch [18:58] * henrix -> EOD [19:05] * apw wanders somewhere more comfortable ... === ayan_ is now known as ayan [20:10] bjf: Is shankbot just lagging on updating https://bugs.launchpad.net/ubuntu/+source/linux-lts-backport-oneiric/+bug/1068230 or has something gone pear-shaped with the rebase promotion logic, perhaps? [20:10] Launchpad bug 1068230 in Kernel SRU Workflow "linux-lts-backport-oneiric: 3.0.0-27.44~lucid1 -proposed tracker" [Undecided,In progress] [20:11] infinity, it's waiting on oneiric linux bug to be promoted to updates [20:11] herton: Oh, that's the wrong logic, IMO. It should just wait on the promotion tasks being set. [20:12] herton: Otherwise, I'll just pre-empt the bot and promote without it setting the tasks, cause I'm not going to do this in two passes. :P [20:13] infinity, I can change that, my understanding was that we wanted that behaviour, at least in case there was some dependencies between the binaries, which isn't the case [20:13] herton: The only place where there's actually a dependency between binaries is lowlatency->master (which just got fixed to no longer be true in raring). [20:14] herton: But even then, if all the promotion tasks are set together, one can assume that the packages will also get promoted together. I don't tend to make more work for myself when I don't have to. ;) [20:14] np, I'll fix the bot later to just wait for confirmation of the tasks instead of the current behaviour [20:15] Shiny, thanks. [20:15] We can test it next cadence. This time, I'll just preempt the bot and DTRT. [20:15] ack [20:18] rtg, ogasawara, This was just assigned to the canonical kernel team: bug 1078861 [20:18] Launchpad bug 1078861 in ubuntu-nexus7 "Rebase kernel to the branch shipping with Android 4.2" [Medium,New] https://launchpad.net/bugs/1078861 [20:19] jsalisbury: I'll assume jani just opened that as a tracking bug and will do the work there [20:20] ogasawara, ahh, ok [20:20] ogasawara, I'm having a look [20:21] ogasawara, bjf: by the way, I just pushed the lts-backport-raring branch to precise [20:21] rtg: ack [20:47] rtg, so does that imply there is an upload happening real-soon-now ? will this be happening in the x-swat ppa like quantal? [20:47] bjf, I'm assuming so, though the PPA name is disingenuous [20:49] maybe there should be a "hardware enablement" ppa === yofel_ is now known as yofel [20:50] bjf, I'll upload later tonight and also send a note to bryceh asking about PPA naming. Maybe they want to start a whole new one. [21:03] rtg, ack [21:11] * rtg -> EOD [21:55] herton: Do you know who's responsible for the regression-testing task on https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1068573 ? [21:55] Launchpad bug 1068573 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.5.0-1604.6 -proposed tracker" [Medium,In progress] [21:56] herton: Would be nice to get that one done and released before starting all over again with the new Q kernels in the PPA. [21:58] infinity, not sure, but I think our QA was doing the testing on armadaxp kernels, bjf ikepanhc ^ [21:59] (Not that it's critical that it be released before we start on Q, it just gets a bit harder to keep it all straight when the flavours are out of sync) [22:00] infinity, QA is doing it. i know they were running into some issues today with HW