[00:31] <poolie> jelmer, what's the eta for testing daily builds for real?
[00:31] <poolie> by which i mean on production launchpad?
[00:31] <jelmer> poolie: basically we're waiting for IS to open some ports
[00:36] <jelmer> poolie: That would make it possible to use on edge/staging. I'm not sure when it'll be enabled on production, but I imagine it would be soon afterwards unless we find things that need to be fixed.
[02:58] <sinzui> thumper, I am starting the next review...
[02:58] <thumper> sinzui: ta
[02:59] <sinzui> I am concerned about ec2. I see a failure that must be from my branch, but ec2 sent me a success message
[02:59] <wgrant> Well, Windmill is switched off in EC2 at the moment, so that was always going to happen.
[02:59] <sinzui> This happened last Thursday too. my confidence is shaken
[03:01] <sinzui> I think lib/lp/blueprints/tests/../stories/standalone/xx-personviews.txt and lib/lp/soyuz/tests/../stories/soyuz/xx-distributionsourcepackagerelease-pages.tx are broken in trunk
[03:01] <sinzui> The last one was run by StevenK before he sent it off to  PQM. it had unicode in it which cause ec2 to barf
[03:03] <rockstar> Is there a way I can run a single test in ec2?  It's one that fails with the GPGmeError on my local box.
[03:03] <wgrant> Erm, what was the failure in the latter file?
[03:04] <wgrant> That looks like it could be one of mine.
[03:04] <wgrant> rockstar: What's the gpgme error?
[03:04] <wgrant> Is it the one with the one-liner fix?
[03:04] <sinzui> I want a thunder dome form test runners, pqm vs ec2 vs buildbot. 3 runners enter one leaves
[03:04] <rockstar> wgrant, I don't remember specifically, but it's a known issue (one that abentley spent some time trying to sort out)
[03:05] <lifeless> sinzui: you forgot hudson
[03:05] <lifeless> 2 in 1 out, 2 in 1 out, 2 in 1 out :)
[03:05] <lifeless> thumper: I'd like a link to activereviews on https://edge.launchpad.net/lmirror/trunk
[03:06] <lifeless> thumper: what do you think?
[03:06] <rockstar> lifeless, no tournament, battle royale!  :)
[03:06] <sinzui> wgrant, the fault was smart quotes pasted into actual test. the test was not loaded run because of a decode error. StevenK ellipsisised the quotes and ran the test locally before submitting it.
[03:06] <wgrant> sinzui: Yeah, and it is now broken because of my change last night.
[03:06] <sinzui> I am preparing a fix for the two tests...if the error really is just the tests
[03:06] <wgrant> So it wasn't running before?
[03:07] <sinzui> right, it did not run.
[03:07] <sinzui> I have seen this before when I used to hack a lot in answers
[03:07] <thumper> lifeless: in the code for this series ?
[03:07] <lifeless> yeah
[03:07] <thumper> lifeless: just targetting the series branch?
[03:07] <lifeless> yeah
[03:08] <wgrant> sinzui: http://pastebin.ubuntu.com/440648/
[03:08] <thumper> sure
[03:08] <lifeless> one less click, one step closer to series-are-just-big-branches
[03:08] <sinzui> wgrant, regardless of who changed it and who fixed it. we are getting mixed message from test runs about whether is it broken
[03:08] <wgrant> sinzui: are we? StevenK probably fired the test off before my thing landed.
[03:08] <thumper> lifeless: in which case we should add a codebrowse link too
[03:08] <lifeless> thumper: YES
[03:09] <lifeless> thumper: that would make many people happy
[03:09] <wgrant> It's been in devel only 13 hours.
[03:09] <thumper> lifeless: maybe not many, maybe just a few
[03:09] <lifeless> thumper: maybe
[03:09] <lifeless> thumper: Lots of people get lost finding codebrowse
[03:09] <thumper> lifeless: I think many people would be happy if we had a bigger brighter "see the code here" on the front page
[03:09] <lifeless> starting at lp.net/PROJECT
[03:09] <poolie> hi
[03:09] <lifeless> thumper: yes
[03:09]  * thumper agrees
[03:09] <wgrant> Well, that's because everywhere other than LP has codebrowse integrated into the app.
[03:10] <thumper> wgrant: that's true
[03:10] <poolie> if i write to a python logger from inside launchpad's mail processor, will that just turn up in a log file in product?
[03:10] <poolie> *production
[03:10] <thumper> wgrant: I'd love to have loggerhead more integrated, but it isn't up to it just yet
[03:10] <lifeless> poolie: I think it has its own system
[03:10] <lifeless> you raise an event
[03:10] <poolie> i see some other code uses it...
[03:10] <sinzui> wgrant the error is different now, and this command certainly confirms the unicode is gone:  iconv -f ascii lib/lp/soyuz/stories/soyuz/xx-distributionsourcepackagerelease-pages.txt > /dev/null
[03:10] <thumper> poolie:  what are you after?
[03:11] <thumper> poolie: and yes, writing to a logger should end up in the process-mail logfile
[03:11] <wgrant> sinzui: The diff I pasted fixes it in an up-to-date devel.
[03:12] <poolie> i want to log the results of the dkim check
[03:13] <sinzui> wgrant, I just got this which matches the error I see in buildbot: http://pastebin.ubuntu.com/440653/
[03:14] <wgrant> sinzui: That's what my diff is for.
[03:14] <wgrant> I broke that test last night.
[03:14] <sinzui> ah!
[03:15] <sinzui> sorry, I was promoted over my abilities years ago.
[03:16] <lifeless> darn
[03:16] <lifeless> I forgot my second battery
[03:16] <lifeless> ah well, not like I'll need it on a cross-tasman hop :P
[03:17] <sinzui> wgrant, thank you. I committed that fix to my branch
[03:17] <wgrant> sinzui: Thanks, and sorry.
[03:18] <wgrant> What caused someone to notice and reenable it?
[03:18] <wgrant> Remarkably bad timing.
[03:29] <lifeless> ok, later - ciao
[03:39] <sinzui> thumper, I am starting your review again after dealing with the buildbot distraction.
[03:39] <thumper> sinzui: the second review?
[03:40] <thumper> sinzui: I'm working on the branch subscription one right now
[03:41] <lifeless> I like the iwlagn driver
[03:41] <lifeless> lets me change mac addresses *and doesn't filter its own traffic*
[03:42] <wgrant> Its MAC spoofing functionality was very handy at LCA.
[03:42] <wgrant> Since the hotel granted 30 minutes free Internet connectivity per day.
[03:43] <lifeless> yes
[03:43] <lifeless> this waiting area is 30/4 hours, which is == for me :)
[03:43] <lifeless> n+1, associate again.
[03:43] <wgrant> Yep.
[03:44] <mwhudson> :)
[03:46] <thumper> sinzui: where is the code that does the magic user.in_admin et al?
[03:46] <thumper> sinzui: for the security adapters
[03:46] <thumper> sinzui: I'd love to move the code specific adapters out of that file
[03:46] <sinzui> .me thinks
[03:46] <sinzui> something "roles"
[03:47] <thumper> sinzui: although I do recall that the security file is "special"
[03:47] <thumper> sinzui: and processed by a script in a special way
[03:47] <thumper> sinzui: to register the security adapters
[03:47] <thumper> personally I'd prefer a metaclass
[03:47] <wgrant> It's not that special. There's just an <authorizations> ZCML directive referencing it.
[03:50] <thumper> wgrant: oh, is that all?
[03:50]  * thumper tries to move some code ones :)
[03:51] <wgrant> Yeah, it looks like it should work fine if you have another one.
[03:51] <wgrant> Since it just registers adapters.
[03:51] <thumper> hmm...
[03:51] <thumper> perhaps not in this branch...
[03:51] <thumper> later.
[03:51]  * thumper must not get distracted
[03:51] <wgrant> But yes, a good idea to chop that damn file up.
[03:57]  * thumper collects children
[04:00] <sinzui> thumper, you have my RC for the second branch.
[04:07] <poolie> are the python logging logs recorded anywhere special during a unit test?
[04:23] <thumper> sinzui: ta
[04:26] <poolie> thumper, is there any way to get into pdb inside a launchpad unit test?
[04:26] <thumper> -D
[04:26] <poolie> it looks like stdin is redirected if i just call set_trace
[04:26] <thumper> poolie: sometimes it is
[04:27] <thumper> it depends on the layer
[04:27] <thumper> and if it is a subprocess test
[04:27] <thumper> not always easy to do
[04:27] <poolie> ok thanks
[04:27] <thumper> bin/test -vvt some_test -D *should* drop into the debugger on a fail
[04:28] <poolie> thanks
[04:29] <poolie> also do you know off hand why things are marked with IWeaklyAuthenticatedPrinciple
[04:29] <poolie> rather than being marked if they're strongly authenticated
[04:29] <poolie> it doesn't really matter, it just seems backwards
[04:29] <poolie> so i wondered if there was a reason
[04:41] <poolie> thumper, my test, after parsing the email, gets
[04:41] <poolie> ForbiddenAttribute: ('email', <Person at 0xe73280c name16 (Foo Bar)>)
[04:41] <thumper> preferredemail.email
[04:48] <thumper> sinzui: being bitten by two things
[04:48] <thumper> sinzui: You should not import BranchSubscriptionEdit from canonical.launchpad.security
[04:48] <thumper> sinzui: and ForbiddenAttribute: ('in_admin', <Person at 0xca7e950 ...
[04:48] <thumper> :(
[04:48] <thumper> too much special casing
[04:49] <sinzui> yuck
[04:49]  * thumper thinks
[04:50]  * thumper could avoid the first by making lp.code.security and putting the class in there with the configuration change
[04:50] <thumper> and then not using the "special in_...." methods
[04:51] <thumper> AAARRRRGGGHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!
[04:52] <thumper> canonical.launchpad.security line 452
[04:52] <sinzui> odd, I am already there
[04:57] <wgrant> thumper: So you get a different object if you're in another module?
[04:57] <poolie> thanks thumper that fixed it
[04:57] <thumper> wgrant: which question?
[04:57] <wgrant> Or are you grabbing another person manually and not adapting to IPersonRoles?
[04:57] <wgrant> The ForbiddenAttribute.
[05:00] <thumper> the IPersonRoles thing will fix the second issue
[05:01] <poolie> actually wgrant (hi) do you know why we have IWeaklyAuthenticatedPrincipal rather than IStronglyAuthenticatedPrincipal?
[05:02] <wgrant> poolie: No idea, sorry.
[05:02] <thumper> yes
[05:02] <thumper> poolie: it is because the email code was written second
[05:02] <poolie> ok... and?
[05:03] <thumper> poolie: and I'm guessing that all the existing code wasn't wanted to be updated to check for strongly authenticated
[05:04] <poolie> mm i can imagine that
[05:04] <poolie> i just wondered if it was easier for them to assert the absence of IWeakly... than to check for IStrongly
[05:04] <poolie> it's just curiousity
[05:32]  * _thumper_ cleans as visitors coming, back tonight
[06:02]  * sinzui find bed
[06:08] <StevenK> (I think ...)
[06:08] <StevenK> thumper: Oh, duh. Thanks. :-)
[06:08] <thumper> np
[06:24] <BjornT> poolie: IWeaklyAuthenticatedPrincipal is really old code. iirc, it's really a start of a rework of the security system, that didn't get finished. the idea was to have both IWeaklyAuthenticatedPrincipal and IStronglyAuthenticatedPrincipal, but the latter never got added. the end result would be to have different security adapters for the two
[06:56] <poolie> ah thanks BjornT
[07:32] <adeuring> good morning
[09:15] <mrevell> Morning
[10:47] <krkhan> i'm getting the "nonce used already" error no matter what value i choose for the nonce. i've even tried FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF as the value
[10:47] <krkhan> (for the api reqs)
[10:49] <krkhan> is there a way for clearing the nonce records
[12:23] <jml> krkhan: look inside ~/.launchpadlib/, there's probably a file you can delete
[12:23]  * jml going offline to get some work done
[12:27] <maxb> If krkhan is choosing nonces, this presumably means not using launchpadlib
[12:34] <james_w> no, the error is misleading I think. I've seen that before, but I can't remember the cause now
[12:41] <krkhan> i wasn't using launchpadlib. i wanted to clear the cache at launchpad server's side. anyways, i have disabled nonce checking for the time being as a workaround
[12:42] <krkhan> i have another question though. i'm currently using the cycle of "make run; change code; ctrl-c; make run again" to play with lp's code. make run takes around 30 seconds to launch each time and it's a bit cumbersome. is it possible to modify lp's code while it's running?
[14:12] <james_w> krkhan: were you using lp.me by any chance? Or accessing anything else that will result in a redirect?
[14:12] <james_w> if you get a redirect then you need to re-sign the resulting request, not send the same headers to the new URL
[15:03] <mars> gmb, ping, there is something odd going on here.
[15:04] <mars> gmb, I ran bzr branch -r 9415 lp:~gmb/launchpad/hook-up-stored-proc-boom-bug-585803
[15:04] <gmb> mars, Ah, the phrase I love to hear Friday of week 3
[15:04] <mars> Good!  We are on the same page :)
[15:05] <mars> gmb, so I ran that test locally, r9415 as the SUCCESS mail says, and the test passes?  Does it work for you too?
[15:05] <gmb> mars, let me just try.
[15:05] <mars> going to try it via 'make check'
[15:06] <gmb> K
[15:12] <mars> passes 'make check'
[15:12] <mars> make check TESTOPTS='-t xx-temporary-blob-storage_txt'
[15:13] <mars> so either a test isolation failure + testrunner fault, or a test environment factor + testrunner fault
[15:14] <gmb> mars, Weird.
[15:14] <gmb> mars, But it *should* fail
[15:14] <gmb> Ah,... or should it
[15:14] <gmb> Hmm.
[15:14] <krkhan> james_w: i was requesting a non-existent page actually. i guess that was the root of all evil
[15:15] <mars> gmb, your mail says "a stray line of output I'd left in a pagetest", but it looks like the doctest failure is producing "{}" when it shouldn't?
[15:15] <mars> gmb, that means the error is that "{}" does not appear in the doctest when it should, correct?
[15:15] <gmb> mars, What I meant was that I'd left 'job.metadata' in the test, so it outputted {}, which I hadn't accounted for
[15:15] <gmb> So by right, it *should* have failed.
[15:16] <gmb> mars, Ah, but, it fails locally
[15:16] <mars> gmb, ok, so why is job.metadata not producing that same output here.
[15:16] <gmb> mars, I have *no* idea.
[15:16] <mars> gmb, it fails for you locally?  What command?
[15:16] <gmb> bin/test -cvvt xx-temporary-blob-storage
[15:17] <mars> wtf, it failed this time
[15:17] <gmb> (!)
[15:19] <mars> argh, my mistake, I was testing "xx-temporary-blob-storage_txt" instead of "xx-temporary-blob-storage"
[15:19] <mars> gmb, ok, thanks!  I can reproduce locally.  Now to figure out why it reports success.
[15:20] <gmb> mars, Best of luck :)
[15:20] <gmb> let me know if I can help further
[15:20] <mars> gmb, ok.  I'll be out for a while, probably up to your EOD, so we may have to pick this up on Monday
[15:20] <mars> make that Tuesday, Monday is a holiday there
[15:21] <gmb> mars, It's a national holiday Monday here too, so no worries :)
[16:10] <rockstar> Is anyone working on the db_lp failure?
[16:17] <jelmer> rockstar: I think curtis said he was going to look into it
[16:20] <noodles775> jelmer, rockstar, sinzui: I think there's some confusion there... sinzui it looks like you replied to the db_lp failure, but meant to reply to the lp failure (in your email)?
[16:21] <rockstar> noodles775, I'm handling the db_lp one.
[16:24] <sinzui> rockstar, db_lp is fixed in devel
[16:24] <noodles775> rockstar: great. Just note that it was already fixed in devel with r10935, so you might just want to merge the change from there.
[16:24] <rockstar> sinzui, ah, okay.  So it WASN'T caused by my branch then (which landed directly into devel)
[16:25] <sinzui> rockstar, This is dumbfounding: https://lpbuildbot.canonical.com/builders/lp/builds/931/steps/shell_7/logs/summary
[16:25] <rockstar> Er, landed directly into db_devel I mean.
[16:25] <rockstar> sinzui, what's dumfounding about that?
[16:25] <sinzui> ^ the error we see is because there is an actual error in how we setup oops reporting. That is hiding the real error that caused the oops
[16:25] <nigelb> bryceh: poke
[16:26] <rockstar> sinzui, this is the one I was looking at: https://lpbuildbot.canonical.com/builders/db_lp/builds/830/steps/shell_7/logs/summary
[16:26] <sinzui> yes I fixed that with wgrant
[16:27] <rockstar> sinzui, okay, I'll leave it alone then.  As I started investigating, I started to realize it probably wasn't my fault anyway, but still was happy to fix it.
[16:27] <noodles775> rockstar: it might be worth checking your ec2 results when your branch landed (see gmb's 'email "Er, this isn't a SUCCESS").
[16:27] <bryceh> nigelb, yep
[16:28] <nigelb> bryceh: wondering if we could interface lp api to talk to reportbug for easy forward to debian
[16:28] <nigelb> something that can pull bug title and description and give to reportbug if we give it the lp bug number
[16:29] <nigelb> if I start off a branch, can help me out?
[16:29] <bryceh> jelmer, btw sorry last night in the middle of our conversation Verizon decided I didn't need internet and switched it off for a few hours.
[16:29] <rockstar> noodles775, well, my output seems truncated, but there's no failures logged.
[16:29] <bryceh> nigelb, sure
[16:29] <nigelb> bryceh: awesome, thanks :)
[16:30] <sinzui> devel is the one I am out of my depth. I cannot see the real error. I think the test env is not setup right for reporting codeimportworker oopses. apparently the section is missing
[16:30] <jelmer> bryceh: ah :-)
[16:30] <bryceh> nigelb, the lp side for that should be pretty straightforward; I've got most of that in arsenal now
[16:30] <jelmer> bryceh: I figured it was something like that
[16:31] <nigelb> bryceh: just pulling from launchpadlib should be enough right?
[16:31] <bryceh> nigelb, yeah
[16:31] <nigelb> bryceh: I'll give it a go i about an hour, I'll poke if I have something working :)
[16:31] <nigelb> (or not working)
[16:32] <bryceh> jelmer, anyway, dunno if you got everything I wrote.  In short, pulling bugs into gtg as tasks isn't implemented but with the latest backends work in theory it should be possible to do now
[16:32] <bryceh> jelmer, I've got plans to do it, just haven't gotten time yet
[16:34] <bryceh> nigelb, sounds good, I've got a meeting at the hour but will be around before and after that
[16:35] <nigelb> bryceh: cool :)
[16:37] <jelmer> bryceh: ah, cool
[16:37] <jelmer> bryceh: are you planning on landing this in mainline or as a separate plugin?
[16:38] <bryceh> jelmer, it would be a plugin which would be included in bzr trunk
[16:38] <bryceh> jelmer, although during development would be in a branch of course
[16:39] <bryceh> jelmer, btw I'm interested in hearing ideas of how it should work, use cases, etc.
[16:40] <jelmer> bryceh: for me personally, I'd be interested in having a way to automatically add all bugs that are assigned to me to gtg, inheriting tags from lp
[16:40] <jelmer> bryceh: as well as all my merge proposals that are work-in-progress
[16:43] <bryceh> jelmer, mm
[16:46] <bryceh> jelmer, some questions that have come up in relation to this...  would you want the import to be read-only or read-write (e.g. if you close the imported bug task or change tags, should it cause some change on lp or not)?  Would you want to make sub-tasks off of bug tasks (LP doesn't support sub-items so we'd have to figure out some alternate way to track it in gtg)?  Do you want to make notes on the bug task in gtg?
[16:50] <jelmer> bryceh: I hadn't thought that far ahead. read-only would be very useful by itself, and a nice first milestone but read-write would certainly also be nice.
[16:50]  * bryceh nods
[16:51] <bryceh> yeah that's what I'll be aiming for first
[17:39] <nigelb> bryceh: how do I query if a bug is private?
[17:42] <bryceh> nigelb, if [ bug.private ]
[17:42] <bryceh> or if you're using arsenal, if [ arbug.bug.private ]
[17:42] <nigelb> I'm directly querying
[17:43] <nigelb> I'll file a bug to tweak the apidocs soon enough.  Its not clear this is how I go about it
[18:10] <nigelb> bryceh: anyway to expose the pcakage name of a bug via api? I see only bug_tasks_collection_link
[18:40] <maxb> nigelb: A bug is not associated with a package directly. A bug has bug tasks. The bug tasks are associated with projects, distributions, or packages.
[18:42] <nigelb> maxb: oh, thats tough :D
[18:42] <maxb> no, that's good :-)
[19:34] <bryceh> nigelb, yeah it gets complicated
[19:34] <nigelb> bryceh: I got everything working except the plugging to reportbug
[19:35] <nigelb> playing with subprocess right now :x
[19:35] <bryceh> nigelb, what you have to do is given the bug #, look at its bug_tasks.  Exclude ones which are closed or that are external watches.
[19:35] <nigelb> nah, I found easier way
[19:35] <bryceh> oh?
[19:36] <nigelb> First line of report is usually "Binary package hint: <package-name>"
[19:36] <nigelb> not perfect, but works :D
[19:40] <maxb> eww, that's horrid
[19:41] <maxb> You really don't want to do that
[19:41] <maxb> iterate the bugtasks, find the ones which are ubuntu packages, and take it from that
[19:42] <nigelb> the problem is that package name might be wrong, so I'm only giving a hint and then user has to manually choose
[19:42] <nigelb> anywy, I'm stuck up against a brick wall called subprocess.open
[19:50] <nigelb> bryceh: help!
[19:51] <bryceh> ok
[19:51] <bryceh> yeah, I would not suggest relying on the Binary package hint text, that is going to be wrong a large percentage of the time
[19:52] <bryceh> yeah like I suggested before, go through the bug_tasks and exclude what you can
[19:52] <nigelb> bryceh: trust me, that's the least of my worries right now
[19:52] <nigelb> bryceh: https://code.launchpad.net/~nigelbabu/ubuntu-review-overview/report-debian
[19:52] <bryceh> ok what's the worry?
[19:53] <nigelb> if you can get this beast working, it would be great
[19:53] <nigelb> I can't get python to pass the arguments to reportbug
[19:55] <nigelb> bryceh: ok, now the arguments are passing correctly, but still #fail
[19:56] <bryceh> what command line are you using to run it?
[19:58] <nigelb> python report-but -b 33333
[19:58] <nigelb> s/bug/bug
[19:59] <bryceh> ahh process handling
[19:59] <nigelb> um, whats wrong?
[20:01] <nigelb> bryceh: ok, now its partly working :)
[20:01] <nigelb> yay to mentors :)
[20:04] <bryceh>     p = subprocess.Popen(args)
[20:04] <bryceh>     p.wait()
[20:05] <bryceh> or perhaps p.communicate() is better than p.wait() depending on how you intend to use it
[20:06] <bryceh> nigelb, anyway, other folk are probably better skilled than me at python to help with process handling stuff, but if you get stuck on launchpadlib-isms feel free to ping me further
[20:06] <nigelb> ok :)
[20:06] <nigelb> thanks :)
[20:08] <mars> nigelb, are you trying to interact with the subprocess using the current script, or just call it?
[20:09] <bryceh> nigelb, lp:~bryceharrington/ubuntu-review-overview/report-debian
[20:10] <nigelb> mars: try to interact with the current script
[20:12] <mars> ok, yes, you'll need .communicate() then to send data to the subprocess' Standard Input, and to read it's Standard Output
[20:12] <nigelb> ah
[20:19] <jml> g'night all
[20:20] <bryceh> I'm trying to find where the package-requests table is in my launchpad.dev environment... could anyone suggest a path to get to this page?
[20:22] <bryceh> the title of the page is "Copy archive contents" fwiw
[20:42] <maxb> Does anyone understand *why* OAuth uses split request/access tokens, rather than just having one token, that gets activated?
[20:43] <maxb> (Purely out of curiosity)
[21:05] <nigelb> mars: I'm getting wierd errors
[21:06] <nigelb> the lp_bug.description becomes the name of the attachment instead of the content :x
[21:09] <nigelb> bryceh, mars: any thoughts on ^ ?
[21:09] <bryceh> right that's correct
[21:10] <bryceh> I have a snippet for getting the content, hang on
[21:11] <bryceh> 	for a in bug.attachments:
[21:11] <bryceh>             # Retrieve content
[21:11] <bryceh>             hosted_file = a.data
[21:11] <bryceh>             hosted_file_buffer = hosted_file.open()
[21:11] <bryceh>             content = hosted_file_buffer.read()
[21:11] <nigelb> hang on
[21:11] <nigelb> whats ^ for?
[21:11] <bryceh> a.message has additional info about the attachment
[21:11] <nigelb> I'm not talking about LP attachment
[21:12] <bryceh>             author = a.message.owner.name
[21:12] <bryceh> nigelb, then maybe you should clarify
[21:12] <nigelb> I meant the description of the bug that I pass to reportbug ends up being the name of the attachment to a debian bug instead of an actual bug
[21:13] <bryceh> oh, I don't really know much about reportbug
[21:13] <nigelb> does arsenel talk to debian bts?
[21:13] <bryceh> nigelb, probably best you save me for launchpadlib questions specifically ;-)
[21:13] <bryceh> nigelb, nope
[21:13] <bryceh> nigelb, bugzilla.freedesktop.org
[21:13] <bryceh> but doesn't do attachments (yet)
[21:14] <nigelb> bryceh: hm, probably I need to write something to talk to debian bts then
[21:14] <nigelb> this is getting me nowhere otherwise
[21:15] <nigelb> bryceh: I'll try to write something to talk to bts and perhaps you can add to arsenel too :)
[21:16] <bryceh> nigelb, ok that would be great :-)
[22:08] <mars> bryceh, ping, could you please tell me the *exact* command you used to execute your test?
[22:10] <mars> bryceh, and the location of the ec2 script that was executed?  (was it in the same branch, or somewhere else like trunk/?)
[22:24] <bryceh> mars, ./utility/ec2 test
[22:24] <bryceh> mars, yeah same branch
[22:26] <mars> bryceh, ok, thanks.  I'm writing a reply to your mail.  Must be past EOD where you are?
[22:26] <bryceh> mars, yeah getting close
[22:28] <mars> ok.  After I get the mail out, feel free to write back whenever you have the time.
[22:29] <bryceh> ok will do
[22:54] <maxb> Ursinha: Hello. Have you considered registering a special Launchpad person to run your QA bot as? It would make notifications/bug histories somewhat more obvious to the uninitiated
[22:54] <Ursinha> maxb, yes, I've considered but haven't executed the idea
[22:55] <maxb> well, +1 :-)
[22:59]  * Ursinha appends on her TODO list 
[22:59] <Ursinha> :)