| maxb | jelmer: What is the intended minimum version of Subversion supported by subvertpy? | 12:21 |
|---|---|---|
| maxb | 0.7.4 seems to have broken vs. svn 1.4 | 12:21 |
| jelmer | maxb: 1.4 should still be supported. Can you file a bug? | 13:07 |
| ddaa | I vaguely recall that one point, plugins needed to be installed in directory that had a specific name for each module | 13:32 |
| ddaa | for example, bzrtools needed to be in a directory called bzrtools, not bzr_tools | 13:33 |
| ddaa | and bzr-svn needed to be in a directory called "svn" | 13:33 |
| ddaa | Has things become more flexible, or easy to figure out, or is documentation, guesswork or source code inspection still required to find out the correct dirname? | 13:34 |
| jelmer | ddaa: They still have to have a specific name. | 13:41 |
| jelmer | ddaa: generally though "bzr-<foo>" becomes <foo> | 13:41 |
| ddaa | yeah, I'm figuring this out | 13:41 |
| ddaa | I guess, except for very simple plugins with only the __init__.py | 13:42 |
| ddaa | or maybe those using relative imports | 13:42 |
| jelmer | ddaa: It would be nice if we supported one extra layer of directories there. So you could just put *any *directory in ~/.bazaar/plugins and have bzr look in that directory for your plugin name. | 14:30 |
| jelmer | That way we could support eggs, users didn't have to know about what name to give the directory, and several other standard python tricks would work (e.g. no need to override package_dir in setup.py) | 14:31 |
| ddaa | yep, that would make sense and there would be no backwards compatibility issue. | 14:31 |
| ddaa | it would make startup microcospically slower, but I don't imagine that being an issue | 14:32 |
| maxb | ddaa: BZR_PLUGINS_AT is a slight exception - it provides a way to run plugins that are not in a directory with the expected name. However you still need to know the name | 14:52 |
| * ddaa nods | 14:52 | |
| maxb | i.e. BZR_PLUGINS_AT=svn@/home/maxb/wc/bzr/bzr-svn/trunk for example | 14:52 |
| ddaa | that's quite advanced though. Thank you for the reminder, I need to put a link to that doc. | 14:52 |
| maxb | jelmer: acknowledged, will file a bug in the next day or so once I've had time to investigate a little more | 14:56 |
| ddaa | Is there a stable URL for the documentation of the latest bzr documentation on doc.bazaar.canonical.com? | 14:58 |
| jelmer | maxb: Thanks. Is it just building that's failing or something at run time? | 14:59 |
| maxb | 1.4: --> fails in testsuite. build succeeded because of C's charming "hey, undefined function, let's just assume it takes no parameters and returns int" behaviour | 14:59 |
| maxb | 1.5: --> fails in build, for a different reason | 15:00 |
| jelmer | oh, if 1.5 fails as well I might have a look now. | 15:01 |
| maxb | they are two distinct bugs | 15:02 |
| maxb | the 1.5 failure was a "wrong number of parameters for function" compile error for svn_wc_crawl_revisions3, IIRC | 15:03 |
| * maxb afk | 15:05 | |
| mgz | hm, I could probably fix this NFD issue pretty easily, but don't have a mac | 16:09 |
| mgz | babune will probably do once we land the leak fix and vila puts up a mac slave | 16:10 |
| mgz | expanding all voiced kana must be hell annoying. | 16:11 |
| * jelmer is tempted to start hacking on bzr-mtn | 16:24 | |
| mgz | jelmer is already too much of a superman. | 16:27 |
| mgz | while you're here, though, mind if I repurpose bug 587074 as a non-utf-8 filenames don't work bug, now you've fixed utf-8 ones? | 16:28 |
| ubot5 | Launchpad bug 587074 in Bazaar Git Plugin "Branching tree with non-ascii filenames fails (affected: 1, heat: 2)" [Medium,Fix committed] https://launchpad.net/bugs/587074 | 16:28 |
| vila | mgz: adding a mac slave requires the leak fix | 16:52 |
| mgz | I... said that! | 16:52 |
| vila | mgz: fixing the NFD issue would be great, but I fear it has to be pretty invasive as it requires, at the minimum, to store the native paths in the dirstate (imbw, but I'm 80% sure, jam could be more precise) | 16:53 |
| vila | mgz: right, sorry | 16:53 |
| mgz | well, there's a choice. either bzr normalises the internal store or it doesn't. | 16:53 |
| vila | mgz: that's because I thought about it more and I think we should land the hack_transport one waiting for a proper hook fix | 16:53 |
| mgz | that's an option. | 16:54 |
| vila | mgz: and I thought about that because I start suspecting it to address some spurious failures on babune | 16:54 |
| mgz | yeah, might do the random sftp failures on babune | 16:54 |
| vila | including some 'lost connection during test; | 16:54 |
| mgz | we've not seen any in the branches we've tested that disconnect transports properly | 16:55 |
| vila | mgz: there is another one related to cleanup_pipe, surprisingly it triggers for some sftp tests (we may be using an http server during the setup...) | 16:55 |
| vila | bug #655557 | 16:55 |
| ubot5 | Launchpad bug 655557 in Bazaar "http cleanup_pipe related test failures (affected: 1, heat: 13)" [Medium,Confirmed] https://launchpad.net/bugs/655557 | 16:56 |
| vila | the number itself is screaming: I want to be fixed by vila | 16:56 |
| mgz | you missed an ever better number by 2. | 16:57 |
| mgz | *even | 16:57 |
| vila | or by 4 :) | 16:57 |
| vila | 4 instead of 7 would have respected 6 5 4, meh so by 3 | 16:58 |
| vila | mgz: did you get better ideas for the hook fix ? | 16:59 |
| mgz | not so far, I agree that it'd be good to have som input from spiv on it, as smarts are his baby | 17:00 |
| mgz | hey GaryvdM | 17:02 |
| vila | mgz: when we implemented shared connections, the medium == connection was good enough | 17:02 |
| GaryvdM | Hi mgz/vila | 17:02 |
| vila | GaryvdM: hey :) | 17:02 |
| GaryvdM | mgz: saw your installir patch - Tommorow :) | 17:03 |
| GaryvdM | *installer | 17:03 |
| mgz | I think it should also fix your cpp runtime issue, but I don't quite remember where you hit that, so I might need to add something extra | 17:03 |
| vila | GaryvdM: while you're there, it would be good if windows installers always mentioned the '-1' in their name (and '-n' when needed) | 17:03 |
| GaryvdM | vila: Ok | 17:04 |
| vila | GaryvdM: it's documented this way in... our doc (can't remember the file name) | 17:04 |
| vila | GaryvdM: no big deal, but I think it will make things clearer *when* a '-2' is needed | 17:04 |
| GaryvdM | mgz: I figured it out - we are excluding MSVCP60.dll, and not MSVCP90.dll | 17:06 |
| GaryvdM | *but not | 17:06 |
| mgz | we don't want to exclude it now, as qt really does need it | 17:07 |
| GaryvdM | yes | 17:07 |
| mgz | (unless we ship the mingw qt, which we probably don't) | 17:08 |
| mgz | + want to | 17:08 |
| vila | mgz: why ? Wouldn't using mingw address the microsoft related problems once and for all ? | 17:09 |
| mgz | yeah, we'd get mingw related problems instead. | 17:10 |
| mgz | they've got some other pointless dll we'd need to bundle somehow, and generate bigger and slower libraries | 17:10 |
| vila | Are they known ? Wouldn't them be easier to address ? | 17:10 |
| vila | ha | 17:10 |
| vila | bigger and slower sounds... surprising though | 17:11 |
| === Ng_ is now known as Ng | ||
| mgz | blast, thought I had a repo, but it's a different bug | 18:45 |
| mgz | oh, nope, two different symptoms of the same | 18:48 |
| mgz | and the workaround still works. | 18:48 |
| mgz | bah, and it is fixed already, and has a targetted bug, but not one that includes the error message, so search didn't find it. | 19:04 |
| lifeless | heh | 19:09 |
| mgz | I'm gonna create a giant chain of dupes here I think... | 19:13 |
| lifeless | on i18n filenames? | 19:13 |
| lifeless | please be careful be to be sure they /are/ | 19:13 |
| mgz | 662254 > 303954 > 205636 > 192859 | 19:13 |
| lifeless | rather than similar symptoms with different call sites | 19:13 |
| mgz | nope, this is different symptoms and ways to break add. | 19:14 |
| lifeless | my rule of thumb is 'if I can fix one bug without fixing the other, its not a dupe' | 19:14 |
| lifeless | mgz: and I have a hunch that that will apply here | 19:14 |
| mgz | it all seems fixed, but may want some specific tests as poolie was mostly looking at the symlink angle I think. | 19:15 |
| lifeless | mgz: sounds wise to me | 19:20 |
| GaryvdM | Hi mgz | 20:00 |
| mgz | hey Gary | 20:00 |
| GaryvdM | I just tried a build of your branch | 20:00 |
| GaryvdM | Still getting a MSVCP90. | 20:01 |
| GaryvdM | dll can't be found error | 20:01 |
| GaryvdM | I'd like to try find a better fix | 20:02 |
| GaryvdM | any ideas? | 20:02 |
| GaryvdM | mgz: is there maybe a env var I can set to point to it? | 20:04 |
| mgz | right, when, is what I want to know. | 20:05 |
| mgz | I'm copying over when we were copying msvcr90 before, but that may be too late for py2exe | 20:05 |
| GaryvdM | When dose the env var get set? = Before I run the build | 20:06 |
| GaryvdM | *does | 20:06 |
| * GaryvdM need a dose of how to spell does... | 20:07 | |
| GaryvdM | mgz: ok - now I understand what you were saying | 20:10 |
| GaryvdM | mgz: so my question is, how do we tell setup.py py2exe what msvc_redist_dir is . | 20:14 |
| mgz | we don't strictly need to I think, if we can just make it stop whining | 20:16 |
| mgz | it's not smart enough to bundle it itself, if we can tell it to shut up then copy it across later | 20:16 |
| mgz | or, we could copy it before, to somewhere py2exe sees | 20:16 |
| GaryvdM | mgz: so if we tell it to ignore it, like this: http://bazaar.launchpad.net/~garyvdm/bzr/no_MSVCP90.dll_2.2/revision/5102 - would that be ok, because bzr-windows-installer will copy it anyway? | 20:18 |
| mgz | I believe so. | 20:19 |
| mgz | We don't copy it yet though, so you need that branch of bzr and my branch of bzr-windows-installers | 20:19 |
| GaryvdM | Ok - I'm going to build with our 2 branches. | 20:20 |
| mgz | what the hell, my new tests still fail with trunk merged...? | 20:23 |
| mgz | I... *checked* it worked with dev ;_; | 20:25 |
| GaryvdM | http://pastebin.ubuntu.com/515194/ - Huh - Is this stacking error? How do I fix? | 20:33 |
| GaryvdM | Yes - it's a 2a repo, and it is stacked on ~ree/gf.recipe.bzr/trunk which is Packs 6 rich-root | 20:42 |
| === Guest16378 is now known as jelmer | ||
| === jelmer is now known as Guest5922 | ||
| GaryvdM | mgz: that worked well, except I built 2.3b2, and not 2.2.1, so I start new build. | 21:21 |
| GaryvdM | and submit mp for my branches. | 21:22 |
| thumper | jelmer__: are you up? | 22:06 |
| jelmer__ | thumper: Hi | 22:06 |
| thumper | jelmer__: https://code.edge.launchpad.net/~vcs-imports/mesa/master | 22:07 |
| thumper | jelmer__: has the problem been fixed in bzr-git? | 22:07 |
| jelmer__ | thumper: No, I haven't looked at it again yet. As far as I can tell it only affects the mesa import and I can't reproduce it locally. | 22:10 |
| jelmer__ | thumper: This is bug 649531. | 22:10 |
| thumper | jelmer__: not even with an incremental? | 22:10 |
| ubot5 | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/649531) | 22:10 |
| thumper | jelmer__: I'm wondering if we have fixed it since then, and may have been a transient bug | 22:12 |
| thumper | jelmer__: perhaps blowing away the server copy and starting again _might_ fix it | 22:12 |
| jelmer__ | thumper: I haven't tried a local incremental import yet since I don't really have an easy way to do that. | 22:13 |
| thumper | jelmer__: the LP codeimportworkers can be run locally :) | 22:14 |
| jelmer__ | thumper: I don't think anything significant has changed since last time, though it's worth a shot. | 22:14 |
| jelmer__ | thumper: Is this particular import significant for some reason? | 22:16 |
| thumper | jelmer__: only because of https://answers.edge.launchpad.net/launchpad-code/+question/122971, and I'm feeling bad it isn't working | 22:16 |
| jelmer__ | thumper: Ah, ok. | 22:22 |
| jelmer__ | thumper: Also, are retries of failed imports now happening daily ? | 22:22 |
| thumper | no | 22:22 |
| * jelmer__ tries another clone of mesa with -Dverify with the hope his machine won't run out of memory | 22:25 | |
| === Ursinha is now known as Ursinha-afk | ||
| maxb | jelmer__: Hi. I'm trying to implement subvertpy tests which need to assert different things based on the version of Subversion being used. I was contemplating using subvertpy.wc.version() as an indicator of the underlying libsvn version, even in non-WC tests. Too horrid, or ok? | 22:56 |
| jelmer__ | maxb: That's alright. | 22:57 |
| jelmer__ | maxb: Please note that we have both version() and api_version() | 22:57 |
| jelmer__ | I suspect you'd want api_version() in this case. | 22:58 |
| maxb | Ah, correct, since all the compatibility decisions are made at compile time | 23:01 |
| maxb | although, hmm | 23:01 |
| maxb | well, never mind, I think I'll just use api_version everywhere for now :-) | 23:02 |
| peitschie | hiya jelmer, maxb | 23:03 |
| poolie | hi there maxb, jelmer, peitschie | 23:04 |
| peitschie | oh... hi poolie :) | 23:04 |
| === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | 2.3b2 is officially released, test it ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| poolie | (spiv is pp) | 23:06 |
| maxb | poolie: Hi. In https://code.edge.launchpad.net/~maxb/hydrazine/lp-promote-ppa-v2/+merge/38389, is the implication of (tweak) that I should consider the MP approved having fixed the lack of NEWS entry? | 23:09 |
| poolie | yes | 23:10 |
| maxb | just checking :-) | 23:10 |
| poolie | np | 23:10 |
| poolie | it's not a big deal but i meant to suggest you would have just one news entry like | 23:10 |
| poolie | * New lp-promote-ppa command to promote (copy) packages from one ppa to another. By default all packages are copied, or the source packages can be filtered by name or distroseries. | 23:11 |
| poolie | something like that | 23:11 |
| poolie | go ahead and merge; you should have access | 23:11 |
| * GaryvdM successfully ran ./setup.py build with 64bit python on windows. \o/ | 23:12 | |
| GaryvdM | going to run selftest now | 23:12 |
| maxb | I like that style of NEWS entry better --- /me tweaks and lands | 23:13 |
| mgz | you're on a roll Gary. | 23:16 |
| mgz | file bugs if you see test failures babune doesn't! (and that aren't smart-server random junk) | 23:17 |
| GaryvdM | Hmm ./setup.py build givs no errors, but I see warning: some compiled extensions could not be loaded | 23:18 |
| GaryvdM | How can I see where those warnings come from. Nothing in .bzr.log | 23:18 |
| mgz | -Werror ? | 23:19 |
| * GaryvdM tries that | 23:19 | |
| maxb | GaryvdM: ./setup.py build -i ? | 23:19 |
| maxb | Or rather, python setup.py build -i, as setup.py's should not be exectuable by convention | 23:20 |
| poolie | GaryvdM: great :) | 23:20 |
| GaryvdM | maxb: I'm using msys, so ./setup.py works :) - I'll try -i | 23:21 |
| GaryvdM | build_ext -i | 23:22 |
| maxb | hurrah, successful subvertpy test run on hardy | 23:24 |
| GaryvdM | maxb: Thanks. build_ext -i was what I needed. | 23:24 |
| === jelmer__ is now known as jelmer | ||
| peitschie | jelmer: i just quickly wanted to touch base and see if you'd had any time for the missing chknodes bug in bzr? (bug #485601) | 23:32 |
| ubot5 | Launchpad bug 485601 in Bazaar Git Plugin "mesa incremental import fails with bzrlib.errors.RevisionNotPresent (affected: 1, heat: 7)" [Medium,Triaged] https://launchpad.net/bugs/485601 | 23:32 |
| peitschie | err... thats not the bug at all.... | 23:32 |
| peitschie | hey ubot... try bug #485601 again...? | 23:33 |
| ubot5 | Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601 | 23:33 |
| * peitschie is very puzzled | 23:33 | |
| jelmer | peitschie: So, we now have a clearer idea of why that bug is cropping up (after discussion with spiv and jam) | 23:33 |
| jelmer | peitschie: The question is what to do with ghosts in bzr-svn. | 23:33 |
| peitschie | jelmer: thats what I figured would b the sticking point :). are there any ideas or workarounds at this point? or are we looking a longer wait with this? | 23:35 |
| jelmer | peitschie: there are some ways you can work around it - basically trying to avoid ghosts | 23:37 |
| jelmer | peitschie: The issue crops up when you merge from another branch that fills in ghosts. | 23:37 |
| peitschie | jelmer: we've actually been trying to do that at the moment... the major difficulty is that essentially devs can't merge directly to svn from any place other than the central network repository | 23:38 |
| peitschie | jelmer: i've gotten them feeding svn updates via the network repo, so that works ok... but committing is sticky as they need to ssh into the network repo box and do the commit locally there... i couldn't think of any other way to prevent all ghosting :( | 23:39 |
| jelmer | peitschie: What do you mean with the network repo exactly? | 23:41 |
| jelmer | is that a svn repository? | 23:43 |
| peitschie | jelmer: sorry... fixing other issues :) | 23:47 |
| maxb | jelmer: merge proposal filed for subvertpy compatibility issues mentioned earlier today. | 23:47 |
| peitschie | jelmer: so by network repo I mean the shared bzr repository | 23:48 |
| peitschie | jelmer: in order to avoid the ghosting, I needed a centralized copy of all the unique revisions. I did this by creating a shared repository devs create bound branches in their own local repositories | 23:49 |
| peitschie | jelmer: so wen a dev commits to their local feature branch, that is automatically replicated up to the network shared bzr repo | 23:49 |
| peitschie | jelmer: so that all works great at the moment... I have a cron job atm pulling svn updates in to the repo (i.e., there is a branch of svntrunk in the network repo, and the cron job runs 'bzr pull' all the time) | 23:50 |
| jelmer | peitschie: ah, cool | 23:50 |
| peitschie | jelmer: the catch is that as soon as a dev tries to merge their feature into svntrunk locally (having branched svntrunk from the shared repo, and then bound it to the real SVN repo), they are no longer able to pull in updates from the central network repo | 23:52 |
| jelmer | peitschie: right, because in that case they end up with ghosts again | 23:52 |
| peitschie | jelmer: yup :). so far, the only workaround I can think of is to get the dev to perform the final merge into svntrunk directly on the network repo via ssh | 23:53 |
| jelmer | maxb: When you said using wc.api_version() in the other tests I thought you meant using e.g. svn.ra.api_version() in test_ra.py | 23:54 |
| maxb | um, didn't I? | 23:56 |
| * maxb rechecks diff | 23:56 | |
| jelmer | maxb: You did, but you also added a call to wc.api_version() to test_repos.py | 23:57 |
| jelmer | maxb: I've followed up to the MP. | 23:57 |
| maxb | jelmer: because there is no subvertpy.repos.api_version() | 23:58 |
| jelmer | peitschie: A proper solution to ghosts and bzr-svn will probably take a while longer. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!