[02:29] <persia> beuno: bigjools: There exists today a facility to copy packages from the PPAs to universe.  At issue is more that there doesn't exist a facility to provide review/feedback on the packages, and it is not possible to upload certain classes of revisions.
[02:30] <beuno> persia, that's interesting. Is it actually in use?
[02:31] <persia> beuno: In a couple cases, but rarely.  The lack of any means of discussion or review means that something in a PPA is unlikely to meet the requirements for a NEW package.
[02:32] <persia> And the way version number blacklisting works means that if someone doesn't get it right the first time, it becomes impossible to get it right later in a PPA.
[02:32] <beuno> persia, it would be interesting to pinpoint the exact tools that would help with that
[02:32] <persia> Mind you, there are a number of use cases for PPAs that make the current version number blacklisting behaviour correct.
[02:33] <persia> Would it?  There was discussion in Boston about what would be needed for LP to provide something like REVU.
[02:33] <beuno> it absolutely would. In what timeframe something like that could be implemented, is a different battle
[02:33] <persia> Essential items were being able to completely revise packaging to cover mistakes (e.g. upload -0ubuntu1 to override -1, or upload 0.2 to override 0.2rc4)
[02:34] <persia> Beaing able to comment on a given release, subscribe to a given package in a given PPA, and indicate advocation.
[02:34] <beuno> that doesn't sound too complicated
[02:34] <persia> Unfortunately, implementation of much of that breaks the use case for using PPAs as a means of distributing packages to end-users.
[02:34] <beuno> are there bugs open for it?
[02:34] <persia> bug #263301 has some related discussion, but nothing explicit.
[02:35] <persia> Essentially, it's a matter of determining whether a PPA is for end-user distribution or for review.  The workflows for these uses, and the constraints that need to be applied are sufficiently different that both doesn't work well for either.
[02:36] <beuno> persia, could you file relevant bugs requesting those features?   just having them there will increase the chances of getting it done
[02:37] <persia> beuno: Can you answer the question as to which is the appropriate use for a PPA?  I won't file bugs towards making it a better review system that would break the distribution experience for all end users without some indication that LP doesn't care about end-user distribution in PPAs.  Similarly, I won't file bugs about how PPAs are broken for end-user distribution without some clear indication that LP doesn't care about review use cases.
[02:37] <persia> The two are fundamentally incompatible, due to expectations on the part of dpkg, existing policies and guidelines, and other issues.
[02:38] <persia> The last answer I got from cprov was "both", but there was indication that it hadn't received deep thought.
[02:39] <beuno> I probably can't answer that with absolute confidence. I still think the bugs are relevant because it makes it easy to follow up on and discuss, but we could as well try this on the mailing list.
[02:39] <persia> I guess.  I think discussion at that level of detail is premature.
[02:40] <persia> It is likely that a decision in one direction or another will be forced by 263301, and that can the be guidance as to which workflow should be fixed (as the current behaviour is very much not ideal for either model)
[02:42] <beuno> persia, fair enough. I won't make you waste more time on it, since it seems you've already tried to get this through without much success.
[02:43] <persia> beuno: I didn't try real hard :)  The discussion in Boston foundered on similar confusions, and there was a *lot* more work that needed to be done on PPAs first.
[02:44] <persia> I think we're reaching the point where we can make progress in one direction or the other soon, but I think it's something that needs to be decided at a policy level, rather than from looking at the problems currently encountered by each use case.
[02:45] <persia> From a communications perspective, it's very difficult to have two sorts of PPAs, and having both limited in various ways may be the best way to not have to decide one way or the other.
[02:45] <beuno> persia, are you going to be at UDS in December?
[02:45] <persia> Yes.
[02:46] <beuno> cool, that may be a very good place to give it another round of discussion
[02:47] <beuno> I think I'll be there too, so I may be able to help as well  :)
[02:47] <persia> Indeed, although I wouldn't be surprised if a decision can be made sooner.
[02:47] <beuno> sure, would make the discussion more precise
[02:47] <persia> I think that 263301 is a good example bug where a change is requested that would break the distribution model in favour of the review model.
[02:48] <persia> Yes, once a decision is made, we can quickly outline the features that are needed to make that model work well, and discuss implementations at UDS.
[02:49] <beuno> great, I'm interested in that discussion  :)
[08:37] <gour> is c. reis the only LP admin creating project-groups?
[08:57] <stub> Not sure. Open a ticket at https://answers.launchpad.net/launchpad and see who takes it.
[08:58] <gour> i already did that - https://answers.launchpad.net/~kiko there are open tickets from 23rd...
[09:44] <gour> the other day i was browsing some LP's help docs with the examples of blueprints, but today i cannot find it :-/
[09:45] <gour> there were scans of paper & pen 'specs'
[10:16] <compengi> how could the membership in a team expire?
[10:17] <Hobbsee> because somenoe didn't renew it?
[10:18] <compengi> Hobbsee, is that someone from user's side or from the administrator's?
[10:18] <Hobbsee> compengi: administrators of the team.
[10:18] <Hobbsee> wait, are you talking about a user expiring from a team?
[10:18] <Hobbsee> if so, then the user's side.
[10:18] <compengi> hmm..
[10:18] <compengi> and how to renew it =/
[10:19] <Hobbsee> add the user to the team again
[10:19] <Hobbsee> or change their status, i guess
[10:19] <compengi> oh
[10:20] <compengi> but i don't see join the team. i only can see "leave"
[10:20] <gour> add?
[10:20] <Hobbsee> are you the administrator of the team?
[10:20] <compengi> nope
[10:21] <wgrant> If you can only leave, then you have not expired.
[10:21] <compengi> i'm a user. and today received and email that my membership in ubuntu-lb team would expire after 7 days from now.
[10:21] <wgrant> Ah.
[10:21] <wgrant> Click the link in the email.
[10:21] <wgrant> If it says you can renew it.
[10:21] <wgrant> If it doesn't say that, you must ask an admin.
[10:22] <compengi> yeah. it says i must contact admins
[10:22] <wgrant> Then contact the admins.
[10:22] <Hobbsee> then you have to contact the admins of the team.
[10:22] <compengi> is this by default?
[10:22] <Hobbsee> don't think so.
[10:22] <wgrant> I thought so.
[10:23] <compengi> weird
[10:23] <Hobbsee> hm, it might be.
[10:23] <wgrant> Why is this weird?
[10:23] <wgrant> Expiry dates with renewal do not make much sense.
[10:23] <persia> I think the default is an open team.  When one closes a team, one can decide how renewals work.
[10:23] <wgrant> persia: But there is a default for that too.
[10:23]  * ajmitch almost expired from core-dev, but that can be renewed by a user
[10:24] <compengi> why should the membership in a team renew his membership
[10:24]  * persia looks for an open team to close to discover the default.
[10:24] <compengi> an *approved* member also
[10:24] <wgrant> persia: Staging works well for that.
[10:24] <wgrant> compengi: That failed to parse - can you please rephrase?
[10:24] <persia> compengi: To show they are still active?
[10:24] <persia> wgrant: Aha.  That way I don't break anything.  Good idea!
[10:27] <compengi> wgrant, if there are no assigments to that team, in which people can participate in. how could someone know if users are active this way, knowing that some other users already participate and active in other projects
[10:31] <persia> compengi: It really depends on the team.  I'd argue that any well-defined team probably works towards some goal, and that any active member can probably report what they did and what they plan to do as part of the discussion with the team admins about renewal.
[10:34] <persia> Indeed.  I've just checked a team for which I'm an admin, and the default for moderated and restricted teams appears to be to invite members to apply for renewal.
[10:48] <klette> Hey, is it possible to set dependencies between bugs?
[10:48] <wgrant> Not at this time.
[10:48] <wgrant> Regrettably.
[10:48] <klette> Planned feature then I hope ;)
[10:48] <wgrant> Unfortunately I don't believe so. Though we (Ubuntu people) have asked for it.
[10:50] <klette> shrug
[10:51] <persia> klette: During the last discussion it ended up being blocked by definition: what does one bug depending on another mean?
[10:51] <persia> If you can come up with a coherent definition that is unlikely to be misunderstood without documentation, and unlikely to be abused, submitting it to the LP folk may result in implementation.
[10:51] <klette> persia: «that bug needs to be solved before we can solve this one»
[10:52] <klette> in my head at least ;)
[10:52] <persia> klette: OK.  What about two bugs that must be solved at the same time?  Is there a dependency?
[10:52] <persia> How about a bug in one place that is actually just a distant symptom of a bug in another place?
[10:53]  * persia isn't an LP developer, but just someone who remembers the last conversation
[10:54] <klette> the first one is tricky, but the second i would mark as a duplicate and add that info the the first bug, as its a result of one bug, not two
[10:58] <Volans> Hi all, perhaps there is some PPA admin here?
[10:59] <persia> Volans: What are you trying to accomplish?
[11:00] <Volans> persia:  there is a build in a virtual machine on my PPA that probably is in loop, I have tried to ask the owner (Adam Conrad) both via IRC or mail, but at the moment  no reply
[11:01] <wgrant> I'm sure somebody will notice eventually.
[11:01] <persia> Volans: Ah.  A broken buildd.  Yeah, that needs a specific sort of person.
[11:01] <wgrant> But it's not such a problem now that there are 31 buildds.
[11:01] <wgrant> infinity is your man, I believe.
[11:01] <Volans> if possible I want to stop the build, is useless and time consuming for the all PPA
[11:02] <wgrant> There are at least 9 other buildds, so it's not much of a problem for others.
[11:02] <Volans> wgrant: yeah, I have tried to talk with him, tonight in IRC and I have sent an email to him
[11:02] <Volans> after 1 hour for some reason the build is gone in a loop, only for lpia architecture
[11:02] <Hobbsee> Volans: normal mortals can't cancel builds
[11:03] <Hobbsee> lamont / infinity / elmo would be able to fix it.
[11:03] <Hobbsee> but infinity for one, isn't good at responding to emails.
[11:03] <Volans> so, I think is very useless to leave it
[11:03] <Hobbsee> even buildd admins can't.
[11:03] <Hobbsee> it pops up a dialog saying "feature not yet implemented"
[11:04] <Volans> Hobbsee: thanks, I will try with the other two, I have talked with lamont and elmo in the past for sysadmin stuffs
[11:04] <Hobbsee> i hope it's fixed relatively soon, but i doubt it will be.
[11:30] <compengi> i'm trying to set a gpg keyserver by "gpg --keyserver keyserver.ubuntu.com" but it seems to take too long. no idea if it's stuck
[11:31] <compengi> i just see "Gpg:  On it goes - message enter...  " and nothing happens. it's been like this over half an hour
[12:52] <sabdfl> would make sense to allow the uploader, or someone with permissions on the destination archive, to kill a build
[12:54] <wgrant> https://blueprints.edge.launchpad.net/soyuz/+spec/builder-job-aborting
[12:54] <wgrant> But I'm not sure if that would cover privileges.
[15:48] <epsy> hi, this is a minor issue, but it's rather confusing..on the commit atom feeds there is always a trailing "..." even if the commit message is complete
[15:49] <intellectronica> epsy: maybe file a bug?
[15:49] <epsy> okay
[15:51] <epsy> intellectronica, in what project ?
[15:53] <intellectronica> epsy: https://launchpad.net/launchpad-bazaar/+filebug
[16:15] <persia> cprov: bug #252689 and bug #263301 aren't quite duplicates: one is about the orig.tar.gz, and the other about the diff.gz and .dsc.  They are admittedly both about the blacklisting rules, so may be easily solved together.
[17:12] <persia> al-maisan: Regarding bug #250820 : the example email has both corrupted and uncorrupted non-ASCII text.  Is that intentional?
[20:31] <gour> LP admin created project-group for me, but it looks i'm not able to add existing project(s) to it, right?
[20:38] <matsubara> gour: in change details for your project you should have the option to choose which project group your project is part of
[20:45] <gour> matsubara: thanks a lot. somehow i missed it :-/
[20:47] <matsubara> gour: you're welcome
[20:47] <gour> :-)
[20:47] <gour> enough for today...
[20:48]  * gour ---> sleep
[20:48] <gour> good night
[20:55] <cyberix> Is marking bugs invalid until they get forwarded upstream the right thing to do? https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/258003
[20:57] <beuno> cyberix, that doesn't sound right. Does the bug exist in Ubuntu?
[21:04] <cyberix> beuno: yes
[21:04] <beuno> cyberix, than the bug is valid
[21:04] <cyberix> sorry I said wrong
[21:04] <cyberix> the status is incomplete
[21:05] <cyberix> but I think the report is not lacking anything
[21:05] <cyberix> expect for reporting upstream
[21:06] <chadm> I am trying to connect to http://bazaar.launchpad.net/~mysql/mysql-server/mysql-4.1/files
[21:06] <chadm> but I am getting the following error
[21:06] <chadm> http://bazaar.launchpad.net/~mysql/mysql-server/mysql-4.1/files
[21:06] <chadm> err
[21:06] <chadm> Sorry, there was a problem connecting to the Launchpad server.
[21:08] <chadm> anyone able to help?
[21:08] <jpds> barry: Odd, it appears to be determined on: "Searching for httplib2==0.2.0".
[21:10] <barry> jpds: did you try the -d (develop) switch?  does it do anything different in that case?  note that the target of -d must be on $PYTHONPATH
[21:11] <beuno> cyberix, than you should note that in a comment
[21:11] <beuno> and leave the bug as confirmed/triaged
[21:12] <beuno> as the bug itself is not incomplete
[21:12] <cyberix> I reported it originally, so I'm not sure, if I'm allowed to change the status into confirmed
[21:12] <jpds> barry: Running the command you suggested just gives me: http://paste.ubuntu.com/42826/
[21:13] <barry> jpds: PYTHONPATH=`pwd`/staging ./setup.py develop -d staging
[21:14] <jpds> barry: That gives me the same as before.. : http://paste.ubuntu.com/42828/
[21:15] <barry> jpds: very odd.  setuptools is being stoopid
[21:17] <barry> jpds: try blowing away launchpadlib.egg-info and trying again
[21:18] <jpds> Same.
[21:18] <jpds> I have the intrepid python-setuptools.
[21:32] <barry> jpds: note that i'm trying everything with a from-source build of 2.5.2
[21:33] <barry> though i don't see why it should matter
[22:04] <bruce90> surely the lp mappy thing could use OSM?
[22:55] <Odd_Bloke> Just realised that I don't want https://code.edge.launchpad.net/~vcs-imports/gwibber/debian to be imported by Launchpad, as that'll generate new revisions when it's been pushed there with bzr-svn (right?).
[23:01] <mwhudson> Odd_Bloke: um, possibly not
[23:01] <mwhudson> i can delete the import for you if you want...
[23:04] <Odd_Bloke> mwhudson: Yeah, please.
[23:07] <mwhudson> Odd_Bloke: done
[23:07] <Odd_Bloke> mwhudson: Thanks. :)