[10:02] <jfi> Hi, is it possible to 'close' a merge request? I would like to no more request it, but keep the comments for reference which appear to not be the case for 'delete proposal to merge'. The possible status are 'Needs review'/'Work in progress'/'Merged', nothing like 'Abandonned'
[10:06] <mgz> jfi, I use merged or rejected depending on which fits best
[10:06] <mgz> I see no problem in rejecting my own mps if I realise after submitting it's the wrong approach or something
[10:07] <wgrant> Only a reviewer for the target branch can set it to Rejected, I believe
[10:07] <jfi> mgz, 'merged' is not appropriate, 'rejected' should be nice but unfortunely I don't have this status in the list:( Maybe due to permission?
[10:07] <mgz> ah, well that sucks
[10:09] <jfi> wgrant, makes sense, maybe would also be nice that the author of the request has a status to 'abandon' the request
[10:09] <mgz> any deep reason for that, or should we just allow the submitter to reject their own stuff? don't see how it's different from marking it merged
[10:10] <mgz> (in that it could be confusing if set incorrectly, but is otherwise harmless)
[10:55] <mgz> heh:
[10:55] <mgz> # Non reviewers cannot reject proposals [XXX: what about their own?]
[11:02] <jelmer> mgz: they can delete their own, but they can't reject their own merge proposals
[11:03] <mgz> right, that is silly. what's the equivalent of branch.isPersonTrustedReviewer like isPersonOwner or something? there's an owner attribute but that can be a team
[11:03] <mgz> get the owner, then use some person thing to see if user is member?
[11:48] <mgz> okay, this seems to work
[11:49] <mgz> slightly annoying to test with launchpad.dev as you need to leave a bunch of teams first as ~name16 login?
[11:52] <mgz> merged is a bit of a wrinkle, it assumes the person listed as reviewer approved
[11:53] <mgz> so needs review -> rejected -> merged doesn't end up in a correct end state
[11:54] <wgrant> name16 is an admin, so trying to check unprivileged operations with it seems odd :)
[11:54] <wgrant> no-priv might be more appropriate
[11:54] <wgrant> Or name12
[11:57] <mgz> it's not documented on the wiki how to login in as anyone else...
[11:57] <wgrant> I removed passwords in January, so you just need to check another user's email address and use that
[11:58] <mgz> aha.
[11:58] <wgrant> no-priv is usually a good one to start with
[11:58] <mgz> it would be nice if the sample data was a bit more explanitory about what it is testing
[11:59] <wgrant> 2005
[11:59] <mgz> rather than having to learn name16 means adminny things, no-privs is at least sensible (but owns no branches)
[11:59] <wgrant> You might be able to guess how name16 came about
[12:01] <mgz> hm, not sure I have a good one. 16th user in lp db was launchpd dev, and their account was initially used in testing data, then stripped of personal details?
[12:01] <wgrant> name16 is person 16
[12:01] <wgrant> Originally, people didn't have names
[12:02] <wgrant> They were added, and the migration set them all to name$id
[12:02] <wgrant> Tests needed updating
[12:02] <wgrant> So they then became impossible to change without changing dozens, or now hundreds, of tests
[12:02] <wgrant> This is why sample data is bad
[12:03] <wgrant> Sasmple data for tests, that is
[12:03] <mgz> ho ho ho. and why the 16 exactly?
[12:03] <wgrant> That was just the value of the sequence at the time it was created back in 2004 or 2005
[12:03] <wgrant> It should still have person.id == 16
[12:03]  * wgrant checks
[12:04] <wgrant> yeah
[12:08]  * mgz answers own question before asking: `make newsampledata`
[12:12] <mgz> hm, but that didn't actually reset the data which is what I was after...
[12:13] <wgrant> 'make schema' recreates your databases from the tree
[12:13] <wgrant> 'make newsampledata' recreates the sampledata SQL in the tree from your databases
[12:13] <wgrant> (launchpad_dev -> current-dev.sql, launchpad_ftest_playground -> current.sql)
[12:13] <mgz> >_<
[12:13] <mgz> okay, so I need to revert then run the command in the right direction :)
[12:14] <mgz> thanks wgrant
[13:31] <q4a> hi all) I'm trying to update package zathura to new version and upload to my ppa. https://launchpad.net/ubuntu/+source/zathura - here i took debian folder, edit changes, but when I run 'debuild -S -sa', I got: "dpkg-source: info: local changes detected, the modified files are:  zathura-0.2.1/pdf-poppler-0-2-1/AUTHORS"
[13:32] <jelmer> hi q4a
[13:32] <jelmer> q4a: you might want to ask in #ubuntu-packaging, that's not really specific to Launchpad
[13:33] <q4a> jelmer: ok, thx =)
[14:41] <issyl0> 1
[14:41] <issyl0> Oops.
[14:43] <hramrach> hello
[14:43] <hramrach> how do you remove a project from launchpad?
[15:42] <cjohnston> czajkowski: ping
[15:43] <mgz> is on holiday, what do you need cjohnston?
[15:44] <cjohnston> mgz: thanks../52
[15:44] <cjohnston> mgz: I'm looking at bug #1035661 and it's still effecting me
[15:45] <cjohnston> I'm wondering if I should report a new bug, or get someone to reopen that one
[15:47] <mgz> cjohnston: the comment by sinzui implies you should file a new bug
[15:47] <cjohnston> thanks mgz
[16:08] <q4a> hi again) is it possible to add my own ppa the ability to build armhf package?
[16:10] <mgz> q4a: no, we don't provide arm builder except for the main archive and employees
[16:11] <q4a> mgz: may be any time soon? or may be i can build it in my chroot and upload it to launchpad?
[16:13] <mgz> yup, you'll want to build locally and upload
[16:14] <q4a> thx
[16:14] <mgz> hm... does that actually work? I think we might not let binary packages through anyway
[16:14] <mgz> you're probably best off asking in #ubuntu or somewhere how you're meant to support arm
[16:19] <cjohnston> mgz: reported..
[16:19] <cjohnston> thanks
[16:20] <mgz> cjohnston: might just want to add a comment to the closed bug mentioning the one you filed.
[16:24] <cjohnston> hrm.. I've gotten 3 timeouts on LP this morning
[18:18] <mgz> how, launchpad soyuz chums, did my dulwich-daily rebuild end up in the juju ppa rather than the bzr one?

[18:19] <mgz> might be related to the fact I screwed up the changelog first time round, then forgot to bump the version, but might now.
[18:19] <mgz> *not
[18:21] <dobey> mgz: my only guess would be a fumbled build request that set the archive to that one instead of the desired one
[18:23] <mgz> ah, a build request also has an option of where it builds into, that doesn't default to what the recipe says?
[18:23]  * mgz looks
[18:23] <mgz> yup, that seems to be it
[18:24] <dobey> it should default to what the recipe says, but i think the first time you build, it defaults to the first one in the list
[18:25] <dobey> after you build once to the correct ppa it should default to that when you use the request build link on the recipe page, at least
[18:26] <mgz> +request-builds just has a alphabetized <select> and no default
[18:27] <mgz> er, not alphabetized, semi-alphabetized
[18:30] <dobey> right
[18:44] <mgz> hm, and from the package importer...
[18:44] <mgz> bzrlib.errors.UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', "<Fault -1: 'Unexpected Zope exception: RequestExpired: request expired.'>")