[02:29] <poolie> lifeless: i'm pretty sure (and I hope) i did not already file bug 790034
[02:29] <poolie> someone else might have; i was pretty brusque with my bug mail while travelling
[02:32] <lifeless> wgrant: bug 163241
[02:42] <lifeless> poolie: bug 204082
[02:46] <lifeless> wgrant: thanks
[02:54] <poolie> heh, you know, as i was filing it, i thought "this sounds just like something mpt would say"
[02:55] <poolie> not recent though
[03:00] <lifeless> yeah
[03:00] <lifeless> I saw it recently which is why it was in my head
[05:25] <cafuego> Hi, am I in the right spot for help with a launchpad build recipe problem?
[05:28] <cafuego> Though I chose my launchpad login as owner, the build log tells me "You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data."
[05:28] <lifeless> thats normal
[05:28] <lifeless> whats the problem ?
[05:29] <cafuego> The builds fail with that error - I think
[05:29] <cafuego> Oh no
[05:29] <cafuego> Never mind, I need to read it properly :-)
[05:30] <cafuego> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[05:30] <cafuego> dailydeb locally was happy enough :-/
[06:10] <spiv> cafuego: where's the recipe?
[06:12] <cafuego> spiv: https://code.launchpad.net/~cafuego/+recipe/inkscape-daily
[06:12] <cafuego> spiv: I've got it working now
[06:12] <spiv> cafuego: that error means your recipe is trying to merge unrelated branches.  If that recipe works locally then that would be strange...
[06:12] <spiv> Ah good :)
[06:12] <cafuego> spiv: It *did* work locally :-)
[06:13] <cafuego> spiv: But yes, they were totally unrelated.
[06:13] <cafuego> spiv: One is lp:inkscape and the other was a branch that only had a debian/ dir with some guff in it.
[06:14] <cafuego> spiv: I just did a branch of lp:inkscape, add by debian stuff and pushed that back up. It's happy enough with that, it seems.
[06:14] <spiv> You can also use the nest or nest-part directives for that
[06:15] <cafuego> Weeeeell... it works now, I should maybe not touch it ;-)
[06:15] <spiv> That's also a good strategy :)
[06:15] <cafuego> Would nest basically dump repo b into repo a?
[06:17] <spiv> Basically.
[06:19] <cafuego> Cool .. yeah that's what it did locally with dailydeb
[06:19] <cafuego> depite me telling it to merge
[06:27] <spiv> I'm pretty sure the dailydeb builds the recipe using the same logic, it just does some extra stuff relating to changelogs, dput, etc.
[06:28] <spiv> So it's still strange to me that you'd have a recipe that would work locally, unless the branches it was using were different, or perhaps unless you have a newer bzr-builder locally than is deployed on Launchpad.
[06:41] <cafuego> spiv: Possibly; I grabbed it from its daily repo.
[06:41] <cafuego> spiv: ANyways, thankyou :-)  I'd better go shopping before traffic gets too awful.
[06:46] <lifeless> spiv: can't use nest-part
[06:46] <lifeless> spiv: noone has merged it into LP
[06:49] <wgrant> Lies.
[06:50] <wgrant> It's been supported since late last year.
[06:50] <lifeless> hmm, someone was having trouble recently
[06:50] <lifeless> or perhaps my memory is playing up
[06:50] <wgrant> They used recipe version 0.2 instead of 0.3.
[06:51] <lifeless> oh, so baked in confusion ?
[06:52] <wgrant> Ja
[06:52] <wgrant> I believe somebody mentioned that in the bug.l
[06:52] <wgrant> Or I absorbed this knowledge from elsewhere...
[06:52] <wgrant> can't quite recall.
[06:53] <spiv> There is (was?) also a bug that it doesn't allow grabbing just a single file.  But the basic feature works just fine AFAIK.
[07:37] <soren> Is there any way to update the URL a particular vcs import is pulling from? One of the upstream projects I'm tracking moved their SVN repo. Again.
[07:38] <soren> ...or must I request a new import?
[07:39] <wgrant> soren: Which import, and what's the new URL?
[07:39] <wgrant> And is it a continuation of the existing repository?
[07:39] <soren> wgrant: It's an Apache project that moved out of incubation, so I believe it should be the same stuff, just at a new URL.
[07:39] <soren> It's libcloud.
[07:40] <soren> Err..
[07:40] <wgrant> That looks like git.
[07:40] <soren> ?!?
[07:40] <soren> It was SVN on Friday.
[07:40] <wgrant> Ah.
[07:40] <soren> and I got an e-mail saying it was marked failing.
[07:40]  * soren goes to look.
[07:40] <wgrant> It's an import of a git-svn import.
[07:40] <soren> Well.. Yes, that one is.
[07:40] <soren> But.
[07:41] <soren> Hang on, let me find the e-mail before I make more of an arse of myself.
[07:41] <wgrant> There's /trunk, /git-trunk, and /old-git-trunk
[07:41] <wgrant>  /trunk is SVN and failing.
[07:41] <wgrant>  /git-trunk is the development focus and succeeding/
[07:41] <soren> Oh, right, there it is.
[07:41] <soren> Yes, right, ok.
[07:41] <wgrant> What's the new URL?
[07:42] <soren> It's the /trunk one that should be moved. https://svn.apache.org/repos/asf/libcloud/trunk/
[07:42] <wgrant> So just drop the incubator/?
[07:42] <soren> Seems like it.
[07:42] <soren> Yep.
[07:43] <wgrant> It's currently importing.
[07:43] <wgrant> Hopefully it will work.
[07:43] <soren> First they were hosted in their own git. Then they moved to somewhere else. Then they realised they wanted to be an apache project and moved to the incubator svn. Then they grew up and moved out of incubation moving their svn repo again. *sigh*
[07:44] <soren> I hope that's the last of this. At least for a couple of years.
[07:44] <wgrant> Moved from git to svn? Ew.
[07:44] <soren> Blame Apache.
[07:44] <soren> I do.
[07:44] <wgrant> Heh
[07:44] <soren> But you raise good point
[07:44] <wgrant> Importing three new revs.
[07:44] <soren> At some point, Apache will inevitably grow up and move to a DVCS and then I'll have to deal with it again :)
[07:44] <wgrant> Seems happy enough.
[07:45] <soren> \o/
[07:45] <soren> wgrant: Thanks muchly.
[07:45] <wgrant> np
[09:02] <soren> Is there a way in the LP ui to copy a package from Ubuntu proper into a PPA?
[09:02] <soren> Or do I have to pull the source package and do it manually?
[09:07] <geser> soren: does the LP API count for you as UI? I guess you can do it through LP API
[09:09] <soren> geser: It doesn't really, but I guess that might be useful.
[09:10] <soren> geser: It's just not something I need very often at all, so having a point-and-click way of doing it would be nice.
[09:10] <soren> geser: Just fetching the source package and uploading it again took me 30 seconds. Using the LP API, I'd have to actually think :)
[09:51] <AfC> I just branched lp:ubuntu/gwibber but ended up with something that is tagged as 3.0.0-0ubuntu1 but meanwhile my perfectly normal Ubuntu Natty system has gwibber-3.0.0.1-0ubuntu3 installed.
[09:51] <AfC> Did I do something wrong trying to get the branch?
[09:53] <geser> AfC: http://package-import.ubuntu.com/status/gwibber.html#2011-04-05%2022:14:35.633519
[09:53] <soren> AfC: The bzr import failed: http://package-import.ubuntu.com/status/gwibber.html#2011-04-05 22:14:35.633519
[09:53] <soren> Darn it.
[09:57] <AfC> soren: huh
[09:58] <AfC> geser: so, er, huh
[09:59] <AfC> So if I needed to grab the sources for gwibber-3.0.0.1-0ubuntu3 (or whatever is current) and rebuild them, what would be the best way to do that?
[09:59] <AfC> should I try to use bzr builddeb's import-dsc?
[10:05] <geser> AfC: apt-get source gwibber (if you have the source repository enabled) or grab the URL for the .dsc from LP and 'dget' it (if you want a specific version)
[10:07] <AfC> geser: and then import-dsc that?
[10:08] <geser> I'd leave the bzr branch alone until the UDD people fix it
[10:09] <geser> with apt-get source you get the unpacked source package (but we get OT for this channel)
[10:10] <AfC> alright
[14:53] <adeuring> henninge: could you please have a look:  https://code.launchpad.net/~adeuring/launchpad/bug-486824/+merge/62883 ?
[14:54] <henninge> adeuring: sure
[14:54] <adeuring> thanks!
[15:18] <kiko> quick question
[15:18] <kiko> if a team has no ML and is subscribed to a bug, all team members get bugmail, right?
[15:18] <kiko> I'm sure that's how it us
[15:18] <kiko> ed to be, at least
[15:18] <kiko> and is there a piece of documentation that says that
[15:19] <henninge> kiko: I thought so, too.
[15:19] <kiko> thanks henninge
[15:19] <henninge> adeuring: do you know for sure?
[15:19] <henninge> dunno about documentation, though.
[15:20] <adeuring> kiko, henninge, yes, that's how I remember it: all team members are subscribed
[15:22] <beuno> wasn't it if no contact email was set, all members got bugmail?
[15:24] <kiko> right
[15:26] <bigjools> it's correct, as we found out recently when removing the contact for the reviewers list
[17:11] <shadeslayer> hi, could someone move https://code.launchpad.net/~neon/project-neon/calligra to this project : https://launchpad.net/calligra ?
[18:03] <Darxus> SpamAssassin has an extensive set of tests run by "make test", which do not appear to be run by the Debian/Ubuntu packaging.  Is there... a policy against running make test in package builds?  Seems like it would be a good idea for automated daily builds.
[19:02] <maxb> Darxus: No, there is no such policy. However, you seem a little confused, as the Debian/Ubuntu packaging is not automated daily builds, as you imply. Also, #launchpad isn't directly related to your question.
[19:42] <Darxus> maxb: Launchpad automated daily builds:  https://launchpad.net/~darxus/+archive/spamassassin-daily
[19:45] <Darxus> I guess that wasn't the most relevant url, this is better, a daily build recipe:  https://code.launchpad.net/~spamassassin/+recipe/spamassassin-daily
[20:43] <ahasenack> hi, PPAs always require the uploads to be done against the "RELEASE" pocket? Not <distro>-proposed, for example?
[20:43] <ahasenack> I want to test a debdiff build, for an sru
[20:43] <ahasenack> so I need to change it to be, say, maverick, instead of maverick-proposed, just so the ppa will build it?
[20:45] <micahg> ahasenack: no, you can modify your ~/.dput.cf  file
[20:45] <ahasenack> micahg: how?
[20:46] <micahg> ahasenack: https://help.launchpad.net/Packaging/PPA/Uploading#Using%20packages%20from%20other%20distributions
[20:47] <ahasenack> micahg: what's the "ubuntu suite", the distro name?
[20:48] <micahg> ahasenack: yeah, maverick in your example
[20:48] <ahasenack> micahg: so I would be able to keep maverick-proposed in the changelog?
[20:49] <micahg> ahasenack: correct
[20:49] <ahasenack> micahg: and for natty, oneirick, lucid, hardy, can I have new sections in dput.cf or do I need to change it everytime?
[20:49] <ahasenack> better specifying a different dput.cf each time I suppose?
[20:49] <micahg> ahasenack: you can have new sections
[20:50] <ahasenack> ok, got i
[20:50] <ahasenack> it
[21:07] <ahasenack> hi guys, I'm getting this rejection when uploading to a ppa: "File smart_1.3-2.diff.gz already exists in smart-512302, but uploaded version has different contents. " The help site didn't mention this error
[21:07] <ahasenack> I uploaded 4 sources.changes files, for 4 distros
[21:07] <ahasenack> it failed for two with this error
[21:07] <ahasenack> the package happens to have the exact version/release in both of the distros where it failed
[21:08] <ahasenack> but the changelog is different of course. Is this taken into account?
[21:09] <micahg> ahasenack: you can't upload the same version twice
[21:09] <ahasenack> micahg: but it's for different distros
[21:09] <micahg> ahasenack: doesn't matter, it's one archive, you need to add something like ~lucid1 or ~lucid~ppa1
[21:12] <ahasenack> hmm, as expected, the hardest part of an sru is not the code fix, but naming the package
[21:13] <micahg> ahasenack: SRUs need separate versions as well
[21:13] <ahasenack> micahg: what should I call it? in natty, for example, the released package is 1.3-1.3build1
[21:13] <ikonia> hey guys, how can you you rennew your membership in a team when it's coming up for renewall/expireation
[21:14] <ahasenack> micahg: I was using 1.3-2
[21:14] <micahg> ahasenack: can you hop in #ubuntu-devel please?
[21:14] <ahasenack> micahg: sure, sorry about asking this in the wrong channel