=== ericm-Zzz is now known as ericm|ubuntu
slangasekbjf[afk]: so bug #900522 is a fun bot corner case.  If I reboot to the new kernel, it's possible I won't be able to reproduce the bug at all because I don't know how the kernel routing table has gotten into this state to begin with ;)00:30
ubot2Launchpad bug 900522 in linux "cached route that can't be removed with 'ip route flush cache'" [Low,Incomplete] https://launchpad.net/bugs/90052200:30
slangasekbjf[afk]: do you know who might be interested / able to help debug the kernel side of this?  If not, I guess I'll just reboot at some point and probably close the bug00:35
=== bjf[afk] is now known as bjf
bjfslangasek: tgardner would probably be the best but i'm not sure 01:54
bjfslangasek: you can add the "bot-stop-nagging" tag if you want01:55
=== bjf is now known as bjf[afk]
slangasekI know... I'm just not sure that's a useful thing to do in this case :)01:56
bjf[afk]slangasek: agreed01:56
=== bladernr_ is now known as bladernr_afk
=== smb` is now known as smb
smbmorning .+08:26
=== himcesjf1 is now known as himcesjf
* apw yawns09:44
* abogani waves all09:53
aboganiBenC: ping09:53
apwppisati, when you have ti-omap4 'fixed' i can probabally test it, so push it up somewhere i an grab it10:36
=== brendand_ is now known as brendand
ppisatiit's baking...10:58
apwchocolate cake ?10:59
* smb gets hungry10:59
ppisatiuhmm... i should make tiramisu one of this day... :)10:59
apwbring it to rally10:59
* apw likes tiramisu11:00
smbGuess it would count as "liquid"11:00
* smb +111:00
ppisatiactually if i froze it but then it will turn crap i guess...11:00
apwheh yeah i bet it would, sigh11:01
apwi know we can just have a sprint at paolo's place11:01
smbRight, have a look at his new flat11:01
apwhe can sleep on the floor11:02
ppisatibut before the sprint i'll have to disassemlbe all the boxes... way too hard... :)11:03
apwwe can use the boxes as desks, no problem11:04
smbNo problem we are good at disassembling...11:04
smb...assembling is another problem11:04
ckingespecially when the pieces have been lost and the manuals are wrong11:04
smbthe what?11:05
* apw swings his hammer widly "this screw will go in this square hole I am sure"11:05
* cking notes that when ever he reassembles furniture there is always one critical bolt or screw missing 11:06
apwcking, though that is probabally triggered by offspring11:06
smbcking, Can't be critical if things still hold together11:07
* apw notes wobbly is ok11:07
smbRemembers a shelf that survived quite a bit of time after moving and having a handful of pieces of unknown destination in my hands11:08
ckingDIY kernel team style sounds a bit hacky to me11:10
apwcking, we could do your extension if you like11:11
smbback to the essentials11:11
ckingback to rubble more like11:11
apwalways need rubble11:11
ckingnot when I need to live in it11:11
smbhey , things usually do work and hold together11:11
ckingnot with kids about11:12
smbThough in that case those few screws don't help much either11:12
apwna just more sharps for them to find11:13
cking"..but daddy you made it and it's your fault" is what I expect to hear11:13
smbcking, It is your fault anyway11:16
ckingyeah, that's very true11:16
apwyou should not buy anything, so there is nothing to break11:16
ckingI can imagine being a hermit...11:16
apwcking, it'd be cheaper11:20
ckingno beer though11:20
apwthose hermit types are the ones who invented beer11:20
ppisatibeer was invented by monks AFAIK11:26
ppisatiapw: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap411:26
ppisatiapw: last commit, the kernel compiled here11:26
apwppisati, ok ta, will test11:28
ppisatiback in 10mins11:28
apwppisati, where are we with bug #861296 ?11:44
ubot2Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/86129611:44
ogra_apw, i think we missed the two weeks SRU window (at least thats what i gathered from GrueMaster's complaints yesterday)11:45
ppisatishould be in every omap4 and imx51 branch11:45
ogra_(ask him for more detail)11:46
ppisatiexcept for P/omap411:46
ppisatiwhich is based off O/omap411:46
apwppisati, ok so it should be available, and it is with stable to roll out11:46
ppisatiso, next sync with will get it11:46
apwogra_, as its for the buildds we could get them a kernel potentially out of band i guess ?11:46
ppisatiwe did it indeed11:47
ogra_i guess lamont already runs it (not sure though, second hand info)11:47
ppisatii handed custom kernels to #is with that fix way back11:47
apwok then we are good11:47
ogra_apw, but GrueMaster needs to test them again 11:47
ogra_to have them in the next SRU batch 11:47
apwyep, there is always new batches to test11:47
ogra_(which is quite annoying for him)11:47
ppisatiapw: with the armhf i'll sync with O so P will get that fix too11:48
ogra_apw, well, he tested them two weeks ago already11:48
apwogra_, well there would be a new kernel to test next two weeks whether that is in or not11:48
apwas there will be security fixes in those kernels every cycle as well11:48
apwso i don't think there is any more or less testing to do11:48
apwppisati, ok good news, my full build of your branch looks good11:48
ogra_well, its just bad if he is told to test something that doesnt get uploaded in time and then he has to start over11:49
ogra_the test means to build java stuff which is really time consuming11:49
apwahh i see, sorry about that then11:49
ogra_yeah, not to me :) ...11:50
* ogra_ is just the cassandra here :)11:50
apwppisati, is this branch 'good' ... do we want it pushed and uploaded?11:50
ppisatiapw: not yet, let me sync it with O first11:51
ppisatiapw: then i'll send the entire batch of changes11:51
apwppisati, ok, back to you :)11:51
apwogra_, are you waiting on armhf ti-omap4 at all ?11:52
apwhow much is it holding you up11:52
ogra_omap4 and ac100 kernels are the last nits missing before we can start armhf images11:52
ogra_everything else is ready 11:52
apwppisati, how long i the resync going to take ?11:53
* apw is considering whether to upload the unresynced version11:53
ppisatihalf an hour, one hour max11:53
apwoh then... that is an easy decision11:54
apwif it is going to be today then cool11:54
apwogra_, are you on the hook for ac10011:54
ogra_apw, infinity is just testbuilding a changed package 11:54
ogra_should be uploaded once he gets up again11:55
apwok cool, ppisati poke me when you are done so we can expedite this thing into the queue11:56
ogra_my expectation is that we can build hf images weekendish ...11:56
apwppisati, have we uploaded ti-omap4 to P at all yet ?11:57
ogra_once i think11:57
ogra_yup, on nov 2111:58
apwoh now i see why i am confused12:12
apwinfinity, did you just invent a linux-meta for ti-omap4 ?12:13
ogra_apw, he uploaded it ahead of the kernel it seems, yep12:15
apwbut where the heck did he get it from12:15
ogra_(there was a conversation in #ubuntu-arm about it )12:15
ogra_<infinity> ppisati: I uploaded meta that assumes 1401 will build on armhf.  So, now I just need a kernel. ;)12:16
apwogra_, great, that just throws all the kernel team process into a cocked hat12:16
apwogra_, and is liable to bollox anyone who is an upgrader from oneiric12:19
ogra_dont blame me :)12:20
apwinfinity, *slap*12:20
* apw just has no idead what infinity has been doing to ti-omap4 meta, this is an utter mess12:23
* apw stomps off to sulk in the corner12:23
infinityapw: Invent it?  It's always been there.12:30
apwinfinity, you didn't use one of our source trees to make it12:30
infinityapw: All I did was add armhf to it (and rev it to the correct ABI)12:30
infinityapw: Uhh.12:30
infinityapw: It was apt-get source linux-omap4. :P12:30
apwso now i have to unf*ck all our trees12:30
infinityapw: It's been in the archive for eons.12:31
apwyeah the package is fine, its that we nolonger have a tree we can build meta from12:31
infinityapw: And I based it on what was in the archive, not much to "unfuck".  debdiff, apply, done.12:31
apwso if i naievly uploaded the top of ours, your changes would go poof12:31
infinityapw: See above, then?12:32
apwinfinity, but the bigger issue is you shouldn't upload meta before the binaries are built12:32
apwas now anyone with the thing installed is liable to end up with no kernel and in a heap of trouble12:32
infinityapw: I uploaded it for armel, where the binaries have been built for weeks but no one updated the meta.12:32
infinityapw: No one has armhf installed with a kernel, cause there are none.12:32
infinityapw: (-meta was out-of-date on armel, and has been for a long time)12:32
apwok then we are ok12:32
* apw whines12:33
infinityapw: Whine less?12:33
apwna bad for me12:33
apwmaybe i could be andy whine-house12:33
ogra_want to join the arm team ?12:33
apwogra_, heh no you are all mad, i'd not fit in12:34
infinityapw: Is it really that tough to apply my delta to git?  Cause, I can provide you with a branch to merge, if you want.12:35
infinityapw: I just have no zinc access anymore to actually commit it.12:36
apwinfinity, nope its not hard, i am moaning about not knowing as i nearly broke things12:36
infinityapw: Meh, if you broke things, I'd just whine right back. ;)12:36
apwi would hope so too12:36
ogra_whiners 12:37
ogra_all you !12:37
infinity(And, for the record, anyone who uploads anything without checking the current state of the archive, and diffing current:new should probably rethink their workflow)12:37
apwinfinity, that'd be us for sure :)12:37
infinityI figured. ;)12:37
apwinfinity, i have also taken a note to slap tim for uploading the kernel and never uploading -meta to match12:37
apwwell actually, i clearly do check cause i just noticed :)12:37
apwinfinity, aside of that, meta looks good12:38
infinityS'ok.  I'll go back to mangling unsupported kernels now. ;)12:38
apwac100 i assume12:38
apwif you have a tip somewhere i can test build it before you upload it, takes about 10mins12:39
apw(test building the packaging as it were)12:39
ppisatiok, pull req sent to the kernel ml12:39
infinityOh, it's already building on my Panda.12:39
apwppisati, ok will do12:39
* ppisati goes to find some food (aka lunch)12:39
apwinfinity, well it takes a lot less time my way12:39
infinityI don't do kernel iterations often enough to have a cross environment set up for it.  Don't care.12:39
infinityIt's an excuse to get caught up on Dexter.12:40
apwheh ok, i found building udebs painful as it takes sooo long to fail12:40
ogra_we dont ahve udebs for ac100 12:40
apwahh then you are likely to work then12:40
ogra_(i think ... unless jani recently added them)12:40
infinityAlso, you're assuming it will fail.12:41
infinityYou should know me better than that. ;)12:41
ogra_it cant fail, its maintained by the arm team :D12:41
infinityogra_: We have udebs for ac100, yes.12:41
ogra_ah, thats new then12:41
ogra_i explicitly didnt build them when i maintained it12:41
ogra_but jani moved to git and all ... using the ubuntu sauce etc 12:41
infinityWell, sort of.12:42
ogra_so i guess we inherit udeb building 12:42
infinityIt's more linaroish than ubuntuish.12:42
apwick :)12:42
ogra_i originally based on n900 ... he moved to some generic linaro ways from that12:42
ogra_but added the sauce12:43
apwogra_, i have often felt the right thing is to take linaro tip and merge our master into it each time to make the new version12:43
infinityI miss being a lot less confused by kernels.  When that all built from the same source package, and x86-centric people whined that merging patches with Sparc was "too hard", so they just didn't, and then they whined when it would FTBFS.12:44
infinityGood times.12:44
ogra_apw, well the prob is that linaro refuses to maintain tehir kernels after a release ... and they release monthly12:44
apwinfinity, its cirtainly different now, i think i've lived through it all, quite a ride12:44
apwogra_, oh i know, you'd be merging their original tip into our tip with cves and hoping that the result worked12:45
ogra_we could go from snapshot to snapshot ... but as soon as *we* release there isnt a way to get SRUs or security fixes12:45
apwogra_, the one thing i am fully aware of is the amount of work their cause me and my arm peeps12:45
apwwe essentially maintain > 2x the kernel revisions we want to cause of this crap12:46
infinityapw: I think we still need some clever way to keep the packaging more centralised and sane than it currently is.  And the secret sauce.  And all that jazz.  Even if we don't want one massive source package that takes forever to build and has (potentially) conflicting patches.12:46
infinityapw: Like, some shiny tool that will essentially roll a proper source package from git, with grafted branches as needed.12:46
apwinfinity, care to be part of a discussion at rally about ideas on how we can improve things12:46
infinityapw: So they all look and act the same.12:46
infinityapw: Yeah, perhaps.12:47
apwthat has been suggested and the AAs went mad that the source should be the source12:47
ogra_hard to do if you have as many different versions as linaro has though12:47
ogra_(read: BSP kernels)12:47
apwand we arn't allowed to backport the packaging changes to older releases12:47
ogra_iirc there are still boards they run with .3512:47
apwand .. 200 other complaints against anything we have suggested12:47
infinityapw: I mean, for Linaro-maintained kernels, we can't do as much, and that's fine, but anything that's theoretically maintained by the Ubuntu kernel team should all match with packaging, enforce, etc.12:47
apwinfinity, and we'd do that in an instant if the sru team would take the harmonised packaging12:48
infinityapw: The source is never the source.  I wonder if maybe some wires got crossed in describing how to do such a thing.12:48
apwbut we did try and they said flat no12:48
infinityapw: I mean, heck, nothing that uses autoconf is "pristine source", upstream always generates configure, etc.12:48
apwinfinity, yeah, its the debian packaging changing in old releases they won't let us do12:49
infinityapw: I don't see how SRUs relate.  That's just different (and stagnant) branches.  You always have to branch at a stable release.12:49
infinityapw: Anything "auto-generating" packaging in a stable release should be deterministic anyway.12:49
ogra_the past is whats creating the workload ...12:49
apwwell if we commonise, we want to commonise everywhere no?12:49
apwelse the old stuff is different and the world is more of a pain than now12:50
ogra_while we can change it for the future, kernel team is stuck with the past stuff12:50
infinityapw: (ie: if I rerun autotools across a source package with the same versions of autoconf, libtool, etc, it won't change the output)12:50
infinityapw: No, changing the past is a no-go.  But that doesn't perclude improving the future. ;)12:50
apwa ripe discussion for rally12:50
apwinfinity, well except where the new differs from the old in semantics as that creates mantenance burden12:51
infinityapw: But let's have an informal beer on Sunday night at the Rally and see if it comes to fisticuffs and/or agreement before you care about my opinions on the matter. :)12:51
apwand right now most of the burden is on people making new branches12:51
apwinfinity, sounds good to me12:51
infinityI'll go work out.12:52
aboganiBenC: About "Reviving Ubuntu PowerPC"...13:08
aboganiBenC: What systems will be used as reference in this effort?13:08
infinityabogani: My PowerStation, for one. ;)13:21
smbherton, I discovered this morning that I had missed one change in the upstream patches which has a related bug in the ec2 deviated files (had been missing two files in the deviations file). I suppose the correct way forward is a completely new tracking bug and to invalidate/mark duplicate the old one. Or is there another option?13:27
* cking grabs some food13:27
hertonsmb, yes, doing a new tracking bug, duplicating the old against the new is ok, no other way13:28
smbherton, ok, will follow-up with that then. thanks13:29
=== himcesjf1 is now known as himcesjf
bullgard6How is a »kernel update« defined? Is the term »kernel update« a technical term meaning something else than just any change in the kernel code to reflect a newer development?  So far I did not find a definition when googling. How can one write: "The package linux-generic is a kernel update"? 13:46
apwgenerally when we talke about a 'kernel update' we are talking about an updated package containing the kernel13:47
apwi don't think i would ever write "the package linux-generic is a kernel update"13:47
apwthe package linux-generic trigers your kernel to be updated13:47
apwby always depending on the latest kernel package available13:47
bullgard6apw: Thank you very much for explaining.13:49
apwppisati, did you get an email in response to my upload13:52
ppisatiapw: i got the "applied" email13:54
apwppisati, did you get anything from launchpad about it13:55
apwbloody lp13:55
infinityapw: The librarian's down.14:08
apwinfinity, does that break uploads?  presume so14:08
infinityapw: Since they have to be stored in the librarian, yeah.14:09
infinityapw: They should be tucked away in queues, waiting to flush when it's fixed, though.  In theory.14:09
apwinfinity, yeah heres hoping ...14:10
=== bladernr_afk is now known as bladernr_
tgardnerjsalisbury, do you have a way to search for bugs against linux-meta ? In almost all cases they should be changed to linux (unless they really are meta package bugs)15:05
ppisatiapw: P/omap4 is in and it's building15:05
jsalisburytgardner, yes, I can do a search on them.  I'll do that and move them over linux15:05
ppisatiapw: but the armhf version says "need building"15:05
ppisatiseems it's queued15:06
apwppisati, yep all good, given the state of the librarian its amazing its building at all15:07
ppisatiapw: but since we don't have any armhf builder, how does it build?15:07
jsalisburyherton, bjf, Request for a patch backport to oneiric:  bug 89959815:08
ubot2Launchpad bug 899598 in linux "[Patch] The resolution of Display Port for intel cards is limited" [Medium,Triaged] https://launchpad.net/bugs/89959815:08
hertonjsalisbury, we will take a look15:08
* herton -> lunch15:08
apwppisati, yep we do, we have about 1015:09
ppisatiah cool15:10
apwppisati, we actually have more than we have armel right now, but then we have 1000s of packages to build15:10
ppisatii see15:10
jsalisburyherton, thanks15:10
ogra_ppisati, apw, infinity can raise the priority for the armhf build15:18
ogra_(or any other archive admin)15:18
apwogra_, yep, its already started building too15:19
ogra_ah, k15:19
=== bjf[afk] is now known as bjf
jsalisbury** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting15:51
* apw wimpers15:53
* ogasawara back in 2015:57
GrueMasterogra_, apw: My issue on kernel SRU yesterday was that a much needed feature that was tested in various kernels a couple of weeks ago didn't get included with this SRU cycle, meaning that people that need these fixes need to wait until almost EOY for them.  Or they run with a test kernel and not get any of the SRU updates in this release. 16:13
GrueMasterJust to clarify.16:13
ogra_yeah, i think i got that across to apw and he even apologized16:13
apwyep and i suspect that is because the submitter was on holiday when he results came in, and appoligies for the testing effort that is wasted as a result16:14
apwseparate to the inconvienience, it sounds like we need some updated test kerenls as well16:14
apwi am assured the fix is applied now though i can't say i have checked16:15
ogra_well, the important part (buildds) is fixed anyway already ... essentially getting it into the archive is rather the formal afterwork :)16:15
GrueMasterFor the record, I'm not trying to stir up that argument again, just clarifying where I stood.16:15
apwGrueMaster, nope and i am not seeing it as a moan either16:15
GrueMasterGood.  :)16:15
apwand had i realised that it was a 2 day effort to test it i'd have been more careful to shepherd the fix16:15
apwi tend to assume its boot and run for a couple of minutes and know, whcih isn't at all the case for this puppy16:16
GrueMasterI do have some qrt tests that magically work with that fix, but since i have had to manually run them anyways until now, it isn't too much effort to monitor them again.16:16
ogra_well, we could just ask lamont to set the verification-done tag on the bug 16:17
apwtopdown mmap support16:17
ogra_gievn he already runs the fix on the buildds16:17
apwits that set isn't it we are talking about16:17
ogra_without having GrueMaster to runn a full test ...16:17
GrueMasterPart of the test process is that I am struggling to automate SRU testing.  Largely due to script issues and the lack of any automated installation capabilities prior to Oneiric on omap4.16:17
GrueMasterBut those are almost resolved.16:18
apwppisati, where do i expect to find 'topdown mmap support' applied?16:18
apwppisati, fsl-imx51 and natty and oneiric ti-omap4 right?  (which it is)16:18
ppisatiapw: M/N/O/P/omap4 and L/imx5116:18
apwso it looks like it is applied everywhere i am expecting it to be, so i assume it'll be in teh next roll up16:19
apwppisati, ok cool, just checking they got applied right16:19
ppisatii posted the testing kernels the day X, but i got the ack about all of them the day _after_ the SRU process started16:20
GrueMasterppisati: In the future, when you go on vacation to get away from it all, make sure to take your laptop so you can still work.  :P16:20
ppisatiso i couldn't pull16:20
ppisatii did it before my internet disconnection16:20
ogra_ppisati, dont listen to him !16:20
apwppisati, yep that is likely our fault16:20
ckinghrm, still more workitems to plough through...16:20
ppisatiIMO it was just an unfortunate timing16:21
ppisatithe problerm is that i can't pull in fixes if they aren't tested16:21
GrueMasterAgreed.  Actually, I was on a national holiday that week as well.16:21
infinityogra_: Err, reading backscroll, I don't think the buildds are fixed.16:22
infinityogra_: lamont tested a kernel on a machine, he didn't do any sort of mass roll-out.16:22
ogra_infinity, i thought lamont was using the fixed kernels since a while16:22
ogra_but after all he did the testing and could just comment on the bug ... leaving tobin off the hook16:23
GrueMasterI tested it too.  Thought I had commented on the bug.16:23
* GrueMaster goes to check.16:23
* ogra_ hasnt looked at the bug 16:23
infinityogra_: He tested one kernel on one machine type.  That's not quite the scope of tobin's testing.16:24
* ogra_ leaves that topic alone then16:25
* ppisati goes back to 3.2/omap4...16:25
ogra_i somewhat had a different impression 16:25
GrueMasterI tested it on babbage3 (Lucid) and panda (natty & oneiric).  Not sure if we had a test kernel for maverick.16:27
GrueMasterDoes the patch need to be retested on top of this new SRU kernel or can it just float into the next SRU cycle and get tested there?16:28
GrueMaster(I may have missed this answer due to lack of caffeine).16:29
apwGrueMaster, for me, just when it gets applied to teh next SRU, i am not expecting it to break16:30
GrueMasterOk, great.  Means I can focus on other things until next SRU cycle without a special testcase getting thrown into the mix.16:30
infinityapw: Looks like I win, my kernel will get built first.16:38
infinity(not that it matters, cause neither one can be published to the archive for a few hours)16:38
amb__We have a bug (LP #886521) which is marked "Fix Committed" in Oneiric. What is the process / timescale that a new kernel gets released to incorporate such fixes (and presumably changes it to "Fix Released")?16:46
ubot2Launchpad bug 886521 in linux "CONFIG_XEN_PLATFORM_PCI should be "y" when building 3.1 kernel" [Medium,Fix committed] https://launchpad.net/bugs/88652116:46
apwamb__, it is likely the fix if already rolled up in the -proposed kernel for testing16:46
smbCould be in the pending round of getting into proposed16:47
amb__apw, so is that an automatic process? 16:47
smbBut normally you find an update in the bug that is automatically generated which tells you to test the proposed kernel16:47
amb__(and/or how do we get at the .debs to test such kernels)16:48
amb__ah, it's not there yet16:48
apwamb__, ok its only just been commited, so it missed the current sru round, so i'd say you'll see it in a kernel in about 3 weeks16:48
smbNo, I think its is on the way. The auto entry has some instructions about enabling proposed16:48
smbbut one also can get the debs from launchpad history of the linux package16:49
smb^ if lp is willing16:49
bjfamb__: we will be building the next oneiric kernel next week, as apw said it will hit -updates three weeks after that, it will be available via -proposed earlier16:49
apwamb__, and expect testing requests for it around then16:49
smbgah! lp timeout16:50
amb__bjf, thanks16:51
bjfamb__: np16:51
ppisatidon't we have the meeting in 1 hour?16:52
jsalisburyppisati, yes16:53
tgardnerjsalisbury, we've been screwed by going off of daylight savings time. there are 2 entries in the calendar16:54
jsalisburytgardner, ahh, ok.  Should one of the entries be removed?16:55
tgardnerjsalisbury, yeah, but which one ?16:56
tgardnerI'll nuke the later one16:56
apwthe meeting is at 17:00 UTC right16:57
bjfapw, yes, the meeting is now16:57
jsalisburyapw, yes, in about 3 minutes16:57
tgardnerhmm, I can't delete the bogus entry. I'll send a note to Pete16:58
apwstupid google16:58
=== arges is now known as arges_away
lamontogra_: I was given to understand that some post-my-testing kernel had the fix, which was great, since that was what I was waiting for - the rollout of a fixed SRU is semi-automatic, manually rolling out a non-standard kernel is a royal pain17:31
ogra_thanks for clearifying :)17:31
=== arges_away is now known as arges
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Dec 13 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* tgardner -> lunch18:36
bjfjsalisbury: i believe bug 793367 can be "Fix Released"19:53
ubot2Launchpad bug 793367 in linux "ecryptfs corruption during make -j" [Medium,Fix committed] https://launchpad.net/bugs/79336719:53
jsalisburybjf, Ok, thanks.  I'll update it.19:53
jsalisburybjf, I'll keep an eye on and to ensure it falls off the hot list automatically as expected.20:02
jsalisburybjf, herton, possible Lucid update regression: bug 90094321:39
ubot2Launchpad bug 900943 in linux "System clock runs fast in kernel 2.6.32-36" [Medium,Confirmed] https://launchpad.net/bugs/90094321:39
* tgardner -> EOD for now21:40
bjfjsalisbury: thanks for the pointer, have added comment, am monitoring it21:59
jsalisburybjf, great, thanks.21:59
=== BenC__ is now known as BenC

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!