[04:00] <dupingping> Help me.
[04:01] <dupingping> just a question, ubuntu membership certificate mail is registered mail or common mail?
[04:02] <dupingping> certificate mail's type is?
[07:53] <dholbach> good morning
[08:19] <davidcalle> Morning o/
[08:26] <dholbach> davidcalle, do you think we can try to land all our branches on staging today? :-)
[08:27]  * davidcalle checks if mike hasn't done it already
[08:28] <davidcalle> Nope
[08:28] <dholbach> I made a change in the one branch which mhall119 was alluding to might be good to have, but it didn't get reviewed yet
[08:29] <davidcalle> dholbach, git checking?
[08:30] <davidcalle> dholbach, https://code.launchpad.net/~dholbach/developer-ubuntu-com/1510904/+merge/276111 ?
[08:30] <dholbach> yep
[08:30] <dholbach> I added checks if git and bzr are installed
[08:33] <davidcalle> dholbach, on the staging juju machine running the devportal instance, git is not installed
[08:33] <dholbach> ok - shall I file an RT?
[08:34] <davidcalle> dholbach, no need, it's a mp on the spec, let me look for the time I needed click to be added, it will point us to the right file to change
[08:34] <dholbach> brilliant - thanks!
[08:35] <davidcalle> dholbach, should I add a minecraft server as well?
[08:35] <davidcalle> :D
[08:36] <dholbach> frozen-bubble please :)
[08:40] <davidcalle> dholbach, https://code.launchpad.net/~davidc3/canonical-mojo-specs/mojo-ue-devportal-git-dep/+merge/276225
[08:40]  * davidcalle pings webops
[08:40] <dholbach> nice one!
[08:41]  * dholbach hugs davidcalle
[08:48] <davidcalle> dholbach, I've left an inline comment in your mp
[08:49] <dholbach> davidcalle, I can't see it?
[08:49] <dholbach> ah, now
[08:50] <dholbach> you're obviously riht
[08:50] <dholbach> right
[08:50] <davidcalle> dholbach, my bad I forgot to click save under the empty comment box at the top of the page after editing at the bottom...
[08:50] <dholbach> fixed
[08:51] <dholbach> and before we let it loose and turn it on on prod, we should talk to the snappy folks again and see if they're really interested in us tracking 15.04 and trunk
[08:51] <dholbach> or whatever they're calling it on github now
[08:51] <dholbach> :)
[08:52] <dholbach> but for playing around with it on staging this should all be good enough
[08:52] <davidcalle> dholbach, ok :)
[09:10] <davidcalle> dholbach, git added to the spec
[09:22] <davidcalle> dholbach, "Could not check out branch "git://github.com/ubuntu-core/snappy""
[09:45] <dholbach> davidcalle, maybe a " too much?
[09:48] <davidcalle> dholbach, nope, git clone git://github.com/ubuntu-core/snappy doesn't work either
[09:49] <dholbach> davidcalle, locally or on the machine itself?
[09:49] <davidcalle> dholbach, locally
[09:49] <dholbach> it works for me
[09:49] <dholbach> davidcalle, http://pastebin.ubuntu.com/13007600/
[09:51] <davidcalle> dholbach, oh wait... The office network I'm on could be restricting this call... Even if that would be crazy. /me switches to full vpn
[09:53] <dholbach> davidcalle, tried it from another host where I had never used git before and it works there as well
[09:53] <dholbach> davidcalle_, tried it from another host where I had never used git before and it works there as well
[09:53] <dholbach> davidcalle_, but we might have to ask IS to punch another hole into the firewall
[09:53] <davidcalle_> dholbach, wow...
[09:53] <dholbach> they're blocking it?
[09:53] <davidcalle_> dholbach, yep :'(
[09:53] <dholbach> :-/
[09:54] <davidcalle_> dholbach, that makes me sad for them
[09:54] <davidcalle_> Anyway, back to testing again :)
[09:56] <davidcalle_> dholbach, note that I also need a vpn to access IRC...
[09:56] <dholbach> :-(
[10:00] <davidcalle> dholbach, the importer will need some more changes for snapcraft, I can see an issue with links, and now the snapcraft intro page needs an image, not sure how markdown deals with this (though, I think I've seen images in github projects  READMEs)
[10:01] <dholbach> ok, I'll file bugs
[10:03] <dholbach> https://bugs.launchpad.net/developer-ubuntu-com/+bug/1511676 and https://bugs.launchpad.net/developer-ubuntu-com/+bug/1511677
[10:03] <ubot2> Launchpad bug 1511676 in developer-ubuntu-com "[md-importer] links are broken" [High,Triaged]
[10:03] <ubot2> Launchpad bug 1511677 in developer-ubuntu-com "Figure out how to display images in imported markdown docs" [Undecided,New]
[10:03] <dholbach> I'll start working on the former
[10:03] <dholbach> the latter I think can wait for a bit
[10:05] <dholbach> davidcalle, can we merge the git import?
[10:06] <dholbach> just so it works and is in trunk... we don't necessarily need to enable it right now in prod
[10:10] <davidcalle> dholbach, just one last thing before, I need to update the pip-cache-revno thingy in trunk
[10:11] <dholbach> ah yes
[10:11] <davidcalle> (it pulls all pip packages, will take 10 min)
[10:12] <dholbach> https://code.launchpad.net/~dholbach/developer-ubuntu-com/import-md-just-daily/+merge/276236
[10:12] <dholbach> I placed the cronjob 5 minutes after the store update
[10:12] <davidcalle> dholbach, I forgot to do that yesterday, which means trunk fails by default right now unless you do it manually first
[10:12] <dholbach> but still in the time when most folks are slleeping
[10:12] <dholbach> mh?
[10:12] <dholbach> ah ok ,yes :)
[10:13] <davidcalle> dholbach, new cron acked, will merge it as well in a minute
[10:13] <dholbach> thanks
[10:13] <davidcalle> a vpn-pulling-and-pushing-50-packages minute ;)
[10:16]  * dholbach hugs davidcalle
[10:34] <davidcalle> dholbach, all merged \o/
[10:35] <dholbach> I'm getting closer to fixing the links as well :-)
[10:35] <dholbach> thanks a lot davidcalle
[10:37] <davidcalle> dholbach, do you mind if I send current trunk to staging without links fixed?
[10:37] <dholbach> not at all
[10:49] <davidcalle> dholbach, do you mind filing a rt to poke a hole in duc firewall for github?
[10:54] <dholbach> will do
[10:56] <dholbach> done, I CCed you on it
[10:58] <davidcalle> dholbach, ty! I'm going for lunch with Estelle and kids, I've asked for the devportal tarball to be uploaded at the rigth place for a staging deployment, I'll trigger it as soon as I'm back :)
[10:58] <dholbach> awesome
[10:58]  * davidcalle runs, ttyl o/
[11:10] <dpm> dholbach, what channel are you running on your phone, stable or rc-proposed?
[11:13] <dholbach> stable
[12:08] <balloons> Happy Friday to everyone!
[13:03] <dpm> hey balloons, happy Friday to you too :)
[13:03] <dpm> balloons, do you have a krillin device running on the stable channel?
[13:15] <balloons> dpm, I don't have a krillin device anymore
[13:15] <balloons> I donated it back to the lab
[13:15] <dpm> ah, no worries
[13:15] <balloons> I do have an n4, but it's running rc
[13:15] <dpm> On 15.10 my phone seems to no longer be recognized when plugged it, although it recognizes my nexus 4
[13:41] <dholbach> salut davidcalle
[13:41] <davidcalle> dholbach, hey again
[13:41] <dholbach> I have two things for you :-)
[13:41] <dholbach> https://code.launchpad.net/~dholbach/developer-ubuntu-com/1511676/+merge/276253
[13:41] <dholbach> https://bugs.launchpad.net/developer-ubuntu-com/+bug/1511677
[13:41] <ubot2> Launchpad bug 1511677 in developer-ubuntu-com "[md-importer] Figure out how to display images" [Medium,Triaged]
[13:42] <dholbach> if you look at the MP you'll see that I stole an old idea from you :)
[13:44] <davidcalle> dholbach, ah right, dissociating url and title for links :)
[13:45] <dholbach> if I had called it MAP it would've been a bit more obvious ;-)
[13:45] <davidcalle> Works for me in any case ;) I'm trying to trigger a staging deployment and I'll give a try to ^
[13:47] <dholbach> <3
[13:47] <dholbach> and let me know if you have any ideas on how to implement the image thing
[13:49] <davidcalle> dholbach, I would say: hosting images in the docs dir in snapcraft, and using the proper markdown extension (there is one for images). To have something that would work both and github and d.u.c, with images hosted on github
[13:50] <dholbach> so we'd hotlink to the image on github? or did I misunderstand
[13:50] <davidcalle> dholbach, yes we would
[13:50] <dholbach> ok
[13:51] <dholbach> I'll see what I can do
[13:51] <davidcalle> dholbach, I can have a look at it a bit later
[13:52] <davidcalle> If you don't feel like messing with it :)
[13:56] <dholbach> I'll take care of writing the UOS Core track blog post and confirming everything
[13:56] <dholbach> and if there's time before EOD I'll look into it :)
[14:02] <davidcalle> mhall119, fyi I'm currently deploying duc trunk to staging, I've used the mojo spec branch, are there any fix for the deployment that haven't made it to it yet?
[14:04] <davidcalle> mhall119, also, I've added git to the list of packages we need
[14:05] <mhall119> davidcalle: everything should be in the spec branch on wendigo
[14:05] <davidcalle> mhall119, ok, so not the lp one yet?
[14:05] <mhall119> davidcalle: the spec will now build the devportal tarball and upload it to swift, and deploy it from there
[14:05] <davidcalle> Haha ok
[14:05] <mhall119> no, not the lp one yet, if you can push what's on wendigo to Lp that would be great
[14:06] <davidcalle> mhall119, there are several branches in there, can you point me to the right one? the default "mojo-ue-devportal" ?
[14:08] <davidcalle> mhall119, "build the devportal tarball" from trunk, prod, or a revno of our choosing?
[14:09] <davidcalle> btw, if I understood what you said correctly, not having to get the tarball uploaded is awesome :)
[14:15] <davidcalle> mhall119, from what I gather from the diff (tell me if I misunderstand): Now, I should simply run make on the spec, wait for it to deploy, then juju set build_label {prod branch revno I want}, wait for it to update
[14:16] <mhall119> davidcalle: yes
[14:17] <mhall119> eventually we'll have "make upgrade" working, which will do it all in one step, but it's not there yet
[14:17] <mhall119> did you pull everything from trunk into prod?
[14:18] <davidcalle> mhall119, not yet no, I'm making a mojo spec branch with all these changes, now that I've looked at them
[14:18] <dholbach> jcastro, https://blueprints.launchpad.net/sprints/uos-1511/+settopics ← there's still this one cloud session sitting there
[14:19] <jcastro> I have no idea what this is
[14:19] <jcastro> oh, openstack, ok I'll ask the guys
[14:20] <davidcalle> mhall119, hah, apparently, we can't push changes back from wendigo to a new mojo-spec branch
[14:23] <mhall119> no, which is why I haven't pushed it to LP yet :)
[14:26] <dupingping> hey, please look http://people.ubuntu.com/~dupingping86/
[14:27] <mhall119> dupingping: ok, what am I looking at?
[14:28] <dupingping> mhall119, I made this table with scraped data from Ubuntu Official Site.
[14:29] <dupingping> mhall119, It's same http://www.ubuntu.com/certification/desktop/models/?release=12.04+LTS&category=Desktop&category=Laptop
[14:29] <dupingping> mhall119, but more easily read.
[14:29] <jcastro> dholbach: I'll figute out what to do with it
[14:30] <mhall119> dupingping: cool, what are your plans for it?
[14:33] <dholbach> thanks jcastro
[14:33] <dupingping> mhall119, yes, i just users can easily choose pc & laptops for ubuntu.
[14:35] <dupingping> i wanted to make it as more easily and more useful browse.
[14:35] <mhall119> dholbach: davidcalle: FYI, the recent devportal deployment has given us the ability to add meta tags for page description and keywords,if anybody wants to use them for the snappy docs
[14:35] <dupingping> It's just viewable. And it's about for my web scraping skills.
[14:35] <dholbach> cool
[14:35] <mhall119> dupingping: cool, have you talked to anybody about getting some of those usability changes back into the original site?
[14:37] <dupingping> mhall119, did not say. but will soon. And do you know who manage the original site?
[14:38] <mhall119> I'm not sure, if it's lp:ubuntu-certification than it's Victor Palau https://launchpad.net/ubuntu-certification
[14:38] <dupingping> yes, let me check it.
[14:53] <dholbach> dpm, with some of the snappy sessions not happening I should even be able to make time for the community roundtable :)
[14:55] <dpm> cool :)
[15:07] <dpm> balloons, on the week update notes, could you expand on "QA tracker set up for Xenial" bit?
[15:12] <balloons> dpm, working on it
[15:14] <dpm> balloons, cool, let me know when done and I'll copy over and press the Send button
[15:15] <jcastro> dpm: will there be lightningtalks at the ubucon?
[15:16] <jcastro> also if there's room for it I'd like to do a gaming-on-ubuntu talk if there's room on the schedule
[15:16] <dpm> jcastro, yeah. 4 x 15 min slots, each day
[15:16] <jcastro> if I talk about cloud for 4 days straight I'll go more insane than normal
[15:16] <dpm> awesome, yeah :)
[15:17] <balloons> dpm, I hope it makes more sense now
[15:17] <dpm> jcastro, I'm just putting together a Trello board to coordinate talks and tasks, I'll just put you there
[15:18] <dpm> balloons, looks better now. Do you have some links, though? I just want to make sure I know what I'm talking about :)
[15:18] <balloons> whoops, I have the links ready, hehe
[15:20] <dpm> jcastro, https://trello.com/b/9WhchzaT/ubucon-summit
[15:24] <jcastro> dpm: I can just add our sessions then?
[15:25] <dpm> jcastro, if you know them, yeah, that'd be great. Note that the sessions are for the first day. There is also the unconference part on the second day if you need to use that for discussions/panels
[15:25] <jcastro> ok I'll just add a bunch and then we can trim/move from there
[15:26] <dpm> sounds good
[15:26] <dpm> if you've got many, you might just want to add them to a new "Proposed sessions" list and then we can move them to the final list
[15:28] <jcastro> oh, where is that?
[15:29] <dpm> jcastro, I'll just create the list. I think your sessions would go better on the Developer track
[15:29] <jcastro> ack
[15:29] <dpm> jcastro, you guys rock, btw
[15:30] <jcastro> do you know if we've asked for an orange box?
[15:30] <dpm> jcastro, oh, I thought you mentioned we'd bring one
[15:31] <dpm> jcastro, if you've got the contact, I can ask
[15:31] <jcastro> yeah, dan poler.
[15:31] <jcastro> he has a little spreadsheet you apply for a box
[15:31] <jcastro> then someone ships it out
[15:31] <dpm> great, will get in touch and add a card for it
[15:32] <jcastro> I will add way more than we have room for, easier to throw away content than to scrounge for it
[15:32] <dpm> jcastro, sounds good
[16:27] <davidcalle> dholbach, mhall119, I'm afraid I don't have good news about the importer fix on staging...
[16:27] <dholbach> ok?
[16:27] <mhall119> did you break staging again?
[16:28] <davidcalle> Staging itself is fine! The importer is not :(
[16:28] <mhall119> oh, well then, it could be worse :)
[16:28] <dholbach> mptt is updated?
[16:28] <dholbach> did the importer run finish?
[16:28] <mhall119> mptt should have been upgraded if the new version is in requirements.txt
[16:28] <dholbach> can we run "./manage.py cms fix-mptt" manually?
[16:29] <davidcalle> dholbach, haven't tried the last one, but yes for all previous q
[16:29] <mhall119> juju run --unit devportal-app/0 './run.py manage.py cms fix-mptt' should do it
[16:31] <davidcalle> mhall119, dholbach, I've been running import commands this way for a while now, and while it looked fine at first (with fix-mptt running at each import), it ended up in the same sad state as before
[16:31] <davidcalle> Running fix-mptt separately deosn't help either
[16:31] <davidcalle> mhall119, dholbach, any way to get the version of mptt from the cli?
[16:32] <dholbach> and not a cache issue, either right?
[16:32] <davidcalle> dholbach, I've been verifying it for more than one hour now, so nope
[16:32] <mhall119> davidcalle: there probably is, with pip, but I don't know the syntax off the top of my head
[16:32] <davidcalle> mhall119, ok
[16:33] <dholbach> davidcalle, python -c 'import mptt; print(mptt.VERSION)'
[16:33] <dholbach> (if that's accessible from anywhere?)
[16:33] <dholbach> davidcalle, I'm sorry...... I really thought this would get us somewhere :-(((((((((
[16:34] <mhall119> dholbach: davidcalle: is there a navigation heirarchy to these docs, or are all the pages on the same nav level?
[16:35] <davidcalle> mptt is 0.7.4 (./run.py "pip show django-mptt")
[16:35] <davidcalle> mhall119, if they were all on the same nav level, it wouldn't be an issue if they were mixed up :D
[16:35] <davidcalle> sorry, long day :p There is a hierarchy
[16:36] <mhall119> np :)
[16:36] <davidcalle> dholbach, don't be sorry, you went above and beyond to look for a fix
[16:37] <dholbach> so now we have an interesting case
[16:37] <dholbach> it works in a local postgres installation
[16:37] <dholbach> but not in staging
[16:45] <dholbach> davidcalle, maybe we should go for https://code.launchpad.net/~developer-ubuntu-com-dev/developer-ubuntu-com/1470715/+merge/268471 instead then ;-)
[16:45] <dholbach> mhall119, ^ I updated the "upgrade" MP and it works again
[16:45] <davidcalle> Looks like pages get "stacked-up", eg I can see one in the page tree (ending up on a 404), which url is https://developer.staging.ubuntu.com/en/snappy/guides/current/garbage/cross-build/security/package-names/config/meta/oem/cross-build/package-names
[16:45] <dholbach> and removed mptt and stuff
[16:46] <dholbach> wow
[16:47] <davidcalle> dholbach, this might be better than digging (y)our head(s) into this issue once again, indeed. You were saying that they don't use mptt in newer django?
[16:47] <dholbach> davidcalle, no, they moved to treebeard
[16:48] <davidcalle> dholbach, I like the name, let's go for it ;)
[16:48] <dholbach> davidcalle, maybe after UOS we can test this MP together and see if it isn't worth trying to get this deployed and working together
[16:48] <dholbach> haha, that was an easy sell
[16:48] <davidcalle> dholbach, agreed
[16:49] <dholbach> mhall119, ^ what do you think?
[16:53] <davidcalle> dholbach, mhall119, I need to go
[16:53] <dholbach> all right
[16:53] <dholbach> have a great weekend!
[16:53] <davidcalle> Have a nice week-end all o/
[16:53] <dholbach> and thanks again for your help!
[16:53] <davidcalle> dholbach, np :)
[16:54] <dholbach> oops, that was Ctrl-R in the wrong window :)
[17:17] <dholbach> all right - I call it a day too
[17:17] <dholbach> have a great weekend everyone!


