/srv/irclogs.ubuntu.com/2009/06/26/#bzr.txt

lifelessthewrath: did you install bzr using cygwin's setup.exe?00:15
jmllifeless, yesterday, you suggested that there were bugs for 1.16.1 other than bug 365615 and bug 39056300:15
ubottuLaunchpad bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] https://launchpad.net/bugs/36561500:15
ubottuLaunchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/39056300:15
jmllifeless, can you please point me to them?00:15
lifelessjml: did I? I thought I said I was flat out :P00:15
lifelessjml: and I recall talking about 2.0 in terms of what bugs there were00:15
lifelessanyhow, I'm not aware of other 1.16 worthy cherrypicks00:16
=== mthaddon is now known as afk
=== afk is now known as mthaddon
lifelessonce abentley's skip-dupes patch lands in trunk that might be worth putting in 1.16 too; though I thought lp devs ran off nightlies00:16
jmllifeless, we do run off nightlies.00:19
=== mthaddon is now known as afk
lifelessin which case there are no other patches for 1.16 that I know of00:20
jmlok.00:20
jmlwhat about things to cherrypick to Launchpad?00:20
lifelessmwhudson has them in hand00:21
jmlsweet.00:21
jmlthanks.00:21
igcmorning00:32
lifelesshai00:33
igchi lifeless00:33
pooliejml, re your "branches that fix bugs"00:49
pooliethere are some more cases like that in devnotes 3.0-ui document00:49
pooliehttp://doc.bazaar-vcs.org/devnotes/bzr-2009-ui-refresh.html00:49
jmlpoolie, ahh thanks.00:50
jmlpoolie, I'd been meaning to refresh myself on the devnotes branch but let it slip my mind.00:50
poolienp00:51
pooliei don't necessarily want that document to become a laundry list of every possible thing you could want to do with bzr00:51
pooliebut these are at least a bit related00:51
pooliealso airing them on the list may atract more thoughts00:51
jmlwell this has a specific focus I guess00:53
pooliejml, could you send a short metronome mail re 1.17?01:15
jmlpoolie: yep, it's already on my list for today01:17
poolieoh cool01:17
pooliemaybe i should send one about 1.17 vs 2.001:17
jmlthat's probably a good idea01:18
jmlmy list for today is perhaps slightly too long, but I know only one way of making it shorter.01:21
jmlpoolie: I'm also going to cut 1.16.1 today, if I can.01:24
pooliedelete things? or do things?01:24
pooliei was planning to do both :)01:24
jmldo things.01:24
lifelessigc: I'm working on iter-changes today01:32
lifelessigc: now that the crisis with fetch is fixed01:32
igclifeless: cool01:32
lifelessigc: I'd appreciate your holding off your other landing ;)01:32
igclifeless: I'm doing reviews and clearing the desks to work on bug 37473501:33
ubottuLaunchpad bug 374735 in bzr "Plan and UI for upgrading multiple stacked branches " [Critical,Triaged] https://launchpad.net/bugs/37473501:33
igcsure01:33
pooliehello igc, lifeless01:34
lifelesshi poolie01:34
pooliei'm planning today to: send a coscup abstract, (re)send a blog acct to igc, write up a patch explaining the 2a format, do the minimal activity-tied-to-pb fix, order a new disk01:34
igchi poolie01:34
poolietalk to spiv01:35
=== Toksyury1l is now known as Toksyuryel
poolieand hopefully get other uifactory fixes done01:35
pooliethey have a tangle-of-string quality - fixing each test makes for larger changes01:35
poolieall good, but it's not converging01:36
poolieso sometimes i take a step back and try something smaller01:36
pooliebut still01:36
pooliethanks for the review igc01:48
jmlanother unusual error from our systems: https://devpad.canonical.com/~matsubara/oops.cgi/2009-06-25/SMPM0101:54
jmlhttp://paste.ubuntu.com/203878/01:55
lifelessit would be nice if that was openid01:55
jmlwhen mirroring http://bzr.malept.com/avant-window-navigator01:55
jmlyes.01:55
lifelessdidn't you file a bug on that 3 weeks ago?01:55
jmlI don't think so.01:56
lifelesshttps://bugs.edge.launchpad.net/bzr/+bug/377453 ?01:56
ubottuUbuntu bug 377453 in bzr "Error from smart server: ScopeReplacer object '_KnitGraphIndex' was used incorrectly" [High,Confirmed]01:56
jmloh good.01:57
lifelesshmm, different but similar01:57
lifelessadd it to the same one I think01:57
jmldone.01:59
lifelessso, iter_changes tests existing now02:00
lifelesstime to fix implementations02:00
lifelesscan anyone confirm: setup.py build_ext -i is putting the so files in bzrlib/bzrlib/ ?02:13
* fullermd hasn't seen it...02:14
* igc school visit & lunch - bbl02:16
lifelessbug 39235502:17
ubottuLaunchpad bug 392355 in bzr "C extensions placed in wrong directory" [Critical,Triaged] https://launchpad.net/bugs/39235502:17
mwhudsonlifeless: no02:17
lifelessmwhudson: python version? bzrlib version?02:17
lifelessmwhudson: are you on karmic?02:17
mwhudsonlifeless: no02:17
mwhudsonpython2.6 jaunty 447702:17
lifelessjml: you're on karmic aren't you... could you check for this (in 1.16 and-or bzr.dev)02:17
mwhudson4479 sorry02:18
fullermdI just did a fresh branch of lp:bzr and they're all in bzrlib/ where they belong.02:18
lifelessfullermd: when you run setup.py build_ext -i ?02:19
fullermdYah.02:19
fullermdWell, ./setup.py [...]02:19
lifelessfullermd: so bzrlib/*.so, not bzrlib/bzrlib/*.so02:19
fullermdRight.02:19
lifelessok02:19
lifelessthats good data02:19
lifelessIt could well be setuptools02:19
fullermd(py 2.6)02:19
lifelesssorry distutils or something02:19
thewrath(9:17:33 PM) thewrath: hey guys with bzr or svn any way to find the number of modified lines02:20
thewrath(9:17:50 PM) thewrath:  svn diff | grep "^+" | grep -v "^+++" | wc -l  gives you added lines02:20
thewrath(9:18:00 PM) thewrath:  svn diff | grep "^-" | grep -v "^---" | wc -l is removed02:20
thewrath(9:18:13 PM) thewrath: but i need modified lines and unmodified lines02:20
lifelesswhat are you trying to calculate02:20
jmllifeless, the bug refers to 'make build' -- I don't even have a build target in my copy of bzr.02:21
lifelessjml: I fabricated. just 'make', or setup.py directly02:21
thewrathi need to find the total number of added, removed, modified and unmodified lines from revision a to revision b02:22
lifelessthe first three are easy02:22
lifelessthe last one is much harder02:22
fullermd'modified' can be pretty tough to quantify...02:22
lifelessI'm not aware of any simple way to do it02:22
thewrathlifeless: how u calculate the modififed02:22
lifelessthewrath: I'd use some of the existing python libraries to parse the diff and turn added and removed into modifications when they are adjacent02:23
lifelessthewrath: be a couple of hours work top, at most.02:23
lifelessthewrath: anyway, why do you want this?02:23
poolieigc, re the revert patch02:23
thewrathlifeless: its for work02:23
pooliecan you try to add a blackbox test?02:23
fullermdI actually thought diff(1) had an arg to show the whole files, which would help with the last, but it doesn't seem to.02:24
pooliethere's a slim nonzero chance it'll break02:24
fullermdYou could fake it by asking for 99999 lines of context, I guess.  Would work on all those sub-100kLOC files.02:24
jmllifeless, https://bugs.edge.launchpad.net/bzr/+bug/392355/comments/102:25
ubottuUbuntu bug 392355 in bzr "C extensions placed in wrong directory" [Critical,Triaged]02:25
lifelessfullermd: we don'tsupport that argument, I don't think02:25
fullermdWell, but we could use the external diff, instead of the internal one.02:25
lifelessjml: so its broken for you too02:25
jmlyep.02:26
thewrathlifeless: can i sent you a pm02:26
lifelessthewrath: I guess02:26
=== BasicPRO is now known as BasicOSX
jmllifeless, does this critical bug mean I should use a chroot to rollout 1.16.1?03:02
jmlI guess I could always experiment.03:02
lifelessjml: the so's don't go in the tarball03:03
lifelessjml: so no special actions required there03:03
lifelesshowever johnf probably needs to know to build debs properly03:03
jmland all the C files go to the correct place, I see.03:04
lifelessjust popping out to the chemist03:24
lifelessbrb03:24
* spiv pops out for food03:45
=== abentley1 is now known as abentley
=== abentley1 is now known as abentley
lifelessdeep hack time04:18
lifelessSMS or ring if you need me04:19
=== r0bby is now known as r0bby|arr
=== r0bby|arr is now known as r0bby
poolielifeless: (realize you're away) fix for progress bar droppings pushed04:30
poolieyay hacks04:31
=== abentley1 is now known as abentley
lifelesspoolie: yay04:47
lifelesspoolie: do you need a review?04:47
poolieyes04:47
poolieis easy04:47
pooliei also need a lunch04:48
lifelessis it 'if count < 1: return' ? or something like that?04:48
poolieclose04:48
* jml sends a metronome email05:22
fullermdOh, good, the RC is on my mother's birthday.  Now I'll remember to call her.  Just don't slip the date!05:25
lifelessigc: may have found other latent commit bugs with this work :)05:31
igclifeless: I recall raising one or two when I was last looking in there05:33
pooliethanks lifeless05:44
jmlok. time to cut 1.16.1.05:51
jmlit's going to look a _lot_ like the current launchpad branch of bzr :)05:51
glyphjml: yay releases!05:59
jmllousy internet :(06:04
jmlglyph, Twisted should do time-based releases!06:04
glyphjml: you know what else06:05
glyphjml: Twisted should have a release manager06:05
glyphjml: and a hundred billion dollars.06:06
jmlglyph, and a pony06:06
jmlmaybe I'll steal the RM job from radix06:07
jmlif only I were less of a bum.06:07
glyphjml: well, relatively speaking06:10
jml:)06:11
jmlhas skip-dupes landed in bzr.dev?06:12
jmlhmm. computer says no.06:13
jmlthere's no bug associated with it either06:13
lifelessits not needed for 1.16.1 anyhow06:13
lifelessbecause 2a is not popular, and you're landing a separate fix that means skip-dupes isn't needed anyway.06:13
lifeless(needed in terms of 1.16.1 as a server, or locally)06:14
jmlok.06:14
jmlstill love merge --uncommitted.06:18
jmlwhen doing a point release...06:24
lifeless?06:24
jmlshould I change the introductory paragraphs?06:24
fullermdI make use of it in nasty and evil ways on many occasions.06:24
jmlin the NEWS file, that is.06:24
lifelessthe whichwhat?06:24
lifelessits a new release06:24
lifelessit should get its own intro06:24
jmlOK. That's not how 1.14 & 1.15 were done, but it is how 1.13 was done.06:25
jmlcan someone please look over the release announcement?06:31
jmlhttp://paste.ubuntu.com/203968/06:31
jmlpoolie, lifeless: ^06:34
lifelessnew codename needed I think06:42
lifelessand the top line should say 1.16.106:42
lifelessthis is a new release; 1.16 is the series06:42
lifelesspersonally, I don't htink you should be moving the bug block06:43
lifelessbig block*06:43
lifelessthat was the 1.16 release06:43
* jml tries to find prior art to copy from07:02
lifelessuse case for you07:02
lifeless'I am a debian user and I have 1.16 already'07:02
lifelessthey should see the new changes they are getting.07:02
vilahi all07:14
lifelesshai07:14
* vila stares at the restart button (triggered by the ssl update) :-/ What the hell these days !07:14
vilaback in a restart07:15
vilare-hi07:19
vilapoolie: ping07:28
jmlI'm off. Back later to finish the bzr 1.16.1 release.07:39
vilajml: excellent metronome mail !07:43
jmlvila, thanks.07:43
vilalifeless: still around for a quick chat ?07:46
lifelessvila: sure07:47
lifelesswhats up?07:47
lifelessjml: when you return, testresoureces has branches that need your personal touch07:47
=== cprov-afk is now known as cprov
igcnight all08:23
pooliehello vila!08:24
pooliejml, yes, really nice mail there08:24
pooliei mean the metronome one08:25
pooliejml, if you're still here, the release mail draft confuses me08:25
poolieit almost looks you you're marking all of the trunk changes as being in 1.16, which would either be inaccurate or a mistake08:26
AdysI got a centralized repo to which I was the only committer. someone has an --unchanged commit on it since a few hours. I try to push my work but I keep getting "branches have diverged"08:37
Adysbzr merge tells "nothing to do". bzr pull tells "no revisions to pull". bzr up tells "Tree is up to date"08:37
Adyswhat am I supposed to do?08:37
vilaAdys: You can either 'push --overwrite' or 'merge; commit; push'08:38
Adysmerge doesnt work =/08:38
AdysI dont know if its a bug08:38
Adysill try push --overwrite08:39
vilaAdys: wait08:39
AdysOk08:39
vila'push --overwrite' will ignore the --unchanged commit and make it hard to get back to, while 'merge; commit;push' will take into account08:40
vilaAdys: what do you want to do ?08:40
Adysvila, merge doesnt work08:40
Adysit tells "nothing to do"08:40
vilaAdys: It works then, doing nothing is sometimes the Right Thing :)08:41
Adyshm08:42
Adyshold on i screwed something up ...08:42
vilaAdys: What does 'bzr info' says ? Are you working with a standalone branch, a checkout ?08:42
Adysstandalone08:42
Adysuh, is there some way to undo a pull? =P08:42
vilaAdys: 'pull --overwrite'08:43
AdysYeah I just did that, it had an old location saved08:43
Adysthink I lost some code.. not a big deal08:44
vilaAdys: committed or not ?08:45
Adysyes08:45
Adyscommitted but not pushed08:45
vilathen it's not lost08:45
AdysHow do I get it back?08:46
vilayou have to find the revid you're interested in and pull it somewhere safe first (aka, not in your current branch)08:46
Adysokay08:47
Adysvila: I need to grab rev 525, but when I branch it it updates to rev 52408:49
vilause 'bzr heads --all' and see if you can find it back08:49
Adysfound it, what do I do now?08:51
AdysHEAD: revision-id: adys@azura-20090626072855-ze3ykij2nuraihhe (dead)08:51
vilaAdys: bzr branch <orig> -rrevid:adys@azura-20090626072855-ze3ykij2nuraihhe <recover>08:55
vilaAdys: replace <orig> and <recover> by valid and appropriate values08:56
AdysAh great stuff, thanks. :)08:56
jmlhello hello08:58
jmlpoolie, had a chance to sanity check?08:59
Adysvila: got it all sorted, thanks a lot!08:59
vilaAdys: Always happy to help (TM)08:59
Adys08:59
jmlgasp08:59
jmlunicode08:59
Adysgasp, customized keyboard layouts :D08:59
jmlbazaar-vcs.org appears to be down :(09:04
pooliejml, i don't think it is present...09:04
pooliestill checking09:04
pooliejml, srsl?09:04
pooliesrsly*09:04
jmlpoolie, yes, srsly.09:05
Peng_Indeed. Cool! Can't connect.09:06
jmlfixed09:07
jml(thanks elmo)09:07
Peng_That was quick. What was wrong?09:08
jmlbuggered if I know :)09:08
pooliejml, it certainly looks like it's not in there09:09
pooliei wonder how the text got into news?09:09
pooliejml i guess launchpad got fixed?09:09
jmlwhich bit of launchpad?09:09
elmoapache upgrade didn't restart cleanly; sorry about that09:10
elmopeng: ^--09:10
Peng_Oh.09:10
pooliejml, the appserver outage?09:11
jmlpoolie, yes. that got fixed09:11
jmlpoolie, what's the number of the bug that appears in NEWS that isn't fixed?09:14
pooliebug 37647809:15
ubottuLaunchpad bug 376478 in percona-xtrabackup "Specify Target Directory Name with innobackupex" [Undecided,New] https://launchpad.net/bugs/37647809:15
poolieyou cherrypicked trunk r447009:15
pooliewhich claims to fix that09:15
poolieah09:15
jmlhttps://bugs.edge.launchpad.net/bzr/+bug/37674809:15
ubottuUbuntu bug 376748 in bzr "after conversion chk formats are badly packed" [Critical,Fix released]09:15
poolieit might just be lack of cherrypick tracking...09:15
poolienormally people tend to merge the bugfix branch into the release branch rather than cherrypicking09:16
pooliebut it's a reasonable enough thing to do09:16
sorenCan I fake the timestamp on a bzr commit?09:18
jmlyes.09:18
soren(without changing my system clock)09:18
poolieof course in this case you couldn't because it was based off too late a version of trunk09:18
pooliesoren, yes09:18
sorenCool. How?09:18
jmlPython!09:19
jml(looking up the api)09:19
sorenI was afraid you'd say that.09:19
sorenOh, well.09:19
sorenHm... Doesn't look to hard at all.09:22
soren(famous last words)09:22
jmlsoren, yeah... I think I'd just hack something up based on cmd_commit().09:24
jmlpossibly even add an option to cmd_commit for the timestamp.09:24
jmlpoolie, so where were we?09:26
pooliei'd be ok with an option to cmd_commit09:26
pooliejml, it's in, and it seems like a reasonable thing to put in09:27
poolieso i think we're good to go09:27
jmlrock'n'roll.09:28
pooliespiv, still around? how did you go today?09:29
WyvernI have a question: I do bzr status and I get a lot of modified files, even though they haven't been touched. But they have an * at the end. What does that mean?09:37
bialixhelp form bzr hackers needed09:38
bialixsee http://pastebin.com/m40991c6609:38
bialixwhy I've got error?09:38
sorenjml: Oh. I was thinking of just calling bzrlib.commit.Commit.commit() from python with the right arguments. This is (hopefully) just a one-off thing.09:39
sorenjml: Oh, that is what you're suggesting as well.09:40
jmlsoren, basically, yes.09:40
* soren has not had sufficient coffee today.09:40
jmlsoren, although tweaking the commit command is probably even less work, as long as you don't bother with user-friendly parsing & data validation.09:41
jmlwhich you won't, because it's a one off thing :)09:41
sorenTrue, true :)09:41
Peng_Wyvern: The executable bit probably changed.09:45
WyvernIndeed! Thanks.09:47
Peng_jam: FYI, mail2.domainpeople.com yelled at me when I tried to send an email to you. (Nothing important, I just used Reply All on a mailing list post.)10:05
jelmeris CommitBuilder.record_entry_contents() going to be removed before 2.0 ?10:06
=== jml changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
jml*mutter mutter*10:19
jmlconflicts are teh suck10:20
sorenHow do I specify a base revision during a merge?11:07
sorenI'm trying to merge two trees that have no common ancestry (bzr-wise, but in the real world, they do), and "bzr merge" suggests that I can somehow do it anyway if I specify a base revision for the merge, but I don't see how to do that.11:08
spivsoren: "bzr merge -r0..-1" will allow you to merge unrelated (bzr-wise) trees11:11
spivsoren: because 0 is common to histories, in a sense.11:12
sorenYeah, I was hoping that would be the case (0 being everyone's grandparent).11:13
sorenhaha..11:13
sorenspiv: YEs, that seems to do the trick. Lovely. Thanks!11:13
=== mrevell is now known as mrevell-lunch
=== Xavura is now known as Xavura|busy
=== mrevell-lunch is now known as mrevell
=== nevans1 is now known as nevans
awilkinsabentley:14:44
abentleyawilkins:14:44
awilkinsabentley: How easy would "parallel" support be in bzr-pipeline?14:44
abentleyawilkins: Not terribly hard, but if the parallels ever met, that would cause criss-cross merges.14:45
awilkinsabentley: I posted to the list about supporting something similar in loom ; the idea of having a web of patch branches that all converge on a single "work" branch, with UI assistance for committing the correct hunks to the appropriate branch14:47
awilkinsLike Mercurial pbranches (only they don't have that UI support)14:47
abentleyawilkins: If by converge, you mean A -> B -> C, A ->D -> C, that would be very, very bad.14:47
awilkinsabentley: Because each branch would be receiving the same merges from the base branch?14:48
abentleyawilkins: Well, let me think about this.14:50
awilkinsFor reference : http://arrenbrecht.ch/mercurial/pbranch/14:50
abentleyawilkins: You get criss-cross when you merge in an inconsistent order, and thereby repeat the merge of revision X with revision Y in two places.14:51
abentleyawilkins: It may be that a pipeline can prevent that, but I'd have to think about it.14:51
awilkinsabentley: I have this mental picture of a commit dialog in qbzr where the patch is on the left and there is a radiobutton column on the right for each patch branch and you select which hunk goes where.14:54
abentleyawilkins: I've never been a fan of selective commit, but I can envision adding it to the uncommitted changes of that pipe.14:55
awilkinsabentley: Does each pipe have a working tree?14:56
abentleyawilkins: No, each pipe has a shelf.14:56
awilkinsabentley: That sounds like the implementation I had in mind ; shelve the changes and switch-unshelve-commit for each branch14:57
awilkinsabentley: I just don't have the time to actually write it though14:58
abentleyawilkins: I'm suggesting that the user would still commit the changes, rather than having it happen automagically.14:58
awilkinsabentley: I can see that working as long as you're not allowed to commit to a branch that depends on branches with shelved changes15:01
abentleyawilkins: I think that restriction would not be workable.15:02
awilkinsabentley: How do you cope with the scenario when you want to commit C, and B has changes in it's shelf ; the changes are presumably in the working tree of C also, and you've just committed them?15:03
kfogelabentley: how can I tell if a given installation of bzr is built with the C extensions?15:03
awilkinskfogel: Presence of .pyd files15:03
abentleyawilkins: It would be unusual for the changes to be in the working tree of C also.15:04
kfogelawilkins: thank you.  where would they be?   (some python path on my system?)15:04
awilkinsabentley: I thought A -> B -> C ... doesn't that imply that the changes from B are in C and C may even be dependant on them15:04
awilkinskfogel: They should be in the bzrlib folder15:05
kfogelawilkins: thanks15:05
awilkinskfogel: "lib" on Win32 bzr.exe, %PYTHON%/lib/site-packages/bzrlib for win32/python15:05
abentleyawilkins: No, it doesn't imply that.  When you want that to be true, you run the "pump" command.  That merges from A->B->C, but it doesn't do anything with uncommitted changes.15:05
awilkinsabentley: I'll have a play with bzr-pipeline for a bit and think some more15:06
awilkinsabentley: It sounds like I'm not totally grokking the way it work15:06
awilkinsabentley: Is there a good source of documentation besides the help? I've only found the launchpad page (after seeing it mentioned o the mailing list)15:08
abentleyawilkins: The way it works is, you're hacking on something in A, then you realize you need to fix B.  You switch-pipe B, which automatically stores the uncommitted changes in A.  You fix B and commit.  You switch-pipe back to A, which restores your changes.  You finish hacking in A.  You pump, which applies the changes in A to B, and the changes in B to C.15:08
abentleyawilkins: "bzr help pipelines" is the main documentation.  There's also a comparison with looms in pipeline-and-loom.txt in the source tree.15:10
kfogelawilkins or abentley: if I have done a long-running 'bzr upgrade --2a' to get a tree to 2a format, and I *think* it completed (but for various reasons am not sure), is there some command I can run to verify, other than 'bzr info -v' ?15:10
awilkinsabentley: That help topic doesn't seem to be in the lp:bzr-pipeline trunk15:10
abentleyawilkins: Sorry, "bzr help pipeline"15:10
awilkinskfogel: On the same topic, I've been running --2a conversions and getting segfaults on windows where it just fails silently, so I'm no help here15:11
kfogelawilkins: ugh.  no useful trace?15:11
jamPeng: I believe my mail host no longer allows direct emails from people, you have to go through official ISPs15:11
abentleykfogel: bzr info -v won't tell you whether it's well-formed.  You would need to run "bzr check" for that.  (Which takes a verry long time)15:11
awilkinskfogel: Just a minidump and an offset in the groupcompress extension15:12
kfogelabentley: 'bzr check' time comparable to the original 'bzr upgrade' time?15:12
awilkinskfogel: I'd make a trivial branch and upgrade it to 2a to see what the successful log output looks like15:12
kfogel(because that was almost 4 days)15:12
abentleykfogel: worse.15:12
kfogelabentley: holy cow15:12
awilkinsabentley: Ok, it still sounds compatible with my intentions as long as the criss-cross merge is dealt with15:14
awilkinsabentley: Because you would actually be working in C, you know how the merged output should look because it's what you actually wrote, so does that make it easier?15:15
abentleyawilkins: I don't know what you mean by "you would actually be working in C".15:16
awilkinsabentley: You have pipes   A > B | D > C15:16
awilkinsSo when you pump, changes in A are merged to B and D and then C15:17
awilkinsSo you end up with two merge revisions being merged to C and they are a crisscross merge15:17
awilkinsIf you are editing in C and your "chunk selective commit" has directed some changes to go to A, some to B and D (and none to C because it's just a convenient tip to amalgamate patches)15:18
abentleyA > B, D > C does not lead to a criss-cross merge.15:18
abentleyawilkins: Why would changes from B be merged into D?15:18
awilkinsabentley: Not from B to D15:19
abentleyThat would be a linear pipeline of A > B > D > C15:19
awilkinsA to B and D15:19
awilkinsB to C, D, to C15:19
abentleyawilkins: So you really men A > B,  A > D > C?15:19
awilkinsabentley: And B > C also15:20
awilkinsIncluding an additional revision of changes to B and/or D15:20
abentleyawilkins: As long as the parallel lines don't merge from one another, I'm not sure that leads to a criss-cross.  But I still need to think about that.15:21
abentleyawilkins: In any case, if you pump from A, you're not necessarily "working in C".  That would only happy if conflicts were encountered merging into C.15:22
awilkinsabentley: I'm thinking ; edit with the lightweight checkout aimed at "C" ; commit chunks to A, pump15:23
awilkinsabentley: Because you're editing in a checkout of C, you know how the end state of the tree should look, so you either don't have conflicts or you know exactly how to resolve them before you start the merge15:24
awilkinsI'm not sure you don;t have conflicts 100% of the time15:24
abentleyawilkins: If you're in C and you pump, that will do nothing, because you pump from the current pipe to the following pipes.15:24
abentleyawilkins: If you're in C, you can't commit chunks to A.15:24
awilkinsabentley: Edit in C : special-multi-pipe-commit to A (shelve ; switch A ; commit ; pump)15:25
abentleyawilkins: You're now in A.15:25
abentleyNot working in C.15:25
awilkinsabentley: Automating this is what I'm driving at ; all the dancing up and down pipes handled in software15:26
awilkinsSo after, switich to C (which got your changes merged upward by the pump)15:27
awilkinsSo the intent is "I always want to work in a tree that looks like it would with all my patches applied, but I want to be able to commit to each of my patches separately"15:28
abentleyawilkins: I'm not in favour of committing changes to A without even having looked at A with those changes.15:28
awilkinsI agree that there is potential hairiness there15:28
awilkinsI think the add-to-shelf approach has merits too15:30
awilkinsIt makes things a little less quick, but I agree it adds safety15:30
awilkinsMy concern with it was that if you have a bunch of changes hanging around in a shelf, they are not committed in the branch you intend them for, they are in it's shelf. You may commit the changes to descendants of that branch ; not entirely a disaster because if you merge them from beneath later they are just a no-action merge.15:32
abentleyawilkins: I don't think it's likely that you would commit the changes to descendants of that branch.15:33
awilkinsabentley: Have you removed them from the tree when you shelved them to that branch?15:34
abentleyawilkins: yes.15:34
dashhmm, i have not heard of bzr-pipeline before. is it a thing like loom?15:34
awilkinsabentley: So now your work cannot continue until you visit A and commit/pump yes?15:34
abentleyawilkins: Your work would only be unable to continue if all the changes you wanted to make depended on the shelved changes.15:35
abentleydash: yes.15:35
dashi've been using loom a lot this week15:36
dashi've been wondering if something better was possible. :)15:36
awilkinsdash: Looks like you walked into the right discussion ; I'm likeing pipeline so far in that I have the impression that it implements the features of looms by manipulating standard branches (?)15:37
abentleydash: As a contributor to loom and heavy user, I think something better is possible, and pipeline is my attempt to achieve it.15:38
=== abeaumont_ is now known as abeaumont
abentleyawilkins: It does manipulate standard branches.  The feature parity is not exact, and that's deliberate.15:39
lifelesspipeline is interesting; If I read the code right it has strong parallels to topgit15:39
* awilkins adds another mental bookmark to review15:40
lifelessdash: have you been liking loom?15:40
dashlifeless: Mostly.15:40
awilkinslifeless: I've shied away from using it because of the stacked branches design15:41
dashMy use case lately has been dealing with code at work where a snapshot of a public SVN repository was taken, checked into a company-internal SVN repo, and both were modified independently for about three months15:41
dashand now I am trying to reconcile the changes15:41
lifelessawilkins: sit in top tree, commit to arbitrary 'patch' - thats a goal I have too, for both generic bzr and looms; but requries care because it is conceptually bad (committing untested code). Howver some folk really do want it15:41
dashand, in particular, stratify them into independent patches15:42
awilkinsMy use case is a software project in an SVN repo which I sync periodically15:42
awilkinsI tidy the code and document it and also write patches15:42
lifelessdash: I find shelve very useful there15:42
dashlifeless: yes. using shelve a lot too.15:42
lifelessdash: commit -i and a split-commit command would be nice15:42
dashyeah15:42
awilkinsBut I don't want things to be dependant on each other (in terms of DAG)15:42
lifelessanyhoo, its past midnight15:43
dashshelve is a little awkward when dealing with 200+ diff hunks :)15:43
lifeless-> sleep15:43
dashI find myself alternating between diff-based and pack-based shelve15:43
awilkins"conceptually bad (committing untested code)" ; I don't think committing untested code is bad, as long as it's plain you're not committing to a branch that will be shipped untested ; AFAIK the Bazaar development process handles this by testing merged revisions before it commits them and that's the place to be15:45
awilkinsEAch time I try pack-based shelve on win32 it's failed so far15:45
awilkinsThe merges I've submitted to Bazaar have included revisions that definitely didn't pass testing because I separated the commits into one revision for the tests that exposed a broken feature, and one that fixed it.15:46
awilkinsBut the merge revision is the one that counts for testing purposes15:46
dashawilkins: yeah, that's the workflow i'm familiar with from svn15:47
awilkinsAnyway ; so, I want to be able to submit patches to my foreign SVN repo without cherrypicking out changes from branches lower in the loom15:48
dashhm.15:58
dashi'm not familiar with doing that15:58
dashso far i've just used 'bzr diff -rthread:' to create patches to send in15:59
awilkinsdash: I created a branch from HEAD of trunk, cherrypicked the patch into it, and pushed it to trunk using bzr-svn16:00
awilkinsdash: Does each thread only list the changes it introduces when you do that or do you get the threads beneath it?#16:03
dashit's the diff between the thread and the one below16:05
awilkinsI suppose that works, in a pinch16:06
awilkinsDoesn't account for diffs to things that were changed by the thread below with respect to trunk though16:06
dashwell right16:07
dashbut i've always envisioned a loom as a stack of patches16:07
awilkinsThe topgit README also makes it sound like the feature I seek!16:07
awilkinsYes, that's the thing that puts me off using it - I have no idea what order I want to put patches in16:08
dasha diff against the bottom thread would include all the changes of the intervening thread16:08
dashwell, they have to go in some order :)16:08
awilkinsYes, but I don't want to have to decide what order before I merge them, before I've even started writing them16:08
awilkinsTopGit readme is very dry and needs more pretty ASCII art like Mercurial pbranches16:11
abentleyawilkins: changing the order of pipes would not be easy, but it's theoretically possible.16:15
awilkinsabentley: Would that involve a lot of rebasing?16:19
abentleyawilkins: No.16:19
awilkinsabentley: I can't think of a way to do it without rebasing ... but now I have to go and pick my wife up from the station, so I'll think about it on the way.16:21
=== awilkins is now known as awilkins_train
abentleyawilkins: Merging.16:21
awilkins_trainINcluding reverse merging?  (now I'm really gone)16:21
infinitySo... At the risk of looking like an idiot, has anyone else noticed bzr 1.16 spamming "unsupported locale" warnings when running under any locale other than en_GB.UTF-8 or C?16:36
infinity(And yes, I have several other locales generated and usable by everything else)16:36
mneptokinfinity: WFM in Klingon. but then, i always challenge such error messages to personal combat with bat'leth.16:43
infinityReproduced here on an up-to-date karmic (times two), and a jaunty with the PPA 1.16 installed.16:48
infinityTo be fair, didn't test EVERY locale, but en_US and en_CA are both grumpy and both quite obviously working in other apps.16:49
radixis there a way to apply shelved changes without removing them from the shelf?16:55
radixI guess not, since there's no parameter that indicates that possibility.16:59
Takhmm, a `bzr branch` from an svn repo seems to have gotten me some ancient files17:10
radixTak: which don't show up in "svn ls <svn-branch>"?17:18
Takno, I mean they're not current17:19
radixoh, I see17:25
Peng_jam: Oh, OK. It was an ISP, though. A stupid cheapo shared host, but they still count. :D17:36
jamPeng_: I don't really know the answer, but I've gotten similar messages emailing vila from my home machine17:39
jamI had to proxy through my ISP to get it to work17:39
jamI don't know why they would reject you17:40
Peng_jam: Well, okay. Anyway, I just wanted to alert you if necessary. :)17:41
jamI didn't want your email anyway :)17:41
jamI'm just hiding behind my mail host17:42
Peng_Heh.17:43
jamLarstiQ: I don't see jelmer around, but I had a question about what I should be bundling in the win32 installer17:44
jamjelmer mentioned something about changing bzr-rebase => bzr-rewrite17:44
jamand I don't really know what the latest versions of17:44
jamrebase/rewrite, svn, subvertpy etc are17:45
jamany ideas?17:45
* Peng_ runs them all from source. :P17:47
Peng_s/source/bzr/17:47
jam*arg***17:54
jamIt seems the project is now called "bzr-rewrite"17:54
jambut the *tag* is "bzr-rebase-0.5.1"17:54
jambad jelmer, no biscuit17:54
jamah well, I can cheat easily enough17:55
kirklandwhen using bzr export ../foo.orig.tar.gz ... is there any way to --exclude a file from being exported?17:58
jamhmm... seems "cd bzr-rewrite; py setup.py install" still installs itself as 'rebase' as well.18:07
jamweird18:08
=== awilkins1train is now known as awilkins
Peng_jam: FWIW, I still call it "bzrlib.plugins.rebase" and it doesn't mind, so maybe you should stick with rebase for now.18:14
Peng_jam: Obviously it would be best to ask jelmer. :D18:14
jamyeah, I'm sticking it where it wants to be18:14
jamjust seemed wrong18:14
jamprobably just an incomplete conversion at this point18:14
=== Kissaki^0ff is now known as Kissaki
Peng_Stupid question: Have enough 2a bugs been fixed that it's reasonably to dogfood it, and interact with different formats over the network?18:49
bpierrehi19:05
rellis__Anyone know what the right path is to obtain loggerhead 1.2.1?19:39
Peng_...1.2.1? Isn't that from the 1990s?19:42
rellis__yeah im thinking the same19:42
Peng_Why?19:42
rellis__my boss asked me to do this so im sort of flying blind19:42
rellis__disregard my question19:42
Peng_Wouldn't you want something...modern?19:42
rellis__yeah indeed i do19:42
rellis__i want absolute current19:42
Peng_rellis__: bzr branch lp:loggerhead :D19:42
rellis__hehe alright19:42
rellis__thanks19:43
Peng_Guaranteed to partially work at least 14% of the time!19:43
rellis__what more could i ask for?19:43
flvr8does 1.16 work more than 14% of the time :) ? we're seeing a couple bugs with 1.1019:46
Takupgrading to 1.16 seems to have fixed my issue with the svn branching19:47
rellis__Tak: Do you know the path to checkout 1.16 specifically?19:49
rellis__or is it just trunk?19:49
Takeh, I used the release download19:49
rellis__huh i missed that on the site i guess19:50
Peng_OK, are we talking about Loggerhead or Bazaar now?19:50
rellis__loggerhead19:51
rellis__yeah that's exceptionally confusing =p19:51
Peng_rellis__: 1.16 hasn't been released yet. It's just the trunk.19:51
rellis__okay nifty19:51
Takoh, yeah, I'm talking about bzr, sorry19:52
Peng_flvr8: Are you talking about Loggerhead or Bazaar? If LH, which bugs? Have you filed reports?19:52
rellis__np :)19:52
Peng_The trunk has a tendency to randomly break sometimes (cough test suite cough), but it fixes lots of things.19:53
flvr8peng - loggerhead as well. (i work with rellis). haven't yet filed a bug, but when we browse to one of the repositories we get an error (for which i haven't yet filed a bug):19:53
flvr8An unexpected error occurred whileproccesing the request: KeyError: ....19:53
Peng_flvr8: I think some KeyErrors have been fixed, but my memory is fuzzy.19:54
flvr8ok, we'll check out trunk and see19:54
Peng_I know an *IndexError* was fixed a while back, but that bug was introduced in the trunk. :P19:58
rellis__So  bzr branch lp:loggerhead should give me current 1.16 development work right?20:01
rellis__The readme says 1.10 so it's a little confusing..20:02
Peng_rellis__: Yeah. Seems nobody updated the version number20:03
rellis__fair enough :)20:03
rellis__Peng: I'm seeing ImportError: No module named main trying to fire up the new serve-branches from trunk... do i need to install some prereq's?20:14
Peng_rellis__: Yeah. See the README. Uh, Paste, SimpleTAL and simplejson (on Python <2.6) are the necessary ones.20:16
rellis__hmmm thought i had those20:16
rellis__i'll reverify20:16
Peng_rellis__: Oh, crap. I didn't see the "main" bit.20:16
rellis__yeah that threw me20:16
rellis__made me think it was something internal20:17
Peng_rellis__: It is. ISTM serve-branches is finding an old copy of the "loggerhead" package.20:17
rellis__ahh gotcha20:17
rellis__hmmm20:17
sanjaysHi20:20
sanjayslooking for a seeming python dependency issue at Loggerhead / Bzr20:26
rellis__When I try to use loggerhead against one of my projects I get this error.. KeyError: 'someguy@somebox-20090314122230-5ds8oco7g27p9ukx'20:46
rellis__any idea what causes this?20:46
rellis__This is the full error from the loggerhead log file.. http://www.pastebin.ca/147580720:49
Peng_sanjays: Aye?20:52
sanjaysya20:53
Peng_sanjays: What's the issue?20:53
sanjayshad a particular problem with loggerhead as frontend  of BZr repository20:53
sanjaysafter import by developers it cannt show the trunk20:54
sanjaysi will tell u the exact error if that helps20:54
Peng_rellis__: That error isn't familiar to me. Upgrading is all I can suggest.20:55
rellis__fair enough peng20:55
rellis__it's the same erro sanjay's refering to20:55
Peng_Oh.20:55
rellis__Peng would you expect the python module for loggerhead to still register as 1.10 like the readme file?20:56
rellis__We did a trunk checkout then installed and we see 1.10 listed everywhere..20:57
Peng_rellis__: Yeah, it still thinks it's 1.10.20:57
rellis__cool20:57
jhhi, I did a 'bzr pull --overwrite' and get a text conflict... how is that possible?21:16
beunojam, hi21:24
beunostill around?21:24
beunoI've got an interesting traceback where check blows up, and reconcile finds nothing21:25
beunohttps://pastebin.canonical.com/19049/21:25
beunolifeless, maybe you're around and bored on a saturday ^21:25
beunoI'm probably going to file a bug, but I'd like to see what's interesting to add to the bug info21:25
jambeuno: yeah22:16
jamwas afk for a bit, though :)22:16
beunojam, filed as 39269822:16
jambug #39269822:16
ubottuLaunchpad bug 392698 in bzr "bzr 1.16 blows up on upgrade or check" [Undecided,New] https://launchpad.net/bugs/39269822:16
jambeuno: and it dies on upgrade as well?22:17
jamat least it looks like you have a missing text in your repository22:17
jamthe inventory wants "(file_id, revision_id)"22:17
jambut the repository says "I don't have that"22:17
jamAFAIK, there isn't much reconcile can do22:17
jamas it can't *create* the file for you22:17
jamnow, if we have the sha1 sum, we could probably fake it22:17
beunojam, it dies on both upgrade and check22:19
beunoit's odd that *this* branch is broken, since there hasn't been anything fancy done to it22:20
beunoI'm less interested in fixing it, and more in debugging why it happened22:20
beunoit's history isn't terribly important to me22:20
* beuno is in the process of upgrading the remaing ~60 branches at the office to 2a22:23
beunoonly that branch failed up to now22:23
beunoand it has to be something that happened from 1.9 to now, which I upgraded a few months ago22:23
beunoso it's a bug in bzr 1.13+22:24
jambeuno: see my comment22:29
jamIt was probably a bug in a really old version22:29
jamthat generated a slightly bogus inventroy22:30
jamand bzr 1.12 or so wouldn't have fetched the data properly22:30
jamto handle the really old problem22:30
jam1.13+ should handle it more correctly now22:30
jamI'm not 100% sure when the fix landed, but the fix was written by lifeless at rev: robertc@robertcollins.net-20090310065003-a57qlol97z6ohczi22:31
beunojam, so is there anything I can do to provide useful information here?  or just delete, init, and move in with life?22:32
beuno*on22:33
jambeuno: I have a theory about what happened, but it is pretty difficult to prove or disprove...22:33
jambeuno: is this a branch with a separate repository?22:34
jamIt might be interesting to see what "bzr log -r revid:'martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo'" says22:34
jamor even "bzr log -v"22:34
jamor bzr log -v --show-ids22:34
jamto see if 'wiki_icon.gif-20070525002152-lu3yrapgr7a4d8dp-75' was modified in that rev22:34
beunojam, it's a standalone branch22:34
beunolet me try that...22:35
jambeuno: do you have more branches of this project?22:35
jamNote that the dates are ~ the same22:35
beunojam, probably not anymore, no. It hasn't been touched in a while, so developers likely deleted them locally22:35
jamand that -75 means this was the 75th file to be added in this commit22:35
jamwhich means it sounds a lot like something that was approximately the initial commits22:35
jamAmazing what info you can glean from non-random revision ids :)22:36
beunobzr: ERROR: Requested revision: u'revid:martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo' does not exist in branch: BzrBranch7('file:///var/www/ellatinoamericano/')22:36
=== Kissaki is now known as Kissaki^0ff
jambeuno: interesting, sounds like a ghost rev then22:37
jamwonder how that happened22:37
jambeuno: there is something weird about 20070525002500220522:37
jamare you sure that was cut & pasted correctly?22:37
beunoyeap22:38
jam2007-05-25 00:25:00: 220522:38
beunoKeyError: ('wiki_icon.gif-20070525002152-lu3yrapgr7a4d8dp-75', 'martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo')22:38
jamstill too many digits22:38
beunobzr log doesn't blow up22:38
jam2009-06-26 18:03:3122:38
beunobzr revision is from 2007-07-1122:39
jam2009062618033122:39
jam20070525002152 => 2007052500215222:39
jam2007-05-25 00:21:5222:39
beunoneither does bzr log -v -n022:39
jamlooks like we generally used date to seconds22:39
jamwhich would be:22:39
jam2007-05-25 00:25:0022:40
jamor22:40
jammartin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo22:40
jambeuno: can you try "bzr log -v --show-ids -r revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo" ?22:40
beunojam, I can upload the repo for you, it's private-ish, but not critical, so it's ok for you to look at it22:40
jambeuno: devpad would be fine22:40
beunomalbisetti@pentaserv:/var/www/ellatinoamericano$ bzr log -v --show-ids -r revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo22:40
beunobzr: ERROR: Requested revision: u'revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo' does not exist in branch: BzrBranch7('file:///var/www/ellatinoamericano/')22:40
jambeuno: alternatively "bzr log --long --show-ids | less" and search for 22qo22:41
jambut I can do that22:41
=== vxnick is now known as vxnick-AFK
jamI want to know who this latin american is... so yes, please upload :)22:41
beunoheh22:42
jamalternatively, create a tarball, gpg sign it to my pub key22:42
jamand upload it wherever you want22:42
beunoit's about 14mb22:42
beunouploading...22:42
beunoit should be about 6 minutes22:45
beunojam, https://devpad.canonical.com/~beuno/ellat.tgz22:50
beunojam, I'm also curious as to why it failed now, and not when I upgraded it to 1.922:52
jambeuno: upgrade to 1.9 doesn't do much but change the indexes, IIRC22:52
jamas in, it doesn't have to check every text, etc22:52
jamit just rewrites what is there to be a btree rather than a KnitIndex22:52
jambeuno: *especially* if you used the fast-path writer that I had written22:52
beunoah22:53
beunoI didn't22:53
beunobut I see what you mean22:53
jambeuno: it is also possible that the upgrade itself is the part that broke things22:53
jamit just didn't care that the text was missing22:53
jambeuno: I get "not in gzip format"22:53
jamis it encrypted?22:53
jamor is it bzip2 ?22:54
beunouhm, no, should be tar.gz22:54
beunoargh22:54
beunoseems broken22:54
jamit is just tar22:54
jamno gz22:54
beunodid you manage to unpack it?22:55
jambeuno: "tar xvf ellat.tgz" worked22:55
beunocool22:55
beunoI missed a flag then  :)22:55
mzzI think I've had firefox automagically decompress things for me when downloading from some servers. I tend to just always use "tar xf" to extract, modern versions of gnu tar don't need the j or z flag, they autodetect if you omit22:56
jambeuno: something very weird22:57
jamah just a sec22:57
jammissed a flag22:57
jamforgot you now need -n022:57
beunoyeah  :)22:57
jambeuno: so something very strange after all22:58
jamaccording to 'bzr log' the first revision is22:58
jam2007-07-1122:58
jambut your error is on a file with22:58
jam2007052522:58
beunoha22:58
jamand a commit around22:58
jam2007052522:58
jamso somehow your branch has a revision that existed... 1+ months before the branch22:58
beunowell, FWIW, that branch was re-inited at some point due to breackage22:58
beunobut the bzr dir was probably killed, and init + added everything22:59
beunomaybe someone merged it in that had the old branch?22:59
jamI do see a revision present:22:59
jam ('martin@pentacorp.net-20070525002205-ybn9m9tqnxu122qo',),22:59
beunoit wouldn't of let them I guess, since there's no common ancestors22:59
jamwhich probably isn't in the ancestry of the branch23:00
jambut is present in the repo23:00
beunothis is getting stranger as we go  :)23:00
jambeuno: so I can do "bzr branch -r revid:'martin@pentacorp.net-20070525002205-ybn9m9tqnxu122qo' . ../ellat2"23:01
jamand then I see23:01
jam$ bzr log ../ellat2/23:01
jam    1 Martin Albisetti  2007-05-2423:01
jam      inicio23:01
jamso *my* guess is that *you* are responsible :)23:01
jambeuno: and if I look at "bzr log -v --show-ids" for that revision23:02
jamI also see what I expected23:02
jamnamely, the file23:02
jamthe file-id matches23:02
jamonly notice that the revision id is different than what you gave as an error23:02
jam2007 05 25 00 22 0523:02
jamwhere you had 2007 05 25 00 22 00 ...23:03
beunoheh, it was 2007, I was doing all kinds of crazy things (?)23:03
jambeuno: I see the same error23:03
beunowooo, finished upgrading all branches, that was the only one that exploded23:05
beunopretty impressive considering we've been using bzr since 0.1223:05
jambeuno: so my guess is that the original commit was bogus23:06
jamwhich is why you started over23:06
jamif you do "bzr branch ellat ellat2"23:06
jamyou should probably be able to upgrade ellat223:07
jamas it will have pruned out the bogus revision23:07
beunocool, easy peasy23:07
beunois there anyway reconcile could tackle this in the future?23:08
beunojam, you're right23:10
beunooddly enough23:10
jambeuno: so... something still strange. In that I get the same failure23:10
beunocheck finds 81 revisions on the borked one23:10
jambut I don't see any way yet for it to occur.23:10
beunoand 57 on the branched one23:10
jamso maybe it is a different rev which is broken23:10
beunojam, upgrading went fine on the newly branched one as well23:11
beunothe 81 vs 57 revs is intriguing23:12
jambeuno: anyway, I'm off for now23:12
jambut I find the bogus text in the inventories of 20 revisions23:12
jambeuno: https://pastebin.canonical.com/19053/23:13
beunojam, cool. Hope it helps at all, and thanks for the workaround23:13
beunohave a nice weekend23:13
jamwhich is probably the 20 or so that aren't in the branch anymore :)23:13
abeaumontvila: ping23:39
lifelessbeuno: ?23:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!