[03:42] <quentusrex> Alright, I have been following this guide for kernel building and installation: http://blog.avirtualhome.com/2010/11/06/how-to-compile-a-ubuntu-10-10-maverick-kernel/
[03:43] <quentusrex> Is there any way to build the package(or even just build the replacement kernel) faster than rebuilding everything from scratch?
[03:43] <quentusrex> I'm trying to test patches to fix a problem with Seagate Barracuda 7200.12  SATA drivers, but it takes 30+ minutes between attempts currently.
[07:10] <apw> quentusrex, you can patch the source, remove debian/stamps/*build* and then fakeroot binary-<flavour> will not rebuild everything
[07:15] <quentusrex> thanks apw, but just to confirm that will rebuild the parts of the kernel that have changed?
=== smb` is now known as smb
[07:19] <apw> quentusrex, it should yes, the packaging still occurs so its still not zippy but doesn't build every c file
[07:19]  * smb waves to apw
[07:20]  * apw waves to smb
[07:20] <quentusrex> thanks apw. I'll give that a try. 
[07:20] <quentusrex> I'm trying to track down a problem with the Seagate Barracuda 7200.12 and the ATI chipset. 
[07:24] <apw> sound fun
[07:29] <ohsix> quentusrex: what problem? the link keeps going down?
[07:45] <quentusrex> ohsix, basically there is a load of ~3 on idle and trying to write anything above 20MB will cause the server to become io-bound and unresponsive.
[07:46] <ohsix> have you looked at dmesg?
[07:46] <ohsix> there's a pretty general problem with seagate drives and the link going down
[07:46] <quentusrex> if I unplug the Seagate hard drive and plug in a Western Digital then everything works fine, and everything works fine if I plug in a 7200.9 Seagate drive.
[07:46] <quentusrex> ohsix, I haven't see anything about the link going down in dmesg
[07:47] <ohsix> post the output to a pastebin, it doesn't say "link down" there are ata errors about resets
[07:48] <quentusrex> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/815540
[07:48] <ubot2> Ubuntu bug 815540 in linux "Server becomes unresponsive after spawning 16 ksoftirqd processes" [Undecided,Confirmed]
[07:48] <quentusrex> there is a dmesg file uploaded there. 
[07:48] <quentusrex> 'reset' isn't in the log.
[07:49] <ohsix> sec, there was a change not too long ago that made the resets transparent too
[07:51] <ohsix> i'll have to think a bit about what i did back when i had the problem drives; they've since been replaced with other seagates that don't do it
[07:52] <quentusrex> ohsix, I would appreciate it.
[07:56] <ohsix> quentusrex: have you tried to track down a firmware update for the drive yet?
[07:56] <quentusrex> ohsix, I started with the drives on CC46
[07:56] <quentusrex> then updated to the latest which is CC49
[07:56] <quentusrex> no difference.
[07:56] <ohsix> ok
[07:57] <ohsix> hm, you know it's been quite a long time; i remember having to disable ncq for some reason, and i'm pretty sure the link resets were it, but i can't remember if just setting the queue depth less than 31 also helped
[07:58] <apw> ohsix, now that seems familiar, some drive causing reserts if you used all of the queue entries or something
[08:00] <ohsix> you could try disabling ahci too; it does the same thing basically
[08:01] <ohsix> then you're back to 'ole classic chipset restrictions
[08:01] <ohsix> there's also something to show those resets again but i'll have to look a bit
[08:02] <quentusrex> yeah, I see a check around them all for verbose. I'm back tracking it to find the config. If you find it first, let me know.
[08:03] <ohsix> ok i found my emails from 2008, i'll look through them :]
[08:04] <quentusrex> What feels crazy is that these are brand new drive models from Seagate. I would think they wouldn't make the same mistake again only 3 years later.
[08:05] <apw> quentusrex, and i bet you are being sensible and spreading your maker to avoid systemic failure too
[08:05] <quentusrex> spreading my maker?
[08:06] <ohsix> they don't actually do the firmware on some of their models, it's actually pretty hard to figure out if you want to avoid stuff
[08:06] <apw> buying differnet makers kit so that if say like the old death-stars they have a manufacturing fault you don't loose everything
[08:07] <quentusrex> apw, aah. Yes, and I stress test every new server before it touches production.
[08:07] <quentusrex> and by stress test I mean memtester for a week straight, then at least a week running boinc for rosetta@home.
[08:07] <quentusrex> rosetta does well at finding incompatible or flaky drives, at least it is good at finding them for me.
[08:07] <apw> so i guess +1 for it catching this bad drive, -1 for seagate for their drive
[08:08] <quentusrex> apw, it's the entire model. I have 3 of the same drives from different batches. all with the exact same problem.
[08:09] <ohsix> ok this is back when i had spindles lock on a bunch of seagate drives, one locked; got rma, the rma had the link down problem
[08:09] <apw> quentusrex, yep, awsome
[08:09] <ohsix> the ncq thing worked around it, and they had to contact an engineer to actually make a new firmware image to update the drive i had to fix it
[08:09] <apw> ohsix, now that sucks, "i want the old one, oh no i don't"
[08:09] <ohsix> apw: they were the enterprise series drive too
[08:10] <ohsix> i had accounted for all types of failure besides then turning into a block of aluminum
[08:10] <apw> probabally why you got anything other than ignored when you said it was broke
[08:10] <ohsix> they use fluid dynamic bearings; they spin weld themselves :D
[08:11] <ohsix> the other drive i had in the set did it within a few power on hours of the first too
[08:12] <ohsix> this is what i said at the time to support: 3.AAK, nforce5 mcp55, the sata link keeps going up and down and the drive keeps resetting with controller errors, and its worse with NCQ enabled [06:01:40 PM]
[08:12] <apw> ohsix, i had all of my personal data on a pair of travel-stars, they both died in the same way within a day of each other
[08:12] <ohsix> they sent me 3.AAM, and they had a hard time doing it too :] but that fixed it
[08:13] <apw> those were the days mind when the manufacturer could claim "oh we don't rate those drives for continuious spin"
[08:13] <ohsix> but according to that message and my confusion, the problem wasn't entirely resolved with disabling ncq
[08:14] <ohsix> quentusrex: i'll keep looking for a way to reenable those messages, and the patch that disabled them (cuz i explicitly remember seeing it on patchwork); i'd start the process to getting even newer firmware, since it takes a while
[08:14] <apw> ohsix, the odd thing is i do recall a reduction in outstanding queue count helping for something like this
[08:14] <ohsix> ya i couldn't figure out why the controller kept resetting, there was no rhyme or reason
[08:14] <apw> quentusrex, cirtanly worth reducing the queue depth on the drive to see if it helps
[08:15] <ohsix> it really liked to break when i was reading enough off the drive constantly, but barely enough to keep the head moving (like playing mp3s or a movie from it)
[08:16] <ohsix> i tried using short and stout cables and stuff to see if that mattered, it didn't
[08:16] <ohsix> it was just some firmware badness
[08:17] <ohsix> oh, you can also try forcing the link speed to sata1.5
[08:18] <quentusrex> I've got to crash soon. It's 1:20am here.
[08:20] <ohsix> ok, you can set the link mode, and ncq at boot with libata.force=1.5Gbps,noncq
[08:21] <ohsix> nohrst, nosrst, and norst controls the hiding of the different reset messages, hard, soft, and both respectively
[08:21] <ohsix> so quick confirmation wrt what i think it is, is libata.force=norst, then get it to do it and check dmesg
[08:21] <quentusrex> ohsix, so how do I enable them?
[08:22] <quentusrex> ok
[08:22] <ohsix> edit the commandline in grub before you boot, or add them to /etc/default/grub (GRUB_CMDLINE_LINUX_DEFAULT) run grub-update and reboot
[08:24] <quentusrex> I'll know shortly ohsix 
[08:25] <quentusrex> ohsix, do you know why it was decided to hide the ata reset messages?
[08:25] <ohsix> i don't remember, that's why i'm looking for the patch again
[08:25] <ohsix> they're mostly useless messages, except in this particular situation heh
[08:26] <ohsix> links go down occasionally anyways, and it doesn't really hurt; but if the host is doing something that crashes the drive firmware you want to know :]
[08:33] <ohsix> aha, forgot about git-blame, i can see who added the documentation
[08:34] <ohsix> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=05944bdf6fadb5394710269df6770dde447b23ca
[08:34] <ohsix> er, heh; going by the commit message that doesn't do what i thought it does
[08:35] <ohsix> that actually disables resets alltogether
[08:36] <quentusrex> ohsix, yeah, that actually made it worse. Took much longer to boot with that option.
[08:36] <ohsix> right
[08:46] <ohsix> i don't see anything that actually hides the messages, looks like stuff just changed
=== Quintasan_ is now known as Quintasan
[10:13] <amitk> apw: you guys sprinting before Plumbers?
[11:52]  * ppisati -> out
[12:54] <davmor2> ogasawara: Morning both test kernels seem to have wifi beaming out quite happily, not seen any issues, on either box hibernate, suspend etc have all brought the wifi back up and connected successfully etc
[13:08] <ogasawara> davmor2: cool, so for the broadcom one, I'll put together a few more kernels so we can narrow down the regression
[13:08] <davmor2> ogasawara: no probs
[13:08] <ogasawara> davmor2: for the ralink, I'll apply the commit and it should hit Alpha3
[13:09] <davmor2> ogasawara: nice,  I'll keep an eye on the ralink one for you over the weekend makes sure nothing drops out etc but so far seems nicely stable
[13:19]  * smb wonders whether reviewing cves is not a waste of time...
[13:20] <tgardner> smb, how so?
[13:20] <smb> tgardner, They seem to get applied quicker than I can look at them.. :-P
[13:21] <tgardner> smb, it seems straightforward to me if they are cherry-picks, and have already been applied to other master branches.
[13:21] <tgardner> I did look at the backports pretty carefully
[13:23] <smb> Yeah, did the same. And yes, more or less those are not very critical in the sense of having much change compared to other branches...
[13:24] <smb> Just for those the question is whether I look at them or just wait whether they get applied the next hour... ;)
[13:25] <tgardner> well, I'm just compulsive about clearing out my inbox first thing. you'll just have to start earlier.
[13:27] <smb> tgardner, Good point. Unfortunately Andy sent them out between the end of my lunch break and your start of the day. I just need to avoid that kind of work in your mornings :)
[13:49] <apw> http://www.debian.org/releases/lenny/example-preseed.txt
[13:57] <ogasawara> skaet: at the rally we had a gcc discussion for the P release.  I recall you had taken notes, did they get transcribed anywhere by chance?
[13:59] <ogasawara> davmor2: when you have a chance, new test kernel at http://people.canonical.com/~ogasawara/lp814882/
[13:59] <ogasawara> davmor2: same info posted to the bug as well
[14:00] <davmor2> ogasawara: righto I'll give it a go in a bit just doing some testing at the minute so might be an hour or so
[14:00] <ogasawara> davmor2: cool, thanks
[14:01] <skaet> ogasawara: have the notes, and happy to put them somewhere public - ideas/preferences?  mail/spec/wiki?
[14:02] <ogasawara> skaet: wiki or spec would be good, I just wanted to have some reference I could share with some Intel folks
[14:02] <skaet> ogasawara, is there a SPEC you want me to add them to?  happy to do that.
[14:03]  * skaet figures there might be a few feathers ruffled if I start off a Oneiric/ToolchainPlans page.
[14:04] <ogasawara> skaet: we can probably add it to https://launchpad.net/ubuntu/+spec/other-kernel-o-gcc-build-dependency as that's where the action was listed for us to get together at the rally
[14:04] <ogasawara> skaet: just throw it on the whiteboard as notes from that meeting
[14:04] <skaet> ogasawara, makes sense.   adding.
[14:05] <ogasawara> skaet: thanks
[14:26] <apw> tgardner, well if i had to guess i'd say it'd be worth adding this to the boot command line via F6: cdrom-detect/eject=false
[14:26] <tgardner> apw, ack
[14:27] <skaet> ogasawara, raw notes added to the spec.
[14:29] <ogasawara> skaet: thanks again
[14:29]  * ogasawara back in 20
[14:46] <sforshee> mjg59, cking: either of you have a minute for an AML question?
[14:49] <apw> ogasawara, ok i've pushed a bunch of cleanups to patches to the tip of oneiric, all from the delta-review.  i've reverted and reapplied patches where they were updated so you can see them, feel free to collapse and move them as appropriate on your next rebase
[14:51] <ogasawara> apw: ack thanks
[14:52] <apw> ogasawara, that represents the bulk of what i am doing for that work item so i have closed it out and made a new one for the remainder
[14:52] <ogasawara> apw: cool
[14:52] <apw> none of the remainder is release critical, so once i have the patches in progress i'll close that too
[14:53] <ogasawara> works for me
[14:53] <apw> ogasawara, i did revert some include additions which may pop an FTBS, i don't think so as none of my test builds needed them, but just in case so you know they are there ... all my reasons are on the wiki
[14:58] <bdmurray> afaict bug 817213 seems fixed in oneiric
[14:58] <ubot2> Launchpad bug 817213 in linux "Spaces instead of mainboard vendor name in dmesg DMI: line" [Undecided,New] https://launchpad.net/bugs/817213
[15:17] <tgardner> apw, 'cdrom-detect/eject=false' seems to have worked
[15:18] <apw> tgardner, awsome
[15:19] <apw> something going our way
[15:21] <apw> something going our way
[15:21] <apw> (but apparently not mine)
[16:41] <bdmurray> hey there so I was looking at https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Battery_drained_whilst_suspended_stock_reply and wanted to stop those from being reported
[16:41] <bdmurray> What is the tell for your your battery drained?
=== _LibertyZero is now known as LibertyZero
[17:30] <davmor2> ogasawara: sorry for the delay, the latest kernel you added has working wifi
[17:30] <ogasawara> davmor2: thanks, was hopping you'd say that.  I'll kick off the next build...
=== cking is now known as cking-afk
[17:46]  * cking-afk --> EOD
=== tgardner is now known as tgardner-afk
[17:47]  * tgardner-afk is out early today
[17:55] <ogasawara> davmor2: k, next test kernel at the same location - http://people.canonical.com/~ogasawara/lp814882/
[17:56] <ogasawara> davmor2: comment also posted to the bug so that I keep track where we are
[18:02] <apw> (but apparently not mine)
[18:02] <quentusrex> apw, ohsix just to let you know the Seagate issue appears fixed in the 2.6.38-11.47 kernel
[18:03] <apw> quentusrex, and its broken in which version ?
[18:03] <quentusrex> I will try to figure out which patch resovled the issue
[18:03] <quentusrex> broken as late as 2.6.38-10.46
[18:08] <apw> quentusrex, what host controller do you have
[18:14] <herton> does someone have any idea why we don't have linux-image-2.6.38-11-powerpc64-smp_2.6.38-11.47_ppc64.deb on repositories?
[18:15] <herton> maint-getabis is complaining:
[18:15] <herton> II: linux-image-2.6.38-11-powerpc64-smp_2.6.38-11.47_ppc64.deb
[18:15] <herton> II: Downloading to kernel.ubuntu.com ... FAILED!
[18:15] <herton> it's the only one missing
[18:15] <davmor2> ogasawara: I have wifi again with that installed
[18:16] <quentusrex> apw, SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
[18:16] <ogasawara> davmor2: k, kicking off the next test build...
[18:18] <apw> herton, it is in the launchpad librarian, so it did exist 
[18:19] <davmor2> ogasawara: I'm off soon so I'll take this one from lp when I get back home from shopping and stuff possibly around 22:00bst currently 19:19 for a reference
[18:19] <ogasawara> davmor2: cool, thanks
[18:21] <herton> apw: hmm, maint-getabis looks at that 4 urls, none has it. strange thing as also none of them have any deb with arch=ppc64
[18:21] <apw> herton, it is in universe
[18:22] <apw> which i believe it should not be
[18:22] <apw> change http://ports.ubuntu.com/pool/universe/l/linux/linux-image-2.6.38-11-powerpc64-smp_2.6.38-11.47_powerpc.deb
[18:23] <apw> herton, you can grab it from there for your purposes i suspect
[18:24] <apw> but ... i'd ask why its there, we've had a lot of stable kernels drop in the wrong hole recently
[18:24] <apw> and its meant to be scripted to avoid that
[18:25] <herton> apw: but this url also doesn't have the ppc64 deb (note that file it looks ends with "ppc64.deb")
[18:29] <bjf> herton, jjohansen, apw, ogasawara, bug 747092
[18:29] <ubot2> Launchpad bug 747092 in linux "[FUJITSU FMVNP2PL] edge scrolling does not work" [Undecided,Confirmed] https://launchpad.net/bugs/747092
[18:45] <quentusrex> apw, It seems to be much better now, but not fixed.
[18:46] <quentusrex> it is possible that restarting the machine after returning the command queue to 20 might have had an effect.
[18:49] <quentusrex> apw, any idea why dmesg never gets written to after boot? even when there is a printk that should be printing to it.
[18:50] <apw_> should work in my experience 
[18:52] <quentusrex> apw, so the issue is down from 10-15 times the overhead down to about 5-10 times the overhead.
[18:52] <apw_> herton: the ppc binaries should be sorted shortly
[18:54] <herton> apw_: cool. I noted that previous natty releases didn't include ppc64 abi (there is no debian.master/abi/2.6.38-*/ppc64 on them)
[18:55] <apw_> ignore ppc64 it is not enabled
[18:55] <apw_> powerpc64 is a powerpc not ppc64 kernel
[18:57] <bjf> ogasawara, sforshee, jjohansen, herton, whoever is looking at that bug, take a look at 74de8a14d8afe3d8dd009e223eea742a753314f4 in the oneiric repo
[18:58] <bjf> ogasawara, sforshee, jjohansen, herton if we do the same thing but match on FMVNP2PL would that get us what we want?
[19:02] <herton> bjf: it's possible, if the "Magic Sequence" is the same on Fujitsu
[19:02] <ogasawara> bjf: posted an additional comment to the bug
[19:05] <bjf> ogasawara, i responded to your comment
[19:06] <bjf> ogasawara, i'm getting "port 22: Connection refused" for tangerine
[19:06] <ogasawara> bjf: hrm, lemme try.  I've been using tyler lately
[19:09] <ogasawara> bjf: I keep getting a "Permission denied, please try again." when I enter my password
[19:09] <bjf> ogasawara, try "the standard password"
[19:09] <ogasawara> bjf: ah, that works
[19:12] <bjf> ogasawara, working for me now
[20:36]  * herton -> eod (soccer)
=== Quintasan_ is now known as Quintasan
=== yofel_ is now known as yofel
[21:05] <kamal> rtg: at your convenience... htop for tangerine?
[21:06] <kamal> tgardner-afk: at your convenience... htop for tangerine?
[21:21] <apw> kamal, done
[21:21] <kamal> apw: ty
[21:51] <kees> with pitti on vacation, who is doing kernel publications?
[21:54] <quentusrex> Anyone know how to enable ahci debug in the kernel?
[21:58] <Fanfare> Hi @ All! I get a kernel freeze when ever i disconnect  from LAN. How to debug? 
[22:01] <bjf> kees, that's always a good question
[22:03] <bjf> kees, the answer is supposed to be SpamapS, skaet, or jdstrand are all supposedly capable 
[22:03] <kees> jdstrand: I think you're EOD, but I'd rather do publications before friday. any chance you can look at the pending ones?
[22:04] <skaet> bjf,  I lack the right permissions on cocoplum it appears.  
[22:04] <jdstrand> kees: what is needed?
[22:04] <skaet> kees,  I can move to -proposed, but not -updates.
[22:04] <kees> bjf: do you have it handy? I know there is at least one I saw go into "needs copy" mode a few days ago.
[22:05] <bjf> kees, i'll look but i'm on rotation this cycle
[22:06] <kees> bjf: I can look too, no worries
[22:06] <kees> jdstrand: let me find them
[22:06] <bjf> kees, it's just that i've not been tracking them
[22:07] <kees> bjf: yeah. I have searches for "what needs me attention" but I don't have a "what's pending?" search handy... building
[22:07] <bjf> kees, i don't see anything right now that needs copying
[22:08] <kees> bjf: https://bugs.launchpad.net/kernel-sru-workflow/+bug/811215 lucid linux-lts-backport-maverick does, IIUC
[22:08] <ubot2> Ubuntu bug 811215 in kernel-sru-workflow "linux-lts-backport-maverick: 2.6.35-30.56~lucid1 -proposed tracker" [Undecided,In progress]
[22:08] <jdstrand> http://people.canonical.com/~ubuntu-archive/pending-sru.html shows that as having *many* bugs that haven't been confirmed
[22:08] <jdstrand> and one that needs to be backed out
[22:08] <kees> https://bugs.launchpad.net/kernel-sru-workflow/+bug/808934 maverick linux does too
[22:08] <ubot2> Ubuntu bug 808934 in kernel-sru-workflow "linux: 2.6.35-30.56 -proposed tracker" [Undecided,In progress]
[22:09] <skaet> jdstrand while you're at it, ;)  could you take a look at moving the .71 lucid kernel from -proposed to -updates https://bugs.launchpad.net/ubuntu/+source/linux/+bug/813507
[22:09] <ubot2> Ubuntu bug 813507 in linux "linux: 2.6.32-33.71 -proposed tracker" [High,In progress]
[22:09] <kees> https://bugs.launchpad.net/kernel-sru-workflow/+bug/813507 lucid linux too
[22:09] <skaet> heh
[22:10] <bjf> jdstrand, i believe most of those *many* are CVE's
[22:10] <kees> so, that's 3 that are many days old
[22:10] <bjf> jdstrand, oops, looking at the wrong one
[22:10] <bjf> kees, that is a lts-backport
[22:10] <kees> bjf: so?
[22:11] <bjf> kees, nothing just making sure we are looking at the same thing
[22:11] <kees> lucid linux is 6 days old (!)
[22:11] <jdstrand> I'm happy to process the kernels, though I would like to verify it is ready so need to review
[22:11] <kees> lucid linux-lts-backport-maverick is 2 days old
[22:11] <jdstrand> I'm currently looking at http://people.canonical.com/~kernel/reports/sru-report.html
[22:12] <kees> jdstrand: bugs 808934 813507 811215 all show full sign-off
[22:12] <ubot2> Launchpad bug 808934 in kernel-sru-workflow "linux: 2.6.35-30.56 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/808934
[22:12] <jdstrand> I don't really understand that page
[22:12] <kees> jdstrand: as in, they're at the "promote" part of the workflow, iiuc
[22:12] <bjf> kees, jdstrand i'm not sure the backport should go to updates before the regular maverick kernel does
[22:13] <kees> jdstrand: basically https://wiki.ubuntu.com/Kernel/kernel-sru-workflow steps 16 and 17
[22:13] <jdstrand> oh my gosh, there is a lot in there
[22:13] <kees> bjf: sure, but they're both ready, afaict
[22:14] <jdstrand> been a while since I looked
[22:14] <bjf> kees, look at http://people.canonical.com/~kernel/reports/sru-report.html
[22:14] <bjf> kees, looks like 805209 needs verification on maverick
[22:15] <jdstrand> kees: so bug 808934 goes to security and updates?
[22:15] <ubot2> Launchpad bug 808934 in kernel-sru-workflow "linux: 2.6.35-30.56 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/808934
[22:15] <kees> bjf: "Verification-testing" is Fix Released
[22:15] <jdstrand> bug 813507 to updates
[22:15] <ubot2> Launchpad bug 813507 in linux "linux: 2.6.32-33.71 -proposed tracker" [High,In progress] https://launchpad.net/bugs/813507
[22:15] <bjf> kees, i'm also unsure about 790754 w.r.t validation
[22:15] <bjf> kees, meant validation
[22:15] <jdstrand> and bug 811215 to security and updates?
[22:15] <ubot2> Launchpad bug 811215 in kernel-sru-workflow "linux-lts-backport-maverick: 2.6.35-30.56~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/811215
[22:15] <kees> bjf: oh
[22:15] <kees> jdstrand: in theory, yes, but hold on a sec. I want to understand what bjf is pointing out. :)
[22:16]  * jdstrand holds for one sec
[22:16] <kees> bjf: where are those bugs verified in the workflow process?
[22:17] <bjf> kees, i'm confused, the "Verification-testing" should be set to "Fix Released" when the bugs have all been verified
[22:17] <kees> bjf: "will be reverted" was 20 days ago
[22:18] <kees> bjf: yeah, I would agree.
[22:19] <kees> bjf: herton set it to fix-released on the 13th, 5 days after 790754 was marked incomplete
[22:19] <kees> jdstrand: lucid linux to -updates appears good to go, though
[22:19] <bjf> kees, yes, and without talking to either him or sconklin, i'm not sure what to tell you
[22:20] <kees> bjf: yeah, I will hold off. I just saw it sitting for a long time and then realized pitti was on vacation. :)
[22:20] <bjf> kees, i'll send email to find out what's up
[22:20] <kees> jdstrand: please ignore the maverick backport and the lucid linux for now. we'll get this sorted tomorrow when sconklin and/or herton are here
[22:20] <kees> bjf: cool, thanks
[22:21] <kees> jdstrand: sorry _maverick_ linux. lucid linux to -updates is fine
[22:21] <jdstrand> kees: what do you need me to do now?
[22:21] <jdstrand> (bug number)
[22:21] <kees> jdstrand: 813507 appears ready for copying to -updates (and not -security)
[22:22] <jdstrand> kees: 'appears ready for copying' doesn't instill as much confidence as I would hope :P
[22:22] <kees> jdstrand: hah. well, the workflow process shows it ready, and sru-report seems to agree.
[22:23] <jdstrand> kees: are you talking about http://people.canonical.com/~kernel/reports/sru-report.html? I don't know how to read that report
[22:24] <jdstrand> well, it has enough so I can figure it out
[22:25] <jdstrand> 1 bug, 588861, and jamespage confirmed it as fixed
[22:25]  * jdstrand goes to copy
[22:25] <kees> jdstrand: right, was just waiting for LP to cough that up.
[22:25] <jdstrand> though I'm not sure why 588861 doesn't have verification tags...
[22:30]  * bjf -> errand
=== bjf is now known as bjf[afk]
[22:31] <jdstrand> ok, copied
[22:31] <kees> jdstrand: thanks!
[22:32] <jdstrand> tha is a lot of steps :)
[22:32] <jdstrand> (kernel-sru-workflow)
[22:32] <jdstrand> I am not suggesting anything different; just suprised :)
[22:35] <kees> jdstrand: it's actually pretty great; the transitions are well-defined and a bot keeps us all honest
[22:36] <jdstrand> seems like it
[22:44] <skaet> re jdstrand, 813507 is ready,  I've just been blocked on it going out since last Friday by not having the right permissions or getting someone not traveling who does.   Should have been pinging you yesterday.... (thanks kees - ;) )
[22:45] <jdstrand> skaet: ack and done
[22:45] <skaet> jdstrand: THANK YOU!  
[22:45] <jdstrand> hehe
[22:46] <jdstrand> sure :)