| * spiv waits for the cold&flu pills to kick in fully | 01:05 | |
| lifeless | ugh | 01:05 |
|---|---|---|
| spiv | I'm definitely doing much better than yesterday. I don't seem to actually have a fever anymore, and I got a proper night's sleep. | 01:06 |
| spiv | Hooray for ubuflu :/ | 01:07 |
| mgz | lifeless: re "Where is test_dir being set?", two instances of `self.test_dir = ` in bzrlib.tests both of which are old | 01:16 |
| mgz | so I presume the change is something to do with how test methods are put on instances in testtools | 01:17 |
| spiv | mgz: oh wow, that's a shorter nick! | 01:17 |
| mgz | blame vila! | 01:17 |
| igc | morning | 01:26 |
| lifeless | hmmm | 01:33 |
| mgz | I presume the code was wrong before, but happened to work because no one was checking if the attribute they'd put the directory name in was still a string or whatever | 01:35 |
| mgz | didn't look too closely once I'd worked out how easy the fix was | 01:39 |
| lifeless | mgz: yeah | 01:48 |
| * igc lunch | 03:03 | |
| nilg | I'm having problems with launchpad since yesterday, anyone else? | 03:39 |
| Croepha | can bzr diff compressed files? like can it give intelegable changes between revisions of a docx file? | 04:31 |
| spiv | Croepha: not as a builtin feature | 04:34 |
| spiv | Croepha: I think it would be possible to write a plugin to do that, or perhaps you could try "bzr diff --using=..." if you already have a tool for producing readable diffs for that file type. | 04:36 |
| lifeless | nilg: some details please | 04:40 |
| lifeless | Croepha: you can write a plugin to the diff code that examines specific files in a different way | 04:41 |
| nilg | lifeless: sorry I works actually | 04:41 |
| vila | hi all | 07:21 |
| bialix | heya | 07:50 |
| igc | night all | 08:14 |
| GaryvdM | Hi and Night igc. | 08:15 |
| bialix | night igc | 08:15 |
| gour | morning | 08:15 |
| gour | night igc | 08:15 |
| igc | hi GaryvdM, gour (and night) | 08:15 |
| gour | #541626 makes bzr-fastimprt unusuable for me | 08:16 |
| gour | is it just fastimport's problem or affects bzr aswell? | 08:16 |
| bialix | you should say bug #541626 | 08:16 |
| ubottu | Launchpad bug 541626 in bzr-fastimport "'BTreeBuilder' object has no attribute '_find_ancestors'" [Undecided,Confirmed] https://launchpad.net/bugs/541626 | 08:16 |
| gour | bialix: thanks | 08:16 |
| bialix | our pet bot, good ubottu, take a cookie | 08:17 |
| * gour would like to to darcs <---> bzr and use LP | 08:18 | |
| gour | s/to to/to do | 08:18 |
| bialix | tailor? | 08:19 |
| gour | i'm not sure it can do incremental import and believe fastimport should be better supported...igc takes care for it | 08:19 |
| bialix | perhaps not today | 08:20 |
| gour | vmiklos (who wrote darcs part) recommends it over tailor as well | 08:21 |
| GaryvdM | bialix: Nudge https://code.launchpad.net/~garyvdm/bzr-explorer/better_tree_filter/+merge/20519 | 08:29 |
| bialix | at evening, sorry, have to work | 08:30 |
| GaryvdM | bialix: Ok | 08:30 |
| * GaryvdM looks at 2 qbzr mps | 08:30 | |
| === gour1 is now known as gour | ||
| === wgrant_ is now known as wgrant | ||
| MvG | Hi there! When will 2.1.2 be released? https://launchpad.net/bzr/+milestone/2.1.2 expects it 2010-04-22, and bug #572098 is really annoying. Yes I could work from a snapshot, but I prefer releases for my production work. | 09:44 |
| ubot5 | Launchpad bug 572098 in Bazaar "`bzr clean-tree` should not blindly delete nested branch/tree/repo (affected: 1, heat: 6)" [High,Fix released] https://launchpad.net/bugs/572098 | 09:44 |
| MvG | Got the wrong bug, it's #559436 that's annyoing me personally, but seeing a list of 5 high priority fixes looks like a release might be a good thing. | 09:45 |
| Peng_ | bug 559436? | 09:56 |
| ubot5 | Launchpad bug 559436 in Bazaar "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 4, heat: 30)" [High,Fix released] https://launchpad.net/bugs/559436 | 09:56 |
| Peng_ | Oh. | 09:56 |
| MvG | Means whenever I switch a branch with local modifications, I get a backtrace... :-( | 09:56 |
| MvG | s/branch/tree/ | 09:57 |
| GaryvdM | vila: Who is the rm for 2.1.* ? | 10:01 |
| vila | GaryvdM: hmm, I've lost track here, was it igc or poolie ? | 10:02 |
| GaryvdM | vila: jam did 2.1.0. I can't find the release announcement for 2.1.1 | 10:03 |
| vila | GaryvdM: yeah, so poolie was RM for 2.1.1, where are you searching for the annoucement ? lp ? | 10:04 |
| GaryvdM | vila: yes | 10:04 |
| vila | GaryvdM: hmm, he presumably forgot this bit then | 10:05 |
| GaryvdM | MvG: Out of the people who could be the rm, none of them are online right now, so it may be a good idea to send a mail to the mailing list. | 10:05 |
| MvG | GaryvdM: OK, will do so. | 10:05 |
| vila | GaryvdM: do you remember which toolkit was used for diffamation ? qt ? | 10:15 |
| vila | GaryvdM: or was it osx specific ? | 10:15 |
| GaryvdM | vila: It was written in java. I'm not sure which toolkit | 10:17 |
| vila | wow, who said java was slow ? :-P | 10:17 |
| vila | for those that couldn't attend UDS, the video is here: http://ubuntudevelopers.blip.tv/file/3617079/ | 10:21 |
| bialix | does somebody really said that java is slow? he should look at python first | 10:30 |
| Peng_ | Heh. | 10:33 |
| vila | bialix: some people explained me that they switched from java to python for web apps because python was faster :-P | 10:33 |
| bialix | ah | 10:33 |
| bialix | maybe | 10:33 |
| bialix | but diffamation is desktop thing | 10:33 |
| guijemont | doesn't java have a reputation of slowness just because a lot of people programming in java don't know what they're doing? | 10:38 |
| vila | yup, so the key is to focus on the relevant part that needs to be animated, things like shortest edit paths (mentioned in the above presentation) are certainly needed to reduce the data set to process | 10:38 |
| guijemont | (me? feeding the trolls?) | 10:38 |
| vila | the same apllies to python really :) | 10:39 |
| guijemont | certainly | 10:39 |
| guijemont | that's where the virtue of brainfuck is | 10:39 |
| guijemont | bad programmers don't go there | 10:40 |
| guijemont | good programmers don't either though | 10:40 |
| GaryvdM | vila: http://www.aviz.fr/diffamation/ | 10:43 |
| guijemont | indeed diffamation looks cool | 10:49 |
| vila | GaryvdM: ecellent, thanks for the url | 10:49 |
| jml | did anyone take notes for the "Bazaar/Launchpad healthcheck" session at the recent UDS? I can't find it on gobby | 11:22 |
| vila | jml: ouch, ping poolie ? :-/ | 11:23 |
| jml | vila: I'll send him an email. | 11:24 |
| vila | mgz: in case you're wondering, I've found the problem with babune | 11:24 |
| vila | jml: I should have known... | 11:24 |
| vila | mgz: the selftest -x option can't be used twice (AFAICS) so TestBreakin and its zombies was back... | 11:25 |
| vila | mgz: I've just finished upgrading babune to lucid and relaunch a full set of runs, gentoo has already succeeded | 11:26 |
| spiv | jml: bazaar-m-healthcheck? | 11:26 |
| jml | spiv, ahh, thanks. I was looking for it under the community track | 11:26 |
| spiv | jml: that would have been logical :P | 11:26 |
| vila | jml: pfff, I'm so disappointed :-P | 11:27 |
| * vila runs (not only to avoid jml's great vengeance :) | 11:27 | |
| jml | :D | 11:29 |
| spiv | vila: Huh, I thought selftest -x could be used twice? | 11:30 |
| spiv | vila: btw, if you feel inclined, maybe set up a builder for bzr on python2.7? | 11:30 |
| spiv | (It'll fail to even start tests atm, though, I filed a bug) | 11:31 |
| bialix | yep, some pages gone from gobby | 12:00 |
| bialix | jml: that page still there | 12:04 |
| bialix | titled bazaar-m-healthcheck | 12:04 |
| jml | bialix: thanks. | 12:05 |
| bialix | I guess we should put those pages to wiki | 12:05 |
| jml | bialix, yeah. that'd be good. | 12:06 |
| jml | bialix, I'm collecting all of the Launchpad-related notes, putting them onto our wiki, then blogging a summary. | 12:07 |
| jml | I'm not going to do that for Bazaar though. | 12:07 |
| bialix | ok | 12:07 |
| bialix | I'll do that for bzr | 12:07 |
| === radoe_ is now known as radoe | ||
| guijemont | I've named some of you there, hope you don't mind: http://guij.emont.org/blog/2010/05/18/scratching-an-itch-make-bzr-gtk-collapse/ | 12:28 |
| guijemont | GaryvdM, jelmer and vila | 12:28 |
| nessita | vila: ping | 13:00 |
| vila | nessita: pong | 14:04 |
| nessita | vila: hi there! I added a comment on https://bugs.launchpad.net/bzr/+bug/581751 | 14:05 |
| ubot5 | 'Error: Could not parse data returned by Launchpad: HTTP Error 401: Unauthorized\nResponse headers:\n---\ncontent-length: 21\ncontent-type: text/plain\ndate: Tue, 18 May 2010 13:05:13 GMT\nserver: zope.server.http (HTTP)\nstatus: 401\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\nBug 581751 is private\n---\n (https://launchpad.net/bugs/581751)' | 14:05 |
| nessita | vila: lifeless suggested me to ping you, is there any debug we can do together? | 14:05 |
| vila | wow, ubottu can't authenticate ? That's weird... | 14:06 |
| nessita | any extra info I can add? I can reproduce it consistently | 14:06 |
| vila | nessita: just sec, let me page in the context | 14:08 |
| nessita | vila: sure, thanks | 14:08 |
| vila | hmm, looks like the nightly hasn't been updated since 2010-03-24, so I'm pretty sure it doesn't have the fix | 14:10 |
| vila | nessita: what do you mean by 'split' the bzr command ? | 14:11 |
| nessita | vila: yes | 14:11 |
| vila | nessita: nice host name by the way :) | 14:11 |
| nessita | heh :-) | 14:11 |
| === CardinalFang_ is now known as CardinalFang | ||
| vila | nessita: sorry for the delay, I've just updated to lucid and my setup is not fully functional yet | 14:15 |
| vila | GaryvdM: did you merge annotate_find to trunk ? It seems that branch doesn't work anymore on lucid | 14:15 |
| nessita | vila: no problem. Just ping me using my nickname and I'll be happy to help debugging | 14:16 |
| GaryvdM | vila: I have not yet merge annotate_find to trunk, but I have merge trunk in to annotate_find, so annotate_find should work on trunk. | 14:16 |
| GaryvdM | *should work on lucid | 14:16 |
| vila | ok, first I'd like to check if the nightly includes the fix I mentioned | 14:16 |
| vila | GaryvdM: Oh, right, you told me that, let me check | 14:17 |
| vila | GaryvdM: thanks, that fixed it :) | 14:18 |
| vila | nessita: right, the fix is revno 5160 on trunk while the nightly seems to be 5106, right numbers, wrong order | 14:20 |
| nessita | vila: ok, so, is there any way of getting a newer bzr other that branching trunk? | 14:20 |
| vila | nessita: can you run bzr from sources ? | 14:20 |
| nessita | vila: I guess so :-) | 14:21 |
| * nessita branches | 14:21 | |
| vila | nessita: none of the ppas seems to contain better than nightly, this fix should be in the next releases (2.0.6, 2.1.2, 2.2xxx) | 14:21 |
| vila | spiv: (surely too late but anyway) I thought -x could be used twice too, regression ? (-s can ! :) | 14:23 |
| vila | nessita: don't forget to run make after branching (hmm, you may need to install some dependencies too, pyrex for one...) | 14:24 |
| nessita | vila: is there any howto? | 14:25 |
| nessita | I mean, a list of deps so I install them at once | 14:25 |
| * vila looks at the package def | 14:26 | |
| nessita | jeje | 14:26 |
| nessita | that's cheating! | 14:26 |
| vila | :) | 14:26 |
| vila | I know we don't have TestDepends but I'm pretty sure we have DevDepends (or whatever the name is) | 14:26 |
| * nessita is still branching | 14:28 | |
| vila | argh, one more regression, can\t switch virtual desktops anymore | 14:28 |
| vila | nessita: hmm, first branch ever ? | 14:28 |
| nessita | yeap | 14:28 |
| * nessita sings like a virgin, branching for the very first time | 14:29 | |
| vila | shift+ctrl+alt+left instead of ctrl+meta-left .... did the design team infected by emacs viruses ? | 14:31 |
| vila | nessita: :-) | 14:31 |
| vila | argh, keyboard layout bug :( | 14:31 |
| nessita | vila: how big is a bzr branch? | 14:48 |
| vila | history or working tree ? | 14:48 |
| nessita | history | 14:49 |
| nessita | vila: it doesn't matter, I was just curious | 14:50 |
| nessita | this thing is still branching :-) | 14:50 |
| vila | nessita: my .bzr shared repo is ~62 | 14:50 |
| vila | ghaa 63M | 14:50 |
| vila | that should be an upper bound as it contains many revisions that were never (or are not yet :) merged to trunk | 14:51 |
| vila | nessita: lag/bandwidth ? | 14:51 |
| nessita | max download rate is 1M for me | 14:52 |
| nessita | and the branch is using ti all | 14:52 |
| nessita | it* | 14:52 |
| nessita | \ 78155kB 107kB/s | Fetching revisions:Inserting stream and counting | 14:53 |
| vila | hmm, 78M already, something weird is going on here :-/ | 14:53 |
| nessita | not relly? | 14:54 |
| nessita | nessita@dali:~$ du -sh src/bzr.trunk/ | 14:54 |
| nessita | 35Msrc/bzr.trunk/ | 14:54 |
| nessita | finished! | 14:54 |
| vila | nessita: so you used twice the volume of the final branch: something weird happened, can file a bug with these numbers please ? | 14:56 |
| vila | nessita: then you can ping lifeless :-) | 14:56 |
| nessita | ok | 14:56 |
| nessita | vila: make completed successfully | 14:57 |
| vila | nessita: so, run 'make' in the bzr branch | 14:57 |
| nessita | done | 14:57 |
| vila | wow, you rock :) | 14:57 |
| nessita | heh | 14:57 |
| vila | no weird messages about extensions nor zlib ? | 14:57 |
| nessita | nopes, it failed because of the lack of pyrex, which I installed and re run make | 14:57 |
| vila | nessita: just do './bzr info -v' there | 14:57 |
| vila | ok, so you should have the other ones already installed (I vaguely remember zlib-dev was required at some point) | 14:58 |
| nessita | vila: https://pastebin.canonical.com/32382/ | 14:58 |
| vila | nessita: cool | 15:00 |
| nessita | vila: this worried me though https://pastebin.canonical.com/32383/ | 15:00 |
| nessita | vila: note bzr vs ./bzr | 15:00 |
| nessita | but versions match? | 15:00 |
| vila | nessita: try using this bzr for your previously failing ... let me look ta this pate | 15:00 |
| vila | nessita: yes, versions are bumped for release only, nightly are not your usual beast | 15:01 |
| nessita | ohhhh ok | 15:01 |
| nessita | vila: shall I redo the splits with the newer bzr? | 15:01 |
| vila | but the full output should mention the revno | 15:01 |
| vila | nessita: not if the fix apply to your case | 15:02 |
| nessita | perfect | 15:02 |
| vila | nessita: bah, no | 15:02 |
| vila | sorry for the convoluted answer | 15:02 |
| nessita | no problem | 15:02 |
| nessita | I can do the split again | 15:02 |
| nessita | shall I branch using newer bzr too? | 15:03 |
| vila | nessita: no, just try the failing command with the new bzr | 15:03 |
| nessita | ok | 15:03 |
| vila | either it's fixed or it's a whole new bug anyway | 15:03 |
| vila | mgz: babune back in blue, expect for the windows run !! | 15:04 |
| nessita | it didn't fail! | 15:04 |
| nessita | vila: nice :-) | 15:04 |
| vila | nessita: pfew, I'm so glad about that ! This fix was a real pain :) | 15:05 |
| nessita | vila: thank you very much for your help! | 15:05 |
| vila | nessita: I was afraid you were hitting the same kind of problem only different, luckily it looks to be the *same* :) | 15:05 |
| vila | nessita: my pleasure | 15:06 |
| nessita | seems like it | 15:06 |
| nessita | vila: have a few more minutes for a follow up question? | 15:06 |
| vila | nessita: sure | 15:06 |
| nessita | vila: so, the merged worked (yey!) but, when applied, it removes some files (because the source branch has those removes in it). Is there any way to avoid/undo certain changes? | 15:07 |
| vila | nessita: if the merge remove 'filea', doing 'bzr revert filea' should restore it, you can then commit and the following merges shouldn't delete it again | 15:09 |
| nessita | vila: yey, you're right | 15:09 |
| nessita | thanks again! | 15:10 |
| vila | nessita: I'll mark the bug as a duplicate then | 15:13 |
| nessita | vila: please do | 15:13 |
| nilg` | bzr repo on launchpad is nearly impossible to get from china, any knowledge about that issue? | 15:15 |
| vila | guijemont: marmitians anonymous, really, you know there are free certificate providers these days ? :-P | 15:18 |
| vila | guijemont: and, of course, no problem with your citations :) | 15:23 |
| guijemont | vila: yeah, should handle that one day | 15:25 |
| guijemont | but the big issue is it's a shared server | 15:26 |
| vila | ha, yeah, technical problems are so much easier to handle when humans are not involved :-D | 15:26 |
| GaryvdM | vila: I know you us synergy. Are you aware of this: http://code.google.com/p/synergy-plus/ | 15:46 |
| GaryvdM | *use | 15:46 |
| GaryvdM | vila: The old synergy segfaults for me. synergy-plus is more stable for me, but the clipboard is broken. | 15:48 |
| vila | GaryvdM: good to see this nice software resurrected, I'll track it to see how it evolve. | 15:49 |
| vila | GaryvdM: it's mission critical for me so unless it works better I'll stick with the working one :) | 15:49 |
| GaryvdM | vila: I see. | 15:51 |
| vila | GaryvdM: also, I try to minimize installs from source, so unless it's packaged for lucid... I will wait (if someone proposes it as a ppa though.... I will gladly test it ;-) | 15:53 |
| vila | GaryvdM: Oh, and I have a pending bug against virtualbox about the bad interactions between vbox, synergy and the apple magic mouse... | 15:54 |
| kfogel | On a Debian GNU/Linux system, ever bzr command gets this warning: | 16:01 |
| kfogel | /usr/lib/python2.5/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken | 16:01 |
| kfogel | RandomPool_DeprecationWarning) | 16:01 |
| kfogel | But python-paramiko package is up-to-date. Googling does not reveal any obvious fixes, and the URL given in the warning is a 404. | 16:01 |
| kfogel | Any ideas? | 16:01 |
| IslandUsurper | Isn't Crypto a separate download from paramiko? | 16:07 |
| cbz | what happens when a pack file size gets to the system filesize limit? | 16:08 |
| IslandUsurper | kfogel, the source install docs list http://www.python.org/pypi/pycrypto/ as the place to get pyCrypto | 16:08 |
| kfogel | IslandUsurper: thanks | 16:08 |
| IslandUsurper | kfogel, I would guess there's a different package for it instead of python-paramiko | 16:09 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| nessita | hey all, me again with weird issues. Anyone has a hint how to solve this conflicts? https://pastebin.canonical.com/32393/ | 16:47 |
| maxb | You know that that's a pastebin most people can't see? | 16:58 |
| nessita | duh, sorry, pastebin was disabled a few hours ago :) | 16:59 |
| nessita | oops, still is | 16:59 |
| === salgado is now known as salgado-lunch | ||
| nessita | public paste: http://paste.ubuntu.com/435609/ | 17:01 |
| === beuno is now known as beuno-lunch | ||
| nessita | maxb: thanks for pointing this out! | 17:01 |
| maxb | I guess this is a private branch? | 17:08 |
| nessita | maxb: yes, I split a subtree from a branch and I merged it against another branch in another project | 17:10 |
| nessita | (using bzr split and bzr merge) | 17:10 |
| maxb | that sounds... complicated :-) | 17:10 |
| nessita | yeah | 17:10 |
| nessita | I'm so frustrated | 17:10 |
| nessita | but I have to do this, and maintain history | 17:11 |
| === kfogel is now known as kfogel-lunchpad | ||
| bialix | GaryvdM: still here? | 17:41 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| === IslandUsurper is now known as IslandUsurperAFK | ||
| bialix | GaryvdM: maybe I simply should dogfood your bzr-explorer patch? I'm not really wise to easily review your changes | 17:43 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| bialix | about duplication: maybe it's worth to require in explorer trunk compatibility with newer qbzr? and keep explorer 1.0.x as compatible with qbzr 0.18? | 17:44 |
| * bialix going to home, will read irclogs later | 17:44 | |
| bialix | ~~~ | 17:44 |
| mgz | vila: good to know the nix hang problems are not related, was coming to that conclusion here | 17:50 |
| mgz | I've got some interesting results on the thread leak regression I'll probably post to the mailinglist | 17:50 |
| === kirkland` is now known as kirkland | ||
| pheller | can anyone tell me what provides XMLSerializer ? | 18:05 |
| pheller | nevermind. I see it's part of bzrlib now | 18:08 |
| === beuno-lunch is now known as beuno | ||
| === luke-jr_ is now known as luke-jr | ||
| vila | mgz: (passing around) regression ? The leaks have been there for... a very long time, what are you comparing to ? | 18:14 |
| mtaylor | abentley: bug in lp-submit in pipelines: I just got this error: bzr: ERROR: There is already a branch merge proposal: https://code.edge.launchpad.net/1.0/~mordred/drizzle/pandora-build/+merge/14733 | 18:14 |
| mtaylor | abentley: too bad the 1.0 doesn't really belong in that url... | 18:14 |
| vila | mgz: the bug itself is very stealth and I have never been able to reproduce it on demand... | 18:15 |
| abentley | mtaylor, funny, I thought I'd fixed that one. | 18:18 |
| mgz | vila, that's just it, yes, the leaks have always been there, but they were never fatal for *me* before | 18:18 |
| mgz | and now I can reliably repo. | 18:18 |
| mtaylor | abentley: it's possible I'm running an old version | 18:19 |
| mgz | vila: I've got a couple of things I'd like you to check if you can | 18:19 |
| === JFo is now known as JFo-afk | ||
| abentley | mtaylor, just testing now. It's possible I only fixed lp-propose. | 18:19 |
| mgz | 1) make really-really sure you're chop-test-run-into-several-smaller-subprocesses workaround is still working, as that should make leaks harmless | 18:20 |
| mgz | 2) do a full babune test run on r4919 and r4920 | 18:20 |
| abentley | mtaylor, yeah, that's it. On 2.1, lp-submit will give you that error. On 2.2, you get lp-propose through its lp-submit alias. | 18:23 |
| mtaylor | abentley: ok. cool | 18:24 |
| mtaylor | abentley: I'll just deal with it then | 18:24 |
| mtaylor | it's certainly not borking me :) | 18:24 |
| abentley | mtaylor, I'll fix it, just not right now. | 18:27 |
| GaryvdM | bialix: If you read this in the log, I've replied to your questions in the mp. Thanks | 18:31 |
| vila | mgz: 1) is demonstrated by babune being almost blue (including some hacks for some slaves to increase BZR_CONCURRENCY *above* the number of available processors) | 18:34 |
| fullermd | For god's sake, let it BREATHE! | 18:35 |
| vila | mgz: what do you call a full run ? All slaves ? | 18:35 |
| vila | fullermd: funnily enough it's the freebsd8 that needs the hack has running it under vbox with more than two cores lead to far too much crashes :-/ | 18:35 |
| vila | s/freebsd8/freebsd8 slave/ and to avoid any misunderstandings, I blame vbox not freebsd (remember the time skew problems I was encountering ? Still there, even worse maybe) | 18:36 |
| vila | and babune's fans have been changed for more silent, yet still efficient, ones, so it can breathe and I don't hear it complain anyway | 18:37 |
| fullermd | Obviously, the answer is to make freebsd8 the host rather than the emulated one ;p | 18:37 |
| vila | fullermd: all tests are run in slaves, not on host :-P Host is for *my* tests :-) | 18:38 |
| vila | so I'll still need to have a freebsd slave ;) | 18:38 |
| fullermd | Daemons don't take well to chains. You're liable to wake up one day to a trident at your throat. | 18:39 |
| GaryvdM | If you interrupt a bzr-git fetch, will it resume, or restart? | 18:39 |
| vila | one more reason to give it only two cores, I may be able to put my neck between the two teeth of the bident :) | 18:40 |
| vila | fullermd: and stop complaining, now you can blame the lower number of cores to explain why freebsd is the slowest nix on http://babune.ladeuil.net:24842 :-P | 18:41 |
| fullermd | Ah, yes. Core limits for VM's should be called the Skynet Prevention Program. | 18:41 |
| vila | You said the name !!!! | 18:42 |
| fullermd | jaunty isn't a nix? ;p | 18:42 |
| vila | hehe, I was waiting for that, check again in a couple of days or drill down for the trend, jaunty and karmic last run are atypical :-P | 18:43 |
| fullermd | Doesn't much matter anyway, since Windows does it in 2 minutes ;p | 18:44 |
| vila | no no, 55mins, note the debug :) This one is running only a small subset :) | 18:45 |
| * fullermd snorts. | 18:46 | |
| * vila dinner :) | 18:46 | |
| fullermd | You've got a pathetic career as a benchmarker ahead of you if you're gonna get bogged down in irrelevant details like that ;p | 18:46 |
| mgz | <vila> mgz: what do you call a full run ? All slaves ? <- windows only, but all tests (minus bb.test_breakin) | 18:47 |
| mgz | I'll get my write-up done later, then things might start making more sense | 18:47 |
| === salgado-lunch is now known as salgado | ||
| mgz | essenstially, I think things have got worse on the threads-leaked-alive front. | 18:50 |
| mgz | and it's the fault of testtools, which is becoming something of a mantra for me | 18:51 |
| fullermd | Well, consistency is a virtue, right? | 18:53 |
| === kfogel-lunchpad is now known as kfogel | ||
| eydaimon | can I create a branch on remote host? say I have a bunch of files in a dir. I want to create a branch on the remote host, and check them in there. how would I do it? | 19:20 |
| beuno | eydaimon, create teh branch locally and push to it | 19:23 |
| beuno | it will create it | 19:23 |
| eydaimon | bzr init . ? | 19:25 |
| eydaimon | then bzr push pathname? | 19:25 |
| beuno | bzr init . | 19:26 |
| beuno | bzr add | 19:26 |
| beuno | bzr commit -m | 19:26 |
| beuno | bzr commit -m'Some message' | 19:26 |
| beuno | bzr push pathname | 19:26 |
| eydaimon | thanks :) | 19:27 |
| eydaimon | will the local branch work as a checkout or as a branch? | 19:27 |
| beuno | youz welcome | 19:27 |
| beuno | a branch | 19:27 |
| eydaimon | can I make it a checkout? | 19:27 |
| eydaimon | so Id on't have to keep pushing | 19:28 |
| beuno | yes, but you will need to checkout from $path | 19:28 |
| eydaimon | so first push, then checkout | 19:28 |
| eydaimon | bzr doesn't seem to like writing to a dir which already exists | 19:28 |
| beuno | yeah, it's fussy about that | 19:33 |
| GaryvdM | eydaimon: You can make your local branch a check out by running bzr bind :push | 19:34 |
| eydaimon | cool. thank you | 19:36 |
| vila | mgz: hmm, re-trying old revisions on windows with the bug fixes in testtools and subunit may be worth a try, but I won't bet a lot on testtools making things worse | 19:38 |
| vila | mgz: keep in mind that the root cause is that transport objects don't close their socket, for http that means keeping the connection alive. The servers have to keep their own connections open. At some point python's gc will finally collect the transports and close the client sockets triggering the server sockets close. | 19:42 |
| vila | mgz: But since that take too long, we finally reach the socket/file handle/thread limit | 19:43 |
| vila | mgz: now, to fix that, we need to close the socket in either the client or the server, that's where I encountered weird behaviors (uncaught exceptions in the server threads leading to hang threads for once) | 19:45 |
| vila | mgz: I have some branches where the servers where almost good and where there were almost no more leaked threads and... get interrupted | 19:46 |
| vila | mgz: It's high n my TODO list now so expect some results soon (for handwaved values of soon of course :) | 19:46 |
| kojiro | There's something I really don't understand about bzr-svn: If I do a merge/commit/push, it puts back changes that were already on the svn repo, but makes it look like I just made those changes | 19:50 |
| kojiro | is that really what I should be doing? | 19:50 |
| === tchan1 is now known as tchna | ||
| === tchna is now known as tchan | ||
| vila | fullermd: benchmarker... OMG what a scary thought... | 20:05 |
| * fullermd . o O ( Vilacraft... ) | 20:06 | |
| jam | vila: shouldn't you be ... not in IRC... by now :) | 20:07 |
| fullermd | Wow, you haven't even started benchmarking, and people are already trying to get rid of you! | 20:07 |
| GaryvdM | jam :-p | 20:07 |
| vila | jam: hey ! Indeed :) | 20:08 |
| jam | hi GaryvdM | 20:08 |
| vila | Proceed as if I wasn't there :) | 20:08 |
| jam | vila: I'm seeing an awful lot of blue on babune :). Though I wonder why selftest-windows isn't, seeing as you worked with Martin all week on it... | 20:08 |
| jam | Are there patches pending? | 20:08 |
| jam | (At least, I thought you said you got Win32 to pass...) | 20:08 |
| vila | jam: AFAIUI, most of them are now due to the infamous "Can't start new thread" | 20:09 |
| vila | I thought we add, but for some reasons, not all tests were running and we based our countdown on that. | 20:10 |
| * mgz reads log | 20:10 | |
| vila | mgz had landed further patches I believe so the remaining ones should be fixed when the leaks will | 20:10 |
| vila | oh, he's there (mgz) so he can comment :) | 20:11 |
| mgz | yup, I'm aiming to splat everything that's not a leak | 20:11 |
| jam | vila: you know, if you gave that vm 2 cpu's, you're troubles would probably go away... | 20:11 |
| mgz | including a couple of things I see but babune doesn't | 20:11 |
| vila | jam: I can't make XP recognize several cores... | 20:11 |
| jam | *your* | 20:11 |
| mgz | on the leak-as-regression thing, something has gone seriously bad in the past 300 revisions | 20:11 |
| jam | vila: my wife runs xp-pro on 2-core | 20:12 |
| jam | (business machine) | 20:12 |
| mgz | leaks are harmless provided there's enough memory to spare for the stack space required by lingering threads | 20:12 |
| vila | ha, pro, that should explain it :) | 20:12 |
| jam | maybe | 20:12 |
| vila | mgz: could be, I can try increasing the memory allocated to the vm | 20:12 |
| jam | xp was based on 2k's kernel, IIRC. So maybe xp-home has an explicit deficit, but xp generally can definitely handle multi-core | 20:13 |
| mgz | between r4919 and r4937 (which is the first post-testtools rev that doesn't corrupt memory), the working set increased two or three fold | 20:13 |
| vila | now waitaminute, I'm pretty sure I'm using a pro version... | 20:13 |
| mgz | and the tests start hanging. | 20:13 |
| vila | mgz: working set ? | 20:14 |
| vila | corrupt memory ? | 20:14 |
| mgz | sorry, yes, this is complicated by lots of unrelated things | 20:14 |
| mgz | hence easier in a big email than on IRC | 20:15 |
| vila | ok | 20:15 |
| jam | mgz: working set => active memory consumption? | 20:19 |
| mgz | right, it's one of the measures I get from windows, also, pagefile usage, and I'm not sure how they overlap | 20:20 |
| mgz | (is the combined value the total memory usage?) | 20:20 |
| bialix | how to configure pqm plugin to send merge request for 2.1 branch? | 20:25 |
| GaryvdM | bialix: Change the submit branch in branch.conf. | 20:28 |
| bialix | e.g.? | 20:28 |
| GaryvdM | bialix: you probably will not have permissions though. | 20:28 |
| bialix | boom | 20:28 |
| GaryvdM | bialix: submit_branch = bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/ | 20:31 |
| GaryvdM | or just | 20:31 |
| GaryvdM | bzr pqm-submit bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/ | 20:32 |
| mgz | vila: so, I ran the whole testsuite against a bunch of different revisions, summary of the results at <http://float.endofinternet.org/temp/bzr_selftest_result_summary.log> | 20:36 |
| * bialix rambling on out-of-date hacking.txt instruction re pqm | 20:37 | |
| mgz | the first rev I can test without the crash from r4920 has massive memory usage, and hangs in a threaded test, as does each revision after that | 20:38 |
| mgz | more recent revisions still have massive memory usage, but run faster (there was a rev aiming to speed up the test suite, right?) and now get various thread-related failures but hang less reliably. | 20:39 |
| vila | mgz: yes, lifeless optimized a bunch of tests | 20:40 |
| mgz | I'm going to run some revs between 4945 and 5200 but it seems to me like the regression is between r4919 (which is fine for me) and r4937 (which is the first post-testtools that I can run) | 20:40 |
| mgz | hence the request for you to try r4919 on babune, if you can | 20:41 |
| mgz | I expect zero thread problems. | 20:41 |
| mgz | (the full results are on my server, but are giant xml files that might hurt unsuspecting webbrowsers) | 20:43 |
| vila | mgz: now running | 20:52 |
| vila | mgz: that was fast :-/ | 20:54 |
| vila | hmm, the qbzr guys are gone for some more vodka I suspect... | 20:54 |
| mgz | bah, dodgy unicode handling in error messages is historical... | 20:55 |
| mgz | don't suppose you have python 2.4 on that box? | 20:56 |
| vila | mgz: 2.4 2.5 2.6 | 20:56 |
| mgz | AttributeError: 'BzrAutoTimingTestResultDecorator' object has no attribute '_call_maybe' <- and I got this from subunit, and didn't know what the hell it was | 20:56 |
| vila | pretty old bug | 20:57 |
| mgz | in bzr? that was fixed? | 20:57 |
| vila | err wait, you got that *now* | 20:57 |
| mgz | I might have been trying to test an old revision at the time. | 20:57 |
| vila | no, I'd say in testtools | 20:57 |
| mgz | I can run the testsuite back to at least ~4000 cleanly | 20:58 |
| vila | they try to preserve backwards compatibility with that (IIRC), they may lack 2.4 testers though | 20:58 |
| mgz | but I have less in-tree infrastructure I'm relying on | 20:58 |
| mgz | r4919 is before testtools | 20:58 |
| vila | bite the bullet man, testtools is the future and the sky is the limit ! :-D | 20:59 |
| mgz | okay, so this probably isn't going to be easy to prove with babune | 21:00 |
| mgz | but, here's my 4919 run: http://float.endofinternet.org/bzrcst/clasfull/4919 | 21:00 |
| vila | mgz: just try to exclude all http server related tests (add a skip in the server setup if you want) and just focus on the rest | 21:00 |
| mgz | and 4920: http://float.endofinternet.org/bzrcst/clasfull/4920 (early crash) | 21:00 |
| mgz | and 4937: http://float.endofinternet.org/bzrcst/clasfull/4937 (crash bug fixed, late hang) | 21:01 |
| vila | argh, poisoned url, kill firefox, kill firefox ! ;) | 21:01 |
| mgz | yeah, sorry ;) | 21:01 |
| mgz | I did load one of those even on your laptop, so it should survive | 21:02 |
| vila | this bug drove me crazy for a long while, there is really no way to predict when something will fail, hece the --parallel=fork trick | 21:02 |
| mgz | but that trick seems currently to be insufficent | 21:02 |
| mgz | and looking at my local test runs, things have got *much worse* with leaks in the past 300 revs | 21:03 |
| vila | mgz: sure, I knew since the beginning we were on thin ice | 21:03 |
| vila | it stoppped working for OSX long ago and get rid of the slaves for this reason | 21:03 |
| mgz | the number of leaks is about the same, but they're causing deadlocks, OOM testfailures, thread handle test failures, and huuuuge memory usage | 21:03 |
| mgz | so, something changed. | 21:03 |
| vila | I've seen it appearing on OSX and I could precisely point the revision, | 21:04 |
| vila | it was totally unrelated :) | 21:04 |
| mgz | ehhehe | 21:04 |
| mgz | there is a symptom vs. cause problem with this, too big a problem to isolate | 21:04 |
| vila | thread scheduling is not... damn, what's the word | 21:05 |
| mgz | the memory usage is causing the failures, or the leaking is causing the memory usage, or...? | 21:05 |
| mgz | deterministic? | 21:05 |
| vila | yeah, thanks, deterministic | 21:05 |
| mgz | okay, I think I'll do two more things before moving onto another problem for the moment | 21:06 |
| vila | not closing the sockets is causing the leaks, increasing memory usage (but not all I think) | 21:06 |
| mgz | #1 cherrypick my r4937 fix back on top of r4920 to see if I can squarely blame testtools for the change in mem usage | 21:07 |
| vila | more memory usage certainly leads to memory fragmentation, => increasing time => different scheduling => may be more leaks | 21:07 |
| mgz | #2 run some revs before and after robert's test-speedup (know what number that was?) | 21:07 |
| vila | at one point it's useless to try to understand what happens | 21:07 |
| vila | mgz: I think there was several commits for several improvements | 21:08 |
| vila | I'd say around 2.1 release | 21:08 |
| mgz | testtools did change some teardown/other details in pretty subtle ways | 21:14 |
| vila | mgz: don't rely on teardown, use addCleanup, you can't mix both | 21:16 |
| lifeless | moin | 21:16 |
| mgz | sure, but were the thread-related tests ever audited for that kind of thing after r4920? | 21:16 |
| vila | mgz: yes, there was some changes there.... speaking of the devil ! | 21:16 |
| lifeless | vila: you can mix them, they have a defined order | 21:16 |
| mgz | it's pure fluke that the bb.test_non_ascii problem went on to cause a reliable crash to annoy me into finding and fixing it | 21:17 |
| mgz | okay, set r4290+4937 running, time for a break. | 21:17 |
| vila | lifeless: I'm falling asleep right now, but I think I remember cases where you could easily shoot yourself in the foot by mixing them | 21:18 |
| lifeless | yes, we had a list discussion | 21:19 |
| lifeless | we want to transition entirely to cleanups | 21:19 |
| lifeless | go to sleep though :) | 21:19 |
| === mwhudson_ is now known as mwhudson | ||
| vila | right, that was the idea I was trying to convey: use addCleanup, not tearDown | 21:19 |
| vila | yeah, 22:22 is a good hour for that | 21:20 |
| mgz | vila: check the diff of r4937 ;) | 21:20 |
| mgz | the point is it happened 17 revs after the breakage, and there may be similar as-yet-uncaught issues related to threading | 21:21 |
| vila | mgz: :-D | 21:25 |
| * vila zzzz.... cmfdinjd bou8rh7m | 21:25 | |
| jam | lifeless: /wave | 22:00 |
| lifeless | jam: hai | 22:01 |
| lifeless | jam: did you have a chance to look at dirstate2? | 22:02 |
| jam | lifeless: I grabbed a copy of it, but haven't poked at it yet | 22:02 |
| lifeless | ok | 22:02 |
| lifeless | jam: whats the time for you now ? | 22:03 |
| jam | 4pm, 1hr before EOD | 22:03 |
| lifeless | so, between mountain view and montreal. doh, my clock is running out of zones | 22:06 |
| fullermd | Heck, I just lookit my watch, it tells me what jam's time is ;p | 22:09 |
| RumblePure | I'm in utter panic. I've checked out from my main branch to my laptop. I did bzr update on my laptop after having worked on my code, and that created a real mess. Original files got screwed up, and tons of files that end with .THIS and .OTHER have been created. | 22:38 |
| RumblePure | How can safely revert to latest commit on laptop? | 22:38 |
| RumblePure | That's all I care about now. | 22:39 |
| beuno | so | 22:39 |
| beuno | you had uncommited changes? | 22:39 |
| RumblePure | beuno: not on the laptop no. I had commited locally | 22:41 |
| beuno | I don't think I follow | 22:41 |
| RumblePure | 1. I checked out from my main branch to my laptop. | 22:42 |
| RumblePure | 2. I worked on my code on the laptop, doing local commits on the laptop's branch multiple times. | 22:42 |
| RumblePure | 3. Satisified with my work, I wanted to commit back to main branch on stationary. | 22:42 |
| lifeless | what bzr version? | 22:43 |
| RumblePure | 4. Bzr said I have to do bzr update before I can do that. After I did bzr update, everything got messed up. | 22:43 |
| lifeless | we made update much better recently, I thought. | 22:43 |
| RumblePure | lifeless: we've been over this man, last time this happened I followed your advice and updated to latest version. | 22:43 |
| RumblePure | 2.1.1 | 22:44 |
| RumblePure | Oh no I think I'm gonna have to throw up. | 22:44 |
| RumblePure | My local commits are no longer even showing when I do bzr log on the laptop. | 22:44 |
| lifeless | RumblePure: calm down | 22:45 |
| lifeless | RumblePure: its all there, there is no data loss | 22:45 |
| lifeless | RumblePure: do you have bzrtools installed ? | 22:45 |
| RumblePure | lifeless: then why wont bzr log show my previous local commits? | 22:46 |
| RumblePure | lifeless: no i dont. what does it do? | 22:46 |
| lifeless | because they are sitting staged until you commit | 22:46 |
| lifeless | if you run bzr st | 22:46 |
| lifeless | and look at the pending merges section of the output | 22:46 |
| lifeless | your most recent commit before you ran update will be there. | 22:46 |
| RumblePure | lifeless: they aren't shown when i do bzr st. only the status. | 22:47 |
| RumblePure | but never mind that. | 22:47 |
| RumblePure | All I wanna do know is to get things to the way they were before i did bzr update on laptop. | 22:48 |
| lifeless | RumblePure: 'bzr st' ? not 'bzr st .' or anything else ? | 22:48 |
| RumblePure | bzr st only | 22:48 |
| lifeless | ok | 22:48 |
| lifeless | anyhow | 22:48 |
| lifeless | if you could install the bzrtools plugin | 22:48 |
| lifeless | if you're on Debian or Ubuntu, apt-get install bzrtools | 22:48 |
| RumblePure | i already have it, or so it seems | 22:49 |
| lifeless | great | 22:50 |
| lifeless | run 'bzr heads --dead' | 22:50 |
| RumblePure | ... what does it do? | 22:50 |
| lifeless | queries your repository | 22:50 |
| RumblePure | Ok this is good, I think I see my last commit. | 22:51 |
| jam | lifeless: looking at your dirstate2 branch, I see that you don't handle a failure in "rename current NEW.check". Are you looking for more of a 'logically, this sequence seems correct' check, or a code check? | 22:51 |
| lifeless | jam: well I know its a sketch, but all feedback is good | 22:52 |
| lifeless | jam: I think the thing to answer at the moment is 'is this the right approach/what needs to be done to plug conceptual holes in it' | 22:52 |
| lifeless | RumblePure: now, you'll have something like: | 22:53 |
| lifeless | HEAD: revision-id: robertc@robertcollins.net-20091220080322-7cx34xsdvkzm1x0p | 22:53 |
| RumblePure | lifeless: I should say that I just realized that I did have uncommited data on the laptop. So this was data that had not even been locally commited. This was the state before I tried bzr update. | 22:53 |
| lifeless | RumblePure: ok, so you *did* have uncommitted changes. | 22:54 |
| lifeless | that makes it trickier. | 22:54 |
| RumblePure | lifeless: but you can scratch it. | 22:54 |
| RumblePure | lifeless: not that important right now. | 22:54 |
| lifeless | RumblePure: you sure ? | 22:54 |
| RumblePure | lifeless: I'm more forced to than sure, but yeah. | 22:54 |
| lifeless | ok. | 22:54 |
| RumblePure | HEAD: revision-id: purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2 (dead) | 22:54 |
| lifeless | copy that string from the email bit on. E.g. for me it would be robertc@robertcollins.net-20091220080322-7cx34xsdvkzm1x0p | 22:55 |
| lifeless | without the (dead) bit | 22:55 |
| jam | lifeless: so I have some "this bit is hard to understand" stuff. and I still need to go through it step-by-step logically to make sure things fail correctly | 22:55 |
| lifeless | now first we reset your working tree: | 22:55 |
| RumblePure | purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2 | 22:55 |
| jam | first bit is that it seems ok | 22:55 |
| lifeless | bzr revert | 22:55 |
| lifeless | secondly, we restore your local state | 22:55 |
| [1]reggie | hey bzr experts -- we have a commit mailer that is failing to work with a SSL server on port 465 | 22:56 |
| lifeless | 'bzr pull --local . -r revid:purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2' | 22:56 |
| [1]reggie | any chance I"m just missing some config option? | 22:56 |
| jam | [1]reggie: I don't think smtplib trivially supports SSL, if you can, use TLS on the standard ports | 22:57 |
| RumblePure | lifeless: ok it says on revision 89, this was better than when bzr log showed only up to 83. | 22:57 |
| [1]reggie | jam, alas this is not an option (other than just setting up a local smtp server) | 22:57 |
| lifeless | RumblePure: now that you've encountered this with bzr 2.1.1, we know that we haven't fixed the issue as well as we thought we had. Is your code open source? | 22:58 |
| RumblePure | lifeless: no, super really sorry man. | 22:58 |
| lifeless | no problem | 22:58 |
| lifeless | however, would you be willing to run some queries for us - that would return metadata only ? | 22:59 |
| RumblePure | lifeless: I remember your buddy at this channel asked the same question. Trust me I wanna help you to 105% to catch this bug, but can't give you the code. :-/ | 22:59 |
| lifeless | thats ok, I understand completely. | 22:59 |
| jam | [1]reggie: it could probably be updated to do so, looking here: http://docs.python.org/library/smtplib.html | 22:59 |
| RumblePure | lifeless: affirmitive. but do it quickly | 22:59 |
| jam | you have to use a different class | 22:59 |
| jam | SMTP_SSL | 22:59 |
| lifeless | RumblePure: bzr heads --all | 22:59 |
| jam | but otherwise should be the same | 22:59 |
| jam | Not sure how you would indicate that in the config file | 22:59 |
| RumblePure | lifeless: One question first, is the local branch on my laptop healthy now? | 23:00 |
| lifeless | RumblePure: should be, yes. | 23:00 |
| [1]reggie | right. I saw that. I'm using a binary insatll of windows. I guess I could use a python install | 23:00 |
| RumblePure | lifeless: I still got some *.THIS and *.OTHER files laying around. Should I just get rid of them? | 23:00 |
| lifeless | RumblePure: yes | 23:00 |
| RumblePure | lifeless: will it bother your inqueries that you want me to run if i just clean up first and do a local commit? | 23:01 |
| jam | [1]reggie: how are you generating emails then? This is failing for 'bzr send'? | 23:01 |
| RumblePure | *inquiry | 23:01 |
| lifeless | RumblePure: it will yes | 23:01 |
| jam | you can always 'bzr send -o filename' and then send that with another mailer | 23:01 |
| lifeless | RumblePure: I want you to run | 23:01 |
| jam | If it is from 'bzr-email', that isn't bundled with the installer anyway | 23:01 |
| RumblePure | lifeless: ok, lemme at least make a hard copy of the folder. | 23:01 |
| lifeless | bzr find-merge-base . [the master branch you checked out] | 23:01 |
| lifeless | that will print a revid | 23:01 |
| jam | also, on Windows, I think the default is to have "bzr send" spawn whatever MAPI mailer is present | 23:02 |
| jam | which means we aren't the ones sending to SMTP anyway. | 23:02 |
| lifeless | I then want you to look in 'bzr log --show-ids' for that revid, and print the revno that it has there | 23:02 |
| lifeless | On 04/08/2010 03:34 PM, Francis J. Lacoste wrote: | 23:02 |
| lifeless | > Stuart Metcalf announced that they should be rolling out an OpenID-enabled | 23:02 |
| lifeless | > Mumble at the end of next week. That will save us from registering 38 | 23:02 |
| jam | anyway, more details needed... :), I might be around later | 23:02 |
| lifeless | bah sorry, paste error | 23:02 |
| lifeless | ignore the email :) | 23:02 |
| === salgado is now known as salgado-afk | ||
| mgz | are the email address for third party packagers written down anywhere? I know at least some of them subcribe to the bzr list | 23:04 |
| RumblePure | lifeless: I reach the master branch through bzr+ssh and a dynamic ip-number that has changed. Will go with new ip-number | 23:04 |
| lifeless | mgz: they were on the wiki at one point | 23:04 |
| mgz | I shall poke around. | 23:05 |
| RumblePure | lifeless: It says it requires argument OTHER | 23:05 |
| RumblePure | lifeless: oh wait | 23:06 |
| RumblePure | lifeless: never mind | 23:06 |
| mgz | hm, DistroDownloads wikipage currently does not seem to have contact points | 23:07 |
| mgz | or rather, it has general links and things but no email addresses. CCing people on a short email I can do, filing upstream bugs and so on is too much for a teeny change | 23:08 |
| lifeless | mgz: which change are we talking about ? the dep one? no need to bother there as I said ;) | 23:09 |
| lifeless | just a courtesy if you feel like it | 23:09 |
| RumblePure | lifeless: It has revno 83 | 23:10 |
| mgz | well, if I could find email addresses, courtesy would be easy, just post a short message to list with CCs. | 23:10 |
| RumblePure | lifeless: the revision id that matches what bzr find-merge-base gave. | 23:10 |
| lifeless | RumblePure: can you look at bzr log <master branch> --show-ids, and get the revno that the base revisionid has there ? | 23:11 |
| lifeless | RumblePure: it may be 83 as well, just want to be sure | 23:11 |
| RumblePure | lifeless: affirmitive, it is 83 that has that revid | 23:12 |
| lifeless | RumblePure: finally, I need to know if you had new files involved in your branch | 23:12 |
| lifeless | bzr st -r 83.. | 23:13 |
| lifeless | have a look in that, and tell me if there are new files | 23:13 |
| RumblePure | lifeless: yes i remember and just checked, there were new files involved | 23:15 |
| lifeless | were those files the ones that went really messy? | 23:15 |
| lifeless | (I don't know) is an ok answer. | 23:15 |
| RumblePure | lifeless: other files went messy too, but yeah those files that were new at the time went messy. | 23:17 |
| lifeless | ok | 23:17 |
| RumblePure | lifeless: with new, I mean they show up under "added:" | 23:17 |
| lifeless | I think this gives me enough to try to reproduce | 23:17 |
| lifeless | thank you | 23:17 |
| lifeless | now, to get your changes into your master | 23:17 |
| RumblePure | lifeless: no problem. Just grab me anytime at ArashU@gmail.com and I'll see what I can do more. | 23:18 |
| lifeless | as you've only added stuff - doing the following should work: | 23:18 |
| lifeless | bzr unbind | 23:18 |
| lifeless | bzr push <master url> | 23:18 |
| lifeless | bzr bind | 23:18 |
| RumblePure | lifeless: Can we try that some other time? I really need to get to bed. Just wanna cleanup (remove *.THIS and *.OTHER files) and commit locally. Will that be OK for now? | 23:18 |
| lifeless | sure | 23:19 |
| lifeless | thanks for your help | 23:19 |
| RumblePure | lifeless: Ok, now I've fixed the stuff I lost and commited *breathing out*. Thx for the help lifeless. You saved my day again. You got my email ArashU@gmail.com? Just grab if you want help to track that bug. | 23:27 |
| lifeless | sure thing, thanks | 23:30 |
| bignose | when I ‘bzr merge ; bzr revert --forget-merges’ I understand that the working tree remains with the changes, but the merged revisions are gone. | 23:34 |
| bignose | but what about ‘bzr merge ; bzr revert’? do the merged revisions remain, waiting for a commit? | 23:34 |
| lifeless | no | 23:35 |
| lifeless | 'bzr revert' discards all changes | 23:35 |
| lifeless | 'bzr revert .' discards only path changes | 23:35 |
| lifeless | 'bzr revert -forget-merges' discards only pending merges | 23:35 |
| lifeless | its a bit magic; sorry. | 23:35 |
| bignose | ah. so why would I have seen advice elsewhere to do both ‘bzr revert ; bzr revert --forget-merges’ to be sure? | 23:35 |
| lifeless | no idea | 23:35 |
| bignose | is it a behaviour that's been different in the past? | 23:35 |
| lifeless | nope | 23:36 |
| lifeless | 'bzr revert' has, ever since creation, been a Big Hammer | 23:36 |
| bignose | what does “only path changes” mean? | 23:36 |
| lifeless | files, directories, symlinks that have changed | 23:36 |
| lifeless | 'things that are paths' | 23:36 |
| bignose | but not contents? | 23:36 |
| lifeless | yes their contents | 23:36 |
| bignose | ah. so what's excluded? | 23:37 |
| lifeless | pending merges | 23:37 |
| bignose | heh. | 23:37 |
| bignose | okay, maybe that's what I'm remembering. ‘bzr revert . ; bzr revert --forget-merges’ | 23:37 |
| bignose | maybe from a person who kept them as distinct operations in their mind | 23:37 |
| lifeless | I would guess a git user | 23:37 |
| bignose | righto. | 23:37 |
| lifeless | as git requires . for basically everything | 23:38 |
| lifeless | but . is an explicit path for us, rather than nothing which is 'find the root and do the default' | 23:38 |
| bignose | so, it can be useful to ‘bzr merge ../foo-feature/ ; bzr revert . ; bzr revert ../bar-feature/ ; bzr commit’ | 23:38 |
| bignose | because that allows a single commit of all the merges | 23:38 |
| bignose | right? | 23:38 |
| bignose | hmm, no. | 23:39 |
| bignose | is there a way to get a bunch of revisions from various places, apply them all, and only then commit? | 23:39 |
| lifeless | bzr merge foo; bzr merge bar --force; bzr merge gam --force; bzr commit | 23:41 |
| bignose | okay, just read the help on that. perfect, thanks. | 23:42 |
| bignose | so lifeless, you're no longer living in oz? | 23:43 |
| RumblePure | lifeless: hey lifeless. I told you I cleaned up, made some changes and then made two or three more local commits. Well guess what. After that I ran bzr update again and it all went smoothly. | 23:45 |
| RumblePure | lifeless: after the update i commited back to master, no problems! | 23:45 |
| RumblePure | lifeless: and .bzr/branch/branch.conf still had the new ip-number. Maybe this wasn't related to the changing ip? | 23:46 |
| RumblePure | lifeless: and I've checked the code. All my latest changes are there. | 23:46 |
| lifeless | RumblePure: I'm not sure | 23:46 |
| lifeless | I'll try and reproduce | 23:46 |
| lifeless | bignose: yah, moved back to NZ | 23:47 |
| RumblePure | lifeless: but remember when the problem showed up I had some locally uncommited changes when I tried to commit back to master? you think that caused it all? | 23:47 |
| lifeless | at this point, yes | 23:47 |
| RumblePure | lifeless: Well I'll try to pin it down some other day, try to find out what's really causing this. | 23:49 |
| mgz | okay, that's shiny. | 23:51 |
| mgz | not only did sourceforge let me use my launchpad openid to post a bug report (as I've long forgotten my login), but launchpad understood the concept of an upstream bug at sourceforge and it's easy to make pretty linky. | 23:52 |
| mgz | it's almost like the days of free software balkanisation are over | 23:52 |
| lifeless | almsot ;) | 23:52 |
| ciss_ | if i try to revert to revision 1, bazaar tells me: "bzr: ERROR: Path(s) are not versioned" - i suppose this is due to some files been unrecoverably deleted. can i tell bzr to ignore missing files and do the revert anyway? | 23:55 |
| ciss_ | ah, sorry, found my error | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!