| === tkamppeter_ is now known as tkamppeter | ||
| vila | hi all ! | 07:34 |
|---|---|---|
| * fullermd waves at vila. | 07:48 | |
| mgz | morning all | 09:07 |
| vila | mgz: morning | 09:08 |
| mgz | vila: what are you up to today? | 09:25 |
| vila | udd stuff mainly | 09:25 |
| vila | on a related note I'm also up to 48 ;) | 09:26 |
| mgz | surely not! | 09:27 |
| 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:28 |
| 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 | 09:33 |
| === Quintasan_ is now known as Quintasan | ||
| vila | mgz: ha, *asking* if there was a problem was needed to trigger the reconnect :) | 11:18 |
| mgz | only 15 minutes downtime though :) | 11:19 |
| vila | yeah, no I need to restore wireless and phone though | 11:28 |
| vila | now | 11:28 |
| vila | hmm, got the phone but still no wifi, lunch break, will obviously work better after that ;) | 11:53 |
| fullermd | Hm, I've got no wifi either. Maybe that means I should eat.. | 11:56 |
| chromaticwt | What advantages does bzr have over git? | 12:48 |
| 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:25 |
| ubot5 | Launchpad bug 883207 in bzr (Ubuntu) "bzr reports huge differences compared to 'diff'" [Medium,Triaged] https://launchpad.net/bugs/883207 | 14:25 |
| 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:26 |
| 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:27 |
| 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 |
| ubot5 | Error: ubuntu bug 898179 not found | 14:28 |
| Wellark | argh.. it's private atm.. | 14:28 |
| smoser | http://paste.ubuntu.com/754921/ | 14:29 |
| vila | smoser: branching... | 14:29 |
| Wellark | ok, public now | 14:29 |
| Wellark | https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/898179 | 14:30 |
| ubot5 | Ubuntu bug 898179 in bzr (Ubuntu) "bzr crashed with UnicodeDecodeError when using dailydeb command" [Undecided,New] | 14:30 |
| vila | smoser: merge-upstream'ed, looking | 14:30 |
| smoser | so --take-other is probably pretty close to what i want. i can go forward with that. | 14:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| vila | so if you keep merging from the same branch, you shouldn't encounter the same issue | 14:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| Wellark | jelmer: the one which comes from oneiri repositories | 14:47 |
| Wellark | lemmecheck | 14:47 |
| 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:48 |
| 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:49 |
| Wellark | 0.7.2 is probably still in proposed | 14:50 |
| mgz | bug 837741 is the one. | 14:50 |
| ubot5 | 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 |
| Wellark | I'll grap it there | 14:50 |
| Wellark | jelmer: I see 0.7.2 for precise, but not for oneiric | 14:54 |
| 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:55 |
| Wellark | yeah, I go manual | 14:56 |
| Wellark | or not.. apparently I have to upgrade bzrlib, too | 14:59 |
| Wellark | daily PPA, here I come :) | 14:59 |
| 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:00 |
| 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:03 |
| 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:10 |
| 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:12 |
| 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:13 |
| 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:15 |
| vila | smoser: justasec, trying locally | 15:16 |
| vila | right, | 15:19 |
| 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:20 |
| 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:21 |
| vila | you may want to do the same for ec2/*.moved/* | 15:22 |
| vila | s/may/probably/ | 15:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| vila | either path can be used, which one you use doesn't change the result | 15:28 |
| smoser | ok. | 15:29 |
| 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:30 |
| vila | because renames are not tracked | 15:31 |
| vila | it's the other side of the same coin | 15:31 |
| vila | and breaks badly for bzr which is why we need to address it | 15:32 |
| 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:34 |
| 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:35 |
| vila | yup, looks sane, does the resulting diff looks sane ? | 15:36 |
| smoser | vila, boto/ec2/elb/__init__.py is not conflicted | 15:41 |
| 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:42 |
| smoser | now do a blanket resolve ? | 15:43 |
| vila | what does 'bzr conflicts' says ? | 15:43 |
| vila | testing locally, there is a problem | 15:44 |
| vila | my 'either path can be used' was misleading, it applies only when .moved is the only difference between the two paths | 15:45 |
| smoser | conflicts still lists all the original conflicts. | 15:46 |
| vila | right, 'bzr st' is clearer here (and also list the conflicts) | 15:47 |
| vila | is the 'tests' hierarchy deletion deliberate ? | 15:47 |
| smoser | it moved. i think. have to check, though | 15:53 |
| smoser | no. tests removal was not deliberate. upstream has it. | 15:54 |
| 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:55 |
| vila | 'bzr revert tests' will restore it | 15:56 |
| 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:57 |
| 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. | 15:58 |
| vila | yeah, exploring with 'bzr qlog', 'tests' was added in 2.0.0-ubuntu1 which get them from upstream-2.0 | 16:01 |
| 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:02 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| Wellark | jelmer: running bzr daily ppa version of dailydeb fixed the problem as you guessed | 16:38 |
| Wellark | now. Is there a way to trigger rebuild on dailyppa after uploading new branches? | 16:39 |
| Wellark | is there any way to see what is the current rebuild period? | 16:40 |
| 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:41 |
| Wellark | hmm.. odd.. I can't find the recipe on any of the branches | 16:43 |
| 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:44 |
| Wellark | but both of those branches say: No recipes using this branch. | 16:45 |
| Wellark | I'm a bit puzzled now | 16:47 |
| jelmer | Wellark: how did you create the recipe? | 16:48 |
| Wellark | no, somebody created it before | 16:48 |
| 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:49 |
| 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:50 |
| jelmer | Wellark: usually I just look for recipes owned by the same user that owns the PPA | 16:54 |
| 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:55 |
| Wellark | sigh... | 16:56 |
| 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 :-/ | 16:57 |
| jelmer | vila: hmm, it seems like the debian and ubuntu branches have parallel imports? | 17:00 |
| 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:01 |
| 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:02 |
| vila | even for native packages | 17:03 |
| vila | and the picture is even more fun when you add the precise branch :-/ | 17:03 |
| 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:05 |
| vila | precise merged them | 17:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| jelmer | vila: no, that's not expected | 17:11 |
| vila | what tags should they use then ? | 17:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| vila | which the 1.0.30 merge shows in its associated diff yes | 17:19 |
| 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:20 |
| vila | no, wait, something is wrong here | 17:22 |
| 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:24 |
| 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:25 |
| jelmer | in the revision graph for the oneiric branch, 1.0.29ubuntu1 shouldn't be present at all | 17:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| 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:39 |
| jelmer | vila: the bootstrapping and old branches don't really matter I think | 17:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| vila | s/big.... ???/dig/ | 17:46 |
| jelmer | :) see you tomorrow | 17:47 |
| vila | hmm, and the tag should be deleted too, everywhere :) ... | 17:48 |
| 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:49 |
| 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:50 |
| vila | yeah, was mostly kidding. | 17:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| jelmer | Wellark: what's the full recipe? | 17:57 |
| 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:58 |
| jelmer | Wellark: does ofono.trunk have a debian/ directory? If not, you probably want {debupstream:packaging} | 17:59 |
| Wellark | ah, ok | 17:59 |
| Wellark | jelmer: ok, now it works! | 18:01 |
| Wellark | jelmer: then there's a documentation bug | 18:01 |
| 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:02 |
| === zyga is now known as zyga-afk | ||
| 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:06 |
| Wellark | jelmer: do you want a bug report or will you handle this on your own? | 18:08 |
| jelmer | Wellark: submitting a fix now | 18:13 |
| jelmer | Wellark: thanks for reporting that, btw | 18:16 |
| Wellark | jelmer: no problem | 18:18 |
| Wellark | thank you for fixing it so quickly! :) | 18:18 |
| smoser | vila, i can't seem to get rid of all the add/remove pairs | 18:48 |
| smoser | http://paste.ubuntu.com/755216/ | 18:48 |
| mgz | jelmer: reviewed bzr-builddeb mp | 18:52 |
| jelmer | mgz: merci | 19:02 |
| jelmer | mgz: updated | 19:27 |
| 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:34 |
| 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:38 |
| mgz | I probably need to join bzr-builddeb-hackers | 19:40 |
| jelmer | mgz: you should be able to be subscribed without being in the team that owns bzr-builddeb | 19:43 |
| jelmer | mgz: that said, you probably should join bzr-builddeb-hackers >-) | 19:44 |
| jelmer | smoser: the diff output seems reasonable enough though | 19:44 |
| mgz | hey, that's a fun regression | 20:49 |
| mgz | too many yaks, too many yaks | 20:49 |
| jelmer | mgz: hmm? | 20:51 |
| 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:55 |
| 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 | 20:56 |
| 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:05 |
| 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:11 |
| poolie | so perhaps we just need to make sure the tests always run with the right fsenc | 21:12 |
| 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 | 21:16 |
| === zyga-afk is now known as zyga | ||
| james_w | jelmer, I am now | 22:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:09 |
| jelmer | james_w: IOW, once there has been a ubuntu-specific revision, the revision graphs will never ever converge again? | 22:10 |
| james_w | jelmer, yeah | 22:12 |
| james_w | that seemed to more accurately reflect the upload history to Ubuntu | 22:12 |
| 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:14 |
| jelmer | vila: ^ | 22:15 |
| mgz | heh | 23:08 |
| mgz | bisected regression... comes out at r6124 ;_; | 23:08 |
| mgz | guess it's a gettext change then. | 23:10 |
| * mgz does the hidden 16 former mainline revs as well | 23:10 | |
| mgz | 6123.1.10 indeed. | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!