[00:15] <infinity> herton: Oh, you could do it too, sure. :)
[01:35] <infinity> herton: How often does shankbot poll the PPA?
[02:16] <bjf> infinity, once an hr.
[02:18] <infinity> bjf: Thanks.
[02:49] <infinity> bjf: Hrm, I'm missing some subtle nuance then, cause linux/hardy has been built and published for well over an hour, but the bug has no promote-to-proposed confirmed.  Weird.
[03:02] <infinity> bjf: And it finally got around to it.  Maybe I'm just impatient.
[03:17] <tyf> if I am using the linux-generic-lts-quantal kernel in Precise, am I able to use any of the lbm-cw packages in the repository? are the kernel modules compiled specifically only for other kernel versions?
[03:38] <Sarvatt> tyr: no you can't, are you using linux-backports-modules-cw-3.6-precise-generic? that's the only one newer than the lts backports kernel
[03:38] <Sarvatt> the lbm-cw packages are compiled against 3.2 kernel updates each time
[03:51] <tyf> so there's none that are compiled against kernel 3.5?
[08:50]  * apw yawns
[11:24] <apw> smb, there is no good reason to not build the DM delay and flakey personalities is there?
[11:27] <smb> apw, Hm, don't think really. They become modules I suspect and then will only be used if someone actually builds a target with them. Which pretty much is another painful and manual process.
[11:27] <apw> smb, that fits my thinking too, thanks
[11:38] <smb> tjaalton, Not sure how/where/what exactly to report but I noticed on my sdp that using the quantal X stack and kernel on Precise running from a SSD is booting pretty fast and comes up ok but when rebooting or shutting down I see a dialogue telling me the system would only run in low-graphics mode (and it definitely was not doing that)
[11:39] <apw> smb, so you see a new X server with "you are in low graphics mode", doe that have to be acknowledged or does the reboot/shutdown complete
[11:39] <tjaalton> smb: I guess it's plymouth's fault
[11:39] <smb> apw, It does go on but if you are quick you could confirm the first screen
[11:40] <apw> smb, and do you get the 'dots' if you confirm it ?
[11:40] <tjaalton> it has some hardcoded checks for 'i915'..
[11:40] <smb> apw, No, I get the second dialogue asking me what "other" config to use. And I was not quick enough to click before that was shot down
[11:41] <apw> smb, ok :)
[11:42] <smb> tjaalton, We had been wondering whether X may go away too quickly because other people with that combo but slower disks do not see that
[11:42] <smb> tjaalton, Or I did something wrong when pulling the new stacks...
[11:43] <apw> smb, i think file a bug against plymouth and see what happens
[11:43] <apw> smb, and mention it to slangasek
[11:43]  * smb thinks what happens will be a response saying "you are running crack"
[11:44] <smb> But anyway, I will try
[11:44] <apw> smb, it is going to be a supported combination ...
[11:45] <tjaalton> right, and I haven't seen that bug with quantal
[11:45] <tjaalton> though I sometimes get the same dialog when it boots up
[11:48] <apw> smb, any idea whether it makes sense to have CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES turned on
[11:49] <smb> apw, Err, not really have an idea what that would be...
[11:53] <smb> apw, Sounds very useful for crashing your system when unaware but interesting create unusual setups...
[11:58] <apw> smb, yeah, i think as it is on i will leave it alone ... even if it is a bit scarey
[12:00] <smb> apw, True and probably there are more evil things that you can do when you can modify the kernel command-line...
[12:07] <smb> slangasek, tjaalton I filed bug 1086345 for the x-lts-quantal oddity I see. If there is more I should do, please let me know
[12:07] <ubot2> Launchpad bug 1086345 in plymouth (Ubuntu) "Quantal-LTS-stack: Showing low-resolution screen on shutdown/reboot" [Undecided,New] https://launchpad.net/bugs/1086345
[12:19] <apw> cking, i assume we have SLUB_DEBUG turned on for a reason ... 
[12:20] <cking> apw, hrm, can't recall exactly when we enabled that
[12:21] <rtg> apw, ogasawara: pushed -rc8. build testing.
[12:23] <cking> apw I would be more concerned if SLUB_DEBUG_ON was enabled, that turns it on by default
[12:24] <apw> cking, SLUB_DEBUG on, i believe _ON is off
[12:25] <cking> apw, if we are concerned about the performance penalty of SLUB_DEBUG I can look at that
[12:25] <apw> cking, i was more interested to know it was a concious decision
[12:26] <cking> apw, it wasn't a conscious decision that I can recall
[12:26] <apw> then ... low low on your list, perhaps test it
[12:27] <cking> apw, if it's not on for previous releases we should disable it for the moment I reckon
[12:32] <herton> cking, apw, I believe it has been always enabled on our config (SLUB_DEBUG), it's helpful to debug some memory corruption cases passing slub_debug on commandline, like double frees, I recall it being useful once to me
[12:32] <herton> but not sure about the performance impact, if it has some then probably should be disabled
[12:32] <cking> in which case, let me assess the overhead, if its is unnoticeable then it's a useful to have feature
[12:33] <apw> cking, herton, works for me
[12:34] <xnox> what is the procedure to get an account on kernel.ubuntu.com ?
[12:38] <rtg> xnox, beg #is via an RT ticket.
[12:39] <xnox> rtg: sounds like a good plan =)
[12:39] <xnox> thanks.
[12:50] <herton> rtg, that commit you mentioned yesterday (bc78c57), do you saw a problem it fixes? I can forward to stable
[12:53] <rtg> herton, no specific problem. I was looking at backporting TRIM support for md arrays and noticed that its likely a good bug fix.
[12:53] <herton> rtg, ok, will ask for inclusion
[13:06]  * henrix -> lunch
[13:14]  * apw wanders out to get some fresh air
[13:24] <Konstigt> is there any ppa with 3.7 for 12.10? or are rarings kernels OK on 12.10 perhaps?
[13:25] <tjaalton> smb: thanks, subscribed
[13:36] <rtg> Konstigt, there are raring kernels for 12.04 at https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport
[13:37] <ogasawara> rtg: I was thinking we should upload today.  lemme know if your test build was successful and I can test on some kit here and then prep the upload.
[13:41] <rtg> ogasawara, I've got x86en built on tangerine. lemme stash it on zinc in a sec and I'll give you an URL
[13:42] <henrix> kees: i'm getting a build error on arm platforms for precise regarding your "seccomp: forcing auditing of kill condition" commit
[13:42] <henrix> kees: https://pastebin.canonical.com/79684/
[13:42] <henrix> kees: any suggestion?
[13:43] <rtg> henrix, you might be a bit early in the day for him
[13:43] <henrix> rtg: ah, right :)
[13:44] <rtg> ogasawara, cking, apw: http://kernel.ubuntu.com/~rtg/3.7-rc8.1/
[13:44] <ogasawara> rtg: ack
[13:44] <cking> rtg, want me to exercise this on a bunch of machines?
[13:45] <rtg> cking, please
[13:45]  * cking rummages around for some H/W
[13:57] <henrix> does anyone know the rational for not having CONFIG_AUDITSYSCALL on arm configs?
[13:57] <henrix> i believe this is what is causing the build failure
[13:57] <rtg> ppisati, ^^
[13:58] <ppisati> henrix: hold on
[13:58] <henrix> ppisati: thanks
[14:01] <ppisati> henrix: config AUDITSYSCALL bool "Enable system-call auditing support" depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH)
[14:02] <ppisati> henrix: ARM was not supported back then
[14:02] <henrix> ppisati: heh, ok. i should have checked that myself :)
[14:02] <henrix> ppisati: thanks.
[14:24] <cking> rtg, kernel seems good on atom n450, ivybridge + sandybridge H/W, will exercise it on some AMD kit now
[14:26] <rtg> cking, ack. thanks
[15:02] <rtg> ogasawara, cking,apw: I'm gonna have to respin Raring with arges ticket_spinlock (fsnotify) patches.
[15:02] <cking> rtg, tested on a bunch of older kit too (AMD, etc) works fine, boots, S3, S4, audio, network
[15:02] <cking> ah, more to test :-)
[15:02] <ogasawara> rtg: ack
[15:02] <ogasawara> rtg: previous build tested fine on my kit here
[15:03] <apw> rtg ack
[15:03] <rtg> cking, yeah, the ticket_spinlock tests might require more manula USB plugging, etc
[15:03] <cking> ack
[15:03] <arges> rtg, there is a script that reproduces the issue easily. I've tested this set of patches with that but would like to do more testing
[15:04] <arges> rtg,  cking : in addition do some performance tests if we can.
[15:04] <cking> arges, such as?
[15:04] <arges> cking, not really sure : ) have to think of something fs notify related
[15:05] <janimo> rtg, I am removing the ubuntu nexus tree from its former location in hwe/ , no objections right?
[15:05]  * janimo goes to update the wiki as well
[15:07] <rtg> janimo, go ahead
[15:13] <apw> arges, the point is that fsnotify is in the way of _all_ operations if its enabled
[15:13] <apw> arges, so if you ask for "read/write" notification for instance
[15:13] <apw> which isn't common but is possible
[15:15] <arges> apw, yea I think I can look at the test case, and try to write something
[15:15] <arges> apw, start time, inotify_add_watch , access file/directory, inotify_rm_watch
[15:18] <apw> yeah
[15:18] <apw> arges, with multiple read/writers in there
[15:32] <rtg> ogasawara, cking, arges, apw: http://kernel.ubuntu.com/~rtg/3.7-rc8.2/ for the fanotify version
[15:32] <arges> rtg, downloading
[15:32] <ogasawara> rtg: ack
[15:34] <ppisati> brb
[15:36]  * rtg relocates...
[15:42] <Konstigt> rtg: thanks but I have 12.10/Quantal
[15:43] <rtg> Konstigt, you can still install the kernel debs from either archive, but you won't get automagic updates via meta packages.
[15:48]  * ogasawara back in 20
[15:49] <Konstigt> rtg: aha, so the kernel isn't really bound to the release and vice versa. so then just downloading the needed files from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc8-raring/ should work.
[15:49] <rtg> Konstigt, yep
[15:50] <rtg> the 'raring' part simply means that it was built using the raring config. I think all mainline are built using the Precise toolchain.
[15:50] <apw> they are built using the previous LTS' tool chain
[15:50] <rtg> so, either Lucid or precise
[15:50] <apw> yes
[15:51] <Konstigt> thanks
[15:51] <apw> (in theory it would also use hardy, but ... i don't think we every make things that old)
[15:52] <jsalisbury> **
[15:52] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:52] <jsalisbury> **
[15:52] <apw> its tuesday _again_ ?
[15:53] <jsalisbury> heh
[15:53] <smb> apw, Its _that_ late again, too
[15:53] <apw> seemingly indeed
[15:55] <jsalisbury> bjf, smb, it looks like bug 1034099 is due to commit ffaf6a1e73719e0250fce7b52015187180a77fe9 
[15:55] <ubot2> Launchpad bug 1034099 in linux (Ubuntu Quantal) "Kernel panic with ulatencyd on kernel 3.2.0-29-generic" [High,In progress] https://launchpad.net/bugs/1034099
[15:55] <smb> jsalisbury, Yeah, somehow I stopped worrying when I saw that...
[15:57] <jsalisbury> smb, is that commit something we can revert ?  If so, I can submit an SRU request.
[15:58] <smb> jsalisbury, Gosh I should read better (commit != comment)...
[15:58] <jsalisbury> smb, its this SAUCE:
[15:58] <jsalisbury> commit ffaf6a1e73719e0250fce7b52015187180a77fe9
[15:58] <jsalisbury> Author: Stefan Bader <stefan.bader@canonical.com>
[15:58] <jsalisbury> Date:   Tue Jul 3 15:01:58 2012 +0200
[15:58] <jsalisbury>     UBUNTU: SAUCE: sched: Fix race in task_group()
[16:00] <smb> Oh f**k, I would not want that reverted but there was something messed up by it and I really cannot say right now what exactly it was
[16:00] <cking> rtg, that kernel works OK on a bunch of laptops, atom, sandybridge, ivybridge, amd64.  however my sharkbay desktop gets video corruption and seems to lock up (tried it now 4 times)
[16:01] <rtg> cking, does the kernel in .1 have teh same issue ?
[16:01] <cking> rtg, yep
[16:01] <rtg> cking, ok, so at least it wasn't introduced by the fanotify patches
[16:01] <cking> I didn't get around to test it until just now 'cos I was exercising it on a bunch of other tests
[16:02] <bjf> cking, sharkbay is haswell?
[16:02] <rtg> cking, does the sharkbay work with ogasawara's Oneiric haswell pile ?
[16:02] <bjf> cking, i don't think all of ogasawara's haswell patches are in raring
[16:02] <jsalisbury> smb, the bug affects precise and quantal.  I'll find out if it also affects raring.
[16:02] <ogasawara> rtg: all the haswell patches I pulled won't land until 3.8 opens
[16:03] <cking> bjf yes, rtg no, but it used to work on earlier raring kernels
[16:03] <bjf> huh
[16:03] <rtg> indeed, huh.
[16:03] <rtg> I'm gonna ignore it for now
[16:03] <cking> sorry, that was not clear
[16:04] <cking> no, as in I never sucessfully tested this box last week, so no, I am not sure, but it was booting fine on earlier 3.7 kernels
[16:04] <smb> jsalisbury, I thought I had someone with a boot oops because of that and thought at that point some additional upstream change was found... 
[16:05]  * cking wonders if this is going to be the last -rc for 3.7
[16:06] <rtg> cking, mebbe
[16:06] <smb> jsalisbury, Do we have this one pulled: commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12
[16:06] <smb> Author: Mike Galbraith <efault@gmx.de>
[16:06] <smb> Date:   Mon Dec 3 06:25:25 2012 +0100
[16:06] <smb>     Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
[16:07] <smb> ... stupid question as that was in the precise tree..
[16:07] <bjf> smb, nope
[16:12] <smb> Hm, ok seems something from 3.7-rc8...
[16:14] <smb> jsalisbury, So can we instead try the other revert which should be queued for stable afaics
[16:15]  * smb curses and rushes over to the other irc meeting
[16:17] <jsalisbury> smb, so put your patch back and then apply fd8ef11730f1d03d5d6555aa53126e9e34f52f12
[16:17] <smb> jsalisbury, Yeah, which reverts the other thing actually
[16:17] <jsalisbury> smb, got it.  thanks
[16:24] <jsalisbury> smb, I ran into an issue when cherry-picking commit: fd8ef11730f1d03d5d6555aa53126e9e34f52f12
[16:24] <jsalisbury> smb, git diff says:
[16:24] <jsalisbury> * Unmerged path kernel/sched/auto_group.c
[16:24] <jsalisbury> * Unmerged path kernel/sched/auto_group.h
[16:25] <jsalisbury> smb, I can manually revert commit 800d4d3 without an issue
[16:25] <rtg> jsalisbury, clean your tree first ?
[16:25] <jsalisbury> rtg, I did a fresh clone
[16:25] <jsalisbury> of the precise tree on tangerine
[16:25] <smb> jsalisbury, Oh well, could be because Peter was bored and renamed most of the files about 3.5
[16:26] <smb> so things moved from kernel into kernel/sched
[16:27] <jsalisbury> smb, ahh.  Can I just do the revert of commit 800d4d3 myself, and have that tested?
[16:27] <jsalisbury> smb, Or I can just fix things up after the cherry pick
[16:27] <smb> wonder whether the lazy fixup of git format-patch <revert>, git am <upstream> -> fail , patch < <export> works
[16:29] <smb> jsalisbury, just reverting the change would work as well for testing. Mainly its to have the upstream changelog (but that could be done later)
[16:29] <jsalisbury> smb, ack
[16:34] <apw> rtg, remind me the nature of the USB_OTG badness when enabled on x86
[16:39] <rtg> apw, I think its because there _isn't_ an OTG on x86 platforms.
[16:41] <infinity> Oh hey, do I get to drop my UAPI hacks from glibc after the next linux upload?  Did that land?
[16:42] <rtg> apw, this must be for you? ^^
[16:42] <infinity> Either of you. :P
[16:42] <infinity> rtg: I expect you to know every line of the every kernel rc.  Sheesh.
[16:45] <apw> UAPI: strip the _UAPI prefix from header guards during header installation
[16:45] <apw> infinity, thats what you are hoping for i believe 
[16:46] <apw> v3.7-rc8~27^2~6
[16:46] <apw> which is in ^^ .... ie in -rc8 and our next upload
[16:46] <infinity> apw: That'd be the one.
[16:47] <smb> bjf, sconklin <arosales> smb: is kernel team going to be using UTAH in their testing?  (perhaps smb can provide some more context)
[16:48] <ogasawara> rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084640
[16:48] <ubot2> Launchpad bug 1084640 in linux (Ubuntu Raring) "linux: 3.7.0-5.13 -proposed tracker" [Medium,In progress]
[16:48] <ogasawara> rtg: in the future, you'd just run create-tracking-bug or whatever it's called and it'll shove the changelog entry for you
[16:50] <sconklin> smb: not in our team testing environment for the foreseeable future. the QA team does theirs differently, and may use it for their kernel tests
[16:50] <apw> sconklin, i thought we had like a shim between utah and our tests so we use the same tests in both environments; right?
[16:51] <apw> (but not using it indeed)
[16:52] <sconklin> apw: the same tests can be run in both environments, all the kernel tests are under autotest client. Different ways of calling them are used in QU and out team
[16:52] <bjf> smb, in a word, no
[16:53] <smb> bjf, Ok, I can pass this on next week. :)
[16:53] <smb> Or... hggdh ^
[16:53] <bjf> smb, is there some feature of utah that would make me want to do so ?
[16:53] <smb> bjf, I am merely the messenger here. No personal interest really in doing one or the other
[16:53] <bjf> smb, should i talkto arosales directly?
[16:54] <smb> bjf, Actually it was hggdh asking through arosales
[16:55] <smb> bjf, Or I ping you before the next server-team meeting to join the fun on irc. :)
[16:55] <bjf> well, that's just damn odd
[16:56] <bjf> smb, not sure i can handle that much fun .. but sure
[16:57] <smb> bjf, Maybe it brings a bit of the scary happy face back. :)
[16:57] <bjf> lol
[16:57] <rtg> apw, both raring branches pushed. I'm just gonna wait to upload until my armhf test build is done.
[16:58] <rtg> about 30 minutes I expect
[16:58] <apw> rtg, ack
[17:18]  * ppisati goes out for a bit
[17:24] <hallyn> rtg: is raring master-next supposed to build right now?
[17:24] <hallyn> (from last night actually) 
[17:24] <rtg> hallyn, yep. are you having issues ?
[17:25] <rtg> hallyn, just pushed -rc8 this AM
[17:25] <hallyn> yeah seemed to complain about a missing file,
[17:25] <hallyn> ok i'll merge that, thanks
[17:25] <hallyn> far prefereable anyway
[17:25] <rtg> hallyn, hmm, I've been building it pretty regular
[17:26] <hallyn> rtg: I got gcc: error: lib/oid_registry.c: No such file or directory
[17:26] <rtg> hallyn, in a PPA, right ?
[17:27] <rtg> apw and I have encountered that same error. restarting the build makes it go away.
[17:28] <hallyn> rtg: yeah ppa..  huh.  ok thanks :)
[17:36] <apw> hallyn, has to be a missing dep in the kernel makefiles somewhere
[17:37] <rtg> apw, the PPA's are -j1 aren't they ?
[17:38]  * apw would have thought not, we check the number of CPUs don't we in the packaging
[17:39] <rtg> apw, ifeq ($(wildcard /CurrentlyBuilding),)....
[17:39] <rtg> oh, that has changed
[17:40] <rtg> apw, indeed, you are correct.
[17:43] <apw> rtg, am pretty sure you did that :)
[17:43] <rtg> apw, you're prolly right.
[17:57] <apw> rtg, actually that /CurrentlyBuilding is about whether we make udebs and the like, and i added that to speend up normal builds
[17:57] <apw> rtg, but its years old
[17:57] <rtg> apw, we _used_ to use it to determine parallelsim. it likely is still that way in hardy
[17:58] <apw> ahh ... :)
[17:58] <rtg> apw, Iv'e been playing with parallel builds in lib, but can't get it to break.
[17:58] <apw> wierd
[17:58] <apw> i wonder if it is also used from outside of lib without deps
[17:58] <apw> they do that kind of thing sometimes ... #include ../xxx/foo.c
[17:58] <apw> and the like
[17:59] <rtg> apw, perhaps during the headers install phase ?
[17:59] <apw> seems odd, but ...
[18:00] <rtg> apw, you'd think it would complain about not being able to find oid_registry_data.c (which is generated)
[18:05] <apw> i need to see a full log which has this in
[18:06] <apw> rtg/hallyn if you get one again do download the log before restarting it
[18:06] <rtg> apw, there isn't a lot of info in it
[18:06] <apw> i want to see the order things occured
[18:06] <apw> if you have one
[18:13] <hallyn> apw: i haven't restarted the one so you can get the log from this morning,
[18:14] <hallyn> apw: https://launchpadlibrarian.net/124867223/buildlog_ubuntu-raring-amd64.linux_3.7.0-5.13ubuntu1userns2_FAILEDTOBUILD.txt.gz
[18:23] <apw> $(obj)/oid_registry.c: $(obj)/oid_registry_data.c
[18:23] <apw> rtg, that is wrong isn't it ?
[18:24] <apw> note the $(obj)/oid_registry.c ... that file is in $(src)/
[18:24] <rtg> apw, I was just trying to figure that out. gonna build with V=1
[18:24] <apw> so i think that apparent dependancy is non-effective
[18:24] <rtg> apw, seems reasonable. why would it _ever_ work ?
[18:25] <apw> they are likely started in the right order by luck
[18:25] <apw> so as long as we are doing things in the stack which take a while it will finish
[18:25] <apw> as the execution engine in make is limiting self to 10 builds or whatever
[18:26] <apw> yeah i think that line should be:
[18:26] <apw> $(src)/oid_registry.c: $(obj)/oid_registry_data.c
[18:26] <apw> and i think that should fix it, if you can reproduce it
[18:26] <rtg> yeah, just changed it. gonne give it awhirl
[18:27] <rtg> apw, well, it didn't break 'make M=lib -j'
[18:28] <apw> heh
[18:29] <apw> rtg, though i am slightly unsure if it should be $(obj)/oid_registry.o: in reality
[18:30] <rtg> that actually makes more sense rule wise
[18:30] <apw> as you do not remake the oid_registry.c, it is the same, but you do remake the .o
[18:31] <apw> rtg, no
[18:31] <apw> rtg, the .c does depend on it, cause you need it made before the other .c is usable
[18:31] <apw> rtg, so .c is right
[18:32] <rtg> apw, I think either is correct
[18:32]  * apw gets a headache
[18:32] <apw> yeah cause you write
[18:33] <apw> foo.o: foo.c bar.h
[18:33] <apw> and that is what we are trying to write here
[18:33] <apw> you don't write
[18:33] <apw> foo.o: foo.c
[18:33] <apw> foo.c: foo.h
[18:34] <rtg> apw, '$(obj)/oid_registry.o: $(obj)/oid_registry_data.c $(src)/oid_registry.c' ?
[18:34] <apw> there is an implicit rule for the first oid_registry.c
[18:34] <apw> so you don't need that i don't believe
[18:34] <apw> $(obj)/oid_registry.o: $(obj)/oid_registry_data.c
[18:34] <rtg> apw, on;y if the rule is '::'. right ?
[18:35] <apw> that sounds reasonable
[18:35] <rtg> $(obj)/oid_registry.o:: $(obj)/oid_registry_data.c
[18:36] <rtg> that seems to work.
[18:36] <apw> rtg, there are no examples of :: in the kernel Makefiles, so i susspect they are avoiding them
[18:36] <apw> so if your '$(obj)/oid_registry.o: $(obj)/oid_registry_data.c $(src)/oid_registry.c' works i would use that
[18:36] <hggdh> bjf, smb: I have no problems with the kernel tests being out of UTAH. This was a question arosales asked me and smb
[18:36] <rtg> apw, maybe I'll have lunch first and then send something upstream.
[18:36] <apw> rtg ack
[18:37]  * rtg -> lunch
[18:53] <hallyn> rtg: apw: weird, I just fetched raring master-next, but it does not have 3.8...
[18:56] <hallyn> rtg: the dev_change_net_namespace patch was just applied by dmiller to the netdev tree, fwiw
[18:56] <apw> hallyn, 3.8 ?  v3.7-rc8 you mean ?
[18:59] <apw> bjf, w
[18:59] <apw> bjf, am i reading this right that this week is prep week for SRUs ?
[18:59] <bjf> apw, saved
[18:59] <bjf> apw, yup!
[19:00] <apw> bjf, is slightly confusing because it is listed as the 'week of the 6th' ... thanks
[19:00] <bjf> apw, where do you see it? on the interlock schedule?
[19:01] <apw> yeah on the interlock schedule RR/ReleaseInterlock on the wiki
[19:01] <hallyn> apw: oh, i misread then.  i was thinking it was going to be 3.8
[19:01] <hallyn> thanks
[19:01] <hallyn> silly me :)
[19:01] <bjf> apw, yes, that's because releases happen on thursdays so the calendar goes from thursday to thursday
[19:01] <bjf> apw, it was/is a release manager thing
[19:03] <apw> bjf, my head is made to hurt by it ... thanks
[19:09] <apw> bjf, is henrix on the hook for kernel prep this week ?
[19:09] <henrix> apw: i am
[19:09] <bjf> apw, yes, something in particular you are interested in?
[19:09] <apw> i may have something urgent for precise
[19:10] <apw> can we spin that one last ?
[19:10] <henrix> apw: well, too late now :) but we can respin it if required
[19:13] <henrix> apw: do you have any idea about when you may have something? i can ping you on thursday about this
[19:13] <apw> henrix, i hope to have it out for review in the AM, and should know the testing is confirmed (we have tested but waiting on the reporter) by EOD tommorrow i hope
[19:14] <henrix> apw: ok, cool. let me know about it.
[19:15] <apw> henrix, will do, and thanks
[19:15] <henrix> np
[19:15] <apw> henrix, and do remember to ping me :/
[19:15] <henrix> apw: heh, i will
[19:22] <apw> ogasawara, rtg, ok i have just pushed the first slab of 3.7 config review updates to raring
[19:22] <rtg> apw, ack
[19:22] <apw> it builds to udebs for me on x86 and armhf, ymmv
[19:26] <ogasawara> apw: ack, thanks
[19:56] <rtg> apw, 'PATCH 3.7-rc8] lib/Makefile: Fix oid_registry build dependency' fired upstream
[20:28] <apw> rtg nice
[20:29] <rtg> apw, the double colon rule was wrong by the way.
[20:34] <apw> rtg, heh good to know
[20:35] <apw> what did you go with in the end
[20:35] <rtg> apw, just the simplest change, e.g., .o
[20:35] <rtg> pushed it to raring master-next
[20:35] <apw> ahh great
[20:36] <rtg> apw, Howell introduced it in -rc1 with the signed modules patch set (I think)
[20:36] <apw> rtg hence it feels like a new issue
[20:37] <rtg> yep
[20:41]  * rtg bugs out for the day
[20:47]  * apw wanders off too
[22:46] <apw> BenC, i am doing some config cleanup work on master, i also have the equivalent in the works for PPC for once you are rebased to -5.  i'll get a pull request to you, so feel free to ignore the config fixes on master i'll do them
[22:48] <BenC> apw: rebased and uploaded on -5 already
[22:52] <apw> BenC, sweet, then i'll get the config fixes done tommorrow and out to you
[23:08] <BenC> apw: thanks