[00:04] <shape> hello  I've run a command apport-collect and where the window pops up to "report a problem to the developers" it freezes
[00:06] <lifeless> shape: #ubuntu may be able to help you with that
[00:08] <shape> lifeless, I just asked there too :)
[00:11] <shape> lifeless: It seems like it worked "as in, it uploaded the log. Thanks
[01:58] <Corey> How do I delete a package from launchpad?  I don't see any way to submit a "deletion request"
[01:59] <StevenK> In your own PPA or the primary archive?
[01:59] <Corey> StevenK: My own PPA.
[01:59] <StevenK> Corey: There's a Delete Packages link off +packages
[02:00] <Corey> (Pushed a package that was busted, it has no reason to be there anymore and it has the potential to blow things up)
[02:00] <maxb> The "Delete packages" link is on the page after "View package details", somewhat counter-intuitively
[02:01] <Corey> Weird, no delete link in the repo I care about, but there is in my personal PPA.  If I recreate the URL structure it works.
[02:01] <Corey> Odd.
[02:02] <EvilResistance> Corey:  not sure you can request a deletion in a PPA...
[02:02] <EvilResistance> not unless you're in a group with upload permissions to it
[02:02] <EvilResistance> s/upload/ownership/
[02:05] <Corey> EvilResistance: It worked.
[02:05] <EvilResistance> heh
[02:06] <Corey> So there's either an issue of "I can delete things I can't" or "there's a UI bug"
[02:07] <wgrant> Which URL doesn't have the link, but you think it should?
[02:07] <Corey> https://launchpad.net/~saltstack/+archive/salt/+packages only shows me a copy packages option, yet https://launchpad.net/~saltstack/+archive/salt/+delete-packages works for me to remove packages.
[02:08] <Corey> Very odd.
[02:13] <wgrant> Corey: Someone deleted and then tried to undelete that PPA
[02:13] <wgrant> That's why the link is missing.
[02:14] <bigjools> I love it that people completely ignore warnings in the UI
[02:17] <Corey> Uh...
[02:18] <Corey> That's not good. :-)
[02:18] <Corey> <-- not it
[02:22] <ScottK> Zombie undead PPAs are after you.
[02:23] <EvilResistance> lol
[02:30] <Corey> So it would seem.
[03:12] <mwhudson> >>> l.project_groups.search(text='lava')[0].all_milestones[0]
[03:12] <mwhudson> <has_bugs at https://api.staging.launchpad.net/1.0/lava/+milestone/backlog>
[03:13] <mwhudson> why is that a has_bugs object, not a milestone?
[03:13] <wgrant> Bug 951365
[03:14] <mwhudson> yay
[03:14] <mwhudson> wgrant: any idea how to fix this?
[03:14] <wgrant> mwhudson: Try lp.load()ing the URL
[03:14] <wgrant> Might work
[03:14] <wgrant> Might not
[03:16] <mwhudson> wgrant: i meant in launchpad
[03:16] <mwhudson> (that doesn't work, btw)
[03:16] <wgrant> Ah
[03:16] <wgrant> rm lazr.restful is easiest
[03:17] <wgrant> I don't know the details of this particular issue.
[03:17] <mwhudson> i was thinking more an afternoon hack than a lifetime hack
[03:17] <mwhudson> ok
[03:17] <mwhudson> will poke around a bit
[04:20] <bullgard4> https://bugs.launchpad.net/bugs/993038 I wonder what does mean needs-bisect»« in "** Tags added: needs-bisect regression-release".
[11:45] <dupondje> thedac: those yade builds are eating all power again :p
[14:07] <hexmode> bug links on https://bugs.launchpad.net/ubuntu/+source/gwibber/+bug/825447 and the like aren't working
[14:09] <hexmode> note that I mean the link on "bug #820921" is broken
[14:10] <hexmode> ok, just to be clear, links like "https://bugs.launchpad.net/825447" don't work
[14:10] <hexmode> nor do links like https://launchpad.net/bugs/820921
[14:11] <hexmode> which ubot5 just  gave not  3 minutes ago
[16:27] <angeloc> hy guys, I'm writing an ubuntu accomplishment that should test if a person had personally verified an SRU bug to earn the tester trophy, any idea?
[16:31] <czajkowski> angeloc: there is an Ubuntu-accomplishement channel
[16:33] <angeloc> czajkowski: sorry for not being more explicit, i have to use launchpad api via python to find for what i'm looking for
[16:33] <angeloc> czajkowski: but i have not found a way to check if a person had personally verified an SRU bug via launchpad api
[16:37] <czajkowski> angeloc: perhaps in launchpad-dev might be able to help
[16:38] <dobey> angeloc: there is no way to get the tag edits for a particular user for all time, afaik
[16:39] <angeloc> dobey: ok, so I can only know if a bug filed by a person was verified but not who verified it, right?
[16:41] <dobey> angeloc: yes, but it's a bit more complex than that.
[16:42] <dobey> angeloc: "tags" is data on the bug object, not the bug_task object. and it's just a string of comma-separated values
[16:43] <angeloc> dobey: complexity don't fear me, the only constraint it should be efficient and should download the least datas
[16:43] <dobey> angeloc: so if a bug was filed against something, and later marked as also affecting something else, and fixed in the other thing, but not the original, the tag may still be there, though it's not really related to the original bug
[16:44] <dobey> angeloc: which means, in its current state, that even if you could check it easily, you might still get it wrong :)
[16:45] <angeloc> dobey: ok, i haven't to corner all possible cases, the accomplishment should check if a user had verified at least one bug to earn the tester trophy
[16:45] <dobey> angeloc: right, and i don't see any good way to do that
[16:46] <dobey> angeloc: who edited the tags list, is not part of the API that I can see
[16:48] <angeloc> dobey: ok, so in the last resort, i can check only if a bug filed by a person has the tag verification-done, it's a little bit different from what I originally thought
[16:49] <angeloc> dobey: i can change the accomplishment from tester to "Filed an SRU verified bug"
[16:49] <dobey> angeloc: right, though the tag may also go away, or get changed back to verification-needed, for various reasons
[16:50] <angeloc> dobey: well okay, i have to check if the user has at least one bug, anytime soon it will have an SRU verified bug!
[16:50] <angeloc> dobey: if not, he should contribute more!
[20:23] <dobey> hrmm, why do my builds in ppa:ubuntuone/beta have a significantly longer wait to build than those in ppa:ubuntuone/nightlies exactly?
[21:06] <dupondje> Hey! Somebody that could look @ the ppa builders
[21:06] <dupondje> https://launchpad.net/~yade-pkg/+archive/stable/+build/3458800
[21:06] <dupondje> people doing daily builds of packages that take 18h+ to build
[21:06] <dupondje> should be allowed imo
[21:07] <dobey> i don't understand your statement
[21:08] <dupondje> well, it seems like some people (see https://launchpad.net/~yade-pkg/+archive/stable/+build/3458800) are uploading packages to their ppa daily
[21:08] <dupondje> not to bad, if the packages wouldn't take more then 18h to build ...
[21:09] <dobey> i think it's stuck
[21:12] <dobey> i mean, i don't think libreoffice even takes that long to build
[21:12] <dupondje> its not libreoffice :)
[21:12] <dupondje> see https://launchpad.net/~yade-pkg/+archive/stable/+build/3458800 for example
[21:13] <dupondje> started 18h ago
[21:13] <dobey> yes i know it's not libreoffice
[21:14] <dobey> https://launchpad.net/~yade-pkg/+archive/stable/+build/3458813 says it was successful and took 8 hours, 50 minutes
[21:15] <dobey> and the i386 build on natty took less than 4 hours
[21:16] <dupondje> strange
[21:16] <dupondje> 4h is still quite alot but ok :)
[21:16] <dobey> likewise on oneiric and precise
[21:16] <dobey> well, there are a lot more than 1 builder
[21:17] <dobey> so it's obviously stuck
[21:17] <dobey> and has been for a very long time
[21:17] <dupondje> its not stuck really
[21:17] <dobey> but i don't have the "kill this build" button
[21:17] <dupondje> refresh in 30 minutes :)
[21:17] <dupondje> you'll see it went to the next file ...
[21:27] <dobey> ok, so it's really slow
[21:28] <dobey> and it's c++. they must use templates
[21:30] <mwhudson> i presume you're not talking about armel :)
[21:32] <dobey> no, these specific builds are on amd64
[21:44] <bobweaver> hello I am wondering how I use dput I have made the whole package .deb .dsc .change ect how do I know push it to ppa ?
[21:47] <mwhudson> bobweaver: https://help.launchpad.net/Packaging/PPA/Uploading should cover this
[21:47] <mwhudson> you can't upload debs though
[21:56] <bobweaver> ok it still will not let me upload I will try again
[22:36] <maxb> There are no lpia PPA builders any more?
[22:36] <maxb> And this is recent?
[22:40] <wgrant> maxb: gold has been playing i386 for the last 24 hours because of the backlog. If you have an lpia build I can move it back.
[22:42] <wgrant> Also, I might try to contact these yade people and ask them to scale back...
[22:42] <wgrant> those builds are looooong
[22:44] <maxb> Well, it only really matters for hardy
[22:44] <maxb> So not hugely
[22:44] <wgrant> That's why I decided lpia probably didn't need the builder :)
[22:45] <maxb> But it means I can't promote a complete all-architectures build from my staging ppa to my release ppa
[22:46] <maxb> I suppose I could investigate playing with the Architectures field and see if LP can be asked not to build the package on lpia at all
[22:46] <wgrant> maxb: gold is lpia again, but it's busy building private stuff so it could be a while
[22:46] <wgrant> It can't :(
[22:47] <maxb> Or, I suppose I could just copy the package anyway, which will create a second needsbuild lpia build, and make the package uninstallable on lpia .... but it's only lpia
[22:49] <maxb> Hm, yes, the amd64 queue is a little extreme, isn't it
[22:52] <wgrant> Yeah
[22:52] <wgrant> quantal has that effect on things
[22:52] <wgrant> and yade doesn't help
[23:10] <Adri2000> I changed my default email address in LP
[23:10] <Adri2000> removed the old one
[23:10] <Adri2000> how should I login now?
[23:10] <Adri2000> looks like it still wants my old address for login, which seems weird
[23:11] <StevenK> Login is done using SSO, which is a seperate system
[23:13] <wgrant> You can manage your login email addresses at login.ubuntu.com
[23:13] <Adri2000> right, https://login.launchpad.net/+emails is probably what I was looking for then
[23:13] <Adri2000> thanks :)
[23:13] <wgrant> Or there