[00:14] <popey> hmm, i recently had my lp id changed from alanpope to popey, my ppa page on lp says that the path to my ppa is http://ppa.launchpad.net/popey/ppa/ubuntu but that 404s, the old url http://ppa.launchpad.net/alanpope/ppa/ubuntu works
[00:15] <popey> i guess this is a bug in the whole name-changing thing, problem is my ppa page actually has the 404ing url in it. I am giving a talk on saturday at my lug about bugs and ppas, would be nice not to expose lp to some ridicule :S
[00:15] <popey> is it possible to get my ppa renamed?
[00:17] <wgrant> popey: You weeeeere told it would break your PPA.
[00:17] <popey> i was?
[00:17] <popey> i didnt realise it would break like this
[00:18] <wgrant> Fortunately, it's fixable.
[00:18] <popey> shall i file a question on lp?
[00:18] <wgrant> Just delete all of the packages, wait 5 minutes, then copy them back in.
[00:18] <wgrant> That'll have it fixed in 10 minutes.
[00:18] <popey> ooo, thats even better
[00:18] <popey> nice one, thanks!
[00:19] <wgrant> And then maybe ask a question to get your old PPA removed from ppa.launchpad.net, as it'll be orphaned now.
[00:19] <popey> nice patronising weeeeeeere there by the way ;)
[00:19] <popey> should i delete my ppa and create a new one after deleting the packages from it? or is that not necessary?
[00:19] <wgrant> You can't delete the PPA - but no, that's not necessary.
[00:19] <popey> ok
[00:20] <Daviey> This is horribly broken
[00:20] <wgrant> Actually, it's possible you could need to wait for the packages to actually be removed from disk first (every 30 minutes, IIRC), before you copy them back.
[00:20] <zsquareplusc> i thought there was a way to automatically build packages from a bzr repo. but the help page only talks about uploading.
[00:20] <popey> i will wait overnight
[00:21] <wgrant> zsquareplusc: Various people have written various scripts to do that. There's nothing built into Launchpad to do that yet.
[00:22] <wgrant> Daviey: What's horribly broken?
[00:23] <popey> someone else could sign up as alanpope and they may have trusted me personally previously, they may not trust the new me
[00:23] <Daviey> wgrant: -> pm
[00:23] <wgrant> popey: The OpenPGP key will stop that.
[00:23] <zsquareplusc> wgrant: ahh now i see, i can upload source packages and they are automatically built. but not yet directly from a repo. thats ok
[00:23] <popey> he explains it better anyway :)
[00:23] <wgrant> zsquareplusc: That's right.
[00:24] <wgrant> Daviey: OK...
[00:24] <Daviey> wgrant: ah well.. it's here now
[00:24] <Daviey> I'm *assuming* it creates a new gpg key.. not checked that if i sign up as ~alanpope now it does
[00:24] <wgrant> It does, yes.
[00:24] <Daviey> but the bigger issue is, how many people bother checking the apt-get warning
[00:25] <wgrant> the OpenPGP key is associated with the PPA in the DB, so it will have been moved with the PPA.
[00:25] <wgrant> Well, it exists for a reason.
[00:25] <Daviey> (considering people are used to apt-get  gpg warnings)
[00:25] <wgrant> It shouldn't be ignored.
[00:25] <wgrant> They shouldn't be used to them.
[00:25] <wgrant> much much worse things can happen if people ignore them.
[00:25] <Daviey> further, a *real* example is ~screen-profiles, which does indeed have many subscribers
[00:25] <Daviey> (well did)
[00:26] <Daviey> "They shouldn't be used to them." doesn't really wash IMO
[00:26] <wgrant> It is certainly a problem.
[00:26] <Daviey> I'm *certain* most users would ignore it
[00:26] <wgrant> Those users are buggy.
[00:27] <Daviey> i imagine many people wouldn't bother checking the digits
[00:27] <wgrant> And apt should probably refuse to install packages from a repo that has recently become unsigned.
[00:27] <wgrant> But, then there's still the risk that somebody will stumble on instructions about installing the old PPA.
[00:27] <Daviey> And if you think about the script mez posted to planet ubuntu, which *many* people adopted (as it brought down the ubuntu keyserver), then that gpg key is automagically imported
[00:27] <wgrant> Then they'll go to the fake PPA page on LP, and get the new evil key.
[00:27] <wgrant> And everybody dies.
[00:28] <popey> wonder how many people did adopt the mezism
[00:28] <Daviey> LP really isn't designed for people changing names, eh :)
[00:28] <popey> s/name/id
[00:29] <zsquareplusc> oww. debuild -S packages the .bzr directory and other files not belonging to the distribution too :/
[00:29] <wgrant> Daviey: That *is* part of the reason you're not allowed to change your name if you have a PPA.
[00:29] <spm> wgrant: point of order. :-) "<wgrant> Those users are buggy." no. that's human nature. exceptions should be just that, exceptional. if it ever becomes normal, then the exceptions themselves are the problem. not the person.
[00:29]  * Daviey thinks about waiting for a popular team to change id.. and creating a PPA with a package that pings a url of mine as part of postinst to count how many people would have been fooled
[00:29] <spm> This is one reason why VISTA's security popups are such a fail. they become "normal" and hence mindlessly accepted.
[00:29] <wgrant> zsquareplusc: Perhaps use bzr-builddeb, or pass '-i' to debuild
[00:31] <wgrant> spm: Right. So the error should be more like the one when apt attempts to remove an Essential package. The user gets a nice big warning, and has to type a sentence acknowledging their fate.
[00:31] <wgrant> If they ignore that, there is nothing that can be done to save them...
[00:31] <spm> ha!
[00:31] <spm> aas, it is not that easy :-)
[00:31] <spm> alas!
[00:32] <spm> piss them off enough, and they'll find a way to switch the irritation off altogether. even worse end result.
[00:32] <Daviey> (aka mez's script)
[00:32] <spm> aiui, yes.
[00:32] <wgrant> Apparently.
[00:33] <zsquareplusc> mmm, debuild 's --help and the manpage do not explain -i though they mention it in an example
[00:33] <wgrant> zsquareplusc: That's because debuild calls dpkg-buildpackage, which calls dpkg-source. See dpkg-source's manpage.
[00:33] <Daviey> Well even running the script manually, popey's post, would be enough to cause a dangerous situation
[00:33] <wgrant> Daviey: Right.
[00:34] <wgrant> So, the moral of the story is that you should always examine email addresses and team memberships of a PPA owner. And/or LP should blacklist old names.
[00:34] <wgrant> But the latter removes much of the reason for renaming accounts - freeing up the namespace.
[00:34] <spm> we had this issue in defence land with MAC's on workstations. force users to DTRT, and you end up with personal shopping lists classified Top Secret.
[00:35] <Daviey> wgrant: i'm certain that locking the old id for a period of time would cause too much issue
[00:35] <wgrant> Daviey: s/would/wouldn't/?
[00:35] <SamB> spm: that sounds like the wrong thing to me
[00:35] <Daviey> err wouldn't :)
[00:36] <spm> SamB: in what way?
[00:36] <SamB> well, it's just excessive
[00:36] <SamB> shopping lists classified top secret!
[00:36] <spm> well that's the fault of using technical controls to solve a people problem. basically. :-)
[00:37] <spm> MAC's don't care about contents, only enforcement.
[00:37] <SamB> now, rw------- I could see
[00:37] <SamB> but top secret means something a bit different from that
[00:38] <spm> SamB: MAC as in madatory access controls. rw----- on steroids kinda thing. force bell-la-padula(sp?) model onto windows etc.
[00:38] <Daviey> wgrant: if you google screen-profiles and PPA there are a number of links that advise (or link to) adding a defunct PPA.  It's too easy for a rogue to adopt the now unused LP id
[00:38] <spm> SamB: so can copy'n'paste from a Secret window into a TS one, but not the other way.
[00:39] <SamB> okay, yeah, that's kind of idiotic
[00:39] <wgrant> Daviey: Right - that's a situation I mentioned earlier.
[00:39] <spm> end result, users end up working in the TS windows only, as life is easy there.
[00:39] <Daviey> oh
[00:39] <spm> yup. it is idiotic. :-)
[00:39] <SamB> isn't that kind of like running as Admin ?
[00:39] <wgrant> Yes.
[00:40] <SamB> Vista's dialog is better than *that*
[00:42] <spm> is not so much the dialog itself, more the frequency of. when he was ~ 3, our little boy was perfectly trained by the XP UI to automatically close any and all warning/error popups. that's a UI  design fail. and a big one.
[00:42] <spm> little boy that cries wolf; by another name,
[00:42] <wgrant> Hmmm. Does process-deathrow not run every half hour?
[00:44] <spm> wgrant: are you talking LP here? and err which part of? :-)
[00:44] <antono> hello
[00:44] <wgrant> Ah, there we go.
[00:45] <antono> i just face a problem
[00:45] <wgrant> spm: It's the Soyuz thingy that removes packages from the disk.
[00:45] <wgrant> It just ran.
[00:45] <wgrant> popey: You can probably restore stuff to your PPA now.
[00:45] <spm> 'k
[00:45] <antono> i just copied package from my ppa to https://edge.launchpad.net/~ubuntu-on-rails/+archive/ppa
[00:45] <popey> wgrant: yeah, its fine now thanks
[00:45] <antono> both ppas in my sources.list
[00:46] <antono> when i trying to update my package i getting following error from aptitude:
[00:46] <antono> E: Failed to fetch http://ppa.launchpad.net/ubuntu-on-rails/ppa/ubuntu/pool/main/g/gitg/gitg_0.4.1-3_i386.deb: Size mismatch
[00:47] <antono> what should i do?
[00:49] <wgrant> antono: I wonder if you have a dodgy proxy between you and Launchpad - that all looks fine to me.
[00:50] <antono> nope, only if my provider is clever enough to setup such a proxy
[00:51] <antono> i'll try to get info from my provider
[00:52] <zsquareplusc> mm. bzr-builddeb looks nice. but it complains about a missing debian/files while debuild -S runs happily without that one
[00:52] <james_w> I dispute that
[00:52] <james_w> :-)
[00:52] <james_w> did you run "bzr builddeb -S"?
[00:53] <wgrant> antono: I can confirm that the archive works fine for me, so it's something on your end.
[00:53] <antono> wgrant: thanks
[00:53] <zsquareplusc> james_w: yes
[00:53] <zsquareplusc> "native" mode
[00:54] <james_w> zsquareplusc: can you pastebin the output please?
[00:54] <antono> is it ok to have 2 versions of one package in both ppas?
[00:54] <antono> *2 copies
[00:54] <james_w> I'm pretty sure bzr-builddeb doesn't check for debian/files
[00:54] <wgrant> antono: They're different binaries, but that is normally fine.
[00:55] <zsquareplusc> james_w, i get three lines: Building using working tree | Running in native mode | bzr: ERROR: [Errno 2] No such file or directory: '<cut>/debian/files'
[00:55] <james_w> ah
[00:55] <james_w> I know this bug
[00:55] <james_w> sorry, I should have remembered it earlier
[00:56] <james_w> it's actually "No such file or directory: some file that has been removed"
[00:57] <antono> wgrant: thank you so much! :)
[00:57] <wgrant> antono: No problem.
[00:58] <james_w> zsquareplusc: bug 174539 I suspect
[00:58] <patapouf> Hi all,
[00:59] <patapouf> I wondering if someone can tell me where I should execute the merge operation if I have a trunk branch a another branch ..
[01:01] <zsquareplusc> james_w ah i see now. no i don't think it is that bug. but i have removed the file and have not yet committed.  there should be some sort of warning like "WARNING: you are building in a working copy with changes" or something like that
[01:02] <intellectronica> patapouf: what do you mean? do you want to merge your branch into trunk?
[01:02] <james_w> zsquareplusc: what does your "bzr status" say?
[01:02] <james_w> perhaps it's a new bug
[01:03] <zsquareplusc> it reports the file that caused the error as removed
[01:03] <patapouf> yep, devel to trunk ...
[01:03] <james_w> ok. thanks
[01:03] <intellectronica> patapouf: just push a merged branch to the location of trunk
[01:04] <patapouf> ok ..
[01:06] <zsquareplusc> james_w after bzr ci, it builds w/o error now :-)
[01:06] <james_w> woop
[01:06] <james_w> zsquareplusc: would you be so kind as to file a bug report telling me how I could reproduce?
[01:08] <zsquareplusc> ow.. reproduce.. hey i'm just building my first package on my own here ;-)
[01:10] <james_w> heh :-)
[01:20] <zsquareplusc> i guess it will take some time until it appears in the ppa after the dput?
[01:27] <wgrant> zsquareplusc: Up to 5 minutes.
[01:27] <wgrant> zsquareplusc: If it doesn't show up on the PPA page within 5 minutes, you probably didn't sign it properly.
[01:37] <zsquareplusc> my bad.. it's even a FAQ entry, heh
[01:37] <wgrant> What was the problem?
[01:39] <zsquareplusc> wrong upload destination
[01:40] <wgrant> Ah.
[01:42] <lifeless> spm: can you see if branch whiteboards are still preserved in the DB?
[01:42] <spm> lifeless: sure, can you give me some pointers of which table(s) to look at?
[01:43] <lifeless> thumper: ^
[01:43] <lifeless> spm: branch or branch*
[01:43] <spm> 'k, one sec
[01:45] <spm> lifeless: branch has > 2500 whiteboards that are not null, on staging.
[01:46] <lifeless> spm: can you get a dump of the whiteboards for branches of squid
[01:46] <lifeless> (join to product where product.name like "%squid%")
[01:46] <spm> lifeless: sure. gimme a few to work some magic.
[01:50] <SamB> what happened to the whiteboards anyway?
[01:51] <SamB> how are vcs-imports problems supposed to be discussed without them?
[01:52] <lifeless> SamB: answers.launchpad.net/launchpad-code
[01:52] <SamB> lifeless: I mean, like, a specific import fails
[01:52] <jml> SamB: code-imports still have whiteboards
[01:52] <SamB> oh
[01:52] <spm> lifeless: https://pastebin.canonical.com/18298/ - you may wish to verify my sql-fu
[01:52] <lifeless> SamB: so I do - if an import fails, you can alert jml & co via answers
[01:53] <jml> answers is definitely the best place to ask questions.
[01:55] <lifeless> spm: looked fine to me
[01:55] <lifeless> thanks
[01:55] <lifeless> I've copied the result part of it to them
[01:58] <SamB> lifeless: isn't it usually the vcs-imports people that alert the users?
[01:59] <SamB> I mean, if the FIRST import fails
[02:02] <thumper> SamB: whiteboards are deprecated throughout launchpad
[02:25] <zsquareplusc> yes! the package works :-)
[02:25] <zsquareplusc> wgrant and james_w: thanks for your help
[02:28] <nhandler> Would an LP admin be able to subscribe me to all packages currently maintained by a certain team if I were to file a question on answers.launchpad.net? Or would I need to manually subscribe to all of them?
[02:31] <jml> nhandler: I don't know.
[02:31] <jml> nhandler: maybe they could. also, maybe you could do it yourself with th LP APIs.
[02:31] <jml> lots of maybes :(
[02:31] <wgrant> The LP API doesn't let you do that/
[02:32] <jml> fail.
[02:33] <wgrant> Rather.
[02:33] <wgrant> Maybe you can convince a Bugs person to expose it.
[02:33] <wgrant> Hmm, but you also can't list a Person's maintained packages.
[02:35] <spm> isn't that a structural subscription? - tho I'm not aware of those being hooked to teams...
[02:35] <wgrant> It is a structural subscription, yes.
[02:36] <spm> heh. usually it's people wanting *out* of one of those. not in. :-D
[02:36] <wgrant> Yep.
[02:40] <spm> nhandler: I gather it's not possible for you to simply join said team?
[02:40] <wgrant> The problem is that lots of subscriptions need to be added.
[02:40] <wgrant> Subscriptions of the team to the packages.
[02:40] <wgrant> There's no way to do that other than manually through the UI.
[02:40] <wgrant> Or SQL.
[02:42] <nhandler> spm: It isn't a real team. It is an account that was created when some packages from Debian were synced: https://edge.launchpad.net/~pkg-perl-maintainers
[02:43] <nhandler> The team maintains over 1000 packages, which is why I was looking for an easier way than me manually subscribing to all of the packages
[02:43] <wgrant> (Maintainers aren't automagically subscribed, I might note)
[02:43] <nhandler> wgrant: I know
[02:43] <wgrant> nhandler: I know you know.
[02:43] <wgrant> I wasn't sure that spm did.
[02:43] <nhandler> ;)
[02:43] <spm> nope, didn't know :-)
[02:44] <spm> ah. perl. yes. that would account for the large number of packages. aka line-noise.
[02:47] <wgrant> You could probably write a script to make a thousand POST requests on your behalf, taking the list of packages from a Debian Sources file (can't use Ubuntu's - the maintainer is overridden).
[02:48] <nhandler> wgrant: I guess I could do that. I just wanted to see if the LP admins had an easy way to do this before I wrote up a script of my won
[02:48] <nhandler> s/won/own/
[02:49] <spm> nhandler: not that I'm aware of - we have to do pretty much the same thing. if only via sql. :-/
[02:49] <wgrant> And the query would be a bit more complicated than the trivial one to remove a subscription...
[02:49] <spm> to a certain extent, going via an automated UI POST would be safer. albeit more clumsy.
[02:49] <spm> exactly.
[02:50] <nhandler> Ok. I guess I'll write up a Perl script to do this ;)
[02:50] <nhandler> Thanks for your help spm and wgrant
[02:51] <wgrant> nhandler: But you'll also file a bug to get the subscription methods exposed.
[02:51] <spm> ha! np.
[02:51] <zsquareplusc> mm when i have a deb package is there a dpkg command to list it's dependencies/suggests w/o installing it?
[02:51] <nhandler> wgrant: Yes I will. Would that be against the API or LP itself?
[02:52] <wgrant> nhandler: launchpad-registry or malone... Since I'm not sure, file against launchpad.
[02:53] <nhandler> wgrant: Sure thing
[02:53] <wgrant> zsquareplusc: 'dpkg -f /path/to/deb Depends'
[02:53] <wgrant> That'll get the Depends field.
[02:55] <zsquareplusc> thanks
[02:56] <zsquareplusc> i've created the PPA for the team i created for the project. is there something i can do that the PPA is listed on the projects homepage?
[04:20] <persia> nhandler, If you haven't run your script yet, for the avoidance of duplication, you might just want to activate the maintenance team for the existing person in LP registered with the team maintainer address, set a contact address to something special (e.g. a LP ML), and subscribe the team.  That way others who want to subscribe to the same bug set don't need to run the script themselves.
[04:24] <nhandler> persia: Good idea, I'll give that a try
[04:25] <persia> nhandler, Note that this will be a few questions in LP: one to try to turn the "maintainer" into a proper team, and probably another to gain "control" without sending the auth details to a public mailing list.
[04:25] <persia> (and maybe more along the way)
[06:41] <bialix> hi, can you suggest me the way to force lp send mail about merge requests made in lp code to our mailing list (qbzr project)?
[06:42] <bialix> can I avoid of creating dummy user with required e-mail?
[06:47] <persia> bialix, You could create a team instead of a user, and give the team contact address as the mailing list.
[06:47] <persia> (and subscribe the team to the branch, etc.)
[06:48] <bialix> we have a team ~qbzr-dev
[06:48] <persia> Does the team have a contact address?
[06:49] <bialix> no, it seems not yet
[06:49] <persia> That's probably the way to do it then (although I don't know the UI very well).
[06:50] <wgrant> But having a contact address may be undesirable, depending on what the team is used for.
[06:50]  * persia defers to wgrant who understands this much better
[06:51] <bialix> wgrant: can you explain?
[06:51] <wgrant> So, this all worked pretty nicely before Launchpad grew far too many new features, resulting in everything being pretty inflexible and somewhat inconvenient.
[06:52] <wgrant> bialix: What do you use ~qbzr-dev for?
[06:52] <bialix> we are working on QBzr project
[06:53] <bialix> members of the team has write privileges to push new revision to trunk
[06:53] <bialix> also members of team manage bugs
[06:53] <bialix> is there is possible other usage of team on LP?
[06:53] <wgrant> OK. Is it used for email at all? Bugmail, branch revision notifications, that sort of thing?
[06:54] <bialix> I don;t understand
[06:54] <bialix> every member susbcribed individually to trunk
[06:54] <wgrant> OK, that's good.
[06:54] <bialix> bugmails going to each member too
[06:54] <wgrant> Good, good.
[06:55] <bialix> ok
[06:55] <bialix> as you said
[06:55] <wgrant> So you should be safe to add the mailing list as the email address.
[06:55] <wgrant> Then you can subscribe the team to get emails about merge proposals, and the emails will go to the mailing list.
[06:55] <bialix> and what about bugmails?
[06:56] <persia> Do you want bugmail to go to the list, or to individuals?
[06:56] <bialix> only to individuals
[06:56] <wgrant> Are the individuals subscribed to bugmail, or is the team?
[06:56] <bialix> I found it's too boring
[06:56] <bialix> how can I check this?
[06:57] <persia> http://bugs.launchpad.net/qbzr ought show it
[06:57]  * persia gets confused
[06:57] <wgrant> https://bugs.launchpad.net/qbzr/+subscribe, in particular.
[06:57] <wgrant> As you can see in the porlet, *nobody* seems to get all bugmail for qbzr.
[06:58] <bialix> but we do get it
[06:59] <persia> For everything, or for individual bugs?
[06:59] <bialix> is not it's a settings of the team itself?
[06:59] <persia> To put it another way, do you get bugmail for every new bug?
[06:59] <wgrant> Hm.
[06:59] <bialix> all new bugs come to me personally at least
[06:59] <wgrant> You are right.
[06:59] <wgrant> The team has an implicit subscription to the bugs, but it's not on +subscribe.
[07:00] <bialix> I guess so
[07:00] <persia> implicit subscriptions ought be shown.
[07:00] <wgrant> Maybe because they're configured as the maintainer.
[07:00] <bialix> this driver/maintainer split is very confusing
[07:00] <wgrant> So, if you set the contact address, something will change: bugmail will go to the mailing list instead of each individual user.
[07:00] <wgrant> It is.
[07:01] <bialix> no, this is bad
[07:01] <wgrant> You should probably replace 'driver' with 'release manager' when you think about it.
[07:01] <bialix> hm?
[07:01] <wgrant> Exactly - this is why I said LP had become inflexible and inconvenient since all these new features appeared.
[07:01] <bialix> this more understandable
[07:02] <wgrant> In Launchpad, 'driver' basically means 'release manager'.
[07:02]  * bialix sigh
[07:02] <persia> wgrant, I don't think the issue is the new features, so much as that some bits lag behind other bits.
[07:02] <wgrant> persia: It worked well when basically the only type of email sent from Launchpad was bugmail.
[07:03] <wgrant> But now we have all manner of other stuff.
[07:03] <wgrant> And it's unconfigurable.
[07:03] <wgrant> Unless you go with the proliferation of teams idea.
[07:03] <persia> I don't remember when LP didn't also send blueprint mail.
[07:03] <wgrant> True, but nobody has seriously used Blueprint properly in years.
[07:03] <persia> proliferation of teams never helped me much: I just end up on more teams that I don't clearly understand.
[07:04] <persia> I tried to use blueprint properly about 7-8 months ago :)
[07:04] <wgrant> Was it a success?
[07:04] <bialix> blueprints give too much karma
[07:04] <bialix> I'm using it
[07:04] <persia> Well, except for the several days wading through the volume due to lack of searching, yes, actually.
[07:04] <bialix> but they is not very cool
[07:04] <wgrant> bialix: That's because almost nobody uses it, because it's pretty out of date and broken.
[07:04] <wgrant> bialix: So the karma is worth more.
[07:05] <persia> The main issue was not being able to process abandoned blueprints well.
[07:05] <bialix> wgrant: it's bad blueprints is dead and broken
[07:05] <wgrant> bialix: I hear there may be work on that soon.
[07:05] <bialix> but
[07:05] <wgrant> But it has been abandoned by the Launchpad team for a long time.
[07:05] <bialix> it require link to spec
[07:06] <bialix> and lp does not provide wiki to save the spec
[07:06] <bialix> it's inconvenient
[07:06] <bialix> why there is no wiki?
[07:06] <bialix> this is most annoying part of blueprints brokeness
[07:07] <persia> bialix, because there's conceivably something better than a wki that could be done, but would be hard to do if there was a wiki, and so it needs to get specified first (or at least that was the way I heard it last)
[07:07] <bialix> and there si not possible toget bird view of all dependecies between topics
[07:07] <wgrant> I think the roadmap page did that - but that was removed some time ago.
[07:08] <bialix> persia: I found Trac idea of wiki for everyting is a breeze
[07:08] <bialix> yes, roadmap page disappear
[07:08] <bialix> into blue?
[07:08] <bialix> blue yonder
[07:08] <bialix> right?
[07:09] <bialix> blueprints UI is tooooooooooooo complex
[07:09] <bialix> all this dance with direction approved, split over 2 settings page
[07:10] <bialix> so yes, it's seriously broken
[07:10] <bialix> and it gives too much karma
[07:10] <wgrant> Once it's less broken, it will give less karma.
[07:11] <persia> Because more people will use it.
[07:11] <wgrant> Right.
[07:11] <bialix> anybody who is not the part of the team could file a blueprint and get more karma than main devs
[07:11] <bialix> it's not right
[07:11] <persia> But yeah, the whole approval mess is a bit tricky.
[07:13] <bialix> which parts of LP (in the term code/bugs/blueprints/translations/answers) will be open sourced?
[07:13] <wgrant> bialix: Everything except the backend bits of Code and Soyuz.
[07:13] <bialix> and what is LAZR means?
[07:14] <bialix> backend bits -- it's ACL for codehosting?
[07:14] <wgrant> https://launchpad.net/lazr - it's the set of some of the Python libraries that Canonical has produced.
[07:14] <al-maisan> Linux/Apache/Zope/Relational database ?
[07:14] <bialix> no, LAZR is acronym?
[07:14] <bialix> ah
[07:14] <bialix> thank you
[07:15] <bialix> ACLs for bzr is so complex to setup. There is no bzr equivalents to bitbucket or github
[07:15] <wgrant> bialix: Um, Launchpad?
[07:15] <wgrant> Codehosting is the stuff you push your branches to.
[07:16] <wgrant> And probably the vcs-imports stuff as well, but I couldn't be sure.
[07:16] <bialix> on LP I can't create private branches for reasonable small fee
[07:16] <bialix> I need paid codehosting for small price
[07:16] <persia> bialix, You've asked a question and discovered the pricing?
[07:16] <bialix> bitbucket and github have it
[07:17] <bialix> $250/year  + VAT
[07:17] <bialix> this is info from one of LP answers
[07:17]  * persia didn't really want to know the number, just wanted to make sure the question was asked.
[07:17] <bialix> I don't asked
[07:17] <wgrant> That's for a proprietary project with private bugs.
[07:17] <wgrant> Private branches could be different.
[07:17] <bialix> but from all info available it's even not clear I (individual) can have private branches
[07:17] <wgrant> You could ask.
[07:18] <bialix> there is info about commercial support
[07:18] <bialix> I've asked poolie directly and he pointed me to answer about commercial support
[07:19] <wgrant> The github model is nice, I agree - I, as a user, can pay a few dollars a month for some number of private branches.
[07:19] <bialix> exactly
[07:19] <wgrant> I suspect LP could get quite a few people on that model...
[07:19] <persia> Even just from folk who were branching other projects and didn't want to publish yet.
[07:19] <bialix> maybe because entire LP is oriented on open source only
[07:20] <wgrant> persia: Exactly.
[07:20] <bialix> while github oriented on profit
[07:20] <wgrant> bialix: LP is for commercial projects too.
[07:20] <bialix> IIUC only for BIG commercial projects
[07:22]  * bialix wishes to run startup as github but for bzr
[07:23] <wgrant> That's probably why they are keeping codehosting proprietary.
[07:25]  * bialix nods
[07:26] <jml> uhh actually, we offer private branches for a fee.
[07:26] <jml> we're just lousy at communicating that.
[07:27] <wgrant> jml: Nothing obviously affordable like the other services, though.
[07:27] <bialix> even google can't find this answer
[07:27] <wgrant> In fact, nothing obvious at all.
[07:27] <jml> see previous comment :)
[07:27] <persia> jml, It might be worth having pricing in a FAQ somewhere, rather than in a series of questions.  Would improve discoverabilit.
[07:28] <jml> probably.
[07:29] <wgrant> Plus I can't create a private branch outside a private project.
[07:29] <bialix> just to compare with github/bitbucket: one can open price page from main page
[07:31]  * bialix has to run
[07:35] <wgrant> jml: So, I can't find documentation about private branch pricings anywhere at all.
[07:35] <wgrant> And if it's not documented, it doesn't exist.
[07:36] <jml> if you say so.,
[07:36] <persia> Is there documentation on private project pricing?  I thought folk were always encouraged to ask questions.
[07:36] <persia> Asking a question about private branches might generate some documentation (if only in the question log)
[07:39] <persia> So, I haven't gotten any bugmail in 7 hours, which is becoming suspicious (especially because I performed bug actions that usually send me mail in that time).  Is it just me?
[07:39] <wgrant> persia: I got some just a couple of hours ago.
[07:40] <wgrant> But there has been significant lag at times lately.
[07:40] <wgrant> Actually, I just got some bugmail 30 seconds ago.
[07:40] <persia> Hrm.  Then it's probably just me.
[07:40] <wgrant> No more than a couple of minutes later than I would expect.
[07:40] <wgrant> And while there are two types of bugmail, the kind I just got is the kind that you would be expecting.
[07:41] <jml> there was a major delay the other day too.
[07:41] <wgrant> Yeah.
[07:41] <wgrant> I got some stuff around 10 hours late...
[07:41] <persia> I actually expect to get both types at a rate of several an hour throughout the day.
[07:43] <spm> persia: can you number a couple of bugs? I'll have a look and check you should have been sent copies.
[07:46] <persia> spm, bug #28835 is the one I mostly noticed.
[07:48] <persia> I kinda expected something from 379592 as well, but I'm not as sure.
[07:49] <spm> persia: ok. two blasts: 2009-06-11 23:40:3[23] & 2009-06-12 03:17:38 - still looking for you in that lot
[07:49] <spm> yup you shoulda got both. persia@u.c
[07:50] <spm> persia: check your spam trap maybe? I know I had a couple of work related emails in tehre recently.
[07:50] <persia> hrm.  Odd.  I'm getting other mail there.
[07:56] <JNRowe> Hi guys, I suspect this has an obvious answer but...  how do I download a snapshot of a project from launchpad, I can't seem to find any such option on the site or in the help.
[07:57] <jmarsden> JNRowe: bzr get lp:~someuser/someproject/somebranch    # is this what you mean ?
[07:58] <JNRowe> no, I wasn't clear.  I meant a tarball or a zip or something as I don't have bzr
[07:58] <jmarsden> Unless the project has published one (few do), there is no way to cause one to be created just for you, as far as I know.
[07:59] <jmarsden> Installing bzr is pretty simple :)
[07:59] <JNRowe> oh right, I just assumed there probably was one I couldn't find as there is with most other code hosting sites
[07:59] <JNRowe> thanks anyway
[08:00] <jmarsden> No problem.  You may be able to download source packages if the project also has a PPA (Personal Package Archive) associated with it
[08:01] <wgrant> There's a feature request somewhere for Loggerhead (the Launchpad code browser) to provide tarballs.
[08:02] <persia> jmarsden, projects can have PPAs now?
[08:03] <jmarsden> Hmmm... teams can... I don't think I've tried it with a project, so maybe not... but the project *team* can have one :)
[08:03] <wgrant> There's meant to be project<->archive links appearing in the next couple of months.
[08:07] <thekorn> hi, I've got a few questions about bug 131679
[08:07] <thekorn> is it just me or is the subscriber portlet missing on this one
[08:08] <wgrant> thekorn: It's there.
[08:08] <wgrant> Just below the duplicates.
[08:08] <wgrant> Why below, I have no idea.
[08:08] <wgrant> Hmm.
[08:08] <wgrant> Ahhh.
[08:09] <wgrant> The portlet is there, but the AJAX bit fails to load.
[08:09] <wgrant> Probably because of a timeout.
[08:09] <wgrant> Oh, no, just a good old OOPS.
[08:09] <thekorn> wgrant, yes, it is there, but content is missing
[08:09] <wgrant> OOPS-1259EB210
[08:10] <wgrant> OK, it is a timeout after all.
[08:10] <wgrant> Probably takes too long to calculate the subscribers of the huge number of dupes.
[08:10] <wgrant> (which is part of the reason it's loaded by AJAX)
[08:10] <thekorn> my other question is about bugmails: should notifications for a bug which happen in a small timeframe be bundled into one bugmail?
[08:10] <persia> I think they should.
[08:11] <wgrant> Changes by one user within a few minutes should be batched, yes.
[08:11] <wgrant> But comments by any user, or intermediate changes by other users, can disrupt that.
[08:12] <thekorn> ah, ok, so it has to be changes by one user, and within a few minutes
[08:14] <thekorn> problem: this bug got ~190 new dublicates within the last few hours, all marked by the same user,
[08:14] <persia> That's arguably changes to 190 *different* bugs.
[08:14] <thekorn> and I got bugmail for each of this actions,
[08:14] <wgrant> Right, they're different bugs.
[08:14] <thekorn> yes, but at the end this are 190 changes to this bug
[08:15] <wgrant> Which bug was the notification sent from?
[08:15] <thekorn> all come from bug 320545
[08:16] <wgrant> I mean, which is in the sub
[08:16] <wgrant> Er, subject field.
[08:17] <thekorn> ok, right, subject is always different
[08:18] <wgrant> Right, the notifications are from different bugs.
[08:18] <wgrant> You just happen to get notifications from them because they are duplicates of a bug to which you are subscribed, I suspect.
[08:18] <wgrant> Batching notifications from different bugs sounds like a bad idea.
[08:18] <thekorn> so, this leads me to another question, why do I get bugmails for bugs which have been marked as duplicate of the bug I'm subscribed to?
[08:19] <wgrant> That changed a couple of years ago, IIRC.
[08:19] <wgrant> But you'd have to ask a Bugs dev.
[08:20] <thekorn> I mean: a would expect tons of bugmails like "bug XXXX marked as dup of 123456, you get this mail, because you are subscribed to 123456"
[08:21] <wgrant> thekorn: Isn't that what those emails are?
[08:22] <thekorn> wgrant, well yes, but I got bugmail from bug xxxxx, but I would expect to get lots of bugmails from bug 123456, which I'm subscribed to
[08:24] <wgrant> Hmm...
[08:24] <wgrant> Sounds like you need to argue with a Bugs person.
[08:24] <thekorn> right,
[08:25] <thekorn> anyway, thanks wgrant for listening to me ;)
[08:26] <wgrant> thekorn: np
[08:26] <thekorn> maybe I should just file a bug, and see what happens
[08:27] <wgrant> That might work.
[08:28] <robert_ancell> is there anyway to stop a mail flood from marking duplicates?  I've been doing some serious triaging in compiz and it appears to be notifying everyone of the duplicates that have been reported.  Some unhappy people out there...
[08:28] <wgrant> robert_ancell: Heh, thekorn was just going to file a bug about that.
[08:29] <robert_ancell> wgrant: I suspend my canonical email is going to be subscribed to every spam list for this...
[08:29] <thekorn> robert_ancell, hehe, good job ;) did you use a script, or did you mark all of them by hand?
[08:30] <robert_ancell> Used lp-set-dup from ubuntu-dev-tools
[08:30] <robert_ancell> I merged three bugs which had about 100 duplicates each
[08:33] <thekorn> robert_ancell, does this script have an argument to add a comment to describe your action?
[08:33] <persia> I generally don't prefer to receive comments from scripts like that, personally.
[08:34] <robert_ancell> thekorn: no option
[08:34] <thekorn> IMO, if somebody is running such kind of scripts, it should be explained
[08:35] <robert_ancell> thekorn: but why notify people? does anyone actually want to know if a bug they're watching gets another duplicate?  especially past the fifth duplicate?
[08:35] <thekorn> persia, you know what's going on, but new user don't
[08:35] <persia> Well, actually, yes.  Sometimes there's useful discussion in the dupes.
[08:36] <thekorn> I mean, let's say I'm mr. random user, and a filed a bug in the past about my compiz not running correctly,
[08:36] <thekorn> I did not hear anything about it for over a few month
[08:36] <persia> thekorn, Hrm.  Perhaps just to leave a comment in the master bug explaining it once?  My issue is with the mass-bug-comments where I get the same message on 100 bugs all at once.
[08:37] <thekorn> and then, I get tons of confusing mails
[08:37] <thekorn> *this* is confusing
[08:38] <persia> Right, but what if you got one mail with the explanation, and then the 100 dup messages?  Would that work for you?
[08:38] <persia> (and I think this has become an #ubuntu-bugs discussion)
[08:38] <robert_ancell> My experience with bugzilla is I always thought duplicate notification should be opt-in
[08:38] <persia> robert_ancell, Very little notification is opt-in for launchpad.  It's designed to encourage communication.
[08:39] <thekorn> persia, the problem here is, that a user which has been subscribed to the bug after this comment has been added will never see this comment in his/her mails
[08:39] <robert_ancell> persia: yes, but my argument here is duplicate notification is not good communication - it is noise for most users
[08:39] <persia> ah, so a user who got subscribed by being previously subscribed to one of the first dupes?
[08:40] <thekorn> persia, yes
[08:40] <persia> Hrm.  It's always bad for someone.
[08:40] <thekorn> that's so true
[08:41] <thekorn> but in my opinion it is worse if it's bad for mister random user,
[08:42] <persia> robert_ancell, In many cases it turns out there is a workaround or hint sitting in a duplicate, especially for the packages that attract fewer bugs.  I'm not certain that a single duplicate message isn't useful for most people.  It's 100 messages that's rarely useful.
[08:43] <robert_ancell> persia: I think in that case there needs to be a threshold, e.g. notify the first 5 duplicates for everyone and then only the remaining for users who have opted in (e.g. developers)
[08:44] <persia> thekorn, But it's *always* bad for mister random user, either the first person in the queue gets tons of duplicate comments, or the last person in the queue doesn't know what happened.
[08:44] <wgrant> The solution is to stop so many dupes being filed.
[08:44] <persia> robert_ancell, I doubt even developers want to see the next 185.
[08:44] <wgrant> There is no excuse for having hundreds of duplicates.
[08:44]  * persia agrees with wgrant
[08:45] <robert_ancell> persia: It doesn't bother me because I can filter them and I want to know how many duplicates there are
[08:46] <robert_ancell> wgrant: a lot of these are pre-apport
[08:46] <wgrant> robert_ancell: So it's probably not a problem that needs solving.
[08:47] <persia> robert_ancell, The number is easily available from LP at any time, and the bugmail never gives you the correct number unless you were a bug contact for the package before the first was filed.
[08:48] <robert_ancell> wgrant: These cases will occur in the future and reporters will get angry again...  I wish they could be batched somehow (e.g. the following 1000 bugs have been marked as a duplicate of bug xxx which you follow)
[08:48] <robert_ancell> persia: but if you are following that bug you get an idea of what is going on
[08:49] <persia> Well, yes.  Wasn't I arguing for duplicate notifications to be sent by default earlier :)
[08:49] <persia> My point is only that it's not useful in terms of determining the count.
[08:50] <robert_ancell> persia: agreed
[08:51] <robert_ancell> wgrant: every duplicate of bug 13169 will send out 300 email right? That is going to annoy people as there will almost certainly be a duplicate every so often. And as we get closed to Karmic the frequency will increase
[08:53] <wgrant> robert_ancell: Probably.
[08:54] <wgrant> The solution to this might be the me-too feature.
[08:54] <wgrant> Most of those users probably don't actually want to be subscribed.
[08:54] <wgrant> They just want to know when it's fixed.
[08:55] <persia> Well, that gets into the unable-to-unsubscribe-from-implicit-subscriptions issue, as many of the subscribers are subscribed as the originator of the bug (or a dup)
[08:55] <persia> But the solution is for LP to be even smarter about helping people find their bug, rather than filing a new one.
[08:57] <robert_ancell> gtg, here's to not having an angry crowd outside my door tomorrow :)
[09:35] <BUGabundo> wgrant:  eheh
[09:35] <BUGabundo> u caught me on my way to #launchpad to ask what was that old bug that didnt allow users to unsub from dups
[09:36] <BUGabundo> and good morning to you all
[09:36] <wgrant> BUGabundo: Heh. Does it work if you go to +subscribe?
[09:36] <BUGabundo> nope
[09:36] <BUGabundo> at least for the master bug
[09:36] <wgrant> What does it do?
[09:36] <BUGabundo> I guess I'm subbed to one of the dupes
[09:36] <BUGabundo> wgrant: does _nothing_
[09:36] <BUGabundo> on edge
[09:36] <BUGabundo> page won't even reload... let me try to open on a new tab
[09:36] <wgrant> +subscribe will unsubscribe you from the dupes, if you are subscribed to them.
[09:37] <BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/131679/+subscribe
[09:37] <BUGabundo> that works!
[09:37] <BUGabundo>          Unsubscribe from                  bug #131679                    Unsubscribing yourself or a team from a bug also unsubscribes from     duplicates.                                 Unsubscribe me from this bug
[09:37] <BUGabundo> humm shouldn't it tell me what are the dupes I'm subbed to ??
[09:38] <BUGabundo> no idea why the AJAX thingy aint working
[09:38] <BUGabundo> but midle click to new tab works, at least I hope so
[09:38] <BUGabundo> clicking now
[09:38] <BUGabundo> You have been unsubscribed from this bug and 1 duplicate (#191365).
[09:39] <wgrant> Ohhhh.
[09:39] <wgrant> Right.
[09:39] <wgrant> I see.
[09:39] <wgrant> It's because the list of subscribers times out.
[09:39] <wgrant> So the button gets partly AJAX-ified.
[09:39] <wgrant> Related to bug #386236 - I'll mutate that to cover this issue too.
[09:39] <BUGabundo> ehehehehe
[09:39] <BUGabundo> it would help if it was done NOW
[09:40] <wgrant> This could be pretty important to get fixed on prod, actually... there are going to be hundreds of irate users finding the unsubscribe link.
[09:40] <BUGabundo> lots of ppl will scream FAULLLL
[09:40] <BUGabundo> if they can't unsub from this massive bug
[09:40] <wgrant> Yep.
[09:40] <BUGabundo> wgrant: one more thing! AFAICT https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/131679/comments/37
[09:41] <BUGabundo> Robbert *just* dupped two bugs to the master one
[09:41] <BUGabundo> brigging with those 169 and 19 dupes
[09:41] <BUGabundo> if so, _why_ did it generated soooo much bug mail ?
[09:41] <BUGabundo> I got >160 emails!
[09:42] <BUGabundo> there is a bad workflow here somewhere
[09:42] <wgrant> BUGabundo: In LP, dupes can't nest.
[09:42] <BUGabundo> I know!
[09:42] <wgrant> So, he actually set some awfully large number of bugs that were dupes of the other two as dupes of the main one.
[09:42] <BUGabundo> we already had that discussion once
[09:42] <wgrant> Then set the two other master bugs as dupes of the main one.
[09:43] <wgrant> Creately approximately an awful lot of email.
[09:43] <BUGabundo> with the new AJAX controls *if* I dupe a bug with dupes to another, don't all the _nested_ dupes dupe the master?
[09:43] <wgrant> No - you can't do that.
[09:43]  * BUGabundo tries to re-read that and make sense 
[09:43] <wgrant> You used to be able to, but that was a bug.
[09:44] <wgrant> A bug that was fixed fairly quicklyy.
[09:44] <BUGabundo> humm really?
[09:44] <wgrant> Because it created really confusing situations.
[09:44] <BUGabundo> I remember doing that just weeks ago
[09:44] <wgrant> And allowed dupe loops, which caused a timeout.
[09:44] <BUGabundo> longer after that _fix_ came in
[09:44] <wgrant> Right - the problem appeared when duping was AJAXified.
[09:44] <BUGabundo> yes, that was the main bug... but recently it worked as I expected it too
[09:45] <BUGabundo> I marked a bug as dupe, and dupes automagicly changed too
[09:45] <BUGabundo> which is what in this case Robbert should have been able to do.... or else I may be need an Hand transplant by now
[09:47] <wgrant> He used a tool from ubuntu-dev-tools to do it.
[09:47] <wgrant> And no, LP will not automatically move dupes across; I just checked on staging.
[09:47] <BUGabundo> ok
[09:48] <BUGabundo> stupid Q: shouldnt it ?
[09:48] <BUGabundo> (assuming it avoids loops)
[09:49] <wgrant> Perhaps. would make it very easy to generate lots of bugmail.
[09:50] <BUGabundo> that the idea: it shouldn't!
[09:50] <BUGabundo> let me think of the Rational
[09:51] <BUGabundo> im subed to bug y. z is dupe of y. y p t o are marked dups of x. now y t p o z are now dupes of x.
[09:52] <BUGabundo> every one (not on X) should only get ONE email of a massive dupping to X
[09:52] <BUGabundo> ppl on X only get one email too, *after* all dupes came through!
[09:53] <BUGabundo> the prob currently is that any bug like X gets also a mail that any pre-dupes bugs, will be marked as dupes of it
[09:53] <BUGabundo> humm Feature or Bug ?
[09:54] <BUGabundo> err
[09:54] <BUGabundo> I'll file a wish bug on that, and try to make up a blueprint too
[09:54]  * BUGabundo runs $ ubuntu-bug launchpad because he's sleepy
[09:58] <BUGabundo> would that be malone ?
[09:58] <wgrant> It would.
[10:02] <BUGabundo> https://bugs.edge.launchpad.net/malone/+bug/2796
[10:02] <BUGabundo> here is a 2005 nested bug LOL
[10:02] <BUGabundo> we've spend 4 years fighting this
[10:02] <BUGabundo> something is wrong with that
[10:03] <BUGabundo> https://bugs.edge.launchpad.net/malone/+bug/65741
[10:03] <BUGabundo> this description is similar to my idea
[10:03] <wgrant> That second one is hardly relevant.
[10:04] <wgrant> Bug #78596 is the one.
[10:05] <wgrant> But Bugs people should be around soon, so it's probably best to talk to them.
[10:05] <BUGabundo> thanks
[10:05] <BUGabundo> let me read that one
[10:05] <BUGabundo> wgrant: btw those 2 bugs I posted are diff stuff
[10:06] <BUGabundo> one is nested other is dupe bugmail
[10:13] <BUGabundo> https://bugs.edge.launchpad.net/malone/+bug/386261
[10:15] <\sh> guys, is there any timeframe to fix bug #385619? (launchpadlib)
[10:20] <BUGabundo> wgrant: one more Q: since when is the user marked as Me Too for every filed bug?
[10:21] <wgrant> BUGabundo: Launchpad 2.2.4 - bug #285167
[10:22] <BUGabundo> eehh
[10:22] <BUGabundo> its one of those: I want. I don't!
[10:23] <BUGabundo> some cases it makes sense. but not always. I file  many bugs for other users lolol
[10:23] <BUGabundo> but then again, that's ME
[10:23] <BUGabundo> not most users... I'll agree on that
[10:25] <persia> BUGabundo, When you file bugs for other people, aren't they usually bugs that you can verify, so you can say they affect you?
[10:25] <BUGabundo> persia: not on my hw. no
[10:26] <persia> hrm.
[10:26] <wgrant> persia: Is that the purpose of that flag, though?
[10:26] <BUGabundo> but usually I'm close to the user, and can confirm on there case
[10:26] <BUGabundo> I guess on those cases, I'll un-Me Too
[10:26] <BUGabundo> should be <5%
[10:26] <persia> wgrant, I thought the purpose of the flag was to reduce the number of "me too" comments, although I'm not sure it's succeeded.
[10:26] <savvas> is rosetta/translations part of launchpadlib? is it possible to get the percentage of translated strings?
[10:27] <wgrant> savvas: Not at the moment.
[10:27] <wgrant> persia: Well, it's currently unobvious that the feature exists.
[10:27] <wgrant> persia: Should I really me-too a bug if I can reproduce it, rather than only if it actually affects me?
[10:27] <savvas> wgrant: have you noticed a bug-wishlist or a blueprint for it?
[10:27] <persia> wgrant, I think there's a bug about that.
[10:28] <BUGabundo> lolol
[10:28] <BUGabundo> I Me Too if I'm affected, not can reproduce
[10:28] <wgrant> savvas: https://answers.edge.launchpad.net/rosetta/+question/67671
[10:29] <savvas>  thanks :)
[10:36] <BUGabundo> persia: please explain what you said on the bug
[10:36] <BUGabundo> its not clear to me
[10:37] <BUGabundo> " there is no means by which the system can know if someone is going to  process another duplicate in the future."
[10:37] <BUGabundo> in this case, according to wgrant, Robbert used a set of ubuntu-dev tools
[10:37] <BUGabundo> so I'm guessing it was a single batch
[10:38] <wgrant> It was many requests.
[10:39] <BUGabundo> ahhhhh
[10:39] <persia> BUGabundo, Right, but LP can't know if the batch is complete at the time a given action is taken, because LP isn't responsible for doing the batch processing.
[10:39] <BUGabundo> that makes it more clear
[10:39] <BUGabundo> let me put that on the bug
[10:40] <BUGabundo> persia: then I would agree
[10:40] <BUGabundo> using dev tools or some other future UI on LP should have a 30 min timeout
[10:40] <BUGabundo> *before* emailing about dupes
[10:40] <wgrant> Arbitrary timeouts like that are pure evil.
[10:41] <BUGabundo> since that isn't even a critical change to any bug. at least not as important as request for input
[10:41] <wgrant> Although LP already does it a bit for batching emails from one bug.
[10:41] <persia> Oh, actually, I just thought that should be part of regular LP processing.  I can't imagine a case where it's important to get dup mail faster, and it covers release day stuff too, where tens of people are simultaneously filing the same bug.
[10:42] <persia> wgrant, Well, yes, but it's better than nothing until a real fix is avaiilable.
[10:42] <wgrant> persia: Is there a real fix?
[10:43] <persia> wgrant, You mean a known fix or a theoretically possible fix?
[10:43] <BUGabundo> wgrant: IA ? :)
[10:43] <savvas> does anyone have any suggestions/workarounds to fix bug 384217?
[10:43] <BUGabundo> well there's 'a' fix!
[10:44] <wgrant> persia: A practically possible fix.
[10:44] <BUGabundo> wgrant: persia: have a tool box allowing the operator to end changes, sending the mail in 1 Minute
[10:44] <persia> BUGabundo, nobody ever uses those properly.
[10:45] <persia> wgrant, Hrm.  Actually, I can't think of one.
[10:45] <BUGabundo> just like the Commit on SQL
[10:45] <BUGabundo> persia: if no user input, go to automode, after 30 min
[10:45] <wgrant> Anyway - dinner time.
[10:46] <BUGabundo> persia: if changing status didn't work, we would not have New/Incomplete states!
[10:46] <BUGabundo> wgrant: enjoy
[10:46] <BUGabundo> persia: users and devs seem to set the proper state some/most of the times
[10:47] <BUGabundo> so why wouldn't an experienced bug triagger using a set of advanced tools / LP UI use yet another option to end a cycle of batching dupes?
[10:47] <persia> BUGabundo, Well, with a "if the user doesn't do anything" default, it's not as broken, but that gets back to wgrant's point about arbitrary timeouts being pure evil.
[10:47] <BUGabundo> is it any worse then getting 200 emails ?!?
[10:48] <BUGabundo> _that's_ pure evil
[10:48] <BUGabundo> on user, on servers, on network, on spam, etc
[10:48] <persia> I suggested the arbitrary timeout.  I'm the wrong person to argue against it :)
[10:54] <BUGabundo> ahaha
[11:02] <wgrant> You know what we need? Some Bugs developers who actually have experience in this area and know how things work.
[11:08] <BUGabundo> wgrant: ROFL
[11:30] <Laney> is there a bug about this? (the spam floods)
[11:30] <Laney> (from dupes)
[11:31] <wgrant> Laney: Bug #386261
[11:31] <BUGabundo> Laney: I filed one
[11:32] <Laney> thanks, just wanted to subscribe to it
[11:34] <BUGabundo> Laney: no so sure it will get any acction :(
[11:36] <Laney> wouldn't just allowing transitive dupes have avoided this problem?
[11:37] <jmehdi> Hi, I'm trying to copy packages in my ppa, from jaunty to karmic series, but I get this error: "The following source cannot be copied: hijra 0.1.18-1~ppa5 in jaunty (same version already has published binaries in the destination archive)", I don't understand...
[11:37] <bigjools> jmehdi: you need to copy with binaries
[11:38] <BUGabundo> Laney: eheh don't even go there!
[11:38] <noodles> bigjools: so why the "same version already has..."?
[11:38] <jmehdi> bigjools: I can't rebuild? why?
[11:38] <Laney> BUGabundo: why not? has this been discussed before?
[11:38] <noodles> ah, in the same PPA... I see.
[11:39] <bigjools> jmehdi: no, because you would rebuild a different md5sum of the same version binary and the pool-based repo can't handle that
[11:39] <bigjools> jmehdi: if you want to rebuild, you need to upload a higher version for karmic
[11:39] <BUGabundo> Laney: ohhh so many times
[11:39] <Laney> oh
[11:39] <Laney> well I can see a problem with undoing it, but beyond that...
[11:39] <BUGabundo> read this backlog a bit and see a few links I posted
[11:40] <jmehdi> bigjools: if I understand there is only one binary version for all series ?
[11:40] <noodles> jmehdi: for the one source in your PPA, yes.
[11:40] <jmehdi> ok
[11:40] <bigjools> jmehdi: correct, in the one PPA
[11:44]  * henninge is back
[11:45] <BUGabundo> hey sabdfl
[11:47] <BUGabundo> can we bump that bug to medium? its no Low!
[11:47]  * BUGabundo humm I scared sabdfl way
[11:47] <wgrant> Medium doesn't exist, in ~launchpad's opinion.
[11:48] <Laney> ok so
[11:48] <Laney> I think it should be solved via bug 78596
[11:48] <Laney> which wasn't rejected!
[11:48] <wgrant> Laney: It could, yes. But nobody is sure how to fix that properly.
[11:49] <wgrant> And fixing the notifications isn't a precondition for solving the moving issue.
[11:49] <BUGabundo> no its not! independent stuff
[11:50] <Ampelbein> wgrant: fwiw, medium should be completely removed from the list of supported importances. either an issue needs fixing asap or it is a minor issue that can wait. but "medium" is like "hum, I don't really know how important this is but medium looks ok". ;-)
[11:51] <wgrant> Ampelbein: That's what ~launchpad says. I disagree, I think.
[11:53] <BUGabundo> Ampelbein: it means: when all critical bugs are done, do me next
[11:56] <persia> Ampelbein, I'm a fan of highly graduated bug stati: so one can usefully sort to manage limited resources (although patches that resolve less important bugs well are always welcome)
[11:57] <jmehdi> bigjools, noodles: actually is it worth copying my packages from jaunty to karmic in my ppa?
[11:57] <bigjools> jmehdi: that's a question that only you can answer
[11:57] <bigjools> do you have any karmic users?
[11:57] <noodles> jmehdi: if you want to be able to provide the software to your ppa users who use karmic...
[11:58] <bigjools> do you want to test yourself in karmic?
[11:58] <jmehdi> yes I'm testing karmic
[11:58] <Ampelbein> BUGabundo: so? why not "high" if it's important to fix? if it's not so important, why not low?
[11:59] <jmehdi> because I'm installing an app on karmic, and I see it is fetched from "ppa.launchpad.net jaunty/main"
[11:59] <jmehdi> so is it fetched from jaunty if it is not present in karmic?
[11:59] <bigjools> jmehdi: you need to fix your sources.list entry on your karmic machine
[12:00] <jmehdi> bigjools: hmm, yes maybe it's wrong
[12:00] <BUGabundo> Ampelbein: not setting that bug to High will not kill any kittens! but sure heck will piss of many users again and again and again
[12:00] <Ampelbein> persia: yeah. From what I see at work, the "medium" issues are the most ignored. When something is important, it gets fixed soon. Not so important stuff gets fixed along the way, but medium is always a middle thing that tends to be time-consuming yet not important enough. ymmv.
[12:01] <persia> Ampelbein, Depends on how you manage your bugs, really.
[12:38] <mpt> bigjools, hi
[12:39] <bigjools> mpt: on a call right now, will catch you shortly
[12:39] <mpt> ok
[12:45] <mpt> bigjools, when you're free, what's this "token" thing? I don't see it mentioned anywhere in the interface or on help.launchpad.net
[12:53] <bigjools> mpt: the tokens are effectively your personal sources.list entry
[12:54] <mpt> bigjools, so until you find out what the token is, you can't actually access the PPA?
[12:54] <bigjools> nope
[12:54] <mpt> ok
[12:55] <bigjools> which is why I think the wording on the UI needs sprucing up
[12:55] <mpt> bigjools, after you have the token, do you actually get mailed about anything that happens with the PPA?
[12:55] <mpt> e.g. when new packages are uploaded
[12:55] <bigjools> mpt: no
[12:56] <mpt> oh
[12:56] <bigjools> but apt-get will tell you of course
[12:56] <mpt> In that case, perhaps you shouldn't be using the word "subscription"
[12:57] <bigjools> what do you think it should be?
[12:57] <mpt> Talk about being given access, access revoked, etc instead
[12:57] <mpt> so
[12:58] <mpt> When the PPA owner grants you access, why do you need to click a button to get the token? Why hasn't Launchpad generated it already?
[12:58] <bigjools> mpt: I explained this already - it's so we can see who is accessing the repo
[12:59] <bigjools> mpt: and I also said that's an implenentation detail
[12:59] <bigjools> the same UI could apply to either ways of doing it
[13:00] <mpt> Sorry, what do you mean by "either way"? What's the other way?
[13:00] <bigjools> immediate generation or lazy generation of the token
[13:00] <mpt> ah, right
[13:00] <mpt> well, tracking who clicked the button tells you something about who is interested
[13:01] <mpt> It doesn't tell you whether they actually installed any of the packages :-)
[13:01] <bigjools> true :)  but salgado's download counters will do that
[13:02] <mpt> Could you instead track whether the person visits the PPA page itself?
[13:03] <bigjools> how do you see that being useful?
[13:03] <mpt> It would mean that I don't need to click a button on a separate page
[13:04] <mpt> Instead I get an e-mail message saying "Hi, you've been granted access to Foo's Bar PPA. For instructions on how to use it, go to <https://launchpad.net/~foo/+archive/bar>."
[13:04] <mpt> I can access that page because I've been granted access
[13:04] <bigjools> that page is totally inappropriate for that situation
[13:04] <bigjools> it's a developer page
[13:04] <mpt> and when I visit that page the first time, Launchpad generates the token
[13:05] <mpt> You're targeting this at non-developers?
[13:05] <bigjools> yes
[13:05] <bigjools> it's for end users
[13:05] <mpt> huh
[13:06]  * mpt rereads the initial e-mail message
[13:07] <mpt> ok, I can see how that might work
[13:08] <mpt> but in that case, +archivesubscriptions is a bit ... sparse
[13:08] <mpt> It tells me barely anything about why I'd want to use the PPA
[13:09] <bigjools> ok, that's good to hear, we need to add more information on there
[13:10] <mpt> but I'm struggling to think of what kind of LP-generated info would be useful
[13:10] <mpt> If it's for end users, even package names wouldn't be that helpful
[13:11] <mpt> Maybe the person who grants you access to a private PPA needs to be able to provide an explanatory message about what it's for?
[13:11] <bigjools> mpt: we should probably put the PPA description on that page
[13:12] <mpt> yep
[13:12] <bigjools> feel free to file a bug :)
[13:12] <mpt> shortly
[13:13] <mpt> but I don't entirely understand the problem space yet
[13:13] <bigjools> ultimately, this is for people who want to control who can download their software
[13:13] <bigjools> whether it be commercial, or beta programmes
[13:13] <mpt> yes
[13:14] <mpt> Do all PPAs have names? Or just PPAs where the owner has more than one?
[13:16] <mpt> The message I got had a Subject of "New PPA subscription for Private PPA for <name of team>", but didn't have any other name or hint of what the PPA was for
[13:17] <bigjools> mpt: they all have names, the default is "ppa"
[13:17] <bigjools> okay
[13:18] <savvas> mpt: you can't change the name of the first PPA :)
[13:18] <savvas> only the display name
[13:19] <mpt> savvas, by "name" I do mean the human name, not the database ID
[13:19] <mpt> sorry if I was confusing
[13:19] <bigjools> mpt: the one that appears in the URL you mean?
[13:20] <mpt> bigjools, display name
[13:20] <bigjools> ah ok
[13:21] <mpt> So, all PPAs have a display name?
[13:22] <bigjools> yep
[13:23] <mpt> which is currently not mentioned in either the e-mail message or the +archivesubscriptions page
[13:23] <bigjools> mpt: well it is
[13:23] <mpt> unless I'm seeing a display name that was autogenerated from the team name
[13:23] <noodles> mpt: so "Private PPA for <name of team>" should be the configurable display name?
[13:23] <bigjools> yes
[13:23] <mpt> ah, I see
[13:23] <bigjools> people can edit that
[13:23] <mpt> ok, that's fine
[13:26] <mpt> hey, RicardoPerez, I just read your comment in bug 382074
[13:26] <savvas> hm.. who or what decides about a project to be listed as featured?
[13:26] <RicardoPerez> mpt: great! what do you think?
[13:27] <wgrant> savvas: The admins. It's manual.
[13:27] <mpt> bigjools, what do you think of this idea: Instead of tracking token generation, track whether the token is actually used to retrieve the Packages.list (or whatever it's called)
[13:28] <henninge> savvas: yes, you can point us to a project and maybe give us a reason why it should be featured.
[13:28] <mpt> bigjools, the reason I suggest that is, it would avoid the need to have a "Confirm" button
[13:28] <bigjools> mpt: yes, we'll probably use that in the download counters
[13:28] <savvas> ah ok, thanks :)
[13:28] <bigjools> but I still want the confirmation stage
[13:29] <bigjools> and now, I really have to leave for lunch
[13:29] <mpt> RicardoPerez, I'm not qualified to comment on your technical suggestion. I do know that if a FAT32-formatted external HD is more useful to more Ubuntu users than an ext3-formatted external HD, something is seriously wrong.
[13:29] <mpt> bigjools, ok, when you get back, tell me why. :-) I'm curious
[13:29] <wgrant> mpt: Yeah, I've always been a bit concerned about that. But the same happens in Windows land - FAT32 vs. NTFS.
[13:29]  * mpt should go for lunch too
[13:30] <mpt> or brunch
[13:31] <savvas> are you a newly-wed? :P
[13:31] <RicardoPerez> mpt: that's the key. my friend is an average Ubuntu user. he bough a new hard disk, he formatted it using ext3 but he needed to call me because he was unable to write into it
[13:32] <mpt> It's also messed up that to format an external HD you need to use a "partition editor" that isn't even installed by default, but that's another story.
[13:32] <wgrant> mpt: DeviceKit-disks has a nice frontend for that.
[13:32] <wgrant> It does crypto and everything.
[13:33] <RicardoPerez> mpt: right. I needed to apt-get install gparted, because he hadn't got it installed
[13:33] <savvas> RicardoPerez: tell him or you go and check out the output of the command: dmesg
[13:33] <savvas> unless it's fixed, that is
[13:34] <savvas> there must be something there useful that says why it's mounted as read-only
[13:34] <RicardoPerez> savvas: well, I'm not in my friend's home now, but the question was hal mounted it on /media/disk using 755 permissions, so my friend's user was unable to write into the disk
[13:35] <RicardoPerez> savvas: after "sudo chmod 777 /media/disk", we was able to write into it
[13:35] <Laney> my god
[13:35] <Laney> it's impossible to unsubscribe from that bug
[13:35] <wgrant> RicardoPerez: Aren't those permissions on the filesystem?
[13:36] <Laney> times out on the web, get an OOPS when using the email interface
[13:36] <wgrant> Laney: Add /+subscribe to the URL.
[13:36] <savvas> hm..
[13:36] <wgrant> deryck: ^^
[13:36] <savvas> maybe there should be a "guide on first mount"? :P
[13:36] <RicardoPerez> wgrant: the 755 permissions are the default permissions assigned by hal
[13:36] <Laney> thanks wgrant
[13:37] <RicardoPerez> my question is: what about hal to use 777 permissions *by default* on a dinamically mounted ext3 volume?
[13:37] <wgrant> RicardoPerez: That sounds dangerous.
[13:37] <savvas> ah wait there is a user at that bug, he claims it does ask you for special permissions
[13:37] <wgrant> Like Windows allowing all users the ability to create directory in C:\
[13:38] <savvas> RicardoPerez: that's already done on fat32 usb flash disks, and it is considered dangerous :)
[13:38] <wgrant> savvas: No - they're mounted with the user's UID, so only the user has access.
[13:38] <RicardoPerez> savvas: well... fat32 hasn't got permissions, I think :)
[13:38] <savvas> exactly
[13:39] <savvas> ah you're both right
[13:39] <RicardoPerez> the /media/disk for a dinamically mounted ext3 volume is owned by root
[13:39] <savvas> let me find that bug and update it :P
[13:39] <RicardoPerez> and has a 755 permissions
[13:40] <deryck> wgrant, Is it 382074 that we're talking, that it doesn't load the subscribers?
[13:40] <wgrant> deryck: Yes.
[13:40] <wgrant> deryck: And breaks the unsubscribe functionality completely.
[13:41] <RicardoPerez> my suggest is to have a 777 permissions by default on an ext3 volume, so anyone can write on the disk
[13:41] <wgrant> It's going to be hitting a lot of people.
[13:41] <wgrant> RicardoPerez: No. Very bad idea.
[13:41] <RicardoPerez> even more, it could have an sticky bit
[13:41] <james_w> deryck: wrote a script that used bug.unsubscribe(person) yesterday. You rock.
[13:41] <RicardoPerez> so an user can't remove the files from another user
[13:42] <wgrant> RicardoPerez: So any user on my system can stick whatever they want on my USB device? No.
[13:42] <deryck> james_w, excellent!  Glad it worked well for you.
[13:43] <RicardoPerez> wgrant: well, I'm not talking about an USB disk (which is almost always a fat32 device), but an internal hard disk drive
[13:43] <wgrant> RicardoPerez: That USB devices are almost always FAT32 is a bug.
[13:43] <deryck> wgrant, I'm definitely trying to get these subscribe bugs all cleared out this cycle.
[13:43] <wgrant> RicardoPerez: 777 is not the solution to anything.
[13:43] <wgrant> Except /tmp
[13:43] <wgrant> deryck: Great.
[13:44] <RicardoPerez> my friend is a solo user (he's the only user in his system), and he bought the new hard disk to put data into it. but he couldn't put anything into it because the disk was mounted as 755 permissions and root owner, so only root could write data
[13:45] <wgrant> RicardoPerez: The owner is the problem, not the permission bits
[13:45] <RicardoPerez> solutions: 1) 777 permissions; 2) change the owner to the friend's user
[13:45] <wgrant> RicardoPerez: If it was mounted dynamically, it was done from the user's session, so it knows who it should grant the privileges to.
[13:45] <RicardoPerez> wgrant: so the 2) solution is better than 1), right?
[13:46] <wgrant> RicardoPerez: By approximately infinitely many times.
[13:46] <wgrant> Anyway, this is way off topic for here.
[13:46] <RicardoPerez> that's right, too :)
[13:49] <RicardoPerez> I've just posted a comment in the bugreport about the owner fix. Hope that helps
[13:52] <eduplessis1> hi
[13:52] <eduplessis1>  [Bug 183685] Unsubscribe
[13:53] <eduplessis1> a lot of people want to unsubscribe
[13:53] <henninge> eduplessis1: add /+subscribe to the bug url to go directly to the subscribe/unsubscribe form.
[13:54] <eduplessis1> ok thanks
[13:54] <eduplessis1> because the button unsubscribe dont work
[14:01] <wgrant> I find it remarkable that those people think their various spellings will work, and that they manage to send some emails several times.
[14:06] <Wachert> hi there
[14:06] <Wachert> how can i create a new language in launchpad? we need german informal and theres just german and german low (not what we need)
[14:07] <henninge> Wachert: if it has an iso code we can create it.
[14:09] <Wachert> i have to search if there is one
[14:09] <Wachert> is just know it as de and de-informal
[14:10] <henninge> Wachert: never heard of it, although I speak it ... ;-)
[14:10] <henninge> Wachert: you can always apply for an iso code
[14:11] <henninge> Wachert: but it doesn't sound to me like "Umgangsdeutsch" will be recognized as a spoken language.
[14:11] <Wachert> kannste deutsch?
[14:11] <henninge> klar
[14:11] <Wachert> na geht doch
[14:11] <Wachert> also informal ist ja kein Umgangsdeutsch
[14:11] <henninge> ist aber ein englischer Channel hier
[14:24] <BUGabundo> wgrant: Laney deryck I think I'll there the direct link to unsub, for all of those that can't do it right now! is it ok ?
[14:24] <Laney> you think you'll what the link?
[14:24] <BUGabundo> eheh
[14:24] <BUGabundo> "post"
[14:25] <BUGabundo> now if I could recall the bug number ....
[14:25] <henninge> BUGabundo:  add /+subscribe to the bug url to go directly to the subscribe/unsubscribe form.
[14:25] <Laney> is there a bug about this timing out issue?
[14:25] <BUGabundo> henninge: I know that, you know that, but the 200+ users there don't!
[14:25] <BUGabundo> Laney: not that I've found one
[14:25] <henninge> BUGabundo: oh, right ;-)
[14:25] <wgrant> Laney: No.
[14:25] <BUGabundo> anyone has the bug on hand?
[14:25] <BUGabundo> wgrant: care to file one?
[14:26] <wgrant> BUGabundo: I'm half asleep.
[14:26] <henninge> I'd assume there is one.
[14:26] <henninge> BUGabundo: that is not the IE7 issue, is it?
[14:26] <wgrant> henninge: No.
[14:26] <wgrant> henninge: It's a bug when a bug has lots of subscribers.
[14:26] <BUGabundo> henninge: no
[14:26] <wgrant> Nobody can unsubscribe any more.
[14:27] <wgrant> Unless they really know what they're doing.
[14:27] <BUGabundo> wgrant: well they can. just not use the ajax thingy
[14:27] <henninge> ah, the timeout problem
[14:27] <BUGabundo>     https://bugs.launchpad.net/bugs/191365
[14:28] <henninge> https://bugs.edge.launchpad.net/malone/+bug/386236
[14:28] <wgrant> That's exposed by the timeout bug, yes.
[14:29] <BUGabundo> For all of those that are trying to unsubcrive from this bug and cant (due to a Launchpad timeout bug on AJAX), please user the following URL:
[14:29] <BUGabundo> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/131679/+subscribe
[14:29] <BUGabundo> is this text ok?
[14:30] <BUGabundo> no one ?
[14:30] <BUGabundo> sent
[14:30] <henninge> BUGabundo: ok, but check the spelling
[14:30] <BUGabundo> I did
[14:30] <henninge> 2 fast 4 me
[14:30] <henninge> ;-)
[14:30] <tsimpson> "please user" <- error
[14:30] <BUGabundo> speller doesn't know unsubscribe
[14:31] <BUGabundo> now to file the timeout one
[14:38] <BUGabundo> wgrant: no. that's me! you do something else :)
[14:38] <wgrant> BUGabundo: 'fraid not.
[14:39] <BUGabundo> oh!
[14:39] <BUGabundo> I've been mistaken all this time :\\
[14:42]  * persia points out that wgrant is not only an annoying user, but sometimes puts on the appointed user representative hat
[14:43] <wgrant> persia: The validity of that hat was brought into question in January, and the question was never resolved.
[14:44] <persia> Hrm.  I missed somethng then.
[14:44] <BUGabundo> I have no idea what you guys are talking about
[14:45] <BUGabundo> I've seen wgrant so long around I though he was a LP dev
[14:45] <persia> The validity of the manner in which a set of stuff was submitted was brought into question, and I was in agreement with those who felt unrepresented, but I didn't know that the role remained unresolved.
[14:45] <persia> I'll try to review, and get out a statement.
[14:45] <wgrant> persia: I wasn't following it at the time, as I was away without Internet access for the two weeks over the debate.
[14:45] <wgrant> Anyway, I should go to bed.
[14:46] <BUGabundo> g'night wgrant
[14:46] <noodles> night wgrant
[14:46] <wgrant> Night noodles, BUGabundo.
[14:47] <henninge> G'Night wgrant
[14:47] <BUGabundo> hey Ursinha
[14:47] <BUGabundo> Ursinha: so now I have to do your job too ?!?
[14:47] <Ursinha> BUGabundo, I'm sorry?
[14:48] <BUGabundo> I'm finding bugs on LP that you should have found before they went to Production :)
[14:49] <henninge> Hi Ursinha, how are you? :)
[14:49] <Ursinha> hey henninge :)
[14:50] <henninge> BUGabundo: Ursinha always likes to smile, so be nice to her and smile, too!
[14:50] <henninge> ;-)
[14:51] <Ursinha> henninge, :)
[14:51] <mpt> bigjools, so you could track whether people are interested in the PPA at all by whether they follow the link in the e-mail message. You could track whether they actually use the PPA by whether they download the Packages.list. It's only because you want to track something partway between those two that you need to make people click the "Confirm" button. Is that right?
[14:52] <bigjools> mpt: I want to see who was interested enough to go and get a token
[14:52] <bigjools> but your other points in the process are equally as valid
[14:52] <mpt> bigjools, I can tell you that right now: No human is interested in "getting a token". :-)
[14:52] <BUGabundo> henninge: I do pleanty of that, where you can't see ! :))
[14:52] <BUGabundo> mas q n seja por isso. Ursinha ***
[14:53] <noodles> bigjools, mpt: we can do both... generate the token when the user first clicks on 'view'?
[14:53] <mpt> noodles, where would "view" be?
[14:54] <noodles> mpt: where it already is... link from email takes you to page listing all your subscriptions...
[14:54] <noodles> From there a person can view each of their subscriptions.
[14:55] <noodles> The user would not need to know anything about a token being generated etc., they just see the sources.list info they need (for now)
[14:55] <noodles> And the owner of the archive can still see who has 'activated' their access/subscription.
[14:57] <noodles> mpt: actually, scrap that... that was the problem in the first place for why it is the way it is...
[14:57] <noodles> A link is a GET request, and we don't want to be creating tokens when they click on a link...
[14:58] <noodles> Although, it could easily be a button instead that POSTs to create the token...
[15:01] <mpt> noodles, bigjools said that the lazy token generation is an implementation detail. So why is it necessary to require the person to click a button?
[15:02] <bigjools> mpt: well I can tell you that they're interested in getting their sources.list
[15:03] <noodles> mpt: from my point of view, because a link should be idempotent - not modifying the DB... but I don't think the link/button differentiation is an issue...
[15:03] <bigjools> mpt: and it doesn't mention token anywhere in the UI
[15:04] <mpt> right
[15:04] <mpt> Let me put it another way
[15:04] <mpt> Why doesn't Launchpad generate the token for a person at the moment the PPA owner grants access to that person?
[15:05] <bigjools> this discussion is going in circles
[15:05] <noodles> mpt: because the *owner* of the PPA would have no way of knowing who is subscribed.
[15:05] <mpt> bigjools, yes :-/
[15:06] <mpt> noodles, we've already established that no-one is "subscribed". Launchpad doesn't send you any mail about things changing in PPAs just because you've been granted access to them.
[15:06] <bigjools> mpt: you only get access to the repository
[15:07] <noodles> mpt: OK, whatever terminology you want to use... the owner of the PPA would have no way of knowing who had accepted their private access
[15:07] <mpt> noodles, that's why I suggested tracking it instead by who downloads the Packages.list for the PPA.
[15:08] <noodles> mpt: yes, I think that would be great if/when we can do so.
[15:09]  * noodles thinks some more...
[15:11] <henninge> bigjools: quick question: empty ppa removal cannot be done be the user, right?
[15:11] <henninge> Actually, cprov: https://answers.edge.launchpad.net/soyuz/+question/72247
[15:11] <cprov> henninge: no, it doesn't
[15:12] <bigjools> henninge: no
[15:12] <henninge> ;-)
[15:12] <henninge> can either of you close that question then, please.
[15:12] <henninge> ?
[15:13] <cprov> henninge: we are still discussing what to do about it, will close it in a bit
[15:13] <henninge> cprov: oh, now I get that. OK.
[15:13] <cprov> henninge: no worries, thanks for poking :) the decision is taking too long, indeed.
[15:14] <henninge> cprov: I put a note on the whiteboard.
[15:14] <noodles> mpt: IMO, when we have the infrastructure that allows us to see quickly which people are using their private access (like a last_download db field that we can filter by etc.) then we could simply create the individual tokens when the team 'subscription' is created.
[15:15] <cprov> henninge: cool, thanks
[15:15] <noodles> mpt: but until that time, we want to be able to provide the owners of private archives with that information, hence the current method.
[15:15] <noodles> (which could be improved so that there's no confirmation etc.)
[15:15] <mpt> noodles, that would be cool, if it would mean you could get rid of the button. :-)
[15:18] <mpt> In the meantime, I suggest referring to "have access", "grant access" etc rather than "subscribe", and changing "Confirm" to "Show Me How" or similar that (a) generates the token if it's not generated yet and (b) reveals instructions on adding the PPA to sources.list.
[15:19] <noodles> mpt: sounds good :) I'll create a bug with that info so it can get scheduled.
[15:19] <mpt> great!
[15:25] <jblount> Can I turn an exisitng answered question into a LP FAQ?
[15:33] <henninge> bigjools, cprov: what is the solution for people who change their account name and cannot reach their ppa after that?
[15:34] <henninge> I know that this is problematic.
[15:34] <bigjools> henninge: they can't change their name with a ppa
[15:34] <cprov> henninge: they can't change the account name anymore
[15:34] <bigjools> it's blocked
[15:34] <cprov> :)
[15:34] <henninge> oh, how does this happen, then? https://answers.edge.launchpad.net/launchpad/+question/73048
[15:35] <henninge> cprov: assign it to you?
[15:35] <cprov> henninge: users who were left in this condition before the code is fixed are welcome to create a new PPA and continue with their work.
[15:35] <henninge> cprov: I'll make that an FAQ, then.
[15:36] <cprov> henninge: yes, fine. It will be a long session gathering the questions assigned to me today.
[15:36] <henninge> ;-)
[15:36] <henninge> cprov: I've only had one so far.
[15:36] <henninge> and now that I have an FAQ I won't assign this one to you.
[15:37] <cprov> henninge: ehe, not your fault anyways.
[18:14] <Sam-I-Am> howdy
[18:15] <Sam-I-Am> i'm backporting some stuff from jaunty to hardy which involves some rebuild libraries and some just installed directly from the jaunty repos.
[18:16] <Sam-I-Am> i want to use a PPA, but i dont know how to tell it to grab the right dependencies
[18:17] <Sam-I-Am> in other words, how does the PPA build environment know to grab a library from jaunty when I've stated hardy in the changes file
[18:18] <Sam-I-Am> without careful control over how these packages are built i cannot know if they're going to work in someone else's build environment
[18:39] <LarstiQ> Sam-I-Am: you can upload to the jaunty queue, if I understand your problem right.
[18:39] <Sam-I-Am> except these are actually built on hardy... just with some libs from jaunty (like libcap2)
[18:40] <Sam-I-Am> i suppose i could build those libraries from source as well and also upload them... just seems like a waste of space
[18:40]  * LarstiQ falls back to not understanding what Sam-I-Am is after
[18:40] <Sam-I-Am> lol
[18:42] <LarstiQ> Sam-I-Am: for a ppa you can designate other ppas for a source to solve dependencies from
[18:42] <LarstiQ> Sam-I-Am: other than that, the Ubuntu archive is also used
[18:42] <Sam-I-Am> so i'm trying to backport a newer version (e.g., jaunty) of a package to hardy... then i find out it needs libs from jaunty... or the versions of libs from jaunty.  in my build environment i can just manually install the libraries from jaunty on hardy (dpkg -i blah.deb) and the main package compiles fine... but it looks like for a PPA id also need to compile all those libraries from hand too
[18:43] <LarstiQ> Sam-I-Am: yes. Or find an archive that already has those built for hardy.
[18:43] <Sam-I-Am> that also works
[18:43] <Sam-I-Am> ok, so that answers the question.
[18:43] <LarstiQ> Sam-I-Am: that's how backporting is, people aren't strict with dependencies, and suddenly you have a whole chain you need to backport
[18:44] <Sam-I-Am> i can make multiple PPAs ... put libaries in some of them... normal packages in others... then use PPA dependencies for building.
[18:44] <LarstiQ> Sam-I-Am: sure. but if you're uploading all the packages you depend on, you could stick with one ppa.
[18:45] <Sam-I-Am> problem is i try to minimize the number of things i need to backport on a per-package basis
[18:45] <LarstiQ> Sam-I-Am: unless you plan on backporting multiple unrelated packages that share dependencies?
[18:45] <Sam-I-Am> for example, package X might need version Y of a lib, but package W builds fine against lib version Z
[18:46] <Sam-I-Am> if i upload version Y, then package W might start depending on it instead of just working with Z (usually the original hardy lib)
[18:46] <LarstiQ> Sam-I-Am: right
[18:46] <LarstiQ> Sam-I-Am: well, you specify the dependencies in control
[18:47] <Sam-I-Am> yeah... i guess i can specify particular versions of libs
[18:47]  * LarstiQ nods
[18:47] <Sam-I-Am> some of them are "just needs libblah" without a particular version
[18:47] <Sam-I-Am> ok, i think i've figure out what i need to do now... just going to take a bit longer than i thought.
[18:51] <kirkland> so I'm using launchpad to manage an upstream project
[18:52] <kirkland> and i'm creating milestones and releases, and publishing release tarballs
[18:52] <kirkland> i'm trying to create a 2.10 milestone, but launchpad doesn't like this
[18:52] <kirkland> because i already have a 2.1 milestone
[18:52] <kirkland> actually, i have 2.[1-9] milestones already
[18:52] <kirkland> which is going to preclude me from making 2.[1-9]0 milestones
[18:53] <kirkland> highly inconvenient
[18:53] <kirkland> is this a launchpad bug?
[18:53] <kirkland> if so, is it a "won't fix" launchpad bug?
[18:54] <beuno> sinzui, ^
[18:54] <sinzui> kirkland: it is by design
[18:54] <kirkland> sinzui: hrm
[18:54] <elmo> sinzui: seriously? why?
[18:54] <kirkland> sinzui: so this is 'won't fix' ?
[18:55] <sinzui> kirkland: milestones must be unique to the project, not the series, because project groups need them to be unique to the project
[18:55] <sinzui> kirkland: we tried to remove the constraint last February, but there were horrible problems on staging
[18:56] <kirkland> sinzui: so i should version my releases 2.001 ... 2.999 ?
[18:56] <sinzui> kirkland: yes.
[18:56] <kirkland> ugh
[18:57] <kirkland> or i guess i can skip 2.10, 2.20, 2.30, 2.100, 2.200 ... etc.
[18:57] <LarstiQ> euh?
[18:57] <kirkland> 2.9 -> 2.11
[18:57]  * LarstiQ wonders what bzr is doing differently
[18:57] <sinzui> kirkland: the common occurrence of this conflict is between the trunk and the stable series. So I suggest not putting the milestone on the trunk series or use a prefix like t2.10
[18:58] <LarstiQ> sinzui: it looks to me like you and kirkland are not talking about the same thin
[18:58] <LarstiQ> ?
[18:58] <kirkland> sinzui: so can i have r2.1 and r2.10 ?
[18:58] <LarstiQ> sinzui: surely, 2.1 and 2.10 don't clash on uniqueness?
[18:58] <sinzui> kirkland: yes you can
[18:58] <sinzui> LarstiQ: yes
[18:59] <kirkland> sinzui: i'll try that, then
[18:59] <kirkland> sinzui: okay, i'll try that
[18:59] <kirkland> sinzui: thanks
[18:59] <sinzui> kirkland: LarstiQ: when we made releases dependent on milestones, there were 90 milestones that we prefixes the series name to to ensure their was no anme conflict
[19:00] <LarstiQ> sinzui: is that a 'no, they do clash', or 'yes, they do not clash'?
[19:00] <sinzui> LarstiQ: they do not clash
[19:00] <LarstiQ> sinzui: then I don't understand what is going on in kirkland's case
[19:00] <kirkland> LarstiQ: https://edge.launchpad.net/byobu/trunk
[19:01] <kirkland> LarstiQ: i had milestones 2.1 - 2.9 already defined
[19:01] <kirkland> LarstiQ: when i tried to create a 2.10 milestone, LP refused, saying i already had a 2.1 milestone
[19:01] <kirkland> LarstiQ: so i called it 2.ten
[19:01] <kirkland> LarstiQ: but just renamed it r2.10
[19:01] <kirkland> LarstiQ: which is fine, as long as I can create r2.100, sometime in the future
[19:02] <LarstiQ> kirkland: right. And my understanding of what sinzui said makes me think LP should not complain about 2.10 because of 2.1
[19:02] <kirkland> LarstiQ: well, it definitely did :-)
[19:02] <LarstiQ> kirkland: hence my confusion :)
[19:03] <sinzui> kirkland: it should not complain about those two names. they are just simple strings that cannot be reused
[19:03] <maxb> I'm confused. How can "2.10" and "2.1" conflicting not be a bug?
[19:04] <sinzui> kirkland: I suspect you are using a milestone name that is already used, and launchpad did not clearly state what series uses it and explain that you can choose a new name, or rename the old one.
[19:04]  * LarstiQ looks for a prior 2.10 in byobu
[19:04] <kirkland> sinzui: hmm, it *just* let me create a 2.10
[19:05] <kirkland> sinzui: but i swear it didn't let me create a 2.10 yesterday
[19:05] <LarstiQ> kirkland: ah see, that is where your name is familiar from, the screen-profiles package :)
[19:05] <sinzui> https://edge.launchpad.net/byobu/+series
[19:05] <kirkland> LarstiQ: is that a good thing, or bad thing?
[19:06] <LarstiQ> kirkland: a good thing I think
[19:06] <sinzui> kirkland: you appear to be conflicting between the release and the milestone
[19:06] <sinzui> kirkland: a release is created from a milestone
[19:07] <sinzui> kirkland: I believe the UI shows your the milestone on the trunk series page and suggests that you create a release from *it*
[19:07] <sinzui> kirkland: and if you look at the milestone itself, it too will suggest to create a release.
[19:08] <kirkland> sinzui: okay, i think we're all good
[19:08] <kirkland> sinzui: i'll let you know in a few months, when i try to create a 2.20 release :-)
[19:08] <sinzui> so, kirkland, I think you now have redundant milestone, because the release implies you just released it
[19:10] <kirkland> sinzui: is there a better way for me to do this?
[19:10] <kirkland> sinzui: i only really create a milestone, so that i can release the tarball
[19:13] <sinzui> kirkland: well, there is a shortcut
[19:13] <kirkland> sinzui: ideally, something i could run from the command line as part of my release.sh script?  :-)
[19:13] <sinzui> kirkland: I believe you can see a (+) Create release on https://edge.launchpad.net/byobu/trunk
[19:14] <kirkland> sinzui: right, that's what i use
[19:14] <kirkland> sinzui: then i have to select a milestone
[19:14] <kirkland> sinzui: and there's a create milestone linke
[19:14] <kirkland> sinzui: which is also what i use
[19:14] <sinzui> That form will let you select an existing milestone *or* create a new one using a very pretty AJAX form
[19:14] <kirkland> sinzui: then i select the date (which is always "now")
[19:14] <kirkland> sinzui: right
[19:14] <kirkland> sinzui: then one i have the release, i click to another page
[19:14] <kirkland> sinzui: and then upload the orig.tar.gz, and the *.asc
[19:15] <kirkland> sinzui: it would be *hot* to do all of this clicking from the command line, ssh/gpg authenticated :-)
[19:15] <sinzui> that *now* problem really irks me. We should solve the DB issue so now is the defaul and you do not need to set it
[19:15] <LarstiQ> kirkland: hmm, wonder if unperish supports that
[19:16] <sinzui> kirkland: there is a bug tracking that feature request to make uploads easier. It is a hard problem so we could not solve it for our 3.0 goals
[19:16] <kirkland> sinzui: cool, thanks, i'll find it and subscribe
[19:17] <kirkland> LarstiQ: i'm unfamiliar with unperish
[19:17] <sinzui> kirkland: I would /recommend/ setting the release url for the series so that the files are automatically downloaded and created, but the script is unreliable
[19:18] <kirkland> sinzui: hmm, okay ...  so is that a positive, or negative recommendation?
[19:18] <cumulus007> Hi, I'm trying to become a Ubuntero, but I can't complete the last step
[19:19] <cumulus007> That step requires me to paste the content of a .asc file into a form on Launchpad
[19:19] <cumulus007> But when I post it, I get the following error: "Bad data"
[19:19] <sinzui> kirkland: It may work for you...it does not work for me. I think I need to hack on it on my weekends to make it rock
[19:20] <LarstiQ> kirkland: it is a script to automate software releases
[19:20] <sinzui> cumulus007: is there an oops id with that error?
[19:21] <cumulus007> No, it just says "there was 1 error"
[19:21] <sinzui> cumulus007: paste your input into http://pastebin.ubuntu.com/
[19:22] <sinzui> and give the the url so that I can look at it
[19:22] <savvas> Was there an email subscription / server mail application related update today for code launchpad?
[19:22] <cumulus007> http://imagebin.ca/view/iQVGgGI.html
[19:22] <cumulus007> http://pastebin.com/d1d29e5e3
[19:22] <savvas> I think my bug 384217 is fixed, that's why I'm asking :)
[19:23] <kirkland> LarstiQ: sinzui; cool, i'll check it out
[19:24] <sinzui> cumulus007: I think you pasted the output twice. There are two messages and two signatures
[19:25] <cumulus007> it works now, thanks :)
[19:25] <sinzui> np
[19:25] <DeSian> hi
[19:26] <DeSian> we translate wordpress since 2.5 in launchapd but still is "Newly translated in Launchpad " why isn't green and Unchanged?
[19:28] <sinzui> DeSian: https://translations.launchpad.net/wordpress/+translations ?
[19:28] <DeSian> sinzui, and?
[19:29] <sinzui> DeSian: are you asking why a lot of the translations are not green on this page?
[19:30] <DeSian> no, i'm talking about our language kurdish CKB
[19:32] <sinzui> DeSian: I don't have an answer for you. I do not see kurdish CKB among the Kurdish languages. The Green means that the wordpress translations were accepted by wordpress, and the PO files were added to the source code
[19:32] <DeSian> sinzui, kurdish CKB is Kurdish (sorani)
[19:33] <sinzui> DeSian: sorry, I am ignorant
[19:34] <sinzui> DeSian: Send an email to the translation group owner (https://translations.edge.launchpad.net/+groups/wordpress-translators) and ask if something needs to be done to accept the translations
[19:34] <DeSian> i'm self the group owner :)
[19:35] <DeSian> i'm her to asking you!
[19:37] <sinzui> DeSian: Send an email to ubuntu-translators@lists.ubuntu.com. Someone from the translations team can help you
[19:38] <sinzui> DeSian: All the launchpad translation team are offline at the moment
[21:26] <mrooney> Is there any standard way to get the repository path of a daily build PPA? Or do you just hope they have a watch file?
[21:30] <Sarvatt> has anyone else been having problems with a high number of transient build failures on karmic amd64 (and sometimes lpia) ever since the core-utils problem a few weeks ago? I don't know where to start looking for the problem, it looks like this (although the specific files it fails on change) and rebuilding always fixes it even though its taken up to 4 rebuilds before. /usr/bin/install: cannot create regular file `/build/buildd/mesa-7.
[21:30] <Sarvatt> 6.0~git20090612.41091087/debian/tmp/usr/include/GL/glew.h': File exists
[21:31] <Sarvatt> here's the logs on 2 seperate PPA's that failed from the same source on different parts http://launchpadlibrarian.net/27837391/buildlog_ubuntu-karmic-amd64.mesa_7.6.0~git20090612.41091087-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz    http://launchpadlibrarian.net/27837181/buildlog_ubuntu-karmic-amd64.mesa_7.6.0~git20090612.41091087-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
[21:35] <Sarvatt> i dont hit the problem ever building it locally on karmic amd64 but its pretty much guaranteed the first attempt will fail on amd64 via PPA now if I upload it while theres a queue
[21:37] <maxb> Sarvatt: Does the package build in parallel at all? The symptoms smell like a race condition
[21:44] <Sarvatt> yeah it does, the part thats racy had its build process changed recently upstream too about the same time the problems started showing up. i'll look into that more. thanks for the help :)
[21:45] <stefanlsd> Im using launchpadlib and doing a getPublishedSources(source_name = app, status='Published', exact_match=True) - what i want to do is check in active series. Do i need to do an if distro_series.active: - or is there a way to do it in the publishedsources check?
[21:55] <james_w> stefanlsd: I would do a loop over ubuntu.series, calling getPublishedSources with distro_series=series with each series that is active
[21:55] <james_w> is that what you meant?
[22:01] <stefanlsd> james_w: how do you determine if a series is active? from my understanding of the doc its a loop over all getPublishedSources and a check if distro_series.active == True?  I was wondering if there was a way in the getPublishedSources to return only active series.  (although thinking about it, thats silly. hehe.  i should probably start with a distribution.active loop before getPublishedSources)
[22:02] <james_w> yeah
[22:02] <james_w> for s in ubuntu.series:
[22:02] <james_w>     if not s.active:
[22:02] <james_w>         continue
[22:02] <james_w>     ubuntu.main_archive.getPublishedSources(distro_series=s, ...
[22:04] <stefanlsd> james_w: thanks!
[22:06] <james_w> np
[22:28] <stefanlsd> james_w: interestingly - i did a loop with the way you mentioned (logical way), and it takes 4 minutes to execute. Same script but doing getPublishedSources first (no distro_series check there) and then doing if distro_series.active: and it executes in 1 minute.
[22:29] <james_w> odd
[22:57] <stefanlsd> Is https://bugs.staging.launchpad.net/ broken for anyone else?
[22:59] <beuno> stefanlsd, it seems to be timing out
[22:59] <stefanlsd> beuno: ok thanks. getting that too
[23:01]  * stefanlsd pokes anyone in charge of  bugs.s.l.n (thats staging.launchpad.net and not sex, language and nudity) - some people do there best dev at midnight on a friday!
[23:05] <mthaddon> stefanlsd: seems to be working ok for me - still timing out for you?
[23:08] <stefanlsd> mthaddon: thanks website working now. getting a launchpadlib HTTP Error 503: Service Unavailable trying to do lp.bugs.createBug() now, but it may be a coding error on my side
[23:09] <mthaddon> k
[23:13] <eagle00789> how can i fix the "Cannot find svn repository root." problem??
[23:24] <eagle00789> i know that it must mean that the svn-server it is pulling from is missing something. but what??