[00:01] wgrant: so having old email addresses is normal? [00:02] Good morning. [00:02] hi spiv [00:02] meoblast001: People change email addresses. You cannot change them in old commits. I think so. [00:02] well, you can, but it's not normal :P [00:03] and it breaks compatibility of all branches [00:03] verterok: see https://answers.edge.launchpad.net/bzr-explorer/+question/84897. Was it ok to say that? [00:04] wgrant: one last question, do most version control systems also use emails like bazaar does? [00:05] bazaar is the only real version control system i've used with any of my projects [00:05] meoblast001: I think all the DVCSes do, but I couldn't be sure. [00:05] hi spiv, I believe you know the most about smart http servers? [00:05] SVN does whatever it wants. [00:05] malept: probably, yeah [00:06] spiv: what does ""An attempt to access a url outside the server jail was made"" [00:06] mean? [00:06] wgrant: well, as linus torvalds says, svn is horrible, right? ;) [00:06] meoblast001: Yes. [00:06] (followed by a chroot-[somenumber]:///) [00:07] malept: probably that you're hitting https://bugs.edge.launchpad.net/bzr/+bug/348308 [00:07] Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] [00:07] malept: there's a work-around in the last comment. [00:07] igc: yes it was ok, I plan to make a installer for Tiger...but I don't have Snow Leopard and don't think I'm going to buy it in the short or medium term (as my main desktop is Ubuntu) [00:08] verterok: cool. As long as the code for the installer is available, I'm sure someone will step up and do the Snow Leopard build. [00:09] spiv: ok, thanks for the pointer [00:09] In the worse case, I have a copy (which might work in a Parallels VM) [00:09] igc: I'm using jfroy's package branch as with that approach was quite easy to get it working :) === tommieb is now known as t0mm13b [00:10] igc: also I added some infrastructure to make it compatible with all supported OS X versions ;) [00:11] verterok: sounds very promising. I'm sure we'll have a heap of OS X users take up Bazaar once Explorer can be easily installed [00:12] making a bundled version of Explorer shouldn't be terribly hard I think [00:12] jfroy|work: bundled? like a standalone "bzr.app"? [00:13] yeah [00:13] that's what we should go for [00:13] guessing widely, either you can use a shell script doing "bzr explore" as the bundle's main executable [00:13] jfroy|work: I have been trying to build such beast using py2app, without much success. but I have a CLI only bzr bundle working [00:13] or setup a small C program that loads up the interpreter and kicks off the command [00:14] jfroy|work, igc: the main issue I think is some bug in python 2.5 subprcoess module that makes explorer and Qbzr unusable :( === lamont` is now known as lamont [00:15] cute [00:15] jfroy|work, igc: I keep getting: [Errno 4] Interrupted system cal [00:15] *call [00:16] each time I click in any button of explorer :( [00:24] igc, jfroy|work: I just pushed my branch, isn't finished yet but works for me (tm): lp:~verterok/+junk/OSX-package [00:24] * verterok needs to run, bbl [00:24] later! [00:25] bye === BasicPRO is now known as BasicOSX [01:27] igc, i'm planning to fire the announcement today [01:27] and then... should i tweak the web site more, or leave it to you? [01:27] poolie: cool. Got KDE screenshots overnight so I'm just uploading a KDE tour now [01:28] poolie: I'm happy for you to tweak the website from here [01:28] ok [01:28] i think my next thing would be to either get the fonts working [01:28] s/working/the right size [01:29] though that might be better left to someone who knows what they're doing :) [01:29] or to change it to be templated, so that we can add some dynamic content [01:29] templated would be good [01:30] I think we're better to leave the font tweaking to web designers myself [01:30] it's fiddly [01:39] right [01:39] spiv, hi? [01:47] poolie: hey [01:47] poolie: had a good trip home? [01:55] yes thanks [01:57] igc, is it really worth having totally separate tours for every environment? [01:57] is it the same content and just different screenshots? [01:57] poolie: content is 95% the same but there are differences [01:58] poolie: people like to see programs running in their environment [01:59] and its the best way IMO to drill home the cross-platform message [01:59] ok [01:59] poolieL I still see lots of comments on IRC like "explorer is only for Windows isn't it" [01:59] so I want to put that to bed forever [02:00] i was wondering if one document showing multiple systems would get that across more effectively [02:00] if people land on the windows one they might still be confused [02:01] the fist paragraph in every tour points to the others [02:02] first [02:08] spiv is there a master bug for toomanyconcurrentrequests masking other errors? [02:10] poolie: bug 429747 is the closest, I think. [02:10] Launchpad bug 429747 in bzr "errors during cleanup mask underlying errors" [High,In progress] https://launchpad.net/bugs/429747 [02:14] how did you get along with that bug last week? [02:33] If I tried an upgrade and it fails, how do I restore the original version? [02:35] quidnunc: mv .bzr bzr.broken; mv backup.bzr .bzr [02:45] poolie: so the only_raises decorator appears to work well. The test fallout from applying it to various unlock methods was pretty minimal. [02:45] ok [02:46] I've pushed up an update to that which adds a brief section to HACKING which tries to explain when to use it, and which exceptions to allow when using it. [02:48] poolie: I get "ERROR: No repository present" after doing that (bzr log) [02:49] k [02:49] what else is new with you? [02:50] what's in your .bzr now, quidnunc? [02:50] poolie: branch, branch-lock checkout, backup.bzr, branch-format, README, repository.backup [02:52] quidnunc: really? is this with an old bzr perhaps? [02:53] anyhow it looks like you have to restore repository.backup to being just 'repository' [02:53] poolie: dunno: bzr://rudel.bzr.sourceforge.net/bzrroot/rudel/trunk [02:53] inside .bzr [02:53] poolie: Thanks, that seemed to work [02:53] i hope to work on making upgrade smarter soon [03:57] poolie: https://bugs.edge.launchpad.net/bzr/+bug/437626 has me stumped [03:57] Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [Critical,Confirmed] [03:58] ah [03:58] me too a bit, i've never seen that message before [03:58] lifeless and I wrote the code with that assertion. [03:59] so it's all you fault [03:59] *your [03:59] Hmm... [03:59] ;) [03:59] idnar: :) [03:59] I wonder if that assertion requires a stacked target to occur, which would suggest stacked branches locally. [04:00] so [04:00] can you reproduce it? [04:00] Hmm, yes, it's triggered by the target.. [04:00] No, although I wasn't trying with stacking locally. [04:01] Although it would be a bit weird for "bzr branch" to produce a stacked branch locally. [04:01] I mean, it's possible to make that happen, but I'd be surprised if people had actually configured that. [04:02] I wonder if it's something like: "make shared-repo; make branch in it stacked on launchpad; make branch a new branch from launchpad". [04:03] i.e. perhaps doing a fetch for a non-stacked branch into a repo that was previously only used for stacked branches causes this? [04:06] oh, because it's creating effectively a situation with lots of ghosts? [04:06] because the repo is kind of hollow underneath the other branches? [04:06] could be [04:07] Yeah. [04:07] Just trying to reproduce that now. [04:09] * spiv blinks at the *five* bzr+ssh connections bzr branch --stacked -r1000 lp:~ubuntu-core-dev/upstart/ubuntu reports. [04:19] ! [04:19] not so hot [04:21] impressive [04:26] * igc lunch [04:43] If an Ubuntu mirror is out of date, is there a central place to report that to? [04:56] afc, probably, but i don't know it off hand [04:56] maybe mirrors@ubuntu.com [05:18] poolie: k [07:42] sending announcement soon... [07:51] It would really be better if the "Bazaar Explorer" thing wasn't used in the same sentence as "GNOME" on your website, as it not a (HIG compliant, GTK based) GNOME application. [07:56] Lots of hail. [07:58] hi all [07:59] poolie: yeah for annoucement :) [07:59] hello bzr 2.0 [08:00] spiv: fun tip: if you throw an appropriate base image from Terry Hills radar into the Weather Applet's Preference -> General Tab -> "Enable radar map -> Use custom address for radar map" Address field, say http://www.bom.gov.au/radar/IDR714.gif its [08:01] spiv: automatically & always there when you pop up the weather Details dialog [08:01] 2.0.0 is announced! Hooray! it's finally happens [08:01] somebody, adjust topic of the channel please [08:02] And it should even be in testing tonight :-) [08:04] in testing? what? [08:05] squeeze [08:05] AfC: thanks! [08:07] * bialix singing and dancing === visik71 is now known as visik7 [08:50] bialix: pypi updated too btw === igc changed the topic of #bzr to: Bazaar version control system | 2.0.0 is out! | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ [09:17] what I would like, in bzr [09:17] is a way of pulling all of my trunk branches when I come online [09:18] jml: yeah, that would be nice [09:19] such a plugin would actually be quite simple [09:19] I mean, having a single command to do this would be quite simple. [09:19] jml: I guess you could put a shell script in /etc/network/if-up.d/... [09:19] hmm [09:20] There's probably a more desktop-oriented way to do the same thing that would actually run as your user. [09:20] Presumably triggered off a dbus event. [09:20] I know that empathy does stuff in reaction to online/offline state changes. [09:23] jml: jam wrote a update-mirrors plugin you could use as a starting point [09:23] * igc dinner [09:24] igc, thanks. [09:24] Hey peoples of the Earth, if I put this in Launchpad's identi.ca stream does it make sense? "Yet more congrats to the Bazaar community! Bazaar 2.0.0 is now out! If you haven't already, try the new default repo format, 2a -- zoooooom!" I'm thinking particularly wrt the 2a format comment, obviously. [09:25] mrevell: by "make sense" do you mean "is it accurate", or "is it appropriate"? [09:26] spiv: accurate [09:26] spiv: Happy also to take comments wrt how appropriate it is, though :) [09:26] It seems accurate to me, but I'm not enough of a microblogging user to know if people following @launchpad would mind it or not. [09:27] I'd possibly not mention "2a" by name, just call it the new default repo format. I'm not sure why I say that, though :) [09:28] I guess because users shouldn't have to care about that sort of jargon. [09:28] spiv: Yeah, won't mention "2a" by name. As for whether people will mind, I think it'll be fine. I tweeted/dented the new bzr website and got a thumbs up back. [09:28] cheers sp [09:28] cheers spiv [09:28] mrevell: LP users may also be interested in the "visual tours" we've put together in the last few days. See http://doc.bazaar-vcs.org/explorer/en/index.html [09:29] Ah, thanks igc. I was planning to blog about bzr 2.0.0 on the LP blog ... I'll mention the visual tours there too. ta. [09:29] mrevell: there's tours for GNOME, KDE, Windows and Mac OS X so that should help communities encourage casual contributors [09:29] ah, very cool [09:29] mrevell: I suppose squeezing in a tiny URL to a 2.0.0 tour or release notes would be good too. [09:30] spiv: Yeah, good point. I guess I can lose the "zooom" :) [09:33] mrevell: Aw, I liked the the zooom! :) [09:34] spiv: heh :) I've changed it to "Bazaar 2.0.0 is now out -- congrats to the bzr community! The new default format gives faster & smaller repos - zoooooom! http://is.gd/3ZZ78" [09:34] mrevell: :) [09:34] Okay, cheers guys, posted. [09:55] igc: many thanks === doko__ is now known as doko [11:08] So, 2.0 is out, so when people say "bzr is much slower than hg and git", we can say "no, not anymore with 2.0". [11:08] Congrats for the release BTW. [11:08] But where are the benchmarks we can point people at so they'll at least consider it? [11:09] I'd love to be able to say more than just "trust me, it's fast now, yes, I know I it's the 5th time I say that" [11:15] Hmm, with 2.0 out, I might consider switching to packaged bzr instead of running bzr.dev [11:15] congrats guys === Noldorin_ is now known as Noldorin [12:44] ddaa: I'm still having the feeling that the periodical repacks take too long. But maybe my hardware is too old. [12:47] Lo-lan-do: are you running 2a? [12:47] Lo-lan-do: and are you talking local or remote? [12:47] I am. [12:47] Local. [12:47] Lo-lan-do: and do you have the C extensions? [12:47] {2a is the format, not the bzr software version} [12:48] Don't know. Do the debs have them? [12:48] they should [12:48] if you have 2.0.0 it will nag if they don't [12:49] It doesn't seem to be complaining. [12:50] http://paste.debian.net/48296/ [12:54] lifeless: Does that sound extreme to you? Maybe it's some misconfiguration on my side… [12:56] Hm. A bzr pack of a similar repo only using rich-root-pack on faster hardware happens in 15 seconds. I guess my desktop PC is to blame. [12:57] * Lo-lan-do tries to compare with really identical repos [12:57] Lo-lan-do: rich-root-pack and 2a times are not comparable [12:58] Yeah, which is why I'm scping the 2a repo to the fast server. [12:58] It only has bzr 1.16.1 though. Another skew. === kiko is now known as kiko-phone [13:08] Lo-lan-do: so, 3 minutes, how many revs? [13:09] Lo-lan-do: or, how big is .bzr/repository/packs [13:09] Lo-lan-do: and note that autopack *doesn't* do as much work as 'bzr pack' === Noldorin_ is now known as Noldorin [13:10] 7662 revisions, 67M [13:10] Good to know. [13:16] Hm. 1.16.1 with better hardware does the bzr pack in 1m25s on modern hardware. Better. [13:17] Is it expected that branching from a rich-root-pack repo into a 2a one is slow too? [13:25] jelmer: you about? [13:39] Lo-lan-do: yes, doing that has to convert all the data. It's basically the same as doing "bzr upgrade". [13:42] I see. [13:42] Ah yes, 2a to 2a is indeed *much* faster. [13:42] I can live with that :-) [13:42] Right, because it can simply copy most of it, rather than needing to extract and re-compress everything. [13:43] (And extract from a slower format...) [13:44] * Lo-lan-do waits for everyone to have a 2a-capable client [14:02] * Lo-lan-do reads /etc/bash_completion.d/bzr.simple [14:02] Would it make sense to cache the results of bzr commands? [14:03] I doubt it, for most of them [14:03] Er, sorry, missing quotes. [14:03] Would it make sense to cache the results of "bzr commands" (for completion)? [14:03] "bzr help commands" you mean? [14:04] Yes [14:04] that sounds reasonable to me [14:04] however, plugins. [14:04] Yes, and upgrades and so on. [14:05] for upgrades I'd expect just checking the mtime of the bzr executable used to suffice [14:05] I guess I could stat /usr/bin/bzr and expire stuff, but it doesn't handle plugins. [14:05] but I haven't thought about that very hard :) [14:05] for plugins you could similarly track the contents of the plugins directories, but that's not entirely trivial and may not always suffice [14:06] I'm thinking about a dpkg trigger that would regenerate a static file when installing/removing a bzr* package, but it wouldn't handle locally-installed stuff. [14:06] I would cache within a shell lifetime, I'd hesitate to cache longer than that [14:07] Lo-lan-do: it also wouldn't handle optional deps being added or other such things; the list of commands is turing complete [14:07] Yay. [14:07] and for locally-installed plugins you'd have to recursively check if any subpackages got their files updated, iiuc. [14:08] Right. I'll probably go the simple way and cache within the shell's lifetime. === mrevell is now known as mrevell-lunch === Toksyury1l is now known as Toksyuryel === mrevell-lunch is now known as mrevell [15:41] I always type 'bzr commit -am "commit message"' when I'm switching between git and bzr a lot. I wish it didn't error. [15:41] (bzr: ERROR: no such option: -a) [15:42] see that git is doing to your branch? :) [15:42] meh [15:42] *brain [15:43] it's hard to NOT type branch in this channel [15:43] michaelforrest: I rarely use git, but iirc you mean you want bzr commit to accept and ignore -a? [15:44] can't you somehow set git to use -a by default? [15:45] mzz: yeah something like that - I'd rather have git accept and ignore -a than set git to do -a by default [15:46] (for some reason...) [15:46] (maybe because I'm more likely to do incremental commits from the command line with git, whereas I'd use bzr qcommit to do incremental commits with bzr) [15:47] maybe that's crazy though. it would probably better to change git's defaults as per luks' suggestion.. [15:48] I don't remember how difficult it is to write a bzr plugin that'd do this [15:48] pretty easy [15:50] having a go at writing a plugin... [15:53] an evil version would be http://paste.pocoo.org/show/143301/ [15:54] but yes, it is crazy :) [15:55] michaelforrest, you want to add all files and commit? [15:56] beuno: I just don't want the error when I accidentally type -am instead of -m [15:57] beuno: I will have to risk bzr suddenly adding a command -a that does something very different to what git does (please let's not let that happen ;) ) [15:58] michaelforrest, creating a plugin that adds -a and does nothing should be very close to trivial [15:59] beuno: yeah that's what I'm doing. [15:59] beuno: my plugin is called "git_cushion" [15:59] have you seen the code I pasted? [15:59] michaelforrest, "lol" [16:00] surely it's not nice, but I'm not sure if it's worth creating a nice solution for this [16:00] michaelforrest, let me know if you need help [16:00] luks: yeah first I tried using my brain but then I just pasted your code in and it worked :) [16:00] plugin created. [16:00] sweet. [16:39] bug 440631 [16:39] Launchpad bug 440631 in bzr "mutable_tree.has_changes() should not take a parameter but always check against basis" [Medium,Fix committed] https://launchpad.net/bugs/440631 [16:40] vila_: I find the description a little brief; perhaps paste in IRC conversations or something? [16:41] lifeless: ouch, you're in Sydney ? [16:41] montreal [16:42] haa, you scared me :) [16:42] as per my mail last week or so ;P [16:42] yeah, sorry, I remember now, I'm just bad at connecting dates and mails [16:42] ..unless I use my agenda that is :) [16:46] lifeless: updated === kiko-phone is now known as kiko [17:04] vila_: about 405745 - I thought there was no client thread in test_http_impl_urls? [17:05] crisb: ..... [17:05] but you were talking about two threads no ? [17:06] ooooh, waitaminute [17:06] one main thread and one thread for the server, [17:07] crisb: the server is blocked in select(), the main thread blocks on close() ? [17:07] must be! [17:08] crisb: but what is the python interpreter doing ? [17:08] vila_: how do you mean? [17:09] if they are only two threads python is supposed to give control to one... === vila_ is now known as vila [17:10] now, the "dirty" part is that we are closing the socket from the main thread why the server is listening in the other thread... Does the police check such things ? [17:10] the code police I meant [17:10] * vila don't want to trigger NSA loggers... [17:10] vila_: well the trouble is when I invoke pdb by sending SIGQUIT it causes the server thread to exit as select() returns, so I only see the trace from the main thread [17:11] vila_: but attaching with dbx I can see both of them hanging around [17:11] crisb: yeah, the bug don't want to be observed... Schroedinger ? [17:12] It's just shy. [17:12] crisb: that's unknown territory to me but are you saying that you can see the python interpreter going in circles without releasing any of the threads ? [17:12] vila: yes its blocked on close() and select() [17:13] I can understand blocked on select(), but not on close(), anything relevant from dbx ? [17:14] wait a minute, what bzr version do you use exactly ? What code is before close() a simple shutdown(RW) or ? [17:15] this is bzr 2.0.0 === beuno is now known as beuno-lunch [17:15] morning all [17:15] hey vila, are you around? [17:16] my right eye is writing a unit test for has_changes while my left one discuss the AIX hangs on server.close(), I'm all ears to you though :) [17:16] vila: and its using shutdown(RWRD), but i've tried changing it to just RW [17:16] vila: just wondering about the status of https://code.edge.launchpad.net/~vila/bzr/selftest-fixes/+merge/10364 [17:16] (this is the --parallel stuff you were working on) [17:16] crisb: no no, I meant a full shutdown, so both read and write [17:17] I'm trying to par the review queue down a bit, and that is "needs fixing" from Robert but "needs review" overall. [17:17] vila: yes thats the original code [17:18] jam: yeah, interrupt level 3 or 4, I need some setup for ec2 and I want to test ec2 by installing a windows host and I want a local windows host first, which is progressing sllloooowwwllly [17:18] crisb: all right, so I don't understand why it accepts to shutdown (not blocking) but not to close... [17:18] vila: so should I mark it "Work in Progress" ? [17:19] and shutting the socket down should also unblock the select [17:19] (sorry about the interrupt levels, I've been there myself) [17:19] jam: good idea, I'll do if you don't [17:19] done [17:19] jam: thanks [17:21] vila: yes, plus looking at netstat and lsof output, the socket is still in LISTEN state! [17:24] anyone know if there are any other sites for hosting open source bzr repositories besides launchpad? [17:25] crisb: so something is wrong there.. can you see the comment in TestingHTTPServerMixin.tearDown ? [17:26] Pilky: I thought Sourceforge and Savannah both would let you push code up. Certainly any sftp or ftp locations could be used. [17:26] I'm not sure how much integration they have with code browsers, etc. [17:26] vila: yep! [17:27] crisb: it's as if your python didn't realize it uses the same socket in both threads and can't propagate the shutdown from the main thread to the server thread.... [17:27] jam: I've used sourceforge before and it has similar issues to launchpad and savannah looks like it might be the same from first glance === davidstrauss_ is now known as davidstrauss [17:28] I'm looking more for something with the simplicity and usability of github/bitbucket [17:28] Pilky: "similar issues" ? [17:29] usability issues [17:29] care to be more specific? [17:29] Pilky: fusionforge has a bzr plugin now [17:30] Slightly more usable than sourceforge and savannah, even :-) [17:30] well basically I feel launchpad shows too much on each page without good separation, overcomplicates things and is just generally not easy to navigate or administrate [17:31] jam: it's improved a lot over the past year or so, but it's still a long way off the likes of github and bit bucket [17:31] Lo-lan-do: I'll take a look [17:31] Doesn't do Launchpad's automated branching/tracking/merging/reviewing, but it has the advantage of being installable :-) [17:33] hmm, seems better, but still not quite what I'm looking for [17:35] vila: the plot thickens! shutdown is throwing ENOTCONN :) [17:35] I might have to look into seeing if it's possible to design a much simpler, more usable UI for launchpad while keeping the current feature set [17:35] crisb: hmm, good, now we know why it's still listening ! [17:36] do it as a side project and then see if the launchpad team are interested in it at all [17:37] Pilky: you probably should write stuff from scratch. Launchpad is massively complex because it intertwines different facets such as bugs, branches, questions, project registry, karma, etc. [17:37] branches can be generated in 3 different ways (code imports, mirrors, hosting), etc. [17:38] crisb: and is self.socket different from None ? [17:38] the reason lp UI is complex is not because lp folks don't know what they're doing, it's because it does something complex. [17:41] vila: yes indeed [17:42] crisb: ..... so it means we can't shutdown the socket before the first connection ? Thats' silly, how can we shutdown a server then 8-/ [17:45] vila: hmm yes. just check the fileno() in select() and shutdown() are the same [17:46] vila: both 5, so its not like the threads havent got the same fd [17:46] Where does bzr get its Platform string from on Windows? [17:50] crisb: I more and more feel that we may be in a dead end here because AIX implements sockets differently... [17:51] Cool, you fixed bzr shelve on Windows with v2.0.0. Thanks devs :) [17:52] crisb: what I'm reading from a google search with "aix socket bug shutdown select" seems to indicate that shutdown() not interrupting select() is considered a bug by many (not sure that include AIX devs though... :) [17:55] crisb: sorry I should leave, can you be there earlier tomorrow ? [17:55] crisb: otherwise just add a comment to the bug with your last experiments... :-/ [17:56] vila: sure, could we not just send the other thread a signal so select() exits? [17:57] Meths: 'import platform' [17:57] crisb: hehe, that's what shutdown is supposed to do ! [17:57] Meths: "platform.platform(aliased=1)" [17:58] it is in the python standard library [17:58] jam: thanks [17:58] I'm not 100% sure where it gets it from, but you could read the code [17:59] vila, crisb: "if sys.platform == 'aix': os.kill(other_thread, SIGHUP)" ? [17:59] jam: you can't kill a thread :-/ [18:00] jam: especially when it is in a blocking call... [18:00] signal.sethandler(SIGHUP, IGNORE) [18:00] or if it's a mailing list thread. [18:00] Even with a Godwin point? [18:00] os.kill(os.getpid(), SIGHUP) [18:00] Damn, /me loses [18:00] signal.sethandler(...) [18:01] "if sys.platform == 'aik': self.knownFailure()" ? [18:01] vila: ^^ [18:02] jam: I'm afraid we'll have to use that yes, but AIUI (crisb can confirm or not) that will be all http tests... [18:03] vila: can you setDaemon() those threads so that it doesn't cause python to block on shutdown? === beuno-lunch is now known as beuno [18:04] jam: they are daemonic threads and that's why we have so many problems with thread/socket leaks [18:06] vila: isnt it naughty to be doing things on the same socket from different threads at once anyway? maybe thats why close() hangs [18:06] jam: at least closing the server thread somehow guarantee that they will be gc'ed later, if we don't close that socket, we exhaust the threads/sockets far quicker, unless you run with --parallel=fork and workaround the problem, but you need some cores.. [18:06] crisb: well, now that it fails, you can say it's naughty :-) But AIX is the first to not be happy with that :D [18:07] crisb: if you are allowed to talk to yourself via a socket, then it seems like it shouldn't be naughty [18:07] you probably shouldn't talk on the same side in both threads [18:08] I suppose it depends if it is considered 'allowed', but certainly it is used in places... [18:08] (such as our test suite :) [18:08] :) [18:08] jam, crisb: the clean way to resolve that will be to have a boolean ste to stop the server and explicitely connect once with a client that explicitly close its socket... [18:08] is it just python that wont let you kill threads? i've used pthread_kill with SIGUSR1 as a way of unblocking other thread before [18:09] crisb: yup, it's python [18:10] crisb: looking here: http://docs.python.org/library/threading.html#thread-objects [18:10] it looks like we have start/run/join, but no kill [18:12] crisb: as jam said :-D [18:12] http://www.velocityreviews.com/forums/t330554-kill-a-thread-in-python.html [18:12] Interesting method [18:12] basically hijacks the system 'trace' functionality to check at every line of execution if the thread should exit [18:13] doesn't sound like it would help with select/shutdown, though. [18:13] jam: indeed :-/ === ossurayynot is now known as tonyyarusso [18:15] but I think having the server loop check a boolean and replacing shutdown() by stop = True, connect(server.address) close() server.close() may work, I'll try that tomorrow [18:15] vila: enjoy your evening [18:15] do you have AIX to check? [18:15] we don't care if neither the client nor the server understand what that last connection is about... [18:15] jam: hehe no [18:16] crisb: I don't think you can provide a VirtualBox VM with an AIX installed don't you ? [18:17] * vila really wants to trigger NSA or IBM lawyers here :) [18:20] from launchpad, it looks like `bzr branch lp:mailman/2.2` should get me mailman's source, but it tells me: "ERROR: Not a branch: /home/kenneth/src/lp:mailman/2.2/" [18:21] kennethd: what version of bzr are you using? [18:21] 0.11.0 (from debian etch) [18:22] is it too old for that format url? is there another format url i can use? [18:22] 0.11 is way way ancient [18:23] kennethd: yes there is, but then your client likely doesn't understand the repository format used [18:23] well, it is debian etch :) [18:23] kennethd: so I'd recommend to upgrade bzr to something released this decade first ;P [18:24] kennethd: you could try backports.org, or just install bzr by hand (you can run it from the unpacked tarball, do run make though) [18:31] ddaa: true, I'll probably have to look into it at some point down the line, got enough stuff on my plate at the moment development wise [18:32] LarstiQ: got 1.5 from the tarball, thanks [18:32]