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