[00:28] jelmer: You have removed the failure note about bzr-explorer from DailyPpaStatus, but the latest build is still failing in the same way? [00:38] ping [00:41] ping who? [01:24] maxb: it's a bzr bug that's been fixed [02:58] jam, ping [02:59] jam, http://bazaar.launchpad.net/~jstpierre/loggerhead/fix-569358/revision/434 [03:00] 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] er, lp:~loggerhead/fix-569358 [03:05] magcius: lp:~/loggerhead/fix-569358 [03:05] magcius: “~foo” of course would always mean the user foo. [03:05] OK. [03:06] I tend not to use that shortcut though because you can't share that URL with other users. [03:43] spiv, it's a bit long to type. [03:43] spiv, and I accidentally pushed to a different URL at first. [03:44] and I'm not sure I can re-set it [03:45] reset what in particular? [03:45] The default location for 'bzr push'? Use 'bzr push --remember URL' [04:43] jam: http://blog.vrplumber.com/index.php?/archives/2490-Meliae-is-neat,-but-scary....html === arjenAU2 is now known as arjenAU [05:40] 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:44] spiv: thanks for the heads up. Didn't realize someone was talking about me at pycon :) [05:44] thomi, i'd guess it's because you're installing it to the wrong path [05:44] but yes, the observation that memory gets sucked into dicts is also what I've found [05:44] hi po [05:44] poolie: hi [05:44] hi there [05:44] i'm going out now; biab [05:45] I'm installing it to /usr/share/pyshared/bzrlib/plugins/sloecode - if I put it in ~/.bazaar/plugins/sloecode it works fine. [05:45] by hand, or using pycentral etc? [05:46] i think just putting the files there is not enough [05:46] hi mars [05:46] the latter, although I'm just following the packaging guide on the wiki, so I may have missed something [05:47] 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] thomi: offhand, I don't think /usr/share/pyshared is in the bzrlib search path [05:47] jam, I was going to do that, I didn't know assertRaises returns the exception. [05:47] I think we search the platform specific ones [05:47] magcius: it doesn't in unittest, it *does* in bzr's test suite [05:48] Yeah. [05:48] thomi, i would just check what's different between your packaging and say bzr-gtk [05:48] I usually use pytest, which is a bit nicer, I guess. [05:48] 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] unittest is very barebones, I know twisted fixed a bunch of those random things up [05:48] poolie: yeah, I've been comparing to bzr-hg, and so far they look very similar [05:48] thomi: very strange [05:49] you might want to try "bzr plugins" and "bzr -Derror". It is possible the plugin is failing to load, and -Derror should tell you why [05:49] magcius: bzr's test frame is (mostly) testtools these days [05:49] magcius: which has some very nice stuff in it, if I do say so myself [05:49] testtools? [05:50] testtools [05:50] fork of unittest or something? [05:50] http://pypi.python.org/pypi/testtools [05:50] magcius: https://launchpad.net/testtools, http://pypi.python.org/pypi/testtools [05:50] jam: I've tried that. 'bzr plugins -Derror' produces no additional output, and 'bzr sc-login -Derror' gives me "unknown command 'sc-login'". [05:51] magcius: a library of tasteful extensions within the unittest design, not a fork [05:51] OK. [05:51] Everybody has their own testing framework :( [05:51] latest kid on the block: http://packages.python.org/Oktest/ [05:52] That's why testtools isn't a new framework :) [05:52] jam, so, I know Loggerhead is a separate project from Launchpad. [05:53] jam, so, if I wanted http://bazaar.launchpad.net/launchpad to do a redirect to http://code.launchpad.net/launchpad [05:53] how would I do that? [05:53] without introducing some coupling or assumptions that we're running under Launchpad. [05:53] Would I have a hookable, global 404 handler? [05:56] magcius: launchpad runs its own "main" script, you could certainly do something at that level [05:56] jam, linky? [05:56] magcius: grabbing it [05:56] Thanks! [05:57] magcius: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/files/head:/lib/launchpad_loggerhead/ [05:57] OK. [05:57] and http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/view/head:/scripts/start-loggerhead.py is the actual start script [05:58] 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] Right. [05:59] Is most of the code in lib.launchpad_loggerhead.app just there for the oops stuff? [05:59] magcius: and stuff like /favicon etc [05:59] OK. [06:00] 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:21] jam, https://code.launchpad.net/~jstpierre/loggerhead/fix-569358/rev/435 [06:21] er [06:21] jam, http://bazaar.launchpad.net/~jstpierre/loggerhead/fix-569358/revision/435 [07:14] jam: I'd appreciate your thoughts on https://bugs.launchpad.net/bzr/+bug/709349 [07:14] Ubuntu bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [High,In progress] [07:16] 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:38] spiv, i read that [07:39] my only idea would be that it is indeed filesystem weirdness, but that would be strange on a local linux fs [07:44] poolie: thanks for that. At least I'm not missing anything obvious then :) [07:45] :} [08:02] hi all ! [08:04] morning vila [08:04] hay jam, you're up quite early :) [08:04] jam: (according to the logs that is) [08:04] vila: I get up around 6:30. Just takes a while to get everyone off to school, etc. [08:29] hi jam, vila [08:29] hi poolie [08:29] hey poolie [08:31] hi vila, I manage to propose a merge, thanks for the help. [08:31] mr-russ: you're welcome ! (on all counts ;) [08:45] package-importer is toasted [08:45] debug_log mentions OperationalError: table failures has 4 columns but 3 values were supplied [08:46] does that ring any bell in someone's head ? [08:50] vila: not for me [08:51] I'm investigating but the error message basically implies that the failures table got an additional row... [08:55] where by row, you mean column? :-) [08:56] maxb: obviously :D [08:58] but this doesn't make a lot of sense... the column is 'emailed' and has been there for more than a year... [08:58] ...except if this exception was *never* caught before.... [09:05] vila: one possibility is if the column changed to being NOT NULL or something along those linse [09:05] lines [09:06] jam: I've icommon..._set_failure to properly initialize 'emailed' to 0 [09:06] vila: weird, 'emailed DEFAULT 0' [09:06] I've also killed the running mass_import and the nexuiz-data one [09:06] jam: indeed [09:06] but also "SELECT count(*) FROM failures" == 0 [09:06] vila: so no failures have ever been logged [09:06] or that table is cleared out by something [09:10] jam: or some new sqlite3? version introduced a change ? [09:10] in behaviour [09:11] bah, very unlikely [09:11] vila: I think the "we've never put anything into that failure table" is pretty significant [09:11] the table is empty right now [09:11] jam: it is not on my local importer [09:12] and _start_package insert a a new row [09:12] in the failures table [09:12] vila: I'm just telling you what I see on jubany [09:12] meta.db has no rows in the "failures" table. [09:12] jam: I get that, I just continue the discussion :) [09:13] the truth is there somewhere, waiting for us to discover it by throwing contradictions to each other ;) [09:13] 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:14] 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:15] I've been told we're losa-less until US starts... [09:18] vila: I started. wait... [09:19] jam: no ! [09:19] jam: you can't properly start the mass_import.py script [09:20] vila: I'm saying I started work, but I'm not in the US zone anymore. [09:20] gee, you scared me ;) [09:20] I almost made a joke about you not being in US anymore... :D [09:20] the kanban is about to get a bit more accurate [09:21] as i roll out trunk [09:21] ah, some of it's going to need to wait on a review [09:21] but, still, a bit better [09:38] i should finish [09:38] vila, i just noticed http://people.canonical.com/~mbp/kanban/vila-kanban.html is curiously empty [09:38] i'm sure you're doing stuff but maybe you should update the bugs? [09:39] poolie: I just made it even more empty :) [09:39] :) [09:41] poolie: and I just pushed a fix for the importer without an associated bug which doesn't help either ;) [09:41] well, the point is to fix things, not move the cards around [09:41] but a certain amount of keeping track of things is useful [09:42] poolie: sure [09:43] wow: http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/junit/bzrlib.tests.test_export/TarExporterTests/test_tgz/ [09:43] jelmer: ^ could that be related to your recent changes ? [09:45] vila, jelmer: Looks like a O_BINARY issue to me [09:45] probably "bzr export" isn't set to use EXACT encoding [09:45] so it outputs in Text form, and that garbles the compressed data [09:46] do we have a bug about switching to sphinx (including pqm) ? I couldn't find one [09:46] or switching to tarmac, whatever [09:46] 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:47] 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] my personal feeling is that without Queued status in Launchpad [09:47] Tarmac is a poor fit for us [09:57] jam: Yeah, that's one of the reasons people buy particular cars which are taxed less. [09:57] jam: Same goes for LPG [09:58] jelmer: is it meant to be a tax on industrial vehicles? [09:58] or because diesel traditionally has higher polutants? [09:58] (I know in the US, they didn't get low-sulpher diesel until something like post 2007) [09:59] jam: I think the pollution is the reason, but I'm not entirely sure [10:00] just curious [10:00] do you even have a car? [10:00] jam: Nope, I don't have one.. and my parents didn't have one when I grew up. [10:01] 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] jam: You're looking at getting a car in .nl? [10:01] jelmer: interesting. I know quite a few people in big cities that live that way. [10:01] jelmer: yeah [10:01] the big thing is having a child, and trying to figure out how to get him around [10:01] it is possible by bike, but likely we still want a car [10:02] jam, i'd be happy to switch to tarmac [10:02] the place we've picked is also more on the outskirts (in Waalre, if that means anything to you) [10:02] it looks like the losas want us to set it up ourselves [10:03] poolie: I've seen quite a few limitations when people get into the details, though. [10:03] limitations of tarmac? [10:03] jam: Ah, nice. I've camped there once :) [10:03] and how do we set it up ourselves without a datacenter access? Run it on our own machines? [10:03] anyhow, i have a medium-low thing on my todo list of prototyping it [10:03] at least for the prototype [10:03] poolie: stuff like not being able to land on anything that isn't the dev focus, etc. [10:03] I think some have been overcome [10:03] but since rockstar isn't focused on it anymore [10:04] maintained bot >>> unmaintained bot [10:04] jam: Are you implying pqm is maintained?? [10:04] :) [10:04] I think that was, honestly, the only problem with PQM [10:04] jelmer: not at all. but I'd rather keep a tool that we're using now and have worked around [10:04] it's not top of my list [10:04] than switch it for *another* unmaintained tool [10:04] 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:05] especially since it was designed around incomplete features in Launchpad [10:05] I *really* want a tweak rating, and "review: needsfixing, merge:approve" is the best we have, but Tarmac will land that patch. [10:05] since we don't have Queued [10:06] i would like 'tweak' too [10:06] ok, really good night now [10:06] poolie: sleep well [10:06] jelmer: need me to fix the windows export breakage? [10:08] g'night poolie, see you tomorrow [10:08] 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] jelmer: did you see my earlier comment about possibly being an "encoding=exact" type thing? [10:08] vila: bonus points, the test passes when "bzr selftest -s bt.test_export" [10:08] but *fails* with --verbose [10:08] jelmer: ^^ [10:09] jam: ahh [10:10] jam: You're probably right, as tgz (and tar) is the only one we actually use open() for [10:10] jam: tar isn't tested though [10:11] jelmer: and doing "bzr export --verbose --format=tgz - " does generate an invalid stream [10:11] jelmer: http://paste.ubuntu.com/580504/ [10:11] makes it pass for me [10:11] with --verbose [10:12] jam: +1 [10:13] poolie: thanks for removing the needs testing column in kanban :) [10:19] vila, jelmer: have you had any problems pushing changes to LP? [10:19] jam: no, but I haven't tried yet this morning [10:19] I just tried to push an update to my "jam-integration" branch, and it is telling me Readonly. [10:19] *sigh* just figured it out [10:19] jam-integration was a mirror [10:19] bad error messages ftl [10:20] (of course, the source is now offline since I took down my server) [10:21] jelmer: anything we can do to get your Kanban "needs release" changes into Released? [10:22] jam: not really, some of them are just waiting for upstream releases [10:22] I'm working on fixing some last bugs before a bzr-svn release now [10:22] but I have no control over wikkid, storm, pygpgme, etc [10:23] 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] I've tried to change the default user-agent, no luck [10:24] evanton: it seems to work fine here in e.g. curl [10:24] evanton: are you getting a 401 of some sort, or a HTML access denied page? [10:24] 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] *code [10:25] evanton: several of us should be around for a while [10:25] evanton: it works here using 'wget' [10:25] jam: no problem pushing so far [10:25] *My* guess is that you have an HTTP proxy that you aren't respecting in your http library [10:26] vila: I figured it out. Was a mirror branch I was pushing to [10:26] and LP giving no reminder ofthat [10:26] right, just read it :-/ [10:27] ok, I found it [10:27] I'm getting a 403 [10:27] "You are not allowed to access this!\r\n" [10:27] it is the urllib3 python HTTP library, if this matters [10:29] evanton: if you can dump your HTTP headers, you might find something interesting. [10:29] I really do expect it is a Proxy issue [10:29] jam: the request headers or the reply headers? [10:29] jam: and I'm not behind a proxy [10:29] evanton: probably both, especially if you can catch the ones your web browser sends [10:30] jam: sure, I have live http headers in firefox [10:37] jam: http://dpaste.org/mdBc/ [10:37] the first is the sniffed http session of urllib3, below is the dump from live http headers (firefox browser) [10:39] evanton: you're not passing an "Accept" (if I read it correctly) [10:39] I don't know if that matters [10:39] evanton: here itis. you are passing the full URL [10:39] "GET http://wiki.bazaar.canonical.com/QBzr" [10:39] not [10:40] "GET /QBzr" [10:40] (that is my guess) [10:40] hmm [10:40] I've certainly seen servers that reject passing the full URL in the GET [10:40] jam: so it likely looks like a problem with this particular http library? [10:41] evanton: something like that [10:41] it is passing "Host:" so it shouldn't be also passing the full URL [10:41] at least, AIUI [10:41] I am confused because I'm using this library for other sites too and this is the first site that dumps me [10:42] 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:44] interesting, retrieving /QBzr works [10:44] passing the whole URL normally means that you want to use the HTTP server as a proxy [10:44] jam: you are probably right, I'll mail the author of urllib3 [10:44] evanton: I can confirm, sending raw socket.socket() messages [10:44] thanks for your help [10:44] sending /QBzr works [10:44] sending full url gives Forbidden [10:45] Is there a way to force "bzr clone" to provide progress information when running in an non-interactive environment? === hunger_ is now known as hunger [10:45] hunger_: BZR_PROGRESS_BAR , IIRC [10:45] hunger: export BZR_PROGRESS_BAR=text [10:45] should do it [10:46] jam: Great! Thanks! [10:46] jam: The bzr checkout wizard in Qt Creator is not providing any indication that it is doing something... we need to fix that:-) [10:49] hunger: I'm guessing you want to ensure the process barrier rather than using bzrlib? [10:49] One thing you could consider, is setting your own UIFactory [10:50] jam: The code was contributed. I have to admit that I never really looked into bzr myself:-) [10:51] jam: It does work pretty well though, doing the normal checkout etc. I di dto test the plugin. [11:19] hello there ! [11:20] I have created a QtCreator plugin for Bazaar [11:20] at some point I need to get the ouput of the 'bzr clone' command [11:21] I have tried to play with the BZR_PROGRESS_BAR env-var [11:21] but with no success [11:22] only the modes 'none' and 'tty' work [11:22] 'dots' or 'text' don't [11:23] any idea ? [11:30] cerf: version of bzr? [11:30] dots is pretty old, IIRC [11:30] v2.2.1 [11:33] it still appears in 'bzr help env-variables' [11:33] 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:34] bug #339385 [11:34] Launchpad bug 339385 in Bazaar "bzr: BZR_PROGRESS_BAR is ignored" [High,Fix released] https://launchpad.net/bugs/339385 [11:34] so the last time I see it explicitly touched is pre 2.0 [11:34] but checking [11:35] that's right I have seen this bug report [11:35] cerf: since bzr-2.0 it has been either "text" or "none" [11:35] not "tty" or "dots" [11:36] cerf: http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0/view/head:/bzrlib/ui/text.py#L144 [11:37] indeed [11:38] 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] should work in all 2.X releases [11:38] what would you suggest to work around my problem ? [11:38] cerf: if you could file a bug about "bzr help env-variables" having bad documentation, and then use "BZR_PROGRESS_BAR=text" [11:38] I think it is just a doc bug [11:38] I cant get tty or text progress output [11:38] Are you sure it was "tty" that worked for you, and not "text" ? [11:40] 'tty' works the same as 'text' for me [11:40] cerf: I can confirm here that "export BZR_PROGRES_BAR=text" works for me [11:40] if I do "bzr log http://.... >out.txt 2>err.txt" [11:40] with the setting, it puts progress into 2 [11:40] without, it doesn't [11:40] are you expecting progress on stdout ? [11:42] yes that's it [11:42] is it possible ? [11:43] cerf: progress is always on stderr, so it doesn't intermingle with real data on stdout [11:43] you can certainly capture stderr of a subprocess, though [11:44] thanks jam, I'm gonna try to read stderr [11:46] cerf: bug #735417 [11:46] Launchpad bug 735417 in Bazaar "doc for BZR_PROGRESS_BAR incorrect" [High,Confirmed] https://launchpad.net/bugs/735417 [11:47] hopefully gets backported to at least 2.2 [12:46] jam: are you submitting a fix for the tgz export test or should I ? [12:46] jelmer: already finished through pqm [12:47] heh, nevermind then :) [12:47] jam: Thanks [12:47] Just used 'pqm-submit' rather than going through the launchpad work [12:47] I usually do that for "trivial" fixes [13:12] jam: the empty failures table is probably due to bug #608563 as I *did* issue a retry --all to address slangasek query [13:12] 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] ah [14:51] eeerk, there are uncommitted changes on jubany ?? [14:51] in delete_branches_from_lp.py fwiw [14:55] I think spiv was hacking on that [15:05] ha (I was about to ask you the same question in #lp-ops ;) [15:05] err is, but anyway [15:06] hmm, I'll try to ping tomorrow and if they come in the way will just shelve them and mail him [15:19] 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] It works here [15:19] and it did fail before my update [15:19] this hints that it has the updated patch: http://babune.ladeuil.net:24842/job/selftest-windows/374/ [15:20] jam: yup, more than hint [15:21] vila: doesn't mean hudson actually succeeded in applying the update. But yeah, I would be surprised if it didn't === deryck is now known as deryck[lunch] [15:21] well, I've seen weird things on jenkins/hudson, but not using the right code ? Never so far [15:22] jam: could it be that the encoding is overridden when running without a real tty or something ? [15:23] 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] vila: redirecting to a file still works for me here [15:24] jam: you're notoriously good at avoiding windows babune slave bugs ;D [15:25] vila: I'm running the wrong file, just a sec [15:26] k weird, I know I got at least one failure in the past [15:26] which 'exact' seemed to help [15:26] but now, it won't fail either way [15:26] I suspect a failure to flush() [15:26] which would make it ~ load dependent [15:26] and certainly babune runs differently there [15:27] jam: also, is redirecting to a file the same thing as running ~without a console as on babune ? [15:27] vila: you are redirecting to a file already. [15:27] not sure about 'without a console' [15:27] but you are capturing the output == redirected to a file [15:28] I can no longer reproduce failure with or without -v with or without my patch :( [15:28] pipe probably... or are you talking about the test framework ? [15:28] jam: ouch [15:29] I know I did see a failure before [15:29] not sure how I triggered it [15:29] but that was how I thought I 'fixed' it. Since it did fail, and then it stopped failing [15:29] ah, got a failure [15:29] load dependent [15:29] vila: "for i in `seq 20`; do bzr selftest -s bp.test_export test_tar_exporter; done [15:29] 'load' as in CPU load or import load order ? [15:29] and I got maybe 3-4 failures out of 20 [15:30] ooooooouch [15:30] (without my patch) [15:33] jam: eerk, erratic on babune too: look for 41 vs 42 :http://babune.ladeuil.net:24842/job/selftest-subset-windows/ [15:34] vila: well, I see now. "test_tar_export" exports to a file on disk, not to '-' [15:34] so it obviously wouldn't have been affected by my patch [15:35] urgh, I dunno what I prefer :-/ [15:36] vila: I think it is just a flushing issue. TarFile.close() does *not* close its underlying stream. [15:36] I don't know why GzipFile would get caught up without flushing itself [15:36] I'm trying a different patch [15:36] note also, that the streams are not explicitly closed [15:36] no try/finally [15:37] ug [15:37] stream = open(dest.encode(osutils._fs_enc), 'w') [15:37] doesn't look good [15:37] I don't know how it ever worked [15:37] maybe got lucky and no '\r' or '\n' in the compressed stream [15:37] aaaaah [15:38] note that for gzip.GzipFile: [15:38] "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] however, we are opening directly with "open()" [15:38] >_< === Ursinha is now known as Ursinha-lunch [15:53] 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] I'll try to get to it tonight. [15:53] I'd like to change a few other things anyway. [15:59] *sigh*, even adding more data to it doesn't guarantee it will fail. time to try harder [16:01]