[07:37] <vila> hello all !
[07:42] <wgz> morninh vila
[07:43] <vila> wgz: hey !
[08:50] <poolie> vila, hi
[08:50] <vila> poolie: hey !
[10:14] <mgz> morning
[11:48] <hno> how do I show the complete log messages of pending merges (merged but not yet committed)?
[11:48] <quicksilver> bzr st -v
[11:48] <quicksilver> ?
[11:48] <hno> that gives the first line only.
[11:50] <quicksilver> hno: good question.
[11:54] <jelmer> hno: I'm not entirely sure how to do that either; 'bzr qlog' can show that info
[11:57] <hno> jelmer, qlog can show uncommitted log info?
[11:58] <jelmer> hno: yep, by default it will do so
[12:13] <quicksilver> when your GUI tool can access information the commandline tools cannot, something has gone wrong with the abstraction layers ;)
[12:17] <jelmer> quicksilver: :)
[12:17] <jelmer> quicksilver: it's all exposed in the API, mostly just not exposed through the cli frontend
[12:20] <quicksilver> yes, I recognise that
[12:20] <quicksilver> so I didn't really phrase my objection correctly
[12:21] <quicksilver> but in an ideal world the CLI client would, by definition, expose all the API functionality
[12:21] <quicksilver> so shell script hackers can cobble together workflows
[12:21] <quicksilver> maybe such people should just be python hackers.
[12:21] <mgz> ...an ideal world consists of shell scripts cobbled together?
[12:22] <jelmer> quicksilver: well, it is somewhat exposed
[12:22] <quicksilver> almost
[12:22] <jelmer> you can do "bzr st --show-ids" and then feed the resulting revision id into "bzr log -rrevid:REVID"
[12:22] <jelmer> that's basically what qlog does, except it does it for you and in a graphically more pleasing way
[12:22] <quicksilver> mgz: an ideal world consists of shell scripts joined orchestrated by fragments of elisp.
[12:22] <quicksilver> jelmer: hmm, yes. Good!
[15:19] <abentley> jelmer: daily builds of pqm are broken, but I can't even see what when wrong this time: https://code.launchpad.net/~bzr/+recipe/bzr-pqm-daily
[15:20] <abentley> jelmer: Ah, looks like someone forced builds.
[15:31] <jelmer> abentley: I don't think that happens just on forced builds
[15:31] <jelmer> it also happens when the PPA queue is backlogged I think
[15:31] <abentley> jelmer: I hadn't heard of that.
[15:32] <jelmer> I've seen it happen quite regularly
[15:54] <abentley> jelmer: Okay, we should probably fix it to drop identical requests.
[16:23] <lamalex> is there a means for reverting the changes introduced in a previous commit?
[16:24] <LeoNerd> merge backwards? replay backwards? uncommit?
[16:24] <LeoNerd> pull from a previous version?
[16:25] <jelmer> :q
[16:26] <mgz> LeoNerd: in other words, lots of ways :)
[16:27] <mgz> you probably want, to eg revert all changes introduced in revision 3, `bzr merge -r3..2`
[16:27] <mgz> lamalex: ^
[16:27] <lamalex> indeed, that's what i was looking for. i can never remember how the -r argument works
[16:28] <mgz> merging the reverse of a rev does take a little mental leap
[16:30] <jelmer> mgz: I think we should have a somewhat easier way to do this, it's a question that comes up quite regularly
[16:42] <quicksilver> I normally go for bzr revert -r2; bzr commit -m "Reverting back to state of code from revision 2"
[16:42] <quicksilver> is the merge version better?
[16:43] <quicksilver> unless I do it before anyone cares about the history, in which case I go for bzr push --overwrite ;)
[16:44] <mgz> well, the problem is there really are a bunch of different things people will want
[16:44] <mgz> I'm not sure how well it'd boil down to a new friendlier command
[16:45] <mgz> your revert method quicksilver is no good when there have been subsequent changes
[16:45] <quicksilver> oh, I see "un-cherry-pick"
[16:46] <LeoNerd> Surely cherry-unpick ?
[16:46] <mgz> and reverse merging a revision also may not be the right thing if you want to reinclude that change later
[16:46] <jelmer> quicksilver: yeah, 'bzr merge --reverse -c -4'
[16:46] <quicksilver> yes, I normally start with  bzr diff -r2..3 | patch -p0 and then fiddle things until that works
[16:46] <quicksilver> but I know vaguely that merge is better because of things diff can't represent.
[16:47] <quicksilver> (why isn't there yet a recognised successor to diff for things which diff can't represent?)
[17:32] <smoser> so what is the correct "UDD" way to store quilt 3.0 ubuntu branches ?
[17:33] <jelmer> smoser: what do you mean with UDD in this context? for recipe usage?
[17:33] <smoser> no
[17:33] <smoser> separate.
[17:33] <jelmer> UDD doesn't have anything special for quilt branches at the moment
[17:33] <smoser> i have a package (euca2ools) that i previously managed quilt 3.0 and basically tried to force ignoraing of .pc in in version control
[17:33] <jelmer> there has been talk about using bzr-looms to represent quilt packages
[17:34] <smoser> i thought aht i had see barry mention improved behavior for quilt 3.0 branches somewhere.
[17:34] <jelmer> yeah, newer versions of bzr-builddeb have improved support for merging branches that contain quilt patches
[17:35] <smoser> ah.
[17:35] <smoser> ok.
[17:35] <smoser> so maybe i should just give up and let .pc be versioned
[17:35] <smoser> i reallydislike that 'bzr diff' shows you diff of .pc files
[17:36] <smoser> oh, and thakn you for your help on my recipe on mailing list also
[17:36] <jelmer> personally, I keep patches unapplied for quilt packages that I maintain and I don't version the .pc directory
[17:37] <jelmer> smoser: I guess it wouldn't be too hard to get 'bzr diff' to ignore changes under .pc/
[17:37] <smoser> but then you can't rely on the importer to do that for you
[17:38] <smoser> if you bzrignore the .pc
[17:38] <smoser> each time it does the import for you, it screws things up
[17:38] <smoser> at least i couldn't (iirc) cget it to actually respect my .bzrignore
[17:38] <jelmer> it doesn't, as the contents of the udd branch is supposed to reflect what's in the archive
[17:39] <smoser> right. so then i had to remmeber to push there each time.
[17:39] <smoser> and if someone else uploaded...
[17:39] <smoser> then issues.
[17:39] <smoser> so i didn't like that
[17:39] <smoser> i was hoping there was somethign better now.
[17:40] <jelmer> there have been improvements with regard to quilt, but that's all related to merging of branches containing quilt
[17:40] <jelmer> not with regard to the importer
[17:40] <jelmer> personally, I think udd branches shouldn't have the quilt patches applied by default; that's hard to change now though
[17:41] <smoser> i think i agree with you on that.
[17:42] <smoser> but its just a pain if osmeone else updates and uploads
[17:42] <smoser> then i ended up with broken importer i think.
[17:42] <smoser> i dont know.
[17:42] <smoser> it seemede like no easy way to get what i wanted
[17:42] <smoser> so i'm apt to stop fighting bots
[17:42] <jelmer> smoser: in what way is it a pain?
[17:42] <jelmer> just because of the noise in 'bzr diff' ?
[17:43] <smoser> i guess that was my largestt grevence.
[17:43] <smoser> s/bad spelling/good spelling/
[17:44] <jelmer> smoser: can you perhaps file a bug about that against bzr-builddeb?
[17:44] <smoser> how would htat be a builddeb bug ?
[17:44] <smoser> oh. does it have hooks. on 'bzr diff' ?
[17:45] <jelmer> yeah, bzr-builddeb lso has the various hooks to improve the merging of branches that contain quilts
[17:55] <smoser> jelmer, i think i'm not going to open a bug.
[17:55] <smoser> its not straight forward
[17:55] <smoser> bcause sometimes you'd wan tot see the .pc files in diff
[17:55] <smoser> sometimes you wouldn't
[17:57] <smoser> jelmer, there is no way to tell the importer that it should not store patch files applied, is there ?
[17:58] <jelmer> smoser: I don't think you would ever want to see them, as long as they're consistent with what's in debian/patches/
[17:58] <jelmer> smoser: no, there isn't any way to tell the importer that AFAIK
[17:59] <smoser> yeah, i guess "as long as they're consistent with what's in debian/patches"
[17:59] <smoser> but if you just import a patch, you'd potentially want to see that you updated those files.
[18:01] <jelmer> smoser: wouldn't that show up as a change to debian/patches/X too though?
[18:01] <smoser> it would, yes.
[18:02] <smoser> but how else would you know to commit those files
[18:02] <smoser> as they're being verisoned, you should commit them.
[18:02] <smoser> (ie, if you were going to commit and push, rather than just let the importer do it)
[18:02] <jelmer> if we're hooking diff, we can hook commit too
[18:02] <jelmer> in other words, we should consider .pc/ metadata I think
[18:03] <jelmer> metadata that we should keep up to date, but preferably not bother the user with
[18:03] <smoser> ok
[18:03] <smoser> its not a bug report i'm pround of
[18:03] <smoser> proud of
[18:03] <smoser> vbut
[18:03] <smoser> bug 947337
[18:03] <smoser> (ie, not proud because it has no easy recreate or example)
[18:04] <jelmer> heh, fair enough
[18:04] <jelmer> it's a bug report though, not your phd thesis :)
[18:04] <jelmer> thanks
[19:39] <Rcart> hey there
[19:39] <Rcart> I want to add a apport hook for mpd and downloaded the apport package
[19:39] <Rcart> but the branch (bzr branch ubuntu:apport) is out-dated
[19:40] <Rcart> when I do bzr update in the branch, it says up to date
[19:41] <jelmer> Rcart: please file a bug against the udd project in launchpad
[19:42] <Rcart> jelmer: great. Working on...
[19:55] <Rcart> jelmer: "udd" does not exist in Ubuntu.
[19:56] <jelmer> Rcart: it's not a package but a project, see http://launchpad.net/udd
[19:57] <Rcart> yeah, but when I try to send the bug claims about that error
[19:57] <Rcart> then I don't select a package before send it?
[19:58] <jelmer> Rcart: actually, it seems for apport you probably want lp:apport
[19:58] <jelmer> (rather than ubuntu:apport)
[19:58] <jelmer> Rcart: https://bugs.launchpad.net/udd/+filebug
[20:00] <Rcart> jelmer: bzr lp:apport works
[20:17] <Rcart> jelmer: bug 947451
[20:17] <Rcart> jelmer: thanks for your help (:
[20:54] <poolie> hi all
[20:54] <poolie> hi wgz?
[21:26] <wgz> hey poolie
[22:12] <bsd> Hi abentley.  Is there are way to export a patch for a particular pipe as a merge directive or something more solid than a patch?  I was wondering about file/directory moves and deletions… kinda like a shelf?
[22:24] <abentley> bsd: You should be able to export a merge directive with -r ancestor::prev
[23:32] <jono> hi all
[23:32] <jono> I just merged in a branch and deleted a directory (which was not required anymore) and bzr is complaining that it can't remove the dir as it is not empty
[23:32] <jono> yet the directory is deleted
[23:32] <jono> how can I fix this?
[23:34] <jono> nevermind, fixed it