=== Guests [n=Guest@modemcable193.149-57-74.mc.videotron.ca] has joined #launchpad === jml [n=jml@ppp201-55.lns1.hba1.internode.on.net] has joined #launchpad === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad === doko_ [n=doko@dslb-088-073-122-003.pools.arcor-ip.net] has joined #launchpad === doko_ is now known as doko [01:20] New bug: #89760 in launchpad "In LP Beta: Tabs in the Milestones doesn't work" [Undecided,Unconfirmed] https://launchpad.net/bugs/89760 [01:23] heya, nice report :) [01:23] :) [01:24] hi kiko [01:24] kiko: you are like my laptop ;) [01:24] hey LaserJock [01:24] pochu, it never sleeps? :) [01:24] kiko: my laptop or me? :) [01:24] LaserJock, I will have free slots to give the MOTU bug list attention this week [01:24] doesn't suspend right? ;-) [01:24] rejoice! [01:25] kiko: awesome!! [01:26] kiko: thanks! [01:28] I am today finishing a report which is, oh, THREE MONTHS late [01:28] this will be a big weight off my back [01:28] phew! [01:29] and I thought I had problems with a report 4 days late :) [01:30] ajmitch!! [01:30] yessir? [01:33] ajmitch is the man [01:34] that he is [01:34] hm === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad === jkakar [n=jkakar@204-174-36-228.unknown-dhcp802.dsl.ucc-net.ca] has joined #launchpad === pochu [n=pochu@ubuntu/member/pochu] has joined #launchpad === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad === freet15 [n=freet15@61.149.0.107] has joined #launchpad === jkakar [n=jkakar@204-174-36-228.unknown-dhcp802.dsl.ucc-net.ca] has joined #launchpad === beuno [n=martin@201-212-211-217.cab.prima.net.ar] has joined #launchpad === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #launchpad === thumper [n=tim@125-236-193-95.adsl.xtra.co.nz] has joined #launchpad === mdz [n=mdz@cpe-76-173-8-128.socal.res.rr.com] has joined #launchpad === merriam [n=merriam@85-211-206-159.dyn.gotadsl.co.uk] has joined #launchpad === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === jordi [n=jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #launchpad === jkakar [n=jkakar@204-174-36-228.unknown-dhcp802.dsl.ucc-net.ca] has joined #launchpad === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad === hacked_kernel_ [n=hacked_k@196.202.91.249] has joined #launchpad === kiko is now known as kiko-zzz === poolie [n=mbp@ppp245-86.static.internode.on.net] has joined #launchpad === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad === stub [n=stub@ppp-58.8.5.145.revip2.asianet.co.th] has joined #launchpad === jml [n=jml@ppp201-55.lns1.hba1.internode.on.net] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #launchpad === Bhaskar [n=Bhaskar@202.79.37.177] has joined #launchpad === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === mtaylor [n=mtaylor@202.160.26.205] has joined #launchpad === freet15 [n=freet15@61.149.0.107] has joined #launchpad === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === jkakar [n=jkakar@204-174-36-228.unknown-dhcp802.dsl.ucc-net.ca] has joined #launchpad === jkakar_ [n=jkakar@204-174-36-228.unknown-dhcp802.dsl.ucc-net.ca] has joined #launchpad === poolie_ [n=mbp@ppp245-86.static.internode.on.net] has joined #launchpad === carlos [n=carlos@163.pool85-48-166.static.orange.es] has joined #launchpad [08:19] morning === Fujitsu waves to carlos. === ddaa [n=david@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === jkakar_ [n=jkakar@204-174-36-228.unknown-dhcp802.dsl.ucc-net.ca] has joined #launchpad === jkakar_ [n=jkakar@204-174-36-228.unknown-dhcp802.dsl.ucc-net.ca] has joined #launchpad === mholthaus__ [n=mholthau@173.153.78.83.cust.bluewin.ch] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === Starting logfile irclogs/launchpad.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #launchpad === Topic for #launchpad: Launchpad users and developers | Next user meeting: Wed 7 March 2007, 1700UTC | Next developer meeting: Thu 8 Mar 2007, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 === Topic (#launchpad): set by mrevell at Fri Mar 2 15:16:04 2007 === bigjools [n=bigjools@82-71-93-249.dsl.in-addr.zen.co.uk] has joined #launchpad === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === jinty [n=jinty@64.Red-83-50-216.dynamicIP.rima-tde.net] has joined #launchpad === mooey [n=chris@217.151.110.115] has joined #launchpad [10:24] how do I get to a non-beta URL ? [10:24] I need to tell someone how to do something with regular launchpad [10:25] but it keeps redirecting, so I cant see what that looks like [10:25] lifeless: go to launchpad.net root [10:25] and click "disable redirection" === dneary [n=dneary@mne69-9-88-163-116-163.fbx.proxad.net] has joined #launchpad [10:27] Hi all [10:28] I uploaded a .pot and a bunch of .po files on Friday, they're listed as Accepted, but there are no translations on the branch in question - anyone know why that might be? [10:28] (for the 2.1 branch of qtwengophone) [10:28] carlos: danilos: ^ [10:29] dneary: the problem is that we didn't implement a way to give priority to those imports over Ubuntu ones and we are opening Feisty for translations right now, so the amount of files to import is huge.... [10:30] ddaa: thanks! [10:31] carlos: Ah, OK [10:31] I didn't understand that Friday, but I get it now [10:31] carlos: Isn't that a flaw in the system, though? [10:31] yeah, that's why I said 'we didn't implement...' [10:31] It makes us non-Ubuntu projects feel like second-class Launchpad citizens [10:32] OK, thanks [10:32] well, it's not that Ubuntu has priority [10:32] it's just that we are importing a lot of files at the same time [10:32] it's just that it's first come first served [10:32] and that ubuntu is a very big guy with a very large plate [10:32] ddaa: right, thanks === Gwaihir [n=Gwaihir@mail.foredil.it] has joined #launchpad [10:34] OK [10:34] dneary: the idea is give non ubuntu projects priority over Ubuntu, so this kind of huge imports doesn't affect you [10:34] Any idea when the ETA for those imports to be finished is? Can you see the state of the queue? [10:34] https://beta.launchpad.net/translations/imports/+index?target=all&status=APPROVED&type=all [10:34] https://launchpad.net/translations/imports/+index?target=all&status=APPROVED&type=all [10:34] Will they be done by Wednesday? [10:34] sorry, use the second link [10:35] that's how the queue is atm [10:36] https://launchpad.net/translations/imports/+index?target=products&status=APPROVED&type=all [10:36] Woohoo! I'm first in the queue [10:36] dneary: I hope, I'm asking some DB magic to mitigate the problem as it's taking much more time than expected but at current rate, it would still take a couple of days [10:36] But I have no idea where I am in the "all files" queu [10:36] dneary: for products, yes ;-) [10:36] the problem is that the distros queue is the same [10:37] dneary: I guess you are near the end of the queue [10:37] it's sorted by date [10:37] carlos: I also uploaded a .tar.gz of .po files through https://translations.launchpad.net/wengophone/2.1/+translations-upload - but I don't see them in the queue [10:38] dneary: If you used that URL, the files are pending to be approved [10:39] Yes, I see them: https://launchpad.net/translations/imports/+index?target=products&status=NEEDS_REVIEW&type=all&start=75&batch=75 [10:39] I have a quick question - how do people manage merges between Launchpad files and their files? [10:40] cron jobs? [10:40] Regular manual imports/exports? [10:40] How do you handle the string changes in svn conflicting with translations in launchpad? [10:40] right now?, manual exports. To do uploads, some use scripts (like the ones I think you were testing) [10:40] carlos: Yeah - I don't think that the scripts are very effective [10:41] And we also script downloads [10:41] Using a regexp on webmail :) [10:42] well, the thing is that the maintainers should cope with those conflicts as we recommend to point to Rosetta as the place to publish the .po files. You can download and then upload the file later without using the web translation form. [10:42] having two persons translating one on svn [10:42] and another in Rosetta [10:42] is a source of conflicts [10:42] either both use SVN or both use Rosetta [10:43] dneary: we are planning a better way to integrate translations with source trees (other than current mechanisms) but it's still in design phase [10:45] f [10:50] New bug: #89833 in malone "+editstatus entry point surprising" [Undecided,Unconfirmed] https://launchpad.net/bugs/89833 === jelmer_ [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad [11:02] reviewer meeting now [11:02] i'm here [11:03] I'm here. [11:07] == Agenda == [11:07] * Roll call [11:07] * Next meeting [11:07] * Queue status. [11:07] ok [11:07] spiv: ? [11:07] SteveA: ? [11:07] jamesh: ? [11:08] I'm here. [11:08] Ah, lifeless just phoned. [11:08] His net connection is down. [11:09] So I guess I'll run the meeting in the meantime. [11:09] SteveA: still recovering from the flu, I guess? [11:09] jamesh: here? [11:09] spiv: yeah [11:09] jamesh: don't labour too hard :) [11:10] Ok, next meeting... [11:10] its just come back [11:10] Ah, great. === spiv stands aside [11:11] thanks though! [11:11] Not a problem. [11:11] so, we're splitting the meetings in two === xerosis [n=kieran@87-194-21-125.bethere.co.uk] has joined #launchpad [11:11] I propose the .au themed one be 4pm (GMT+11) which should be within Bjornt's working hours [11:11] Yes please! [11:11] and if BjornT can be kind enough to attend both, we can keep consistency. [11:12] if thats too early for BjornT, then 5pm(GMT+11) [11:12] BjornT: what do you say? [11:13] lifeless: au 4pm is 7am for me, so i'd prefer 5pm [11:13] np [11:13] That's fine with me. [11:13] all in objection, type something now [11:14] BjornT: please coordinate a time with the non .au reviewers that is convenient for you, and update teh https://launchpad.canonical.com/ReviewerMeetingAgenda?action=edit with that [11:14] lifeless, BjornT: thanks! [11:14] lifeless: sure [11:14] BjornT: are you willing to chair that meeting? or just be present ? [11:15] lifeless: i can chair the non-au one. [11:15] cool! [11:15] ok, queue status (one second while I note this down) === jamesh has to finish off salgado's one [11:17] jamesh: can you look at david/launchpad/complete-revisions-landing - the review metadata for it [11:17] jamesh: I think its not 10 days old, and something fishy has happened [11:17] and yes, yes you do [11:17] lifeless: he probably backdated it when adding it [11:17] lifeless: or changed the URL [11:18] you also have a branch of marks, and flacoste has a branch of tims that are getting old [11:18] BjornT: can you nag flacoste :) [11:18] sure :) [11:18] spiv: your branches - how are they looking ? [11:18] specifically flacoste-.. [11:19] jamesh: have you landed my patch to the pending-reviews yet ? [11:19] I only have one :) [11:19] I'll do flacoste's tonight. [11:19] lifeless: not yet [11:19] spiv: you'll have more for tomorrow :) [11:19] jamesh: :(. === lifeless begs [11:19] lifeless: well, I can't comment on that today :) === spiv is starting to think of >500 line branches as large. Must be because smaller branches are increasingly normal! [11:20] thats good [11:21] there are 13 open reviews [11:21] but jamesh is back from sprint now [11:21] and noone else is on leave AFAIK [11:24] are you still doing 2 reviews a day ? [11:25] I have been a bit lax on the 2/day front. [11:25] me too, although i generally review the branches before the get 2 days old. === ddaa is looking at tim's explicit-branch-type [11:26] ok, [11:26] what I'll do for the next week is stack your queues deep [11:26] that way, we wont have the low bandwidth-latency multiplier effect :) [11:26] I think the new folks need some mentoring about focus and small branches... [11:26] +1 [11:27] jamesh: it will help me immensely to deploy my pending reviews update [11:27] lifeless: yep. I'll get onto it tomorrow [11:27] thank you [11:27] thats all from me [11:27] anything new ? [11:28] ddaa: how old is david/launchpad/complete-revisions-landing [11:28] nothing from me === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [11:29] lifeless: put it up for review on thursday [11:29] had been work-in-progress for some time before [11:29] ddaa: you did something strange when you did that [11:29] just moved it around, and changed work-in-progress to needs-review [11:29] ddaa: do you recall what it was ? (Did you change url? change the timestamp?) [11:29] ha, yes, changed url [11:30] complete-revisions -> complete-revisions-landing [11:30] ddaa: please dont do that, the system is primitive and trivially breakable [11:30] made it depend on recent rocketfuel, instead of cherrypickable... [11:30] new url + old timestamp -> looks like its been unallocated for 10 days [11:30] s/cherrypickable/mergeable in production/ [11:31] hu, okay sorry... [11:32] ddaa: so either just make a new entry, or keep the url please [11:33] gotcha, url == id [11:33] carlos: you added your firefox-import branch as needs-review on PendingReviews [11:33] hmm [11:34] sorry, I forgot to change the status [11:34] thanks for the warning === carlos changes it [11:38] thanks for coming, metting over [11:43] spiv: could you take a quick look at the changes in test_acceptance.py in https://devpad.canonical.com/~jamesh/pending-reviews/jml/launchpad/fix-intermittent-test/full-diff [11:43] spiv: just to make sure that the changes look semantically correct [11:45] BjornT: ok, I'll take a look now [11:45] thanks spiv [11:47] BjornT: I don't know why he does joinThread in the deferToThread decorator. It should be redundant. [11:49] BjornT: he never sets _bail_registered to True! [11:51] yeah, i was going to comment on that :), and also propose another way of doing it. [11:51] BjornT: The basic transformation of test_* methods looks sound, though. === dneary [n=dneary@mne69-9-88-163-116-163.fbx.proxad.net] has joined #launchpad [11:52] spiv: ok, thanks. i'll include your comments about joinTread. [11:53] BjornT: please feel free to require lots of explanation about anything that's unclear. I'm familiar with Twisted testing idioms, and also discussed this with jml a fair bit over VOIP, but ideally this should be comprehensible to more than just two people :) [11:54] spiv: i will :) [11:55] BjornT: The trick here is that TrialTestCases allow test methods to return a Deferred to wait for, and the framework will keep running the Twisted reactor until that Deferred is called back. [11:56] yeah. i remember that from having reviewed one of salgado's branches that did the same. [11:56] So now he's running the two twisted services in-process, and waiting for events from them to determine test completion, and to avoid blocking the event loop he's running most of the assertions and bzr client code in a seperate thread. [11:57] Incidentally, jml says that these tests take a minute less to run now they don't need to spawn subprocesses :) [11:58] morning [11:59] I'll probably apply the same sort of changes to the authserver and librarian tests eventually, so they can avoid subprocesses too. [11:59] spiv: and that's the reason for having to run TrialSuite()._bail() at exit? [11:59] The reason for that really deserves a honking great comment. [12:00] That arranges for the Twisted reactor to get shutdown, which in turn means that it's threadpool is stopped. Otherwise, the process hangs indefinitely at exit because of non-daemonic threads. [12:00] there's an XXX that has the beginning of a comment for it, but it doesn't include the end of it :) [12:01] Ah, heh, so there is. === effie_jayx [n=valles@190.37.175.250] has joined #launchpad === jelmer_ [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad [12:20] New bug: #89846 in soyuz "binary ancestry calculation broken for new binary packages" [Undecided,Unconfirmed] https://launchpad.net/bugs/89846 === carlos -> bank === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #launchpad === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [01:00] good morning === bac [n=bac@cpe-065-190-191-245.nc.res.rr.com] has joined #launchpad === CodeDragon [n=none@195.134.12.229] has joined #launchpad === CodeDragon [n=none@195.134.12.229] has left #launchpad [] === TeTeT [n=spindler@modemcable178.77-70-69.static.videotron.ca] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad [01:27] stub, lifeless, SteveA : Ping? gandwana Launchpad Apps Server [1/2] is down. === effie_jayx [n=valles@190.37.175.250] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === Sikavica [n=chatzill@82.114.78.10] has joined #launchpad === kiko-zzz is now known as kiko [01:48] wake up gandwana [01:49] stub, lifeless, Znarl: is anyone else working on gandwana? [01:50] New bug: #89854 in launchpad-bazaar "codebrowse fails with infinite redirections" [High,Confirmed] https://launchpad.net/bugs/89854 === sinzui [n=Curtis@pool-70-18-225-105.res.east.verizon.net] has joined #launchpad [02:14] Hello. I am Curtis Hovey. This is my first day on the Launchpad team. Anyone have a clue-by-4 to point me how I start my day? [02:15] good morning curtis and welcom [02:15] welcome, i mean [02:15] sinzui: welcome [02:16] sinzui: I'm about to go to bed, but bac, SteveA or kiko ought to be able to sort you out. [02:17] sinzui: sure i'll give you a hand [02:17] spiv: thanks. As I thought [02:18] welcome sinzui! [02:19] sinzui: i just sent you a private message -- you see it? [02:20] bac: no :( === sinzui thinks another app is screwy the desktop [02:22] sinzui: you use IM or skype? [02:22] bac: gaim [02:23] bac: my message to you didn't show. back to x-chat [02:23] bac: you're not identified. [02:23] bac: you need to be identified to freenode to send private messages. [02:25] Hobbsee: thanks [02:25] bac: no problem, need help with registering/identifying? [02:26] sinzui: Welcome Curtis. [02:26] kiko: ping [02:26] Hobbsee: yeah i need to take care of that. thanks for the reminder. [02:26] SteveA: hi [02:27] bac: /msg nickserv help should get you started :) [02:27] SteveA: if you want i can help sinzui get started since it's all pretty fresh. [02:32] sinzui: I just send you a standardized "welcome to canonical" message === jamesh [n=james@203-59-195-215.dyn.iinet.net.au] has joined #launchpad [02:32] SteveA: thanks [02:32] bac: sure, that would be great! please do. [02:33] sinzui: what is your AIM id? until i get my freenode nick sorted out it may be best to move over to IM [02:33] bac: CurtisHovey === barr1 [n=barry@216-15-33-253.c3-0.slvr-ubr2.lnh-slvr.md.static.cable.rcn.com] has joined #launchpad === ddaa -> post office [02:40] sinzui: did you get the email? [02:40] sinzui: I got a bounce kinda thing from Verizon saying "UCE not wanted" [02:40] SteveA: yes, I'm reading the wiki [02:41] do you use Verizon? want to see the bounce? [02:41] SteveA: interesting. I Verizon doesn't like kiko either. === carlos -> lunch === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === Sikavica [n=chatzill@82.114.78.10] has left #launchpad [] [02:51] sinzui, your ISP is pretty horrible wrt incoming email. I have never once managed to email you directly :-( [02:52] kiko: I'll look into switching my email though my domain provider. I get more control too === flacoste [n=francis@modemcable252.1-202-24.mc.videotron.ca] has joined #launchpad === sinzui [n=Curtis@pool-70-18-225-105.res.east.verizon.net] has joined #launchpad [03:07] sinzui: you can get a POP3 account for canonical email [03:08] carlos: I see that. I'm writing the request now [03:08] ok === pochu [n=pochu@ubuntu/member/pochu] has joined #launchpad [03:12] moin === bac is now known as BradCrittenden === statik is now known as statik_ === zwnj [n=behnam@213.207.210.231] has joined #launchpad === statik_ is now known as statik [03:27] statik: hello. how was your weekend? [03:28] BradCrittenden: excellent, thanks. I think my brain melted a little from being immersed in another language. how was yours? [03:29] good. nice weather mostly. had a good time. [03:29] sorry for the absurdly long nick. trying to resolve registration on the other [03:35] New bug: #89866 in malone "Search bugs in all projects fails with an UnexpectedFormData error" [Undecided,Confirmed] https://launchpad.net/bugs/89866 [03:46] barr1: ping [03:47] ddaa: pong [03:47] barr1: got some time to talk about pyrex vs. ctypes? [03:48] ddaa: sure. i've only dabbled, but i'll help if i can! [03:49] barr1: I understand you talked about my use of pyrex to bind to libsvn with SteveA at Pycon. [03:49] and that you suggested using ctypes instead of pyrex [03:49] right? === UB` [n=mik@stargate.fastweb.it] has joined #launchpad [03:50] yep [03:50] ctypes is a python 2.5 thing tho [03:50] hi [03:50] So SteveA asked to have a talk with you about it. === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad [03:50] i've a little problem [03:50] I sent a bug message with a log pasted [03:50] barr1: I haven't looked much at ctypes, but the reason I chose pyrex instead [03:50] thing i like about ctypes is that it comes w/py2.5 out of the box [03:51] but there are some security issues [03:51] I have to edit that message [03:51] could you help me? === BradCrittenden is now known as bac [03:51] is that ctypes is ABI-based, you need to somehow embed the definition of the ABI you are in binding to the Python code === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #launchpad [03:51] UB`: file a support request/question on the launchpad product [03:52] pointing to the specific log message to edit [03:52] or tell stub directly [03:52] he's the database admin, and does things like excising stuff out of the db when there is no UI for it. [03:53] could I disturb him in private? [03:53] barr1: while pyrex is API based, you just give it a high-level description of the API, and just as much as you need to bind to, and the compiler deals with the ABI. [03:53] UB`: sure, removing security-sensitive data is reason enough [03:53] thank you === barr1 is now known as barry [03:54] barr1: also, most open source libraries, (including libsvn) really only document APIs [03:55] and inferring the ABI out of the headers files can be a painful exercise [03:55] I understand that ctypes is great when you need to bind to arbitrary windows APIs, where the ABI is known and very stable. [03:55] where a compiler is not generally available, and turn-key operation is essential [03:56] but I'm far from convinced it's a good fit for binding on linux [03:56] barry: your turn :) [03:57] ddaa: interesting. you've obviously looked at this stuff in more detail than i have. i really only mentioned ctypes in passing, but it sounds like you have good reasons to prefer pyrex. the only question is whether that outweighs the benefit of pyrex as an add-on dependency. [03:57] s/benefit/cost/ [03:58] One thing I am assuming so far, is that there is no tool to automatically produce the ABI out of header files. [03:59] that produces something usable by ctypes [03:59] ddaa: i've not heard of anything, but i could make inquiries in the python community if you want [03:59] since libsvn is incredibly anal about ABI compatibility, that would essentially negate my argument against ctype in this case [04:00] barry: I'm interested in any input you may have. [04:01] I'm not strongly committed to pyrex, and it does involve add a lot of cruft (the high-level API description) === pochu [n=pochu@ubuntu/member/pochu] has joined #launchpad [04:01] since the libsvn API is mind-bendingly complex === bac [n=bac@cpe-065-190-191-245.nc.res.rr.com] has joined #launchpad [04:01] i always like to reduce moving parts if possible, especially in favor of out-of-the-box support. would it be useful to do try to do a limited a/b test of the two modules? [04:02] what do you mean "a/b test of the two modules"? [04:02] you probably already have a bunch of pyrex glue -- would it make sense to try to duplicate some of that w/ctypes and evaluate the cost/benefit for this particular application? [04:03] I guess that would provide an interesting data point [04:03] but I have two practical objections [04:04] 1. it's a lot of work that would have to be re-done for simple prospection [04:04] 2. it will not be definitive since the really interesting APIs I want to bind to are not wrapped yet. [04:05] so 2 just means that whatever the result, it will have to be considered with a grain of salt [04:06] and 1 means that I will only be willing to go down that road if there is some hint that it's not going to be a lot of effort, or that it will indeed lead to interesting results [04:06] for any pertinent value of "interesting" [04:06] right. well, istm that you've looked at the technical issues in much more detail than i have, so i'm not sure i can add anything useful ;). i'll be happy to help in any way i can though! [04:06] barry: the point is, I did not look at ctypes much [04:07] most of my argument is based on knowing there is a ABI/API dichotomy [04:07] and having practical experience with the pyrex side of the problem [04:07] so maybe I am entirely misguided :) [04:08] ddaa: what's the best way to get the current pyrex bindings? is there a bzr branch somewhere i can grab? if so, perhaps i can look at that and try to do some ctypes bindings to get a feel for it, though i've never looked at libsvn [04:08] barry: /code/david/cscvs/pyrex on devpad [04:09] it's still very experimental [04:09] cool, thx. i'll also try to do a bit of research on the api/abi issue [04:09] another data point that might be relevant: [04:09] I have no interest in writing a general wrapper for libsvn [04:10] it's more a framework than a library, and it's absurdly generic in some places [04:10] so I am focusing on the simplest wrapper that does was cscvs needs [04:10] ddaa: ctypese can be rather cumbersome, but being pure python is the final win for my opengl uses. [04:11] LarstiQ: here you go :) well defined ABI, portability, no compiler available [04:11] exactly [04:12] ddaa: gotcha [04:12] it also was much easier to get supports vectors out of libsvm with ctypes than with swig === LarstiQ is unfamiliar with pyrex [04:12] LarstiQ: pyrex is like skinning two headed goats using a silver knife under a full moon. === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [04:13] it's scary and weird at first, but it does grow on you after a while [04:13] ddaa: all the right conditions then [04:14] which interestingly, is the opposite of svn, which is friendly and comfortable at first, but sends you mad after a while. [04:14] ddaa: lol [04:14] oops... sorry, did it again... [04:16] LarstiQ: swig? OMG [04:16] the native libsvn python bindings are done using swigs === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [04:16] ddaa: current libsvm binding is written in that [04:16] or, with [04:16] current? [04:16] extending it is painful [04:16] official [04:16] ddaa: right [04:16] it's pretty much unmaintained [04:17] except for the bits that jelmer had to beat into compliance to get actual work done... [04:17] no no [04:17] libsvm != libsvn [04:17] ... === LarstiQ works with support vector machines ;) [04:17] btw ddaa: this kind of came up because of talks for bridging the svn/bzr gap. i wanted to try the svn plugins for bzr, but found the mass of stuff i had to install and compile from source on my mac was just overwhelming [04:18] barry: pretty much directly caused by upstream bindings being a steam pile of unmaintained swig insanity. [04:18] (my thinkpad was running some feisty daily build and was having trouble getting on the network at pycon) [04:18] ddaa: yep [04:18] which is largely why I'm getting into this whole mess to start with [04:18] got no trust in upstream to maintain those bindings [04:18] how did pycon go? [04:19] ddaa: anything to make that mass easier to deal with [04:19] LarstiQ: best one evar [04:19] almost 600 people [04:19] i'd say 50-100 sprinters after the conference proper ended [04:20] barry: actually, the original cause was "I tried to fix the upstream bindings, but they broke me". [04:20] ddaa: ;} [04:20] steel pot / clay pot thing [04:20] barry: cool [04:21] ddaa: even though you can apt-get the bzr-svn plugin, it doesn't work. building from source is a soul crusher [04:21] *nod* [04:21] ddaa: the high level goal is this: several projects wanted to explore bzr but have their code in an svn repository, and have devs who don't live and breath revision control systems [04:22] mh [04:22] I can see how ctypes would be a good fit there. [04:22] so what we want is something that will look and smell exactly like "svn" client to those devs while others can experiment with bzr, eventually touting the benefits, teaching others how to use it, and then eventually migrating them to use the bzr client [04:22] provided there's something to help bridge the API-ABI gap. [04:23] we talked about a bunch of alternative approaches, but i think they all had problems. stevea mentioned something (i forgot the term) but a bzr server that also speaks svn [04:23] bzr-svn is great. It got an amazing potential for getting through the back door. [04:24] bzr-svnserve is also useful [04:24] ddaa: i tend to think that would be idea because it wouldn't require moving the repo to start the transition [04:24] it needs a lot more work though [04:24] sorry, bzr-svn would be ideal i think [04:24] but there's a whole spectrum of embrace-extend-bzrminate tools [04:25] barry: completely agree [04:25] and I agree that ctypes is what would be best to make bzr-svn rock [04:25] yep. it's definitely worth working on because i think there's a lot of interest in bzr, but also a lot of reluctance to just make the switch, especially because many projects have recently gone through a cvs->svn migration [04:26] that's a lot of upheaval for a dev community [04:26] yeah === LarstiQ marks svnserve up for the bzr GSoC list [04:26] barry: you're preaching to the converted [04:27] :) [04:27] 1. bzr-svn to get the committers to switch to bzr one by one [04:27] 2. bzr-svnserver to switch the server to bzr without bothering non-committers [04:28] actually makes it a winning proposition for us to have big projects switch to svn [04:30] barry: so, yeah. If you can come up with a practical way to bind to libsvn with ctypes, I'm willing to put my cscvs effort behind it. [04:30] there's sort of two (or three) propaganda points you have to win: first, convince people that the 'd' in dvcs is a fundamentally better way to operate; 2) that it's worth the overhead to learn a new model and set of commands; 3) that you won't lose anything by switching (i.e. it's a pure win), and 4) bzr is as mature and stable as svn (i.e. you will never ever ever lose data in bzr) [04:30] might make the cscvs work more costly than it has to be, but it would have a very positive externality. [04:31] ddaa: agreed [04:32] barry: actually, those all four points can go away with bzr-svn because it has the potential to make _trying_ bzr in situation near zero-cost. [04:33] and experience shows than in any given project of significant size, you'll find at least one influential developer willing to try a DVCS. [04:33] but often it's prevented by the interoperability watershed [04:33] ddaa: agreed, although at some point you want people to move their data into bzr and turn off their svn repos. that requires a lot of confidence that your data is rock solid stable (i.o.w. it's part technical part evangelical) [04:34] I think it's mostly (but not quite) a red herring. [04:34] ddaa: another data point: we keep all the python.org files under svn (i do the same for all my personal servers). that process has broken down for a number of reasons, so we've switched to bzr for all our etc files [04:35] When people love and want to use a tool, they pretty much want to be convinced that switching is safe. [04:35] ddaa: agreed! [04:36] and as long as it's relatively speedy, or that whatever performance costs you incur are amortized over all your work (i.e. always branch into a repo) [04:37] speed is another problem, got plenty of solutions and good work is being done [04:37] the new formats are already enabling improvements in bzr-svn performance [04:38] oh, and have you ever tried to put your os system files under svn? what a royal pita. requires you to hand edit .svn/entries files. not fun [04:38] barry: is bzr doing better at that? [04:38] and you just have a handful of nutcases (linus and keithp leading the pack) who argue that a system needs to be designed for speed to be fast enough. [04:39] I think these folks are overgeneralizing their specialized domain knowledge. [04:39] LarstiQ: from what i've read on the python dot org mailing list over the weekend, yes it went much more smoothly. we couldn't put / under bzr because it took too long, but putting /etc under bzr was quite acceptable. and no ugly manual hacks required [04:40] barry: cool. We haven't really focused on supporting it :) [04:40] ddaa: i come from the gvr school of thought on optimization :) [04:40] /etc should be cool, not to wide, and mostly text [04:40]