[07:41] <smb> morning
[07:47] <abogani> smb: morning
[08:00]  * apw yawns
[08:00]  * smb pats apw 
[08:01]  * apw waves to jk- 
[08:07] <jk-> hey apw
[08:23] <ikepanhc> good morning folks
[08:26] <smb> ikepanhc, hey Ike
[08:26] <ikepanhc> :)
[08:27] <apw> moin
[09:44] <TeTeT> cking: hi there, I've used the suspend-resume script you provided in some util on a Lenovo T520 and now it's no longer returning from sleep at all - is it possible that setting the wakealarm messed something up? I checked the script, but cannot see anything ill in it
[09:46] <cking> TeTeT, I recommend using fwts to test this. install fwts and run the wakealarm test to sanity check this first.
[09:46] <cking> run "fwts wakealarm -"  to do the wakealarm test
[09:47] <cking> oops, I meant "sudo fwts wakealarm -"
[09:47] <TeTeT> cking: right now when it is sleeping, I press power button, the hd icon flashes for a split second, system goes back to sleep
[09:47] <TeTeT> cking: ok, will give that a try
[09:48] <cking> and then "sudo fwts s3 -" to do a suspend/resume tests
[09:48] <_ruben> is there any documentation on how to use the linux-meta sourcepackage (or something else) to create the equivalent of the linux-(image-)server packages for a custom flavour?
[09:50] <TeTeT> cking: bummer, I'm  stuck on Lucid due to customer requirement - any PPA for fwts?
[09:52] <TeTeT> cking: nevermind, trying to build it myself
[09:52] <cking> yep, ppa:firmware-testing-team/ppa-fwts-stable
[09:54] <cking> I've never heard of a system that seems to wake and the goes back to sleep. most unusual
[09:55] <TeTeT> cking: wakealarm tests passed, now onto suspend
[09:57] <TeTeT> cking: same symptom, hd icon blinks, then system goes back to sleep, only hard power off will restart it. Any idea what to do next? Weird is, that I've seen this system doing suspend/resumes before. The new behaviour only appeared when trying the automated suspend/resume test
[09:58] <apw> _ruben, no documentation no, but its a fairly straight forward meta package relationship
[09:59] <apw> _ruben, there are examples in the mvl-dove etc branches in the lucid meta package
[09:59] <_ruben> apw: no experience with metapackaging though
[09:59] <_ruben> will have a look
[09:59] <cking> TeTeT, so, do a clean boot and from the command prompt run "sudo pm-suspend" and see if you can wake it successfully
[10:00] <TeTeT> cking: no success, tried it from console and gnome-terminal, even unplugged power and battery one time
[10:01] <cking> TeTeT, any idea when this stopped working then?
[10:02] <TeTeT> cking: yes, after I run sus-res.sh, let me pastebin it here: http://pastebin.ubuntu.com/613108/
[10:04] <apw> OMG we have cd images
[10:05] <cking> TeTeT, so, just to clarify, S3 worked, but *after* running that script it no longer works?
[10:05] <TeTeT> cking: sort of worked, suspend worked fine, resume was shaky at best, at times graphics were utterly distorted, at times it resumed just fine
[10:06] <TeTeT> cking: I'm completely lost on what could have broken the resume completely
[10:07] <cking> TeTeT, lots of things - like misbehaving drivers or hardware, perhaps a newer kernel?
[10:07] <cking> so has this machine run S3 reliably at any point in it's past?
[10:07] <apw> or just phase of the moon, as its unrelaible to start with
[10:08] <TeTeT> cking: from what I've seen - unreliably from the start, though our customers engineer said it worked reliably for him
[10:09] <TeTeT> cking: I did a successful run of 3 manual suspend resumes this morning, but had failures before that
[10:09] <apw> TeTeT, so we need to know if it worked before, if so where
[10:09] <TeTeT> cking: so I thought it would be good to gather some metrics through an automated sus/res test and used the script you provided me a year or so ago
[10:10] <TeTeT> apw: tested it via hotkey fn-f4, suspend through menu
[10:10] <TeTeT> cking + apw : noteworthy is, that it is a laptop (T520) with Natty kernel and Lucid userland, due to customer requirements
[10:10] <cking> TeTeT, the problem is that if it's "randomly" locking up we need to get some debug out to see where it's hanging. This could be tricky if it's failing in the early resume path
[10:11] <TeTeT> the kernel comes from the backports ppa though
[10:11] <cking> ah, I'm not sure if we guarantee lucid userland working sanely with natty kernels
[10:11] <apw> https://wiki.ubuntu.com/DebuggingKernelSuspend
[10:12] <apw> TeTeT, from where ?  we don't have a backports PPA
[10:12] <TeTeT> cking: I'm quite sure we don't really support it, but it's an important customer and they'd like to demo the system tomorrow. Long term we need to find something supportable though
[10:12] <apw> TeTeT, which exact version of the kernel are they running
[10:12] <cking> apw, won't we have issues with X and drm with a lucid + natty combo?
[10:13] <TeTeT> cking: it also runs xorg-edgers, otherwise only framebuffer is available
[10:13] <jpds> Does anyone know what could be causing this error? http://pastebin.ubuntu.com/613113/
[10:13] <apw> so an untested combination then
[10:13] <TeTeT> apw: https://launchpad.net/~kernel-ppa/+archive/ppa
[10:14] <TeTeT> apw: linux-lts-backport-natty
[10:14] <apw> which VERSION
[10:14] <TeTeT> apw: sorry, 2.6.38-8.42~lucid1
[10:26] <mnemoc> so there is a ppa for oneric's kernel on natty...
[10:28] <apw> mnemoc, nope
[10:28] <apw> mnemoc, i was suggesting he takes the one in the oneiric release pocket
[10:28] <apw> just to test
[10:28] <mnemoc> ic
[10:42] <mnemoc> will adding dmesg -n 8 to /etc/init/dmesg.conf help me to get detailed netconsole since the begining?
[10:46] <mnemoc> /etc/default/rcS :)
[11:00]  * ppisati -> out 4 lunch
[11:29] <mnemoc> when trying to debug locks up on resume, does a "Magic number:" without any "hash matches" worth anything?
[11:31] <apw> mnemoc, not that i know of
[11:32] <mnemoc> thanks :-/
[11:34] <mnemoc> [    2.913282]   Magic number: 11:37:579
[11:34] <mnemoc> [    2.925935] pci_bus 0000:00: hash matches
[11:34] <mnemoc> [    2.938883] rtc_cmos 00:04: setting system clock to 2011-05-26 10:33:30 UTC (1306406010)
[11:34] <mnemoc> :'(
[14:39] <apw> ppisati, i note that the maverick to-omap4 is really old, is that on your list to rebase to master ?
[14:41] <mnemoc> apw: is the "beep" on resume from the EC, the kernel or ubuntu? the times my thinkpad resumes correctly it always beep, when it doesn't resume it doesn't beep either
[14:42] <mjg59> mnemoc: The EC
[14:44] <mnemoc> mjg59: does that imply my problem is on how the suspend is registered and not on a driver causing troubles on resume?
[14:46] <ppisati> apw: we don't rebase omap4
[14:46] <ppisati> apw: i only cherry pick CVEs IIRC
[14:46] <mjg59> mnemoc: Difficult to know
[14:46] <apw> really ? hrm i thought that was only the .38 one
[14:47] <ppisati> apw: wait, i can be wrong, let me check...
[14:47] <tgardner> apw, ti-omap4 has so much cruft in it that I don't think we can rebase it.
[14:47] <apw> tgardner, on maverick ?
[14:47] <ppisati> https://wiki.ubuntu.com/Kernel/Dev/Flavours
[14:48] <ppisati> the matrix in the low part says "no rebase"
[14:48] <ppisati> yep, never rebase an omap4 after midnight :)
[14:48] <apw> heh ok, then it also needs some love if this matrix is anything to believe
[14:48] <apw> http://people.canonical.com/~apw/cve/pkg/linux-ti-omap4.html
[14:49] <tgardner> apw, you have to cherry-pick stable and CVE updates, which makes it kind of a pain in the ass
[14:49] <apw> tgardner, ok ... well its not been done since Feb, so we need to get that done again
[14:50] <tgardner> apw, thats what we have ppisati for :)
[14:50] <apw> its lagging a lot ... ppisati another one for you :)
[14:50] <apw> needs cves and any stable updates on that one :)
[14:51] <ppisati> as for cves, i already have them in my tree on zinc, waiting for the master tree to hit -updates
[14:51] <ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
[14:52] <ppisati> about the stable update, well, i usually follow: if it's not broken, don't touch it :)
[14:52] <ppisati> i mean, if no one complains about a particular problem, i usually don't cherry pick from master
[14:52] <ppisati> e.g. the pci prefetch patch i saw yesterday
[14:52] <apw> ppisati, the problem with that approach is we get a lot of our CVEs via those stable updates, and they arn't marked as CVEs in our tree as a resul
[14:52] <ppisati> shall i really aplly it?
[14:52] <tgardner> ppisati, I think ti-omap4 only needs CVEs and perhaps some select stable updates.
[14:53] <apw> which is fine, as long as we are moniroting http://people.canonical.com/~apw/cve/pkg/linux-ti-omap4.html and applying any missing ones
[14:53] <ppisati> apw: ok
[14:53] <apw> as i say we get a lot of our cves unmarked via stable these days
[14:53] <ppisati> so i'll better follow that pages
[14:53] <apw> ppisati, more fun :)
[14:54] <ppisati> in fact, some of the imx51 are only on that page
[14:54] <apw> http://people.canonical.com/~apw/cve/pkg/ALL-linux.html ... has all of them
[14:55] <apw> tgardner, ^^ has a complete view of all our open ones
[14:56] <tgardner> apw, hmm, pretty colors
[14:56] <apw> tall piles of orange up the page == bad :)
[14:56] <tgardner> apw, what is the difference between yellow and orange?
[14:57] <apw> priority of the bug
[14:57] <apw> i think orange is more important
[14:58] <apw> of course we expect the arm branches to lag where they are rebases until the rebases are pushed
[15:24] <JFo> that was interesting. machine froze and nothing I had done today was saved. For instance; e-mail that I read, documents I had changed and saved, etc.
[15:24] <JFo> very odd
[15:25] <charlie-tca> oh, I know that one, too. 
[15:26] <charlie-tca> I did that yesterday and had to force the hard restart
[15:26] <JFo> yeah, me too
[15:26] <JFo> had to softswitch the machine off
[15:26] <JFo> but the mouse pointer was still working
[15:26] <sconklin> tgardner: I'm going to apply upstream stable to Natty master-next today unless you've already started working on it
[15:26] <JFo> was like the background froze
[15:26] <charlie-tca> and I even ssh'd in and ran top and ps, none of my applications on the desktop showed up anywhere
[15:26] <tgardner> sconklin, go ahead
[15:27] <sconklin> ack
[17:01] <JFo> <-lunch and errands.
[17:17] <bjf> sbeattie, has there been any thoughts on breaking up qa-regression-testing so it's not a 650MB pull just to get the scripts?
[17:18] <sbeattie> bjf: yes. if you have the tree locally, the scripts/make-test-tarball will pull together just the bits for a specific test script.
[17:18] <sbeattie> bjf: it's less than ideal, but for some use cases it works okay.
[17:19] <bjf> sbeattie, but that means i have to pull down the 650MB so i can create a smaller tar file ?
[17:20] <sbeattie> bjf: yes. Like I said, it's less than ideal. OTOH, once it's down, a bzr pull or bzr up will keep it up to date, and you won't need to pull over and over.
[17:21] <sbeattie> (that's one thing I miss from subversion, the ability to just check out part of a tree)
[17:22] <bjf> sbeattie, i understand that once i have it it's easier to keep updated, but I'm thinking of how to get the tests onto systems to be re-imaged and tested
[17:24] <sbeattie> bjf: right. we've tended to have the test-driver generate the specific tarball(s) from a cached copy of the bzr tree, rather than shove the entire tree onto the test system.
[17:25] <bjf> sbeattie, sure, i just worry that you now have a snapshot that "someone" needs to be diligent about keeping refreshed with the latest changes, and that's sure to bite us in the ass now and then
[17:25] <sbeattie> bjf: what's annoying is, of that 650MB, 300MB of it is sitting in .bzr
[17:25] <sbeattie> bjf: understood.
[17:34] <hggdh> bjf, sbeattie: this is the approach I did on the current kernel SRU tests -- I have a helper build script that grabs all updates needed from a local branch of the QRT, and rebuilds the test tarball
[17:35] <hggdh> bjf, sbeattie: another thing to keep in mind is the QRT is continuously tinkered with -- updates, corrections, etc
[17:35] <bjf> hggdh, that's why i don't like taking snapshots
[17:36] <hggdh> bjf: I understand, but given the QRT is continuously updated, there is not much options (and also given the limitations on bzr)
[17:37] <bjf> hggdh, if i understand you, you are saying you need to snapshot because QRT is also where open development is happening at the same time
[17:38] <hggdh> bjf: indeed. 
[17:38] <bjf> hggdh, well, to my thinking, that's broken, we should be using "releases" of QRT, how do you know that the snapshot you just took is in a state to be used?
[17:40] <hggdh> bjf: this is a chicken-and-egg problem... most of the (current) updates that affect kernel testing were done _because_ of the kernel testing; also, QRT is updated to add new tests
[17:41] <hggdh> bjf: and -- on my view -- we need them. For standard -- non-security-related -- we do not need to update (and I have been using the autotest.kernel.org pretty much stable
[17:41] <hggdh> for example
[17:41] <bjf> hggdh, i disagree but this isn't the right place to have that discussion
[17:42] <hggdh> bjf: OK
[17:43] <sbeattie> bjf: we try hard to ensure commits to QRT are complete and don't break things. We don't always succeed...
[17:44] <bjf> sbeattie, i understand
[17:44] <jdstrand> bjf: 'open development' is, while true, somewhat mischaracterized. for example, the kernel tests are updated when regressions are found, when there are new reproducers for CVEs, when the test is wrong on an older release. the scripts are also coded with release specific items and commits should not be made to qrt without verifyingon all releases
[17:45] <jdstrand> of course, things do change, but generally speaking, the tests are supposed to become better, more accurate and more comprehensive for *all* releases, not just devel, for example
[17:47] <sbeattie> jdstrand: do you know if there's anything we can do to better pack the tree? .bzr is 300MB locally.
[17:47] <bjf> jdstrand, i care about all kernel releases, stable as well as devel. i just think that there are problems with the process
[17:47] <jdstrand> we've talked about 'releases' of qrt, but that ends up being a lot of overhead. eg, we have a test case for a new cve that affects hardy - oneiric. we can update in a bunch of trees or just one
[17:47] <jdstrand> sbeattie: I do not, though I think a fresh checkout should reduce that
[17:47]  * jdstrand is not sure
[17:47] <sbeattie> bjf: we also care about all the releases; if anything where QRT can lag is in the devel release.
[17:47] <jdstrand> I pulled out the vm that was in there
[17:48] <jdstrand> I also just now gzipped the stuff in install/get_file_info_results/
[17:48] <sbeattie> jdstrand: yeah, saw the commit, thanks.
[17:48] <jdstrand> bjf: I wasn't implying you didn't care about other releases, I was making the point that commits we make must work on all of them
[17:49] <jdstrand> but, people will always have to pull from somewhere, if for no other reason than to get the latest reproducers
[17:49] <jdstrand> so I'm not sure how to fix that other than with scripting
[17:50] <jdstrand> as for the size, that is a problem, but creative 'mirroring' can help there
[17:50] <bjf> jdstrand, yes, people will always have to pull from somewhere
[17:51] <jdstrand> so, fwiw, I just branched it fresh and it is now 563M. still huge, but slightly better
[17:51] <bjf> jdstrand, the problem i'm most having here, is if all ubuntu projects worked they way you believe QRT is working and should continue to work, we'd never have anything in a state to ship
[17:51] <ubuser> can someone help me
[17:51] <apw> bjf, who did we liase with in -security over dapper bugs ?
[17:52] <jdstrand> sbeattie: I was wrong, .bzr is still 305M
[17:52] <ubuser> i cant get my pc to boot, i tried installing grub2, now it is giving me error 15 
[17:52] <ubuser> is there a way around this?
[17:52] <bjf> apw, probably kees to start with
[17:52] <bjf> apw, you have one you think should go in?
[17:52] <jdstrand> bjf: I understand your point, but qrt isn't 'shippable'. we don't want it in a frozen state, because we want the new tests (unlike saw hardware cert)
[17:52] <apw> bjf, do you know what we are meant to do with dapper entries?  as we're not planning another uplaod ?
[17:53] <jdstrand> there are always new SRU bugs and CVE reproducers, etc that we want to ship
[17:53] <bjf> apw, i think "ignored" is acceptable state
[17:53] <jdstrand> apw: oh, that was me
[17:53] <apw> bjf, and we have carte-blanc to apply those to anything that open ?
[17:53] <ubuser> please help me get past the grub menu!!! im stuck at boot screen
[17:54] <apw> jdstrand, ^^
[17:54] <jdstrand> apw: I went through all the dapper ones and gave a list of what was important to fix and what wasn't. I forget where I sent it, but iirc it was all 'done'
[17:54] <apw> ubuser, what do you see ?
[17:54] <jdstrand> that was last month
[17:54] <ubuser> i see grub error 15 at boot screen
[17:54] <apw> jdstrand, since then there are new ones added, are you going to sort through those as well or do we just wack them
[17:54] <ubuser> escape button to bypass this error would pwn
[17:55] <sbeattie> bjf: in particular, if you're testing a kernel update, we may have just committed reproducers for a specific issue that that kernel is intended to address.
[17:55] <bjf> sbeattie, ack
[17:55] <apw> ubuser, it seems that Error 15: means file not found, so something it needs is missing
[17:56] <apw> ubuser, were you using grub beforehand ?
[17:56] <ubuser> yes
[17:56] <[7]> ubuser: "error 15" means that whatever is running there is not grub2
[17:56] <jdstrand> apw: new ones ask kees about. that said, if they are 'low' priority, ignore for sure. if they are 'high' then fix. 'medium' is a more pragmatic approach that I you and kees can decide on. eg, if it is in a driver that no one uses, ignore. if it is something on everyone's machine, maybe fix (but still, maybe not)
[17:56] <ubuser> i tried to install it again, i wanted to fix my video settings, and everyone in the ubuntu channel kept telling me to update
[17:56] <ubuser> and i updated, b4 i went to sleep
[17:56] <jdstrand> s/that I you/that you/
[17:56] <ubuser> but i had my video working, now i got screweedddd
[17:57] <apw> so what exactly did you type to install grub
[17:57] <broder> is there anything in particular i can do to get more attention for bug #784335? i'm no kernel debugger myself, but i'm happy to mangle the machine in question in any way that would be helpful
[17:57] <ubot2> Launchpad bug 784335 in linux "Heavy network utilization with r8169 leads to kernel panic" [Undecided,Confirmed] https://launchpad.net/bugs/784335
[17:57] <jdstrand> apw: fyi, kees will be online in a little while
[17:58] <[7]> ubuser: also, your question isn't really related to the kernel, right?
[17:59] <ubuser> mine is
[17:59] <apw> jdstrand, thanks dropped him an irc asking him to deal with it :)
[17:59] <ubuser> but im so far screwed it aint funny
[17:59] <jdstrand> hehe
[17:59] <ubuser> no luck for m3 yay
[17:59] <ubuser> im having video errors, but that doesnt matter.
[17:59] <ubuser> im stuck without a pc
[17:59] <[7]> ubuser: no, it isn't. it's related to grub, not to the kernel. anyway, try this: https://help.ubuntu.com/community/Grub2#Reinstalling%20from%20LiveCD
[18:00] <apw> yeah, thanks [7]'s suggestion is the first step
[18:00] <ubuser> kernel = radeon.new-pll=0
[18:00] <ubuser> thats the trouble im having with kernel
[18:00] <ubuser> i need to add it
[18:00] <ubuser> but i cant, cuz i cant get on my pc
[18:00] <ubuser> i need to delete grub
[18:00] <ubuser> idk how
[18:00] <[7]> no, you need to install grub2
[18:00] <ubuser> i cant no cd
[18:00] <jdstrand> bjf, sbeattie: the size of qrt is a long-standing issue that has always bothered me
[18:00] <apw> ubuser, you cirtainly don't need to delete grub ... thats what boots your system
[18:01] <apw> ubuser, you could use a memory stick instead
[18:01] <[7]> as apparently your boot partition contains grub2 files but your mbr contains grub 0.97
[18:01] <jdstrand> bjf, sbeattie: I just tried bzr co --lightweight ./qa-regression-testing/ qrt-test and qrt-test is 259M
[18:01] <sbeattie> jdstrand: me too, as someone at the end of a slow dsl line.
[18:01] <ubuser> how can i install the new grub easily then?
[18:01] <[7]> by booting a live system on that box
[18:01] <jdstrand> bjf, sbeattie: ymmv, I've not ever used --lightweight before just now
[18:01] <ubuser> i got a ubuntu 5.10 cd, but idk if thatll work
[18:02] <apw> 5.10 ... heh what the heck was that warty ?
[18:02] <jdstrand> du -sh ./.bzr
[18:02] <jdstrand> 476K	./.bzr
[18:02] <ubuser> i am currently on 10.04
[18:02] <ubuser> i updated...
[18:02] <ubuser> i jus have that cd..
[18:02] <[7]> it should be doable with 5.10 as well, but there probably aren't instructions for it
[18:02] <[7]> another option would be a grub rescue disk
[18:02] <ubuser> okay so put the cd in and click repair maybe? ill brb
[18:02] <sbeattie> jdstrand: I wonder if  bzr pack --clean-obsolete-packs would help
[18:02] <[7]> ubuser: it's not as simple as that
[18:02] <sbeattie> jdstrand: also, another experiment would be to try bzr export
[18:03] <ubuser> great..
[18:03] <ubuser> i wish u could hit escape, thats mad lame
[18:03] <jdstrand> sbeattie: I think the other big opportunity is scripts/mysql/employees_db/*
[18:03] <[7]> you'll need to rewrite the mbr from the command line, or use a more recent ubuntu version and follow the instructions i linked
[18:03] <jdstrand> sbeattie: 164672 ./mysql
[18:04] <[7]> hm, or you could temporarily drop some grub0.97 files on the /boot partition using 5.10, that might work
[18:04] <jdstrand> sbeattie: those are all text files and could be compressed-- but we would need to adjust test-mysql.py
[18:04] <ubuser> im not downloading another gig, i will throw it in the streets
[18:04] <jdstrand> sbeattie: could probably shave another 150M off right there
[18:05] <jdstrand> sbeattie: iirc, I tried pack --clean-obsolete-packs once and it didn't do as much as I had hoped
[18:07] <jdstrand> sbeattie: before updating mysql, it might be worth talking to mdeslaur, since he might not have compressed for a reason
[18:08] <jdstrand> sbeattie: after that, it is conceivable we could split out data/-- it is <40M and I'm not sure the benefit would outweigh the pain of having to deal with that change properly
[18:10] <sbeattie> jdstrand: I'm dubious of splitting out data/ as well.
[18:12] <sbeattie> jdstrand: realistically, scripts and data is 110MB (with mysql/ compressed), that's better than the current situation.
[18:12] <jdstrand> totally!
[18:13] <sbeattie> jdstrand: I could be convinced to split out results tracking to a different tree, but even as it is, I forget to update that part of the tree.
[18:13] <jdstrand> 650M+ to 110M is pretty good :)
[18:13] <jdstrand> well, results is only 9M
[18:25] <apw> the sha1 to the cve-tracker ... want to see what the update script does
[18:25] <jdstrand> sbeattie: fyi, in some cases I would have a tarball for a directory to unpack. you could theoretically create employees_db.tar.gz, add a bzrignore and a line or two of code and by done with it (there are likely other ways to handle it)
[18:25] <jdstrand> s/and by/and be/
[18:25] <jdstrand> anyhoo, my 2 cents. I'm moving along now :)
[18:26] <kees> apw: no, because we talked about creating a new bug and duping the old one.
[18:26] <bjf> kees, you know where the bug-opening script live? you can run it thus: "create-cve-tracker --staging --cve=2011-????" and it will create a bug on the qastaging server and give you a url to it to look at
[18:26] <kees> apw: but I don't know where to find the new bug creator tool
[18:26] <bjf> kees, it is in the kteam-tools git repo
[18:26] <kees> bjf: okay, one sec....
[18:27] <bjf> kees: git://kernel.ubuntu.com/ubuntu/kteam-tools.git
[18:27] <apw> kees, yeah thats the rigth thing to do, but presumably that would end up updating the cve tracker to have an extra upstream sha1
[18:27] <apw> and as we don't ahve the sync i wanted to add it manually to see if my scripting will revoke the complete status
[18:27] <kees> right, I want to get the steps in the right order
[18:27] <apw> as it should
[18:29] <kees> ImportError: No module named lpltk.service
[18:29] <kees> is that part of arsenal?
[18:29] <tgardner> kees, launchpad API I think
[18:30] <kees> hm, no, I have all the upstream LP bits installed, afaik. I use it for the QA and Security tools
[18:30] <bjf> kees, new arsenal lpltk
[18:30] <kees> bjf: do you have the bzr location of that handy?
[18:30] <bjf> kees, getting it
[18:30] <bjf> kees, bzr+ssh://bazaar.launchpad.net/~arsenal-devel/arsenal/python-launchpadlib-toolkit/
[18:31] <kees> thx
[18:31] <tgardner> bjf, is there a way to automate that? or at least indicate whats missing? I'll sure as hell forget next time I'm on  a new machine.
[18:32] <bjf> tgardner, that's why we want to make "kteam-tools" a package with "lpltk" a dependency
[18:32] <bjf> tgardner, but in the mean time, i'll think about it
[18:32] <tgardner> bjf, ok, packaging is likely fine.
[18:33] <kees> eeeeww, it's using desktop auth?
[18:33] <kees> bryce: I thought you fixed arsenal to not do this. :)
[18:35] <apw> kees, is the cve-tracker going to have the bug number in it, i assume so
[18:35] <kees> apw: one sec
[18:35] <bryce> kees, yes
[18:36] <kees> bryce: maybe it doesn't do it for the qastaging server?
[18:36] <kees> I just got prompted for "desktop integration"
[18:38] <doko> rtg, apw, ogasawara: uploaded gcc-4.6, no linaro changes, only fsf updates, currently building
[18:38] <ogasawara> doko: ack, thanks
[18:38] <bryce> kees, it's fixed in LaunchpadService, but some script use lpltk.service
[18:39] <apw> doko, thanks for the heads up
[18:39] <bryce> which I think brad means to be a symlink to the former but maybe not?
[18:39] <bryce> bbiab
[18:40]  * kees doesn't know, but ./create-cve-tracker is just hanging.... digging...
[18:40] <apw> kees, it takes some minutes to run and says nothing
[18:42] <kees> oh, whoa, I bet it's the linear CVE search!
[18:42] <kees> work-around for that is to just add a CVE comment, and that will link to the CVE even if LP doesn't know about it.
[18:45]  * apw has to wander ... kees let me know when the cve tracker has the bits and i'll see what my tooling does
[18:46] <kees> apw: okay
[18:47] <kees> bjf: that's weird, the script told me it created 718952 on staging, but that's not the right bug.
[18:47] <bjf> kees, looking
[18:49] <bjf> kees, https://qastaging.launchpad.net/ubuntu/+source/linux/+bug/718952   looks good to me!
[18:49] <ubot2> Launchpad bug 718952 in grub2 "no longer boots because ext4 /home lost its UUID" [Undecided,New]
[18:49] <kees> bjf: it's not reported by me, not a kernel bug, doesn't have the packages, nominations, etc.
[18:50] <kees>  ** Error: An exception was thrown after creating the bug, therefore, one should have been created. And you may have to fix it up by hand.
[18:50] <kees> https://bugs.staging.launchpad.net/bugs/718952
[18:50] <bjf> kees, i'm looking at it right now, it's by you, is a kernel bug, and has the nominations
[18:50] <bjf> kees, you are not looking at qastaging
[18:50] <kees> oh, well, that's the url the script reported. heh
[18:50] <bjf> kees, look at the url i just posted
[18:50] <kees> yeah, that one looks okay.
[18:50] <bjf> kees, ah! will fix that
[18:51]  * kees adjusts too
[18:51] <kees> *sigh* thanks LP OOPS-1972QASTAGING77
[18:51] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=1972QASTAGING77
[18:53]  * kees tries again
[18:53] <bjf> kees, fixed that bug, thanks
[18:54] <kees> np, I've got a few other updates too... but I want to actually finish one bug creation without it failing...
[18:54] <kees> AttributeError: 'Bug' object has no attribute 'newMessage'
[18:54] <kees> wtf??
[18:54] <kees> (my addition, but it's part of the API!)
[18:54] <kees> https://edge.launchpad.net/+apidoc/1.0.html#bug
[18:55] <bjf> kees, let me run it and see
[18:56] <kees> bjf: that's a change I made
[18:56] <kees> I replaced the linear CVE search with:
[18:56] <kees>                     # Link the appropriate cve to the bug.
[18:56] <kees>                     # Cannot safely use 'linkCVE' due to LP: #439470
[18:56] <kees>                     print "Linking to %s ..." % (title)
[18:56] <kees>                     bug.newMessage(content=title)
[18:57] <bjf> kees, where did you make that change?
[18:58] <kees> http://paste.ubuntu.com/613387/
[18:59] <bjf> kees, bug is an instance of an lpltk Bug class
[19:01] <kees> oh, so it is. :)
[19:02]  * kees swaps to add_comment
[19:02]  * kees is not used to using lpltk :)
[19:02] <kees> I've done too much raw LP API coding
[19:05] <kees> \o/ https://qastaging.launchpad.net/bugs/718955
[19:05] <ubot2> Launchpad bug 718955 in beat-box "icon for currently playing song doesn't make sense" [Low,Fix released]
[19:05] <bjf> kees, timeout error :-(
[19:06] <kees> me too... trying again and again. qastaging sure is useful
[19:06] <kees> but at least the script completed without error
[19:06] <bjf> kees, when it's up, and working, yes
[19:06] <bjf> it doesn't know that lucid is not supported
[19:06] <bjf> sorry, that should be karmic
[19:07] <kees> I can fix that. the cve tracker has all that logic.
[19:08] <bjf> kees, i just depend on LP that way I don't get out of sync with what is really supported and what my db says is supported
[19:08] <bjf> kees, note, qastaging is different from staging, qastaging is yet another, different snapshot of the LP db
[19:09] <bjf> kees, the staging server was just too unreliable for dev work and the LP folks said to use qastaging (it's marginally better)
[19:10] <kees> ah! I see now. the .active test. nice.
[19:10] <kees> qastating is just out of date.
[19:10] <bjf> yes
[19:11] <kees> bjf: how do you want me to send update to kteam-tools? [PATCH] to kernel-team list?
[19:11] <kees> *updates
[19:11] <bjf> kees, yup, that works
[19:16] <kees> bjf: okay, sent
[19:52] <vanhoof> do we have a max recommended amount of memory on amd64 flavours (maverick/natty/oneiric) ?
[19:53] <vanhoof> I know the theoretical limits of x86_64, but are there any practical limits that are recommended?
[19:59] <bjf> vanhoof, nothing that i'm aware of
[20:38]  * jjohansen -> lunch
[21:15] <mak_ubu10> hey... my computer takes 25 mins to boot...
[21:15] <mak_ubu10> can anybody help me....
[21:15] <mak_ubu10> it waits for a long time.... after showing "Loading hardware drivers"
[23:15] <ubuser> sound for ubuntu plz
[23:26] <ikonia> ubuser: stop joining random channels and asking, we are dealing with your problem elsehere