=== tkamppeter_ is now known as tkamppeter [07:34] hi all ! [07:48] * fullermd waves at vila. [09:07] morning all [09:08] mgz: morning [09:25] vila: what are you up to today? [09:25] udd stuff mainly [09:26] on a related note I'm also up to 48 ;) [09:27] surely not! [09:28] since 17 minutes to be precise [09:28] grr [09:28] 18 [09:28] clocks are conspiring to make me tyop now ? [09:33] I'll probably lose my internet access today, hopefully no longer than 1/2 hour, I may even be able to warn here first === Quintasan_ is now known as Quintasan [11:18] mgz: ha, *asking* if there was a problem was needed to trigger the reconnect :) [11:19] only 15 minutes downtime though :) [11:28] yeah, no I need to restore wireless and phone though [11:28] now [11:53] hmm, got the phone but still no wifi, lunch break, will obviously work better after that ;) [11:56] Hm, I've got no wifi either. Maybe that means I should eat.. [12:48] What advantages does bzr have over git? [14:25] hey all. i'm wondering if i could get a little help doing a merge. [14:25] i'm trying to 'bzr merge-upstream' with lp:ubuntu/python-boto [14:25] smoser: hi, you're welcome [14:25] python-boto exhibits bug 883207 [14:25] Launchpad bug 883207 in bzr (Ubuntu) "bzr reports huge differences compared to 'diff'" [Medium,Triaged] https://launchpad.net/bugs/883207 [14:26] and the merge reports a bunch of conflicts that are just silly. [14:26] vila, thank you ;) [14:26] ha, hmm, sounds like a parallel import again, right ? [14:27] maybe.. [14:27] can you pastebin the output of 'bzr conflicts' ? [14:27] i'm perfectly willing to just say "bzr merge-upstream" and take upstreams' version of any file. [14:28] in this case, 'bzr resolve --take-other' should get you pretty close to what you're after [14:28] vila, i can... but you can very easily see the same thing as me. (bzr branch lp:ubuntu/python-boto && cd python-boto && bzr merge-upstream ) [14:28] hmm.. am I doing something wrong or is this a real bug: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/898179 [14:28] Error: ubuntu bug 898179 not found [14:28] argh.. it's private atm.. [14:29] http://paste.ubuntu.com/754921/ [14:29] smoser: branching... [14:29] ok, public now [14:30] https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/898179 [14:30] Ubuntu bug 898179 in bzr (Ubuntu) "bzr crashed with UnicodeDecodeError when using dailydeb command" [Undecided,New] [14:30] smoser: merge-upstream'ed, looking [14:31] so --take-other is probably pretty close to what i want. i can go forward with that. [14:32] however, it has the issue on some files as reported in 883207. it thinks some files have been deleted and replaced with the same content. [14:32] and i would really like to fix this branch so it doesn't do that any more. [14:32] Wellark: I think that's a dupe of a bug mgz fixed earlier [14:32] as its really annoying. [14:32] Wellark: what version of bzr-builder are you running? [14:33] smoser: so, the root issue is that to track renames, bzr assign a file-id when a file is first added [14:33] smoser: when it happens for the same file in two separate branches, we call it a 'parallel import' [14:33] yeah, i'm not sure what got it into this situation, and quite likely the source of the problem is typing this sentance. [14:34] smoser: when these two branches are merged, bzr (so far) fail to realize that these two files are really the same [14:34] but i'd like to get it fixed, and am willing to do some hacks now to get there. [14:34] 'bzr resolve --take-other' removes the file-id present in the branch and takes the other one [14:35] so if you keep merging from the same branch, you shouldn't encounter the same issue [14:36] well that is good enough for me. [14:36] the long term fix is to allow both file histories to be merged [14:37] smoser: let me know how it goes for the *next* merge-upstream [14:37] smoser: and if you're subscribed to the udd mailing list, there is a thread about collecting such issues/recipes [14:38] smoser: called 'UDD: categorising and working around common issues' [14:38] vila, thanks. [14:38] one other thing as punishment for your helpfulness [14:38] i just did merge-upstream... resolve --take-other... [14:38] then 'bzr commit' [14:39] and it did not ask me to add a message [14:39] it did the same thing as debcommit would have [14:39] which is not what i wanted (non-interactively taking the debian changelog entry) [14:39] jelmer: is that ^ Riddell patch striking ? [14:40] vila, smoser: yes, that's fixed in bzr-builddeb trunk [14:40] in other words, trunk now has it disabled by default and you have to explicitly enable it [14:40] pfew, lucky me ;) [14:40] in older versions of bzr-builddeb the option defaults to True, but you can disable it [14:41] jelmer, ok. i'm bzr-builddeb 2.7.9ubuntu1 [14:41] but, thanks. [14:41] is there a way to explicitly request edit ? [14:41] i guess i can just type a message and use --file [14:41] smoser: set "commit-message-from-changelog = False" in bzr-builddeb's config, e.g. ~/.bazaar/builddeb.conf [14:42] thanks to everyone. i have to say, that i find #bzr to be probably the most immediately helpful channel that i frequent, followed closely by #launchpad. [14:47] jelmer: the one which comes from oneiri repositories [14:47] lemmecheck [14:48] jelmer: 0.7.1-0ubuntu1 [14:48] Wellark: It's fixed in 0.7.2, which is in oneiric. I've just marked your bug as a dupe. [14:49] hm, bzr-builder doesn't have an exposted version number? [14:49] mgz: it does in 0.7.2 :-) [14:49] and hey, you're talking about exactly the same bug I was just reading mail on [14:50] 0.7.2 is probably still in proposed [14:50] bug 837741 is the one. [14:50] Launchpad bug 837741 in bzr-builder (Ubuntu) "bzr-builder has to call .decode on get_maintainer() output" [High,Fix released] https://launchpad.net/bugs/837741 [14:50] I'll grap it there [14:54] jelmer: I see 0.7.2 for precise, but not for oneiric [14:55] Wellark: sorry, my bad. I meant to say precise [14:55] I'll just grab the trunk directly [14:55] np [14:55] Wellark: 0.7.2 is indeed not in oneiric. You should be able to grab it from the bzr daily build PPA or install it in ~/.bazaar/plugins manually. [14:56] yeah, I go manual [14:59] or not.. apparently I have to upgrade bzrlib, too [14:59] daily PPA, here I come :) [15:00] Wellark: it's ppa:bzr/daily [15:00] Wellark: I'm surprised you would need a newer bzrlib though, did you get an error of sorts? [15:03] hey, on the ubuntu bugs index page for a package it tells you what versions are in what series, hadn't noticed that before [15:10] vila, i just realized that 'take-other' didn't get me my bin.moved directory [15:10] so i'm missing a bunch of bin/ files. [15:10] suggestions on thta ? [15:12] bin.moved was put out of the way and 'bzr rm'ed' , so either you move the files you want back into your branch and add them again (suboptimal) [15:13] or you come back to the state after 'bzr resolve' to cancel the removal of the files you want to keep [15:13] ghaa, this sounds horribly complicated :-/ [15:15] smoser: did the above make sense or should I explain more ? [15:15] i can easily reproduce the prior-to-resolve state. [15:15] vila: yeah, we really should address parallel imports at some point.. [15:15] ok [15:15] so how would i 'cancel the removal' ? [15:16] smoser: justasec, trying locally [15:19] right, [15:20] so, you 'bzr mv bin.moved/* bin' to say : I want to keep those [15:20] i didn't do that, but i can. [15:20] it will fail for s3put, leave it for now, do 'bzr mv bin.moved/*admin bin' to get the missing ones [15:20] and there was one file i think that existed in both. [15:20] right. [15:21] *now*, if you do 'bzr resolve --take-other' you'll notice that it says: deleted bin.moved/s3put (and deleted bin.moved) [15:21] so the original bin and bin/s3put are the only ones deleted [15:22] you may want to do the same for ec2/*.moved/* [15:22] s/may/probably/ [15:23] ok.. so what do i do about the conflicts ? [15:23] what i've done before, which probably got us into this situation was 'bzr rm, bzr add' [15:24] EEEEEERK ! [15:24] :) [15:24] never ever do that :) [15:24] well bzr rm seemed like the only way to get the original outof the way. [15:24] That's exactly the cause indeed, not a parallel import but a remove/add pair breaking the rename tracking :) [15:24] as 'bzr mv --force' isnt a thing. [15:25] when do you need to get the original out of the way ? [15:25] because its different than the right version [15:25] and 'bzr mv' wouldn't do it. [15:25] the content ? [15:25] yeah [15:26] so you got .THIS .OTHER .BASE ? [15:26] and conflict markers in the file / [15:26] s!/!?! [15:26] bzr diff ./boto/ec2/autoscale.moved/group.py ./boto/ec2/autoscale/group.py [15:26] as an example. [15:27] if .moved appears somewhere, there was a conflict on the name (abusively called content conflict) [15:27] resolve --take-other should do the right thing [15:27] oh [15:27] resolve --take-other boto/ec2/autoscale/group.py [15:27] in this case [15:28] either path can be used, which one you use doesn't change the result [15:29] ok. [15:30] i understand the 'rm and add' are bad, but from other rcs (ie git) the result is still sane. [15:30] yup [15:31] because renames are not tracked [15:31] it's the other side of the same coin [15:32] and breaks badly for bzr which is why we need to address it [15:34] vila, so does this seem sane: [15:34] $ for d in $(find . -name "*.moved"); do for e in "$d/"* ; do o=${e//.moved/}; if [ -e "$o" ]; then echo bzr resolve --take-other $o; else echo bzr mv $e ${e//.moved/} ; fi; done; done [15:34] bzr resolve --take-other ./bin/s3put [15:34] bzr resolve --take-other ./boto/ec2/autoscale/group.py [15:34] bzr resolve --take-other ./boto/ec2/autoscale/__init__.py [15:34] bzr mv ./boto/ec2/autoscale.moved/instance.py ./boto/ec2/autoscale/instance.py [15:34] bzr resolve --take-other ./boto/ec2/autoscale/launchconfig.py [15:34] bzr mv ./boto/ec2/autoscale.moved/policy.py ./boto/ec2/autoscale/policy.py [15:34] bzr mv ./boto/ec2/autoscale.moved/request.py ./boto/ec2/autoscale/request.py [15:34] bzr mv ./boto/ec2/autoscale.moved/scheduled.py ./boto/ec2/autoscale/scheduled.py [15:34] bzr mv ./boto/ec2/elb.moved/healthcheck.py ./boto/ec2/elb/healthcheck.py [15:34] bzr resolve --take-other ./boto/ec2/elb/__init__.py [15:34] bzr mv ./boto/ec2/elb.moved/instancestate.py ./boto/ec2/elb/instancestate.py [15:34] bzr mv ./boto/ec2/elb.moved/listelement.py ./boto/ec2/elb/listelement.py [15:34] bzr mv ./boto/ec2/elb.moved/listener.py ./boto/ec2/elb/listener.py [15:34] bzr mv ./boto/ec2/elb.moved/loadbalancer.py ./boto/ec2/elb/loadbalancer.py [15:34] !pastebin :) [15:34] bzr mv ./boto/ec2/elb.moved/policies.py ./boto/ec2/elb/policies.py [15:34] bzr mv ./boto/ec2/elb.moved/securitygroup.py ./boto/ec2/elb/securitygroup.py [15:34] bzr mv ./boto/ec2/cloudwatch.moved/alarm.py ./boto/ec2/cloudwatch/alarm.py [15:34] bzr mv ./boto/ec2/cloudwatch.moved/datapoint.py ./boto/ec2/cloudwatch/datapoint.py [15:34] bzr resolve --take-other ./boto/ec2/cloudwatch/__init__.py [15:34] bzr mv ./boto/ec2/cloudwatch.moved/listelement.py ./boto/ec2/cloudwatch/listelement.py [15:34] bzr resolve --take-other ./boto/ec2/cloudwatch/metric.py [15:34] crap! [15:35] sorry [15:35] http://paste.ubuntu.com/755002/ [15:35] thats what i meant to paste. [15:35] lol, nw [15:36] yup, looks sane, does the resulting diff looks sane ? [15:41] vila, boto/ec2/elb/__init__.py is not conflicted [15:42] smoser: no, you did: 'bzr resolve --take-other ./boto/ec2/elb/__init__.py' [15:42] so you took the other content [15:42] ok. so that output was expected, and did what i wanted. thats fine. [15:43] now do a blanket resolve ? [15:43] what does 'bzr conflicts' says ? [15:44] testing locally, there is a problem [15:45] my 'either path can be used' was misleading, it applies only when .moved is the only difference between the two paths [15:46] conflicts still lists all the original conflicts. [15:47] right, 'bzr st' is clearer here (and also list the conflicts) [15:47] is the 'tests' hierarchy deletion deliberate ? [15:53] it moved. i think. have to check, though [15:54] no. tests removal was not deliberate. upstream has it. [15:55] oh wait. it *was* deliberate :-( [15:55] the upstream tarball apparently does not have tests/ in it although revision control does. [15:55] testing locally, 'bzr resolve --take-other' output seems fine [15:55] so that sucks for a different reason. [15:56] 'bzr revert tests' will restore it [15:57] yeah, but dont you think its probably best to leave it gone ? [15:57] I have no idea [15:57] yea.. i was hoping you'd have a better feel for that. [15:57] Only a personal preference for not deleting tests (especially all of them ;) [15:57] it does suck that upstream's tarball and revision control tag aren't equal. [15:58] well, the only issue is that my tests/ directory would then be that of 2.0.2, not 2.1.1 and potentially not even work, *and* its different than upstream tests/ [15:58] i'll mail upstream about lack of that in tarball as a long term fix. [16:01] yeah, exploring with 'bzr qlog', 'tests' was added in 2.0.0-ubuntu1 which get them from upstream-2.0 [16:02] which ironically outlines why getting the parallel import fixed is important as here if upstream add the tests again, we really want to reconcile the histories === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [16:38] jelmer: running bzr daily ppa version of dailydeb fixed the problem as you guessed [16:39] now. Is there a way to trigger rebuild on dailyppa after uploading new branches? [16:40] is there any way to see what is the current rebuild period? [16:41] Wellark: there is a "Build now" link that is shown whenever one of the branches has unbuilt revisions [16:41] let's see [16:41] otherwise the branches with changes get rebuilt within a 24-hour window [16:41] there is no ETA on when in the 24-hour window that is (but an open lp bug about showing that) [16:43] hmm.. odd.. I can't find the recipe on any of the branches [16:44] there has to be one as the daily ppa sends me build error emails [16:44] the build uses these branches: https://code.launchpad.net/~indicator-network-developers/ofono/trunk, https://code.launchpad.net/~indicator-network-developers/ofono/trunk.packaging [16:45] but both of those branches say: No recipes using this branch. [16:47] I'm a bit puzzled now [16:48] Wellark: how did you create the recipe? [16:48] no, somebody created it before [16:49] now, I'm suppose to continue development and maintenance of those packages and I'm trying to figure out all the pieces of the puzzle [16:49] s/no/no, I didn't create it my self/ [16:50] jelmer: do you have some powertool to list the recipes which land stuff to this PPA: https://launchpad.net/~indicator-network-developers/+archive/daily-ppa ? [16:54] Wellark: usually I just look for recipes owned by the same user that owns the PPA [16:55] Wellark: based on the versions of the packages in that PPA, it seems like those packages weren't created by a recipe [16:55] Wellark: it's probably just somebody (a bot?) doing daily source package uploads [16:56] sigh... [16:57] jelmer, mgz: I'm looking at some import failure and I encounter a weird case you may help me to understand, get the branches for debootstrap -rtag:1.0.36 for oneiric, sid and wheezy, launch qlog on them and tell me it's not as bad as I fear :-/ [17:00] vila: hmm, it seems like the debian and ubuntu branches have parallel imports? [17:01] vila: seems like it was caused by the fact that ubuntu diverged for a bit, then discarded its changes [17:01] hm. [17:01] vila: it diverged in 1.0.29ubuntu1, and then discarded that [17:01] but the tags '1.0.xx' should be for upstream no ? [17:02] they seem to exist with different revids in debian and ubuntu [17:02] vila: there is no upstream in this case [17:02] vila: it is a native package [17:02] surely the same tag can't be used for different revs ? [17:03] even for native packages [17:03] and the picture is even more fun when you add the precise branch :-/ [17:05] vila: different branches can have different tags [17:05] right, that's the theory, but does it make sense here ? [17:05] vila: in this case bzr-builddeb doesn't pull from the Debian branch anymore because it sees the Ubuntu and the Debian branch have diverged [17:06] precise merged them [17:07] this branch is a little large for my connection, it's not finished yet. [17:07] there we go. [17:07] mgz: oh, sorry :-( ~133MB [17:09] vila: please file a bug against bzr-builddeb [17:09] jelmer: so, debian and ubuntu, for native packages, having the same tag used for different versions is expected ? [17:10] jelmer: I'm trying to understand first, I'm not sure builddeb is at fault here, the failure is udd so far and it seems it assumes a tag cannot point to different revs there [17:10] s/udd/in udd/ [17:10] jelmer: so, debian and ubuntu, for native packages, having the same tag used for different versions is expected ? [17:11] vila: no, that's not expected [17:11] what tags should they use then ? [17:12] x.y.zdebianN and x.y.z.ubuntuN ? [17:12] okay, I see the pretty picture. [17:12] vila: the tag names aren't the issue [17:13] vila: it's the fact that bzr-builddeb doesn't pull from the debian branch to import those revisions, and then reimports them itself. [17:13] vila: and when it reimports htem itself, they end up with new revision ids and tags [17:14] ha [17:14] so the ubuntu ones are wrong is what you're saying ? [17:14] vila: when 1.0.30 was synced from debian to ubuntu, that discarded 1.0.29ubuntu1 [17:15] vila: yes [17:15] it would be interesting to see if you can reproduce this issue by taking the ubuntu branch at 1.0.29ubuntu1 and then trying to import the 1.0.30 package [17:15] but the parents of the ubuntu 1.0.30 are 1.0.29ubuntu1 *and* debian 1.0.30 [17:16] vila: the parents of ubuntu 1.0.30 should be 1.0.29 only [17:16] vila: it should be the same revision as debian 1.0.30 [17:17] vila: what happened is basically the equivalent of "bzr push --overwrite" [17:17] meh, 1.0.29ubuntu1 cannot be part of debian right ? Oh, you mean 1.0.29ubuntu1 shouldn't be there *at all* anymore ? [17:18] vila: right, it shouldn't be there anymore at all [17:18] vila: if you look at the current changelog.gz, you'll also see it's not there [17:19] which the 1.0.30 merge shows in its associated diff yes [17:20] I suspect the package importer have no idea this can occur [17:20] so both may need to be fixed (importer and buildeb) [17:22] no, wait, something is wrong here [17:24] say 1.0.29 was for lucid and then 1.0.30 for maverick, I still want 1.0.29 to be there so I can make other dot releases for lucid, as long as the content for 1.0.30, the prior history shouldn't need to be altered [17:24] s/as the content/& is correct/ [17:25] vila: I'm not sure I follow? [17:25] you said 'right, it shouldn't be there anymore at all' , that sounds excessive [17:26] in the revision graph for the oneiric branch, 1.0.29ubuntu1 shouldn't be present at all [17:27] the tags was a red herring as you explain, knowing they are legit, the branches don't look that weird now [17:27] 1.0.29, 1.0.30, etc should be present in the oneiric branch [17:28] 1.0.29ubuntu1 commit says: 'Cherry-pick from trunk:' so it has been released right (in natty) ? [17:28] why should it disappear from the history in this case ? [17:29] it seem the branches converge again at 1.0.30 if they can have different revs for the same tag, what's the issue ? [17:29] vila: it's like bzr release series [17:29] endless superfluous merges ? [17:30] vila: it's possible to cherry-pick a change from trunk onto 2.1 but it will become a different revision, and that different revision isn't in lp:bzr [17:30] right, but it's still part of the 2.1 history and becomes part of bzr.dev history when merged up [17:31] vila: there was no up-merging from ubuntu into debian here though [17:31] vila: which is why that revision shouldn't be part of the oneiric history [17:31] right and they will never be because ubuntu is downstream and has a larger history [17:32] vila: ubuntu oneiric has the exact same history as debian sid at the moment [17:32] vila: they're both shipping 1.0.38 [17:32] but their branches are different, same content because ubuntu merges debian but still different histories [17:32] vila: the ubuntu natty branch *should* have 1.0.29ubuntu1 [17:33] vila: their branches should be the same, like for any package where ubuntu doesn't have a delta [17:33] we seem to agree about the branch content but disagree about the branch history [17:34] vila: about what should be in the branch history you mean? [17:34] the oneiric history should be a subset of the natty history so 1.0.29ubuntu1 should also be part of oneiric [17:34] yes [17:35] grr [17:35] s/subset/superset/ of course [17:35] or not ? [17:35] vila: I don't think it should be a superset, it doesn't reflect what has actually happened [17:36] are you saying the history can somehow be restarted when a new ubuntu release is started ? [17:36] so the natty branch and the oneiric one can really diverge and never be reconciled ? [17:38] my understanding was that launchpad was always creating the new release branches from the previous release... [17:38] vila: sure - the same thing happens e.g. with SRUs [17:39] james_w: around? [17:39] right, but SRU happen *after* the branches have been bootstrapped [17:39] miss an s, here are some ssss [17:40] vila: the bootstrapping and old branches don't really matter I think [17:41] vila: the point is that when ubuntu discards its changes for a package, we should reflect that in the history [17:41] * vila blinks [17:41] by removing a revision ? [17:41] vila: effectively, what ubuntu is doing is: [17:42] taking a debian, making some local changes to it [17:42] taking a debian package (1.0.29), making some local changes to it and uploading that (1.0.29ubuntu1) [17:42] recording that in the branh history [17:42] then later, when e.g. the fixes in 1.0.29ubuntu1 have been applied upstream too, they discard their version of it [17:42] "bzr pull --overwrite debianlp:debootstrap" [17:43] so they again have the same history as debian [17:43] wow [17:43] and no trace that 1.0.29ubuntu1 ever existed ? [17:44] right - see debian/changelog in e.g. 1.0.37, no sign that 1.0.29ubuntu1 was ever there [17:44] hehe, touche [17:44] hmm [17:44] right, so I see your point [17:44] I don't think it is what is implemented yet though, [17:45] but I can imagine that the failures are related [17:45] I'll big further tomorrow, thanks for the explanations and the discussion [17:46] s/big.... ???/dig/ [17:47] :) see you tomorrow [17:48] hmm, and the tag should be deleted too, everywhere :) ... [17:49] vila: not everywhere, just those ubuntu releases that no longer have the version.. [17:49] ha ! Who is making things harder now ! :0D [17:50] vila: I don't think that's making things harder - it's just one of the things we should do when we do the "bzr pull --overwrite" from debian [17:53] yeah, was mostly kidding. [17:54] --overwrite may have a lot of unforeseen fallouts is what I meant, people having mirrors and so on [17:54] or pending proposals [17:55] hmm.. I'm trying to write a recipe [17:55] my .recipe file contains: [17:55] vila: I don't think we necessarily handle that very well at the moment, as we record the parent but don't actually have the changes from 1.0.29ubuntu1 [17:55] anyway, food for thougt, first of all, fixing the imports ;) EOD, have fun ! [17:55] # bzr-builder format 0.4 deb-version {debupstream}-0ubuntu1+bzr{revno}+bzr{revno:packaging} [17:56] vila: g'night & g'appetite :) [17:56] but running $bzr dailydeb gives me an error [17:56] bzr: ERROR: Invalid deb-version: {debupstream}-0ubuntu1+bzr5947+bzr2792: Invalid version string '{debupstream}-0ubuntu1+bzr5947+bzr2792' [17:56] so it seems that {depupstream} doesn't get substituted [17:57] Wellark: what's the full recipe? [17:58] jelmer: $ cat ofono.recipe [17:58] # bzr-builder format 0.4 deb-version {debupstream}-0ubuntu1+bzr{revno}+bzr{revno:packaging} [17:58] ofono.trunk [17:58] arg,, [17:58] argh. [17:58] jelmer: http://pastebin.ubuntu.com/755157/ [17:59] Wellark: does ofono.trunk have a debian/ directory? If not, you probably want {debupstream:packaging} [17:59] ah, ok [18:01] jelmer: ok, now it works! [18:01] jelmer: then there's a documentation bug [18:02] bzr help dailydeb says [18:02] "{debupstream} will be replaced by the upstream portion of the version number taken from debian/changelog in the final tree." [18:02] bzr help builder, I mean [18:02] Wellark: "bzr help dailydeb" doesn [18:02] t mention {debupstream} here === zyga is now known as zyga-afk [18:06] Wellark: never mind, found it in "bzr help builder" [18:06] jelmer: 20:00:11 < Wellark> bzr help builder, I mean [18:06] :) [18:08] jelmer: do you want a bug report or will you handle this on your own? [18:13] Wellark: submitting a fix now [18:16] Wellark: thanks for reporting that, btw [18:18] jelmer: no problem [18:18] thank you for fixing it so quickly! :) [18:48] vila, i can't seem to get rid of all the add/remove pairs [18:48] http://paste.ubuntu.com/755216/ [18:52] jelmer: reviewed bzr-builddeb mp [19:02] mgz: merci [19:27] mgz: updated [19:34] vila, i'm sure you're sleeping or afk, but it seems to me that this ended up doing what i wanted [19:34] http://paste.ubuntu.com/755287/ [19:34] i would appreciate your input (or others) as to if this will then get me into a sane state for merges from debian and/or upstream in the future. [19:38] ah, so I don't get bzr-builddeb bug mail... [19:38] smoser: I'm not entirely sure if that revert command will do the right thing. I would personally use "bzr resolve --take-other $d" [19:40] I probably need to join bzr-builddeb-hackers [19:43] mgz: you should be able to be subscribed without being in the team that owns bzr-builddeb [19:44] mgz: that said, you probably should join bzr-builddeb-hackers >-) [19:44] smoser: the diff output seems reasonable enough though [20:49] hey, that's a fun regression [20:49] too many yaks, too many yaks [20:51] mgz: hmm? [20:55] hi all [20:55] something in 2.5 broke the error you get when trying to commit an unversioned file, with non-ascii filenames [20:56] it was kinda bust before but now it's good ol' "Unprintable exception" [20:56] which... as I was trying to test a different fix against that was very confusing [21:05] hm [21:05] mgz, i would like to change the tests from using hardcoded file names to getting the names from some kind of factory object [21:11] picking well known problem values isn't bad. [21:11] so that more of them can be unicode [21:11] right they could just start with a list like that [21:11]