[00:51] <alexp_sssup2> hi everyone. PPAs does not support building for powerpc, but don't accept binary packages either. What is the right way to provide powerpc debs to users (beside uploading then somewhere else?)
[00:52] <wgrant> alexp_sssup2: You can't do that with a PPA, unfortunately.
[05:29] <jtv> lifeless: thought this might interest you… https://code.launchpad.net/~jtv/storm/profile-fetches/+merge/43323
[07:36] <Admin_> b
[09:36] <alopenerp> How can i buy a voucher to register a project as private ?
[09:37] <alopenerp> It used to be available on canonical shop
[10:03] <mrevell> Hello alopenerp, sorry for the delay in spotting your question.
[10:03] <mrevell> alopenerp, Mark your project's licence as "proprietary" and you'll get a link taking you to buy the voucher.
[10:03] <mrevell> alopenerp, Ping me if you need any help.
[12:50] <kiko> hey there
[12:50] <kiko> question
[12:50] <kiko> should a series driver not have the right to +setproductseries for a blueprint?
[12:51] <kiko> mrevell, ^^
[12:55] <kiko> hellooo
[12:55] <kiko> sinzui? flacoste?
[13:10] <alopenerp> mrevell: I bought a voucher my project is currently licensed as apache and i would like to set it as proprietary, but i'm unable to do so
[13:27] <alopenerp> I just redeemed a voucher but my branches are still public, it's a well known bug in launchpad that require a manual fix, i did it many here on irc could somebody fix my project openerp-ctp ?
[13:40] <maxb> losa ping: Anyone available to help alopenerp ?
[13:43] <mthaddon> alopenerp: which person or team should be able to create branches?
[13:55] <mrevell> maxb, mthaddon: I think alopenerp has resolved the issue ... we've been PMing.
[13:55] <mthaddon> ok
[14:33] <alopenerp> mthaddon: nope it's not yet resolved all branches i push are public i don't know how to switch them to rpivate
[14:33] <mthaddon> alopenerp: which team or person should be able to see the private branches?
[14:34] <alopenerp> team ~openerp-ctp
[14:34] <alopenerp> project openerp-ctp
[14:34] <mthaddon> alopenerp: ok, you should be all set
[14:38] <flacoste> kiko!
[14:39] <alopenerp> mthaddon: thanks it's ok now
[14:39] <kiko> flacoste, :)
[14:39] <kiko> how are you
[14:39] <kiko> flacoste, nobody helped me, so I had to help myself
[14:40] <mthaddon> great
[14:40] <flacoste> i'm good, do you still need help?
[14:48] <kiko> flacoste, no, it's all good
[14:48] <kiko> flacoste, see my question above though
[14:48] <kiko> product drivers don't have blueprint Edit permission basically
[14:50] <flacoste> kiko: product drivers or product series driver?
[14:51] <flacoste> kiko: if you file a bug we could fix it rapidly, we are in bug jam mode until the end of the year :-)
[14:51] <kiko> flacoste, product drivers.
[14:51] <flacoste> kiko: that looks shallow and easily fixable
[14:51] <kiko> flacoste, hmm, I asked salgado to try, let me check
[15:04] <flacoste> sinzui, bac, Edwin-afk: does one of you can qa bug 638924
[15:05] <sinzui> EdwinGrubbs, was doing that QA 30 minutes ago
[15:05] <sinzui> The page is better, but not perfect. EdwinGrubbs was going to hunt down some staging oopses to verify if the death was in the ORM
[15:06] <EdwinGrubbs> flacoste: I can mark it as qa-ok, since it works fine except for not completely solving the timeout problem.
[15:06] <flacoste> EdwinGrubbs: thanks
[15:07] <flacoste> sinzui: are you doing QA of bug 689431?
[15:08] <sinzui> Yes staging is broken Chex is helping me
[15:08] <flacoste> sinzui: shouldn't we testing this on qastaging?
[15:09] <sinzui> qastaging does not have a mailman
[15:09] <sinzui> or an archives which is what I am testing
[15:09] <flacoste> sinzui: ok, can you file a RT to make sure we fix that?
[15:09] <flacoste> we should be able to QA mailing lists stuff on qastaging since it's part of the nodowntime set
[15:09] <flacoste> it thought it had been done
[15:10] <sinzui> the archives or that qastaging does not have a mailman
[15:10] <flacoste> the mailman
[15:10] <flacoste> and archives
[15:10] <flacoste> but maybe mailman was done, but not the archives setup
[15:11] <flacoste> abentley: hello, since thumper is on leave, do you think you could qa bug 670440?
[15:12] <abentley> flacoste, I'll look into it.
[15:12] <flacoste> abentley: thanks
[15:12] <flacoste> Ursinha: we have a registered bug about reusing branch in qa-tagger right?
[15:12] <Ursinha> flacoste, yes
[15:13] <flacoste> Ursinha: how do we work-around it in the mean time?
[15:13] <Ursinha> flacoste, what's the situation? I've landed a fix that doesn't touch fix released bugs when linked to the branch, only others
[15:14] <flacoste> Ursinha: revision 12065 and 12083
[15:14] <flacoste> Ursinha: what about if it wasn't fix released
[15:14] <flacoste> but fix commited
[15:14] <flacoste> because the branch was reused before the revision was deployed
[15:14] <Ursinha> than it will be touched
[15:15] <flacoste> can we change that to fix commited?
[15:15] <flacoste> since it makes sense to merge the branch, qa it
[15:15] <flacoste> and then reuse it
[15:15] <flacoste> it's possible that it's not deployed between the two events
[15:15] <flacoste> like now
[15:15] <Ursinha> flacoste, problem is you have incremental commits, or commits fixing bad branches (not rollbacks)
[15:15] <flacoste> Ursinha: and i think the problem isn't that the tags are touched
[15:15] <flacoste> Ursinha: but more that the revision is considered linked to two unrelated bugs
[15:16] <flacoste> look at the current report for those two revisions
[15:16] <Ursinha> looking
[15:18] <Ursinha> flacoste, hm, iirc the previous discussion on this behavior, the only way to "fix" that would be to make tagger only consider mentioned bugs in the commit msg, not linked bugs to the branch
[15:19] <Ursinha> this behavior of checking bugs linked to the branch was added due to people forgetting to mention bugs and we end up with lots of untested commits
[15:19] <flacoste> Ursinha: really? i'm sure we could apply some heuristics here
[15:19] <flacoste> for example if a branch link is merged and the bug is fix released or fix-commited QA-ok do not consider for the new revision
[15:20] <Ursinha> branch link is merged, what exactly that means?
[15:21] <flacoste> Ursinha: if you look at bug 660770
[15:21] <flacoste> and compare with bug 673252
[15:21] <flacoste> actually, that's a bad example since the second one doesn't have any branch linked :-/
[15:22] <flacoste> but if it had, you'd see that the branch was merged
[15:22] <flacoste> whereas on the first one, it's still up for review
[15:22] <flacoste> and you can look at the merged revno on the merge proposal
[15:22] <Ursinha> so I'd need to check the merge proposals of that branch
[15:22] <flacoste> to distinguish between, it's a reuse and it fixes two bugs
[15:23] <flacoste> yeah, that's my suggestion
[15:23] <Ursinha> I wonder if you have lots of merge proposals in the same branch, linked to lots of bugs, will all of them appear in every bug? because the bug is linked to a branch that has lots of mps
[15:23] <Ursinha> not sure I'm making sense
[15:23] <Ursinha> let me think a bit
[15:24] <flacoste> Ursinha: i haven't see that
[15:24] <flacoste> but they probably apply similar logic in the code
[15:24] <flacoste> abentley or thumper would be able to confirm
[15:24] <Ursinha> hm, no because a branch can have only one active mp for a target at a time
[15:25] <Ursinha> abentley, is that correct?
[15:25] <abentley> Ursinha, that's correct.
[15:28] <Ursinha> wondering how would I find that merged mp related to the bug
[15:29] <abentley> Ursinha, merge proposals don't link to bugs in any way.  The display just uses the branch links.
[15:29] <Ursinha> that's what I thought
[15:29] <Ursinha> so how could I tell a merged mp relates to a specific bug, so I wouldn't touch it?
[15:30] <Ursinha> I need coffee :)
[15:30] <abentley> Ursinha, I can only think of gross things like scanning the description for "bug #"
[15:31] <abentley> flacoste, I think it would be nice if bug fixes were linked to revisions in our data model, not to branches.
[15:32] <flacoste> abentley: that sounds like a sound idea
[15:34] <abentley> flacoste, I guess that's a LEP?
[15:36] <flacoste> abentley: it could be one, but it could also be a model change to address some bugs
[15:36] <flacoste> depending on the scope of the changes
[15:37] <flacoste> but since it's kind of tricky, a LEP might be in order
[15:37] <abentley> flacoste, True, but I think it's "features-sized", because the existing model is assumed all over the place.
[15:37] <flacoste> yeah
[15:37] <flacoste> it's tricky beceau on the other hand, there has been a lot of criticism on the way bzr does --fixxes
[15:38] <flacoste> which basically ties a revision to a bug fix
[15:38] <abentley> flacoste, data migration would be a nightmare, for example.
[15:38] <abentley> flacoste, are the criticisms just that if you forget, you can't fix it later?
[15:38] <flacoste> whereas we didn't record revision in the bugbranch link
[15:38] <flacoste> abentley: and that the fix is usually over multiple revisions
[15:39] <flacoste> more like LP does it, when using a feature branch: this branch is intended to fix that bug
[15:39] <flacoste> and there is no single revision that provides the fix
[15:39] <flacoste> but when it's merged on mainline then one revision contain the fix
[15:40] <abentley> flacoste, in bzr, revisions are tree snapshots, not deltas.  So to me, the first snapshot that doesn't have the bug is the one that fixes it.
[15:41] <flacoste> ok, i can get that
[15:41] <flacoste> but from a UI perspective i think you have to be intimate with the bzr data model to get it
[15:41] <flacoste> so it's not really intuitive
[15:42] <flacoste> most people think of revision as deltas
[15:42] <flacoste> i do
[15:42] <flacoste> even if for bzr, that's not the case
[15:43] <abentley> flacoste, if you think of it as deltas, there may be many deltas leading up to the bug being solved, but there's one that builds on the others to actually fix the bug.
[15:48] <flacoste> right, that's also 'correct'
[15:48] <flacoste> but as a user, i think of it in two ways
[15:48] <flacoste> i create a feature branch that fixes the bug
[15:49] <flacoste> once it's merged on mainline it's fixed
[15:49] <flacoste> or i like you explained, i commit and at one point the bug is no more
[15:49] <flacoste> which i can record their
[15:49] <flacoste> there
[15:50] <flacoste> anyway, in both case, the bzr data model is probably fine
[15:50] <flacoste> we just have to be clever at the UI level above it
[15:51] <flacoste> and consider both feature branch and one-branch cases
[15:51] <flacoste> in short, yeah, that probably sounds like a LEP :-)
[15:55] <abentley> flacoste, fullly agreed.
[15:59] <abentley> Ursinha, could qa-tagger look for "its own bug fixed by a commit" messages to figure out what revision fixes a bug?
[15:59] <abentley> Ursinha, could qa-tagger look for its own "bug fixed by a commit" messages to figure out what revision fixes a bug?
[16:02] <flacoste> kiko: salgado proposed https://code.launchpad.net/~salgado/launchpad/target-driver-edit-blueprint/+merge/44046 to fix your issue
[16:04] <kiko> flacoste, so I hear, help get it through :)
[16:07] <kiko> flacoste, is QA on that done on staging?
[16:07] <flacoste> kiko: qastaging
[16:07] <kiko> flacoste, qastaging.launchpad.net?
[16:08] <flacoste> kiko: yep, but it's not merged yet, bac just approved the review
[16:08] <kiko> cool
[16:08] <bac> kiko: i just sent it to ec2 for salgado.  it'll be a few hours...
[16:09] <kiko> bac, okay, ping me when it's back -- and thanks
[16:10] <bac> kiko:  ok.  also i subscribed you to bug 691559
[16:12] <flacoste> jelmer: what's the QA status of bug 690074?
[16:13] <jelmer> flacoste: it is QA OK, like the other bug that branch fixes.
[16:13] <jelmer> flacoste: updating now, thanks for the reminder.
[16:13] <flacoste> jelmer: thx!
[16:18] <aboudreault> hi. I'd to download a file listed in the PPA package details. but got a file not found. what's the URL to get the directory list of the ppa?
[16:18] <aboudreault> *directory file list*
[16:24] <flacoste> sinzui: let me know once you've QA-ed bug 689431, i'll trigger set-up the nodowntime release
[16:24] <jelmer> aboudreault: Hi
[16:24] <sinzui> flacoste, I ask for the mbox since the archives is usless
[16:24] <jelmer> aboudreault: There isn't a single directory you can list. You could look at the Packages file for a particular distroseries in the PPA (e.g. maverick)
[16:25] <jelmer> aboudreault: The best way to look at the contents of the PPA is using the "View Package Details" link on the PPA web page, or using the web service API.
[16:25] <aboudreault> jelmer, I'm already there. but the link are broken.
[16:26] <jelmer> aboudreault: Which PPA? That's probably a bug.
[16:26] <aboudreault> jelmer, https://launchpad.net/~georepublic/+archive/pgrouting-testing/+packages , trying to download pgrouting_1.6.0-0+1-SNAPSHOT.orig.tar.gz  (51.0 KiB)
[16:27] <jelmer> aboudreault, That file appears to be removed from the librarian (our file store)
[16:28] <jelmer> I'm not sure why.
[16:28] <aboudreault> it's not the first time I got something like that
[16:28] <aboudreault> (in different ppas)
[16:29] <jelmer> The file does still appear to be present in the pool:
[16:29] <jelmer> http://ppa.launchpad.net/georepublic/pgrouting-testing/ubuntu/pool/main/p/pgrouting/
[16:31] <aboudreault> good, can download it from there
[16:32] <jelmer> I'm not sure what's going on with the file in the librarian
[16:37] <aboudreault> jelmer, do you take care to create a bug or.. ?
[16:38] <jelmer> aboudreault: Yes, I'll see if I can find the relevant bug and file a new one if I can't. Should I subscribe you?
[16:39] <aboudreault> great. yes please. "aboudreault". Thank you!
[16:39] <jelmer> ok
[17:52] <lamont> launchpadlib has to be packaged somewhere, doesn't it???
[17:54] <benji> lamont: I don't quite understad the question.  If you want to install it, "apt-get install python-launchpadlib" should work for you.
[17:54] <lamont> benji: it was more that I'm running maverick and apt-cache search launchpadlib returned nothing
[17:55] <lamont> though interestingly, python-launchpadlib has been there since karmic. silly apt
[18:25] <maxb> That's fairly odd. I uploaded a package for hardy/jaunty/karmic/lucid/maverick/natty, and just the karmic upload disappeared into a black hole
[18:27] <maxb> If there's anyone with log access around, is there anything in the upload processor logs for mercurial mercurial_1.7.2-1ppa1~karmic1 to ~mercurial-ppa/staging-releases around 14:35 UTC (since reuploaded just now)
[18:46] <smoser> hi. is there any way to download mbox format archives of mailing list on launchpad ?
[18:47] <smoser> ie: https://lists.launchpad.net/openstack/threads.html i'd like to get an mbox like is common for mailman lists
[18:47] <smoser> (ie http://lists.mindrot.org/pipermail/openssh-unix-dev/ see 'Downloadable Version')
[18:47] <Chipaca> hi all. I can't find how to stop a project from using answers (that is, it's using answers, and I want to make it stop). Help?
[19:08] <Chipaca> abentley: ping
[19:08] <abentley> Chipaca, pong
[19:09] <Chipaca> abentley: hi. My Q above ^
[19:10] <abentley> Chipaca, on the project page, there should be a listing of what the project uses, with a configure link below it.
[19:10] <Chipaca> abentley: I don't see it :(
[19:11] <abentley> Chipaca, do you have admin rights to the project?
[19:11] <Chipaca> abentley: I see the "administer" link
[19:12] <Chipaca> abentley: I assume that means yes
[19:12] <abentley> Chipaca, what project?
[19:12] <Chipaca> abentley: ubuntuone
[19:13] <abentley> Chipaca, I see what you see.  I suspect this means that the rights to configure this are very limited.
[19:14] <Chipaca> abentley: meaning I have to pester the person who registered the project?
[19:14] <abentley> Chipaca, I think so.
[19:14] <Chipaca> abentley: ok
[19:20] <abentley> Chipaca, here's what I see on a project I registered: http://people.canonical.com/~abentley/configure-tracker.png
[19:20] <Chipaca> abentley: i know the box you mean, i see it also in projects i registered
[19:20] <Chipaca> abentley: the ubuntuone project is a lot more complicated and special than the ones I've registered myself, though :)
[19:21] <abentley> Chipaca, :-)
[19:36] <abentley> sinzui, do you know whether it's possible to get an export of a Launchpad-hosted mailing list in mbox format?
[19:38] <sinzui> not without a losa's assistance. The admin can copy the mailman/archives/private/<team>-mbox/<team>.mbox
[19:39] <sinzui> ^ abentley that mbox is always complete. The db file in the same directly keep a record of what can be published as pages
[19:42] <abentley> smoser, That's not something provided by Launchpad.  It would require admin intervention.
[19:43] <smoser> thats what i thought, thanks for the verification.  it is a nice feature in mailman.
[19:47] <abentley> smoser, np.