| vila | full test suite passing on natty with python2.7 \o/ | 00:40 |
|---|---|---|
| fullermd | Must be time for py2.8 to come out. | 00:58 |
| vila | fullermd: nah, switching to py3.x would be far much fun :) | 01:01 |
| vila | fullermd: by the way, if you're near Dallas in the coming 10 days, come have a beer ;) | 01:01 |
| fullermd | If I could get that far away from this project, I'd keep running and never come back :| | 01:03 |
| vila | . o O (Oh... one of *those* days :-/) | 01:07 |
| fullermd | Days? Ho ho ho. I stopped counting it in _days_ last summer. | 01:08 |
| AfC | Any idea what the state of the "transparent http pass through to bzr server" mechanism is? I last looked for it a couple years ago, and could make it fly, but is it still around? | 02:05 |
| lifeless | I'm not aware of it plans or actions to remove it. | 02:18 |
| maxb | "transparent http pass through to bzr server"? bzr+http:// ? | 02:18 |
| lifeless | maxb: http:// | 02:23 |
| lifeless | maxb: which probes for a bzr server | 02:23 |
| maxb | Ah, http://, which decides to be bzr+http:// if possible | 02:25 |
| lifeless | yes | 02:26 |
| AfC | yeah, that | 02:31 |
| AfC | is it in active use anywhere? | 02:31 |
| AfC | (ie, are you guys using it on, say, Launchpad) | 02:31 |
| AfC | I am often is given to feel that he's the only one using bzr:// :( | 02:32 |
| AfC | I'd hate to go down another path which isn't really what the developers want me doing. | 02:32 |
| poolie | "he" meaning AfC? | 02:32 |
| AfC | poolie: yeah :) changed from /me to I :) | 02:32 |
| AfC | IRC needs history editing! | 02:33 |
| poolie | we are not using it externally on lp | 02:33 |
| poolie | we could deploy it publicly | 02:33 |
| poolie | probably we would only do that if we could get clients switching to it automatically when they are accessing a public readonly branch | 02:33 |
| fullermd | I gave passing thought to setting up bzr+http once, but the inflexibility of paths made me give up before really trying. | 02:33 |
| poolie | i don't think the efficiency win of avoiding ssh would be worth making users manually type different urls | 02:34 |
| fullermd | Every once in a while you hear somebody here running it I think... | 02:34 |
| poolie | some people might find it worthwhile, but probably not enough to get to the top of the list | 02:34 |
| AfC | I've actually got it rigged up so that bzr://path/to are our public URLs and bzr+ssh://path/to are what developers push to. Symmetrical, at least | 02:35 |
| AfC | but I was exploring whether or not [instead] I could host out of eg ~/public_html via Apache mod_userdirs and then realized I'd have to have people use http:// URLs there. | 02:35 |
| fullermd | Is where I gave up. | 02:35 |
| fullermd | (actually, with ~/public_bzr, but...) | 02:36 |
| AfC | heh, nice | 02:36 |
| AfC | yeah, obviously you wouldn't want n instances of python bzr serve running | 02:36 |
| fullermd | (separate vhost, with UserDir so set, so it all Just Works... except dumbly) | 02:36 |
| AfC | and in any case, there's the port issue | 02:36 |
| misterbiscuit | having trouble with bzr fast-export-from-svn | 02:38 |
| misterbiscuit | probably my own fault | 02:38 |
| maxb | define trouble | 02:39 |
| misterbiscuit | keep ending up with svn.core.SubversionException: ("Can't open file '.../format':No such file or directory" | 02:39 |
| maxb | hmm... without obfuscation, please? | 02:39 |
| misterbiscuit | '...' isn't literally printed | 02:40 |
| misterbiscuit | OK | 02:40 |
| misterbiscuit | background: in the root of my svn repo, there are several directories, one for each project | 02:41 |
| misterbiscuit | inside each project directory, there is the usual trunk, branches, tags | 02:41 |
| misterbiscuit | the repo is accessed via HTTPS | 02:41 |
| misterbiscuit | so I tried: bzr fast-export-from-svn https://svn.example.com/svn/myrepo/myproject | 02:42 |
| misterbiscuit | and ended up with a traceback whose last line is | 02:43 |
| misterbiscuit | svn.core.SubversionException: ("Can't open file 'https:/svn.example.com/svn/myrepo/myproject/format': No such file or directory", 2) | 02:44 |
| misterbiscuit | correction, I tried: bzr fast-export-from-svn https://svn.example.com/svn/myrepo/myproject myproject.fi | 02:45 |
| misterbiscuit | sorry, left off the last parameter there | 02:45 |
| fullermd | I'd guess offhand that fast-export-from-svn expects to be pointed at the _repo_, not something inside it. | 02:45 |
| maxb | fast-export-from-svn expects to operate on a repository locally on disk, not an URL | 02:45 |
| maxb | it also assumes a /trunk directly in the root of the repository | 02:47 |
| maxb | You may be better off using bzr-svn | 02:47 |
| maxb | Instead of bzr-fastimport | 02:47 |
| maxb | bzr svn-import https://svn.example.com/svn/myrepo/myproject myproject.bzr | 02:48 |
| misterbiscuit | so: I scp'ed the entire repo down (myrepo) to my local disk, and tried: bzr svn-import /path/to/myrepo myrepo.fi | 02:48 |
| misterbiscuit | and I ended up with a message like, "Exporting revision 191... skipping." for every revision | 02:49 |
| misterbiscuit | after it finished, myrepo.fi was just an empty file | 02:49 |
| maxb | uh, I think you mean you ran 'bzr fast-export-from-svn /path/to/myrepo myrepo.fi' | 02:50 |
| misterbiscuit | I'm sorry, you're correct | 02:50 |
| maxb | see what I said above about using using bzr-svn instead of bzr-fastimport | 02:51 |
| misterbiscuit | I will try it. I started with fast-export-from-svn because that's the approach strongly recommended by the Bazaar Data Migration Guide | 02:54 |
| misterbiscuit | In fact, the page I'm looking at doesn't even mention svn-import | 02:55 |
| misterbiscuit | is it deprecated or soon-to-be-deprecated? | 02:55 |
| misterbiscuit | ahh, it is mentioned as an alternative tool on the subversion-specific page in the migration guide | 02:56 |
| misterbiscuit | so I click the bzr-svn link and I'm taken to ... the project page? Where's the documentation? | 02:57 |
| misterbiscuit | this new user experience needs improvement | 02:57 |
| misterbiscuit | and there's a third tool apparently: svn2bzr | 03:01 |
| fullermd | That I'm pretty sure IS quite long deprecated. | 03:01 |
| misterbiscuit | bzr svn-import https://svn.example.com/svn/myrepo results in: | 03:05 |
| misterbiscuit | bzr: ERROR: Invalid http response for https://svn.example.com/svn/myrepo/.bzr/branch-format: Unable to handle http code 401: expected 200 or 404 for full response. | 03:05 |
| misterbiscuit | our svn server does require authentication | 03:05 |
| misterbiscuit | bzr help svn-import doesn't mention any way for me to provide my credentials, however | 03:06 |
| misterbiscuit | I assume there is none | 03:08 |
| fullermd | I believe it reads svn's stored credentials. | 03:08 |
| misterbiscuit | Hmm, that would make sense, but then I'd argue it isn't working | 03:09 |
| misterbiscuit | I'm running bzr svn-import /media/maxtor/svn/myrepo now | 03:09 |
| misterbiscuit | and its cranking away | 03:09 |
| misterbiscuit | (that's my local copy that I scp'ed down from the svn server) | 03:10 |
| fullermd | Note that it's probing for a bzr branch there, not svn. So maybe bzr-svn isn't engaged yet at that point. | 03:10 |
| misterbiscuit | Yeah, that '.bzr/branch-format' looked strange to me | 03:11 |
| misterbiscuit | Any idea why its doing that? Did I run the command incorrectly? | 03:11 |
| fullermd | You may be able to force it using svn+https://. | 03:11 |
| fullermd | Well, when you get a URL, who knows what it is? It could be svn, it could be bzr smart, it could be bzr dumb, maybe it could (if you have the plugin) be hg or git or SCCS... so, in some order, it checks until it finds a match. | 03:12 |
| misterbiscuit | Shouldn't "svn-import" assume its an svn repo? | 03:13 |
| fullermd | All else being equal, probably. But the layer connecting to the URL may have no idea what command was being run. | 03:13 |
| misterbiscuit | I see | 03:14 |
| fullermd | (just a guess of course) | 03:14 |
| misterbiscuit | Yeah, fair enough | 03:14 |
| misterbiscuit | bzr svn-import svn+https://svn.example.com/svn/myrepo looks to be working | 03:16 |
| misterbiscuit | Did appear to be working | 03:17 |
| maxb | You really probably wanted to be running svn-import svn+https://svn.example.com/svn/myrepo/myproject | 03:17 |
| misterbiscuit | I'll try that now | 03:17 |
| misterbiscuit | It did some work, but then bombed | 03:18 |
| misterbiscuit | 'KeyError: 'No such TDB entry' | 03:19 |
| misterbiscuit | Note that the bzr svn-import I kicked off against the repo on my local filesystem is still running | 03:19 |
| misterbiscuit | So assuming it finishes, I guess that's the way I'll have to go | 03:20 |
| aroman | hey all, sorry to bother you guys with such a n00b question, but I somehow set bzr to push to the wrong launchpad branch. However, when I push to the right one (manually specifying the branch), running "bzr pull" uses the _old_ branch, not the new one. Is there any way to force bzr to push to a specific lp branch? Thanks! | 03:20 |
| poolie | aroman, use 'push/pull --remember' | 03:20 |
| poolie | or vi .bzr/branch/branch.conf | 03:20 |
| aroman | poolie: brilliant -- I was just digging around in .bzr now. thanks a ton! | 03:21 |
| lifeless | spiv: btw, you were assigned to the bug's LP bugtask... you might want to search for bugs to which you are assigned in *any* project that you're not actually intending to be assigned to. | 03:27 |
| misterbiscuit | maxb and fullermd, thanks for your help; I have to go but it looks like running bzr svn-import on a local copy of my svn repo might work out | 03:30 |
| catphish | is there any provision in the network protocols to allow a user to create remote branches? | 09:55 |
| catphish | or does the server admin need to create each branch? | 09:56 |
| maxb | bzr push url works just fine | 10:02 |
| maxb | where url doesn't exist before | 10:02 |
| catphish | so the server is expected to create a branch where one doesn't exist? | 10:05 |
| AfC | yes | 10:50 |
| neaj | i want to 'bzr branch http://svn.../somemassiverepo/sometinymodule' .. now it's downloading 10s of MB of metadata .. is this the right way? | 10:53 |
| neaj | will that fat metadata cache be reused if i like 'bzr branch http://svn.../somemassiverepo/sometinymodule | 10:53 |
| neaj | sorry | 10:54 |
| neaj | will that fat metadata cache be reused if i later 'bzr branch http://svn.../somemassiverepo/someothermodule' ? | 10:54 |
| neaj | hmm, 'bzr branch http://svn.plone.org/svn/collective/dotipython dotipython' worked, but now 'bzr branch http://svn.plone.org/svn/collective/PDBDebugMode PDBDebugMode' fails: bzr: ERROR: Not a branch: "http://svn.plone.org/svn/collective/PDBDebugMode". | 11:18 |
| neaj | maxb: thanks, yes, i see it isn't re-downloading the metadata | 11:18 |
| maxb | bzr-svn has a concept of repository layouts, by which it defines what paths in svn are considered branches | 11:21 |
| maxb | have a look in your ~/.bazaar/subversion.conf for what it has guessed as the layout for this repository | 11:22 |
| === Ursinha-afk is now known as Ursinha | ||
| maxb | catphish: Yes, does it not? | 12:22 |
| catphish | it doesn't exist yet | 12:23 |
| catphish | i'm creating a server to host bzr branches | 12:23 |
| catphish | not sure what protocol it will use yet | 12:23 |
| catphish | hopefully smart over http | 12:23 |
| fabio_kreusch | Hi there, I have a repository which is a mix of a bzr repository and a subversion repository. I have this because the project was started on a Bzr server and then the client requested for us to upload it to a subversion server. So what I did was to ignore on .bzrignore the .svn folders, and on Subversion I ignored the .bzr folder | 12:29 |
| catphish | hopefully the backend will automatically create the branches as required | 12:30 |
| catphish | i will just not validate the last part of the url | 12:30 |
| fabio_kreusch | But now, when I try to commit on bzr to bzr+http://mybzrserver, I receive this msg: 'A subversion remote access command failed: could not resolve hostname thehostname' | 12:31 |
| fabio_kreusch | I think bzr is trying to commit to subversion too | 12:31 |
| fabio_kreusch | is there any way to make bzr totally ignore svn? | 12:31 |
| maxb | fabio_kreusch: It sounds like you have the bzr-svn plugin installed, and bzr is unsure whether it should be operating on the .bzr or .svn part of the working copy | 12:32 |
| maxb | Try bzr --no-plugins commit | 12:32 |
| fabio_kreusch | ok, that did it, but my co-workers use tortoise-bzr, and it doesn't seem to support --no-plugins | 12:36 |
| fabio_kreusch | do you know if there is another way to disable it? | 12:36 |
| fabio_kreusch | maxb: ? | 12:37 |
| quicksilver | tell them GUIs are for the weak, and if they don't learn the CLI they will be fed to the lions? | 12:37 |
| fabio_kreusch | haha | 12:37 |
| quicksilver | alternatively, remove the svn plugin from their machines (if they don't need it for some other reason) | 12:37 |
| fabio_kreusch | i whish i could do that =P | 12:37 |
| maxb | I suggest not working in a hybrid working copy with both .bzr and .svn | 12:37 |
| maxb | Or, you could uninstall bzr-svn if you never use | 12:37 |
| maxb | it | 12:37 |
| Tak | being fed to lions is preferable to using the windows cli | 12:38 |
| fabio_kreusch | maxb: i did it that way because bzr-svn was acting weird for me | 12:38 |
| maxb | Are you aware of how bzr-svn works? Using it properly would seem to be a far better way of managing this than separately committing to two different vcses | 12:38 |
| maxb | You could just push the bzr branch straight into svn | 12:39 |
| fabio_kreusch | my problem was that every time I pushed the bzr branch to svn with bzr-svn, it was recreating old branches which were already merged into trunk on the svn repository | 12:39 |
| soren | Ok, so I've just branched lp:bzr. If I run "./bzr selftest something | 13:47 |
| soren | " | 13:47 |
| soren | ... I get some warnings about plugins it can't load. This is probably fine, but I also get this: | 13:47 |
| soren | bzr: ERROR: The API for "<module 'bzrlib' from '/home/soren/src/bzr/bzr/bzrlib/__init__.pyc'>" is not compatible with "(2, 2, 0)". It supports versions "(2, 3, 0)" to "(2, 3, 0)". | 13:47 |
| soren | Am I doing something wrong? | 13:52 |
| maxb | Perhaps ~/.bzr.log will provide a traceback which illuminates what is complaining | 13:55 |
| catphish | what does "bzr branches" do? | 13:56 |
| catphish | it seems to take almost a second to run | 13:56 |
| catphish | and produces the same output as 'ls' - is there any advantage to using it over ls? | 13:56 |
| Tak | `bzr help commands/branches` will tell you ;-) | 13:57 |
| soren | maxb: There's no such thing. | 13:57 |
| soren | maxb: Oh, in ~? | 13:57 |
| catphish | Tak: the help doesn't tell me | 13:57 |
| catphish | i tried that first | 13:58 |
| Tak | "Purpose: Scan a location for branches" | 13:58 |
| catphish | yes, but my question stands, what is the advantage over 'ls' | 13:58 |
| maxb | catphish: The problem with "bzr branches", is that it recurses over the entire tree, and if you have bzr-{svn,hg,git} installed, it spends ages probing for those kinds of branches too | 13:58 |
| Tak | ... ls doesn't know about branches? | 13:59 |
| maxb | that's why it's unusably slow | 13:59 |
| soren | maxb: Oh, it's due to a plugin in ~/.bazaar/plugins | 13:59 |
| soren | maxb: Thanks! | 13:59 |
| catphish | maxb: thanks, i think i will just use ls then, i don't need recursion or foreign repos | 13:59 |
| etenil | Hi there | 14:28 |
| etenil | I'm working on a project on a linux and a windows box, and the windows box is always changing the files mode so that bazaar lists these as changes (which they aren't). How can I make bazaar ignore this? | 14:30 |
| LeoNerd | Shared filesystem? | 14:32 |
| awilkins | Tak, On the matter of Windows CLI, Powershell makes it almost bearable. | 14:33 |
| awilkins | The terminal is still bobbins, but the shell has some features I wish the *nix shells had. | 14:33 |
| etenil | LeoNerd: No, it's not shared, I just transported the files with me on a memory stick | 14:33 |
| awilkins | etenil, There's a bug for that | 14:33 |
| etenil | ah ok | 14:33 |
| LeoNerd | etenil: Ah.. Try mounting noexec ? | 14:33 |
| etenil | well then... | 14:33 |
| awilkins | The problem is that your thumbstick is FAT32 | 14:33 |
| LeoNerd | Or at least, with a sensible mode so it doesn't go shoving +x everywhere | 14:34 |
| awilkins | ^^ mount noexec | 14:34 |
| etenil | yes, it is fat32 | 14:34 |
| awilkins | OR do what I used to do and keep the repo on the stick, and take a lightweight checkout from it to the local filesystem | 14:34 |
| etenil | well the problem isn't with the linux box but with the windows box | 14:34 |
| awilkins | Problem is that FAT32 has no exec bit - so by default Linux assumes that it's ON for every file, unless you mount noexec | 14:35 |
| catphish | if its fat32 the problem may actually be with linux | 14:35 |
| catphish | as far as i know fat32 has no modes | 14:35 |
| awilkins | Windows has no concept of exec bit, so it assumes it's OFF | 14:35 |
| catphish | so the linux kernel will make them up | 14:35 |
| awilkins | Actually, it just leaves existing ones along | 14:35 |
| etenil | and there's no rule I could put in .bzrignore to solve this I suppose? | 14:36 |
| LeoNerd | noexec would break e.g. shell/perl/ypthon | 14:36 |
| catphish | couldn't you just commit them with the the exec bits set | 14:36 |
| LeoNerd | *gah enter key* ... scripts that might happen to be on the filesystem, whereas exec generally doesn't break anything. So exec is usually the default sa it breaks less | 14:36 |
| awilkins | Bug is : https://bugs.launchpad.net/bzr/+bug/248333 | 14:37 |
| exarkun | bzr: ERROR: No such file: u'/var/lib/buildbot/twisted/.bzr/repository/indices/49ef04533e5410f03a9e1f78b25083b0.rix': [Errno 2] No such file or directory: u'/var/lib/buildbot/twisted/.bzr/repository/indices/49ef04533e5410f03a9e1f78b25083b0.rix' | 14:37 |
| etenil | ah | 14:38 |
| etenil | a bzr revert did it | 14:38 |
| exarkun | 'bzr update' started failing with this error | 14:38 |
| etenil | \o/ | 14:38 |
| maxb | exarkun: The implication being that an internal file has mysteriously vanished from the bzr repository | 14:39 |
| ChrisWoollard | I have a branch on my computer. I have deleted a file from it. How can I pull the latest version from lp? | 14:39 |
| ChrisWoollard | of that file. | 14:39 |
| awilkins | ChrisWoollard, You can either bzr revert that file (if you've not comitted it's deletion) or you can bzr cat it it from a branch that has it (if you've not committed it's deletion) | 14:40 |
| maxb | ChrisWoollard: Deleted... and then committed the deletion? And now you want to undo the deletion and track updates from the parent branch again? | 14:40 |
| ChrisWoollard | it is not commited | 14:41 |
| awilkins | ChrisWoollard, Just revert it's path | 14:41 |
| awilkins | Or use qrevert to find it | 14:41 |
| exarkun | maxb: Hrm :/ | 14:42 |
| * awilkins is assuming you have qbzr installed or are on the default Windows distro | 14:42 | |
| ChrisWoollard | Lovely. Thanks. | 14:42 |
| maxb | exarkun: NFS? ext4? Recent system crashes? | 14:42 |
| exarkun | ext3, no recent crashes | 14:43 |
| maxb | exarkun: Does the .pack file with the same hex-id exist? Do the other indices? (.rix .iix .tix .six .cix) | 14:43 |
| maxb | Format of this repository? | 14:43 |
| exarkun | There's an obsolete pack with that hex | 14:44 |
| maxb | ! | 14:44 |
| exarkun | Shared repository (format: 2a) | 14:44 |
| maxb | are the five indices for that hex also present in the obsolete_packs dir? | 14:44 |
| exarkun | oh. yes. | 14:45 |
| maxb | In that case, mv the pack into packs/ and the indices into indices/ | 14:45 |
| maxb | The implication being that something has violated the supposed inviolate ordering of moving packs vs. updating pack-names | 14:46 |
| exarkun | okay, after that the update succeeded | 14:48 |
| exarkun | I doubt I can provide instructions for reproducing the problem. Is a bug report saying "something can violate the supposed inviolate ordering of moving packs vs. updating pack-names" useful? | 14:50 |
| maxb | What is the bzr version? | 14:50 |
| exarkun | 2.2.2 | 14:50 |
| maxb | hmm. I'm not guaranteeing anyone will do anything useful with the bug report, but it might be worth filing it anyway, to register on the developers collective conciousness that this issue occurs | 14:51 |
| maxb | If you do, be sure to mention ext3, because a lot of this class of issue is easily blamed on ext4 | 14:52 |
| exarkun | okay, thanks | 14:52 |
| * exarkun notices something else | 14:53 | |
| exarkun | here's the first time the error became apparent, http://buildbot.twistedmatrix.com/builders/lucid32-py2.7maint/builds/307/steps/bzr/logs/stdio | 14:54 |
| maxb | hrm. I wonder what the other process holding the lock was | 14:56 |
| exarkun | yea, that'd be useful. but I guess that information is unavailable. | 14:57 |
| spiv | exarkun: good morning | 15:00 |
| spiv | exarkun: I assume you're using bzr 2.1.0 or newer? | 15:00 |
| exarkun | spiv: yes, 2.2.2 | 15:00 |
| spiv | Ok, no known bugs in this stuff since 2.1.0 I think. | 15:01 |
| exarkun | Hm | 15:05 |
| exarkun | I guess there is concurrent access to the shared repository in this scenario. | 15:05 |
| exarkun | I forget, does that actually work yet? | 15:06 |
| maxb | yes | 15:06 |
| exarkun | okay. At least that perhaps explains why something was locked. | 15:07 |
| exarkun | https://bugs.launchpad.net/bzr/+bug/701940 | 15:07 |
| maxb | The real question is how the lock managed to go away without the new pack-names being written | 15:08 |
| spiv | exarkun: thanks, that bug report looks good (as much it can be with the available info, at least...) | 15:09 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| ovnicraft | hello guys, i am new in bzr i have a problem i bzr merge and i dont apply the changes for specific file , how i can do it? | 15:55 |
| ovnicraft | i found bzr revert --forget-merges but can i aplly just for a file? | 15:58 |
| ovnicraft | i run it with my file as arg but i still see the changes in the diff my question is, when i commit the changes will applied? | 16:00 |
| ovnicraft | any feedback here? | 16:02 |
| fullermd | --forget-merges isn't what you want. That makes it lose the merge metadata. | 16:02 |
| fullermd | You'd just want to revert the file. | 16:02 |
| spiv | ovnicraft: as fullermd says, just "bzr revert FILE" | 16:04 |
| ovnicraft | spiv, thanks and when i push in parent repository what happen? my changes in file will applied? | 16:15 |
| ovnicraft | or give conflicts? | 16:15 |
| ovnicraft | spiv, | 16:16 |
| ovnicraft | so i am trying to push and tell what the branches diverges | 16:16 |
| spiv | It's just a regular commit, there's nothing special about reverting or not that file. | 16:17 |
| spiv | ovnicraft: use 'bzr missing' or a graphical tool like 'bzr qlog BRANCH1 BRANCH2' to see how their revision history diverges. | 16:17 |
| ovnicraft | spiv, the diverge is in the file what i revert | 16:18 |
| spiv | No, divergence is a property of branches, not files. | 16:18 |
| ovnicraft | but bzr dont letme push | 16:19 |
| ovnicraft | isee in documentacion push args --overwrite | 16:19 |
| spiv | Yes, because the branches have diverged. | 16:19 |
| spiv | Yes, overwrite will let you push - but it will overwrite some changes. | 16:20 |
| spiv | You should look at 'bzr missing' or similar first to see what's going on. | 16:20 |
| ovnicraft | bzr missing show me the diverges ? | 16:20 |
| spiv | It can tell you which revisions are in branch A but not in B, and vice versa. | 16:21 |
| spiv | See 'bzr missing --help' for details. | 16:21 |
| spiv | Or just try it :) | 16:21 |
| ovnicraft | spiv yes i see 10 missing revisions now | 16:25 |
| ovnicraft | so i understand with overwrite my revision will overwrite and forget the missing revision , i am ok? | 16:26 |
| spiv | Yes, that's what overwrite will do. | 16:27 |
| spiv | Typically you'd use 'bzr merge' to combine the divergent changes from both branches into one branch (and thus resolve the divergence). | 16:27 |
| Williamson69[TFD | If anyone knows a lot about Linux and could answer my questions. Please query me. I am a very new user and want to use Linux. Please help me. If you are a Guru on Linux. I would love to talk to you. Please query | 16:36 |
| === Williamson69[TFD is now known as Wiliamson69 | ||
| === Wiliamson69 is now known as Chiumiento | ||
| === beuno is now known as beuno-lunch | ||
| bialix | bonsoir vila | 16:54 |
| vila | bialix: hellllo ! | 16:54 |
| bialix | heya! | 16:54 |
| bialix | how it's going? | 16:54 |
| spiv | bialix: hi | 16:54 |
| vila | bialix: I'm in Dallas, so it's still early here :) | 16:54 |
| bialix | hi spiv :-) | 16:55 |
| bialix | vila: I've suspected that, in some of your last mails there was -0600 timezone ;-) | 16:55 |
| vila | bialix: how are *you* going ? Seems like I didn't "see" you for quite a long | 16:55 |
| vila | s/long/& while/ | 16:55 |
| vila | bialix: happy new year by the way :) | 16:56 |
| bialix | oh, yep | 16:56 |
| bialix | happy new year to all | 16:56 |
| bialix | :-) | 16:56 |
| * fullermd picks vila up and waves him at bialix. | 16:57 | |
| * bialix is happy to see fullermd | 16:57 | |
| * bialix waves back and grin | 16:57 | |
| bialix | vila: haven't had too muich time for hacking | 16:58 |
| fullermd | I wonder if vila brought this cold snap with him... | 16:59 |
| bialix | what's about Gary? | 16:59 |
| vila | bialix: no idea, I miss him :-/ | 17:00 |
| jelmer | vila! | 17:00 |
| bialix | nobody else made a windows installers :-( | 17:01 |
| bialix | heya jelmer | 17:01 |
| bialix | HNY | 17:01 |
| vila | fullermd: not really, I'm pretty sure it predates my arrival and afaik the wheather was going *better* bach there when I left ;) | 17:01 |
| jelmer | hi bialix | 17:01 |
| fullermd | A likely story. Sounds like you've spent a lot of time planning your alibi to me... | 17:02 |
| vila | hehe, I never spent actual time on such things, it's all occurring in the background | 17:03 |
| fullermd | That's just what you'd say if you were a serial killer... | 17:05 |
| * fullermd blocks up some roads and cowers in his closet. | 17:05 | |
| vila | .... you shouldn't have mentioned that you know | 17:06 |
| * bialix hopefully will back later | 17:06 | |
| fullermd | Mentioned what? I didn't mention anyway. Nope, not a thing... | 17:10 |
| vila | ...too late... | 17:13 |
| vila | black helicopters sent | 17:13 |
| vila | ... as a decoy of course | 17:13 |
| vila | mgz: are you around ? | 17:13 |
| mgz | poink. | 17:14 |
| fullermd | Drat. There's never a SAM around when I need one. | 17:14 |
| mgz | ...you want to shoot me down? | 17:16 |
| vila | mgz: do you remember the bug # about windows env vars encoding ? | 17:19 |
| mgz | bug 262874 | 17:19 |
| ubot5 | Launchpad bug 262874 in Bazaar "environment may not be in get_user_encoding() on Windows" [Medium,Confirmed] https://launchpad.net/bugs/262874 | 17:19 |
| vila | mgz: and can you remind me what your objection was against mbcs there, I thought you commented on the bug but apparently no | 17:21 |
| mgz | It's Complicated. :) | 17:21 |
| mgz | basically, the way the 'mbcs' codec is written in python sucks. | 17:22 |
| mgz | doesn't do *quite* the same thing as BlahBlahA interfaces do over BlahBlahW functions | 17:22 |
| mgz | getting bytes out should be fine whatever, but putting bytes in is liable to blow things up | 17:23 |
| vila | jam is looking at the bzr_home_in_unicode test failure | 17:26 |
| mgz | decoding is potentially worse as you can get u'\u0000' back out unexpectedly, but the enironment should always be given to us as something we can use, unless someone else has already broken the process | 17:26 |
| jam1 | mgz: right, but regardless cp1252 is never correct for setting into the env, right? | 17:27 |
| === jam1 is now known as jam | ||
| jam | I think there are 2 bugs atm | 17:27 |
| mgz | it is if that's what GetACP gives you. | 17:27 |
| jam | 1, config_dir() isn't correctly interpretting BZR_HOME when it is unicode | 17:27 |
| jam | mgz: GetACP? | 17:27 |
| mgz | and yeah, that test used to fail in a different way, so it's likely there are two issues | 17:28 |
| jam | 2, we aren't *setting* BZR_HOME correctly for it to be interpretted by config_dir() | 17:28 |
| mgz | ctypes.windll.kernel32.GetACP() | 17:28 |
| jam | config_dir() doesn't do any escaping/etc of the env var | 17:28 |
| mgz | it's what locale.getpreferredencoding boils down to as well, which... is what the user encoding should be on windows | 17:28 |
| mgz | in the general case, we can't put an arbitrary unicode path in the environment | 17:29 |
| jam | mgz: atm I can only find a difference vs mbcs in characters that can't be encoded in cp1252 | 17:29 |
| mgz | so the test needs to pick one that works in the actual system's encoding | 17:29 |
| jam | mgz: SetEnvironmentVariableW | 17:29 |
| jam | mgz: I think config_dir() should be switching to use GetEnvironmentVariableW(), and the test changed to use SetEnvironmentVaribleW() | 17:30 |
| jam | on window | 17:30 |
| mgz | jam: right, but remember Python is using the ()A interfaces, not W | 17:30 |
| jam | windows | 17:30 |
| jam | mgz: it is for os.environm | 17:30 |
| jam | but we don't have to for our stuffg | 17:30 |
| jam | lots of windows specific stuff already for command line, might as well do it for env vars | 17:30 |
| mgz | ...explictly? that's new. | 17:30 |
| jam | mgz: we already have base = win32utils.get_appdata_location_unicode() | 17:30 |
| jam | which is find the specific unicode $APPDATA location | 17:31 |
| jam | via the SHutils stuff | 17:31 |
| jam | which uses ctypes.windll.shell32.SHGetSpecialFolderPathW | 17:31 |
| jam | if it can | 17:31 |
| mgz | the difference between cp* and mbcs is the implementation | 17:31 |
| mgz | cp* codecs use tables implemented in python | 17:32 |
| jam | mgz: so I think my point is, we shouldn't worry about it at all, we should be using the W apis on Windows wherever we can | 17:32 |
| jam | since otherwise we're just broken anyway | 17:32 |
| jam | I can set my HOME to an arabic path on Windows, even though I'm in cp1252 | 17:32 |
| mgz | mbcs calls mbtwc kernel functions without giving you means of setting the parameters | 17:33 |
| mgz | jam: if you set it to an arabic path, and then run python and do os.environ['home'] what do you get? | 17:33 |
| mgz | because I'd expect questionmarks. | 17:33 |
| jam | mgz: I agree, but my argument is that python's os.environ is broken on Windows and we shouldn't be using it | 17:34 |
| mgz | it's... just the way it's implemented. same problem we have with the subprocess module, and did have with the commandline as you said. | 17:34 |
| mgz | Python 3 is 'the' fix, which then confuses a bunch of nixy things that assume stuff is arbitrary bytes, not text | 17:35 |
| mgz | C:\>set FISH=é | 17:35 |
| mgz | C:\>echo %FISH% | 17:35 |
| mgz | é | 17:35 |
| mgz | C:\>python -c "import os;print os.environ['fish']" | 17:35 |
| mgz | e | 17:35 |
| jam | mgz: yeah, that doesn't surprise me | 17:36 |
| jam | which is why we're working around it | 17:36 |
| mgz | that's the pain with the mbcs codec, the params it passes to widechartomultibyte does cute lossy downcoding | 17:36 |
| vila | let's don't do that then :) | 17:36 |
| jam | we have the functions available, just not conveniently | 17:36 |
| jam | I think we should add osutils.get/set_environ_variable() and try to use them when we have something we want to be unicode compatible | 17:37 |
| mgz | at least with cp* codecs, the "replace" and "strict" params let you control your error handling | 17:37 |
| mgz | I agree somewhat jam, it's just a question of how much broken core python stuff we want to rewrite to make corner cases work rather than just fail sensibly. | 17:37 |
| mgz | the problem at the moment is a lot of the failures aren't safe or sensible. | 17:38 |
| jam | mgz: HOME style env vars don't really fail sensibly | 17:38 |
| jam | they tend to just prevent people from getting stuff done | 17:38 |
| mgz | not that everyone's trying to set their HOME to strings that aren't in their legacy encoding | 17:38 |
| mgz | well, treating that as 'HOME is not set' would perhaps be sensible. breaking because it can't find a dir named ????? is not. | 17:40 |
| jam | mgz: so we can change the config_dir() code to just decode os.environ and get mostly correct | 17:41 |
| jam | it just seems sad that we're on a platform that can handle any Unicode paths/variables etc | 17:41 |
| jam | and we are restricting it to mbcs because thats what python does | 17:41 |
| jam | mgz: http://paste.ubuntu.com/553270/ | 17:44 |
| jam | this makes the test pass | 17:44 |
| jam | and seems ~ correct | 17:44 |
| jam | without resorting to unicode environment getters | 17:44 |
| jam | what do you think? | 17:44 |
| jam | from what I can see, the config_dir() is actually broken on Linux, since it never decodes the string | 17:45 |
| jam | until later when it will assume the string is UTF-8 (which it almost always is, but that isn't supposed to be guaranteed) | 17:45 |
| mgz | it is sad, but seems most practical for the moment. | 17:46 |
| vila | +1 | 17:46 |
| mgz | just happening to work with utf-8 isn't suprising, I think bzrlib has a few spots like that | 17:46 |
| vila | with the comment duplicated in both places | 17:47 |
| jam | http://paste.ubuntu.com/553272/ | 17:47 |
| jam | this is the other option | 17:47 |
| jam | which does the decode always | 17:47 |
| jam | which has a bug the way I wrote it, because it double decodes | 17:47 |
| jam | but you get the idea | 17:47 |
| jam | mgz: do you know what "os.path.expanduser()" does? Is it unicode sensitive if you pass it u'~' instead of '~' ? | 17:48 |
| mgz | my general nitpick would be the location of the code, don't really want this kind of involved platform logic in multiple places in the tree | 17:49 |
| jam | I have the feeling very few people have non-ascii home dirs on Linux | 17:49 |
| mgz | ^might be, I'll check | 17:50 |
| jam | mgz: I sort of agree, but config tends to be one of the few places that we deal with environment stuff | 17:50 |
| === Ursinha is now known as Ursinha-lunch | ||
| mgz | also I'm not conviced the actual chain of checks is really right | 17:51 |
| jam | mgz: well on windows I think it will be very rare to not have APPDATA | 17:51 |
| mgz | launchpadlib caught me out the other day by expecting HOME to be set, it's generally not on windows | 17:51 |
| jam | but BZR_HOME > APP_DATA > HOME seems fine to me | 17:51 |
| jam | actually, on new windows, I would bet that GetSHSpecialFolder(APPDATA) has to return something | 17:52 |
| jam | or *lots* of programs would die | 17:52 |
| mgz | yup, that much seems fine. and checking, does seem expanduser has the same ordering (but no clever unicode logic) | 17:53 |
| dash | ahoy. i'm encountering #445690 in 2.2.2 | 17:54 |
| dash | oh. https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/445960 | 17:54 |
| dash | (tracekback on bzr unshelve) | 17:54 |
| jam | mgz: https://code.launchpad.net/~jameinel/bzr/2.3-unicode-home/+merge/46015 | 17:54 |
| dash | i guess i oughta try it in 2.3b4? | 17:54 |
| jam | dash: I thought we touched some fixes against PreviewTree.inventory in the 2.3 series | 17:55 |
| jam | I would recommend trying | 17:55 |
| jam | I think that bug is actually a dupe, but I'm not positive | 17:56 |
| === beuno-lunch is now known as beuno | ||
| mgz | bug 389674? | 17:57 |
| ubot5 | Launchpad bug 389674 in Bazaar "NotImplementedError(_PreviewTree.inventory) when unshelving must create the parent directory" [Medium,Confirmed] https://launchpad.net/bugs/389674 | 17:57 |
| jam | mgz: thanks | 17:58 |
| mgz | implies it's not fixed on trunk. | 17:58 |
| jam | yeah | 17:58 |
| jam | there is the patch for it | 17:58 |
| dash | aha. google didn't find that one | 17:58 |
| jam | let me check | 17:58 |
| jam | yeah, nobody submitted that as a merge request | 17:59 |
| jam | I'll poke it real quick | 17:59 |
| dash | ok. so i guess i'll apply that patch to turn my code loose from shelve | 18:00 |
| dash | guess i'll make sure to create a branch instead of shelving next time :) | 18:00 |
| jam | dash: shouldn't generally be a problem | 18:01 |
| dash | sure | 18:01 |
| poolie | hi bialix, dash, mgz | 18:04 |
| mgz | hey poolie. | 18:04 |
| * dash waves | 18:05 | |
| dash | aha, i see how this got triggered. | 18:06 |
| dash | i h ad a shelved change to a file that was deleted in a revision after the shelf entry was created. | 18:07 |
| mgz | deleted aside about os.path.expanduser from that review, but must remember to file launchpadlib bug at least. | 18:08 |
| mgz | the bzrlib.config logic doesn't matter much as it really shouldn't reach that check like you said jam, appdata should always work. | 18:09 |
| jam | dash: https://code.launchpad.net/~jameinel/bzr/2.3-unshelve-inventory-bug-389674/+merge/46021 | 18:28 |
| jam | mgz: I'm doing a small spike on getting the win32 test suite passing | 19:05 |
| jam | I was going to look at test_break_lock_corrupt_info next | 19:05 |
| jam | is there any work you've got that I should be aware of | 19:05 |
| jam | *right* now, I'm going to lunch | 19:05 |
| jam | mgz: email me if you have anything, since my machine will be off for food | 19:05 |
| mgz | nope, feel free to boink that one | 19:06 |
| mgz | it's just a pain due to how the test is constructed. | 19:06 |
| === Williamson69[TFD is now known as Chiumiento | ||
| jam | mgz: test_break_lock_corrupt was actually a genuine windows failure, because we were holding the file open while we tried to delete it. | 20:34 |
| jam | https://code.launchpad.net/~jameinel/bzr/2.3-break-lock-corrupt-win32/+merge/46036 | 20:34 |
| mgz | yup. | 20:34 |
| jam | it feels good to have a windows test fail because the code is actually wrong, rather than the test being wrong | 20:34 |
| mgz | but that's only because andrew wrote the test that way, it's not usefully failing | 20:35 |
| jam | mgz: no, it really is failing for a good reason | 20:35 |
| jam | check the fix | 20:35 |
| jam | force_break_corrupt was using "f = transport.get(); f.readlines()" which was holding the file open while it went and called transport.delete() | 20:35 |
| mgz | hm! | 20:35 |
| jam | as I said, nice to have a real failure | 20:36 |
| jam | that leads to a real fix | 20:36 |
| mgz | I'd misdiagnosed when I looked at it first time round then. | 20:36 |
| jam | rather than just a test case update | 20:36 |
| jam | mgz: yeah, I thought it was an ld vs ld2 race windows bug | 20:36 |
| mgz | goodjobjam. | 20:36 |
| jam | http://babune.ladeuil.net:24842/job/selftest-windows/lastCompletedBuild/testReport/bzrlib.tests.test_transform/TestTreeTransform/test_rename_fails/ | 20:37 |
| jam | is this a problem because of French windows? | 20:37 |
| jam | vila: ^^ | 20:37 |
| mgz | I've got that one. | 20:37 |
| mgz | it's bug 273978 | 20:37 |
| ubot5 | Launchpad bug 273978 in Bazaar "UnicodeDecodeError when strerror is not ascii" [Low,Confirmed] https://launchpad.net/bugs/273978 | 20:37 |
| mgz | don't have a branch on any of the other outstanding bugs though, the random failures in particular I've not dug into. | 20:38 |
| jam | np | 20:39 |
| jam | out of 6 current failures, i've fixed 2, you've got the third | 20:39 |
| jam | and 2 look transient | 20:39 |
| jam | which I'd like to look into anyway | 20:39 |
| jam | but we're getting close | 20:39 |
| mgz | that one you've just done it bug 659978 | 20:39 |
| jam | mgz: especially since test_rename_fails passes here, because I don't have French windows | 20:39 |
| ubot5 | Launchpad bug 659978 in Bazaar "bt.test_lockdir.TestLockDir.test_break_lock_corrupt_info fails on windows" [Low,Confirmed] https://launchpad.net/bugs/659978 | 20:39 |
| awilkins | Zero Windows Bugs ???!?!?!?!?!!? What will we tell stories about at parties | 20:40 |
| jam | awilkins: I'm sure there are still bugs, just not failing tests :) | 20:40 |
| jam | mgz: thanks for the bug link | 20:41 |
| mgz | numbers for the remaining are 581311 and randoms 681047 and 686587 | 20:42 |
| mgz | 581311 I briefly talked to vila about, it may be we just want to catch the winsock errno while still leaving the standard errno to propogate (as the semantics seem to be a little different) | 20:43 |
| jam | bug 581311 | 20:44 |
| ubot5 | Launchpad bug 581311 in Bazaar "bt.test_bundle.TestReadMergeableFromUrl.test_smart_server_connection_reset fails on windows" [Medium,Confirmed] https://launchpad.net/bugs/581311 | 20:44 |
| jam | mgz: of course, right now, the test passes for me | 20:46 |
| jam | but the first time I ran it, I got 10053 | 20:46 |
| mgz | hm, has been reliable for me. | 20:49 |
| jam | I think it depends on a bit of race | 20:49 |
| jam | and whether it fails during connect | 20:49 |
| jam | or during read() | 20:49 |
| awilkins | It it another test running in another thread hogging the socket? | 20:50 |
| mgz | that sounds possible. | 20:50 |
| mgz | ha, pile-on review approval. | 20:50 |
| jam | awilkins: no other threads are reading from that one | 20:50 |
| jam | but system load can change some timings | 20:50 |
| jam | mgz: I don't see any error trapping in SFTPTransport.get_bytes(), it seems to all be in SFTPTransport.get() | 20:51 |
| jam | which may be a reasonable hint | 20:51 |
| jam | if SFTPTransport.get() fails to open the file, then it will catch the exception and raise it | 20:51 |
| jam | but if f.read() fails, there is no special error handling | 20:51 |
| jam | but I guess it shouldn't get that far | 20:55 |
| jam | because you don't do *any* sftp chatter on the socket | 20:55 |
| jam | just close it immediately | 20:55 |
| jam | mgz: hm.... only HTTP raises errors.ConnectionReset that I can find | 20:58 |
| === Meths_ is now known as Meths | ||
| jam | i don't quite see how the stuff ever worked | 20:58 |
| jam | I guess the hpss stuff handles ConnectionReset... | 20:58 |
| spiv | Yeah, it does, in medium.py IIRC | 20:59 |
| mgz | I think the thought is either osutils.read_bytes_from_socket or smart.medium should maybe be catching that socket.error | 21:00 |
| mgz | which presumably is always errno.ECONNRESET on nix, but not always (or ever in this case) errno.WSAECONNRESET on windows | 21:01 |
| jam | mgz: yeah, i did finally track into the code you are talking about | 21:01 |
| dcraven | Hi. Is it possible to make bzr --remember multiple push branches? | 21:02 |
| mgz | ...then how would it know which one to use when you typed `bzr push`? | 21:03 |
| dcraven | Both :) | 21:03 |
| dcraven | I'm lazy :/ | 21:03 |
| mgz | ah. | 21:03 |
| dcraven | I do one after the other, but sometimes I forget to update one. | 21:03 |
| dcraven | No biggie. I just wondered if bzr could remember better than I can :) | 21:03 |
| jam | mgz: well, it happened once, but I can't reproduce it now | 21:04 |
| jam | but I have something that I'm fine with as a patch | 21:04 |
| bob2 | there's some old plugin...bzr multipush? | 21:04 |
| dcraven | bob2: Hmm.. I'll have a look. Thanks :) | 21:04 |
| jam | bob2: I think multipush is more about pushing more than one branch, each to a single destination | 21:05 |
| jam | I could be wrong | 21:05 |
| bob2 | yeah, you're right, I misremembered | 21:05 |
| dcraven | Yeah. Looks like that instead. | 21:05 |
| dcraven | It's not likely all that common of a wish I suppose. | 21:05 |
| jam | mgz: https://code.launchpad.net/~jameinel/bzr/2.3-connection-reset-581311/+merge/46043 | 21:12 |
| jam | I'm fine just treating WSAECONNABORTED as a reset | 21:12 |
| jam | we don't have any other way to deal with it | 21:12 |
| jam | and nobody needs to see an ugly traceback because they disconnected | 21:12 |
| jam | (I think we get ABORTED if we write too much data on the channel, etc. But really, who cares, something broke on the network) | 21:12 |
| lifeless | sure they do | 21:12 |
| lifeless | its a reward for disconnecting | 21:12 |
| lifeless | a bit like an easter egg | 21:13 |
| spiv | Except less like chocolate and more like a great big error. | 21:13 |
| jam | mgz: http://babune.ladeuil.net:24842/job/selftest-windows/lastCompletedBuild/testReport/bzrlib.tests.test_http/SmartClientAgainstNotSmartServer/test_probe_smart_server_urllib_HTTP_1_0_/ | 21:18 |
| jam | looks like the same WSAECONNABORTED failure | 21:18 |
| mgz | yup, it's similar, and the branch may fix that too. | 21:19 |
| jam | mgz: I think it needs a different fix | 21:19 |
| jam | line 601 of bzrlib/transport/http/_urllib2_wrappers.py | 21:20 |
| mgz | got bug 686587 on that. | 21:20 |
| ubot5 | Launchpad bug 686587 in Bazaar "Random failure on bt.test_http.SmartClientAgainstNotSmartServer.test_probe_smart_server" [Low,Confirmed] https://launchpad.net/bugs/686587 | 21:20 |
| jam | explicitly checks 10054 but not 10053 | 21:20 |
| jam | mgz: I'm just going to roll a 10053 into that code, and include it with the earlier fix | 21:22 |
| mgz | it mildly urks me we're getting the same error there, just from the test name | 21:23 |
| spiv | jam: there's a NEWS conflict in that patch accord to the lp diff | 21:23 |
| jam | spiv: my favorite | 21:23 |
| mgz | "probe" doesn't imply is should be trying to do messy disconnects unlike the other test. | 21:23 |
| mgz | but it's probably not a real issue. | 21:24 |
| jam | mgz: it is trying to read from .bzr/smart which shouldn't be there, I believe | 21:24 |
| jam | mgz: note that the test passes here | 21:25 |
| mgz | well, it's random on babune. | 21:25 |
| jam | the other possibility is a timing thing, where the smart server is disconnecting at a particular pace that screws with the test | 21:25 |
| === mbarnett changed the topic of #bzr to: **Launchpad down/read-only from 23:00 - 00:30 UTC for a code update** Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b4 is officially out ! (rm vila) | ||
| jam | mgz: some more get().read() stuff vs get_bytes() | 21:55 |
| jam | https://code.launchpad.net/~jameinel/bzr/2.3-per-transport-tests/+merge/46047 | 21:55 |
| jam | this in just the test suite | 21:55 |
| vila | there is a bug for this where I commented exactly that | 21:56 |
| mgz | you did vila, and I didn't think that was it as the refcount looks like it should do the right thing there, but it's worth changing it anyway and seeing | 21:58 |
| mgz | ...did that make sense? | 21:58 |
| mgz | I need to not edit my sentences half way through typing them. | 21:58 |
| jam | mgz: I believe that sftp is a bit tricky with refcounting | 21:58 |
| jam | IIRC, if a file handle dies due to refcounting | 21:58 |
| jam | it does an *asynchronous* close | 21:59 |
| jam | check paramiko | 21:59 |
| mgz | uu, that sounds nasty. certainly worth landing then. | 21:59 |
| jam | mgz: SFTPFile.__del__() => self._close(async=True) | 21:59 |
| jam | def close() => self._close(async=False) | 22:00 |
| dash | oh no __del__ :( | 22:00 |
| vila | mgz: yup, made sense | 22:07 |
| vila | mgz: I guess the end of your sentence was: '... if we still see this failure or not' | 22:08 |
| jam | vila: do you know the bug # ? I'm on a roll of closing win32 bugs, it would be nice to shoot down another | 22:08 |
| vila | hehe, searching it, unless mgz beats me to it | 22:08 |
| mgz | bug 681047 | 22:08 |
| ubot5 | Launchpad bug 681047 in Bazaar "Random failures on SFTPTransport tests on windows" [Low,Confirmed] https://launchpad.net/bugs/681047 | 22:08 |
| mgz | just reviewing now | 22:08 |
| vila | he did :) | 22:08 |
| jam | thanks mgz | 22:09 |
| vila | mgz: what trick are you using to find them this quickly ? A big whiteboard in your room ? | 22:09 |
| vila | mgz: according (and thanks) to jam, it seems you will be the one fixing the *last* windows failure. When should we expect your patch ? :D | 22:10 |
| mgz | I filed the bugs, so they're helpfully linked on my user page by launchpad :) | 22:10 |
| vila | doh ! | 22:11 |
| mgz | ^ a.... month ago? ;_; | 22:11 |
| mgz | it's slightly trickier than it looks and I'm being overly perfectionist probably. | 22:11 |
| jam | mgz: isn't it just .decode('mbcs') for IOError/OSError? Or are you trying to do something different with setlocale? | 22:13 |
| mgz | in essence, it's just the plumbing and specifics that make it fiddly. | 22:13 |
| jam | mgz: we need to get your last fix by midnight in France, so tomorrow babune will be all blue | 22:13 |
| mgz | :) | 22:13 |
| jam | mgz: of course, that gives us 45minutes | 22:14 |
| mgz | I will put up something that works well enough for the test even if the big picture needs a little more polishing. | 22:14 |
| jam | and we can't land that quickly in PQM | 22:14 |
| mgz | ...so I have minus how many minutes to finish up here? :) | 22:14 |
| vila | mgz: stop counting, act ! :D | 22:16 |
| mgz | okay, I'll (semi) cheat for the deadline, but this is a worthwhile change anyway. | 22:20 |
| vila | mgz: I have no doubt about that :) I don't doubt that you will follow up too anyway :) | 22:24 |
| === Ursinha is now known as Ursinha-afk | ||
| mgz | okay, proposing merge now. | 22:41 |
| mgz | https://code.launchpad.net/~gz/bzr/trivial_test_rename_fails_stringification/+merge/46055 | 22:46 |
| spiv | jam: http://webnumbr.com/bzr-pqm-queue-length | 22:46 |
| mgz | ..oo, launchpad going away in 11 minutes | 22:50 |
| vila | mgz: ... exactly and lp isn't showing your diff :-/ | 22:50 |
| spiv | vila: http://bazaar.launchpad.net/~gz/bzr/trivial_test_rename_fails_stringification/revision/5583 | 22:51 |
| spiv | vila: so technically lp is showing the diff :P | 22:51 |
| vila | mgz: falling back to local review mode | 22:51 |
| vila | spiv: :) | 22:51 |
| mgz | ...I've misspelt 'exception' | 22:52 |
| awilkins | Converted someone to Bazaar as an SVN client this week. Muhahahaha. Etc. | 22:52 |
| jam | mgz: why did you check to_file in one branch, and from_file in the other? | 22:52 |
| jam | to_path/from_path | 22:53 |
| mgz | it's a quirk of the test, if that diff had a bit more context it'd be clear | 22:53 |
| mgz | basically, where the limbo dance fails is slightly different depending on if we induced a permissions failure from locking the file or setting a bit on the directory | 22:54 |
| vila | omg, this test is ugly :) | 22:54 |
| jam | mgz: gotcha | 22:54 |
| jam | one case it failed to overwrite the target, other case it failed to move the target | 22:54 |
| jam | merge:approve | 22:55 |
| mgz | I've been making it gradually more ugly by making it more reliable... really want some test helper thing for doing 'what if there's a permissions problem' cleanly | 22:55 |
| vila | mgz: or turn it into multiple tests, each one focused on a dedicated aspect or even os specific maybe ? | 22:55 |
| vila | mgz: could wait for another submission | 22:56 |
| jam | submitted | 22:56 |
| vila | indeed :) | 22:56 |
| mgz | yup, I've done per-os tests for a similar thing elsewhere, but it's still a little funky trying to create enironment problems for testing | 22:56 |
| mgz | I remember you had to add something because some tests were failing when run as root... because then you're omnipotent | 22:57 |
| mgz | and unix is of the philosophy that god cannot create a rock so heavy he himself cannot lift it | 22:58 |
| vila | mgz: yup, there is a test feature named not_root or something | 22:58 |
| vila | well, we can always use more explosive ? | 22:58 |
| jam | vila: the test uses it | 22:58 |
| vila | jam: lol, you're right, I missed it :) | 22:59 |
| vila | in retrospect, it *obviously* uses it | 22:59 |
| jam | interestingly, setting a directory to readonly doesn't do anything on windows | 22:59 |
| jam | since it only tracks readonly for files | 22:59 |
| vila | I still haven't setup a babune job running as root though | 22:59 |
| mgz | right. | 22:59 |
| jam | I could see splitting it up into two tests | 23:00 |
| jam | but it doesn't seem like a big gain | 23:00 |
| mgz | am mostly interested in sharing this stuff between tests. permissions errors are not uncommon as a user stambling block, so would like more tests that check we give good feedback in various circumstances | 23:02 |
| maxb | If anyone has a spare moment, I'd appreciate second opinions on bug 455636 | 23:24 |
| lifeless | poolie: https://dev.launchpad.net/LEP/WebservicePerformance | 23:24 |
| ubot5 | 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 7274\ncontent-type: text/html;charset=utf-8\ndate: Wed, 12 Jan 2011 23:24:51 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1 | 23:24 |
| maxb | bug 455636 | 23:25 |
| ubot5 | 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 7274\ncontent-type: text/html;charset=utf-8\ndate: Wed, 12 Jan 2011 23:25:09 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1 | 23:25 |
| maxb | hrm | 23:25 |
| lifeless | thanks ubot | 23:28 |
| bob2 | teehee | 23:33 |
| maxb | bug 455636 | 23:36 |
| ubot5 | 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 5661\ncontent-type: text/html;charset=utf-8\ndate: Wed, 12 Jan 2011 23:36:56 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1 | 23:36 |
| jam | maxb: I think we already support anonymous access without using an ssh key. The one thing we could make clearer is something like "bzr launchpad-logout" which would remove the username and have him access only the anonymous side. | 23:45 |
| jam | I suppose the other aspect is that if you are anonymous, we warn you that you should log in | 23:46 |
| jam | so we should have a flag to also suppress that warning | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!