[00:14] 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] 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] is it possible to get my ppa renamed? [00:17] popey: You weeeeere told it would break your PPA. [00:17] i was? [00:17] i didnt realise it would break like this [00:18] Fortunately, it's fixable. [00:18] shall i file a question on lp? [00:18] Just delete all of the packages, wait 5 minutes, then copy them back in. [00:18] That'll have it fixed in 10 minutes. [00:18] ooo, thats even better [00:18] nice one, thanks! [00:19] And then maybe ask a question to get your old PPA removed from ppa.launchpad.net, as it'll be orphaned now. [00:19] nice patronising weeeeeeere there by the way ;) [00:19] should i delete my ppa and create a new one after deleting the packages from it? or is that not necessary? [00:19] You can't delete the PPA - but no, that's not necessary. [00:19] ok [00:20] This is horribly broken [00:20] 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] i thought there was a way to automatically build packages from a bzr repo. but the help page only talks about uploading. [00:20] i will wait overnight [00:21] zsquareplusc: Various people have written various scripts to do that. There's nothing built into Launchpad to do that yet. [00:22] Daviey: What's horribly broken? [00:23] someone else could sign up as alanpope and they may have trusted me personally previously, they may not trust the new me [00:23] wgrant: -> pm [00:23] popey: The OpenPGP key will stop that. [00:23] 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] he explains it better anyway :) [00:23] zsquareplusc: That's right. [00:24] Daviey: OK... [00:24] wgrant: ah well.. it's here now [00:24] I'm *assuming* it creates a new gpg key.. not checked that if i sign up as ~alanpope now it does [00:24] It does, yes. [00:24] but the bigger issue is, how many people bother checking the apt-get warning [00:25] the OpenPGP key is associated with the PPA in the DB, so it will have been moved with the PPA. [00:25] Well, it exists for a reason. [00:25] (considering people are used to apt-get gpg warnings) [00:25] It shouldn't be ignored. [00:25] They shouldn't be used to them. [00:25] much much worse things can happen if people ignore them. [00:25] further, a *real* example is ~screen-profiles, which does indeed have many subscribers [00:25] (well did) [00:26] "They shouldn't be used to them." doesn't really wash IMO [00:26] It is certainly a problem. [00:26] I'm *certain* most users would ignore it [00:26] Those users are buggy. [00:27] i imagine many people wouldn't bother checking the digits [00:27] And apt should probably refuse to install packages from a repo that has recently become unsigned. [00:27] But, then there's still the risk that somebody will stumble on instructions about installing the old PPA. [00:27] 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] Then they'll go to the fake PPA page on LP, and get the new evil key. [00:27] And everybody dies. [00:28] wonder how many people did adopt the mezism [00:28] LP really isn't designed for people changing names, eh :) [00:28] s/name/id [00:29] oww. debuild -S packages the .bzr directory and other files not belonging to the distribution too :/ [00:29] Daviey: That *is* part of the reason you're not allowed to change your name if you have a PPA. [00:29] wgrant: point of order. :-) " 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] This is one reason why VISTA's security popups are such a fail. they become "normal" and hence mindlessly accepted. [00:29] zsquareplusc: Perhaps use bzr-builddeb, or pass '-i' to debuild [00:31] 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] If they ignore that, there is nothing that can be done to save them... [00:31] ha! [00:31] aas, it is not that easy :-) [00:31] alas! [00:32] piss them off enough, and they'll find a way to switch the irritation off altogether. even worse end result. [00:32] (aka mez's script) [00:32] aiui, yes. [00:32] Apparently. [00:33] mmm, debuild 's --help and the manpage do not explain -i though they mention it in an example [00:33] zsquareplusc: That's because debuild calls dpkg-buildpackage, which calls dpkg-source. See dpkg-source's manpage. [00:33] Well even running the script manually, popey's post, would be enough to cause a dangerous situation [00:33] Daviey: Right. [00:34] 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] But the latter removes much of the reason for renaming accounts - freeing up the namespace. [00:34] 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] wgrant: i'm certain that locking the old id for a period of time would cause too much issue [00:35] Daviey: s/would/wouldn't/? [00:35] spm: that sounds like the wrong thing to me [00:35] err wouldn't :) [00:36] SamB: in what way? [00:36] well, it's just excessive [00:36] shopping lists classified top secret! [00:36] well that's the fault of using technical controls to solve a people problem. basically. :-) [00:37] MAC's don't care about contents, only enforcement. [00:37] now, rw------- I could see [00:37] but top secret means something a bit different from that [00:38] SamB: MAC as in madatory access controls. rw----- on steroids kinda thing. force bell-la-padula(sp?) model onto windows etc. [00:38] 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] SamB: so can copy'n'paste from a Secret window into a TS one, but not the other way. [00:39] okay, yeah, that's kind of idiotic [00:39] Daviey: Right - that's a situation I mentioned earlier. [00:39] end result, users end up working in the TS windows only, as life is easy there. [00:39] oh [00:39] yup. it is idiotic. :-) [00:39] isn't that kind of like running as Admin ? [00:39] Yes. [00:40] Vista's dialog is better than *that* [00:42] 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] little boy that cries wolf; by another name, [00:42] Hmmm. Does process-deathrow not run every half hour? [00:44] wgrant: are you talking LP here? and err which part of? :-) [00:44] hello [00:44] Ah, there we go. [00:45] i just face a problem [00:45] spm: It's the Soyuz thingy that removes packages from the disk. [00:45] It just ran. [00:45] popey: You can probably restore stuff to your PPA now. [00:45] 'k === matsubara is now known as matsubara-afk [00:45] i just copied package from my ppa to https://edge.launchpad.net/~ubuntu-on-rails/+archive/ppa [00:45] wgrant: yeah, its fine now thanks [00:45] both ppas in my sources.list [00:46] when i trying to update my package i getting following error from aptitude: [00:46] 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] what should i do? [00:49] antono: I wonder if you have a dodgy proxy between you and Launchpad - that all looks fine to me. [00:50] nope, only if my provider is clever enough to setup such a proxy [00:51] i'll try to get info from my provider [00:52] mm. bzr-builddeb looks nice. but it complains about a missing debian/files while debuild -S runs happily without that one [00:52] I dispute that [00:52] :-) [00:52] did you run "bzr builddeb -S"? [00:53] antono: I can confirm that the archive works fine for me, so it's something on your end. [00:53] wgrant: thanks [00:53] james_w: yes [00:53] "native" mode [00:54] zsquareplusc: can you pastebin the output please? [00:54] is it ok to have 2 versions of one package in both ppas? [00:54] *2 copies [00:54] I'm pretty sure bzr-builddeb doesn't check for debian/files [00:54] antono: They're different binaries, but that is normally fine. [00:55] james_w, i get three lines: Building using working tree | Running in native mode | bzr: ERROR: [Errno 2] No such file or directory: '/debian/files' [00:55] ah [00:55] I know this bug [00:55] sorry, I should have remembered it earlier [00:56] it's actually "No such file or directory: some file that has been removed" [00:57] wgrant: thank you so much! :) [00:57] antono: No problem. [00:58] zsquareplusc: bug 174539 I suspect [00:58] Launchpad bug 174539 in bzr "export doesn't handle files going missing from working tree" [Low,Fix released] https://launchpad.net/bugs/174539 [00:58] Hi all, [00:59] 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] 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] patapouf: what do you mean? do you want to merge your branch into trunk? [01:02] zsquareplusc: what does your "bzr status" say? [01:02] perhaps it's a new bug [01:03] it reports the file that caused the error as removed [01:03] yep, devel to trunk ... [01:03] ok. thanks [01:03] patapouf: just push a merged branch to the location of trunk [01:04] ok .. [01:06] james_w after bzr ci, it builds w/o error now :-) [01:06] woop [01:06] zsquareplusc: would you be so kind as to file a bug report telling me how I could reproduce? [01:08] ow.. reproduce.. hey i'm just building my first package on my own here ;-) [01:10] heh :-) === asac_ is now known as asac [01:20] i guess it will take some time until it appears in the ppa after the dput? [01:27] zsquareplusc: Up to 5 minutes. [01:27] zsquareplusc: If it doesn't show up on the PPA page within 5 minutes, you probably didn't sign it properly. [01:37] my bad.. it's even a FAQ entry, heh [01:37] What was the problem? [01:39] wrong upload destination [01:40] Ah. [01:42] spm: can you see if branch whiteboards are still preserved in the DB? [01:42] lifeless: sure, can you give me some pointers of which table(s) to look at? [01:43] thumper: ^ [01:43] spm: branch or branch* [01:43] 'k, one sec [01:45] lifeless: branch has > 2500 whiteboards that are not null, on staging. [01:46] spm: can you get a dump of the whiteboards for branches of squid [01:46] (join to product where product.name like "%squid%") [01:46] lifeless: sure. gimme a few to work some magic. [01:50] what happened to the whiteboards anyway? [01:51] how are vcs-imports problems supposed to be discussed without them? [01:52] SamB: answers.launchpad.net/launchpad-code [01:52] lifeless: I mean, like, a specific import fails [01:52] SamB: code-imports still have whiteboards [01:52] oh [01:52] lifeless: https://pastebin.canonical.com/18298/ - you may wish to verify my sql-fu [01:52] SamB: so I do - if an import fails, you can alert jml & co via answers [01:53] answers is definitely the best place to ask questions. [01:55] spm: looked fine to me [01:55] thanks [01:55] I've copied the result part of it to them [01:58] lifeless: isn't it usually the vcs-imports people that alert the users? [01:59] I mean, if the FIRST import fails [02:02] SamB: whiteboards are deprecated throughout launchpad [02:25] yes! the package works :-) [02:25] wgrant and james_w: thanks for your help [02:28] 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] nhandler: I don't know. [02:31] nhandler: maybe they could. also, maybe you could do it yourself with th LP APIs. [02:31] lots of maybes :( [02:31] The LP API doesn't let you do that/ [02:32] fail. [02:33] Rather. [02:33] Maybe you can convince a Bugs person to expose it. [02:33] Hmm, but you also can't list a Person's maintained packages. [02:35] isn't that a structural subscription? - tho I'm not aware of those being hooked to teams... [02:35] It is a structural subscription, yes. [02:36] heh. usually it's people wanting *out* of one of those. not in. :-D [02:36] Yep. [02:40] nhandler: I gather it's not possible for you to simply join said team? [02:40] The problem is that lots of subscriptions need to be added. [02:40] Subscriptions of the team to the packages. [02:40] There's no way to do that other than manually through the UI. [02:40] Or SQL. [02:42] 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] 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] (Maintainers aren't automagically subscribed, I might note) [02:43] wgrant: I know [02:43] nhandler: I know you know. [02:43] I wasn't sure that spm did. [02:43] ;) [02:43] nope, didn't know :-) [02:44] ah. perl. yes. that would account for the large number of packages. aka line-noise. [02:47] 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] 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] s/won/own/ [02:49] nhandler: not that I'm aware of - we have to do pretty much the same thing. if only via sql. :-/ [02:49] And the query would be a bit more complicated than the trivial one to remove a subscription... [02:49] to a certain extent, going via an automated UI POST would be safer. albeit more clumsy. [02:49] exactly. [02:50] Ok. I guess I'll write up a Perl script to do this ;) [02:50] Thanks for your help spm and wgrant [02:51] nhandler: But you'll also file a bug to get the subscription methods exposed. [02:51] ha! np. [02:51] mm when i have a deb package is there a dpkg command to list it's dependencies/suggests w/o installing it? [02:51] wgrant: Yes I will. Would that be against the API or LP itself? [02:52] nhandler: launchpad-registry or malone... Since I'm not sure, file against launchpad. [02:53] wgrant: Sure thing [02:53] zsquareplusc: 'dpkg -f /path/to/deb Depends' [02:53] That'll get the Depends field. [02:55] thanks [02:56] 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] 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] persia: Good idea, I'll give that a try [04:25] 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] (and maybe more along the way) [06:41] 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] can I avoid of creating dummy user with required e-mail? [06:47] bialix, You could create a team instead of a user, and give the team contact address as the mailing list. [06:47] (and subscribe the team to the branch, etc.) [06:48] we have a team ~qbzr-dev [06:48] Does the team have a contact address? [06:49] no, it seems not yet [06:49] That's probably the way to do it then (although I don't know the UI very well). [06:50] 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] wgrant: can you explain? [06:51] 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] bialix: What do you use ~qbzr-dev for? [06:52] we are working on QBzr project [06:53] members of the team has write privileges to push new revision to trunk [06:53] also members of team manage bugs [06:53] is there is possible other usage of team on LP? [06:53] OK. Is it used for email at all? Bugmail, branch revision notifications, that sort of thing? [06:54] I don;t understand [06:54] every member susbcribed individually to trunk [06:54] OK, that's good. [06:54] bugmails going to each member too [06:54] Good, good. [06:55] ok [06:55] as you said [06:55] So you should be safe to add the mailing list as the email address. [06:55] Then you can subscribe the team to get emails about merge proposals, and the emails will go to the mailing list. [06:55] and what about bugmails? [06:56] Do you want bugmail to go to the list, or to individuals? [06:56] only to individuals [06:56] Are the individuals subscribed to bugmail, or is the team? [06:56] I found it's too boring [06:56] how can I check this? [06:57] http://bugs.launchpad.net/qbzr ought show it [06:57] * persia gets confused [06:57] https://bugs.launchpad.net/qbzr/+subscribe, in particular. [06:57] As you can see in the porlet, *nobody* seems to get all bugmail for qbzr. [06:58] but we do get it [06:59] For everything, or for individual bugs? [06:59] is not it's a settings of the team itself? [06:59] To put it another way, do you get bugmail for every new bug? [06:59] Hm. [06:59] all new bugs come to me personally at least [06:59] You are right. [06:59] The team has an implicit subscription to the bugs, but it's not on +subscribe. [07:00] I guess so [07:00] implicit subscriptions ought be shown. [07:00] Maybe because they're configured as the maintainer. [07:00] this driver/maintainer split is very confusing [07:00] So, if you set the contact address, something will change: bugmail will go to the mailing list instead of each individual user. [07:00] It is. [07:01] no, this is bad [07:01] You should probably replace 'driver' with 'release manager' when you think about it. [07:01] hm? [07:01] Exactly - this is why I said LP had become inflexible and inconvenient since all these new features appeared. [07:01] this more understandable [07:02] In Launchpad, 'driver' basically means 'release manager'. [07:02] * bialix sigh [07:02] wgrant, I don't think the issue is the new features, so much as that some bits lag behind other bits. [07:02] persia: It worked well when basically the only type of email sent from Launchpad was bugmail. [07:03] But now we have all manner of other stuff. [07:03] And it's unconfigurable. [07:03] Unless you go with the proliferation of teams idea. [07:03] I don't remember when LP didn't also send blueprint mail. [07:03] True, but nobody has seriously used Blueprint properly in years. [07:03] proliferation of teams never helped me much: I just end up on more teams that I don't clearly understand. [07:04] I tried to use blueprint properly about 7-8 months ago :) [07:04] Was it a success? [07:04] blueprints give too much karma [07:04] I'm using it [07:04] Well, except for the several days wading through the volume due to lack of searching, yes, actually. [07:04] but they is not very cool [07:04] bialix: That's because almost nobody uses it, because it's pretty out of date and broken. [07:04] bialix: So the karma is worth more. [07:05] The main issue was not being able to process abandoned blueprints well. [07:05] wgrant: it's bad blueprints is dead and broken [07:05] bialix: I hear there may be work on that soon. [07:05] but [07:05] But it has been abandoned by the Launchpad team for a long time. [07:05] it require link to spec [07:06] and lp does not provide wiki to save the spec [07:06] it's inconvenient [07:06] why there is no wiki? [07:06] this is most annoying part of blueprints brokeness [07:07] 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] and there si not possible toget bird view of all dependecies between topics [07:07] I think the roadmap page did that - but that was removed some time ago. [07:08] persia: I found Trac idea of wiki for everyting is a breeze [07:08] yes, roadmap page disappear [07:08] into blue? [07:08] blue yonder [07:08] right? [07:09] blueprints UI is tooooooooooooo complex [07:09] all this dance with direction approved, split over 2 settings page [07:10] so yes, it's seriously broken [07:10] and it gives too much karma [07:10] Once it's less broken, it will give less karma. [07:11] Because more people will use it. [07:11] Right. [07:11] anybody who is not the part of the team could file a blueprint and get more karma than main devs [07:11] it's not right [07:11] But yeah, the whole approval mess is a bit tricky. [07:13] which parts of LP (in the term code/bugs/blueprints/translations/answers) will be open sourced? [07:13] bialix: Everything except the backend bits of Code and Soyuz. [07:13] and what is LAZR means? [07:14] backend bits -- it's ACL for codehosting? [07:14] https://launchpad.net/lazr - it's the set of some of the Python libraries that Canonical has produced. [07:14] Linux/Apache/Zope/Relational database ? [07:14] no, LAZR is acronym? [07:14] ah [07:14] thank you [07:15] ACLs for bzr is so complex to setup. There is no bzr equivalents to bitbucket or github [07:15] bialix: Um, Launchpad? [07:15] Codehosting is the stuff you push your branches to. [07:16] And probably the vcs-imports stuff as well, but I couldn't be sure. [07:16] on LP I can't create private branches for reasonable small fee [07:16] I need paid codehosting for small price [07:16] bialix, You've asked a question and discovered the pricing? [07:16] bitbucket and github have it [07:17] $250/year + VAT [07:17] 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] I don't asked [07:17] That's for a proprietary project with private bugs. [07:17] Private branches could be different. [07:17] but from all info available it's even not clear I (individual) can have private branches [07:17] You could ask. [07:18] there is info about commercial support [07:18] I've asked poolie directly and he pointed me to answer about commercial support [07:19] 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] exactly [07:19] I suspect LP could get quite a few people on that model... [07:19] Even just from folk who were branching other projects and didn't want to publish yet. [07:19] maybe because entire LP is oriented on open source only [07:20] persia: Exactly. [07:20] while github oriented on profit [07:20] bialix: LP is for commercial projects too. [07:20] IIUC only for BIG commercial projects [07:22] * bialix wishes to run startup as github but for bzr [07:23] That's probably why they are keeping codehosting proprietary. [07:25] * bialix nods [07:26] uhh actually, we offer private branches for a fee. [07:26] we're just lousy at communicating that. [07:27] jml: Nothing obviously affordable like the other services, though. [07:27] even google can't find this answer [07:27] In fact, nothing obvious at all. [07:27] see previous comment :) [07:27] jml, It might be worth having pricing in a FAQ somewhere, rather than in a series of questions. Would improve discoverabilit. [07:28] probably. [07:29] Plus I can't create a private branch outside a private project. [07:29] just to compare with github/bitbucket: one can open price page from main page [07:31] * bialix has to run [07:35] jml: So, I can't find documentation about private branch pricings anywhere at all. [07:35] And if it's not documented, it doesn't exist. [07:36] if you say so., [07:36] Is there documentation on private project pricing? I thought folk were always encouraged to ask questions. [07:36] Asking a question about private branches might generate some documentation (if only in the question log) [07:39] 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] persia: I got some just a couple of hours ago. [07:40] But there has been significant lag at times lately. [07:40] Actually, I just got some bugmail 30 seconds ago. [07:40] Hrm. Then it's probably just me. [07:40] No more than a couple of minutes later than I would expect. [07:40] And while there are two types of bugmail, the kind I just got is the kind that you would be expecting. [07:41] there was a major delay the other day too. [07:41] Yeah. [07:41]