| === AfC1 is now known as AfC | ||
| vila | hello all ! | 07:37 |
|---|---|---|
| wgz | morninh vila | 07:42 |
| vila | wgz: hey ! | 07:43 |
| poolie | vila, hi | 08:50 |
| vila | poolie: hey ! | 08:50 |
| mgz | morning | 10:14 |
| 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:48 |
| quicksilver | hno: good question. | 11:50 |
| jelmer | hno: I'm not entirely sure how to do that either; 'bzr qlog' can show that info | 11:54 |
| hno | jelmer, qlog can show uncommitted log info? | 11:57 |
| jelmer | hno: yep, by default it will do so | 11:58 |
| quicksilver | when your GUI tool can access information the commandline tools cannot, something has gone wrong with the abstraction layers ;) | 12:13 |
| jelmer | quicksilver: :) | 12:17 |
| jelmer | quicksilver: it's all exposed in the API, mostly just not exposed through the cli frontend | 12:17 |
| quicksilver | yes, I recognise that | 12:20 |
| quicksilver | so I didn't really phrase my objection correctly | 12:20 |
| 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:21 |
| 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! | 12:22 |
| === yofel_ is now known as yofel | ||
| 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:19 |
| abentley | jelmer: Ah, looks like someone forced builds. | 15:20 |
| 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:31 |
| jelmer | I've seen it happen quite regularly | 15:32 |
| abentley | jelmer: Okay, we should probably fix it to drop identical requests. | 15:54 |
| === verterok` is now known as verterok | ||
| lamalex | is there a means for reverting the changes introduced in a previous commit? | 16:23 |
| LeoNerd | merge backwards? replay backwards? uncommit? | 16:24 |
| LeoNerd | pull from a previous version? | 16:24 |
| jelmer | :q | 16:25 |
| mgz | LeoNerd: in other words, lots of ways :) | 16:26 |
| 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:27 |
| mgz | merging the reverse of a rev does take a little mental leap | 16:28 |
| jelmer | mgz: I think we should have a somewhat easier way to do this, it's a question that comes up quite regularly | 16:30 |
| 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:42 |
| quicksilver | unless I do it before anyone cares about the history, in which case I go for bzr push --overwrite ;) | 16:43 |
| 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:44 |
| mgz | your revert method quicksilver is no good when there have been subsequent changes | 16:45 |
| quicksilver | oh, I see "un-cherry-pick" | 16:45 |
| 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:46 |
| quicksilver | (why isn't there yet a recognised successor to diff for things which diff can't represent?) | 16:47 |
| smoser | so what is the correct "UDD" way to store quilt 3.0 ubuntu branches ? | 17:32 |
| === deryck is now known as deryck[lunch] | ||
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| smoser | i think i agree with you on that. | 17:41 |
| 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:42 |
| smoser | i guess that was my largestt grevence. | 17:43 |
| smoser | s/bad spelling/good spelling/ | 17:43 |
| 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:44 |
| jelmer | yeah, bzr-builddeb lso has the various hooks to improve the merging of branches that contain quilts | 17:45 |
| 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:55 |
| smoser | jelmer, there is no way to tell the importer that it should not store patch files applied, is there ? | 17:57 |
| 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:58 |
| 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. | 17:59 |
| jelmer | smoser: wouldn't that show up as a change to debian/patches/X too though? | 18:01 |
| smoser | it would, yes. | 18:01 |
| 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:02 |
| 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 |
| ubot5 | 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 |
| smoser | (ie, not proud because it has no easy recreate or example) | 18:03 |
| jelmer | heh, fair enough | 18:04 |
| jelmer | it's a bug report though, not your phd thesis :) | 18:04 |
| jelmer | thanks | 18:04 |
| === deryck[lunch] is now known as deryck | ||
| === Omni|AFK is now known as Omni|Work | ||
| 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:39 |
| Rcart | when I do bzr update in the branch, it says up to date | 19:40 |
| jelmer | Rcart: please file a bug against the udd project in launchpad | 19:41 |
| Rcart | jelmer: great. Working on... | 19:42 |
| Rcart | jelmer: "udd" does not exist in Ubuntu. | 19:55 |
| jelmer | Rcart: it's not a package but a project, see http://launchpad.net/udd | 19:56 |
| 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:57 |
| 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 | 19:58 |
| Rcart | jelmer: bzr lp:apport works | 20:00 |
| Rcart | jelmer: bug 947451 | 20:17 |
| ubot5 | Launchpad bug 947451 in Ubuntu Distributed Development "apport branch OUT-OF-DATE" [Undecided,New] https://launchpad.net/bugs/947451 | 20:17 |
| Rcart | jelmer: thanks for your help (: | 20:17 |
| poolie | hi all | 20:54 |
| poolie | hi wgz? | 20:54 |
| wgz | hey poolie | 21:26 |
| 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:12 |
| abentley | bsd: You should be able to export a merge directive with -r ancestor::prev | 22:24 |
| 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:32 |
| jono | nevermind, fixed it | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!