[01:38] <lifeless> maxb: hi
[01:38] <maxb> hi
[01:38] <lifeless> maxb: we should batch enable
[01:38] <lifeless> maxb: rather than you causing me to get 4K emails
[01:39] <maxb> aww, it's only a few hundred :-)
[01:39] <maxb> On a more serious note, some of the things currently suspended have reasons for failing
[01:40] <maxb> so I'm eyeballing them in a browser and re-suspending ones that had a reason for being suspended
[01:41] <lifeless> ok
[01:41] <lifeless> wouldn't want to frag apache svn again
[01:43] <maxb> apache? but this is sourceforge. But indeed, we don't want to frag them either, so I've been doing it in batches and watching for one to complete before starting another
[01:44] <lifeless> cool; I'm very glad you're doing this.
[01:46] <maxb> screenscraping for the win..... kinda ;-)
[02:12] <mwhudson> feel free to submit patches to make this easier btw :-)
[02:45] <lostogre> I have been trying to import my public gpg key for a couple of hours now. I keep getting "Launchpad could not import your OpenPGP key" errors. Can someone help?
[02:47] <lostogre> When I query the server with the Key ID, it shows my key.
[02:55]  * lostogre thinks there isn't any body back there.
[05:55] <micahg> hi lifeless, I was wondering if the convert to question issue was on the LP team radar still
[05:58] <wgrant> It is right at the top of our slow pages list :(
[05:59] <micahg> wgrant: ok, as I understood it (which isn't very much), it was almost a whole project unto itself to get it fixed
[06:09] <lifeless> micahg: its about 1/2 done
[06:09] <lifeless> micahg: however its not the top timeout culprit at the moment; its not forgotten, its just not the thing burning our fingers
[06:10] <micahg> lifeless: ok, it's just impossible to use most of the time
[06:10] <lifeless> :(
[06:11] <micahg> lifeless: do you need any more oopses for it?
[06:11] <lifeless> nope, we know very well the problem
[06:11] <micahg> ok, thanks
[06:11] <lifeless> there is a backend job created for it
[06:11] <lifeless> we just need to move code actions from A to B
[10:00] <czajkowski> kiko: boo
[10:00] <kim0> Hi LP gurus. I'm pushing code to "https://code.launchpad.net/~kim0/+junk/ec2-ebs-migrate-Instance" which is a branch from "https://code.launchpad.net/~abd4lla/+junk/ec2-ebs-migrate" However I am not getting "propose for merging" link, any idea why ?
[10:02] <czajkowski> kim0: boo
[10:02] <jtv> thumper: still up?  ^^
[10:02] <kim0> czajkowski: indeed boo it is :)
[10:04] <bigjools> kim0: it's usually a permission thing
[10:05] <kim0> bigjools: um both projects are public
[10:05] <kim0> bigjools: where do I see permissions
[10:06]  * bigjools was guessing
[10:06] <bigjools> let's have a look
[10:08] <bigjools> kim0: another guess - it might be because it's a +junk branch, but I'm not sure.  The codehosting experts are all asleep right now
[10:13] <kim0> bigjools: thanks .. yeah I heard the junk thing earlier. Would have thought it doesn't make a difference. Thanks for the help
[10:14] <bigjools> kim0: I know that there's some restrictions on +junk to encourage people to make real projects
[10:14] <kim0> ah I see
[10:58] <jfi_> Hello, the deletion of a ppa package (throw the LP web interface), does not delete the .orig.tar.gz file? (even if there is only one package for this .orig.tar.gz file)
[11:04] <bigjools> jfi_: the files are deleted from the repo area first and then cleaned up from the librarian (internal storage) a few days later.
[11:05] <bigjools> do you have a particular problem?
[11:05] <jfi_> bigjools, a potential one maybe
[11:05] <bigjools> perhaps I can help
[11:05] <jfi_> bigjools, I have uploaded a source package (the first one for this orig.tgz)
[11:06] <jfi_> bigjools, the installation was totally wrong due to conflicting files, so I delete the package to avoid users having trouble
[11:06] <jfi_> bigjools, then I uploaded a new source package (based on the same orig.tgz)
[11:06] <bigjools> and it was rejected? :)
[11:07] <jfi_> no, it is accepted, built, deployed, etc
[11:07] <bigjools> ok
[11:07] <jfi_> I just wonder if later the orig.tgz is not going to be deleted as it has not been re-uploaded
[11:07] <bigjools> it won't be deleted, no
[11:07] <jfi_> fine, thanks for the information!
[11:07] <bigjools> it's reference-counted so all the referring packages need to be deleted first
[11:08] <bigjools> plus, you get the few days grace I mentioned above
[11:08] <jfi_> ok, thx!
[11:12] <persia> bigjools: Isn't there also a downgrade protection reference that prevents reuse of the file later?
[11:12] <bigjools> persia: you can't re-upload it, if that's what you mean
[11:12] <bigjools> (with different contents)
[11:13] <persia> I thought you couldn't reupload it at all, even with the same contents, but yes, that's what I was confirming.
[11:13] <bigjools> if it has the same content it just assumes you're stupid and not using debuild -sd :)
[11:14] <persia> How does it determine that, if the file has been deleted as no longer referenced.  Checksums?
[11:19] <wgrant> persia: We keep a record of checksums, yes (forever, at the moment)
[11:20] <persia> Which checksums?  The ones reported in the .dsc, or something recalculated in LP?
[11:24] <wgrant> persia: The upload checks that they are the same.
[11:25] <persia> Checks that *what* are the same?
[11:28] <wgrant> persia: The hashes of the uploaded files, the hashes in the DSC, and the hashes of any existing files of the same name in the target archive.
[11:28] <wgrant> All three must match.
[11:29] <wgrant> 'existing files' includes all history, too.
[11:29] <persia> Which hashes do you calculate?
[11:30] <persia> Or is it something like all the hashes reported in the .dsc?
[11:30] <persia> (or where in the code is this, and I'll stop asking questions that may seem confusing, wrong-headed, or pointless)
[11:31] <wgrant> We match MD5 and SHA1 (not SHA256 yet) hashes of all files referenced in the changes file.
[11:31] <persia> Thanks!
[11:36] <bigjools> wgrant: until they get expired *cough*
[11:37] <persia> bigjools, When/how do they get expired?  I thought it was never.
[11:37] <bigjools> persia: just ppa files
[11:38] <persia> If it ever happens, I don't understand why it's not possible to store them for only a short time.
[11:38] <persia> Yeah, PPA files :)  I had a long-standing and highly-argued bug about whether PPAs should be held to publication standards or not.  I thought it was resolved that they would be, but now I'm confused.
[11:38] <bigjools> ubuntu files are kept forever.  ppa files are deleted once there's no more packages using them plus the grace period
[11:39] <wgrant> bigjools: Oh, right, we haven't fixed that yet.
[11:39] <persia> My feeling is that they should either be held to publication standards, or not, but very much not something in-between.
[11:39] <persia> Ah, it's a bug.  That's fine then :)
[11:39] <bigjools> yes
[11:39] <wgrant> It's a long-standing bug in the librarian schema.
[11:40] <bigjools> although where the "bug" is is a point of contention
[11:40] <persia> bigjools, What's the contention?
[11:43] <bigjools> where the checksum should live
[11:46] <persia> Heh.  That makes sense.
[13:47] <yodog> !ops
[13:47] <yodog> !ops
[13:47] <yodog> nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga nigga
[13:47] <yodog> im tru gangsta
[13:47] <yodog> !ops
[13:48] <yodog> nigga nigga nigga nigga
[13:48] <yodog> !staff
[13:48] <yodog> hey piko ban me
[14:04] <maxb> pindonga: So, you can certainly write scripts to upload source packages to Launchpad
[14:04] <maxb> I do it myself
[14:05] <maxb> However, in order to have some security partitioning, I have a separate launchpad profile just for this
[14:05] <maxb> (and so a separate PGP key for that profile)
[14:05] <pindonga> maxb, yes, I was planning on having a different user for this
[14:05] <maxb> You may wish to do the same if you go this route
[14:05] <pindonga> as this is a plugin for tarmac, this would be the tarmac user running it
[14:05] <pindonga> so the packages would be uploaded by that user
[14:06] <pindonga> so, having that user use a key without passphrase should make it work
[14:31] <dholbach> hola
[14:32] <dholbach> can somebody explain what's going wrong here: http://paste.ubuntu.com/566982/ ?
[14:38] <maxb> dholbach: Given who just joined the channel, you might want to repeat that :-)
[14:39] <dholbach> I'm happy to do that :)
[14:39] <dholbach> can somebody explain what's going wrong here: http://paste.ubuntu.com/566982/ ? :-D
[14:39] <tsimpson> dholbach: edge is gone IIRC
[14:39] <tsimpson> you need to use LPNET_SERVICE_ROOT from launchpad.uris
[14:39] <tsimpson> *launchapdlib.uris
[14:39] <dholbach> oh man, I don't want to know how many scripts all over the place fail now
[14:40] <dholbach> couldn't it just have been an alias or something?
[14:40] <maxb> edge is going, not gone
[14:40] <maxb> unless someone has changed their mind recently
[14:40] <tsimpson> I had to mess with some scripts because they didn't like edge
[14:42] <tsimpson> yeah, that error is because the api.edge.launchpad.net/... stuff is redirecting (HTTP redirect) to api.launchpad.net
[14:42] <tsimpson> and I lplib doesn't consider them the same service
[14:42] <tsimpson> s/I /
[14:45] <leonardr> dholbach: for a number of reasons we could not get a redirect to work
[14:46] <dholbach> leonardr, what's the workaround? what do I do instead of "Launchpad.login_anonymously('test', EDGE_SERVICE_ROOT, '/tmp/bla')"?
[14:46] <leonardr> dholbach: Launchpad.login_anonymously('test', 'production', '/tmp/bla')
[14:48] <dholbach> leonardr, thanks!
[14:48] <dholbach> leonardr, I'm quite sure it's a horrible suggestion for all kinds of reasons, but can we do something like putting a EDGE_SERVICE_ROOT = 'production' in lplib and push that as sru into the distro?
[14:49] <dholbach> (and maybe add some kind of warning)
[14:49] <dholbach> I'm sure I will at least have to fix this in 20-25 scripts all over the place now :(
[14:50] <leonardr> dholbach: it's not a bad idea, and benji also suggested it
[14:51] <dholbach> I wasn't sure I was aware of all its implications and it felt like hack from somebody (me) who doesn't know what they're talking about ;-)
[14:52] <leonardr> it is a hack, but all it does it secretly make the change you would have to make anyway
[14:52] <dholbach> I'll go ahead and see what I have to fix
[14:52] <dholbach> thanks again leonardr
[14:53] <dholbach> maybe some kind of reminder in a lp blog entry would be good then
[14:53] <dholbach> FWIW I just noticed this breaking like 30 min ago
[14:54] <bigjools> dholbach: out of interest, where would you look for an announcement about this?  Just the blog?
[14:55] <dholbach> if you want to spread the message: the blog, the lpstatus identi.ca account and maybe even ubuntu-devel-announce@lists.u.c
[14:57] <bigjools> dholbach: interesting that you didn't consider the 2 mailing lists we already announce on :/
[14:58] <dholbach> it was an interesting data point then ;-)
[15:00] <bigjools> dholbach: it's a good idea to keep up with launchpad-announce and launchpad-users :)
[15:00] <bigjools> lpstatus is for service status and outages etc.
[15:17] <kiko> flacoste, you around?
[15:17] <flacoste> hi kiko, on the phone
[15:18] <kiko> flacoste, okay, ping me later
[15:21] <mhall119> leonardr: ping
[15:22] <leonardr> hi
[15:22] <mhall119> trying to move loco-directory off of edge
[15:22] <mhall119> we were using launchpadlib.launchpad.EDGE_SERVICE_ROOT as lpinstance
[15:22] <leonardr> mhall119: use 'production' instead
[15:23] <ari-tczew> how can I request remove of the team ?
[15:23] <mhall119> just 'production'?
[15:23] <mhall119> EDGE_SERVICE_ROOT is a url
[15:24] <mhall119> oh, that's working now...
[15:24] <leonardr> mhall119: yes, just the string 'production'
[15:24] <mhall119> weird, first time I tried that it timed out
[15:25] <mhall119> now it works
[15:26] <mhall119> thanks leonardr
[15:27] <leonardr> np
[15:27] <bigjools> ari-tczew: file a question here: https://answers.edge.launchpad.net/launchpad
[15:28] <ari-tczew> bigjools: thanks done
[15:33] <ari-tczew> is there any bereavement on Launchpad? some colours have been changed to gray or black
[15:39] <ripps> is launchpad.net down? I can only use launchpad via edge, but none of my other programes, ubuntu-bug/dl-ubuntu-test-iso are working.
[15:40] <dholbach> bdmurray, ^ it ubuntu-qa-tools might need a similar fix as the 5-a-day-stats
[15:41] <bdmurray> rcmorano: what release of Ubuntu are you using?
[15:42] <komputes> LP SPAM FOUND - https://bugs.launchpad.net/ubuntu-beginners-wiki-sod/+bug/599121
[15:51] <mdeslaur> I'm getting the following error when trying to use some of our launchpadlib tools this morning: "NotImplementedError: Can't look up definition in another url (https://api.launchpad.net/1.0/#team)"
[15:51] <leonardr> mdeslaur: you need to find the code that says Launchpad.login_with("foo", EDGE_SERVICE_ROOT)
[15:51] <leonardr> and change EDGE_SERVICE_ROOT to "production"
[15:51] <leonardr> the edge server no longer exists
[15:52] <mdeslaur> Ah! thanks leonardr
[15:52] <mdeslaur> leonardr: so, the concept of edge doesn't exist anymore, right?
[15:53] <leonardr> mdeslaur: right
[15:53] <mdeslaur> leonardr: there was an email that was sent about that, right? (/me searches memory...)
[15:53] <joey> hi lifeless and jamesh - what do you need?
[15:54] <joey> hi lifeless and jamesh - something wrt IRC
[15:56] <mdeslaur> ah, found it: http://blog.launchpad.net/general/edge-is-deprecated
[16:00] <joey> flacoste, lifeless, jamesh - how now brown cow re IRC privs?
[16:01] <joey> flacoste, lifeless, jamesh -  /msg chanserv access #launchpad list
[16:01] <joey> jml: you too^^
[16:02] <jml> joey: be with you in a sec.
[16:06] <jml> joey: we're happy wrt ops privs, we just need to change ubot5 to list ops correctly when someone asks for !ops.
[16:07] <joey> !ops
[16:07] <joey> hmm I don't much about ubot5
[16:07] <jml> joey: I figure we should talk to jussi & ask him to configure it.
[16:07] <joey> yeah
[16:07] <tsimpson> I can do that :)
[16:07] <joey> tsimpson: sweet, tell me how it works!
[16:07] <jml> tsimpson: oh, that would be great, thanks.
[16:08] <tsimpson> to change a factoid you usually do "!no factoid is <reply> whatever you want"
[16:08] <joey> jml: fyi I'm also fixing perms on -meeting.  I had to submit a group request to some of it
[16:08] <tsimpson> but you can't change it unless you have privileges
[16:08] <joey> !no factoid is lifeless, flacoste, jml, joey
 Your edit request has been forwarded to #ubuntu-irc.  Thank you for your attention to detail
