| maxb | jelmer: You have removed the failure note about bzr-explorer from DailyPpaStatus, but the latest build is still failing in the same way? | 00:28 |
|---|---|---|
| jdobrien_ | ping | 00:38 |
| maxb | ping who? | 00:41 |
| jelmer | maxb: it's a bzr bug that's been fixed | 01:24 |
| magcius | jam, ping | 02:58 |
| magcius | jam, http://bazaar.launchpad.net/~jstpierre/loggerhead/fix-569358/revision/434 | 02:59 |
| magcius | also, does the lp bookmark thingy support shortcuts for users? So I can replace lp:~jstpierre/loggerhead/fix-569358 with ~loggerhead/fix-569358 or something | 03:00 |
| magcius | er, lp:~loggerhead/fix-569358 | 03:00 |
| spiv | magcius: lp:~/loggerhead/fix-569358 | 03:05 |
| spiv | magcius: “~foo” of course would always mean the user foo. | 03:05 |
| magcius | OK. | 03:05 |
| spiv | I tend not to use that shortcut though because you can't share that URL with other users. | 03:06 |
| magcius | spiv, it's a bit long to type. | 03:43 |
| magcius | spiv, and I accidentally pushed to a different URL at first. | 03:43 |
| magcius | and I'm not sure I can re-set it | 03:44 |
| spiv | reset what in particular? | 03:45 |
| spiv | The default location for 'bzr push'? Use 'bzr push --remember URL' | 03:45 |
| spiv | jam: http://blog.vrplumber.com/index.php?/archives/2490-Meliae-is-neat,-but-scary....html | 04:43 |
| === arjenAU2 is now known as arjenAU | ||
| thomi | Hi, I'm trying to package a bzr plugin. I'm testing the package, and I can't see the plugin name in 'bzr plugins'. I can't import the plugin from a python console either, but if I cd to /usr/share/pyshared then I can. | 05:40 |
| jam | spiv: thanks for the heads up. Didn't realize someone was talking about me at pycon :) | 05:44 |
| poolie | thomi, i'd guess it's because you're installing it to the wrong path | 05:44 |
| jam | but yes, the observation that memory gets sucked into dicts is also what I've found | 05:44 |
| jam | hi po | 05:44 |
| jam | poolie: hi | 05:44 |
| poolie | hi there | 05:44 |
| poolie | i'm going out now; biab | 05:44 |
| thomi | I'm installing it to /usr/share/pyshared/bzrlib/plugins/sloecode - if I put it in ~/.bazaar/plugins/sloecode it works fine. | 05:45 |
| poolie | by hand, or using pycentral etc? | 05:45 |
| poolie | i think just putting the files there is not enough | 05:46 |
| poolie | hi mars | 05:46 |
| thomi | the latter, although I'm just following the packaging guide on the wiki, so I may have missed something | 05:46 |
| jam | magcius: looking pretty good. The only thing left I might ask (since you've done so well), is to use "e = self.assertRaises(...)" and then check the attributes of the exception, to make sure it is redirecting to the right url. Then we know the redirecting is working correctly, and somebody can't mess it up later. | 05:47 |
| jam | thomi: offhand, I don't think /usr/share/pyshared is in the bzrlib search path | 05:47 |
| magcius | jam, I was going to do that, I didn't know assertRaises returns the exception. | 05:47 |
| jam | I think we search the platform specific ones | 05:47 |
| jam | magcius: it doesn't in unittest, it *does* in bzr's test suite | 05:47 |
| magcius | Yeah. | 05:48 |
| poolie | thomi, i would just check what's different between your packaging and say bzr-gtk | 05:48 |
| magcius | I usually use pytest, which is a bit nicer, I guess. | 05:48 |
| thomi | jam: on my system (Ubuntu 10.10), all the bzr stuff is in there. I can see my plugin right next to all the other installed plugins :-/ | 05:48 |
| magcius | unittest is very barebones, I know twisted fixed a bunch of those random things up | 05:48 |
| thomi | poolie: yeah, I've been comparing to bzr-hg, and so far they look very similar | 05:48 |
| jam | thomi: very strange | 05:48 |
| jam | you might want to try "bzr plugins" and "bzr <command> -Derror". It is possible the plugin is failing to load, and -Derror should tell you why | 05:49 |
| lifeless | magcius: bzr's test frame is (mostly) testtools these days | 05:49 |
| lifeless | magcius: which has some very nice stuff in it, if I do say so myself | 05:49 |
| magcius | testtools? | 05:49 |
| lifeless | testtools | 05:50 |
| magcius | fork of unittest or something? | 05:50 |
| lifeless | http://pypi.python.org/pypi/testtools | 05:50 |
| spiv | magcius: https://launchpad.net/testtools, http://pypi.python.org/pypi/testtools | 05:50 |
| thomi | jam: I've tried that. 'bzr plugins -Derror' produces no additional output, and 'bzr sc-login -Derror' gives me "unknown command 'sc-login'". | 05:50 |
| spiv | magcius: a library of tasteful extensions within the unittest design, not a fork | 05:51 |
| magcius | OK. | 05:51 |
| magcius | Everybody has their own testing framework :( | 05:51 |
| magcius | latest kid on the block: http://packages.python.org/Oktest/ | 05:51 |
| spiv | That's why testtools isn't a new framework :) | 05:52 |
| magcius | jam, so, I know Loggerhead is a separate project from Launchpad. | 05:52 |
| magcius | jam, so, if I wanted http://bazaar.launchpad.net/launchpad to do a redirect to http://code.launchpad.net/launchpad | 05:53 |
| magcius | how would I do that? | 05:53 |
| magcius | without introducing some coupling or assumptions that we're running under Launchpad. | 05:53 |
| magcius | Would I have a hookable, global 404 handler? | 05:53 |
| jam | magcius: launchpad runs its own "main" script, you could certainly do something at that level | 05:56 |
| magcius | jam, linky? | 05:56 |
| jam | magcius: grabbing it | 05:56 |
| magcius | Thanks! | 05:56 |
| jam | magcius: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/files/head:/lib/launchpad_loggerhead/ | 05:57 |
| magcius | OK. | 05:57 |
| jam | and http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/view/head:/scripts/start-loggerhead.py is the actual start script | 05:57 |
| jam | magcius: I would probably say, poke around in 'app.py' looking for where requests come in. Because you have to do it higher than the BranchWSGIApp, because you don't have a branch | 05:58 |
| magcius | Right. | 05:58 |
| magcius | Is most of the code in lib.launchpad_loggerhead.app just there for the oops stuff? | 05:59 |
| jam | magcius: and stuff like /favicon etc | 05:59 |
| magcius | OK. | 05:59 |
| jam | if you look at "RootApp.__call__" it has a fair amount of tests. It also glues the Launchpad virtual file system into the web interface | 06:00 |
| magcius | jam, https://code.launchpad.net/~jstpierre/loggerhead/fix-569358/rev/435 | 06:21 |
| magcius | er | 06:21 |
| magcius | jam, http://bazaar.launchpad.net/~jstpierre/loggerhead/fix-569358/revision/435 | 06:21 |
| spiv | jam: I'd appreciate your thoughts on https://bugs.launchpad.net/bzr/+bug/709349 | 07:14 |
| ubot5 | Ubuntu bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [High,In progress] | 07:14 |
| spiv | jam: I've just added a comment about where I'm up to: basically something that ought to be impossible appears to be occurring. | 07:16 |
| poolie | spiv, i read that | 07:38 |
| poolie | my only idea would be that it is indeed filesystem weirdness, but that would be strange on a local linux fs | 07:39 |
| spiv | poolie: thanks for that. At least I'm not missing anything obvious then :) | 07:44 |
| poolie | :} | 07:45 |
| vila | hi all ! | 08:02 |
| jam | morning vila | 08:04 |
| vila | hay jam, you're up quite early :) | 08:04 |
| vila | jam: (according to the logs that is) | 08:04 |
| jam | vila: I get up around 6:30. Just takes a while to get everyone off to school, etc. | 08:04 |
| poolie | hi jam, vila | 08:29 |
| jam | hi poolie | 08:29 |
| vila | hey poolie | 08:29 |
| mr-russ | hi vila, I manage to propose a merge, thanks for the help. | 08:31 |
| vila | mr-russ: you're welcome ! (on all counts ;) | 08:31 |
| vila | package-importer is toasted | 08:45 |
| vila | debug_log mentions OperationalError: table failures has 4 columns but 3 values were supplied | 08:45 |
| vila | does that ring any bell in someone's head ? | 08:46 |
| spiv | vila: not for me | 08:50 |
| vila | I'm investigating but the error message basically implies that the failures table got an additional row... | 08:51 |
| maxb | where by row, you mean column? :-) | 08:55 |
| vila | maxb: obviously :D | 08:56 |
| vila | but this doesn't make a lot of sense... the column is 'emailed' and has been there for more than a year... | 08:58 |
| vila | ...except if this exception was *never* caught before.... | 08:58 |
| jam | vila: one possibility is if the column changed to being NOT NULL or something along those linse | 09:05 |
| jam | lines | 09:05 |
| vila | jam: I've icommon..._set_failure to properly initialize 'emailed' to 0 | 09:06 |
| jam | vila: weird, 'emailed DEFAULT 0' | 09:06 |
| vila | I've also killed the running mass_import and the nexuiz-data one | 09:06 |
| vila | jam: indeed | 09:06 |
| jam | but also "SELECT count(*) FROM failures" == 0 | 09:06 |
| jam | vila: so no failures have ever been logged | 09:06 |
| jam | or that table is cleared out by something | 09:06 |
| vila | jam: or some new sqlite3? version introduced a change ? | 09:10 |
| vila | in behaviour | 09:10 |
| vila | bah, very unlikely | 09:11 |
| jam | vila: I think the "we've never put anything into that failure table" is pretty significant | 09:11 |
| jam | the table is empty right now | 09:11 |
| vila | jam: it is not on my local importer | 09:11 |
| vila | and _start_package insert a a new row | 09:12 |
| vila | in the failures table | 09:12 |
| jam | vila: I'm just telling you what I see on jubany | 09:12 |
| jam | meta.db has no rows in the "failures" table. | 09:12 |
| vila | jam: I get that, I just continue the discussion :) | 09:12 |
| vila | the truth is there somewhere, waiting for us to discover it by throwing contradictions to each other ;) | 09:13 |
| jam | vila: so I agree with your original assertion "we've never hit that on Jubany" or, we've hit it, but just failed imports because of it, etc. | 09:13 |
| vila | so I've landed a patch that create the failure row as it is created in _start_package and I'm waiting for some {lo|g}sa to restart the importer... | 09:14 |
| vila | I've been told we're losa-less until US starts... | 09:15 |
| jam | vila: I started. wait... | 09:18 |
| vila | jam: no ! | 09:19 |
| vila | jam: you can't properly start the mass_import.py script | 09:19 |
| jam | vila: I'm saying I started work, but I'm not in the US zone anymore. | 09:20 |
| vila | gee, you scared me ;) | 09:20 |
| vila | I almost made a joke about you not being in US anymore... :D | 09:20 |
| poolie | the kanban is about to get a bit more accurate | 09:20 |
| poolie | as i roll out trunk | 09:21 |
| poolie | ah, some of it's going to need to wait on a review | 09:21 |
| poolie | but, still, a bit better | 09:21 |
| poolie | i should finish | 09:38 |
| poolie | vila, i just noticed http://people.canonical.com/~mbp/kanban/vila-kanban.html is curiously empty | 09:38 |
| poolie | i'm sure you're doing stuff but maybe you should update the bugs? | 09:38 |
| vila | poolie: I just made it even more empty :) | 09:39 |
| poolie | :) | 09:39 |
| vila | poolie: and I just pushed a fix for the importer without an associated bug which doesn't help either ;) | 09:41 |
| poolie | well, the point is to fix things, not move the cards around | 09:41 |
| poolie | but a certain amount of keeping track of things is useful | 09:41 |
| vila | poolie: sure | 09:42 |
| vila | wow: http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/junit/bzrlib.tests.test_export/TarExporterTests/test_tgz/ | 09:43 |
| vila | jelmer: ^ could that be related to your recent changes ? | 09:43 |
| jam | vila, jelmer: Looks like a O_BINARY issue to me | 09:45 |
| jam | probably "bzr export" isn't set to use EXACT encoding | 09:45 |
| jam | so it outputs in Text form, and that garbles the compressed data | 09:45 |
| vila | do we have a bug about switching to sphinx (including pqm) ? I couldn't find one | 09:46 |
| vila | or switching to tarmac, whatever | 09:46 |
| jam | jelmer: Just found out an interesting road-tax issue. Diesel costs significantly less at the pump, and traditionally gets significantly higher km/L, but the road tax is almost 2x per year. | 09:46 |
| jam | vila: I don't know of a bug. poolie's statement in the past was "If we are going to set something new up, probably should be tarmac, but it isn't worth the effort yet to switch off of PQM". | 09:47 |
| jam | my personal feeling is that without Queued status in Launchpad | 09:47 |
| jam | Tarmac is a poor fit for us | 09:47 |
| jelmer | jam: Yeah, that's one of the reasons people buy particular cars which are taxed less. | 09:57 |
| jelmer | jam: Same goes for LPG | 09:57 |
| jam | jelmer: is it meant to be a tax on industrial vehicles? | 09:58 |
| jam | or because diesel traditionally has higher polutants? | 09:58 |
| jam | (I know in the US, they didn't get low-sulpher diesel until something like post 2007) | 09:58 |
| jelmer | jam: I think the pollution is the reason, but I'm not entirely sure | 09:59 |
| jam | just curious | 10:00 |
| jam | do you even have a car? | 10:00 |
| jelmer | jam: Nope, I don't have one.. and my parents didn't have one when I grew up. | 10:00 |
| jelmer | my mom has a car these days, and I have a drivers license.. but I mostly use it when I'm in the US or during holidays (when we use somebody else's car) | 10:01 |
| jelmer | jam: You're looking at getting a car in .nl? | 10:01 |
| jam | jelmer: interesting. I know quite a few people in big cities that live that way. | 10:01 |
| jam | jelmer: yeah | 10:01 |
| jam | the big thing is having a child, and trying to figure out how to get him around | 10:01 |
| jam | it is possible by bike, but likely we still want a car | 10:01 |
| poolie | jam, i'd be happy to switch to tarmac | 10:02 |
| jam | the place we've picked is also more on the outskirts (in Waalre, if that means anything to you) | 10:02 |
| poolie | it looks like the losas want us to set it up ourselves | 10:02 |
| jam | poolie: I've seen quite a few limitations when people get into the details, though. | 10:03 |
| poolie | limitations of tarmac? | 10:03 |
| jelmer | jam: Ah, nice. I've camped there once :) | 10:03 |
| jam | and how do we set it up ourselves without a datacenter access? Run it on our own machines? | 10:03 |
| poolie | anyhow, i have a medium-low thing on my todo list of prototyping it | 10:03 |
| poolie | at least for the prototype | 10:03 |
| jam | poolie: stuff like not being able to land on anything that isn't the dev focus, etc. | 10:03 |
| jam | I think some have been overcome | 10:03 |
| jam | but since rockstar isn't focused on it anymore | 10:03 |
| jam | maintained bot >>> unmaintained bot | 10:04 |
| jelmer | jam: Are you implying pqm is maintained?? | 10:04 |
| poolie | :) | 10:04 |
| jam | I think that was, honestly, the only problem with PQM | 10:04 |
| jam | jelmer: not at all. but I'd rather keep a tool that we're using now and have worked around | 10:04 |
| poolie | it's not top of my list | 10:04 |
| jam | than switch it for *another* unmaintained tool | 10:04 |
| poolie | if someone else gets a bee in their bonnet and does not have too much other stuff queued or in progress, they can do it | 10:04 |
| jam | especially since it was designed around incomplete features in Launchpad | 10:05 |
| jam | I *really* want a tweak rating, and "review: needsfixing, merge:approve" is the best we have, but Tarmac will land that patch. | 10:05 |
| jam | since we don't have Queued | 10:05 |
| poolie | i would like 'tweak' too | 10:06 |
| poolie | ok, really good night now | 10:06 |
| jam | poolie: sleep well | 10:06 |
| jam | jelmer: need me to fix the windows export breakage? | 10:06 |
| jelmer | g'night poolie, see you tomorrow | 10:08 |
| jelmer | jam: If you have an idea of what's going wrong. I'm looking at it and it seems like a perfectly reasonable test to me. | 10:08 |
| jam | jelmer: did you see my earlier comment about possibly being an "encoding=exact" type thing? | 10:08 |
| jam | vila: bonus points, the test passes when "bzr selftest -s bt.test_export" | 10:08 |
| jam | but *fails* with --verbose | 10:08 |
| jam | jelmer: ^^ | 10:08 |
| jelmer | jam: ahh | 10:09 |
| jelmer | jam: You're probably right, as tgz (and tar) is the only one we actually use open() for | 10:10 |
| jelmer | jam: tar isn't tested though | 10:10 |
| jam | jelmer: and doing "bzr export --verbose --format=tgz - " does generate an invalid stream | 10:11 |
| jam | jelmer: http://paste.ubuntu.com/580504/ | 10:11 |
| jam | makes it pass for me | 10:11 |
| jam | with --verbose | 10:11 |
| jelmer | jam: +1 | 10:12 |
| jelmer | poolie: thanks for removing the needs testing column in kanban :) | 10:13 |
| jam | vila, jelmer: have you had any problems pushing changes to LP? | 10:19 |
| jelmer | jam: no, but I haven't tried yet this morning | 10:19 |
| jam | I just tried to push an update to my "jam-integration" branch, and it is telling me Readonly. | 10:19 |
| jam | *sigh* just figured it out | 10:19 |
| jam | jam-integration was a mirror | 10:19 |
| jam | bad error messages ftl | 10:19 |
| jam | (of course, the source is now offline since I took down my server) | 10:20 |
| jam | jelmer: anything we can do to get your Kanban "needs release" changes into Released? | 10:21 |
| jelmer | jam: not really, some of them are just waiting for upstream releases | 10:22 |
| jelmer | I'm working on fixing some last bugs before a bzr-svn release now | 10:22 |
| jelmer | but I have no control over wikkid, storm, pygpgme, etc | 10:22 |
| evanton | I am trying to retrieve http://wiki.bazaar.canonical.com/QBzr using a http library and I'm getting access denied, but it works in a regular browser, why is the site dumping me like that? | 10:23 |
| evanton | I've tried to change the default user-agent, no luck | 10:23 |
| jelmer | evanton: it seems to work fine here in e.g. curl | 10:24 |
| jelmer | evanton: are you getting a 401 of some sort, or a HTML access denied page? | 10:24 |
| evanton | jelmer: if you'll be around I can try finding that coed snippet so I could provide an exact answer to this question | 10:24 |
| evanton | *code | 10:24 |
| jam | evanton: several of us should be around for a while | 10:25 |
| jam | evanton: it works here using 'wget' | 10:25 |
| vila | jam: no problem pushing so far | 10:25 |
| jam | *My* guess is that you have an HTTP proxy that you aren't respecting in your http library | 10:25 |
| jam | vila: I figured it out. Was a mirror branch I was pushing to | 10:26 |
| jam | and LP giving no reminder ofthat | 10:26 |
| vila | right, just read it :-/ | 10:26 |
| evanton | ok, I found it | 10:27 |
| evanton | I'm getting a 403 | 10:27 |
| evanton | "You are not allowed to access this!\r\n" | 10:27 |
| evanton | it is the urllib3 python HTTP library, if this matters | 10:27 |
| jam | evanton: if you can dump your HTTP headers, you might find something interesting. | 10:29 |
| jam | I really do expect it is a Proxy issue | 10:29 |
| evanton | jam: the request headers or the reply headers? | 10:29 |
| evanton | jam: and I'm not behind a proxy | 10:29 |
| jam | evanton: probably both, especially if you can catch the ones your web browser sends | 10:29 |
| evanton | jam: sure, I have live http headers in firefox | 10:30 |
| evanton | jam: http://dpaste.org/mdBc/ | 10:37 |
| evanton | the first is the sniffed http session of urllib3, below is the dump from live http headers (firefox browser) | 10:37 |
| jam | evanton: you're not passing an "Accept" (if I read it correctly) | 10:39 |
| jam | I don't know if that matters | 10:39 |
| jam | evanton: here itis. you are passing the full URL | 10:39 |
| jam | "GET http://wiki.bazaar.canonical.com/QBzr" | 10:39 |
| jam | not | 10:39 |
| jam | "GET /QBzr" | 10:40 |
| jam | (that is my guess) | 10:40 |
| evanton | hmm | 10:40 |
| jam | I've certainly seen servers that reject passing the full URL in the GET | 10:40 |
| evanton | jam: so it likely looks like a problem with this particular http library? | 10:40 |
| jam | evanton: something like that | 10:41 |
| jam | it is passing "Host:" so it shouldn't be also passing the full URL | 10:41 |
| jam | at least, AIUI | 10:41 |
| evanton | I am confused because I'm using this library for other sites too and this is the first site that dumps me | 10:41 |
| evanton | not using the default urllib2 because this one can reuse http connections (handy when having to retrieve a couple of urls from the same site) | 10:42 |
| evanton | interesting, retrieving /QBzr works | 10:44 |
| luks | passing the whole URL normally means that you want to use the HTTP server as a proxy | 10:44 |
| evanton | jam: you are probably right, I'll mail the author of urllib3 | 10:44 |
| jam | evanton: I can confirm, sending raw socket.socket() messages | 10:44 |
| evanton | thanks for your help | 10:44 |
| jam | sending /QBzr works | 10:44 |
| jam | sending full url gives Forbidden | 10:44 |
| hunger_ | Is there a way to force "bzr clone" to provide progress information when running in an non-interactive environment? | 10:45 |
| === hunger_ is now known as hunger | ||
| jam | hunger_: BZR_PROGRESS_BAR , IIRC | 10:45 |
| jam | hunger: export BZR_PROGRESS_BAR=text | 10:45 |
| jam | should do it | 10:45 |
| hunger | jam: Great! Thanks! | 10:46 |
| hunger | jam: The bzr checkout wizard in Qt Creator is not providing any indication that it is doing something... we need to fix that:-) | 10:46 |
| jam | hunger: I'm guessing you want to ensure the process barrier rather than using bzrlib? | 10:49 |
| jam | One thing you could consider, is setting your own UIFactory | 10:49 |
| hunger | jam: The code was contributed. I have to admit that I never really looked into bzr myself:-) | 10:50 |
| hunger | jam: It does work pretty well though, doing the normal checkout etc. I di dto test the plugin. | 10:51 |
| cerf | hello there ! | 11:19 |
| cerf | I have created a QtCreator plugin for Bazaar | 11:20 |
| cerf | at some point I need to get the ouput of the 'bzr clone' command | 11:20 |
| cerf | I have tried to play with the BZR_PROGRESS_BAR env-var | 11:21 |
| cerf | but with no success | 11:21 |
| cerf | only the modes 'none' and 'tty' work | 11:22 |
| cerf | 'dots' or 'text' don't | 11:22 |
| cerf | any idea ? | 11:23 |
| jam | cerf: version of bzr? | 11:30 |
| jam | dots is pretty old, IIRC | 11:30 |
| cerf | v2.2.1 | 11:30 |
| cerf | it still appears in 'bzr help env-variables' | 11:33 |
| jam | cerf: we've supported it for a long time. though I think poolie changed the values in a release, I'm trying to track down which one | 11:33 |
| jam | bug #339385 | 11:34 |
| ubot5 | Launchpad bug 339385 in Bazaar "bzr: BZR_PROGRESS_BAR is ignored" [High,Fix released] https://launchpad.net/bugs/339385 | 11:34 |
| jam | so the last time I see it explicitly touched is pre 2.0 | 11:34 |
| jam | but checking | 11:34 |
| cerf | that's right I have seen this bug report | 11:35 |
| jam | cerf: since bzr-2.0 it has been either "text" or "none" | 11:35 |
| jam | not "tty" or "dots" | 11:35 |
| jam | cerf: http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0/view/head:/bzrlib/ui/text.py#L144 | 11:36 |
| cerf | indeed | 11:37 |
| jam | cerf: There may be another bug involved. But "dots" has been gone for a long time, I don't see how "tty" would do anything. "text" looks like it | 11:38 |
| jam | should work in all 2.X releases | 11:38 |
| cerf | what would you suggest to work around my problem ? | 11:38 |
| jam | cerf: if you could file a bug about "bzr help env-variables" having bad documentation, and then use "BZR_PROGRESS_BAR=text" | 11:38 |
| jam | I think it is just a doc bug | 11:38 |
| cerf | I cant get tty or text progress output | 11:38 |
| jam | Are you sure it was "tty" that worked for you, and not "text" ? | 11:38 |
| cerf | 'tty' works the same as 'text' for me | 11:40 |
| jam | cerf: I can confirm here that "export BZR_PROGRES_BAR=text" works for me | 11:40 |
| jam | if I do "bzr log http://.... >out.txt 2>err.txt" | 11:40 |
| jam | with the setting, it puts progress into 2 | 11:40 |
| jam | without, it doesn't | 11:40 |
| jam | are you expecting progress on stdout ? | 11:40 |
| cerf | yes that's it | 11:42 |
| cerf | is it possible ? | 11:42 |
| jam | cerf: progress is always on stderr, so it doesn't intermingle with real data on stdout | 11:43 |
| jam | you can certainly capture stderr of a subprocess, though | 11:43 |
| cerf | thanks jam, I'm gonna try to read stderr | 11:44 |
| jam | cerf: bug #735417 | 11:46 |
| ubot5 | Launchpad bug 735417 in Bazaar "doc for BZR_PROGRESS_BAR incorrect" [High,Confirmed] https://launchpad.net/bugs/735417 | 11:46 |
| jam | hopefully gets backported to at least 2.2 | 11:47 |
| jelmer | jam: are you submitting a fix for the tgz export test or should I ? | 12:46 |
| jam | jelmer: already finished through pqm | 12:46 |
| jelmer | heh, nevermind then :) | 12:47 |
| jelmer | jam: Thanks | 12:47 |
| jam | Just used 'pqm-submit' rather than going through the launchpad work | 12:47 |
| jam | I usually do that for "trivial" fixes | 12:47 |
| vila | jam: the empty failures table is probably due to bug #608563 as I *did* issue a retry --all to address slangasek query | 13:12 |
| ubot5 | Launchpad bug 608563 in Ubuntu Distributed Development "requeue_package.py --all-of-type retries all packages" [High,Triaged] https://launchpad.net/bugs/608563 | 13:12 |
| jam | ah | 13:12 |
| vila | eeerk, there are uncommitted changes on jubany ?? | 14:51 |
| vila | in delete_branches_from_lp.py fwiw | 14:51 |
| james_w | I think spiv was hacking on that | 14:55 |
| vila | ha (I was about to ask you the same question in #lp-ops ;) | 15:05 |
| vila | err is, but anyway | 15:05 |
| vila | hmm, I'll try to ping tomorrow and if they come in the way will just shelve them and mail him | 15:06 |
| jam | vila: I don't know what is going on here: http://babune.ladeuil.net:24842/job/selftest-windows/374/testReport/junit/bzrlib.tests.blackbox.test_export/TestExport/test_tar_export/ | 15:19 |
| jam | It works here | 15:19 |
| jam | and it did fail before my update | 15:19 |
| jam | this hints that it has the updated patch: http://babune.ladeuil.net:24842/job/selftest-windows/374/ | 15:19 |
| vila | jam: yup, more than hint | 15:20 |
| jam | vila: doesn't mean hudson actually succeeded in applying the update. But yeah, I would be surprised if it didn't | 15:21 |
| === deryck is now known as deryck[lunch] | ||
| vila | well, I've seen weird things on jenkins/hudson, but not using the right code ? Never so far | 15:21 |
| vila | jam: could it be that the encoding is overridden when running without a real tty or something ? | 15:22 |
| vila | 79.100 encoding stdout as sys.stdout encoding 'cp1252' in http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/junit/bzrlib.tests.blackbox.test_export/TestExport/test_tar_export/ may not be relevant... | 15:23 |
| jam | vila: redirecting to a file still works for me here | 15:23 |
| vila | jam: you're notoriously good at avoiding windows babune slave bugs ;D | 15:24 |
| jam | vila: I'm running the wrong file, just a sec | 15:25 |
| jam | k weird, I know I got at least one failure in the past | 15:26 |
| jam | which 'exact' seemed to help | 15:26 |
| jam | but now, it won't fail either way | 15:26 |
| jam | I suspect a failure to flush() | 15:26 |
| jam | which would make it ~ load dependent | 15:26 |
| jam | and certainly babune runs differently there | 15:26 |
| vila | jam: also, is redirecting to a file the same thing as running ~without a console as on babune ? | 15:27 |
| jam | vila: you are redirecting to a file already. | 15:27 |
| jam | not sure about 'without a console' | 15:27 |
| jam | but you are capturing the output == redirected to a file | 15:27 |
| jam | I can no longer reproduce failure with or without -v with or without my patch :( | 15:28 |
| vila | pipe probably... or are you talking about the test framework ? | 15:28 |
| vila | jam: ouch | 15:28 |
| jam | I know I did see a failure before | 15:29 |
| jam | not sure how I triggered it | 15:29 |
| jam | but that was how I thought I 'fixed' it. Since it did fail, and then it stopped failing | 15:29 |
| jam | ah, got a failure | 15:29 |
| jam | load dependent | 15:29 |
| jam | vila: "for i in `seq 20`; do bzr selftest -s bp.test_export test_tar_exporter; done | 15:29 |
| vila | 'load' as in CPU load or import load order ? | 15:29 |
| jam | and I got maybe 3-4 failures out of 20 | 15:29 |
| vila | ooooooouch | 15:30 |
| jam | (without my patch) | 15:30 |
| vila | jam: eerk, erratic on babune too: look for 41 vs 42 :http://babune.ladeuil.net:24842/job/selftest-subset-windows/ | 15:33 |
| jam | vila: well, I see now. "test_tar_export" exports to a file on disk, not to '-' | 15:34 |
| jam | so it obviously wouldn't have been affected by my patch | 15:34 |
| vila | urgh, I dunno what I prefer :-/ | 15:35 |
| jam | vila: I think it is just a flushing issue. TarFile.close() does *not* close its underlying stream. | 15:36 |
| jam | I don't know why GzipFile would get caught up without flushing itself | 15:36 |
| jam | I'm trying a different patch | 15:36 |
| jam | note also, that the streams are not explicitly closed | 15:36 |
| jam | no try/finally | 15:36 |
| jam | ug | 15:37 |
| jam | stream = open(dest.encode(osutils._fs_enc), 'w') | 15:37 |
| jam | doesn't look good | 15:37 |
| jam | I don't know how it ever worked | 15:37 |
| jam | maybe got lucky and no '\r' or '\n' in the compressed stream | 15:37 |
| vila | aaaaah | 15:37 |
| jam | note that for gzip.GzipFile: | 15:38 |
| jam | "If not given, the ‘b’ flag will be added to the mode to ensure the file is opened in binary mode for cross-platform portability." | 15:38 |
| jam | however, we are opening directly with "open()" | 15:38 |
| vila | >_< | 15:38 |
| === Ursinha is now known as Ursinha-lunch | ||
| jam | jelmer: so there is another bug, and its time for me to go. Basically you also changed it to use "open(..., 'w')" where GzipFile used to translate that to 'wb' automatically, | 15:53 |
| jam | I'll try to get to it tonight. | 15:53 |
| jam | I'd like to change a few other things anyway. | 15:53 |
| jam | *sigh*, even adding more data to it doesn't guarantee it will fail. time to try harder | 15:59 |
| jam | jelmer/vila: if you want to poke at it, a good start for forcing a failure is at lp:~jameinel/bzr/integration | 16:01 |
| jam | It uses osutils.rand_chars() to put in a bunch of data, that ends up likely to create '\n' in the output stream | 16:02 |
| vila | jam: use rand_chars() *until* you end up with a '\n' in the gzip output and stick with it ? | 16:03 |
| mgz | >>> [c for c in "".join(chr(i) for i in range(256)) if "\n" in c.encode("zlib")] | 16:09 |
| mgz | ['\t', '\x95', '\xa5', '\xb5', '\xc5', '\xd5', '\xe5', '\xf5'] | 16:09 |
| === beuno is now known as beuno-lunch | ||
| vila | mgz: :D | 16:10 |
| mgz | ...hm, need to limit it to the non-adler32 bit of the value though, tab is no good. | 16:13 |
| mgz | all the rest would do though. | 16:14 |
| mgz | or a PNG, which has a cunningly crafted header to detect errors like this. | 16:15 |
| * mgz pulls jam's branch to start on a fix. | 16:17 | |
| mgz | meh, I hate '-' as a magic name meaning stdout | 16:21 |
| mgz | seems like the test is fixable, but this will still be bogus code | 16:21 |
| mgz | anyone who pipes a compressed tar from bzr on windows risks corrupting it, we don't set our output stream to binary mode | 16:22 |
| mgz | and even if we did, we don't control the other end of the pipe. | 16:22 |
| mgz | ah, 'exact' does handle our end. | 16:25 |
| === deryck[lunch] is now known as deryck | ||
| mgz | hm, I wonder if there's any tar metadata that will vary across platforms or python versions and screw this plan up. | 16:42 |
| mgz | testing this kind of bug with zip would be much easier... :) | 16:42 |
| jelmer | mgz: what are you trying to fix? | 16:43 |
| mgz | vila's babune error. | 16:44 |
| jelmer | mgz: shouldn't that just be a matter of opening the file in binary mode? | 16:44 |
| mgz | jam's got a branch that does that, but it seems like something's still borked, and it needs testing. | 16:44 |
| mgz | it's probably just the test framework that's wrong post-jam-fix | 16:45 |
| vila | mgz: if you're able to reproduce it reliably *and* fix it, I think we shouldn't try too hard to keep reproducing it | 16:45 |
| mgz | well, I have a magic string that works here, I'm just #1 worried it may not consistently, as the tarfile module has been fiddled with a lot since 2.4 and #2 the test still fails | 16:46 |
| jelmer | mgz: I thought jam's fix was for a different issue | 16:46 |
| vila | I fail to see how you could not guarantee that the compressed data will always be the same across all supported envs so trying to do it is likely to be brittle | 16:47 |
| jelmer | at least, I think the change to use 'exact' isn't really relevant here | 16:47 |
| mgz | it sets encoding='exact' on the command, which appears to be about this issue. | 16:47 |
| vila | mgz: he later said it wasn't relevant (AIUI) | 16:47 |
| mgz | ah, okay, missed that, I'll change the other line he mentioned then. | 16:48 |
| vila | mgz: he got tricked by the test failing erratically | 16:48 |
| vila | mgz: and (still AIUI) ended up suspecting the compressed data to contain '\n', found that gzip guarantee using 'wb', etc | 16:48 |
| jelmer | vila: do you know if he submitted another fix? | 16:48 |
| vila | jelmer: not that I know of, he ended up saying: | 16:49 |
| vila | <jam> jelmer/vila: if you want to poke at it, a good start for forcing a failure is at lp:~jameinel/bzr/integration | 16:49 |
| vila | <jam> It uses osutils.rand_chars() to put in a bunch of data, that ends up likely to create '\n' in the output stream | 16:49 |
| vila | < | 16:49 |
| jelmer | vila: it seems like the open on bzrlib/export/tar_exporter.py:111 should be changed to have 'wb' instead of 'w' | 16:49 |
| jelmer | vila: ah, he noticed that as well | 16:50 |
| vila | jelmer: without looking at the code, he said 'w' should never had worked so the test was passing by luck | 16:50 |
| vila | or maybe it's a new test you added recently ? | 16:50 |
| jelmer | I added the test recently | 16:50 |
| jelmer | actually, I think that one may have been there before | 16:50 |
| vila | that would explain it then, even on babune the failure was erratic | 16:51 |
| jelmer | but the code didn't use open() earlier | 16:51 |
| vila | here we are | 16:51 |
| jelmer | jam said he was going to look at it tonight though | 16:51 |
| mgz | I've got it. | 16:51 |
| vila | yeah, I can't look at it right now either | 16:51 |
| mgz | the sys.stdout bit is the dodgiest aspect. | 16:51 |
| vila | binary(sys.stdout) | 16:52 |
| vila | :) | 16:52 |
| mgz | that's still only our end. | 16:52 |
| mgz | also, it's scattered all over the file. | 16:53 |
| vila | if it's going to contain a gzip content, the other end has better be prepared to handle it as binary | 16:53 |
| mgz | I'm not sure if 'exact' on the command should have stdout covered already or not. | 16:53 |
| jelmer | mgz: isn't the test failure while writing to test.tar.gz ? | 16:53 |
| mgz | it is, but we also want to not corrupt things written to stdout if possible. | 16:54 |
| mgz | (as far as possible) | 16:54 |
| jelmer | fair 'nough | 16:55 |
| === beuno-lunch is now known as beuno | ||
| === Ursinha-lunch is now known as Ursinha-afk | ||
| === JayFo is now known as JFo | ||
| jam | jelmer, vila: didn't read the whole argument, but there are 2 bugs | 16:59 |
| jam | one is open('w') | 16:59 |
| jam | one is encoding = 'exact' | 16:59 |
| jam | I fixed one, but the test was flakey | 16:59 |
| mgz | okay, that works. | 17:01 |
| mgz | so, jam, 'exact' does handle setting stdout to binary before we arrive at lines like `stream = sys.stdout` in tar_exporter? | 17:01 |
| jam | mgz: yes | 17:01 |
| jam | I have a fix for the other, but I wanted to make the test reliably fail | 17:02 |
| jam | note that zlib does huffman encoding, etc. | 17:02 |
| jam | so any one character isn't guaranteed to trigger it | 17:02 |
| mgz | hm, what goes through plain_tar_exporter? because there's another non-binary open there. | 17:02 |
| jelmer | mgz: not open() open() though, tarfile.open() | 17:02 |
| mgz | ^well, it is in practice on idential input, zlib is pretty stable | 17:02 |
| jam | lots of them in the cod. the compressors like gzip.GzipFile take 'w' but internally turn it into 'wb' | 17:03 |
| jam | might just want to force them all | 17:03 |
| mgz | looks like open-open to me jelmer | 17:03 |
| mgz | ^the main issue is tar is a big binary blob that I'm worried may not be very consistent | 17:04 |
| jam | mgz: just for the heck of it, I also wanted to switch to osutils.open_file() | 17:04 |
| mgz | even if we're not writing mtime and other obviously variable things | 17:04 |
| jam | since then it won't interact with ssh children, etc | 17:04 |
| mgz | sounds reasonable jam. | 17:04 |
| mgz | http://paste.ubuntu.com/580664/ <- this is my diff on top of your branch thus far. | 17:07 |
| jam | mgz: anyway /me is in family time | 17:07 |
| mgz | byebye. | 17:07 |
| jam | mgz: also, we don't need _fs_encode for open() and I'd rather avoid it | 17:07 |
| jam | I'd also rather use encode('utf-8') where it gets put into headers | 17:07 |
| mgz | yup. | 17:07 |
| jam | thoguh there are arguments both ways | 17:07 |
| mgz | the open argument doesn't end up in the tar anyway, it's just the branch filenames to worry over there | 17:08 |
| jam | mgz: ! is ok, if you are sure it will fail 100%, though I'd rather take the chances on 65k * 1-in-256 chances of getting '\r' randomly | 17:08 |
| mgz | well, the problem with random is that it's... random. "!" is 100% with the code on my machine, it's just a question of if tar module changes have ever modified the output it gives to gzip. | 17:10 |
| mgz | the constants all look pretty constant from the code, provided stuff like file mode bits haven't been messed with. | 17:12 |
| magcius | jam, is my merge deployed yet? | 17:15 |
| * jelmer moves | 17:15 | |
| jam | mgz: true, but 1in 2^256 is a pretty small chance of failure :) | 17:20 |
| mgz | fairynough. | 17:22 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| achiang | hello, having some conceptual issues, hoping to get some pointers. upstream branch has two commits, -1, and -2 that i want to drop | 18:11 |
| achiang | so i tried: bzr uncommit ; bzr uncommit ; bzr revert --no-backup | 18:11 |
| achiang | can i just push this new local copy to upstream now? | 18:11 |
| achiang | i think maybe not so much... | 18:11 |
| beuno | no | 18:11 |
| beuno | so, what you'll want | 18:11 |
| beuno | is to revert to -3 and then apply -1, I think | 18:12 |
| achiang | beuno: i've tried reading the bzr merge and bzr revert man pages several times and still find them rather incomprehensible. :-/ | 18:12 |
| beuno | so, if these are revnos, say, 9 and 10 | 18:13 |
| beuno | I'd bzr revert -r 8 | 18:13 |
| beuno | commit, and then bzr merge -r 10 | 18:14 |
| beuno | I think that would do it | 18:14 |
| maxb | achiang: Hi. So, you could push your uncommitted head if you really wanted to, but rewinding a public branch leaves no evidence that you intended them to be removed | 18:14 |
| beuno | and will cause others that have it to maybe have problems | 18:14 |
| maxb | So, other people who had already obtained those revisions would not receive any kind of information that you wanted them gone and would probably reintroduce them | 18:14 |
| achiang | yes, i want to leave a record of my revert | 18:14 |
| maxb | So, what you actually want to do is to ensure you have your local tree up to date and clean at revision -1 | 18:15 |
| maxb | and then bzr merge -r -1..-3 | 18:15 |
| maxb | Actually, make that 'bzr merge -r -1..-3 .' | 18:15 |
| achiang | maxb: beuno: i think i got it with what beuno mentioned... i just said, "bzr revert --no-backup -r 29" | 18:16 |
| achiang | and that gets rid of r30 and r31 | 18:16 |
| achiang | and now i'm making a new commit | 18:16 |
| maxb | beuno instructions confuse me, the revert and commit bits make sense, but what's the final merge for? | 18:16 |
| beuno | to bring back the -1 revision, which he wanted | 18:17 |
| beuno | he has -1, which he wants, and -2, which is doesn't | 18:17 |
| achiang | beuno: no, i did not do the final bzr merge | 18:17 |
| maxb | Not according to achiang's initial statement | 18:17 |
| achiang | conceptually, it was dropping just the top two commits | 18:18 |
| achiang | not commits in the middle anywhere | 18:18 |
| achiang | beuno: maxb: thanks for the help (again). i know i've asked for help on dropping commits before, but the bzr way of doing it still hasn't sank in yet. :-/ | 18:19 |
| beuno | ah | 18:19 |
| beuno | then it was just rever, yeah :) | 18:19 |
| maxb | The bzr way is not all that different to the svn or cvs way, really :-) | 18:20 |
| achiang | if one starts as a git user and then tries to grok bzr, it's hard | 18:20 |
| maxb | well yes, that's cos git is different to mostly everything else :-) | 18:21 |
| achiang | ... but growing most rapidly in adoption, so maybe it's time to rethink that attitude. :) | 18:21 |
| achiang | but anyway, i am not here to bite the hands that help me | 18:21 |
| maxb | I know it is. I just don't understand why :-( | 18:21 |
| achiang | i genuinely appreciate the help, so thank you | 18:21 |
| maxb | I am capable of using git, I just don't understand why I would want to | 18:22 |
| maxb | And when I can 'bzr branch git://......' I don't have to :-) | 18:22 |
| === Ursinha-afk is now known as Ursinha | ||
| maxb | This reminds me, I need to write some sort of hook-based branch replication solution, so I can have another go at popularizing bzr at work | 18:24 |
| maxb | (am continually mystified that no-one has done this already) | 18:26 |
| maxb | Surely someone out there must run a bzr hosting server with near-realtime syncing of pushed changes to an offsite node? | 18:26 |
| vila | maxb: I think bound branches address more than 90% of the needs so nobody stepped up... | 18:28 |
| maxb | ? | 18:28 |
| maxb | How do bound branches address the use-case of bzr.someorganization.com being replicated to another server? | 18:29 |
| vila | that's not what I said | 18:29 |
| vila | I meant, if you know your changes are already in two different places, you don't care pushing them to a *third* place | 18:29 |
| maxb | I suppose | 18:29 |
| vila | but I fully agree with you that we need a better backup story for hosting servers | 18:30 |
| maxb | But recovering from a putative disk failure relying on individual developer workstations isn't a very palatable situation | 18:30 |
| vila | indeed | 18:31 |
| maxb | I suppose everyone who does this is coming up with their own solution for their private architecture | 18:31 |
| maxb | Which is a shame, because bzr's hooks are almost good enough to make this work really nicely | 18:32 |
| vila | the hard part is handling the restore and the deleted branches and other evil details | 18:32 |
| maxb | stacking locations being a very evil detail :-) | 18:32 |
| vila | shhh, don't wake up the daemons ;) | 18:33 |
| maxb | I was planning to punt on that and just use shared repositories | 18:33 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| insanity99 | hey guys, im trying to set up bazaar so i can access my python folder on 2 computers. but im finding it hard to do | 19:47 |
| insanity99 | anyone here? | 19:54 |
| wilx | Hi. | 20:04 |
| wilx | I am sort of confused about workspace models provided by the Bazaar Explorer. | 20:05 |
| wilx | Basically, I want to mirror a SVN branch locally. | 20:05 |
| wilx | From that local mirror I want to be able to create Bazaar branches. | 20:05 |
| insanity99 | dont think anyones here | 20:05 |
| insanity99 | im trying to set up bazaar so i can access my python folder on 2 computers. but im finding it hard to do | 20:06 |
| wilx | ..so that I can do disconnected development. | 20:06 |
| wilx | And when I am done with development, I want to be able to commit the changes back to the mirror and through that back to the SVN repo. | 20:06 |
| wilx | Do I want "feature branches" or "colocated branches" or "shared repository"? | 20:07 |
| jelmer | wilx, shared repository is just a storage optimization | 20:51 |
| jelmer | wilx, it sounds like you want feature branches | 20:51 |
| wilx | Ok. Thanks. I will try with that. | 20:56 |
| chx | hi. is bzr heads supposed to be very very slow? :) | 21:22 |
| lifeless | no | 21:24 |
| chx | it just sits there | 21:25 |
| chx | for quite some time now :/ | 21:26 |
| soren | It's quite slow for me, too. | 21:26 |
| soren | I have a /lot/ of branches, though. | 21:26 |
| chx | so here's why i am running it: one of teammates did a number of bzr commit --local then bzr pull and now he wants his commit history back. Is that possible? | 21:26 |
| soren | $ time bzr heads | 21:27 |
| soren | [...] | 21:27 |
| soren | real1m1.604s | 21:28 |
| soren | user0m32.600s | 21:28 |
| soren | sys0m8.460s | 21:28 |
| soren | Not as slow as I remembered. | 21:28 |
| soren | It's doing a lot of work, though. As I said, I have a lot of branches. | 21:28 |
| chx | i dont have a lot of branches but the repo is quite big -- lots and lots of files and revisions. | 21:28 |
| lifeless | chx: sure its possible. bzr heads --dead | 21:28 |
| chx | just came back empty | 21:29 |
| chx | after like eight minutes or something | 21:29 |
| chx | bzr st -v shows them as pending | 21:29 |
| lifeless | oh | 21:29 |
| lifeless | just commit :> | 21:29 |
| lifeless | chx: its not dead - its a pending merge; bzr heads --all should list his last commit | 21:32 |
| chx | so i am expressing myself wrong. previously bzr log showed them as commits. that's what we would like back. a bzr commit would put them into one commit. | 21:37 |
| chx | yes. i know this should be a branch and not bzr commit --local :/ | 21:37 |
| soren | chx: I don't think I understand the motivation, but something like this should do it: | 21:40 |
| soren | chx: bzr pull . -r revid:the_revision_id_of_his_original_head | 21:40 |
| psynaptic | hey there, I have lost my head | 21:40 |
| soren | chx: bzr merge url_to_the_shared_repo | 21:40 |
| soren | chx: bzr commit -m 'Merge trunk' or whatnot. | 21:40 |
| lifeless | pssibly bzr merge --uncommitted will suck the pending merge across - I'm not sure though | 21:41 |
| chx | psynaptic: no you didnt | 21:41 |
| chx | psynaptic: you have all your commits but now they form a pending merge | 21:41 |
| psynaptic | my working copy contains all the changes | 21:42 |
| psynaptic | which is what scares me | 21:42 |
| chx | soren: bzr pull . -r 18143 is no revisions to pull | 21:49 |
| soren | chx: Not revno, revid. | 21:51 |
| chx | oh revid! | 21:51 |
| soren | And make it "-r revid:the_rev_id" | 21:51 |
| chx | so then the question is, how do i see the revid of a pending merge that st -v shows me? | 21:52 |
| soren | chx: As lifeless said, bzr heads --all should show it. | 21:53 |
| soren | chx: I'm not sure bzr status gives it up easily. | 21:53 |
| chx | ok give me ten minutes while that runs :D | 21:54 |
| psynaptic | ;) | 21:54 |
| lifeless | what format repo is this that its taking so long? | 22:03 |
| psynaptic | it's on launchpad | 22:05 |
| psynaptic | which seems slow for us | 22:06 |
| psynaptic | we have tons of branches though | 22:06 |
| BjornW | Hi there, can someone tell me if and where I can find more information on using php to script bzr? | 22:06 |
| chx | lifeless: i think 2a | 22:07 |
| lifeless | oh | 22:07 |
| lifeless | don't run heads against lp | 22:07 |
| lifeless | you run it against your local branch | 22:07 |
| chx | oh my lord it runs against LP???? | 22:08 |
| * chx immediately breaks | 22:08 | |
| chx | lifeless: ok, so .... this is a checkout bastardized with commit --local and then up. | 22:08 |
| lifeless | chx: lightweight or heavyweight? [bzr info should say[ | 22:11 |
| chx | lifeless: heavyweight checkout. we do not use lightweight checkouts. | 22:11 |
| lifeless | ok | 22:11 |
| chx | " checkout of branch: " | 22:11 |
| lifeless | so, I'm not sure why bzr heads is going to lp, but it will explain it | 22:11 |
| lifeless | (the performance) | 22:12 |
| lifeless | and why it doesn't see your head | 22:12 |
| lifeless | so | 22:12 |
| lifeless | bzr unbind | 22:12 |
| lifeless | then bzr heads --dead | 22:12 |
| chx | ahhha | 22:13 |
| chx | didnt dare to unbind | 22:13 |
| chx | i mean, i thought of reconfigure | 22:13 |
| chx | but let me try | 22:13 |
| chx | i am now, after all, on a copy. | 22:13 |
| lifeless | chx: unbind saves the location | 22:21 |
| === psynaptic is now known as psynaptic|away | ||
| lifeless | chx: you can 'bind' to get it rebound | 22:21 |
| chx | even after unbind it have not finished yet | 22:21 |
| chx | though i ran bzr heads --all | 22:21 |
| chx | lifeless: i have stopped it running. it STILL did not finish. | 22:51 |
| lifeless | chx: :( | 23:04 |
| lifeless | chx: maybe spiv can give you a hand; I'm juggling too many things just now | 23:04 |
| spiv | chx: check the output of 'bzr info' | 23:09 |
| spiv | Maybe there's something obviously odd. | 23:09 |
| chx | spiv: http://paste.pocoo.org/show/354260/ | 23:12 |
| chx | spiv: i think it's not too odd | 23:14 |
| chx | spiv: http://paste.pocoo.org/show/354263/ this is st -v | 23:14 |
| spiv | chx: and the problem you're having is that 'bzr heads --all' is being very slow? | 23:17 |
| chx | spiv: well psynaptic mostly just wants his commits to show in bzr log as it did before bzr up :( | 23:18 |
| psynaptic | this is what happened: | 23:19 |
| psynaptic | <changes> | 23:19 |
| psynaptic | ci "commit1" | 23:19 |
| psynaptic | sorry.. | 23:19 |
| psynaptic | ci "commit1" --local | 23:19 |
| psynaptic | <changes> | 23:19 |
| psynaptic | ci "commit2" --local | 23:19 |
| psynaptic | then I had this local history: | 23:20 |
| psynaptic | commit2 | 23:20 |
| psynaptic | commit1 | 23:20 |
| spiv | If you're trying to find the revid of the pending merge, try using 'bzr qlog', it shows revids of pending merges. | 23:20 |
| psynaptic | but then I ran up, I got changes from commit1 and commit2 dumped into my working copy and lost the commit history | 23:20 |
| spiv | And then "bzr pull --overwrite -r revid:..." as suggested earlier will put the commit back as the tip | 23:21 |
| psynaptic | not sure why but we don't have qlog | 23:21 |
| spiv | psynaptic: not lost, just not on the mainline anymore. If you commit you'd still see commit1 and commit2 in in the output of 'bzr log -v' | 23:22 |
| spiv | psynaptic: it's part of the qbzr plugin | 23:22 |
| psynaptic | ahh, so if I commit these changes it will keep my history? | 23:22 |
| spiv | (Oops, I meant 'bzr log -n0', rather than 'bzr log -v') | 23:22 |
| spiv | Yes, it'll appear as a merge, essentially. | 23:22 |
| psynaptic | right | 23:23 |
| psynaptic | lemme try that | 23:23 |
| spiv | That's why 'bzr st' is telling you about 'pending merges', to reassure you that history is being kept and will be recorded when you commit. | 23:23 |
| psynaptic | didn't seem to work like that | 23:23 |
| psynaptic | ok, I have restored the backup | 23:25 |
| psynaptic | st does show pending merges but they were consolidated into a single log item when I did commit --local | 23:26 |
| spiv | Try 'bzr log -n0' | 23:26 |
| spiv | or 'bzr qlog' (or 'bzr viz' if you have bzr-gtk) | 23:26 |
| psynaptic | right | 23:27 |
| psynaptic | bzr log -n0 does show all the commits | 23:27 |
| psynaptic | :) | 23:27 |
| psynaptic | great, thanks a lot | 23:28 |
| psynaptic | I am happy now | 23:28 |
| psynaptic | :D | 23:28 |
| spiv | Mostly we just show the "left-hand" or "mainline" history by default | 23:28 |
| psynaptic | I see | 23:28 |
| spiv | But when you commit a merge (or "bzr up" then "bzr commit" when you have local commits, which is essentially the same situation) there's a revision with multiple parents. | 23:29 |
| spiv | bzr log -n0, and the visualisation tools like 'bzr qlog' can tell you about the full graph. | 23:30 |
| psynaptic | handy | 23:30 |
| SuperMMX | hi, when I use bzr-svn to branch in windows, I found that there are revisions with backslap \ in one directory name, and the next revision fixed it. But now I get the error of invalid character in the directory name. bzr 2.3.0 with the bundled bzr-svn. | 23:36 |
| SuperMMX | is there any way to workaround this ? | 23:36 |
| jelmer | SuperMMX: no, Bazaar doesn't support entries with backslashes unfortunately | 23:38 |
| jelmer | bug 81844 | 23:38 |
| ubot5 | Launchpad bug 81844 in Bazaar "Handle backslashes in filenames more gracefully" [Wishlist,Confirmed] https://launchpad.net/bugs/81844 | 23:39 |
| SuperMMX | no workaround at all ? That was just one revision. | 23:39 |
| SuperMMX | actually, I google all related bugs, mailling list, seems no luck so far. | 23:39 |
| jelmer | SuperMMX: none other than cloning from a location that doesn't have any backslash in the history | 23:39 |
| SuperMMX | jelmer: that's bad, one mistake blocks all. | 23:40 |
| jelmer | I think we should probably increase the importance of that bug | 23:41 |
| jelmer | given the number of people that have hit it so far | 23:41 |
| SuperMMX | probably shallow branch can fix the problem, but that wil be in the far future. | 23:42 |
| jelmer | yes | 23:42 |
| SuperMMX | jelmer: thanks anyway. | 23:46 |
| psusi | I'm trying to specify a tag with bzr branch -r that has a : in it and it seems to be interpreting the : in a way that confuses it | 23:50 |
| psusi | is there some sort of escape needed or something? | 23:50 |
| jelmer | psusi, prefix the tag name with tag: | 23:51 |
| psusi | ahh | 23:51 |
| jelmer | that forces bzr to consider that string as a tag name | 23:51 |
| Peng | : is special in revison specs -- see "bzr help revisionspec" | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!