[04:26] <CIA-33> ubiquity: superm1 * r3362 ubiquity/ (debian/changelog ubiquity/frontend/mythbuntu_ui.py):
[04:26] <CIA-33> ubiquity: * mythbuntu_ui:
[04:26] <CIA-33> ubiquity:  - Hide step_label during the last step just prior to reboot. (LP: #412823)
[04:30] <superm1> cody-somerville, you'll want to see if bug 412825 affects standard xfce in xubuntu too
[04:31] <superm1> i believe it should as there is no specific code in mythbuntu_ui for rebooting
[04:32]  * cody-somerville nods.
[04:34] <superm1> make sure you boot up to the full live env though, not an only-ubiquity mode just in case it turns out to be a permissions thing or something like that
[10:02] <lool> Not sure whether you folks read planet gnome but I thought you might be interested in the mockups for advanced partitioning in the Fedora installer http://mairin.wordpress.com/2009/08/12/anaconda-advanced-storage-devices/
[10:02] <lool> It shows that it's a hard problem for everybody
[10:51] <evand> very cool, thanks!
[11:01] <idimmu_> morning!
[11:02] <idimmu_> if i wanted to completely strip out tasksel from the install process, which file should i be mangling?
[11:02] <idimmu_> im thinking ill be tearing apart the initrd.gz ?
[11:03] <idimmu_> theres a reference to tasksel in the lib/kickseed/kickseed.sh ?
[11:03] <idimmu_> also is there any actual documentation on how the install process works anywhere?
[11:07] <CIA-33> hw-detect: cjwatson * r128 ubuntu/debian/ (changelog disk-detect.templates): Drop disk-detect/iscsi/enable template, which is no longer used.
[11:17] <cjwatson> idimmu_: http://wiki.ubuntu.com/Installer/Development links to a paper
[11:17] <cjwatson> idimmu_: the only thing you'd need to change to remove tasksel is pkgsel
[11:17] <idimmu_> sweet
[11:18] <cjwatson> idimmu_: though you can preseed things such that tasksel doesn't actually do anything
[11:18] <cjwatson> so why bother actually changing the code? :)
[11:18] <idimmu_> tried that
[11:18] <idimmu_> didnt work
[11:18] <cjwatson> well, how about I help you with that? it will be easier
[11:18] <cjwatson> what exactly did you try?
[11:18] <idimmu_> that would be awesome
[11:19] <idimmu_> tasksel:tasksel/first=""
[11:19] <idimmu_> in the pxelinux.cfg/default
[11:19] <idimmu_> d-i     tasksel/first multiselect
[11:19] <idimmu_>  (with trailing white space) in the preseed.txt
[11:19] <idimmu_> (we're trying to pxe install jeos)
[11:19] <idimmu_> (hardy0
[11:20] <idimmu_> https://lists.ubuntu.com/archives/ubuntu-installer/2009-August/000466.html
[11:21] <cjwatson> so your problem is that standard is still installed?
[11:21] <idimmu_> yes
[11:21] <cjwatson> tasksel:tasksel/skip-tasks=standard
[11:21] <cjwatson> we probably oughta document that
[11:21] <idimmu_> oo
[11:21] <cjwatson> standard is handled specially which is why you need to do this ...
[11:21] <idimmu_> yeah
[11:22] <idimmu_> i found the skip option in the change logs
[11:22] <cjwatson> hang on, that's already in your preseed file
[11:22] <idimmu_> yep :)
[11:22] <cjwatson> oh, but you put "d-i" as the owner
[11:22] <idimmu_> ah!
[11:22] <cjwatson> d-i	tasksel/first multiselect
[11:22] <cjwatson> d-i	tasksel/skip-tasks multiselect standard, server
[11:22] <cjwatson> the effect of "d-i" there is that it isn't copied to the installed system, and tasksel is run chrooted ...
[11:23] <cjwatson> so replace "d-i" with "tasksel" and it should work
[11:23] <idimmu_> ah ok
[11:23] <idimmu_> tasksel tasksel/skip-tasks etc
[11:23] <idimmu_> ?
[11:23] <cjwatson> right
[11:23] <idimmu_> cheers
[11:23] <cjwatson> maybe we should implicitly copy tasksel/* over anyway, dunno if I like that kind of magic but ...
[11:25]  * idimmu_ reboots the server
[11:26] <idimmu_> looking at all the example they are all tasksel tasksel/blah
[11:27] <idimmu_> so ive no idea how i managed to inject the d-i
[11:27] <idimmu_> ah
[11:27] <idimmu_> not all the examples are tasksel tasksel/blah :/
[11:28] <idimmu_> http://www.emdebian.org/d-i/lenny/preseed.cfg
[11:28] <idimmu_> (ok ok, its 3rd party, my bad :/ )
[11:29] <cjwatson> hmm, wonder if I can track down the author of that
[11:31] <idimmu_> im not sure its worth it
[11:31] <cjwatson> I've had a go
[11:31] <cjwatson> at least somebody who probably has edit access
[11:31] <idimmu_> just googled "d-i tasksel" and got ~400 results
[11:31] <idimmu_> cool!
[11:32] <idimmu_> sweet. base system installed, time to see what it does next
[11:34] <idimmu_> tasksel tasksel/first multiselect
[11:34] <idimmu_> tasksel tasksel/skip-tasks multiselect standard, server
[11:34] <idimmu_> ok that didnt work
[11:35] <idimmu_> append tasksel:tasksel/first= vga=normal initrd=jeos-hardy/ubuntu-installer/i386/initrd.gz locale=en_GB conso <snip>
[11:38] <idimmu_> looks like skip-tasks was first added in intrepid, and im using hardy, maybe ?
[11:38] <cjwatson> drop the tasksel:tasksel/first= from the append line; it's not necessary if you're using a preseed file, and it's confusing
[11:38] <idimmu_> ok
[11:38] <cjwatson> oh, that could be
[11:39] <cjwatson> hmm, maybe jeos just plain didn't do this right in hardy
[11:40] <idimmu_> wonder whether i could use a jaunty netboot to install hardy/jeos or something
[11:40] <idimmu_> tasksel tasksel/first multiselect
[11:40] <idimmu_> tasksel tasksel/skip-tasks multiselect standard
[11:40] <idimmu_> ok ive cleaned out my append line
[11:40] <cjwatson> that ain't gonna help, tasksel is installed from the target suite
[11:40] <idimmu_> my preseed.txt looks like that
[11:40] <idimmu_> oh
[11:40] <idimmu_> poopsock
[11:40] <cjwatson> here's a simple and stupid approach
[11:40] <cjwatson> (give me a second)
[11:40] <idimmu_> :)
[11:42] <cjwatson> erg, this is going to be a right pain to get right for netbooting
[11:43] <cjwatson> d-i preseed/early_command string echo "sed -i 's/^in-target.*tasksel/#&/' /var/lib/dpkg/info/pkgsel.postinst || true" /var/lib/dpkg/info/download-installer.postinst
[11:43] <idimmu_> yep
[11:43] <cjwatson> I think
[11:43] <idimmu_> lol
[11:43] <cjwatson> that just brutally nukes tasksel at run-time, but no need to rebuild anything
[11:43] <idimmu_> sweet
[11:43]  * idimmu_ tries
[11:48] <idimmu_> hmm, blue screen of death
[11:48] <idimmu_> ah thats better!
[11:54] <cjwatson> cool
[11:54] <idimmu_> hmm, well its downloaded tasksel (expected) and its downloaded ubuntu-standard (apprehensive)
[11:54] <idimmu_> we'll see what it does with them!
[11:55] <idimmu_> configured and installed tasksel :o
[11:56] <idimmu_> 'an installation step failed'
[11:56] <idimmu_> it did tasksel, which resulted in fuck all happening, and now its gone straight to grub :)
[11:57] <idimmu_> time to see whats installed :)
[11:58] <cjwatson> odd that it still did tasksel, I wouldn't mind seeing the installation logs at some point
[11:58] <cjwatson> I might have screwed up that sed business, I didn't test it
[11:59] <idimmu_> well its looking better than before
[11:59] <idimmu_> ubuntu-standard/wget/manpages etc *have* installed
[11:59] <idimmu_> but the openoffice stuff hasnt
[12:00] <idimmu_> aspell etc
[12:00] <idimmu_> ill get the installation logs for you!
[12:02] <cjwatson> that sounds like an accident due to the "an installation step failed" bit actually
[12:02] <cjwatson> the standard way to turn that stuff off is:
[12:02] <cjwatson> d-i     pkgsel/language-pack-patterns   string
[12:02] <cjwatson> d-i     pkgsel/install-language-support boolean false
[12:02] <idimmu_> http://www.idimmu.net/installer.tar.gz
[12:02] <idimmu_> cheers, ill add that to the bottom
[12:05] <cjwatson> it doesn't like your preseed file all that much, I wonder if that's related
[12:05] <cjwatson> Aug 13 10:51:14 preseed: warning: Unknown type error, skipping line 13
[12:05] <cjwatson> Aug 13 10:51:14 preseed: warning: Unknown type error, skipping line 16
[12:05] <cjwatson> Aug 13 10:51:14 preseed: warning: Unknown type error, skipping line 27
[12:05] <cjwatson> it looks like you generated this preseed file using debconf-get-selections --installer - that actually really isn't recommended
[12:05] <cjwatson> it's better to start with the example in the installation guide (help.ubuntu.com/8.04)
[12:06] <cjwatson> your installed system is going to have a load of junk in its debconf database that will never go away
[12:06] <idimmu_> ah
[12:07] <idimmu_> yeah
[12:07] <cjwatson> still trying to figure out your actual failure though
[12:07] <idimmu_> ok ill work on that whilst i have my lunch,
[12:07] <idimmu_> cheers for all the help btw!
[12:08] <idimmu_> bbiab
[12:09] <cjwatson> oh, blah
[12:09] <cjwatson> d-i preseed/early_command string echo "sed -i 's/^in-target.*tasksel/#&/' /var/lib/dpkg/info/pkgsel.postinst || true" >> /var/lib/dpkg/info/download-installer.postinst
[12:09] <cjwatson> that extra ">>" makes a big difference
[12:19] <davmor2> cjwatson: I'm assuming this is an issue with packages and not the install but I've installed from this cd 2 times already this time I've done an oem install and it's failed http://www.davmor2.co.uk/syslog
[12:23] <cjwatson> davmor2: neither
[12:23] <cjwatson> Aug 13 10:59:07 kernel: [ 1881.892102] sr 2:0:0:0: [sr0] Unhandled sense code
[12:23] <cjwatson> Aug 13 10:59:07 kernel: [ 1881.892107] sr 2:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[12:23] <cjwatson> Aug 13 10:59:07 kernel: [ 1881.892110] sr 2:0:0:0: [sr0] Sense Key : Hardware Error [current]
[12:23] <cjwatson> Aug 13 10:59:07 kernel: [ 1881.892114] sr 2:0:0:0: [sr0] Add. Sense: Timeout on logical unit
[12:23] <cjwatson> Aug 13 10:59:07 kernel: [ 1881.892120] end_request: I/O error, dev sr0, sector 1090844
[12:23] <cjwatson> Aug 13 10:59:07 kernel: [ 1881.892124] Buffer I/O error on device sr0, logical block 272711
[12:23] <cjwatson> it all goes south from there
[12:23] <cjwatson> apparently quite a localised error on the CD since most other stuff works
[12:24] <davmor2> cjwatson: cool I'll try another cd then
[12:25] <shtylman> evand: is "Exception is ..." a python 2.6 thing only? and I thought that we ran on top of 2.6 not 2.5?
[12:37] <evand> shtylman: we build for both, as I understand it
[12:38] <shtylman> ahh, gotcha
[12:38] <shtylman> do you know when the alpha 4 disks come out?
[12:41] <evand> shtylman: when slangasek pulls the lever. If you want to follow along with the progress, check #ubuntu-release
[12:42] <shtylman> cool
[12:46]  * idimmu_ tries the new d-i preseed/early_command
[13:03] <idimmu_> woohoo thanks cjwatson that  >> totally sorted it!
[13:03] <cjwatson> great
[13:03] <idimmu_> no ubuntu-standard :D
[13:03] <idimmu_> shineee
[13:09] <idimmu_> do you still think its worth me cutting any extra cruft from the preseed.txt?
[13:09] <idimmu_> (yes i did generate some of it from debconf-get-selections)
[13:47] <cjwatson> idimmu_: up to you, it's probably not a huge deal
[13:49] <idimmu_> k
[14:26] <idimmu_> hmm it looks like because we're not running tasksel now
[14:27] <idimmu_> even though ive enabled the universe repository, the equivalent of apt-get update isnt being run
[14:27] <idimmu_> so now im trying to preseed installation of puppet it's failing :)
[14:27] <idimmu_> Aug 13 13:21:53 preseed: running preseed command preseed/late_command: apt-get update ; apt-get install puppet
[14:27] <idimmu_> Aug 13 13:21:53 log-output: sh: apt-get: not found
[14:27] <idimmu_> Aug 13 13:21:53 log-output: sh: apt-get: not found
[14:27] <idimmu_> heh
[14:27] <cjwatson> err
[14:28] <cjwatson> oh, you forgot to chroot
[14:28] <cjwatson> in-target apt-get update && in-target apt-get install puppet
[14:28] <idimmu_> ah cheers!
[14:28] <cjwatson> preseed/late_command runs in the installation root, which doesn't have apt-get
[14:28] <idimmu_> yeah figured that
[14:29] <idimmu_> this installer stuff is pretty cool
[14:29] <mpt> cjwatson, I guess <https://launchpad.net/ubuntu-express> is a duplicate of <https://launchpad.net/ubiquity>?
[14:30] <cjwatson> can you duplicate projects?
[14:30] <cjwatson> the guadalinex guys might still be using their old ubuntu-express for all I know, although I think they've switched
[14:30] <cjwatson> juanje on Freenode would probably know
[15:24] <CIA-33> ubiquity: mterry * r3323 translated-timezones/ (4 files in 4 dirs): kde: support translated timezones too
[15:29] <mterry> uh, ignore that, that wasn't a commit to trunk.  i accidentally had cia on for my branch
[15:33] <cjwatson> didn't look like a commit to trunk; it's OK to have CIA on for branches
[15:34] <mterry> cjwatson, oh, OK
[15:39] <cjwatson> commits to trunk would show up as "trunk/" rather than "translated-timezones/", normally
[15:39] <cjwatson> as long as 'bzr nick' is right
[15:49] <CarlFK> what's a list I can post questions about customizing the live CD? (like adding shortcuts on desktop/task bar, autorun, what can I remove to make room...)
[15:51] <cjwatson> I don't know if there is one; it's probably closer to ubuntu-desktop than here
[15:53] <CarlFK> thanks
[18:35] <eeejay> hey evand, are you around?
[19:22] <rbelem> hey cjwatson
[19:22] <rbelem> i made some changes to ubuntu-cdimage
[19:23] <rbelem> i'm planning add debmirror as a mirror option
[19:23] <rbelem> list all config vars in etc/config
[19:24] <rbelem> the changes are in my branch, https://code.launchpad.net/~rclbelem/ubuntu-cdimage/mainline
[21:48] <cjwatson> rbelem: if you request a merge into the main development branch in LP, I'll get mail
[21:48] <cjwatson> that's preferred
[21:49] <cjwatson> rbelem: I don't like "Removed source on etc/config from every script. It is only on for-project" though - we don't always use for-project for absolutely everything
[21:49] <cjwatson> so that will be my first merge comment :)
[21:49] <rbelem> cjwatson, hum... i will make a cleanup
[21:49] <rbelem> :-)
[21:51] <rbelem> cjwatson, which are the main scripts, that runs the others script?
[22:03] <cjwatson> rbelem: I want config sourced in all scripts
[22:04] <cjwatson> everything is supposed to be runnable standalone; this is useful for debugging
[22:04] <cjwatson> well, all except a select few. for-project indeed *shouldn't* source it; its only role is to set the PROJECT and CAPPROJECT variables
[22:05] <cjwatson> and kill-after and semaphore don't need it
[22:16] <rbelem> cjwatson, nice!!! i will do it today
[22:17] <rbelem> cjwatson, tomorrow i will ping you about the new changes
[22:18] <cjwatson> please use the merge proposal interface in LP, and then you don't have to ping me on IRC :-)
[22:19] <cjwatson> I'd rather do this kind of thing asynchronously
[23:11] <rbelem> cjwatson, ok ;-)
[23:32] <idimmu_> cjwatson: thanks for all the help today dude, by the time i left work i had a fully pxeing completely minimal puppeting jeos installation
[23:32] <idimmu_> night night


[00:00] <jelmer> lifeless: thanks, much appreciated!
[00:03] <poolie> lifeless: could you repaste to me or point me to the numbers for gc performance on bzr.dev please?
[00:04] <lifeless> http://paste.ubuntu.com/116333/ <- these?
[00:05] <lifeless> poolie: or the usertest ones ian did?
[00:07] <poolie> that looks right
[00:08] <poolie> that's the first 1000 commits of bzr?
[00:08] <Odd_Bloke> So I'm using looms for something at the moment.  I have two looms currently, and I have a change to make which belongs between them.  Can I do that in any sensible manner?
[00:08] <lifeless> poolie: thats more
[00:08] <lifeless> poolie: I have the first 1000 stats , one sec
[00:08] <poolie> if this is more that's fine
[00:09] <poolie> so it's something more than 1000 commits of bzr? all of them?
[00:09] <lifeless> 7410
[00:09] <lifeless> not sure of the revno
[00:11] <lifeless> http://paste.ubuntu.com/117486/
[00:12] <poolie> thanks
[00:15] <lifeless> spiv: woo
[00:15] <lifeless> spiv: no new failures, just that one test I discussed with John to tweak, and a 1200 line patch to eyeball :P
[00:17] <spiv> Heh.
[00:17] <spiv> Hmm, overdue for breakfast.
[00:29] <lifeless> spiv:
[00:29] <lifeless> # branch.sprout(bzrdir) is defined as using the branch format selected
[00:30] <lifeless> # by bzrdir; format preservation is achieved by parameterising the
[00:30] <lifeless> # bzrdir during bzrdir.sprout, which is where stacking compatibility
[00:30] <lifeless> # checks are done. So this test tests that each implementation of
[00:30] <lifeless> # Branch.sprout delegates appropriately to the bzrdir which the
[00:30] <lifeless> # branch is being created in, rather than testing that the result is
[00:30] <lifeless> # in the format that we are testing (which is what would happen if
[00:30] <lifeless> # the branch did not delegate appropriately).
[00:31] <spiv> lifeless: +1
[00:31] <mwhudson> which reminds me of something
[00:31] <mwhudson> what's the difference between clone and sprout?
[00:31] <lifeless> mwhudson: push and branch
[00:31] <lifeless> mwhudson: identical copy vs new line of development
[00:32] <lifeless> spiv: so with that explanation, it seems reasonable to me, to say, if (remote), parameterise bzrdir with [arbitrary non-source branch format]
[00:32] <mwhudson> ok
[00:32] <lifeless> spiv: and otherwise leave well enough alone
[00:33] <igc> lifeless, spiv: pull is giving me grief in brisbane-core saying ...
[00:33] <igc> "must end write group before releasing wrote lock"
[00:34] <lifeless> igc: that means that its breaking in a @write_locked decorator
[00:34] <igc> I've spent 30 minutes trying to find the problem but no luck so far :-(
[00:34] <lifeless> and the code path isn't aborting the write group [generally a bug]
[00:35] <lifeless> igc: disable that assertion, you'll see another one pop up; I thought we logged the real one or something, but perhaps not yet
[00:35] <igc> I've looked at the changes to fetch.py, repository.py and pack_repo.py but nothing stands out to my untrained eye
[00:35] <lifeless> spiv: ^ does my plan scan for you ?
[00:35] <igc> lifeless: ok, I'll try that
[00:36] <lifeless> igc: or even (if its nt a blackbox test) a pdb call inside the point that that is raise, would let you look at sys.exc_info
[00:37] <spiv> lifeless: yes, that sounds good
[00:39] <spiv> igc: ah yeah, as lifeless says that's typically like TooManyConcurrentRequests — there's an underlying exception being lost by the failure to abort the write group.  If you can change abort_write_group or something to log the current exception first, or just reraise, that might help.
[00:42] <lifeless> spiv: ok thats done and passing
[00:45] <lifeless> spiv: suggstion: in those acceptance tests we have
[00:45] <lifeless> spiv: put a ratchet now on the hpss call count
[00:46]  * spiv nods
[00:52] <lifeless> spiv: bombs away, putting up a bundle - you can pull that to get the final code
[00:54] <spiv> Ok.
[00:55] <lifeless> spiv: I think you didn't pair with me on enough of this that you can review it with clear conscience:)
[00:57] <lifeless> in the meantime, I'm going to eat, then look at record_stream().next().get_network_bytes conceptually for a bit
[00:57] <lifeless> possibly by walking, I think this is a thinking time
[01:05] <jelmer> hmm, activity reporting works on svn transports but I'm not sure it should be kept in, it makes svn look slow :-P
[01:06] <lifeless> jelmer: why?
[01:07] <jelmer> lifeless: average speed is < 100kb/s
[01:08] <jelmer> I'm getting much more than that for "native" bzr
[01:08] <jelmer> lifeless: I was kidding, it works well
[01:08] <fullermd> Hey, maybe there'll be an entirely new and original statement made in this thread about explicitly-vs-not tracking renames...
[01:08] <jelmer> I guess I should just do some more optimization
[01:10] <mtaylor> hey all you wonderful people...
[01:10] <mtaylor> anybody gonna update the bzrtools package in the PPA?
[01:11] <mtaylor> I'd like to upgrade my bzr but I can't because it'll uninstall bzrtools, and I use those too much ... :(
[01:11] <igc> lifeless, spiv: so disabling that exception didn't work, nor did looking at exc_info() via pdb ...
[01:11] <igc> it does have an exception there about NotABundle but it's a red herring caused by ..
[01:12] <igc> an attempt to read the location as a bundle early in cmd_pull
[01:12] <igc> comment that bit out and exc_info is (None,None,None)
[01:13] <jml> mtaylor: I don't know the answer to your question.
[01:13] <mtaylor> jml: oh well.
[01:13] <jml> mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper
[01:13] <mtaylor> jml: yes. perhaps so.
[01:14] <mtaylor> jml: or, a release policy that ensures bzrtools goes to the ppa at the same time as bzr - I'd be fine with either
[01:14] <igc> lifeless, spiv: it might be something dumb on my end - let me keep looking
[01:14] <jml> cdiff, cbranch & clean-tree are about all I use from it.
[01:14] <jml> patch sometimes
[01:15] <mtaylor> shelve
[01:15] <jelmer> mtaylor: shelve is in bzr itself these days
[01:15] <mtaylor> shelve is my savior in many case
[01:15] <mtaylor> is it?
[01:15] <mtaylor> cool
[01:16] <jelmer> there was also agreement about having clean-tree in bzr itself, but nobody has stepped up yet and actually done it
[01:16] <mtaylor> heh
[01:16]  * jml adds a personal todo
[01:22] <jelmer> poolie: what are your plans for backports exactly?
[01:22] <lifeless> igc: hi
[01:22] <jelmer> poolie: addition to PPA or replacement?
[01:23] <lifeless> igc: so unlock was being called and no exception had occured?
[01:23] <lifeless> igc: what specifici test is doing this?
[01:24] <poolie> jelmer: in addition to the PPA
[01:24] <poolie> maybe not updated immediately when we release, and maybe not done for every release
[01:25] <lifeless> igc: (I will run it and give it a shot)
[01:25] <poolie> > jml: mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper
[01:25] <poolie> i agree with jml
[01:25] <poolie> if "everyone has it" as seems to be the case why keep it separate
[01:29] <lifeless> so network delta reuse
[01:29] <lifeless> I think a sensible approach is:
[01:30] <lifeless> each record in a stream has a network representation
[01:31] <lifeless> we assume that a stream recipient can use any part of a stream they have seen before, for text extraction
[01:31] <lifeless> we assume a stream recipient *will* extract every text, to validate them
[01:32] <lifeless> a delta which needs data not introduced as a diff by that delta just includs that in its network representation
[01:33] <lifeless> and the stream knows what to include/not include
[01:33] <lifeless> finally, we have graph data seperate, but offer a single api call to get the right bytes for serialisation
[01:34] <lifeless> this lets compressors like knits and gc which don't embed graph data not have to grow graph data foo
[01:34] <lifeless> but lets compressors like weaves which do embed graph data just use the embedded data
[01:35] <lifeless> a minor tweak would be to say that record.get_bytes_as(record.storage_kind) if record.storage_kind not in ('chunked', 'fulltext') will return something with inline bytes for graph and raw data
[01:35] <spiv> I'm not clear on what you mean by "a delta which needs data not introduced as a diff by that delta just includs that in its network representation"
[01:36] <lifeless> spiv: a knit-delta-gz
[01:36] <lifeless> spiv: with include_delta_closure == True
[01:37] <lifeless> would just include its parents transitively up to a full text in the blob you get when you ask for the bytes
[01:37] <spiv> Ok.
[01:38] <lifeless> so a naive implementation which never recompresses might include the same external parent several times
[01:38] <spiv> So the network representation for record can vary depending on the stream's include_delta_closure flag, and what has gone on the stream prior to that record.
[01:38] <lifeless> (when we have include_delta_closure ==True)
[01:38] <lifeless> spiv: yes
[01:38] <spiv> Ok.
[01:39] <lifeless> spiv: should I start a branch that aims to test this and get it working with knits and weaves?
[01:39] <spiv> Yes please :)
[01:39] <lifeless> ok
[01:40] <spiv> Hmm, I need caffeine, but I'm out of beans.
[01:40] <lifeless> I have one remaining 'this may be bad' bit - which is that we may need (given this structure) to stash the stream of inventories during a rich root upgrade
[01:40] <lifeless> because of the 'can use anything seen before' constraint
[01:40] <lifeless> but I think writing a temporary versioned files to disk isn't really so bad
[01:40] <spiv> Ugh.
[01:41] <lifeless> alternatively, we window it
[01:41] <lifeless> we say 'anything in the last 256 items', and the generator knows that it has to track what parents are available in that window
[01:41] <spiv> Let's just kill non-rich-root already ;)
[01:41]  * spiv nods
[01:41] <lifeless> spiv: well it still applies with xml -> bbc
[01:41] <spiv> I know :)
[01:41] <lifeless> spiv: or even bbc-flavour-A to bbc-flavour-B
[01:42] <spiv> And I'm sure we'll be varying the inventory format again one day, we're good at doing that ;)
[01:42] <lifeless> because we may need random access to data from the source which is at the far end of the wire
[01:42] <lifeless> so we need a contract where the sender can say 'you need these texts to read my shit', here they are
[01:42] <lifeless> and the recipient can then access them all
[01:43] <igc> lifeless: I'm about to grab some food so here's a brain dump ..
[01:43] <igc> to trigger it ...
[01:43] <igc> bzr-gcchk init --gc-plain-chk xx
[01:43] <igc> cd xx
[01:44] <lifeless> igc: there isn't a test case that dies?
[01:44] <igc> bzr-gcchk pull ../some-pack-branch
[01:44] <igc> bzr-gcchk is brisbane-core with the latest groupcompress plugin
[01:44] <igc> usertest is dying
[01:45] <igc> it gets pass 900 revisions being pulled so my theory is ...
[01:45] <igc> it's something in groupcompress/repofmt.py, around auto-packing say
[01:46] <lifeless> bzr.dev is the test branch ?
[01:46] <igc> I added -Dpack and looked at bzr.log ...
[01:46] <lifeless> igc: oh, packing is broken
[01:46] <lifeless> igc: I was discussing this with jam
[01:46] <igc> btw, groupcompress/repofmt.py needs to import trace and use trace.mutter for -Dpack to work :-)
[01:47] <lifeless> probably need to disable autopack at the moment
[01:47] <igc> bzr.log had a message about autopacking to 1000 revs but it wasn't the very last message fwiw
[01:48] <igc> lifeless: so what's the easiest way to disable autopack?
[01:48] <lifeless> bzrlib.repofmt.pack_repo - in there somewhere ;)
[01:48] <igc> lifeless: np. I disable it in fastimport so I'll do the same thing I do there :-)
[01:48] <jelmer> poolie: thanks
[01:48] <doozer__112> hi - apologies for what's probably a basic question... ;)  But - I'm testing bazaar on XP and the tortoise? integration into the explorer shell works fine - but the only major task it doesn't seem to do is rolling back between versions of a file.  I can do it from the command line if necessary, but was wondering if I'm just missing something?!
[01:49]  * igc grabs some lunch
[01:52] <igc> lifeless: a quick update ...
[01:53] <igc> I tried the same thing with bzr.dev+groupcompress using gc-plain
[01:53] <lifeless> igc: it should break the same way, if you do multiple write groups to it; fetch from a compatible repo won't do that though
[01:53] <igc> it falls over as well, but in a different place - insert_record_stream inside the group_compress plugin
[01:53] <lifeless> doozer__112: I'm not sure, perhaps you could file a bug? (If its not obvious, thats a bug, if its not there, thats a bug too :P)
[02:04] <lifeless> poolie: re: performance figures, the insertion time includes disk read IO
[02:05] <lifeless> poolie: so its not a reliable figure yet. My observation is that its not wildly off, as each pass thrashes on the same content :P
[02:05] <lifeless> igc: a backtrace, and the exception would be good
[02:16] <doozer__112> lifeless: heh, thanks, just playing with some of the other GTK based GUI's too..
[02:17] <lifeless> spiv: please paste your knit modem code :)
[02:22] <victory747> I'm having troubles with bzr-svn - I am pulling into an existing repostiory, and since upgrading to jaunty (bzr 1.11, bzr-svn 0.5.0), all my revision-ids used to have blahblah:Dir%2Ftrunk: and now they have blahblah:Dir/trunk:
[02:22] <victory747> So it sees the branches as having diverged
[02:25] <lifeless> victory747: bzr-svn 0.5 is a fairly big upgrade, I suggest reading the release notes
[02:29] <spiv> lifeless: you mean http://people.ubuntu.com/~andrew/bzr/streaming-push ?
[02:29] <igc> lifeless: the backtrace from pulling into a gc-plain branch has just been emailed to you
[02:29] <lifeless> spiv: just the bencode bits :)
[02:30] <spiv> lifeless: http://rafb.net/p/rIAqn353.html
[02:40] <victory747> lifeless: Thanks - I think I understand now
[02:42] <lifeless> igc: ugh, uhm
[02:43] <lifeless> [02:43] <lifeless> --- repofmt.py  2009-02-10 22:08:17 +0000
[02:43] <lifeless> +++ repofmt.py  2009-02-10 22:47:37 +0000
[02:43] <lifeless> @@ -300,6 +300,8 @@
[02:43] <lifeless>          self._reconcile_does_inventory_gc = True
[02:43] <lifeless>          self._reconcile_fixes_text_parents = True
[02:43] <lifeless>          self._reconcile_backsup_inventory = False
[02:43] <lifeless> +        # Tell fetch what we require.
[02:43] <lifeless> +        self._fetch_order = 'topological'
[02:43] <lifeless>
[02:43] <lifeless> igc: ^ try that
[02:43] <lifeless> igc: it shouldn't be needed, but if you have a broken source repo it may help
[02:45] <lifeless> spiv: thanks
[02:47] <kenichi> what's bzr for "up -r NN" where NN is a few revisions ago?
[02:47] <lifeless> kenichi: currently the closest is 'bzr revert -r NN'
[02:49] <kenichi> lifeless: that doesn't seem to work the way i'm thinking...  i want revert the whole working copy to rNN.
[02:50] <lifeless> kenichi: thats what it does
[02:50] <lifeless> kenichi: after doing that, 'bzr diff' shows the change from NN to -1
[02:51] <kenichi> ugh.. sorry, i should stop working now... yes, thanks it works.
[03:13] <poolie> igc, the display of merges in the commit template is a good idea but not a post-rc thing i think
[03:14] <igc> poolie: ok
[03:14] <igc> poolie: did you see markh's email re tortoise docs?
[03:15] <igc> he'll like them in 1.12
[03:15] <igc> apparently, it was ready for 1.11 but hasn't been landed by anyone
[03:20] <poolie> i landed something related to that...
[03:21] <tro> is ther an external api reference? http://starship.python.net/crew/mwh/bzrlibapi-oe/ seems down
[03:22] <lifeless> tro: you can run pydoctor locally
[03:23] <lifeless> mwhudson: ^
[03:23] <poolie> ah i see it
[03:23] <poolie> tro, lifeless, i'll see if we can run it on escudero
[03:23] <tro> :)
[03:36] <mrooney> Will upgrading my bzr in Intrepid fix this: "Selected-file commit of merges is not supported yet"?
[03:36] <mrooney> or, is there a way to merge just one file
[03:36] <fullermd> No, and not if you want merge tracking of it.
[03:37] <mrooney> Crap. Okay, thanks
[03:37] <lifeless> mrooney: you can merge just one file, but it becomes a cherrypick: 'bzr merge branch/FILENAME'
[03:37] <fullermd> You can fling around single file changes or the like, but history-wise it's indistinguishable from doing the same thing manually.
[03:37] <mrooney> lifeless: will merging again in the future (a full merge) work fine then?
[03:37] <lifeless> mrooney: probably
[03:38] <mrooney> okay that is what I need then, thanks I'll give it a try!
[03:39] <mwhudson> tro: http://starship.python.net/crew/mwh/bzrlibapi/ ?
[03:40] <poolie> tro: where is the -oe version linked?
[03:41] <poolie> our main doc server is apparently too old to have a packaged version of pydoctor
[03:41] <lifeless> spiv: ping
[03:42] <spiv> lifeless: pong
[03:42] <lifeless> spiv: how do you bdecode 'the first item from this long bytestream'
[03:42] <spiv> You don't.
[03:42] <lifeless> ah-ha!
[03:42] <lifeless> no wonder it was seeming difficult
[03:42] <spiv> At least, not with any bencode.py that anyone has written.
[03:42] <poolie> you could write one fairly easily
[03:43] <spiv> You could in principle do it.
[03:43] <spiv> But honestly, I've written enough network stuff like that in recent times :)
[03:43] <poolie> mwh: should i remove the link to the editable copy?
[03:44] <mwhudson> poolie: yes, i think so
[03:46] <lifeless> spiv: so heres my structure
[03:46] <lifeless> I have a NetworkRecordStream calss
[03:46] <lifeless> which takes a bytes_iterator
[03:47] <lifeless> and has a read() method that returns a generator which reconstitutes the input stream
[03:48] <lifeless> I want to dispatch to some code that isn't written yet
[03:50] <lifeless> so I want the generating code to output enough data that I can dispatch on it
[04:46] <lifeless> spiv: is _length_prefix in bzr.dev?
[04:49] <spiv> lifeless: no, but it's trivial:
[04:49] <spiv> def _length_prefix(bytes): return struct.pack('!L', len(bytes))
[04:56] <lifeless> spiv: its ok for now I'm just handwaving, we can tune Monday
[05:23] <lifeless> poolie: spiv: I'm calling it, have a good weekend
[05:23] <lifeless> spiv: I have good progress at pushing that down to the VF interface
[05:23] <lifeless> spiv: we'll still have to do the ugly vis-a-vis delta closures and so on
[05:25] <poolie> night ll
[05:26] <spiv> lifeless: cool
[05:26] <spiv> lifeless: the write group stuff is looking good too
[05:26] <spiv> poolie: woo
[05:34] <poolie> spiv, can we have a really quick call?
[05:36] <AfC> poolie: I thought you were aiming for the<PHONE_NUMBER> timestamp :)
[05:36] <poolie> not precisely
[05:40] <AfC> Anyway,
[05:40] <AfC> Congratulations to the Bazaar hackers on your continued persistence.
[05:44] <spiv> AfC: even in the face of lengthy mailing list threads? :)
[05:47] <fullermd> If it goes on long enough, somebody will say something that hasn't been said the last 50 times the topic was discussed.
[05:47] <fullermd> Surely.  Statistics alone...
[06:38] <fullermd> Hm.  The tarball for the 1.12 release is called bzr-1.12rc1.tar.gz ?
[06:58] <vila> hi all
[07:00] <vila> mtaylor: Are you having a problem with bzr/bzrtools getting out of sync ? Where are you getting them from ?
[07:00] <mtaylor> vila: from the ~bzr ppa
[07:00] <vila> Both will be upgraded today to 1.12 if poolie finish the 1.12 release (which he should ;-)
[07:00] <mtaylor> vila: deb http://ppa.launchpad.net/bzr/ppa/ubuntu intrepid main
[07:00] <mtaylor> cool
[07:00] <vila> In the mean time the bzr-beta-ppa contains both 1.12rc1
[07:01] <vila> mtaylor: which TZ are you in ?
[07:02] <mtaylor> vila: Pacific US
[07:03] <vila> mtaylor: then you should have then when you wake up tomorrow :)
[07:03] <mtaylor> vila: yay! (although you are assuming I will go to sleep at a reasonable time...)
[07:04] <mtaylor> vila: so I _might_ have it before I go to bed!
[07:04] <vila> mtaylor: now *you're* assuming I can produce them before you go to sleep :)
[07:05] <fullermd> Sleep?  Didn't we do that LAST week?
[07:14] <igc> hi vila. Thanks for the review. I'll take a look next week.
[07:14] <vila> igc: sure, enjoy your week-end, and remember that I like the overall direction, I just disagree on details :)
[07:16] <igc> vila. cool. today was lost fixing fast-import bugs and trying to get the groupcompress stuff working under usertest
[07:16] <vila> igc: and don't forget that failing test in usertest :-)
[07:17] <igc> vila: which one is that? can you email me the details please?
[07:17] <vila> I think I did in the past, but I'll mail a fresh one anyway :)
[07:18] <vila> log from bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict
[07:18] <vila> with a ~440 line output totally opaque to me :-/
[07:19] <vila> igc: still there in revno 137
[08:12] <hno> Hmm.. 1.12 released but tarball not on launchpad?
[08:13] <hno> seems 1.12rc1 got uploaded again instead..
[08:33] <Youssef> Hi al!!!!
[08:39] <igc> night all - have a good weekend
[08:44] <LarstiQ> lifeless: it seems so
[09:23] <radix> is someone going to add bzrtools to the bzr PPA
[09:23] <radix> so that my update-manager stops telling me I need to do a partial upgrade
[09:24] <radix> (and so that I can upgrade bzr without removing bzrtools)
[09:45] <vila> radix: as soon as poolie fix the source upload, I'd build the ppas for both bzr and bzrtools
[09:45] <radix> vila: cool, thanks
[09:47] <vila> I jsut can't upload it myself being currently blocked by a failing test (apparently due to some weirdness in my install as ./bzr selftest bzrlib.tests.tree_implementations.test_path_content_summary.TestPathContentSummary.test_unicode_symlink_content_summary fails for both bzr.dev and bzr-1.12 >-/
[09:50]  * fullermd gets a failure there too.
[09:51] <fullermd> FAILED (errors=1, known_failure_count=2)
[09:51] <vila> let's kill a chicken, how can pqm left that pass ?
[09:54] <fullermd> I don't even know what it means  :p
[09:55] <vila> fullermd: what python version are you using ? What os version ? 32/64 bits ?
[09:55] <vila> it suceeds on hardy inside a 32 bits VM but failed on intrepid in 64 bits native
[09:56] <fullermd> 2.5.2 FreeBSD/i386
[09:56] <vila> 32 bits ?
[09:56] <fullermd> Yah.
[09:56]  * fullermd can't imagine word size has much to do with it though...
[09:56] <vila> Of course... just when I thought word size couldn't have anything to do with it you confirm that 32bit works :-(
[09:57] <fullermd> Hm?  It _fails_ for me.
[09:57] <vila> Oh ! Thanks
[09:58] <vila> do you have a python-2.4 handy ?
[09:58] <fullermd> It would take a lot of sit-around-and-compile.
[09:59] <vila> fullermd: nevermind, thanks anyway
[10:00] <vila> Urgh, python-2.5.2 disagree with itself about encondig strings between my two tests 8-(
[10:01] <fullermd> FWIW, 1.12rc1 out of the tarball "passes" (via SKIP'ing that test) on 2.5.2 FreeBSD/amd64
[10:01] <vila> 2.5.2 on hardy/32bits says: '\u03b2-path', where 2.5.2 on intrepid/64bits says: '\xce\xb2-path'
[10:02] <fullermd> Oh, wait, I've got LANG=C on that box...
[10:02] <fullermd> Yah, it fails there too with the UTF-8 locale.
[10:29] <UbuntuBoy> lol
[10:54] <Lo-lan-do> jelmer: I don't know if you committed the fix you mentioned earlier, but a bzr update I did just now took one minute and a half instead of the previous five minutes.  Thanks :-)
[10:59] <vila> jelmer: ping
[11:02] <UbuntuBoy> brb
[11:15] <nielsbom> (I'm a n00b), what's the correct way to stop having a simple local bzr repository?
[11:15] <nielsbom> I just deleted the .bzr dir, that worked, but seemed wrong
[11:15] <Kinnison> Depends what you mean
[11:16] <nielsbom> Can you elaborate?
[11:19] <Kinnison> Well, if all you wanted was to abandon your revision control then removing .bzr works
[11:19] <nielsbom> Kinnison: Yeah, that answers my question :)
[11:19] <Kinnison> If you wanted something with more complex semantics then it wasn't necessarily the right thing to have done
[11:19] <nielsbom> Kinnison: is there a bzr command for that?
[11:19] <nielsbom> Kinnison: or is just ok to rm .bzr?
[11:20] <Kinnison> personally I'd use bzr export to create a non-controlled copy
[11:20] <Kinnison> and then tar up and backup the version with the .bzr
[11:20] <Kinnison> but that's because I don't abandon revision control, if I can help it
[11:20] <fullermd> Me, I'd...   well, not do it in the first place   ;p
[11:21] <nielsbom> Kinnison: ok clear, thanks
[11:21] <Kinnison> sometimes I have to translate from one RCS to another, where importing the history isn't an option
[11:21] <glade88> what would be the equivalent of "svn update" in bzr? "bzr update" doesnt seem to do the same
[11:21] <glade88> ..neither "bzr upgrade"
[11:21] <fullermd> bzr update does the same thing svn update does.  That may not be quite what you want in a given case, though.
[11:21] <Kinnison> glade88: In a checkout, bzr update ought to work
[11:21] <fullermd> Perhaps you want 'bzr pull'.
[11:21] <Kinnison> glade88: in a branch, you may want bzr pull
[11:21] <Kinnison> snappish
[11:22] <glade88> it is a Launchpad branch.
[11:22] <glade88> bzr pull LP:ideatorrent ?
[11:22] <Kinnison> simply 'bzr pull' will pull from the last location IIRC
[11:24] <glade88> damn this "ssh passphrase". can I make it not to ask each time? "ssh add URL" doesnt seem to work for some reason..
[11:24] <glade88><EMAIL_ADDRESS>[11:24] <glade88> ^in my case
[11:24]  * fullermd didn't know there WAS a 'ssh add'...
[11:24] <glade88> fullermd: any other way to save the passphrase?
[11:25] <Kinnison> do you mean your ssh password, or your ssh key passphrase?
[11:25] <fullermd> bzr doesn't have anything to do with that, TTBOMK.  That's all in your ssh client.
[11:25] <fullermd> Well, it has to be passphrase where LP is concerned.
[11:25] <fullermd> There's a ssh-agent or something like that.
[11:25] <glade88> its my ssh passohrase
[11:25] <glade88> and yes, bzr has nothing to do with that :)
[11:25] <Kinnison> ssh-add ~/.ssh/id_rsa
[11:25] <Kinnison> that kind of thing
[11:25] <glade88> since it is the same for svn
[11:27] <glade88> Kinnison: fullermd: thanks, bzr pull works. I'll pondermore on the passphrase thing.
[11:27] <glade88> cheerio
[11:28]  * Kinnison 's suggested ssh-add commandline is what glade88 wants
[11:28] <fullermd> Well, only once you have the agent running.
[11:28] <nielsbom> Just found this in the user guide (d'oh!): If you accidently put the wrong tree under version control, simply delete the .bzr directory.
[11:28] <fullermd> And you need that ancestrally to all your terminal creations (or manual hackery in each)
[11:29] <Kinnison> fullermd: typically, linux systems start ssh agents as part of the X session
[11:29] <Kinnison> fullermd: As for other systems, dunno :-(
[11:30]  * fullermd always has a hand-crafted .xinitrc, so nothing gets started he doesn't order  :p
[11:30] <glade88> Kinnison: w00t! yes, darn me I was using "ssh add" not "ssh-add". worksformenow (tm) . ty
[11:30] <Kinnison> fullermd: How retro :-)
[11:31] <fullermd> Oh, that's not retro.  What's retro is how the last line starts the window manager, ctwm  :p
[11:32] <Kinnison> Oh dear
[11:32]  * Kinnison pats fullermd gently on his clearly damaged head :-)
[11:32] <fullermd> But it's ctwm with a few of my own local hacks applied, of course.
[11:32] <fullermd> Sorta like the web browsing is firefox with my local hacks, and the mail reading is mutt with my local hacks, and...
[11:33]  * fullermd . o O ( If the world would just cater to me more, things would be so much easier... )
[11:38] <fullermd> Oh dear.  Somebody actually _likes_ $Log$?
[11:38] <vila> fullermd: some even likes log --forward :-)
[11:39] <fullermd> log --forward is almost as cool as missing --reverse!
[11:40] <vila> Don't start *me* on --reverse :-)
[11:40]  * fullermd reverses vila on --start.
[11:40] <vila> --start is good :-)
[11:40] <fullermd> Hey, we should add stat --backward, to show the merge revs in the opposite order, too.
[11:41] <fullermd> Then we'll cover the gamut better!
[11:43] <Kinnison> urf
[11:53] <UbuntuBoy> Hi guys!
[11:54] <UbuntuBoy> I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" please
[12:21] <nielsbom> (noob question) is it possible to co-develop a website using 2 computers which can't be connected through SSH (or something like it) using bzr? (Something like sending a whole repositorie as a file and merging it locally, and vice versa?)
[12:22] <Lo-lan-do> nielsbom: Yes, with merge requests sent by email.
[12:27] <santagada> actually  you can save a bundle to a file and transport it anyway you fell like it
[12:28] <santagada> for example a pen drive
[12:29] <Lo-lan-do> Yeah, or a floppy disk or a punched card.  I sort of assumed the two computers still had access to *some* net :-)
[13:10] <UbuntuBoy> Lo-lan-do!?
[13:11] <UbuntuBoy> I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" how can I do that please?
[13:11] <santagada> Lo-lan-do: you are not paranoid enough :)
[13:12] <Lo-lan-do> UbuntuBoy: I don't even know what a windows service is...
[13:12] <UbuntuBoy> lol
[13:12] <UbuntuBoy> a deamon i u want
[13:13] <UbuntuBoy> if
[13:13] <UbuntuBoy> sry
[13:13] <UbuntuBoy> a deamon if u want
[13:13] <santagada> UbuntuBoy: you know a service is not really a daemon right?
[13:13] <UbuntuBoy> :p
[13:13] <UbuntuBoy> yep
[13:14] <santagada> UbuntuBoy: so I'm guessing that if there is no service plugin and windows services are not mentioned on bazaar manual it is not supported
[13:14] <UbuntuBoy> mmmhhhhh...
[13:15] <santagada> UbuntuBoy: but maybe there is a way to use unix tools or something from microsoft to use a daemon as a service
[13:16] <santagada> UbuntuBoy: why not use IIS and fastcgi?
[13:16] <UbuntuBoy> because I prefer use directly bzr://
[13:17] <UbuntuBoy> its more easy
[13:18] <UbuntuBoy> it's sry
[13:20] <santagada> UbuntuBoy: I don't really agree... but ok
[13:20] <UbuntuBoy> :)
[13:20] <santagada> UbuntuBoy: use the unix daemon tools or unix tools that came with your windows server to do it
[13:21] <UbuntuBoy> unix daemon tools ?
[13:21] <santagada> UbuntuBoy: with IIS you can easily integrate with AD also
[13:21] <UbuntuBoy> I dunno
[13:21] <UbuntuBoy> how
[13:21] <santagada> UbuntuBoy: I think it is unix tools
[13:21] <santagada> daemon tools is that thing to run .iso images
[13:22] <santagada> UbuntuBoy: as an Ubuntu boy you probably know how to link LDAP and apache... with IIS is probably even easier to connect to AD for authentication
[13:22] <santagada> authorization will be left as an exercise :D
[13:22] <UbuntuBoy> hmmm
[13:23] <UbuntuBoy> hmm...
[13:23] <UbuntuBoy> i'm not really an ubuntyboy I took this nick becoz i didn't find anything else looooooooool
[13:24] <UbuntuBoy> or my name
[13:24] <Youssef> like this
[13:24] <Youssef> hihi
[13:24]  * Youssef put back his deguisment
[13:25] <santagada> Youssef was cooler
[13:25] <UbuntuBoy> Really?
[13:25] <UbuntuBoy> okay
[13:25] <Youssef> hihi
[13:26] <Youssef> ^^
[13:26] <Youssef> hmmm
[13:30] <santagada> Youssef: windows services for unix is deprecated I think, and don't do what you want
[13:30] <Youssef> about what?
[13:32] <Odd_Bloke> Youssef: I would suggest a post to the ML.
[13:33] <Youssef> ML?
[13:33] <Youssef> what is it?
[13:33] <Youssef> sorry guys im a windows user I try my best to learn the linux world
[13:33] <Youssef> it's a bit hard for me the please use full words
[13:34] <Youssef> not only those characters lol
[13:34] <Youssef> santagada! You said -> and don't do what you want <- what does it means?
[13:34] <Odd_Bloke> Youssef: Mailing List.
[13:34] <Youssef> loooooooooooooooool
[13:34] <Youssef> okay okay
[13:35] <Youssef> and why would you suggest me to post to the mailing list?
[13:35] <santagada> Youssef: I don't see a way to run a daemon as a service
[13:35] <Youssef> hhoo okay okay
[13:35] <santagada> Youssef: because them more people can see your question
[13:36] <santagada> Youssef: and can give you a more complete answer
[13:36] <Youssef> ooohhh
[13:36] <santagada> Youssef: or just because your question might become a feature request for a future version of bazaar :D
[13:36] <Youssef> okay
[13:36] <Youssef> mmhhhh...
[13:36] <santagada> Good luc
[13:36] <Youssef> interesting hehe
[13:36] <santagada> luck
[13:37] <Youssef> thankyou very much
[13:37] <Youssef> guys
[13:37] <Youssef> thanks a lot hehe
[13:37] <Youssef> but one last question
[13:37] <Youssef> where is the mailing list?
[13:40] <Odd_Bloke> Youssef: https://lists.ubuntu.com/mailman/listinfo/bazaar
[13:42] <nielsbom> Lo-lan-do: thanks!
[13:51] <xtian_> Can anyone tell me how to prevent bzr on windows from using plink for sftp (and get it to fall back to paramiko)?
[13:53] <xtian_> I can force it to fallback by renaming plink, but I need plink on my path to edit remote files in emacs.
[13:56] <xtian_> whoa, tumbleweeds, huh?
[13:57] <Lo-lan-do> And crickets.
[13:57] <Odd_Bloke> I don't know.
[13:57] <Odd_Bloke> And I can't think who here uses bzr on Windows.
[13:58] <xtian_> Fair enough! I might try the mailing list.
[13:58] <Odd_Bloke> Probably wise
[13:59] <xtian_> Cheers!
[14:03] <Tak> eh, I use bzr on windows, but not with sftp
[14:04] <xtian_> do you just use it with launchpad?
[14:08] <Tak> no, I use it with bzr-svn and smb
[14:20] <verterok> xtian_: try with set BZR_SSH=paramiko
[14:20] <xtian_> aha! Thanks!
[14:20] <xtian_> Trying now.
[14:21] <xtian_> Is there any reference where I could find that kind of thing in future?
[14:22] <xtian_> That worked! Thanks heaps.
[14:22] <verterok> xtian_: I found it the mail list archive, but I'm sure it's in the official docs
[14:23] <verterok> xtian_: if you can't find it in the official docs, please file a bug about it
[14:23] <xtian_> Wilco
[14:23] <xtian_> Just looking now
[14:24] <xtian_> Gah - there it is - I was looking for the wrong keywords. I could find mention of restoring auto-detection of plink in some bug threads, but not that.
[14:25] <xtian_> Thanks again!.
[14:26] <verterok> xtian_: np, glad to hlep
[14:29] <hno> Youssef: There is a tool in the windows resource kit for creating services of arbitrarily programs not having builting service capabilities.
[14:33] <Kinnison> What's the status of tracking cherrypicks in bzr?
[14:43] <vila> verterok: that was short :-)
[14:43] <verterok_> vila: me netwokr is flaky, hopefully be back at home during the weekend :)
[14:44] <verterok_> /me/my
[14:44] <vila> s!/me/my!s/me/my/! :-)
[14:45] <verterok> :)
[14:45] <Odd_Bloke> s,s!/me/my!s/me/my/! :-),s!/me/my!s/me/my/!,
[14:45] <Odd_Bloke> :)
[14:45]  * fullermd hopes you don't try that in csh...
[14:51] <yenzenz> hi
[14:52] <Odd_Bloke> yenzenz: Hi. :)
[14:52] <yenzenz> is this a known issue: download link to tgz of 1.12 release is broken at http://bazaar-vcs.org/Download
[14:53] <Odd_Bloke> yenzenz: I wasn't aware of it.
[14:53] <fullermd> Yes, it's known.
[14:54] <yenzenz> fullermd: ok, thnaks. so just a matter of time :)
[14:54] <nielsbom> {noob} I start a local repository on my pc (bzr init, bzr add, bzr commit), then I want to send the whole branch including all files to a colleague so he can start development on his own pc and then send patches my way. How do I export my whole dir, incl repository to him? Should I do that with bzr? Or just copy it?
[14:55] <Lo-lan-do> You can copy the .bzr dir
[14:56] <nielsbom> Lo-lan-do: yes, I understand that, and also copy all the files in the dir in which my files reside.
[14:57] <Lo-lan-do> You don't *need* to copy those, since they can be regenerated from the .bzr dir.
[14:58] <nielsbom> Even if he hasn't had the repo before?
[14:59] <Lo-lan-do> The .bzr dir contains the full history.  So he can just bzr reconfigure --tree and get the working files from that.
[14:59] <Lo-lan-do> (Or just bzr checkout)
[15:00] <fullermd> Well, if you send the .bzr from a dir with a checkout, you'd use revert...
[15:00] <jelmer> vila: hi
[15:01] <vila> jelmer: hi
[15:01] <vila> jelmer: did you see my mail about 1.12
[15:01] <vila> jelmer: did you see my mail about 1.12  ?
[15:01] <jelmer> vila: Yeah
[15:01] <jelmer> vila: Strange it's failing for you :-/ Does it fail both with dirstate C extensions and without?
[15:02] <vila> It fails *with* C extensions
[15:02] <jelmer> does it work without?
[15:02] <vila> let me check
[15:04] <fullermd> It works for me without, and fails with.
[15:04] <vila> works without
[15:04] <vila> ...
[15:04] <vila> gha...
[15:05] <nielsbom> Lo-lan-do: ok, I'm starting to understand, I think (we're testing it now)
[15:05] <Lo-lan-do> nielsbom: Maybe you could use the bzr-fast-export.py script from plugins/fastimport if you don't feel comfortable copying a .bzr dir.
[15:06] <vila> jelmer: does it make sense to you ?
[15:06] <jelmer> vila: Not entirely yet, but at least more
[15:06] <nielsbom> Lo-lan-do: I'm ok with that for starters
[15:08] <vila> jelmer: with my patch, that's the opposite, fail without extensions, works with
[15:11] <nielsbom> Lo-lan-do: So I have a local repository, I committed to it, then I copy the .bzr directory to another directory, say example/. I then go to that dir and give the command bzr reconfigure --tree. I get the error "example is already a tree"
[15:12] <nielsbom> Lo-lan-do: "example/ is already a tree
[15:12] <jelmer> vila; Looks like there's an inconsistency in dirstate C extensions / Python
[15:12] <Lo-lan-do> nielsbom: Try "bzr revert" instead.  Apparently the .bzr contains info on what's supposed to be outside itself :-)
[15:15] <vila> jelmer: yup, we need more tests parametrized on C extension availability or not
[15:15] <jelmer> vila, i.e. one already provides unicode, the other provides ascii
[15:17] <nielsbom> Lo-lan-do: cool, that worked thanks!
[15:17] <vila> What are the consequences if we revert your patch ? Is bzr-svn impacted ?
[15:18] <jelmer> vila: No, bzr-svn is not impacted, but some repositories will be impacted (as it'll break symlinks with unicode names)
[15:19] <jelmer> vila, Do you really need to revert it though? Only newly added tests seem to fail
[15:20] <vila> jelmer: well, I came across it just before a release... I don't think it should block it, but that's for the RM to decide...
[15:21] <vila> jelmer: plus, it fails only under unclear circumstances...
[15:21] <vila> jam: ping
[15:21] <jelmer> vila: I mean, the alternative would be to just remove the tests added by my patch
[15:21] <jam> hi vila
[15:21] <vila> untested code is broken code :-)
[15:22] <jelmer> vila, well, that seems to be what's breaking for you
[15:23] <vila> jelmer: Only because I came across it via the test but I presume I can reproduce it from command line, so our users can too
[15:25] <jelmer> vila: this was already broken from the command-line
[15:25] <jelmer> my patch was meant to address it
[15:25] <vila> jelmer: I understand that, don't get me wrong.
[15:26] <vila> But it the fix seems incomplete then, even if you can't trigger it yourself (or so it seems) because, well, your setup is different
[15:26] <vila> I can't reproduce it either under hardy/32bits inside a VM,
[15:27] <vila> I reproduce it only under intrepid/64bits on a real host
[15:27] <vila> Same python version: 2.5.2
[15:27] <vila> I fail to understand why the word size has an impact though....
[15:28] <jelmer> I'll see if I can reproduce on my 64bit machine
[15:28] <jelmer> it seems strange indeed that the word size would affect the type of a field in dirstate..
[15:30] <fullermd> It happens for me on i386 and amd64 both.
[15:32] <jam> fullermd: are you on BSD?
[15:32]  * jam seems to remember that BSD has different ideas about fs_enc
[15:33] <fullermd> What's the thing that makes bzr spit its fs_enc out?
[15:35] <jam> fullermd: um... python -c 'import bzrlib.osutils; print bzrlib.osutils._fs_enc" ?
[15:36] <jelmer> the problem seems to be that the dirstate C extensions call _read_link() with a str argument
[15:36] <jelmer> and the native Python code calls it with a unicode argument
[15:36] <fullermd> UTF-8
[15:36] <jam> so the dirstate code should be using a UTF-8 string (always), which is probably incorrect on some situations
[15:36] <fullermd> I note that (if it matters) it's the (PreviewTreePost) variant that fails.  (DirStateRevisionTree) and the other options work.
[15:37] <fullermd> Well.  I assume pass == work.
[15:37] <jelmer> jam: the dirstate code should always use unicode internally?
[15:37] <jelmer> s/unicode/utf8
[15:39] <jam> jelmer: generally, yes
[15:39] <jam> The paths stored *in* the dirstate file should all be utf-8
[15:39] <jam> And 90% of all processing is done via utf-8 strings
[15:40] <jam> only when finally yielding them to upper layers do we decode it back to Unicode
[15:40] <jelmer> and when reading from the OS encoding as _fs_enc?
[15:41] <jam> jelmer: right
[15:41] <LarstiQ> evening
[15:41] <jam> hi LarstiQ
[15:41] <jam> beuno: ping
[15:41] <LarstiQ> hey jam
[15:44] <jelmer> Hey LarstiQ
[15:44] <jelmer> hi emmajane
[15:44] <LarstiQ> hi jelmer, emmajane :)
[15:44] <emmajane> jelmer, hello :)
[15:44] <emmajane> LarstiQ, hello as well
[15:44] <jelmer> emmajane, thanks for the report wrt the docs on samba.org, btw
[15:44] <emmajane> jelmer, no problem.
[15:45] <emmajane> jelmer, I wasn't sure if it was meant to work with local files, but not online. Or something.
[15:46] <jelmer> emmajane, it's supposed to work, but seems to break from time to time as it's updated automatically
[15:46] <emmajane> heh. Yeah. There's 'supposed to' and then there's 'output from scripts' :)
[15:47] <jam> Does anyone else know if 'loggerhead' is fully plugin-ized now?
[15:48] <LarstiQ> jam: yes, fsvo fullu
[15:48] <jam> well, is "bundling it with the win32 installer" going to work
[15:48] <LarstiQ> jam: I don't think it does the fancy decorating of 'bzr serve' yet
[15:48] <jam> I guess is the question
[15:48] <jelmer> emmajane, :-)
[15:48] <LarstiQ> jam: ooh, goed question.
[15:48] <jam> I think it will take a few steps
[15:48] <jam> as it would also require extra dependencies
[15:48] <jam> like we have to do with bzr-svn, etc.
[15:48] <jam> I think I need to put together a spec
[15:48] <jam> for handling setup issues with bundling plugins
[15:49]  * LarstiQ cries as selftest slows his netbook to a crawl
[15:49] <jam> as I'm tired of having to edit bzr's setup.py for each plugin
[15:49] <jelmer> vila, jam: So the problem seems to be that py_update_entry() calls _read_link() with a unicode string
[15:49] <jelmer> vila, jam: Whereas the C extensions call it with a utf8 string
[15:51] <jam> hmm... something odd here
[15:51] <jam> as the C extension just passes through the "abspath" it was given
[15:51] <jam> which is also what "py_update_entry" does
[15:52] <jam> So I'm guessing it isn't the 'update_entry' code
[15:52] <jam> but the _process_entry code
[15:52] <jam> which is getting something wrong
[15:57] <emmajane> And now for something completely different: an on-topic comment! :)
[15:57] <emmajane> Next weekend I'm giving a bzr talk at SCaLE. I'm giving essentially the same talk as I gave before.
[15:58] <beuno> jam, pong
[15:58] <emmajane> The slides are at: http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation if anyone has comments for add/modify/deletes.
[15:58] <jam> beuno: on bug #328860, Martin mentions wanting to bundle loggerhead with the win32 installer
[15:58] <jam> I was just curious if loggerhead has been fully turned into a "plugin"
[15:58] <emmajane> The talk description is at: http://scale7x.socallinuxexpo.org/conference-info/speakers/emma-jane-hogbin (It's just an intro talk)
[15:59] <jam> so that it would be bundled in the same fashion that bzr-svn, etc. would be
[16:00] <beuno> jam, poolie actually did turn it into a plugin during our sprint
[16:00] <beuno> let me find the merge proposal..
[16:01] <beuno> https://code.edge.launchpad.net/~loggerhead-team/loggerhead/loggerhead-plugin/+merge/3095
[16:01] <beuno> jam, ^
[16:01] <beuno> I'll merge that in today
[16:02] <jam> beuno: well, I won't change anything for 1.12
[16:02] <jam> just thought I'd check where things were at
[16:02] <jam> Does that also decorate "bzr serve" ? Or is it just "bzr loggerhead-commands"?
[16:02] <beuno> it decorates serve
[16:02] <beuno> which is what prompted jml's work on it
[16:06] <jelmer> emmajane, do you have some other format than flash? gnash is not cooperating with me atm
[16:06] <fullermd> Ooh look, a 1.12 tarball...
[16:07] <emmajane> jelmer, is there an option to download the ODP from that page?
[16:08] <emmajane> http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation/download ?
[16:08] <emmajane> it gives a PDF, I think.
[16:08] <Lo-lan-do> beuno: Will you also merge the init script for daemon-like operation?
[16:09] <jelmer> emmajane, that seems to require login :-/
[16:09] <Lo-lan-do> (You did ask me to pester you :-)
[16:09]  * fullermd keeps waiting for the day flash joins java applets in the dustbin...
[16:09] <emmajane> jelmer, boo to slideshare.
[16:09] <beuno> Lo-lan-do, I may put up a merge proposal for someone with a working brain to review  :)
[16:09] <jelmer> beuno, and will you remove start-loggerhead ? (-:
[16:10] <beuno> jelmer, not until I get config working with serve-branches  :/
[16:11] <emmajane> jelmer, http://bazaar-vcs.org/Talks?action=AttachFile&do=get&target=bzr-intro-template.odp
[16:11] <jelmer> emmajane, thanks
[16:11] <emmajane> jelmer, thanks for looking! :)
[16:13] <fullermd> Things you notice when updating packages:
[16:13] <fullermd> bzrtools 1.12.0 is 1 'larger' than bzrtools 1.11.0.  Thus, it's fitting that the tarball is also 1 byte larger.
[16:13] <jam> a single byte, that is quite intriguing
[16:14] <Lo-lan-do> "Well, it's one louder, innit?"
[16:14] <fullermd> But why not make each byte bigger?
[16:14]  * fullermd nods at jam.
[16:14] <fullermd> I thought so.
[16:14] <fullermd> -SIZE (bzrtools-1.11.0.tar.gz) = 69765
[16:14] <fullermd> +SIZE (bzrtools-1.12.0.tar.gz) = 69766
[16:15] <jam> well, also of interest:
[16:15] <jam> 3.8M Feb  9 04:42 bzr-1.11.tar.gz
[16:15] <jam> 3.9M Feb 13 09:53 bzr-1.12.tar.gz
[16:15] <jam> 1 (100kB) bigger
[16:16] <fullermd> Well, not really.  It's 39807 bigger.
[16:17] <Odd_Bloke> s/bigg/loud/
[16:19] <fullermd> Of course, if you subtract that from the curent bzrtools, you get 29959.  Subtrace that from the previous bzrtools, you get 9848.
[16:19] <Toksyuryel> Would Stackless provide any measurable speed improvements to bzr?
[16:19] <fullermd> Sum those digits, you get 29, which starts the pattern.  The next digit is the 9 again from the start of 9848.  The 59 is one more than the trailing 48.
[16:19] <fullermd> So it all works out anyway.
[16:20]  * fullermd wanders off to smoke some more crack...
[16:20] <Toksyuryel> seems to have done a lot for EVE Online, am wondering if bzr can achive similar performance gains
[16:21] <Toksyuryel> http://en.wikipedia.org/wiki/Stackless_Python
[16:23] <Odd_Bloke> Toksyuryel: Without really knowing anything more, I would note that EVE and bzr are fairly different apps. ;)
[16:23] <Toksyuryel> Granted, but still :)
[16:23] <jelmer> emmajane: seems good to me :-) simple, and quick
[16:23] <Odd_Bloke> Essentially, I doubt it, because bzr isn't multi-threaded.
[16:23] <jfroy> Morning!
[16:24] <jelmer> emmajane, why does "bzr tags --sort=time" need special attention? The other commands mentioned seem much more common
[16:24] <jelmer> hi jfroy !
[16:24] <Toksyuryel> Is threading planned for a future development?
[16:24] <Odd_Bloke> Toksyuryel: I don't know.
[16:24] <emmajane> jelmer, it's just one that I use a lot myself (tagging what versions I send to the client). I talk a bit about it.
[16:25] <Toksyuryel> Perhaps implimenting threading and moving to stackless coule provide performance improvements over the current model?
[16:25] <Toksyuryel> *could
[16:25] <fullermd> I would tend to doubt it, certainly in the near or mid term.
[16:25] <jfroy> jelmer: congrats on 0.5 final
[16:25] <emmajane> jelmer, thanks for taking a look. Much appreciated.
[16:26] <Toksyuryel> fullermd: I see
[16:27] <jelmer> Toksyuryel, what would the benefit of threading be exactly?
[16:28] <Toksyuryel> potential speed increases? I'm just wondering and asking. someone's gotta actually answer the question with "yes that would make it faster" or "no it would not make it faster" :D
[16:29] <jam> Toksyuryel: currently I think our big bottlenecks are stuff like graph walking
[16:29] <jam> it is pretty hard to come up with efficient walking code
[16:29] <jam> and even harder to do something that is also parrallel
[16:29] <jam> One possible place would be text insertion, I guess
[16:29] <Toksyuryel> like I said... I am just asking. I am not saying "this would definitely be faster and you should do it right now".
[16:30] <jam> if you are trying to insert 100 different texts, you could probably farm a couple of those out to different threads
[16:30] <Toksyuryel> please stop trying to spin my words to your own ends :)
[16:30] <Toksyuryel> I understand that it's not a high priority compared to other things which need to be done
[16:31] <santagada> jam: sorry to botther you but isn't this kind of stuff io bound?
[16:31] <jam> santagada: some is, some is 'diff' bound
[16:31] <fullermd> I expect the place we're most likely to pick up parallelism would be from python-level stuff, really.
[16:31] <jam> stuff like 'annotate' could benefit
[16:32] <fullermd> e.g., list comprehensions are inherently parallelizable.
[16:32] <jelmer> Toksyuryel: You're talking about specifics, parallelism can be achieved through more than just threading
[16:42] <jfroy> I was just asked by a friend if bzr had an equivalent to git add -p. He tells me it lets you commit a subset of all the changes in the branch, even from the same file. I've never done that in bzr, so I'm not sure.
[16:43] <fullermd> You can specify files, you can use shelve to set aside bits before you commit, or...   I think somebody wrote a plugin to do a darcs-style record?
[16:43] <fullermd> (I don't know if/how well it works)
[16:45] <Odd_Bloke> jfroy: Yeah, shelve is probably what he's looking for.
[16:46] <Odd_Bloke> You use it put some of your changes on the 'shelf', commit, then use unshelve to pull them back off.
[16:46] <Odd_Bloke> It has the advantage of allowing you to confirm that you haven't broken anything with the subset of changes you're committing before you commit them.
[16:46] <jam> jfroy: it is sort of the "inverse" of add -p, in that you are taking off things you don't want to commit, rather than explicitly listing the things *to* commit
[16:46] <jam> however, it leaves the tree in a state that you can run "make test" on
[16:46] <jam> which is generally beneficial
[16:49] <lbieber> Can someone tell me how to modify the 1200 second timeout limit in bzr? I'm experiencing a problem on several of our machines where they occasionally time out, not sure if it is because they are behind a firewall or not
[16:50] <jfroy> Thank you all.
[16:50] <LarstiQ> lbieber: do you have a .bzr.log of when that happens?
[16:51] <lbieber> LarstiQ:  one minute let me see if I can dig it up
[16:52] <jam> lbieber: you can set bzrlib.lockdir._DEFAULT_TIMEOUT_SECONDS
[16:52] <jam> though if you are hitting that
[16:52] <jam> (default is 5 min)
[16:52] <jam> I'm guessing it is something else.
[16:52] <lbieber> LarstiQ: ummmm, where would I find .bzr.log, I'm not seeing it anywhere?
[16:53] <jam> ~/.bzr.log
[16:53] <jam> Or if on windows $My Documents/.bzr.log
[16:53] <jam> bzr --version spells it out for you
[16:57] <lbieber> ahhhh -  let me fix this first and see if it helps, from the log file - 0.120  WARNING: using slower ElementTree; consider installing cElementTree and make sure it's on your PYTHONPATH
[16:58] <Myrtti> I was wondering if http://paste.ubuntu.com/117733/ this is an error of bzr, launchpad or me?
[16:59] <Odd_Bloke> Myrtti: That looks like a bzr problem.  Is there any chance you could try with a newer version of bzr?
[17:00] <jam> Myrtti: that is a known bug with bzr 1.6.1 when using -Dhpss
[17:00] <jam> what bug happened that caused you to try and use -Dhpss
[17:00] <jam> as that is the real issue
[17:01] <jam> (that said, if you upgrade your bzr, it probably all goes away anyway)
[17:02] <Myrtti> what I did was I removed some of the launchpad projects and tried to rebranch them
[17:02] <Myrtti> bzr pull worked while the launchpad project working copies were there
[17:03] <Myrtti> but now http://paste.ubuntu.com/117739/
[17:05] <jam> so that looks more like you don't have you ssh keys set up properly
[17:05] <jam> it may have been working before because you didn't do "bzr launchpad-login"
[17:05] <jam> (so we were using anonymous http access, rather than authenticated bzr+ssh access)
[17:06] <Odd_Bloke> Myrtti: OK, so you probably did the inital lp:foo branch before running 'bzr launchpad-login'.  So the branches had the http:// location stored (because currently we store the resolved URL, not just the 'lp:foo' bit).  Then you ran launchpad-login, and it's now trying to use bzr+ssh.  But you haven't set up SSH keys with Launchpad.
[17:06] <Myrtti> well that's funny, because it gave me that even before I had logged in
[17:06] <Myrtti> and now that there is a proper ssh key at launchpad, it still doesn't work.
[17:07] <Myrtti> or that's what I think
[17:07] <Odd_Bloke> Myrtti: What does 'ssh<EMAIL_ADDRESS>give you?
[17:08] <Myrtti> Agent admitted failure to sign using the key.
[17:08] <Myrtti> Permission denied (publickey).
[17:08] <jpds> Ah, the seahorse-agent bug.

[17:11] <jpds> bug 328127
[17:12] <Myrtti> that's funny
[17:12] <Myrtti> I'm on intrepid.
[17:12] <Myrtti> >___<
[17:13] <jpds> So am I, I have the same problem :/
[17:13]  * Myrtti checks
[17:14] <Myrtti> gnome-keyring: Installed: 2.24.1-0ubuntu1
[17:15] <jpds> Really odd.
[17:15] <Myrtti> I'm on xfce4 though
[17:16] <Myrtti> and I know about these things about as much as my guinea pigs know about particle physics
[17:19] <Odd_Bloke> Myrtti: Try "SSH_AUTH_SOCK= ssh<EMAIL_ADDRESS>[17:19] <Myrtti> and presto it works
[17:22] <Myrtti> Odd_Bloke: thanks
[17:23] <LarstiQ> abentley: from the standup reports you're not yet in nested territory?
[17:23] <abentley> LarstiQ: No.  Hopefully next week.
[17:25] <Odd_Bloke> Myrtti: :)
[17:25] <Odd_Bloke> Myrtti: Adding a comment on the bug with your version details might be helpful. :)
[17:26] <LarstiQ> abentley: k, I'm paging through a full test suite run log now, deferring most things for later, almost got myself convinced to commit/push the current status
[17:26] <abentley> LarstiQ: Great.
[17:28] <Myrtti> Odd_Bloke: done :-) thanks
[17:29] <pickscrape1> Is bzr-1.12 compatible with bzr-loom 1.4?
[17:30] <pickscrape1> I'm getting this when running bzr status: bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose'
[17:31] <pickscrape1> The backtrace refers to /usr/lib/python2.5/site-packages/bzrlib/plugins/loom/commands.py
[17:31] <Odd_Bloke> pickscrape1: Could you pastebin a more complete error?
[17:31] <pickscrape1> sure
[17:31] <pickscrape1> Is there one for this channel, or should I just paste anywhere?
[17:32] <LarstiQ> any pastebin works
[17:33] <pickscrape1> http://pastebin.ca/1336235
[17:33] <vila> pickscrape1: try updating your plugin I'm pretty sure it has been fixed on trunk
[17:33] <pickscrape1> I was running it direct from apt... I'll uninstall that and grab it manually
[17:33] <vila> pickscrape1: yup, seeing the traceback I'm even more sure :)
[17:35] <pickscrape1> Is bzr-loom available in a PPA anywhere?
[17:36] <vila> I don't  think so
[17:36] <vila> Do you get 1.12 from bzr-ppa ?
[17:36] <vila> Did you get 1.12 from bzr-ppa ?
[17:36] <pickscrape1> vila: yes
[17:36] <vila> pickscrape1: did you get bzrtools too ?
[17:37] <pickscrape1> I had to uninstall bzrtools because 1.11 was never uploaded to the PPA, so currently I have that installed manually
[17:38] <vila> pickscrape1: could you try to install bzrtools from bzr-ppa ?
[17:38] <pickscrape1> vila: yes, I will once I've fixed etckeeper, which has also just started complaining :)
[17:38] <vila> pickscrape1: argh, no wait, the builds aren't finished yet :-/
[17:40] <pickscrape1> OK, using loom trunk has fixed the problem: thanks :)
[17:40] <pickscrape1> etckeeper needed BZR_COMMIT_OPTIONS="--unchanged"
[18:11] <LarstiQ> woops, unlocking other_tree once too many
[18:36] <vila> pickscrape1: bzrtools-1.12 available in bzr-ppa, can you try it ?
[18:37] <pickscrape1> vila: I just did, and it seems to work fine :)
[18:37] <pickscrape1> Thanks for your help
[18:37] <vila> pickscrape1: great, thanks for your test :)
[18:37] <vila> pickscrape1: which os/version/arch are you using ?
[18:38] <pickscrape1> vila: jaunty amd64 and intrepid x86 (tested on both)
[18:39] <vila> pickscrape1: you're my man, two birds with one stone :)
[18:39] <pickscrape1> :)
[19:23] <jfroy|work> jelmer: I was wondering if you had some experience to share with setting up bi-directional bzr-svn syncing.
[19:55] <ronny> jelmer: sup?
[19:57] <jfroy|work> ronny: I believe he's away ATM.
[19:58] <ronny> hmm
[19:58] <ronny> -9 to<PHONE_NUMBER> (<PHONE_NUMBER> 19:45:30 UTC )
[19:58] <ronny> [20:45]        MinceR | A4Tech: no u
[19:58] <ronny> ops
[19:58] <ronny> touchpads + broken syndaemon are hellish
[20:02] <Lo-lan-do> jfroy|work: I'm usung bzr-svn, maybe I can be of help?
[20:04] <jfroy|work> Lo-lan-do: ok, so here's the use case. Project A is hosted in a Subversion repository over which I have little or no control. I want to introduce a Bazaar bridge, of sort, to allow some developers to use Bazaar as their main VCS. However, it is likely some other will continue using Subversion.
[20:04] <jfroy|work> I'm only interested in syncing one branch, the trunk,
[20:05] <jam> vila: ping
[20:05] <jfroy|work> That is, the Subversion trunk with a Bazaar branch, from which Bazaar-using developers would pull and push from.
[20:05] <miracle2k> when I init-repo after I already have branches checked out, can I make them part of the repository, or they I need to re-clone?
[20:05] <jam> miracle2k: check 'bzr reconfigure' I think it has some flags for that
[20:06] <Lo-lan-do> jfroy|work: I think it's simpler for everyone if people just use bzr as a Subversion client then.
[20:06] <jam> jfroy|work: I believe doing:
[20:06] <jfroy|work> miracle2k: AFAIK you need to branch into the repo to get the branch to store its history data in it
[20:06] <jam> bzr co svn+ssh://path/to/trunk
[20:06] <jam> Should "just work"
[20:06] <jam> as in, the developers can commit there, and it will update the subversion trunk
[20:07] <Lo-lan-do> That's exactly what I'm doing, and it seems to works well.
[20:07] <jfroy|work> Lo-lan-do: I see. So each developer would maintain their own Subversion trunk checkout.
[20:07] <miracle2k> jam, jfroy|work: There's a reconfigure --use-shared which I'm gonna try. Thanks.
[20:07] <jfroy|work> miracle2k: ah, good to know, didn't know that existed :)
[20:07] <jfroy|work> jam: thanks for the tip
[20:07] <jam> jfroy|work: it is certainly the easiest way
[20:07] <jam> there are always others
[20:07] <jam> you can also
[20:07] <jam> cd my-local-trunk
[20:08] <jam> bzr pull ../my-branch
[20:08] <jam> and if that succeeds (branches aren't diverged)
[20:08] <jam> it should be the same as doing "bzr push svn://...."
[20:35] <pickscrape1> Was a release email sent out for 1.12?
[20:42] <jam> pickscrape1: I don't think so
[20:43] <jam> Or it was sent, but Martin forgot to approve his email
[20:43] <jam> Let me check
[20:43] <pickscrape1> I just enjoy reading the release notes is all :)
[21:08] <jam> pickscrape1: http://doc.bazaar-vcs.org/bzr.1.12/en/release-notes/NEWS.html#bzr-1-12-1234567890-2009-02-13
[21:08] <jam> Or to see the on-going one: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html
[21:08] <pickscrape1> jam: thanks
[21:28] <jam> lifeless: to your earlier question, "groups" do not get +junk branches:
[21:28] <jam> bzr: ERROR: Permission denied: "/~bzr/+junk/bzr-groupcompress": : +junk branches are only available for individuals. Please consider registering a project for collaborating on branches: https://help.launchpad.net/Projects/Registering
[21:29] <zsquareplusc> bzr 1.12 and olive? i get errors on my ubuntu box. for example the log windows are shown, but the log itself is never shown
[21:30] <jam> as such, I went ahead and created: https://edge.launchpad.net/bzr-groupcompress
[21:31] <jam> since I needed to do a couple patches to the plugin
[22:44] <jelmer> ronny: hi
[22:44] <jelmer> jfroy|work: hi
[22:45] <jfroy|work> hey
[22:45] <jfroy|work> As you can read in your history, my question was mostly answered, unless you have something to add to Lo-lan-do's recommendation.
[22:54] <jelmer> jfroy|work: ah, sorry, hadn't seen that
[22:54] <jelmer> jfroy|work: yeah, his answer seems to cover it all - just pretend the svn branch is a bzr branch and all should be well
[22:55] <ronny> re
[22:56] <jfroy|work> jelmer: just need to make sure the other developers who wish to use bzr understand they really need to not use a bound branch for daily work, because operations on that branch will be *slow*.
[22:56] <jfroy|work> Your standard "train them a bit" situation, I suppose.
[22:58] <ronny> jelmer: im at the final point of vcs unhappyness, all reasonable vcs's have at least one major pain point i dont want to be brothered with
[23:16] <jelmer> jfroy|work: just tell them to use 0.5.1, which will be lightning-fast
[23:16] <jelmer> ronny: yeah, it's tricky to get right :-/ a task-specific API is probably easier than a generic one like anyvc
[23:17] <ronny> jelmer: nah, also all common vcs's have at least one fail that makes me hate them
[23:23] <jfroy|work> jelmer: is that so?
[23:24] <jfroy|work> (this is a worst case scenario, the svn server is still 1.4 with no plan to upgrade to 1.5 anytime soon :p )
[23:41] <sri> so..
[23:41] <sri> is there a irc hannel for paramiko?