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