[02:27] <mark06> quite frank question, is Launchpad/Canonical/Ubuntu deteriorating?
[02:29] <spm> http://yourlogicalfallacyis.com/loaded-question :-)
[02:30] <mark06> you mean the answer would not be frank as well from official representatives?
[02:32] <spm> mark06: are you honestly trying to play bingo with that list of fallacies and cross them all off?
[02:32] <mark06> ah from the example is like I want that?
[02:32] <mark06> no, I just thought that was for me
[02:33] <mark06> honestly I would feel quite sad if things are not going so well
[02:34] <mark06> I just received an email today about deactivation of hg import (well explained), and I remember I feel Ubuntu hasn't been so great since some time, but maybe it's just a feeling
[02:35] <wgrant> Hg imports are being discontinued because bzr-hg isn't up to the standard of the other imports
[02:35] <wgrant> There's a total of 43 hg imports that work, and hundreds that don't
[02:35] <mark06> I also saw some project saying it was moving to github...
[02:37] <mark06> I understand the reasons, I feel fine... I honestly hope things get better, Launchpad even without wikis is far superior than github imho
[02:38] <mark06> and ubuntu made linux more popular, and bzr is nice
[02:39] <mark06> I also saw an outdated why bzr over hg page, all this together made me wonder this... I sincerely can't get this dvcs flamewar...
[02:43] <mark06> the hg folks said on a response page that Linus mentioned hg as the only alternative worth attention other than his git... so funny this Linuseligion
[02:45] <mark06> ah sorry this is not my blog :(
[07:41] <pef_> Hi! I'm trying to merge an (apparently autogenerated?) launchpad account into my main one
[07:41] <pef_> because I want to use the register the email address as mine
[07:42] <pef_> so I go through the merge process
[07:42] <pef_> but when I click on the link in the email, I get an Oops ...
[07:42] <wgrant> pef_: What's the OOPS ID?
[07:42] <pef_> I tried it twice, here's one of them:  OOPS-e2f5d3b6769c012de049daf4a60c0941
[07:44] <pef_> thanks!
[07:44] <wgrant> Let's see...
[07:46] <pef_> but I never registered a patrick-farrell-imperial account (as far as I can remember)
[07:46] <pef_> I have no idea how it came about, to be honest
[07:47] <wgrant> https://launchpad.net/~patrick-farrell-imperial says it was used as the uploader or maintainer of an Ubuntu package, but with the name "The ICOM team"
[07:47] <wgrant> Looks like that package was synced from Debian
[07:48] <pef_> err
[07:48] <pef_> I do make packages for our group
[07:48] <pef_> but I'm pretty sure none of them ever got into Debian
[07:48] <pef_> I would have noticed
[07:49] <wgrant> Ah, maybe someone uploaded it to a PPA and that page is lying
[07:49] <wgrant> Anyway, you've run into a bug. If you ask a question at https://answers.launchpad.net/launchpad/+addquestion an admin can sort the merge out for you manually.
[07:50] <pef_> you couldn't just add patrick.farrell@imperial.ac.uk to the email addresses for pefarrell, could you?
[07:50] <pef_> that's my actual goal (so that I can send an email to a list)
[07:52] <wgrant> No, but if you ask the question I can have that account merged in a few minutes.
[07:52] <wgrant> Bug #1057947
[07:52] <pef_> ok
[07:53] <pef_> https://answers.launchpad.net/launchpad/+question/209799
[07:53] <pef_> thanks for launchpad, by the way, we love it
[07:58] <wgrant> pef_: The merge is queued, should be finished in a couple of minutes.
[07:59] <pef_> great, thanks
[08:01] <wgrant> pef_: That's done. You'll now need to confirm the email address at https://launchpad.net/~/+editemails, and that should be that.
[08:02] <pef_> great, all done
[08:02] <wgrant> Indeed, looks good
[08:32] <geser> wgrant: have you an idea what this logs tries to tell me? https://launchpadlibrarian.net/117613235/upload_4158616_log.txt
[08:33] <wgrant> geser: Looks like a connectivity glitch when talking the librarian :/
[08:33] <wgrant> A retry will work
[08:34] <geser> ah, ok. I guess it's not worth doing a retry as it's from the archive rebuild
[08:45] <lifeless> mgz: btw wherever you found the bot source code that handles oops links
[08:46] <wgrant> It needs the OOPS- prefix?
[08:46] <lifeless> mgz: it currently chews off the OOPS- prefix in generating the URL, it shouldn't.
[08:46] <lifeless> mgz: there is backwards compat code to permit that, but I'd like to eventually ditch that.
[08:50] <tsimpson> lifeless: what should the format be, exactly?
[08:53] <lifeless> tsimpson: https://oops.canonical.com/oops/?oopsid=OOPS-ddb3a4e6e473461ac93b92604efcb918 is the canonical url for the oops =OOPS-ddb3a4e6e473461ac93b92604efcb918
[08:53] <lifeless> bah, miscopied the =
[08:53] <lifeless> tsimpson: https://oops.canonical.com/oops/?oopsid=OOPS-ddb3a4e6e473461ac93b92604efcb918 is the canonical url for the oops OOPS-ddb3a4e6e473461ac93b92604efcb918
[08:53] <lifeless> the OOPS regex lp uses is OOPS-.*\>
[08:54] <tsimpson> so I just need to keep the OOPS- part, ok
[08:54] <maxb> Wouldn't that regex match the string "OOPS-foo bar baz quux" ?
[08:55] <lifeless> maxb: no, because \> matches end of word, in non-greedy
[08:55] <lifeless> tsimpson: yes, I think so
[08:56] <maxb> \> can change the greediness of the preceding * ?
[08:56] <lifeless> maxb: no you can set greediness globally
[08:57] <lifeless> maxb: I was being sloppy those
[08:57] <lifeless> maxb: *though* - that isn't the exact regex we use
[08:58] <lifeless> maxb: the exact one is phrase in terms of 0-9a-zA-Z kindof things
[09:00] <tsimpson> testing OOPS-ddb3a4e6e473461ac93b92604efcb918 testing
[09:00] <tsimpson> oh, forgot to reload
[09:01] <tsimpson> testing OOPS-ddb3a4e6e473461ac93b92604efcb918 testing
[09:01] <tsimpson> there we go
[09:02] <lifeless> tsimpson: thanks!
[09:02] <tsimpson> you're welcome :)
[09:24] <mgz> lifeless: oops.*/oops/?oopsid=OOPS=* is the canonical form? that seems oopsy
[09:26] <lifeless> OOPS- not OOPS=
[09:27] <mgz> sorry, right.
[09:27] <mgz> so, I'm not sure it's clear you'll be looking at an oops when you visit that link ;)
[09:27] <lifeless> well, its the right URL
[09:28] <lifeless> its the one oops-tools itself emits in its reports
[09:30] <lifeless> mgz: what makes it unclear ?
[09:30] <mgz> lifeless, it's too clear :D
[09:31] <lifeless> mgz: ah ok
[13:26] <ItaloPessoa> hi
[13:28] <ItaloPessoa> somebody could help me? when I try upload a pack to a ppa i go this message Uploading linkorganizer_1.0.3.dsc: 125 Data connection already open, starting transfer
[17:08] <czajkowski> c
[17:41] <Darxus> How do I find out if the packaging for wayland / weston are in bzr on launchpad anywhere?
[17:56] <dobey> Darxus: are they in the ubuntu archive?
[18:31] <Darxus> dobey: Yes.
[18:31] <Darxus> bzr: ERROR: bzrlib.errors.BzrCommandError: deb-version not fully expanded: {debversion}+{git-commit}. Valid substitutions are: ['{time}', '{date}', '{revno:packaging}', '{revno}', '{svn-revno:packaging}', '{svn-revno}', '{git-commit:packaging}', '{git-commit}', '{latest-tag:packaging}', '{latest-tag}', '{debversion:packaging}', '{debversion}', '{debupstream-base:packaging}', '{debupstream-base}', '{debupstream:packaging}', '{debupstream}', ...
[18:31] <Darxus> ... '{revdate:packaging}', '{revdate}', '{revtime:packaging}', '{revtime}']
[18:31] <Darxus> From https://launchpadlibrarian.net/117683014/buildlog.txt.gz
[18:31] <Darxus> It says both "debversion" and "git-commit" are valid... why did that fail?
[18:42] <yofel> can someone make sense of this FTBFS? https://launchpad.net/~scribus/+archive/ppa/+recipebuild/315603
[18:42] <yofel> all I see as error is "Abort"
[19:08] <Darxus> This works:
[19:08] <Darxus> # bzr-builder format 0.3 deb-version {debversion}+{revno}
[19:08] <Darxus> This fails:
[19:08] <Darxus> # bzr-builder format 0.3 deb-version {debversion}+{git-commit}
[19:08] <Darxus> :(
[19:09] <Darxus> "You have exceeded today's quota for ubuntu quantal."
[19:09] <Darxus> Wonderful.
[19:50] <Darxus> Any ideas why {git-commit} is failing for me?  Base branch is https://code.launchpad.net/~ted/wayland/master "This branch is an import of the HEAD branch of the Git repository at git://anongit.freedesktop.org/wayland/wayland."  So, it is imported via git....
[19:51] <Darxus> Recipe is https://code.launchpad.net/~darxus/+recipe/wayland-daily
[21:19] <dobey> Darxus: i would avoid git-commit; it's basically completely useless as part of a version as it's not a constantly incrementing number. you could get a later git commit which sorts lower than an older one, for version comparison
[21:19] <dobey> Darxus: for daily builds, i typically use {debupstream}+r{revno}-{revno:packaging} as the deb-version
[21:21] <Darxus> dobey: I plan to keep the date in there, but I'd like to be able to look up what commit a build came from to see if, for example, it's before or after a fix for some problem.
[21:21] <dobey> yofel: scroll up. there's an issue with the libtiff dependencies; looks like it wants both libtiff4-dev and libtiff5-dev, which conflict
[21:23] <dobey> Darxus: which is exactly why i use +r{revno}; git using only hashes for everything makes this much harder to do of course
[21:23] <yofel> dobey: meh, good catch, sorry for the noise and thanks!
[21:36] <Darxus> dobey: I don't see what you have against those hashes, they can be used to look up commits in the git logs.
[21:36] <dobey> Darxus: i don't have anything against them; but they are just hashes. they don't translate well to other things, like displaying to a user
[21:37] <Darxus> Right, but if what you want is to find out where that build falls in the git commit log, they're what you want.
[21:38] <dobey> right, but putting them in the package's version identifier isn't really a good way to do that
[21:38] <dobey> for the reasons i already stated
[21:39] <Darxus> I agree including other things before it is important, but why not tack it on to the end?
[21:41] <dobey> why not just use the bzr revno, look at that revision in bzr, and it tells you the git commit id. it gives you the exact same information, and presents a more readable version to users
[21:41] <Darxus> dobey: Because it saves a step.  But good point.
[21:43] <dobey> Darxus: it doesn't really matter, you're not looking at subcommits from a merge or anything, you're only looking at specific toplevel revisions in the main branch. you can look at the change in bzr to see what's wrong and just fix it in the git repo if you can, if necessary. which is what i do with rhythmbox for example