[16:09] <tsimpson> (in -irc) <ubot5> In #launchpad, joey said: !no factoid is lifeless, flacoste, jml, joey
[16:09] <tsimpson> so someone would approve it and actually change it, like me for instance :)
[16:09] <joey> rock on
[16:10] <jml> !no ops is lifeless, flacoste, jml, joey
[16:10] <jml> tsimpson: thanks.
[16:10] <tsimpson> there is some magic for channel specific factoids too
[16:11] <tsimpson> !no ops-#launchpad is <reply> Help! lifeless, flacoste, jml, joey
[16:11] <jml> ahh, I imagine 'ops' is channel specific :)
[16:11] <joey> jml, aside from here and -meetings, are -foundations, -reviews, -translators and -dev, and -yellow in need of updates?
[16:11] <jml> joey: -foundations and -reviews are dead
[16:11] <joey> ok, so I'll have a peek at -dev
[16:25] <eugenesan> my build failing with error related to http://wiki.debian.org/ImplicitPointerConversions
[16:26] <eugenesan> But same build passes for official Natty
[16:28] <geser> on the same architecture? this only triggers on amd64 (and ia64 in the past)
[16:28] <bigjools> eugenesan: amd64 build?
[16:31] <apw> can anyone tell me what the error below means from launchpadlib ?
[16:32] <apw> Can't look up definition in another url (https://api.launchpad.net/1.0/#bug)
[16:32] <leonardr> apw: you need to find the code that says Launchpad.login_with("foo", EDGE_SERVICE_ROOT)
[16:32] <leonardr> and change EDGE_SERVICE_ROOT to "production"
[16:32] <leonardr> the edge server no longer exists
[16:32] <apw> leonardr, hrm, why has edge gone away?
[16:32] <leonardr> http://blog.launchpad.net/general/edge-is-deprecated
[16:33] <seb128> hey
[16:33] <seb128> http://paste.ubuntu.com/567034/
[16:33] <seb128> known issue?
[16:33] <leonardr> seb128: http://blog.launchpad.net/general/edge-is-deprecated
[16:33] <leonardr> you need to find the code that says Launchpad.login_with("foo", EDGE_SERVICE_ROOT)
[16:33] <leonardr> and change EDGE_SERVICE_ROOT to "production"
[16:34] <seb128> great
[16:34] <apw> leonardr, what is the correct name for production?
[16:34] <leonardr> apw: 'production'
[16:34] <seb128> who decided to break compatibility and all the script distro is relying on?
[16:34] <geser> leonardr: you should set up a bot with this answer :)
[16:34] <apw> leonardr, as the blog says LPNET_SERVICE_ROOT, but that doesn't exist
[16:34] <seb128> couldn't you keep that as a compatibility thing?
[16:34] <leonardr> seb128: unfortunately not. however, i have launchpadlib branches that will make your existing code use production
[16:35] <seb128> ups
[16:35] <leonardr> apw: what version of launchpadlib are you using?
[16:35] <apw> the default in maverick i think
[16:35] <apw> ii  python-launchpadlib                               1.6.1-1                                           Launchpad web services client library
[16:36] <leonardr> apw: try 'production', and if that doesn't work, follow the advice given here: http://blog.launchpad.net/general/edge-is-deprecated#comment-40626
[16:36] <seb128> leonardr, is there any way to get the old syntax still working?
[16:37] <JFo> leonardr, 'production does not work
[16:38] <leonardr> seb128: yes, see https://code.launchpad.net/~leonardr/launchpadlib/fake-edge/+merge/49651
[16:38] <leonardr> JFo: if you're using 1.6.1-1, do me a favor and paste me the contents of /usr/share/pyshared/launchpadlib/uris.py
[16:39] <apw> leonardr, so compatibility could have been maintained by making EDGE_SERVICE_ROOT be the 'production' string?
[16:39] <apw> could we not have done that?
[16:39] <leonardr> apw: we could have done it earlier, yes
[16:39] <seb128> leonardr, that means code running on stable ubuntu series will need launchpadlib backports to all series?
[16:39] <apw> leonardr, well i am thinking 'still'
[16:40] <leonardr> seb128: yes, you will have to change launchpadlib or change the code that calls it
[16:40] <seb128> that's ridiculous
[16:40] <leonardr> apw: that's what's in https://code.launchpad.net/~leonardr/launchpadlib/fake-edge/+merge/49651
[16:40] <leonardr> seb128: please take it up with lifeless
[16:40] <JFo> leonardr, https://pastebin.canonical.com/43289/
[16:41] <leonardr> JFo: that's the same code i have, and 'production' works for me. what happens when you try 'production' instead of edge/EDGE_SERVICE_ROOT?
[16:42] <JFo> one sec... leonardr I may have made an error
[16:47] <leonardr> apw: what happens when you try 'production'? what error do you get?
[16:47] <leonardr> and what does your code look like?
[16:50] <JFo> leonardr,
[16:50] <JFo>   File "kernel-buglist-by-team.py", line 30, in <module>
[16:50] <JFo>     import KernelBugListByTeam
[16:50] <JFo>   File "/home/jfo/canonical-qa-tracking/misc-scripts/KernelBugListByTeam.py", line 33, in <module>
[16:50] <JFo>     from launchpadlib.launchpad import production
[16:50] <JFo> ImportError: cannot import name production
[16:50] <JFo> is what I see
[16:50] <leonardr> JFo: i meant to use the literal string "production" instead of EDGE_SERVICE_ROOT
[16:50] <JFo> ok
[16:50] <leonardr> Launchpad.login_with("foo", "production")
[16:51] <leonardr> or, you can import LPNET_SERVICE_ROOT, as recommended in the blog post, and if that doesn't work i'd like to go into more detail about that
[16:51] <eugenesan> bigjools,geser: Sorry for delay. Thi s fails only on amd64 but passes on same amd64 in Natty
[16:52] <bigjools> eugenesan: the builder chroots will fail the build for those errors, deliberately
[16:53] <JFo> leonardr, ok, I will try this and, if that doesn't work, the LPNET_SERVICE_ROOT before I pester you again :)
[16:53] <leonardr> ok
[16:53] <eugenesan> bigjools: Here are related logs: http://launchpadlibrarian.net/64306864/buildlog_ubuntu-natty-amd64.gtk%2B3.0_3.0.0-0ubuntu1_BUILDING.txt.gz http://launchpadlibrarian.net/64328199/buildlog_ubuntu-maverick-amd64.gtk%2B3.0_3.0.0-0ubuntu1~eugenesan~maverick1_FAILEDTOBUILD.txt.gz
[16:53] <bigjools> eugenesan: this is not something that will be changed, you need to fix the source
[16:54] <eugenesan> bigjools: But why main build is ok?
[16:54] <bigjools> eugenesan: what do you mean by "main" build?
[16:54] <eugenesan> bigjools: Not PPA build for Natty
[16:55] <bigjools> the ubuntu build you mean?
[16:55] <eugenesan> yes
[16:55] <bigjools> it can't be the same source then
[16:55] <bigjools> they use the same chroots
[16:56] <eugenesan> Same source, I can even see problematic warning in both logs
[16:57] <bigjools> hmmm
[16:57] <eugenesan> Just ubuntu build do no fail, it maybe related to Maverick.Natty differencis
[16:57] <bigjools> eugenesan: can you point me at the sucessful build in natty?
[16:58] <eugenesan> http://launchpadlibrarian.net/64306864/buildlog_ubuntu-natty-amd64.gtk%2B3.0_3.0.0-0ubuntu1_BUILDING.txt.gz
[16:58] <JFo> leonardr, no joy :-(
[16:58] <leonardr> JFo: what errors do you get?
[16:58] <bigjools> eugenesan: not the log, the build page
[16:58] <eugenesan> https://launchpad.net/ubuntu/+source/gtk+3.0/3.0.0-0ubuntu1/+buildjob/2260644
[16:59] <bigjools> thanks
[16:59] <JFo> leonardr, https://pastebin.canonical.com/43291/
[16:59] <JFo> same as before
[16:59] <JFo> well, similar
[16:59] <geser> eugenesan: I can only find the "implicitly conversion" in your ppa log but not the natty build
[17:00] <bigjools> what I was going to say too ...
[17:00] <leonardr> JFo: the right code is "from launchpadlib.uris import LPNET_SERVICE_ROOT"
[17:00] <leonardr> did you get the same problem with the literal string "production"?
[17:01] <eugenesan> I do not have natty build, onlt Maverick. You think this might be related to less strict checking in natty?
[17:01] <bigjools> you're backporting it?
[17:01] <eugenesan> yes
[17:01] <JFo> leonardr, I did
[17:01] <bigjools> could be different compiler options
[17:01] <JFo> let me try some changes...
[17:02] <bigjools> eugenesan: did you copy the source without changing it?
[17:02] <leonardr> JFo, also let me see the code you used with 'production' that broke
[17:02] <eugenesan> yes
[17:02] <eugenesan> to me it looks more like debhelper checking
[17:03] <eugenesan> Compiler reports same in both cases, I suspect code added in this packages might fail on Natty/amd64...
[17:04] <bigjools> eugenesan: ah I see it
[17:04] <eugenesan> Those warnings related to code added by Canonical for globalmenu
[17:05] <bigjools> one sec
[17:07] <geser> eugenesan: might be due to diffent gcc: 4.4 in maverick and 4.5 in natty as the other warnings around it are the same only the implicitly conversion is missing with gcc-4.5
[17:08] <leonardr> apw, JFo: the breakage was a mistake that's being fixed. edge will continue to work, but you should stop using it or one day this will happen for real
[17:08] <JFo> ok
[17:09] <eugenesan> Looks reasonable, do you have which packages is responsible for after-build log parsing?
[17:10] <bigjools> it looks like a bug in the builders
[17:10] <geser> as far as I know it either done by the buildd itself or the script monitoring the build
[17:10] <bigjools> it's done in the buildd code
[17:11] <bigjools> lib/canonical/buildd/check-implicit-pointer-functions in the launchpad tree if you're curious
[17:11] <bigjools> eugenesan: please file a bug
[17:11] <bigjools> the natty build should have failed
[17:11] <eugenesan> agree
[17:11] <bigjools> file on launchpad-buildd project please
[17:12] <eugenesan> ok, thanks for clarifications
[17:12] <bigjools> thanks for pointing this out
[17:14] <bigjools> eugenesan: ha I can see what's broken too - there's an extra :N in the natty logs
[17:15] <bigjools> it breaks the regex used to match these
[17:16] <eugenesan> btw: there are alread two bug filed on subject: #504078 and #415497
[17:17] <eugenesan> dx team will be "happy"
[17:22] <apw> leonardr, ok
[17:38] <bigjools> eugenesan: you need to file a new bug, those are not the same thing
[17:53] <maxb> bigjools: By means of testing on qastaging, I conclude that the "Launchpad could not import your OpenPGP key." question that is ongoing seems like something is broken in LP, rather than user error
[17:54] <maxb> Is there some internal separation between keyserver.ubuntu.com and where LP fetches keys from?
[17:54] <bigjools> maxb: that's entirely possible, I left it with sinzui for now since I am EODing soon
[17:55] <bigjools> there's a different URL for internal requests but they should go to the same server IIRC
[19:02] <kiko> flacoste, ping?
[19:02] <flacoste> kiko: still on the phone :-/
[19:02] <kiko> flacoste, okay :)
[19:02] <flacoste> kiko: should be free in ~1h
[19:52] <sinzui> maxb lp supposedly uses host: keyserver.internal. I expected this name to be redefined in the production configs. It is not. I will ask an admin to investigate what keyserver lp is talking too. This might explain the common out-of-sync issue users experience registering keys
[19:54] <flacoste> kiko: ping
[20:00] <cody-somerville> aww... no way.... after just uploading several hundred meg crash file to launchpad I get a 'Cannot connect to crash database, please check your internet connection. HTTP Error 502: Bad Gateway'. :(
[20:09] <maxb> sinzui: Thanks. It would go some way to explaining "You may have to wait between ten minutes (if you pushed directly to the Ubuntu key server)" found in lib/lp/registry/templates/person-editpgpkeys.pt
[20:10] <sinzui> I have been telling users 1 hour. Maybe I will have a definitive answer today
[20:10] <maxb> Which is contradicted by "It can take up to thirty minutes before your key is available to Launchpad." in lib/lp/registry/help/openpgp-keys.html
[20:11] <sinzui> yes. That pt needs updating.
[21:19] <dmpinheiro> hi. I'm trying to change bugs from one project milestone to other project milestone using the launchpadlib API.
[21:19] <dmpinheiro> but I can't retrieve the bugs from a milestone
[21:20] <leonardr> dmpinheiro: do you have code that doesn't work, or do you not know what code to write?
[21:20] <dmpinheiro> here is a example that I did without success: http://paste.pocoo.org/show/338588/
[21:21] <dmpinheiro> I can't get all bugs given a milestone
[21:21] <dmpinheiro> the collection always return empty
[21:21] <dmpinheiro> did I do something wrong ? The REST API usage is correct ?
[21:23] <leonardr> dmpinheiro: i don't see any problems so it's probably a problem with the launchpad-side logic. try this:
[21:23] <leonardr> bugs = oship.searchTasks(milestone=milestone)
[21:25] <dmpinheiro> it doesn't work too
[21:25] <dmpinheiro> I already tested this possiblity
[21:26] <dmpinheiro> I verified the http request, increasing the httplib2 debug level
[21:27] <dmpinheiro> The server really doesn't response a json representation
[21:29] <dmpinheiro> As I said, my purpose is move a set of bugs from a project to another
[21:29] <dmpinheiro> Do you know any other API usage that can help me to achieve my goal ?
[21:30] <leonardr> dmpinheiro: well, once you have the tasks you can change the .target on each one
[21:31] <leonardr> there's either a bug in launchpad that is keeping you from seeing the bug tasks, or you don't have permission to see them, or you're searching for them wrong--i don't know enough about bugs to say which
[21:32] <leonardr> you could instead find _all_ the bug tasks in your project and iterate over them, checking the milestone of each. this would be inefficient but it would work
[21:42] <dmpinheiro> leonardr: I got the problem : The status of all bugs wasn't the default from the searchTasks method.
[21:42] <dmpinheiro> leonardr: A passed all possible bug status and the method retrieve them correctly. Thanks!
[21:43] <dmpinheiro> leonardr: as I expected, It was my fault . :)
[21:44] <leonardr> well, that's not the best design
[22:14] <jml> the default is "only open bugs"
[22:30] <dmpinheiro> Hi again. As I said, I'm trying to move bugs from a project to another. What's the most simple way to do that ?
[22:31] <wgrant> lifeless: Excellent, I wanted a deploy to cocoplum at some point anyway :)
[22:31] <dmpinheiro> i tried changed the target attribute from each bug_task, but seems to be impossible because a IntegrityError was raised.
[22:32] <wgrant> dmpinheiro: Try the transitionToTarget method.
[22:33] <wgrant> Ah
[22:33] <wgrant> Actually, that's gone.
[22:33] <wgrant> Set the target attribute.
[22:33] <wgrant> I see you're doing that, though.
[22:33] <wgrant> Hmm.
[22:33] <wgrant> Were you trying to move from a project to a distribution, or vice-versa?
[22:34] <wgrant> That error can also occur when you are moving a task to a target for which the bug already has a task -- duplicate tasks are forbidden.
[22:35] <dmpinheiro> on contrary : I'm moving from a distribution to a project
[22:36] <wgrant> Right. You can't do that at the moment.
[22:36] <wgrant> You can move a task between distributions, or between projects, but not from one type to the other.
[22:36] <wgrant> I am not entirely sure why.
[22:44] <james_w> wgrant, bug 80902
[22:46] <lifeless> wgrant: in the model ?
[22:46] <lifeless> wgrant: that would be a bug
[22:47] <wgrant> lifeless: It is a bug, yes.
[22:47] <wgrant> And it looks like it is critical, too!
[23:41] <mtaylor> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[23:42] <mtaylor> is that a known issue?
[23:44] <wgrant> mtaylor: Works for me. Still broken for you?
[23:44] <mtaylor> wgrant: it's now working. I'll assume you fixed it. :)
[23:45] <wgrant> Hmm, that's not good.