[01:03] <Noldorin> hey jelmer
[01:16] <poolie> hi Noldorin
[01:16] <Noldorin> hi poolie
[01:19] <Noldorin> poolie, good job on 2.5 so far. working nicely so far, and liking the co-located branches support
[01:19] <poolie> great
[01:19] <poolie> thanks
[01:19] <Noldorin> is it going to be part of core in the RTM?
[01:20] <poolie> yes it should be
[01:20] <Noldorin> ah good
[01:21] <Noldorin> when jelmer gets round to fixing up the last few nags with bzr-git, mirroring should be a breeze
[01:30] <Noldorin> poolie, oh, and is the url format for colocated brnaches being improved?
[01:35] <poolie> improved meaning shorter?
[01:35] <poolie> i'm not completely sure
[01:35] <Noldorin> poolie, indeed. just replacing ",branch=" with "," i mean
[01:35] <poolie> not sure
[01:36] <Noldorin> i think i submitted the bug for it a while ago. not sure though
[01:45] <Noldorin> ok
=== aurora|nap is now known as AuroraBorealis
[06:18] <vila> hi all !
[06:18] <poolie> hi vila
[06:19] <vila> poolie: 1 on 1 ? mumble ?
[06:38] <poolie> oh hi
[06:38] <poolie> bah, vila, sorry, sure, mumble would be good
[06:39] <vila> :)
[06:41] <vila> hmm, if mumble can start...
[07:18] <poolie> vila, so something like
[07:18] <poolie> judge 'bzr2.4 st' 'bzr2.5 st'
[07:38] <Merwin> Hi, I got a very strange problem :
[07:38] <Merwin> thibaut@thibaut-VirtualBox:~/OpenERP 6/Logica/addons$ bzr resolve --all --take-other
[07:38] <Merwin> bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]
[07:38] <Merwin> What does it means ? :-/
[07:39] <poolie> Merwin, hi, it's a bug, perhaps due to you trying to resolve some unusual merge state
[07:39] <poolie> i don't recall seeing that before
[07:40] <poolie> vila, do you?
[07:40]  * vila fighting silly bt mouse
[07:40] <vila> Merwin: it's a bug
[07:40] <Merwin> I'm using bzr 2.4.1 on Ubuntu
[07:40] <vila> 'Tree transform is malformed' is *always* a bug
[07:41] <Merwin> So, how can I do ? Should I upgrade bzr ?
[07:41] <vila> Merwin: file a bug specifying which branches you were merging and the precise revids involved so we can reproduce it
[07:42] <Merwin> Unfortunatly, I can't. My company don't want us to release the sources right now :/
[07:42] <vila> Merwin: resolving the conflicts one by one may work around the issue
[07:42] <vila> ha, well, that makes it harder to fix the bug then :-/
[07:43] <AuroraBorealis> i'm sure they won't do anything with it
[07:43] <Merwin> AuroraBorealis: I'm sure too, but I want to keep my job :p
[07:43] <AuroraBorealis> ask maybe?
[07:43] <Merwin> They have been clear about this
[07:44] <AuroraBorealis> ITS LIFE OR DEATH MAN
[07:45] <Merwin> vila: May the bug have already been fixed ?
[07:45] <Merwin> I mean, in a moire recent bzr version
[07:45] <AuroraBorealis> doesn't hurt to try
[07:45] <vila> Merwin: let me check
[07:45] <vila> Merwin: but yeah, if you can test with a more bzr version that would also help
=== michaelh1|away is now known as michaelh1
[07:47] <Merwin> Ho I'm stupid the branch is not one of ours
[07:47] <Merwin> I will update it, but it's a hudge branch
[07:47] <AuroraBorealis> well its still causing a bug o.o
[07:48] <Merwin> How can I send it to you? Should I zip the folder ?
[07:48] <vila> Merwin: a quick inspection of the bugs fixed since 2.4.1 reveals nothing obviously related
[07:49] <Merwin> vila: Ok. I can send you this branch, just tell me how :)
[07:49] <vila> Merwin: no need to zip  and send huge amount of public data ;) Just file a bug, mention the branches involved and the revids
[07:49] <Merwin> The branch is not on lp
[07:49] <Merwin> How could you test it ?
[07:49] <vila> https://bugs.launchpad.net/bzr/+filebug
[07:50] <vila> are the branches public (I can access them) or not ?
[07:50] <Merwin> Not
[07:50] <Merwin> And the dir have a 633MB size xD
[07:51] <vila> unpractical then :)
[07:51] <Merwin> I will push it on lp
[07:51] <poolie> Merwin, just the traceback would be a reasonable place to start
[07:51] <poolie> you don't need to attach the whole thin
[07:52] <vila> g
[07:52] <Merwin> poolie: I've no traceback, just the message I showed you, unless I have somthing to run in "debug" mode ?
[07:52] <poolie> there will be a traceback in ~/.bzr.log
[07:54] <Merwin> Ok, I'll post it
[07:57] <Merwin> poolie, vila: https://bugs.launchpad.net/bzr/+bug/880701
[07:57] <ubot5> Ubuntu bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [Undecided,New]
[08:01] <mgz> morning all
[08:01] <Riddell> hi mgz
[08:06] <vila> mgz, Riddell : hi !
[08:06] <vila> Merwin: please also mention the output of 'bzr st'
[08:06] <Merwin> ok vila
[08:09] <Merwin> vila: Done
[08:12] <Merwin> Hum, I just saw in bzr st that there were some .OTHER file 'added', wtf
[08:13] <vila> yeah, wtf indeed ;) I think it's due to a 'parallel import' where the same files have been added in the two branches,
[08:14] <vila> are seen as different (even if their content is the same) due to a known glitch in the way bzr tracks renames
[08:14] <Merwin> I never did a bzr add of this files, I'll revert and do the merge again
[08:14] <vila> Merwin: try resolving the conflicts one by one
[08:15] <Merwin> vila: How can I see a list of the versionned files ?
[08:15] <vila> bzr ls --versioned -R
[08:16] <vila> Merwin: in general, *never* use 'bzr resolve --all' it's not meant to be used to resolve "regular" conflicts but to just *delete* them relying on the user to have resolved them
[08:17] <vila> s/to have resolved/having resolved/
[08:17] <Merwin> vila: But here I have 51 conflicts without any conflicts to resolve, just a BASE and an OTHER files, I don't know why because I never modified these files
[08:18] <Merwin> bzr ls --versioned -R | grep OTHER returns nothing after a revert
[08:18] <Merwin> So files are added during the merge -_-
[08:18] <vila> Merwin: they are so-called 'Content conflicts' where the same path is used for files which are seen different by bzr
[08:19] <vila> bzr help conflict-types
[08:19] <vila> Merwin: or also when files are deleted in one branch but modified in the other
[08:20] <Merwin> humf
[08:20] <Merwin> No shortcut to reolve the 51 conflicts in one command without using --all ? :D
[08:22] <Merwin> vila: I already got some "Content conflicts" from the same files last time I merge, will this happen every time ? How could I fix it ?
[08:22] <vila> Merwin: ECONTEXT, I can't say for sure without knowing more about why these conflicts occur
[08:23] <vila> Merwin: just using 'bzr resolve --take-other' should work (but they were bugs in the past about that, I'm not sure we fixed them all)
[08:24] <vila> Merwin: so resolving them one by one is the safe path
[08:24] <Merwin> ok
[08:30] <Merwin> vila: I got the same eeror  for each file
[08:30] <Merwin> Resolving one by one doesn't solve the problem :/
[08:30] <vila> o.0 highly unexpected
[08:31] <vila> Merwin: can you post the traceback for one of these single file attempt ?
[08:31] <Merwin> yep
[08:32] <Merwin> lol lp down :p
[08:33] <vila> it's back
[08:34] <Merwin> It's ok vila, posted
[08:42] <mgz> vila: new unhappy test, don't think I've seen this one fail before <http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/569/testReport/junit/bzrlib.tests.test_config/TestConcurrentStoreUpdates/test_writes_are_serialized_bazaar_/history/>
[08:42] <mgz> and, I'm patch pilot this week? :)
[08:43] <vila> mgz: yup you are \o/
[08:43] <vila> mgz: failing test: permissiondenied, so, known symptom, cause unknown
[08:43] <mgz> well, the word 'concurrent' makes me suspicious
[08:44] <vila> mgz: never failed anywhere else for that matter
[08:45] <mgz> possibly a factor outside the test suite? we can hope.
[08:45] <Merwin> vila: How can I resolve these conflicts ? Does overwrite the with the .other and bzr resolve --all could work ?
[08:45] <mgz> another process having the file open at the wrong time could do something like that.
[08:45] <mgz> Merwin: did you try --take-other?
[08:46] <mgz> if that works for you, it's the right solution
[08:46] <Merwin> mgz: Yes, nothing work, I have the TreeMalformed bug
[08:46] <vila> mgz: concurrent here is with threads, strongly sync'ed
[08:47] <vila> Merwin: to clarify, Mlaformed transform  is not *one* bug but a catch-all
[08:47] <Merwin> ok
[08:48] <Merwin> But, does this means that my branch is broken and won't be able to any merge ?
[08:48] <Merwin> This might be a problem :x
[08:50] <vila> well, I don't think your branch is broken
[08:50] <vila> most of the malformed tranform bugs in the past had to do with bugs in the code itself
[08:51] <vila> but not being able to reproduce the issue locally is a blocker to do the diagnosis :-/
[08:52] <vila> Merwin: 'bzr st --show-ids' may shed some light
[08:52] <Merwin> vila: Whith the pending merge ?
[08:52] <vila> yup
[08:53] <vila> having no .THIS hints at a deleted/modified case though
[08:54] <vila> which confusingly translate into .OTHER being added
[08:54] <Merwin> vila: Posted on LP Bug
[08:56] <Merwin> vila: Curiously, it's not clearer to me :D
[08:57] <vila> say file F is deleted in trunk, modified in feature and you merge 'feature' into 'trunk',
[08:58] <vila> there is a conflict because 'trunk' said: I don't want F anymore, but 'feature' says: I've modified F
[08:58] <Merwin> vila: Here, we work on a branch that is never merged back to the original one
[08:59] <vila> when creating the conflict helpers, F.OTHER contains the 'feature' version but the is no F.THIS since trunk deleted it
[09:00] <vila> Merwin: so what ? if you deleted locally, the version you deleted has been modified, there are cases where you know want this file back *because* the reason you deleted it doesn't exist anymore
[09:00] <vila> s/know/now/
[09:00] <Merwin> hum
[09:00] <vila> that's why it's a conflict, there is no way to automate such decisions
[09:02] <vila> on the other hand, there is a need to express that the deletion is permanent and that you're not interested in the modifications and won't be in the future
[09:02] <vila> this need is known and will be implemented when time permits
[09:02] <vila> Merwin: it
[09:03] <vila> it's kind of being able to say: for this file, if a conflict occur, just resolve it with --take-other
[09:03] <vila> or --take-this
[09:04] <vila> Merwin: do you have the same error for 'bzr resolve --take-other crm/crm.py'
[09:05] <Merwin> vila: Yes
[09:05] <vila> Merwin: and by the way, if you use '--take-other' for a delete/modified case, you are indeed saying: hey, if the other side changed, I want the file back
[09:05] <vila> Merwin: ok
[09:05] <Merwin> thibaut@thibaut-VirtualBox:~/OpenERP 6/Logica/addons$ bzr resolve --take-other crm/crm.py
[09:05] <Merwin> bzr: ERROR: Tree transform is malformed [('duplicate', 'new-2', 'new-204', u'crm.py')]
[09:06] <Merwin> vila: I didn't understand all you explained, but I'm glad if you understood the problem :D
[09:06] <vila> Merwin: what if you do 'bzr mv crm/crm.py.OTHER crm/crm.py' ; 'bzr resolve crm/crm.py'
[09:07] <Merwin> ERROR: Could not move crm.py.OTHER => crm.py: crm/crm.py is already versioned.
[09:07] <mgz> just `mv`
[09:07] <mgz> vila is too used to typing 'bzr'
[09:07] <mgz> :P
[09:07] <Merwin> 1 conflict(s) resolved, 49 remaining
[09:07] <Merwin> vila: <3
[09:08] <vila> no, I really meant 'bzr mv', what is this already versioned 'crm/crm.py' ??
[09:08] <mgz> ...really?
[09:08] <Merwin> erf
[09:08] <vila> hold on
[09:08] <vila> just 'mv' worked ??
[09:09] <Merwin> Yes
[09:09] <mgz> I thought mv name.OTHER name; bzr resolve name was ~same as --take-other?
[09:09]  * vila blinks
[09:09] <vila> mgz: bzr mv x.OTHER X ; bzr resolve X should be ~same
[09:09] <vila> hence my surprise
[09:11] <Merwin> hum. I tried to create a new repo from the remote one we use (the on I push after merge). I then merged from the original trunk, and in this case I onlyt have the text conflict
[09:11] <Merwin> Not all the content conflicts I got
[09:11] <vila> haaaa, can you explain that in the bug report ?
[09:12] <vila> Merwin: at least you're out of trouble right ?
[09:12] <Merwin> I still have ONE content conflicts
[09:12] <Merwin> I'll try to resolve it using --take-other
[09:12] <vila> which one ?
[09:13] <Merwin> crm/test/test_crm_meeting.yml
[09:14] <Merwin> I've got the same problem on this file :D
[09:15] <Merwin> And same error with 'bzr mv'
[09:15] <vila> with --take-other ? Or with a bare 'mv' + resolve ?
[09:15] <Merwin> bzr mv doesn't work (already versionend error), --take-other raise the Malformed error
[09:16] <Merwin> mv worked
[09:16] <Merwin> Ok, I did my merge ! finally worked !
[09:17] <vila> great
[09:18] <Merwin> I pushed the "copy" repo, and pulled from the other repo (which was bugged) after I reverted it, it's ok
[09:18] <Merwin> I let the bug opened vila?
[09:20] <vila> Merwin: yup
[09:20] <vila> Merwin: We won't be able to fix your issue but we can at least output a traceback to make it clearer that it's an internal bug and not a user error ;)
[09:21] <Merwin> vila: Why you won't fix it ?
[09:21] <vila> Merwin: if your branches become public though, we will be able to reproduce it so please specify the revids involved
[09:21] <vila> Merwin: because I have no way to diagnose it properly so I can't fix it
[09:21] <Merwin> ok, I will push it on lp
[09:22] <vila> Merwin: you can ?
[09:22] <Merwin> Yes, it's not a branch where we push our things
[09:22] <vila> Merwin: in this case commit after your merge and mention this branch in the bug report and I will be able to diagnose \o/
[09:23] <Merwin> Ok, it will take time, I'll keep you informed :)
[09:23] <vila> cool
[09:24] <vila> in other news, the importer made tea this morning during lp downtime and 4 more signatures have been added
[09:25] <Merwin> signatures for ?
[09:26] <vila> Merwin: no relation with your bug :)
[09:27] <vila> signature here refers to a traceback encountered when lp is down in the package importer http://package-import.ubuntu.com/status/
[09:54] <Merwin> vila: https://code.launchpad.net/~thibaut-dirlik/+junk/bzr-bug-880701
[09:56] <vila> Merwin: thanks, please mention it in the bug report explaining how you proceeded in the ned
[09:56] <vila> end
[09:56] <Merwin> vila: To reproduce the bug, revert to the previous rev, and merge with lp:openobject-addons
[09:56] <Merwin> Ok
[09:56] <vila> Merwin: right, the tip should give me all the needed revisions :)
[09:56] <vila> branching
[10:38] <vila> Merwin: huh ? got your branch (revno 4921), created 'work' revno 4920 and 'from' revno 4899.14.120
[10:38] <vila> Merwin: in 'work' doing 'bzr merge ../from' gives: Nothing to do.
[10:39] <Merwin> vila: hum try to merge from lp:openobject-addons from revno 4920
[10:40] <vila> ha, indeed, diferent result
[10:40] <Merwin> do you get the errors ?
[10:41] <vila> yup when merging from lp:open..-addons
[10:41] <vila> good enough
[10:42] <Merwin> Ok, happy you can reproduce it
[10:42] <Merwin> Thanks for your support ;)
[10:44] <vila> Merwin: I'll take a closer look after lunch but I already suspect some weirdness in revno 4908
[10:45] <Merwin> vila: Hum it seems my boss removed the crm module and replaced it right ?
[10:46] <Merwin> I see that crm/* have been added in rev 4908 whereas it already existed in the original trunk (lp:open...-addons)
[10:46] <vila> Merwin: something like that yes, *this* could lead to files being seen with different file-ids
[10:46] <vila> Merwin: aka the so-called 'parallel import'
[10:46] <vila> Merwin: but I'll look closer later
[10:46] <Merwin> Ok, thank you again ^^
[10:46] <vila> Merwin: I'll let you know if you stay connected here ;)
[10:46] <Merwin> I'll be there :)
[11:25] <mgz> vila: can you confirm that import-package does actually run with a valid locale?
[11:25] <mgz> the init.d script for mass-import tries to set one, but given certain failures I have doubts that it's actually getting all the way down
[11:39] <mgz> okay, I think I understand this,
[11:43] <mgz> for some reason the import-dsc is on a slightly different path an unpacks the tarball
[11:43] <ChrisCauser> Hi everyone, has anyone managed to install loggerhead on Lucid which has bzr 2.5 installed?
[11:43] <ChrisCauser> or am I doing something silly?
[11:44] <ChrisCauser> http://paste.ubuntu.com/717742/
[11:58] <mgz> ChrisCauser: that looks like the latest bzr daily, which loggerhead is saying is too new
[12:00] <mgz> what loggerhead package are you trying to install? the daily as well?
[12:01] <vila> mgz: care to clarify this path issue ? Afaics mass-import should indeed set it correctly and I know no code path that could reset/change it
[12:02] <vila> mgz: now, the importer is a bzrlib client not a bzr one so there may be some holes...
[12:04] <mgz> vila: minor confusion, from the import-dsc command and the import-package script doing something slightly different
[12:05] <mgz> the basic issue is in bzr-builddeb, just in a couple of forms
[12:05] <vila> mgz: you know we run old versions of them on jubany right ?
[12:05] <vila> them == bzr and bzr-builddeb
[12:05] <mgz> yeah, which won't help matters in fixing this.
[12:05] <vila> right
[12:05] <vila> so,
[12:05] <mgz> because it can't be done from lp:udd
[12:06] <vila> mgz, Riddell, jelmer : Do you know a reason why we shouldn't run bzr.dev on jubany ?
[12:07] <vila> i.e. : install and use our own branch
[12:08] <mgz> well, I don't need the latest bzr, but we need to be able to fix things in bzr-builddeb
[12:08] <vila> mgz: we use revno 613 and we can deploy more recent versions if needed
[12:08] <vila> as long as it doesn't break horribly :)
[12:09] <vila> oh, jelmer is away this week right ?
[12:09] <vila> or at least in some unreachable TZ ;)
[12:09] <mgz> I want to break things with better error messages :)
[12:09] <mgz> vila: yeah, he's off being a git
[12:10] <vila> :)
[12:34] <lamont> jelmer: around?
[12:35] <mgz> lamont: he's mostly away this week
[12:35] <lamont> well then. fine.
[12:45] <ChrisCauser> mgz: Doh, thought it was in the same PPA. Thanks. :). Right, now, next stupid question, where is the loggerhead PPA? Typing in loggerhead PPA takes you to the source code, but I cannot seem to find the ppa url. Is there one?
=== yofel_ is now known as yofel
[13:59] <mgz> ChrisCauser: it's the same ppa, I just wanted to know the full name of the loggerhead packaged you're trying to install
[14:00] <mgz> as according to <http://people.canonical.com/~jelmer/recipe-status/bzr.html> the loggerhead-daily is green on lucid
[14:01] <ChrisCauser> mgz: Thanks: http://paste.ubuntu.com/717851/
[14:02] <mgz> hm yup, that is what it should be
[14:27] <ChrisCauser> mgz: Cool, well, at least you guys know that something fishy is afoot. I haven't done anything unusual with my system other than add the bzr daily ppa.
[14:34] <allenap> Can anyone help with a weird mutual stacking issue on Launchpad? https://answers.launchpad.net/launchpad/+question/175926
[14:35] <allenap> It looks like lp:~afcowie/java-gnome/mainline is stacked on lp:~java-gnome/java-gnome/4.1 ... which is stacked on lp:~afcowie/java-gnome/mainline.
[14:43] <mgz> allenap: yup, that's a nice infinite recursion traceback
[14:44] <mgz> things like this have been fixed manually in the past, right?
=== med_out is now known as medberry
[14:45] <allenap> mgz: Indeed. I don't know about that, but I can probably figure out how to do it. I wanted to check this wasn't something that requires a big response, or if it's just a curiosity.
[14:47] <mgz> I've got a little list of things like this I was planning on asking you about on thursday
[14:48] <mgz> looking through mailing list archives to see if that gives any clues
[14:49] <mgz> bug 726976 and dupes look like this
[14:49] <ubot5> Launchpad bug 726976 in Bazaar "Stacking loop causes unhelpful "unable to obtain lock" errors during "bzr up"" [High,Confirmed] https://launchpad.net/bugs/726976
[14:50] <mgz> "Edit the .bzr/branch/branch.conf files for those branches via SFTP"
[14:50] <mgz> appears to be the suggested solution.
[14:54] <jelmer> lamont: hi
[14:56] <allenap> mgz: Ta, I'll do that.
[14:57] <vila> tada ! Here comes jelmer :-)
[14:57] <Noldorin> hi jelmer
[14:58] <mgz> it's not clear whether the step 2 from the earlier bug of touching the branch to purge a launchpad cache is still needed
[14:59] <jelmer> hi vila, Noldorin
[15:00] <mgz> jelmer, while you're here to bug,
[15:00] <mgz> any idea why loggerhead is uninstallable from the dailies on lucid?
[15:02] <mgz> it says it wants < 2.5 and the bzr-daily-lucid is newer, so unhappiness
[15:02] <mgz> it's green on your status page though.
[15:02] <jelmer> mgz: it probably built fine, but has anm invalid dependency for the binary package
[15:04] <mgz> ...that seems like it'd be a problem for every plugin than declares a bzr version though
[15:04] <mgz> because 2.5 isn't released yet
[15:04] <mgz> or are the rules just written inconsistently?
[15:06] <jelmer> mgz: Plugins usually declare they support version X or pre-releases of version Y
[15:07] <jelmer> mgz: as far as I can tell loggerhead claims support for bzr >= 1.17 && bzr < 2.5.0~
[15:07] <vila> Merwin_: just so you know, I'm working on a fix but it's tricky. This is indeed caused by one case of 'parallel import' though
[15:08] <mgz> okay, so it is just that dep that's borked, and the builders don't catch it because they don't install. thanks!
[15:09] <Merwin_> vila: Ok !
[15:44] <lamont> jelmer: also, I'd love to have a bzrtools/hardy
=== beuno is now known as beuno-lunch
[16:25] <mgz> this is the stupidest fix
[16:25] <mgz> but it's the sanest choice short of ripping out the whole of bzrtools_import and starting again
[16:51] <jelmer> lamont: I'll have a look
[16:51] <jelmer> lamont: (I'm in CA this week)
[17:10] <jelmer> mgz: which fix?
[17:15] <mgz> bug 508258, proposing now.
[17:15] <ubot5> Launchpad bug 508258 in bzr-builddeb "Failure to import non-ascii filenames" [High,In progress] https://launchpad.net/bugs/508258
=== beuno-lunch is now known as beuno
=== zyga is now known as zyga-afk
[22:14] <poolie> hi all
[22:17] <jelmer> hi poolie
[22:17] <poolie> hi, how's it going?
[22:17] <jelmer> having fun :) How are you?
[22:18] <poolie> good thanks, camping was good
[22:23] <poolie> thanks for the notes
[22:34] <jelmer> anytime
[22:34]  * jelmer runs off to some sessions, back later