[00:06] <yofel> hey, how long does it usually take for packages to be published? The package here already waits 10h to be published https://edge.launchpad.net/~neon/+archive/ppa/+packages
[00:07] <wgrant> yofel: It should be done within 5 minutes.
[00:07] <wgrant> Let's see.
[00:07] <Quintasan> yofel: I was about to ask that
[00:07] <yofel> Quintasan: beat you :P
[00:15] <wgrant> yofel: Can you visit https://launchpad.net/~neon/+archive/ppa/+edit and confirm that the 'Publish' setting is checked?
[00:16] <yofel> Quintasan: ^
[00:17] <Quintasan> ahh
[00:17] <Quintasan> solved
[00:17] <Quintasan> wgrant: thanks
[00:18] <wgrant> I really need to convince people that we should remove that checkbox.
[00:19] <wgrant> it doesn't make sense for users to have access to it.
[00:21] <Quintasan> well
[00:21] <Quintasan> I can only agree on that
[00:26] <MTecknology> wgrant: You ever have a day where you've done a whole lot of work - but got nowhere?
[00:27] <wgrant> MTecknology: Regrettably so.
[00:27] <MTecknology> wgrant: All I can think about is going to the bar - but I don't go there so it wouldn't make sense...
[00:27] <MTecknology> wgrant: you happen to know much about recipes?
[00:28] <wgrant> MTecknology: A bit.
[00:28] <wgrant> Why?
[00:29] <MTecknology> wgrant: I've been fighting them and maybe I'm missing some dumb thing
[00:31] <MTecknology> wgrant: I have this recipe that works perfect locally - http://paste.ubuntu.com/467253/ - but a recipe in LP can't use run
[00:32] <rinze> MTecknology: Couldn't you just use merge for the debian changes?
[00:32] <MTecknology> rinze: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[00:33] <wgrant> Give them a common ancestor.
[00:33] <MTecknology> how?
[00:33] <wgrant> Base your packaging changes branch on your normal branch.
[00:34] <MTecknology> Any chance you could hold my hand a wee bit on this one?
[00:35] <MTecknology> as if it hasn't been held enough....
[00:35] <wgrant> MTecknology: Why isn't lp:~nginx/ninx/debian-changes-0.8 based on lp:~nginx/ninx/debian?
[00:35] <wgrant> If it was, you could just merge it in.
[00:36] <MTecknology> I couldn't figure out how to base it on the branch
[00:36] <wgrant> bzr branch lp:~nginx/ninx/debian debian-changes-0.8
[00:36] <wgrant> Make the changes.
[00:36] <wgrant> Commit.
[00:36] <wgrant> Push.
[00:37] <MTecknology> and if I only want to maintain the one file in that branch?
[00:37] <wgrant> Why would you want to do that?
[00:38] <MTecknology> the more I think about that - the more it sounds like a better idea
[00:38] <MTecknology> I'll do that
[00:41] <spiv> Incidentally, I'm working on a change to recipes to allow merging files/directories from unrelated branches, but I think wgrant's advice here is good even if that work were finished and deployed.
[00:42] <MTecknology> spiv: I'm doing that now and finally clicked why that's a better idea
[00:42] <MTecknology> spiv: and incredibly awesome feature to add :)
[00:46] <MTecknology> wgrant: so I'm taking the lp:~nginx/ninx/debian out of the recipe entirely?
[00:48] <wgrant> MTecknology: It depends.
[00:48] <wgrant> If you leave it in, you'll automatically get changes from that branch.
[00:49] <wgrant> Which is probably what you want.
[00:49] <MTecknology> yup - which is why i thought I didn't need any files other than the ones i was changing
[00:50] <wgrant> Remember that it's a merge, not a clobber.
[00:51] <MTecknology> so it'll look like this instead? http://paste.ubuntu.com/467258/
[00:52] <wgrant> I think so.
[00:53] <MTecknology> I'll try it out...
[00:55] <MTecknology> wgrant: do I love you, no... do I want to buy you a beer... yes
[00:55] <wgrant> Hah.
[00:56] <MTecknology> wgrant: so if they change file xyz my branch will overwrite their change when I do the merge since it's something I changed?
[00:57] <wgrant> MTecknology: It will follow normal bzr merge rules.
[00:57] <wgrant> If you both change the same part of the file, it will conflict.
[00:58] <MTecknology> wgrant: oh... that'll happen every time
[00:58] <wgrant> MTecknology: lp:nginx/ninx/debian changes regularly?
[00:59] <wgrant> It's only your delta relative to lp:nginx/ninx/debian that matters.
[00:59] <MTecknology> wgrant: the file I changed will
[00:59] <MTecknology> I changed a file that they will change
[00:59] <wgrant> Howso?
[00:59] <MTecknology> I'm horrible with understanding merge conflicts so my face blanks
[01:00] <MTecknology> changelog and a couple others that will be less frequently changed
[01:00] <wgrant> You shouldn't be modifying the changleog.
[01:00] <wgrant> bzr-builder does that for you.
[01:01] <MTecknology> except that it won't handle if your building a different version with the same changelog
[01:01] <wgrant> Hm?
[01:02] <MTecknology> there's stable 0.7.x and development 0.8.x - both can use the exact same debian/
[01:03] <wgrant> But bzr-builder handles the new changelog entry for you.
[01:04] <MTecknology> how do I assign it the right version?
[01:04] <wgrant> MTecknology: The deb-version bit in the first line of the recipe.
[01:05] <MTecknology> wgrant: I'd very much rather not have to change that for every single build but... doesn't sound like I have the choice
[01:05] <spiv> MTecknology: the deb-version can include things like {revno}
[01:06] <spiv> So you shouldn't have to change it every single build.
[01:06] <wgrant> Exactly.
[01:06] <MTecknology> spiv: the version will change with every build
[01:06] <wgrant> It'd be fairly useless for daily builds otherwise.
[01:07] <wgrant> MTecknology: What do you mean?
[01:07] <MTecknology> the branches will only change with new versions
[01:07] <wgrant> As in new stable releases?
[01:07] <MTecknology> yup
[01:08] <wgrant> Hmm. I don't know enough about the version syntax to tell you how to solve that.
[01:08] <wgrant> spiv: Do you know?
[01:09] <MTecknology> wgrant: I was saying earlier that {last_tag:branch_name} would solve this for me
[01:09] <wookey> wgrant: I can see no sign of the file that dpkg-source is whinging about in the uploaded archive
[01:09] <wgrant> wookey: It must be a dpkg bug which has since been fixed.
[01:10] <spiv> wgrant: it just has {revno}, {time}, {revno:BRANCH-NAME} and {debupstream} I think
[01:10] <MTecknology> {debupstream} is what I was trying to get at
[01:10] <MTecknology> that's the exact string I want for 0.7.x
[01:10] <MTecknology> but not for 0.8.x
[01:11] <wookey> hmm, so given that I promised to upload this today, but the pristine source I gave to Debian won;t uplaod to my PPA, what do you suggest I do?
[01:12] <wookey> (the user who wanted it need a version rebuild on maverick because the libvtk is different on ubuntu)
[01:13] <wookey> I can build it on my maverick chroot here but that will produe amd64 packages and he wants i386
[01:14] <MTecknology> spiv: # bzr-builder format 0.2 deb-version {debupstream}-0ppa{revno} <-- I think that's right for 0.7.x - For 0.8.x I would need to have 0.8.34-0ppa{revno} and for every branch upload change the version..
[01:16] <spiv> What's the recipe look like?
[01:16] <MTecknology> https://code.edge.launchpad.net/~nginx/+recipe/nginx-develpment
[01:18] <spiv> Won't the {revno} take care of that already?
[01:19] <MTecknology> spiv: It's the 0.8.34 that I don't like having to change every time I want to make a new build
[01:19] <MTecknology> spiv: I know I'm asking a lot from something that's still very beta..
[01:24] <spiv> MTecknology: oh, I see.
[01:25] <spiv> MTecknology: it would be good to support that, although I'm not sure what a good mechanism for that would be
[01:25] <MTecknology> spiv: last_tag :D
[01:25] <spiv> There's no such concept in bzr.
[01:26] <spiv> "highest" tag, perhaps.
[01:26] <MTecknology> ya, that
[01:26] <spiv> Although that strikes me as pretty fragile, and dependent on details of how projects tag things.
[01:26] <wgrant> I wonder if it could use pristine tar information instead.
[01:27] <spiv> Please file a bug on bzr-builder for this, but the solution isn't obvious to me.
[01:27] <spiv> In the meantime, perhaps just call your package 0.8?  Or 0.8.x if debian allows that...
[01:28] <MTecknology> spiv: maybe you know this one... bug 608450 mentions having a branch you can merge that makes the changes
[01:29] <wgrant> The rationale given there doesn't make sense, AFAICT.
[01:30] <wgrant> We put in an awful lot of work to make sure recipe builds were as secure as PPA builds.
[01:30] <wgrant> And they are.
[01:30] <wgrant> So there's no security risk, unless we evaluate the recipe somewhere else.
[01:30] <spiv> MTecknology: I have a branch intended to permit merging debian/ from a branch with unrelated history
[01:30] <MTecknology> spiv: that one let lets you basically overwrite files?
[01:31] <spiv> MTecknology: no
[01:31] <spiv> But if you know there are files in an existing branch, well make a branch based on the existing branch and merge it in.
[01:31] <MTecknology> wgrant: It's kinda sad because I actually got excited when I maqde it run locally :P
[01:33] <MTecknology> I've also been considering just asking the deb maintainer to just had another svn branch in trunk for 0.8 :P
[01:33] <spiv> My patch is targetted to the 'parallel import' case, where Launchpad has essentially the same project in unrelated branches via code imports and package imports, and you'd like to make a recipe to e.g. package the latest upstream trunk using the same packaging that's already in ubuntu.
[01:33] <MTecknology> that sounds a lot like my use case
[01:34] <wgrant> I don't think it is.
[01:34] <MTecknology> oh
[01:34] <MTecknology> maybe a use case matching what i had in my head
[01:36] <spiv> My patch (currently) adds a 'merge-part' instruction to recipes so that you can specify merging just part of a (possibly unrelated) branch, e.g. 'merge-part debian-from-parallel url://to/branch -1 debian/', IIRC
[01:36] <MTecknology> wgrant: far as the security things goes - I could see the point if rules didn't basically allow you to do the same thing
[01:37] <MTecknology> spiv: nice
[01:37] <wgrant> MTecknology: Right. You can already execute arbitrary code, so the restriction is pointless.
[01:39] <MTecknology> wgrant: I guess this is just part of workign out the kinks :P
[01:41] <MTecknology> It's 19:40 and I got here at 07:40... I should continue working from home..
[02:45] <MTecknology> wgrant: so.. I just emailed upstream about making a debian-dev - we'll see if she's up for that
[03:20] <tcr> Can I cross-reference a bug in project FOO in a bug report to a project BAR? If so, how?
[03:21] <wgrant> tcr: So, it depends on how the bugs are related. Do you have two in particular for this case?
[03:22] <spiv> What do you mean by cross-reference, exactly?  As a minimal option, you can write "See also bug 999999" in a comment, and it will be automatically hyperlinked.
[03:23] <tcr> spiv: The numbers are universally unique? I'd have thought they're unique per project only?
[03:23] <wgrant> No, they're universally unique.
[03:23] <thiebaude> I had my account suspended, how do i find out why it was?
[03:23] <tcr> Oh that's cool, and news to me.
[03:23] <wgrant> Unless your project has 600000 bugs. :)
[03:23] <thiebaude> launchpad account
[03:23] <spm> thiebaude: which account?
[03:23] <thiebaude> lauchpad
[03:23] <thiebaude> launchpad
[03:23] <spm> thiebaude: no :-) what was the name of it.
[03:24] <tcr> spiv: That's all I wanted. Thanks
[03:24] <wgrant> launchpad.net/~thiebaude?
[03:24] <thiebaude> ok let me check 1 sec
[03:25] <thiebaude> yes it is thiebaude
[03:27] <spm> thiebaude: ok, apparently your account was being abused to send spam back in April; and was duly suspended.
[03:28] <thiebaude> can i get it back
[03:28] <thiebaude> since i did't spam
[03:30] <spm> thiebaude: I didn't mean to imply _you_ had; only that your account was. possibly your PC was trojaned or similar. You ain't the first, won't be the last.
[03:30] <thiebaude> ok thanks for that info:)
[03:30] <thiebaude> spm
[03:30] <thiebaude> i understand
[03:31] <thiebaude> what is the next step for me to get the account back?
[03:31] <spm> thiebaude: I've reactivated it; but you'll need to go thru the 'forgotten password' steps
[03:32] <thiebaude> spm ,ok thanks i sure will, and thank you for helping me:)
[03:33] <spm> np :-)
[03:33] <thiebaude> tc
[04:34] <Muscovy> Is it possible to add icons and screenshots to thing in my PPA for the software centre?
[04:38] <wgrant> Muscovy: Not at the moment. But I believe the Software Center people are working on that sort of thing.
[04:46] <Muscovy> Ok, thanks.
[05:23] <MTecknology> spm: whois says you're around - any chance you could make me blink with joy?
[05:47] <thumper> MTecknology: whazzup?
[05:48] <MTecknology> thumper: I was hoping for a peak at an answer request
[05:48] <thumper> MTecknology: ah
[05:48] <MTecknology> thumper: Are you an LP admin?
[05:49] <thumper> MTecknology: alas, no
[05:49] <MTecknology> Seems there used to be a lot more than there are now
[05:50] <thumper> MTecknology: no... not really
[05:50] <MTecknology> oh, then my mind fooled me in the past :P
[05:51] <wgrant> There were, but not for a few years now.
[05:52] <MTecknology> I've been using LP for a while now.. I can vaguely name a few I was pretty sure were on the list - back when I called 'em all rubber duckies
[05:53] <MTecknology> so.. what is the limit on number of times you can build a package for each release in a day?
[05:54] <wgrant> 5, I believe.
[05:54] <wgrant> It is a stupid restriction.
[05:55] <MTecknology> oh.. I thought I did a lot more than 5 today - I wasn't surprised to hit it :P
[06:35] <spm> there's a restriction on #builds of a package? huh. didn't know that one.
[06:36] <wgrant> spm: There's a new restriction on the number of builds per day of a recipe for each series.
[06:36] <wgrant> It is the only such arbitrary limit in Launchpad, I believe.
[06:36] <spm> Ahh I see. I'm aware of the new recipe stuff, but don't know too much about it unf.
[06:37] <wgrant> Except for the PPA disk quota, I guess.
[06:37] <spm> that one does make sense in a 'please clean up what you *really* want from what you don't; then ask for more' sense.
[07:41] <james_w> MTecknology: please file bugs on bzr-builder with your requests
[08:00] <mistrynitesh> https://help.launchpad.net/ReadingOpenPgpMail recommends using FireGPG for reading openpgp mails on Gmail. However, the FireGPG project is discontinued and the software no longer supports gmail
[08:01] <mistrynitesh> is this the correct channel to report this?
[08:04] <thumper> mistrynitesh: yeak
[08:05] <thumper> mistrynitesh: there has been some recent work on email authentication using DKIM (I think that's right)
[08:05] <thumper> mistrynitesh: so that may mean that email from gmail will be trusted as if it was signed
[08:05] <lifeless> yes
[08:06]  * thumper just noticed the typo above
[08:06] <thumper> s/yeak/yes/
[08:06] <thumper> although I probably was going to say yeah
[08:06] <thumper> ak isn't anywhere near s
[08:06] <wgrant> thumper: It's actually landed.
[08:07] <wgrant> So 10.08 will automatically verify emails from Gmail.
[08:07] <thumper> wgrant: but probably not live yet
[08:07] <wgrant> Right.
[08:07] <thumper> wgrant: how goes the new semester?
[08:07] <thumper> last one right?
[08:07] <thumper> lifeless: morning, you there for the entire week?
[08:08] <mistrynitesh> thumper: i did not understand what you meant by "email from gmail will be trusted as if it was signed"
[08:09] <lifeless> thumper: yea, GHM in den hag on the weekend then home on monday, get in wed
[08:09] <thumper> mistrynitesh: sorry I misread your initial question
[08:09] <thumper> mistrynitesh: is the email signed or encrypted?
[08:09] <mistrynitesh> encrypted
[08:10] <mistrynitesh> so I had to copy the mail to a text file and then read it on command line
[08:10] <thumper> I don't know an answer, perhaps a more general firefox forum could help
[08:10] <thumper> morning jtv
[08:10] <jtv> hi thumper
[08:10] <jtv> you going to Den Haag then?
[08:10] <mistrynitesh> sure, what I wanted to report is that the help page on launchpad should be updated with this development
[08:11] <thumper> mistrynitesh: ok, thanks
[08:11] <wgrant> thumper: It starts Monday. And yes, it's the last one.
[08:11] <wgrant> Then I have to find something to do.
[08:11] <lifeless> jtv: thumper is in NZ again already
[08:11] <jtv> ah
[08:13]  * thumper wanders off
[12:19] <Quintasan> james_w, wgrant, maxb: can something be done about that import -> https://code.edge.launchpad.net/~vcs-imports/kdelibs/kde4 failing?
[12:21] <maxb> Quintasan: Only by someone first fixing bug 579491
[12:21] <shadeslayer> hi i would like to know if theres a way to make https://code.edge.launchpad.net/~vcs-imports/kdelibs/kde4 work
 james_w, wgrant, maxb: can something be done about that import -> https://code.edge.launchpad.net/~vcs-imports/kdelibs/kde4 failing?
 Quintasan: Only by someone first fixing bug 579491
[12:22] <shadeslayer> ah..
[12:22] <shadeslayer> i see Quintasan already asked :D
[12:22] <wgrant> You two seem to come in pairs :P
[12:22] <Quintasan> well, we want Project Neon to move since I figured out how to build Qt :P
[12:22] <shadeslayer> wgrant: were trying to get project Neon up and working
[12:23] <Quintasan> shadeslayer: wut, I'm the spokesperson for our project :P
[12:23] <geser> wgrant: perhaps the idea is: if more people ask then it seems to be important and more likely to get fixed. would that work?
[12:23]  * shadeslayer thought it was a collaborative effort :(
[12:24] <Quintasan> shadeslayer: yeah, but repeating the same sentence over again won't help :P
[12:24] <yofel> well, let's increase the 'affects' count a bit in any case...
[12:24] <shadeslayer> Quintasan: i didnt know you asked ^_^
[12:25] <yofel> shadeslayer: http://paste.ubuntu.com/467466/
[12:26] <shadeslayer> ok :P
[12:41] <shadeslayer> btw how come gitorious.org is not recognized by LP?
[12:42] <wgrant> Not recognised? In what sense?
[12:44] <shadeslayer> wgrant: for eg. when i login with the LP open id , i get a warning saying that gitorious.org is not recognised by launchpad open sign in service
[12:44] <wgrant> I don't know. Ubuntu/Launchpad SSO aren't actually part of Launchpad any more.
[12:45] <shadeslayer> ah ok
[12:45] <wgrant> But it just means it's not been explicitly configured yet.
[12:45] <wgrant> I don't know why it tells you that.
[13:04] <mtaylor> spm: not still up are you?
[13:10] <shadeslayer> merge packaging lp:~bzr/bzr/packaging << whats the role of the word 'packaging' here?
[13:10] <shadeslayer> the first one...
[13:10] <poolie> shadeslayer, is this in a build recipe?
[13:10] <shadeslayer> yes
[13:11] <shadeslayer> im trying it out for rekonq first.. so that i can work on kdelibs
[13:13] <wgrant> shadeslayer: It gives the branch a name in the recipe. You can then say {revno:packaging} in the version string.
[13:14] <shadeslayer> wgrant: ok.. another question then,suppose im merging the 2 branches,and my packaging is in http://bazaar.launchpad.net/~rekonq/rekonq/rekonq-ubuntu/files
[13:15] <shadeslayer> and im using merge packaging lp:~rekonq/rekonq/rekonq-ubuntu
[13:15] <shadeslayer> would that work?
[13:15] <wgrant> That should work, yes.
[13:15] <wgrant> Assuming that the branches have a common ancestor.
[13:15] <shadeslayer> common ancestor? :D
[13:16] <wgrant> rekonq-ubuntu has to be based on the original branch.
[13:17] <shadeslayer> theres no original branch
[13:17] <wgrant> Hm?
[13:18] <wgrant> You're merging the branch into something.
[13:18] <shadeslayer> wgrant: this is the first import of rekonq packaging branch
[13:18] <wgrant> shadeslayer: What is the base branch of your recipe?
[13:18] <shadeslayer> wgrant: none...
[13:18] <shadeslayer> uh
[13:19] <shadeslayer> you mean the initial code import
[13:19] <wgrant> You can't merge into nothing.
[13:19] <wgrant> After the initial recipe header line, there is a branch name.
[13:19] <shadeslayer> ohhh.. one sec
[13:19] <wgrant> Then you have subsequent directives like 'merge blah lp:blah'
[13:20] <wgrant> The base branch is retrieved, then the directives are followed on top of that.
[13:20] <shadeslayer> wgrant: https://code.edge.launchpad.net/~rekonq
[13:20] <shadeslayer> rekonq-ubuntu is packaging and rekonq/trunk is base branch
[13:21] <wgrant> So, that's not going to work.
[13:21] <shadeslayer> ok.. why?
[13:21] <wgrant> rekonq-ubuntu isn't based on trunk.
[13:21] <wgrant> So there's no way to merge them.
[13:22] <wgrant> rekonq-ubuntu appears to be the contents of the debian/ directory?
[13:22] <shadeslayer> YES
[13:22] <shadeslayer> sorry for the caps
[13:22] <wgrant> Why isn't it a full branch, with an added debian/ directory?
[13:23] <shadeslayer> you mean it should be a branch with a debian/ folder and then it should be used?
[13:23] <wgrant> I think you should create a new branch of trunk and throw the debian/ directory in there.
[13:24] <wgrant> That's pretty much how the Ubuntu packaging branches work.
[13:24] <shadeslayer> ohh i see
[13:24] <wgrant> So your packaging branch is a complete extracted Debian source package.
[13:24] <wgrant> It has the application source, and it has the debian directory.
[13:24] <shadeslayer> wgrant: lemme show you something
[13:24] <mtaylor> shadeslayer: http://www.advogato.org/person/robertc/diary/130.html may be helpful
[13:24] <shadeslayer> wgrant: https://code.edge.launchpad.net/~neon
[13:25] <shadeslayer> same thing there... we have qt-ubuntu and qt-trunk
[13:25] <shadeslayer> uh.. qt-kde
[13:26] <shadeslayer> so qt-kde is our intial import
[13:26] <shadeslayer> and qt-ubuntu is our packaging branch
[13:27] <wgrant> Is there a reason you've done in that way?
[13:27] <shadeslayer> wgrant: you would have to ask Quintasan :D
[13:32] <Quintasan> wgrant: well, if there is a debian/ directory inside a branch and nest requires a name of the dir
[13:33] <Quintasan> so it would look like: ./debian/debian/control
[13:33] <wgrant> Quintasan: Why not make the branch look like a source package?
[13:33] <wgrant> Just a branch of trunk, but with the debian/ directory added.
[13:33] <wgrant> Then a plain merge is all that's required; no nest.
[13:34] <shadeslayer> btw is the {date} plugin now available in recipes ?
[13:34] <Quintasan> wgrant: I don't get it, you want me to put debian/ to our kde-qt branch
[13:34] <Quintasan> ?
[13:34] <Quintasan> shadeslayer: date was available all the time O_o
[13:34] <shadeslayer> ah ok
[13:35] <wgrant> Quintasan: No. In a branch of kde-qt.
[13:36] <wgrant> Rather than having qt-ubuntu as a standalone branch, have it be based on qt-kde, but with the added debian/ directory.
[13:36] <Quintasan> and how do I do that?
[13:36] <wgrant> bzr branch qt-kde qt-ubuntu
[13:36] <wgrant> cd qt-ubuntu
[13:36] <wgrant> <copy in packaging>
[13:36] <wgrant> bzr add
[13:37] <wgrant> bzr ci -m "Add packaging."
[13:37] <wgrant> bzr push
[13:37] <shadeslayer> ill bbl
[13:40] <Quintasan> wgrant: and how the daily build will handle this?
[13:41] <wgrant> Quintasan: The recipe that's there at the moment is for this kind of model.
[13:41] <wgrant> It won't work with the qt-ubuntu branch that's up there now.
[13:41] <Quintasan> wgrant: http://pastebin.com/t9XE2wnv
[13:41] <Quintasan> that's the recipe I used to generate qt-kde source tarball
[13:43] <lool> Hey folks
[13:43] <lool> I fucked up
[13:43] <wgrant> Quintasan: Ah. I was looking at a recipe on LP, which has since been deleted.
[13:43] <wgrant> Quintasan: Replace the third line with 'merge debian lp:~neon/project-neon/qt-ubuntu'.
[13:43] <lool> I created a regular project and cant attach it to a project group now; I should have created it under the project group
[13:43] <lool> Would some admin be able to fix that for me?
[13:44] <wgrant> lool: Click 'Change details' on your project.
[13:44] <lool> linaro-toolchain is the meta-project (group) and linaro-toolchain-misc is the project which should be attached to the group
[13:44] <wgrant> Find the 'Part of' field.
[13:44] <lool> wgrant: Gah, thakns
[13:45] <lool> wgrant: worked fine
[13:45] <Quintasan> wgrant: well no need to place debian/ intro source then?
[13:45] <Quintasan> into*
[13:45] <wgrant> Quintasan: debian/ will exist in qt-ubuntu. qt-kde won't have it. So you tell the recipe to merge qt-ubuntu into qt-kde.
[13:46] <Quintasan> great
[13:46] <wgrant> That way you get the latest code from qt-kde, and the debian/ directory from qt-ubuntu.
[13:58] <Quintasan> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[13:58] <Quintasan> wgrant: ^
[13:58] <wgrant> Quintasan: Sounds like you didn't branch qt-ubuntu from qt-kde...
[13:59] <ttx> from #openstack: <jonesy> you know, from an end-user perspective (someone looking for info or code for a project they're interested in), I've never liked launchpad, but I just did a merge proposal, and it was one of the easiest experiences I've had outside of maybe github.
[14:00] <poolie> nice :)
[14:00] <poolie> now let's fix the other bits
[14:00] <wgrant> Well, some UI design might help...
[14:36] <Quintasan> GRR
[14:38] <Quintasan> wgrant: I have qt-kde (Qt source code) and qt-ubuntu (contains debian/) directories sitting in my home, doing bzr branch qt-kde qt-ubuntu = bzr: ERROR: Target directory "qt-ubuntu" already exists. and --use-existing-dir yields me error that qt-ubuntu is already a branch
[15:05] <ocatacoo> I keep getting bug reports sent to me from launchpad and see no way to stop them or unsubscribe what should I do to unsubscribe from them
[15:07] <Meths> Are you receiving updates on one bug or lots of bugs for a project?
[15:07] <jelmer> ocatacoo: the last line of the email should explain why you are receiving the email.
[15:07] <jtv> ocatacoo: there should be an explanation of how you're subscribed at the bottom of each email.
[15:08] <ocatacoo> You received this bug notification because you are subscribed to
[15:08] <ocatacoo> Hardware Certification.
[15:08] <shadeslayer> thats why :)
[15:08] <ocatacoo> but I am not subscribed
[15:08] <shadeslayer> ocatacoo: un-subscribe from the h/w certification team/ML
[15:10] <ocatacoo> thats not the bug kist but I am not subscribed to them either and not getting from the mailing list anyway
[15:11] <Meths> ocatacoo: Have you been to https://bugs.launchpad.net/hardware-certification  to check what subscription options you get in the right-hand menu?
[15:13] <shadeslayer> hi im getting this FBTFS with LP recipes http://launchpadlibrarian.net/52316355/buildlog.txt.gz
[15:13] <shadeslayer> and i have no idea what it means... ive never seen that error before
[15:14] <ocatacoo> it shows that I can subscribe
[15:14] <maxb> shadeslayer: I believe it means recipe builds are completely broken on maverick owing to changes in the default package seeding which no longer include aptitude in the chroot
[15:15] <Quintasan> :/
[15:15] <shadeslayer> hmm...
[15:15] <Quintasan> maxb: about that import bug, do you have someone working on it or you lack information?
[15:15] <shadeslayer> maxb: how can we fix this?
[15:15] <ocatacoo> hardware cert doesnt have a mailing list that I can find anyway
[15:16] <maxb> Quintasan: You sound like you think I'm officially associated with Launchpad :-)  I'm not.
[15:16] <maxb> shadeslayer: I've not looked into it in detail, but I imagine the proper fix is to fix pbuilder to not assume aptitude is part of the base chroto
[15:18] <Quintasan> maxb: Well, you're running around answering everything, I assumed you are in some way :P
[15:18]  * maxb afk
[15:18] <jelmer> Quintasan: Hi
[15:18] <Quintasan> jelmer: um, hello
[15:19] <jelmer> Quintasan: what are you trying to do exactly?
[15:19] <jelmer> Quintasan: it sounds like you're trying to clone a branch to a location where a branch already exists
[15:20] <Quintasan> jelmer: doesn't matter now, I'm not going to copy 300mb source tree just to replace a nest line with merge
[15:20] <Quintasan> not worth it
[15:20] <ocatacoo> so where do I need to ask to unsubscribe?
[15:22] <jtv> ocatacoo: gmb may be able to help
[15:22] <ocatacoo> jtv, ? whatis gmb ?
[15:22] <jelmer> Quintasan: I think "bzr join" does what you were looking for, if you ever need it later
[15:23] <jelmer> ocatacoo: he's a Launchpad engineer, gmb is his nickname on IRC :-)
[15:23] <jtv> ocatacoo: gmb is someone who may show up now that his name's been dropped :-)
[15:23] <jelmer> shadeslayer: What is the related recipe?
[15:24] <shadeslayer> jelmer: for rekonq?
[15:24] <jelmer> shadeslayer: yeah - is that for which you just pasted the FTBS log?
[15:25] <shadeslayer> yes one sec
[15:25] <shadeslayer> jelmer: https://code.edge.launchpad.net/~rekonq
[15:25] <shadeslayer> everything is there
[15:26] <shadeslayer> rekonq-ubuntu is packaging branch
[15:27] <bigjools> shadeslayer: you probably need to add a build-depend on aptitude
[15:30] <abentley> bigjools, I don't think that will work, pbuilder satisfies those depends, so pbuilder will already be running before aptitude is installed.
[15:39] <ocatacoo> jtv: I contacted him through launchpad , I just didnt want to file a bug because of something so trivial
[15:40] <jelmer> abentley: it also should be up to the user to install aptitude because pbuilder happens to use it
[15:40] <jelmer> has the dependency on aptitude in maverick perhaps been changed from Depends to Recommends?
[15:40] <jelmer> the dependency of pbuilder on aptitude I mean
[15:41] <jelmer> abentley, bigjools: Yeah, that looks like it:
[15:41] <abentley> jelmer, pbuilder never had a dependency on aptitude, but aptitude used to be in base.
[15:41] <jtv> ocatacoo: you can also file a question under Answers
[15:42] <jtv> ocatacoo: if it turns out to be really a bug, the question can be turned into one—although of course usually that's not the case
[15:42] <abentley> jelmer, the choice to use pbuilder is not the user's, so it shouldn't be up to the user to install aptitude.
[15:42] <jelmer> abentley: It seems strange that it doesn't even recommend or suggest it even though it can generate scripts that use it.
[15:42] <jelmer> abentley: Argh - that's what I meant to say, sorry
[15:43] <jelmer> missing negation in that sentence
[15:43] <abentley> jelmer, yes, bugs have been filed about the lack of a dependency.  However, when used as directed, AIUI, pbuilder's lack of a dependency is not a problem.
[15:44] <ocatacoo> jtv: thank you I am sure that I just don't see something that I should , but I have looked , just obviously not in the right place...
[15:44] <jelmer> abentley: ah, ok
[15:44] <abentley> jelmer, because the scripts install aptitude in the chroot and then run scripts in the chroot.
[15:44] <jelmer> abentley: Ahh, of course
[15:44] <jelmer> abentley: Please ignore me :-)
[15:45] <jtv> ocatacoo: it's not always easy with so many ways to get subscribed to something...  I do know for a fact that it must be some kind of direct subscription in your case.  If it were indirect (i.e. because you're a member of a team that's subscribed) then the message would say so.
[15:45] <jtv> ocatacoo: you're not registered as a bug reporting contact or somesuch either?
[15:47] <ocatacoo> not that I can see but ...?
[15:49] <shadeslayer> btw any idea if the svn import plugin will be fixed?
[15:49] <ocatacoo> Have a good day...
[15:49] <maxb> Fixed in what way? the kdelibs thing?
[15:49] <shadeslayer> maxb: yeah :(
[15:49] <shadeslayer> were stalled for now
[15:49] <maxb> I gave the bug number. You can look at the history of it there.
[15:49] <maxb> Or maybe even try your hand at fixing it :-)
[15:50] <shadeslayer> if only i knew python ^_^
[15:50] <jelmer> I know how to fix it, I just haven't had the time to spend on doing so.
[15:51] <shadeslayer> jelmer: oh please please please fix it :D
[15:51] <shadeslayer> ill send you cookies
[15:53] <jelmer> (-:
[15:53] <shadeslayer> also.. pbuilder needs fixing :/
[15:54] <shadeslayer> btw how come Quintasan's Qt build went through but not my build?
[15:54] <jelmer> shadeslayer: Was he perhaps building for Lucid?
[15:54] <shadeslayer> jelmer: nope..karmic build
[15:55] <jelmer> shadeslayer: Ah, still.. karmic and lucid had aptitude in base, maverick doesn't
[15:55] <shadeslayer> uh
[15:55] <jelmer> IIUC
[15:55] <shadeslayer> jelmer: s/karmic/maverick
[15:55] <jelmer> shadeslayer: No idea then..
[15:55] <jelmer> abentley: do you know perhaps?
[15:56] <abentley> jelmer, know what?
[15:57] <shadeslayer> abentley: why rekonq is FTBFS in maverick while Qt builds fine
[15:58] <abentley> shadeslayer, not yet.  Can you give me some build URLs?
[15:58] <shadeslayer> sure
[15:58] <shadeslayer> abentley: https://code.edge.launchpad.net/~rohangarg/+recipe/rekonq-daily/+build/402
[15:58] <shadeslayer> thats rekonq FTBFS
[15:58] <shadeslayer> which is due to aptitude not being in the base ubuntu chroot
[15:59] <shadeslayer> abentley: http://launchpadlibrarian.net/52262923/buildlog_ubuntu-maverick-amd64.project-neon-qt_1.0%2B1200~ppa1_FULLYBUILT.txt.gz
[15:59] <shadeslayer> thats Qt being built fine
[16:00] <abentley> shadeslayer, that looks like a binary build.
[16:00] <shadeslayer> abentley: binary build? Quintasan ^^
[16:01] <MTecknology> james_w: for being able to use 'run' I filed one and it was marked invalid - I'll add a bug for the latesttag
[16:17] <james_w> MTecknology: thanks
[16:38] <MTecknology> mthaddon: You renamed ninx to nginx but I still see "Bazaar branches of Ninx" :S
[16:41] <mthaddon> MTecknology: ok, fixed
[16:42] <sense> Could someone help me to merge the imported account 'sense-ubuntu' into 'sense'? I've tried several times, but it timed out each time. The latest Error ID is OOPS-1664ED1753. I need to merge before I can get my new email address to associate with my account.
[16:43] <MTecknology> mthaddon: was it just an easy to set variable?
[16:43] <mthaddon> yep
[16:44] <MTecknology> cool
[16:44] <MTecknology> mthaddon: oh, that stuff was removed if you want to disable the other one :)
[16:45] <mthaddon> MTecknology: ok, done
[16:46] <maxb> Either the PPA publisher is getting slower or I'm getting more impatient
[16:46] <bigjools> it's slower than it used to be :(
[20:19] <romaia> hello, who should I talk to about the ppa builder?
[20:19] <romaia> two of my build seen to have entered a loop
[20:19] <romaia> https://launchpad.net/~stoq-maintainers/+archive/unstable/+build/1885729
[20:20] <romaia> kiko,  ^
[20:21] <shadeslayer> romaia: entered a loop?
[20:21] <shadeslayer> romaia: the one you posted just started
[20:21] <romaia> shadeslayer, yes,
[20:21] <shadeslayer> +building
[20:21] <romaia> shadeslayer, try reloading the page.
[20:21] <romaia> the time counter restarts a few times,
[20:21] <romaia> than the status go back to queued
[20:22] <romaia> it has been like for amount an hour.
[20:23] <shadeslayer> mmm
[20:23] <shadeslayer> its back to started 7 secs ago
[20:23] <shadeslayer> something is wrong it seems
[20:23] <romaia> https://launchpad.net/~stoq-maintainers/+archive/unstable/+build/1885704
[20:23] <romaia> this one as well
[20:27] <matsubara> StevenK, hey, could you take a look at the issue ^ please? anything wrong with the builder?
[20:27] <shadeslayer> romaia: the second one seems to be fixed
[20:27] <romaia> shadeslayer, yes.
[20:27] <shadeslayer> and the first one is now building
[20:29] <romaia> shadeslayer, any idea what happend?
[20:29] <romaia> is it worth filling a bug?
[20:29] <shadeslayer> romaia: a) temporary issue b) someone fixed it
[20:29] <shadeslayer> romaia: nah...
[20:29] <shadeslayer> but if it makes you feel good,go ahead :P
[20:30] <romaia> if it happens again...
[20:30] <romaia> maybe it has something to do with the fact that I pressed the force rebuild button.
[20:31] <romaia> shadeslayer, thanks anyway
[20:31] <shadeslayer> romaia: :D
[21:36] <MTecknology> What's going on here?    bzr branch lp:~nginx/nginx/debian.mod_wsgi   bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~nginx/ninx/0.8/".
[21:39] <MTecknology> oh!
[21:40] <MTecknology> lifeless: how can I unstack a branch?
[21:41] <romaia> bzr reconfigure --unstacked
[21:41] <MTecknology> thanks
[21:41]  * MTecknology corsses fingers
[21:42] <MTecknology> romaia: that's generating the same error - any ides how I can fix it - the project was renamed so the branch it was stacked on is gone
[21:43] <romaia> MTecknology, sorry, no idea.
[21:43] <romaia> I just know the unstacked commands since I use it quite often
[21:44] <MTecknology> I rarely use it but was hoping that'd be the ticket - I suppose it need sot know what it's stacked against before it can unstack though
[21:46] <MTecknology> Looks like the guys that can fix it are in a meeting
[21:47] <MTecknology> mthaddon: when you're back from your meeting could you take a peak at this?