[12:29] <ogra> :))
[12:30] <pygi> Backing up itself:
[12:30] <pygi> ... recognized CD-RW ... blanks it ... burns ... verifies ok.
[12:31] <pygi> libburn-on-cdrecord, weeee :)
[12:36] <sbalneav> ogra: I sent off the lbmount to pitti.
[12:36] <sbalneav> here's for you
[12:36] <sbalneav> sent
[12:36] <sbalneav> hopefully, this will address all his concerns!
[12:42] <cbx33> ogra, I am so sorry about before....I just totally mis-read it
[12:42] <cbx33> and I didn't need to implement the message numbers
[12:42] <cbx33> because of the way it is now done
[12:44] <cbx33> using signals and callback handlers
[12:50] <ogra> sbalneav, ltspfsmounter done in python ... i'm working on the cleanup function now ... and add the bits to ldm locally
[12:51] <sbalneav> Dude!
[12:52] <cbx33> ogra, how are we going to start process for execute and detach them from python?
[12:52] <sbalneav> and you'll send me your new bits tonight so I can play play play, right?!?!? :)
[12:52] <Laser_away> easy boy ;-)
[12:56] <ogra> sbalneav, doing now, not sure if i have the power to go on hacking after the meeting
[12:57] <sbalneav> this a private meeting?
[12:57] <rodarvus> sbalneav, nope, ubuntu developers team weekly meeting
[12:57] <rodarvus> starting in 3 minutes on #ubuntu-meeting
[12:58] <sbalneav> I might pop in for a bit.
[12:58] <ogra> sent
[12:58] <sbalneav> thanks ogra, things are REALLY starting to look good.
[12:59] <mhz> neurogeek: hi there
[12:59] <ogra> yeah
[12:59] <neurogeek> mhz, how is it going??
[12:59] <ogra> now the floppies and we're done :)
[01:00] <cbx33> :)
[01:00] <cbx33> well done guys
[01:00] <ogra> well, the floppy part can still be hairy :)
[01:00] <ogra> oh, and we dont have a queueing solution yet for pre-plugged devices ...
[01:00] <cbx33> I don;t know how you've managed to do that....and put up with me whinging about SCP and dbus
[01:01] <mhz> neurogeek: just passing by a cibercafe ...
[01:01] <mhz> neurogeek: but good thx
[01:02] <cbx33> nn all
[01:02] <neurogeek> mhz glad to hear that.. when are you planning on having inet at home again?
[01:03] <mhz> neurogeek: uuufff, as soon as I can afford to move to an apartment :(
[01:04] <neurogeek> why is that? you have to move out?
[01:04] <mhz> neurogeek: i have even tried to get web access from a neighbours' but distance was to large
[01:05] <neurogeek> mhz, have you tried to build a home-made antenna?
[01:07] <mhz> neurogeek: hmm, not yet, mainly because I should be moving anyways. Actually, I should have moved 2 months ago, at least.
[01:08] <neurogeek> mhz, ok.. good luck then
[01:08] <mhz> hehehe
[01:09] <mhz> neurogeek: thx
[01:09] <mhz> neurogeek: how about you? SMS? other apps?
[01:12] <neurogeek> mhz, well, im working on a lot of stuff right now.. SMS is a pain because of the contracts.. plus im learning french.. jejeje very difficult i have to say..
[01:23] <mhz> neurogeek: indeed, but not so much when you already master at least another lang besides your mother tongue.
[01:24] <mhz> and not as difficult as learning Chineese or Janpaneese, or any alike (Russian even)
[01:24] <mhz> :)
[01:25] <neurogeek> well thats true.. but man.. in spite.. that d**n difficult
[02:00] <bddebian> Howdy
[02:01] <ogra> sbalneav, you got mail :)
[02:01] <sbalneav> Cool
[02:01] <sbalneav> checking
[02:02] <sbalneav> So, was it a good meeting?
[02:02] <ogra> sorry for the broken version ...
[02:02] <ogra> sure :)
[02:02] <ogra> i'm always happy if i survive the thursday meeting ;)
[02:04] <sbalneav> :( Do you sometimes not survive?
[02:05] <ogra> sure i do ... but thats the day where mdz usually asks the hard questions ... :)
[02:08] <sbalneav> ahhhh
[02:08] <sbalneav> :)
[02:14] <ogra> ltspfs /tmp/.ogra2-ltspfs/usbdisk-sda1 fuse rw,nosuid,nodev,user_id=1002,group_id=1002 0 0
[02:14] <ogra> ltspfs /media/ogra2/usbdisk-sda1 fuse rw,nosuid,nodev,user_id=1002,group_id=1002 0 0
[02:14] <ogra> hmm
[02:14] <ogra> intresting
[02:14] <ogra> there is no bind mount at all
[02:15] <ogra> ohh
[02:16] <ogra> as the user who did the bindmount i see it ...
[02:16] <ogra> if i'm not the user i see it as ltspfs mount :)
[02:16] <ogra> thast transparency ... :P
[02:17] <ogra> but thats very sexy for the cleanup
[02:17] <ogra> ogra@edubuntu:~$ cat /proc/mounts |grep ltspfs|grep ogra2|awk '{print $2}'
[02:17] <ogra> /tmp/.ogra2-ltspfs/usbdisk-sda1
[02:18] <sbalneav> yeah, the bindmount's nice that way
[02:18] <ogra> oh, ah ... its different in the output of mount ...
[02:19] <ogra> mount actually shows the bind mount
[02:19] <ogra> /proc/mounts has it as ltspfs mount
[02:19] <ogra> so we just need to unmount all ltspfs mounts that match $USER from /proc/mounts ... easy :)
[02:29] <sbalneav> yep!
[02:30] <sbalneav> but, we'll need to use the lbmounter on the bind mount one, because it will need su
[02:31] <sbalneav> man!  2:30 am your time!  I hope you sleep in!
[02:51] <ogra> cleanup code done ...
[02:51] <ogra> i'll mail it to you and go to bed ;)
[02:52] <ogra> i also removed the special cdrom handling ... pitti should solve it
[02:53] <sbalneav> excellent
[02:53] <ogra> sbalneav, i just discovered a horrible thing :/
[02:53] <sbalneav> oh noes!
[02:53] <sbalneav> what?
[02:54] <ogra> ogra@edubuntu:~/devel/ltspfs/ltsp-localdev-scott$ ls -l /media/|grep ogra
[02:54] <ogra> drwx------ 2 ogra2 ogra2 4096 2006-08-18 02:52 ogra2
[02:54] <ogra> what do you see ?
[02:54] <sbalneav> um, an ogra2 directory?
[02:55] <ogra> ogra@edubuntu:~/devel/ltspfs/ltsp-localdev-scott$ su ogra2
[02:55] <ogra> Password:
[02:55] <ogra> ogra2@edubuntu:/home/ogra/devel/ltspfs/ltsp-localdev-scott$ mkdir /media/ogra2/blupp
[02:57] <ogra> ogra2@edubuntu:/home/ogra/devel/ltspfs/ltsp-localdev-scott$ ltspfs <IP_ADDRESS>:/tmp/drives/usbdisk-sda1 /media/ogra2/blupp
[02:57] <ogra> xauth:  timeout in locking authority file /home/ogra/.Xauthority
[02:57] <ogra> well, i cheated and su'ed ...
[02:58] <ogra> but blupp is mounted ...
[02:58] <ogra> and i see the file contents
[02:58] <ogra> our suid wrapper only needs to create the subdir :/
[02:58] <sbalneav> that's all it does, and the bindmount
[02:59] <ogra> we dont need the bindmount
[02:59] <ogra> thats what i mean
[02:59] <ogra> the user has full rw permissions ... so i can create subdirs and just use ltspfs directly...
[02:59] <ogra> as user
[02:59] <sbalneav> well, that makes it simpler! :)
[03:00] <ogra> right
[03:00] <sbalneav> lol
[03:00] <sbalneav> ok
[03:00] <ogra> but we wasted a lot of time for the bind stuff :(
[03:00] <sbalneav> meh
[03:00] <sbalneav> you say wasted time, I say "learned what not to do!"
[03:00] <sbalneav> :)
[03:00] <ogra> heh, ok
[03:00] <sbalneav> hey: whatever gets us a good solution.
[03:01] <sbalneav> ok, I'll hack on that tonight.
[03:01] <sbalneav> anything more to send me before you pass out?
[03:02] <ogra> i'll send you what i have canged in ltspfsmounter
[03:03] <ogra> sent
[03:09] <sbalneav> goin' to bed?
[03:12] <ogra> yep
[03:12] <ogra> now
[03:12] <ogra> its not removing the dirs set on cleanup ...
[03:13] <ogra> but thats trivial ...
[03:15] <sbalneav> I'll play with it tonight.
[03:17] <ogra> night
[03:18] <ogra> oh, btw, thats solves the two cdrom issue as well ...
[03:18] <ogra> (now i'm off ... really !)
[03:20] <sbalneav> you're a str
[03:20] <sbalneav> star
[04:16] <sbalneav> back.  Developing on edubuntu now.
[09:04] <RichEd> greetz
[09:05] <jsgotangco> hi
[09:06] <RichEd> highvoltage: busy recovering from a machine hang & hard reboot :(
[09:07] <jsgotangco> RichEd: https://lists.ubuntu.com/archives/edubuntu-devel/2006-August/001675.html
[09:07] <RichEd> hi jsgotango ... comment was for you ... autocomplete picked up the voltage part !
[09:07] <jsgotangco> oh!
[09:08] <RichEd> give me a minute or two ... just getting my work back into shape to start my day ...
[09:08] <RichEd> opening your link now & email in a few secs.
[09:08] <highvoltage> RichEd: :(
[09:09] <highvoltage> especially on #ubuntu
[09:10] <RichEd> 'lo ... maybe you should convert to lowvoltage ... especially given the western cape electricity situation
[09:11] <highvoltage> there already is a lowvoltage
[09:13] <RichEd> watt a pity ;)
[09:13] <highvoltage> heh, i nearly didn't get that :)
[09:13] <RichEd> jsgotangco: how is your day looking ? can we shift our time to the top of the next hour ?
[09:14] <RichEd> i'm goping to do some urgent email ... and then try to get skype working
[09:17] <jsgotangco> RichEd: sure but i'll be out in 2 hours from now im going to have a haircut
[09:18] <jsgotangco> and ill be without net access till monday
[09:18] <RichEd> no problem. 42 mins and counting ...
[09:58] <RichEd> 10 mins
[10:02] <jsgotangco> sure sure :)
[10:02] <jsgotangco> ive already sent email reply, purchased something online and tested a webapp being developed for a client :)
[10:03] <jsgotangco> all done while listening to Judas Priest ;)
[10:04] <RichEd> yep ... can't get quaity work like that done to britny !
[10:17] <RichEd> jsgotangco: revising my last email ... then i'm yours
[10:32] <RichEd> ping jsgotangco ... (at last) ...
[10:34] <jsgotangco> hi
[11:11] <jsgotangco> RichEd: thanks for the time
[11:18] <RichEd> jsgotangco: my pleasure
[11:19] <RichEd> greetz willvdl
[11:19] <RichEd> am going to mail you case study doc format now
[11:20] <RichEd> followed by a high level steps forward project plan ... to you and cbx33 = pete savage
[11:20] <willvdl> greetings
[11:21] <willvdl> the mail from Maning on edubuntu-devel has got me thinking
[11:21] <RichEd> yep ... i want to factor that in ... and corey's response ....
[11:21] <RichEd> and a user mail i got with good priase for home kids use
[11:22] <willvdl> cool.
[11:23] <willvdl> did you get the evaluation I sent you yesterday?
[11:26] <jsgotangco> the email from Maning is a reflection of the overall situation here
[11:26] <willvdl> jsgotangco: I liked your reply
[11:27] <willvdl> I remember highvoltage coming across a wikipedia bundle put together by the red cross childrens' hospital
[11:27] <jsgotangco> an LTSP setup here is quite unknown
[11:27] <jsgotangco> the wikipedia DB is not big, but the images are
[11:28] <jsgotangco> if you merge the data + media it may span to more than 4 DVDs
[11:28] <willvdl> in tuXlabs we got reprimanded because some child stumbled across a hand-drawn karma sutra page
[11:29] <jsgotangco> yeah wikipedia has that
[11:29] <willvdl> Was amusing but serious at the same time
[11:30] <jsgotangco> the wikipedia maybe useful for current events, but wikibooks seems a saner option
[11:30] <willvdl> We packaged an offline snapshot (not the whole thing) and therefore were responsible for the content we provided
[11:31] <RichEd> jsgotangco: skype up & working ... just added you to my contacts
[11:31] <willvdl> The idea of using a snapshot the someone like Red Cross have gone through by hand is quite enticing
[11:31] <RichEd> we'll give it a go on tuesday ... okay ?
[11:31] <jsgotangco> sure thing
[11:31] <RichEd> willvdl: yep got the mail ... goiong through them all now
[11:33] <willvdl> It's a nice read. especially the recommendations if you just want to scan
[11:46] <RichEd> coffee time comedy note ... have you guys heard this ? http://www.spaff.com/poesy/blog.html
[11:47] <RichEd> I BLOG ALONE ~ Parody of Green Day's "Boulevard of Broken Dream
[11:48] <willvdl> MY eyes! It burns! It burnses
[11:48] <jsgotangco> agghhh
[11:48] <jsgotangco> my virgin eyes@!
[11:48] <RichEd> listen ... don't look :)
[11:49] <willvdl> too late. it's burnt into my eyelids
[11:50] <jsgotangco> RichEd: what's your skype ID?
[11:51] <RichEd> richard.edubuntu
[11:51] <jsgotangco> Cape Town, Somalia???
[12:16] <RichEd> Cape Town, Somalia ??? RichED checks outside his window
[12:19] <willvdl> Toto, RichEd's not in Kansas anymore
[12:20] <RichEd> no UN observers spotted ... can't be somalia
[12:57] <rodarvus> good morning
[03:01] <sbalneav> ogra: pingity!
[03:03] <ogra> sbalneav, pongity
[03:03] <ogra> did you notice that ubuntu uses dash as default shell ?
[03:04] <ogra> no bashisms allowed :/
[03:04] <sbalneav> Dash?
[03:04] <sbalneav> No I didn't
[03:04] <ogra> so we need to keep the tr pipe ...
[03:04] <ogra> sorry
[03:05] <sbalneav> Thats ok
[03:05] <ogra> another big prob i have here is that we move /tmp around during boot
[03:05] <sbalneav> But, I had a better idea for the ldm...
[03:05] <ogra> so .delayed-mount gets lost
[03:05] <sbalneav> ?!
[03:06] <ogra> tmop gets bind mounted into a tmpfs during boot
[03:06] <ogra> *tmp
[03:06] <ogra> so it becomes rw
[03:06] <ogra> .delayed-mount doesnt get copied along ...
[03:06] <sbalneav> ah, ok, I didn't try right from a cold powerup
[03:06] <ogra> if you plug in before login while ldm is up, all is fine
[03:07] <sbalneav> that's what I was testing.
[03:07] <ogra> but pre plugged doesnt work ... i'm hunting :)
[03:07] <ogra> and cdpinger needs to use .delayed-mount as well
[03:07] <ogra> i wonder how evil it woud be to write to /dev
[03:07] <ogra> (.delayed-mount i mean)
[03:08] <ogra> dev is already a tmpfs in the initramfs and doesn tget moved anymore
[03:08] <ogra> /var/run should also be possible
[03:08] <ogra> whats your idea for ldm ?
[03:08] <ogra> i have the code we discussed yesterday running here ... works fine
[03:09] <sbalneav> about the other, though, we should make an exit script call in ldm.  After the fork, we could call something like "post-login-ldm", set up a small script similar to Xsesssion that will go through a post-ldm.d dir, and execute stuff in there.  That way, if we come up with more stuff that needs to be done post-login, it's easy to add (just drop script in post-ldm.d)
[03:10] <ogra> yup, i thought the same ... but thats a bit much for now ... lets keep it in mind ...
[03:10] <ogra> we cant rewrite the whole of ltsp in one chunk :)
[03:10] <sbalneav> is it getting too close to freeze to make that change to ldm?
[03:10] <ogra> ldm will get a lot of other stuff as well ...
[03:11] <ogra> no, but i'm running out of time
[03:11] <ogra> we need to get finished
[03:11] <ogra> i have 12 sepcs or so ... and only until 7th of sept
[03:11] <sbalneav> ok, then lets stick with delayed-mounter, we just need to figure out where to put .delayed-mount
[03:11] <ogra> and i work extensively on one
[03:11] <sbalneav> Well, I'll of course help with them all :)
[03:11] <ogra> sure
[03:12] <ogra> but still ... not much time left
[03:12] <ogra> i'll do some testing which dir might be appropriate
[03:12] <sbalneav> absolutely.  So, if pitti approves the lbmount, lets just stick with the bindmount for not.
[03:12] <sbalneav> now
[03:12] <ogra> yep
[03:13] <ogra> if he would approve ltspfs/d, then i could finally move on and add the scripts to the packages :/
[03:13] <ogra> its still not in main ...
[03:13] <ogra> i feel a bit stuck currently in that area ...
[03:14] <sbalneav> ok.  I think all we need to do for floppies (legacy) is a udev rule (ive got one allready), and a simple if [ -f /dev/floppy ] ; then /lib/udev/add_fstab_entry floppy vfat; fi
[03:14] <ogra> no
[03:14] <ogra> s/vfat/auto/ please
[03:14] <ogra> but the rest looks fine ...
[03:15] <ogra> what do we do about unmounting ?
[03:15] <sbalneav> ltspfsd handles is, remember? :)
[03:15] <ogra> the bindmount ?
[03:16] <sbalneav> that will get done during the add_fstab_entry.
[03:16] <ogra> the removal of the bind mount :)
[03:16] <sbalneav> your cleanup bit
[03:16] <ogra> hmm
[03:16] <sbalneav> ssh ... && ltspfsmounter cleanup
[03:17] <ogra> so the floppy stays on the desktop all the session
[03:17] <sbalneav> sure
[03:17] <ogra> ah
[03:17] <ogra> ok
[03:17] <sbalneav> there's no way to check for media with floppies
[03:17] <ogra> yes
[03:17] <ogra> thast what i meant
[03:17] <sbalneav> yeah, what we do on stock is just put it there.
[03:18] <sbalneav> worstcase is, they click on it with no drive, and the floppy drive rattles :)
[03:18] <ogra> yup, understood
[03:18] <sbalneav> simple, elegant, and workable.
[03:18] <ogra> well, elegant would be to have feedback from the HW like on cdroms ;)
[03:18] <ogra> but its the best we can have :)
[03:19] <sbalneav> yeah, but floppies have been broken for media detection for, oh, say 20 years, so I don't think we can solve that one :)
[03:20] <sbalneav> we could conceivably have this finished up tonight.
[03:20] <ogra> well ... we could invent an extension kit and ship ubuntu special floppy edition CDs with a soldering iron and a little circuit ;)
[03:20] <sbalneav> lol
[03:20] <sbalneav> I'll get right on it :)
[03:20] <ogra> heh
[03:20] <sbalneav> what'll be next after this, nbd swap?
[03:21] <sbalneav> or the dhcp autoconfig?
[03:21] <ogra> dhcp autoconfig is only installer hacking
[03:21] <ogra> well, fsvo only :)
[03:21] <ulisse> ciao
[03:22] <ogra> tast something i need to build many test CDs for etc
[03:22] <ogra> ndb swap i would say ... but i need to see what rodarvus has already, we'll do that at the sprint
[03:22] <ulisse> is it possible to have local sound on terminals? I only can play sounds thru the server...
[03:22] <sbalneav> sprint's next week?
[03:22] <ogra> yes
[03:22] <ulisse> with ltsp, I mean...
[03:23] <ogra> starting sunday
[03:23] <sbalneav> ulisse: what is it you're trying to do?
[03:23] <ogra> ulisse, create a lts.conf file in /opt/ltsp/i386/etc/
[03:23] <ogra> add:
[03:23] <ogra> [default]
[03:23] <ogra> SOUND=True
[03:23] <ogra> then all your clients will use local sound output
[03:24] <sbalneav> Oh, I see what he's saying, I was thinking he meant running a local sound app like skype or something/
[03:24] <sbalneav> ulisse: yep, that will work.
[03:25] <ogra> student-control-panel completion is high priority ... i should have that done by end of the month as well
[03:25] <rodarvus> ogra, was scp approved at all?
[03:25] <rodarvus> (or i'm mixing scp with ltspmanager?)
[03:25] <ogra> and i can probably add the ldm-post-session.d thingie afterwards if i have the time to target ltsp-login-and-session-handling
[03:25] <sbalneav> ogra: someone else was working on it yesterday, I think.  cbx33 i beleive?  Anything I can help with that?
[03:26] <ogra> rodarvus, no, but that doesnt matter as long as its approved in the end
[03:26] <sbalneav> morning rodarvus
[03:26] <ulisse> YEAH! It's working! Thanks ogra and sbalneav :)
[03:26] <ogra> well, he does the biggest part (dbus integration) atm ...
[03:26] <ogra> the other stuff is rather trivial
[03:26] <rodarvus> hi sbalneav!
[03:27] <ogra> ltsp-manager is something i can work on after freeze ... its in universe and will stay theer for edgy
[03:27] <sbalneav> guess my question is: what would YOU like me to start poking on after we get localdevs done?
[03:27] <ulisse> I had already tried sthg similar, but with an older/different howto I found at ltsp.sourceforge.net... it didn't work
[03:27] <ogra> sbalneav, https://launchpad.net/people/ogra/+specs pick what you like :)
[03:28] <sbalneav> rodarvus: how much have you done on pulling across our patches into nbd?
[03:28] <ogra> sbalneav, but i think we should rather see that we get you up to speed with packagin ... make you a member and motu so you can package and upload ;)
[03:28] <sbalneav> well, that too.
[03:28] <sbalneav> :)
[03:28] <ogra> :)
[03:29] <rodarvus> sbalneav, this was the easy part, mostly done
[03:29] <sbalneav> ok, cool
[03:29] <rodarvus> I just have to cleanup it, and send upstream
[03:30] <rodarvus> well, I propose sbalneav to apply for ubuntu-devel, on next CC meeting
[03:30] <rodarvus> ogra and I will surely cheer for you :)
[03:30] <ulisse> hmm... other question (I'm quite new to ltsp...): is it possible to access local drives? (hd, cdrom...)
[03:30] <sbalneav> ulisse: hehe
[03:30] <sbalneav> we're working on is AS WE SPEAK!! :)
[03:31] <sbalneav> hang around and watch the exciting development!
[03:31] <ulisse> wow! So it is better if I let you work... :)
[03:31] <sbalneav> Not for dapper, but it will be in edgy.
[03:31] <ulisse> np, I'll wait
[03:31] <sbalneav> We promise it will be very sexy :)
[03:32] <ogra> rodarvus, he needs to become member first :)
[03:33] <rodarvus> right. that too >:-)
[03:33] <ogra> (but tat shouldnt be *any* problem :) at least with the EC )
[03:33] <rodarvus> indeed
[03:33] <rodarvus> edubuntu-membership automatically gives ubuntu membership, doesn't it?
[03:33] <ogra> the meeting after the sprint is an EC one
[03:34] <ogra> yep
[03:35] <ogra> bah, i got s used to listen to my music from the thin client from a usb disk that it starts to annoy me to develop on the scripts :P
[03:35] <ogra> since i need to stop the music all the time :)
[03:35] <ogra> i need more hardware !
[03:35] <sbalneav> ogra: I think once we get the .delayed-mount issue sorted, and the quicky bit in for floppies, we're basically done, yes?
[03:36] <ogra> yep
[03:36] <sbalneav> ogra: want another thin client? I can bring you one in Sept!
[03:36] <ogra> i have a bunch here
[03:36] <ogra> i just dont want to clutter the new office with tube monitors ...
[03:37] <ogra> so i need new LCDs ... but amd currently a bit short on money
[03:37] <ogra> (the move costed a lot)
[03:37] <sbalneav> ah, you need flatpanels then!  I'll see if I can dig you one up.
[03:37] <sbalneav> I think I have one I can give you.
[03:37] <ogra> thick i can get it in a plane nowadays ?
[03:37] <ogra> you know the L in LCD stands for liquid ;)
[03:38] <sbalneav> Sure, just check it, not carry on :)
[03:42] <ogra> sbalneav, btw, did you test ssh with cipher=none ?
[03:43] <sbalneav> heh, did some testing at home
[03:43] <ogra> and ? does it speed up as you thought ?
[03:44] <rodarvus> I'm considering buying a LCD in Wiesbaden
[03:44] <sbalneav> my rough calculation is...
[03:44] <rodarvus> ogra, how much do you pay for a reasonable 19" LCD in Germany?
[03:45] <ogra> rodarvus, nice, lets go shopping :)
[03:45] <rodarvus> heh :)
[03:45] <sbalneav> if we run with cipher = none, at 15 terminals you're only getting 20% more load than by just using gdm
[03:45] <ogra> the one i brought to paris costed ~220
[03:45] <sbalneav> so, performance wise I think it'd be good to push for,
[03:45] <ogra> it as a special offer at a HW discounter here
[03:46] <sbalneav> but, if the ssh maintainer doesn't want to include it by default, at a bare minimum, we should write up a howto on how to patch it, for the adventurous who want the performance.
[03:46] <ogra> sbalneav, well, i dounbt we can convince the debian and ubuntu ssh mantainers. ...
[03:46] <ogra> but lets try :)
[03:47] <sbalneav> I think it would be well worth the effort to at least explain the reasoning.
[03:47] <ogra> sure
[03:48] <ogra> thats not the point ... i'm sure Kamion will understand it well ... but having the possibility to drop all cipher will be considered harmful by him, i'm pretty sure
[03:49] <sbalneav> yeah, but it would be a very deliberate action on the users part.
[03:49] <ogra> well, it will be one value to change in an upcoming ldm.conf :)
[03:50] <sbalneav> keep all the config files the same so that None wouldn't be recognized.  They'd have to edit /etc/ssh/sshd_config on the server, AND specify ssh -C ...,None on the command line when sshing.
[03:50] <sbalneav> not something likely to happen by accident :)
[03:50] <ogra> true
[03:51] <sbalneav> I mean: you can also do an apt-get install telnetd in ubuntu, also a very deliberate act. :)
[03:52] <ogra> rodarvus, thats a cheap discounter you find in nearly every city in germany: http://www.mediaonline.de/shop/category_5000_5000_-3_5000.13012.13014
[03:52] <rodarvus> LCD monitors are *quite* expensive in Brazil :/
[03:53] <ogra> they start at 180 it seems
[03:53] <rodarvus> 180 would be an excellent price!
[03:53] <ogra> sbalneav, right ... lets wait for Kamion ...
[03:54] <rodarvus> I'll be right back
[03:55] <sbalneav> ogra: I'll throw an lcd in my luggage.
[03:55] <ogra> woah ..
[03:56] <ogra> you really dont need to, you know that !
[03:58] <sbalneav> No problem: anything I can do to make your life better.
[04:00] <RichEd> ogra: all set for the sprint ?
[04:00] <RichEd> (hi)
[04:00] <ogra> RichEd, not yet ... (i only have to drive 250km)
[04:01] <ogra> thats quickly prepared :)
[04:01] <sbalneav> In his Porche
[04:01] <ogra> i hope so ...
[04:01] <sbalneav> Which, so I understand, will bring him :)
[04:01] <ogra> the valves are rattling quite evil
[04:01] <rodarvus> I wonder whats the distance from Curitiba to Wiesbaden
[04:01] <ogra> need to adjust them ...
[04:02] <RichEd> well have fun on the autobahn ... rattles and all !
[04:02] <ogra> if i dont find the time tomorrow, i will take the citroen ...
[04:02] <rodarvus> ogra, take care on your way to Wiesbaden.
[04:02] <ogra> sure :)
[04:03] <ogra> its only german motorways ... nothing to fear :)
[04:04] <rodarvus> right
[04:04] <rodarvus> in Brazil you are not allowed to drive faster than 110 km/h
[04:04] <rodarvus> there is only one freeway in the whole country where you can drive a little faster: 120 km/h
[04:05] <ogra> heh
[04:06] <rodarvus> medium sized trucks: 100 km/h. big trucks, 80 km/h. huge trucks, 60 km/h (and 30 km/h on hills)
[04:06] <ogra> in germany you are a hazard with 120 ... you can either line up with the trucks with 100 on the right lane or need to drive faster ...
[04:06] <sbalneav> ogra: just looking at the Xnest bug needed for the sabayon bit.  If I start Xnest on a terminal, it works fine.  So maybe it's just the way sabayon's STARTING the xnest?
[04:07] <ogra> sbalneav, thats what i suspected ... but even that might be gone already
[04:07] <ogra> i didnt look into it yet and was planning it for post freeze ... its a bugfix, not freeze critical
[04:07] <ogra> so it has a bit more time ...
[04:09] <ogra> right, works fine here as well
[04:11] <sbalneav> Well, that's good.  Fix is likely to be easy then.
[04:11] <ogra> i dont want to install sabayon now, but i bet it works already :)
[04:30] <sbalneav> ogra: you want 1024x768 or 1280x1024? :)
[04:40] <ogra> i have 1280x1024 already ...
[04:40] <ogra> oh, pitti pinged in query
[04:42] <ogra> meh
[04:42] <ogra> he wont approve ltspfs and ltspfsd before next week ...
[04:43] <sbalneav> is he going to audit them?
[04:44] <ogra> well, he usually only looks at security bugs etc
[04:44] <ogra> and at the packging
[04:44] <ogra> i hope he doesnt start auditing the code because he feels like
[04:49] <ogra> urgh
[04:49] <ogra> indeed he did audit the code ...
[04:50] <sbalneav> did he send you an email?
[04:51] <ogra> nope
[04:51] <ogra> he talks to me in pm
[04:51] <ogra> he needs to rush out sapparently
[04:53] <ogra> sbalneav, https://wiki.ubuntu.com/MainInclusionReportLtspfs
[04:54] <ogra> sbalneav, https://wiki.ubuntu.com/MainInclusionReportLtspfsd
[04:54] <ogra> he added comments ...
[04:55] <ogra> no biggies on first sight (but dont ask for second :P )
[04:56] <sbalneav> ah, ok, just the sprintf stuff.
[04:56] <sbalneav> I can fix that today.
[04:57] <ogra> yay
[04:58] <ogra> Keybuk promotes them anyway :)
[04:58] <ogra> now they are in main :)
[04:58] <sbalneav> ah, well, we'll fix pitti's concerns anyway.  Good to be nice to pitti.
[04:58] <ogra> so i can add all the scripts to the packages ....
[04:59] <ogra> right, but its always an un-calculatable value if he's involved ...
[04:59] <ogra> you never know what he finds ...
[04:59] <ogra> might take you days to get it right :)
[05:01] <sbalneav> heh, I'd rather that than a sloppy guy who passes everything.  The two thing he flagged are a 1/2 hour's work.  I'm heading home in 1/2 hour to take delivery of a mattress, so I'll get to them then.  I'll let you know when you can do a cvs pull/repackage.
[05:01] <ogra> good
[05:03] <bddebian> Hello
[05:06] <sbalneav> Hello bddebian
[05:07] <sbalneav> ok, I'm going to start heading home.  I'll log in once I get myself oganized.  Expect me again in an hour.
[05:07] <bddebian> Hi sbalneav
[05:07] <sbalneav> see you all in a bit.
[05:07] <ogra> ciao
[05:09] <willvdl> ping RichEd
[05:16] <lucasvo> what do I need to get localdevices working(dvd)?
[05:17] <ogra> a bit of patience :)
[05:17] <lucasvo> ogra: currently not in edgy?
[05:19] <ogra> nope, not yet
[05:19] <ogra> the ltspfs packages moved to main about 30min ago
[05:19] <ogra> now the scripts need to be added there
[05:19] <ogra> and sbalneav has to do some small fixed on the suid wrapper we use
[06:25] <sbalneav> Back again
[06:28] <highvoltage> sbalneav: wb
[06:31] <ogra> sbalneav, .delayed-mounts must move to /var/run ... and we need to create the /tmp/drives/mountpoint dirs for them in delayed_mounter ... working on it
[06:32] <sbalneav> Awesome.  One supposes /var/run would be the "proper" FHS standard place for them anyway
[06:33] <ogra> /var/run is used by udev as well, so we can always be sure thats available at any time
[06:33] <ogra>  /tmp sadly changes during boot
[06:34] <ogra> argh
[06:34] <ogra> as fstab does
[06:34] <ogra> gah
[06:34] <ogra> thats why it doesnt mount ... damned
[06:35] <ogra> well ...  i guess we need to enhance the format of .delayed-mounts so we can create an fstab entry if its not there yet
[06:36] <ogra> this bind mounting stuff to have rw files is hard :/
[06:43] <sbalneav> He's just marking dead pages in the garbage collector.  We all need it from time to time :)
[06:44] <highvoltage> absolutely
[07:10] <pygi_> anybody have some time to test something for me? :)
[07:11] <highvoltage> pygi: depends what :)
[07:11] <pygi> highvoltage, "libburn-on-cdrecord" layer
[07:12] <highvoltage> how do i do that?
[07:12] <highvoltage> i don't have any bandwidth though :/
[07:12] <highvoltage> i'm on gprs :(
[07:13] <willvdl> eek
[07:13] <pygi> highvoltage, ah, later then :)
[07:13] <willvdl> was wondering what you did for bw
[07:13] <pygi> thanks for good will tho
[07:14] <highvoltage> lol @ good will
[07:14] <highvoltage> nice pun
[07:18] <jsgotangco> gprs eekkk
[07:19] <pygi> highvoltage, just you laugh ^_^
[07:21] <highvoltage> jsgotangco: it's how i've been connecting from home for almost the last year now :(
[07:21] <highvoltage> willvdl: i'm actually thinking of getting a WBS card
[07:21] <jsgotangco> huh? you must have loads of cash to do that
[07:21] <willvdl> eeeeeek
[07:21] <highvoltage> jsgotangco: it's cheaper in south africa than the rest of the world
[07:22] <jsgotangco> i can imagine considering the state of wired telecoms there
[07:22] <pygi> jsgotangco, lots of competition :)
[07:22] <highvoltage> it costs between R0.50 and R2 per MB, depending on which package you are
[07:22] <highvoltage> divide R by 6 for US$
[07:22] <willvdl> highvoltage: mweb have a _decent_ish offering
[07:22] <highvoltage> willvdl: i'm contemplating that too
[07:22] <jsgotangco> is 3G still expensive there?
[07:23] <highvoltage> 3g is the same price as gprs, basically
[07:23] <willvdl> it's still vodacom
[07:23] <highvoltage> willvdl: but i have to sign the contract with mweb ;)
[07:23] <highvoltage> you're right though. their offer does look good
[07:23] <highvoltage> they say on mweb's website that it's HSDPA
[07:23] <jsgotangco> why not get an HSDPA card
[07:24] <highvoltage> jsgotangco: that's the plan :)
[07:24] <willvdl> jsgotangco: I have one. it is slightly more expensive but getting HSDPA speed is a myth
[07:24] <highvoltage> we use the terms HSDPA/3G fairly interchangably here
[07:24] <willvdl> or a female moth
[07:24] <highvoltage> heh
[07:24] <jsgotangco> heh
[07:25] <willvdl> mybroadband.co.za has cool section on getting cards to work on linux
[07:25] <jsgotangco> hmm is it just me or is it that planet ubuntu is like a spammer lately >:D
[07:26] <highvoltage> how so?
[07:27] <highvoltage> i think it sux a bit that people aren't using real hackergotchis :/
[07:27] <pygi> soon you'll see k3b without cdrecord :)
[07:29] <highvoltage> jsgotangco: wow, i see what you mean
[07:29] <highvoltage> seems like Ubuntu Demon is taking out his forum-habits on his blog!
[07:29] <pygi> highvoltage, http://img520.imageshack.us/img520/7821/cdrskink3bxu3.gif
[07:29] <pygi> enough bandwith for this?
[07:30] <jsgotangco> ohhhhh
[07:31] <highvoltage> pygi: can i burn dvd's too with libburn?
[07:31] <pygi> highvoltage, no, you can't :'(
[07:31] <highvoltage> and is there any limitations on cd-writing?
[07:31] <highvoltage> what can't it do at the moment?
[07:32] <pygi> yes, there are limitations
[07:32] <pygi> no -tao, no multi-session, no dvd support
[07:32] <pygi> most notable lackings
[07:32] <highvoltage> those aren't biggies for me
[07:33] <highvoltage> i can't remember ever writing a multi-session cd on linux before
[07:33] <jsgotangco> >:D
[07:33] <highvoltage> and i mostly write data cd's, so i always write dao/sao
[07:33] <highvoltage> pygi: is there a libburn howto somewhere?
[07:34] <pygi> highvoltage, what exactly would you need?
[07:34] <highvoltage> pygi: did i tell you before that I once had a signature that said "Solaris said: 'install solaris or better', so I installed GNU/Linux"?
[07:35] <highvoltage> pygi: just to burn plain iso images to CD, nothing fancy. some bootable, but i suppose that happens at the mkisofs level.
[07:35] <pygi> highvoltage, no, you haven't :)
[07:35] <pygi> highvoltage, libburn is a library, but I have application for you
[07:36] <pygi> http://libburn.pykix.org/wiki
[07:36] <pygi> (do a checkout, and run:)
[07:36] <pygi> bootstrap
[07:36] <pygi> ./configure
[07:36] <pygi> make
[07:36] <pygi> (do not use "sudo make install" for now, Makefile.am broken)
[07:36] <highvoltage> ok, i'll put it on my download hitlist
[07:37] <highvoltage> ok
[07:37] <pygi> highvoltage, you have "burniso" binary under test directory
[07:37] <pygi> it's very easy to use
[07:37] <pygi> ./burniso ~/downloads/ubuntu.iso
[07:37] <pygi> that's all you need :)
[07:37] <highvoltage> how would i burn cd's from k3b then like you do?
[07:38] <highvoltage> i mean, how would i replace cdrecord with it?
[07:38] <highvoltage> wow, that is easy :)
[07:38] <pygi> ah, to burn cd's from k3b
[07:38] <pygi> I need to write tutorial for that :)
[07:40] <pygi> highvoltage, let's start :)
[07:40] <pygi> once you compile everything, you'll have "cdrskin" binary under "cdrskin" dir
[07:40] <pygi> click in menu "Settings" on "Configure K3b..." , "Programs" , "Search Path". In the form enter the complete address of the cdrskin binary.
[07:41] <willvdl> pumpkin time. lekker weekend all
[07:41] <highvoltage> u2 will
[07:41] <pygi> click "Programs"...cdrskin should be default writer app
[07:42] <pygi> highvoltage, you must test whetever cdrecord address of the writer is a valid cdrskin-address of the same device
[07:42] <pygi> This can be tested by inserting a *blank* CD-RW into the drive (leaving any other drive empty) and trying to burn a K3b data CD.
[07:43] <highvoltage> i think i'll check how big it is and try to download it
[07:43] <pygi> if it isn't, I'll help then
[07:43] <pygi> highvoltage, not big really
[07:43] <pygi> and now, if addresses are good, you can burn
[07:43] <pygi> if addresses aren't good, poke me
[07:44] <pygi> highvoltage, btw. -tao is needed for burn-on-the-fly without knowing size of cd
[07:44] <highvoltage> aah
[07:44] <highvoltage> i rarely brun on the fly
[07:45] <highvoltage> *very* rarely :)
[07:45] <pygi> good, good ^_^
[07:46] <pygi> highvoltage, I should fix the makefile.am soon, so you should *even* be able to install it
[07:46] <pygi> I'll soon also have debian package
[07:47] <highvoltage> *g*
[07:48] <pygi> thanks for the help ^_^
[07:48] <pygi> if you find any bugs or you miss something, file a ticket pls
[07:59] <highvoltage> Checked out revision 5.
[08:05] <ogra> sbalneav, done ! delayedmounting is working as expected :)
[08:05] <sbalneav> Wooters!
[08:06] <ogra> so whats missing apart from floppies ?
[08:06] <sbalneav> I've just built another edubuntu box, and waiting for updates to download, once they do: sed -i -e "s/dapper/edgy/g" /etc/apt/sources.list
[08:07] <sbalneav> Thats it, I think
[08:07] <ogra> yeah
[08:07] <sbalneav> I'm waiting for cvs to come back to fix the ltspfs[d]  stuff that pitti remarked on.  I'd expect I'll have that done in a couple hours.  You want to add the couple lines for floppies?
[08:08] <ogra> i cant test them
[08:08] <sbalneav> ok, tell you what: I may have some odd versions of things.  Can you tarball me up everything, so I'm running exactly what you've got, and I'll do it right now.
[08:09] <ogra> take your time :)
[08:09] <ogra> its enough to add the floppy part next week
[08:09] <sbalneav> oh, btw, s/.ltspfs-socket/.server-socket/ ?
[08:09] <ogra> oh, right, havent done that yet
[08:09] <sbalneav> cripes, we'll be talking in python soon
[08:09] <sbalneav> :)
[08:10] <ogra> yay :)
[08:10] <sbalneav> for i in bugs:
[08:10] <sbalneav>    i.fixBug()
[08:10] <ogra> i.reject() ?
[08:10] <bddebian> i.sitidle()
[08:13] <highvoltage> lol
[08:15] <ogra> oh, i forgot, we still need a nautilus patch to suppress the eject menuitem
[09:03] <ogra> sbalneav, http://people.ubuntu.com/~ogra/ltsp-localdev.tgz
[09:03] <sbalneav> Ooooo
[09:03] <sbalneav> yum
[09:03] <ogra> including the ldm changes
[09:03] <sbalneav> Super!!!
[09:03] <ogra> lucasvo, if you like the risk and want to play .... ^^^^
[09:04] <ogra> theer are two subdirs (server/client) containing READMEs with instructions
[09:04] <ogra> but i'll likely package all the stuff over the weekend ...
[09:05] <ogra> so if you can wait ... its just apt-get then :)
[09:05] <ogra> sbalneav, that hasnt te socket namechange yet ...
[09:06] <ogra> i'll take a long break now, but will probably fix it later tonight
[09:06] <sbalneav> I think you deserve a movie & a beer
[09:34] <pygi> highvoltage, how's k3b? :)
[11:31] <lucasvo> ogra: I guess I'll wait


[00:00] <mtaylor> abentley: so, I spoke with a friend of mine who runs email at uc berkeley... they just recently did some turbogears email integration work, so I wanted to see what they did for addresses
[00:00] <mtaylor> turns out, they analyzed a bunch of addresses they had in the system (about 1.5 million)
[00:01] <mtaylor> (you are right - there is no specced length limit)
[00:02] <mtaylor> but _most_ of the email addresses were in the 30 char length and the really long ones were about 60
[00:03] <mtaylor> so they set it at about 150 chars and decided that if anyone with a longer address wanted to do anything they would just laugh at them
[01:42] <mtaylor> the link to the bzr repos on http://bazaar-vcs.org/QBzr is wrong - it should be either http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/ or lp:qbzr
[01:42] <mtaylor> bzr branch https://launchpad.net/qbzr
[01:42] <mtaylor> doesn't even partially work
[02:23]  * igc lunch
[02:34] <sechastain> there are coding standards for bzr, right?
[02:35] <Peng_> They're in the HACKING document.
[02:35] <Peng_> http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html
[02:35] <Peng_> Or doc/developers/HACKING.txt in the source, I think.
[02:35] <sechastain> that's it
[02:35] <sechastain> thanks
[03:01] <lifeless> spiv: ping; can I nag you to review my breadth first search patch; its a dependency on 'more-find-ghosts' that you already tweaked.
[03:56] <lifeless> spiv: piong
[03:57] <poolie> hi lifeless
[04:01] <cr3> how can I revert a commit on many files?
[04:01] <poolie> bzr revert FILE ...
[04:01] <sechastain> uncommit
[04:01] <poolie> or bzr revert DIR
[04:01] <poolie> unless maybe you want uncommit instead?
[04:02] <cr3> poolie: yeah, uncommit would be awesome... checking manpage
[04:02] <spiv> lifeless: ok, I'll do that now
[04:02] <cr3> first time I use this feature, absolutively cool!
[04:10] <Peng_> cr3: If you've already pushed, don't uncommit.
[04:12] <cr3> Peng_: thanks for the warning, but I was safe
[04:12] <Peng_> :)
[04:18] <lifeless> I poolie
[04:20] <hacklberry> if i want to use bzrsvn against svn 1.4.6 do i still need to apply the patch to the svn python bindings as described on the bzr homepage wiki? (i know i can look at the diff myself and figure that out, so just in case someone knows from top of their head...)
[04:20] <fullermd> No, you lifeless.
[04:20] <mtaylor> hacklberry: well, it'll work without the patch, but the memory leak may hit you if the svn repos is really big
[04:21] <mtaylor> hacklberry: but I've been using it against svn for a while without problems (except for the memory leak)
[04:21] <fullermd> Er, AFAIK, the stock 1.4.x bindings won't work at all without the patch.
[04:21] <Odd_Bloke> I poolie?
[04:21] <mtaylor> oh
[04:21] <mtaylor> nevermind then... don't listen to me
[04:23] <hacklberry> mtaylor: thanks for the info, does the mem leak depend on the size of the whole svn repo or the size of a module one want's to work with?
[04:23] <mtaylor> hacklberry: depends on how you are branching it
[04:24] <mtaylor> hacklberry: I, most of the time, do bzr svn-import to get a bzr repos of the svn repos
[04:24] <mtaylor> hacklberry: at times, this takes a very, very, very long time
[04:26] <hacklberry> mtaylor: thanks
[04:26] <mtaylor> hacklberry: sure. but also fullermd is probably right about the patch - he's smarter than I am
[04:26] <mtaylor> :)
[04:26] <mtaylor> so ignore me about that
[04:27] <fullermd> Oh, great, now my ego is gonna strut around all day....
[04:27] <fullermd> We may be talking about different patches.
[04:27] <fullermd> There IS a memory leak patch that prevents it from going out the window and down the road on big things.
[04:27] <fullermd> That's not strictly _necessary_, especially if you have a small repo, but it's still a good idea.
[04:28] <fullermd> But there's also a giant mega-patch that you _need_ with 1.4.x bindings, because they're useless, which I think basically updates them to 1.5.x bindinds.
[04:34] <hacklberry> fullermd: just for reference i was gibbering about this patch: http://samba.org/~metze/subversion-1.4.0-metze-python-bindings.patch
[04:35] <jelmer> hacklberry: yes, you will still need to update the patch if you are on subversion 1.4.x
[04:35] <jelmer> unless your distributions ships its packages with it
[04:35] <jelmer> Debian and Ubuntu do
[04:37] <mtaylor> ah
[04:37] <mtaylor> that's why I'm working fine "without" the patch
[04:38]  * mtaylor doesn't understand people who don't use debian/ubuntu
[04:38] <fullermd> Linux?  That thing is still around?   :p
[04:38] <mtaylor> hehe
[04:38]  * TFKyle doesn't understand people who do use ubuntu :P
[04:39] <jelmer> The memory leak fix is not included in the Debian/Ubuntu packages yet
[04:39]  * mtaylor stabs TFKyle in the eye
[04:39] <hacklberry> jelmer: thanks. OT:(huh distirbution - what's that :-) ? slack base here, the rest rolled from sources...
[04:39] <jelmer> but will be included in the next upload to sid (and first import from sid from ubuntu)
[04:39] <TFKyle> ubuntu's good though, they applied one of my patches for a while
[04:39]  * mtaylor would be happier if he could figure out how to go through the dev process on either debian or ubuntu...
[04:40] <mtaylor> but I guess I haven't sacrificed goats in the right places yet
[04:41]  * TFKyle typically uses gentoo, have ubuntu and a few BSD's installed in vmware though
[04:42] <mtaylor> there are some times when it seems that after a branch I don't have a pull location set automatically
[04:42] <mtaylor> is that just me being wrong, or are there times when that's true?
[05:03] <jelmer> mtaylor: it'll only remember the branch location if there was none set previously or if you specify --remember
[05:03] <mtaylor> jelmer: so when I make a fresh clean branch, it _should_ remember the pull location, right?
[05:04] <jelmer> it may actually be set to the location you branched from by default
[05:04] <jelmer> cat .bzr/branch/branch.conf
[05:06] <lifeless> ok, Repository.get_parent_map is working
[05:06] <lifeless> shoud gzip the content I think though
[05:40] <hacklberry> jelmer: i installed svn 1.5.0 (dev build), but when i run 'bzr selftest svn' i got: bash-3.1$ bzr selftest svn
[05:40] <hacklberry> testing: /usr/bin/bzr
[05:40] <hacklberry>    /usr/lib/python2.5/site-packages/bzrlib (1.0.0 python2.5.1.final.0)
[05:40] <hacklberry> ERROR: bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_create_checkout
[05:40] <hacklberry>     _get_global_config() takes exactly 1 argument (4 given)
[05:40] <hacklberry> [10/722 in 4s, 1 errors] bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_create_checkout_lightweight                                                                Segmentation fault
[06:18] <abentley> lifeless: Perhaps even bzip?  Probably lots of redundancy in revision ids.
[06:27] <spiv> abentley: bzip is a pretty large leap in processing cost, IIRC.
[06:30] <abentley> spiv: Sure, but on today's hardware, it could still be very cheap.
[06:30] <spiv> Yeah.  Worth experimenting with.
[06:31] <spiv> I'm guessing in the context of ~64k of graph data it won't be worth it, but that's purely a guess :)
[06:32] <abentley> Is it going to be 64K compressed or uncompressed?
[06:33] <spiv> abentley: good question ;)
[06:34] <spiv> abentley: lifeless just posted (and I just reviewed) a smart method that just does 64k uncompressed.
[06:39] <fullermd> bzip2 is awful slow.  zlib's a lot faster, and will probably get you enough of a saving to not notice the difference on less than a couple megs...
[07:27] <brilliantnut> hi anybody knows about 1.1?
[07:27] <AfC> brilliantnut: are you subscribed to the bazaar project mailing list?
[07:28] <brilliantnut> no, only to announce
[07:30] <brilliantnut> but I keep browsing thru  those archives for info on 1.1, did I miuss something?
[07:33] <AfC> brilliantnut: Martin wrote a ... oh, damn. Well, whatever
[07:48] <lifeless> abentley: 64 on the wire is my current 'sweet spot' for requests
[07:48] <lifeless> abentley: so if we compress it, ~64k compressed
[07:49] <lifeless> with 64k uncompressed we do 4 round trips to get those 100 commits
[07:49] <lifeless> spiv: thanks for the reviews; I'll reply to the tomorrow morning. Some stuff I agree with, some I don't :)
[07:50] <lifeless> spiv: in particular, I want the tests for the two variants of the searcher protocol to be single units; to avoid skew being added by one-or-other tests;
[08:05]  * igc dinner
[10:07] <rjek> Is there a place I can branch the current release version from?
[10:08] <rjek> (ie, not http://www.bazaar-vcs.org/bzr/bzr.1.0/ but something like http://www.bazaar-vcs.org/bzr/bzr.current/)
[10:09] <Lo-lan-do> If you do that, then you'll be left out with a diverged branch when a new version is published.
[10:09] <rjek> (pref. one I can fetch with 0.90 :)
[10:09] <rjek> Which is the issue I'm wanting to solve.
[10:09] <rjek> ie, when a new release is made, I can just bzr pull.
[10:10] <Lo-lan-do> You can't do that, since each release comes from a different branch.
[10:10] <dato> rjek: s/current/dev/, but you need 0.92 for that
[10:10] <fullermd> Releases aren't cut from the trunk, they're cut from their own branches.
[10:10] <dato> ah
[10:10] <dato> I misunderstood rjek
[10:10] <rjek> That's a shame.  OK.
[10:10] <fullermd> Well, I imagine he misunderstands himself too   ;)
[10:10]  * dato releases his stuff from $project.stable
[10:10] <fullermd> Why do you want a release branch instead of trunk?
[10:10] <lifeless> rjek: http://bazaar-vcs.org/bzr/bzr.0.92/
[10:11] <rjek> lifeless: I'm fetching bzr.dev.knits atm.
[10:11] <rjek> (which 0.90 can grock.)
[10:11] <lifeless> rjek: the url I gave will give you 0.92, and 0.92 can grok it
[10:11] <lifeless> sorry, 0.90 can grok it
[10:11] <rjek> I know.
[10:12] <Odd_Bloke> bzr.dev is normally pretty solid, so I run from that in most places.
[10:12] <rjek> But if it's suggested that I go for bzr.dev, is bzr.dev.knits not just bzr.dev except in the older format that pre-0.92 versions can read?
[10:12] <fullermd> Yes, it is.
[10:12] <Odd_Bloke> And possibly a few hours out of date.
[10:12] <rjek> Right, I'll get that then.  Going via an intermediate version is a faff. :)
[10:12]  * fullermd is still pulling the .knits variant.
[10:13] <lifeless> rjek: yeah, we try to allow reasonable overlap for folk
[10:13] <lifeless> but we do keep finding things we can do better
[10:13] <fullermd> Aw, bzr.dev.as.weaves isn't around anymore?  Shucks...
[10:14] <lifeless> fullermd: we're not masochists
[10:14] <fullermd> I'm sure there's evidence to the contrary in the code still   :p
[10:21] <brilliantnut> poolie: would you have any idea of what happened to the 1.1 release of bazaar that was scheduled on 11th Jan?
[10:22] <poolie> brilliantnut, yes, i've just been delayed in making it
[10:22] <poolie> should be out tonight
[10:22] <poolie> it will have no substantial changes from 1.1rc1
[10:22] <dato> poolie: it is very minor, but 1.1 still claims pack-0.92 is experimental. http://bundlebuggy.aaronbentley.com/request/<20080114093341.GA6173%40chistera.yi.org>
[10:22]  * rjek wishes to upgrade as 0.90 is painfully slow for even the most trivial of tasks.
[10:23] <brilliantnut> ok. Thanks :) I've been waiting for 1.1 since ages.
[10:23] <dato> well
[10:24] <dato> poolie: er, well, never mind really, because with pack-0.92 being default, it won't show under "experimental formats" in `bzr help formats`, I just realized of that.
[10:24] <dato> (so it only affects rich-root pack)
[10:24] <poolie> brilliantnut, do you mean since december?
[10:24] <poolie> or were you waiting for 1.1 because you don't use 1.0 releases? :)
[10:24] <brilliantnut> yeah,
[10:25] <brilliantnut> no, we tried out 1.0, and found that it was missing something for our particular situation
[10:25] <fullermd> I don't trust 0.9x releases.  I've been waiting for 0.19 forever   :|
[10:25] <poolie> but it's fixed in 1.1?
[10:25] <poolie> that's good
[10:26] <brilliantnut> talking to jelmer here helped us understand that there was a patch going in which would solve our problem.. spiv was making that patch.
[10:26] <brilliantnut> so, we have been waiting for 1.1 since then..
[10:26] <Odd_Bloke> spiv: No pressure. :p
[10:26] <brilliantnut> We had scheduled time on Saturday to migrate from CVS to bzr 1.1 :(
[10:26] <brilliantnut> yeah, spiv, no pressure.
[10:26] <awilkins> Are we discussing the reason that the replay branch doesn't work with a 1.0 client (KnitRepository error?)
[10:27] <awilkins> Is KnitRepository the bit that handles branches of differing format versions?
[10:28] <poolie> KnitRepository is a set of imprementations
[10:28] <poolie> um, i'd have to see the bug or error msg
[10:28] <awilkins> Japanese implementations :-) ?
[10:28] <awilkins> https://bugs.launchpad.net/bzr/+bug/182803
[10:28] <ubotu> Launchpad bug 182803 in bzr "Replay branch appears broken" [Undecided,New]
[10:30] <ubotu> New bug: #182803 in bzr "Replay branch appears broken" [Undecided,New] https://launchpad.net/bugs/182803
[10:35] <rjek> What does "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data." mean when doing bzr upgrade?
[10:39] <Peng_> rjek: What format are you currently using (bzr info)?
[10:40] <rjek> bzr info doesn't say, but I believe it's knits.
[10:41] <fullermd> Check the first line of output.
[10:41] <Peng_> rjek: You're using a rich-root or subtree format, which includes metadata that non-rich-root formats like pack-0.92 don't support. Try upgrading to rich-root-pack.
[10:41] <rjek> Ah, yes: dirstate-with-subtree
[10:42] <rjek> What is a rich root, anyway?
[10:42] <Peng_> rjek: Try rich-root-pack, then.
[10:43] <rjek> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>.  Does not support nested trees
[10:43] <rjek> :)
[10:43] <Peng_> rjek: pack-0.92-subtree then.
[10:43] <Peng_> rjek: Older formats didn't store any information about the root directory of the branch. Rich root formats do.
[10:44] <rjek> OK, pack-0.92-subtree works, although I have no idea what it means, and the option appears to be undocumented in "bzr help upgrade"
[10:45] <Peng_> rjek: Yeah. Subtrees are kind of experimental, so they're hidden.
[10:45] <Peng_> rjek: Rich roots were invented as something between the regular formats and subtree formats that wasn't experimental.
[10:46] <rjek> And what is a subtree?
[10:46] <Peng_> rjek: With rich roots, you can use bzr split and join (make a directory in a branch into its own branch, and vice versa).
[10:46] <Peng_> rjek: No idea. :) Something more advanced than that I guess.
[10:46] <dato> Peng_: no, split/join are with *subtree, not with rich-root alone
[10:47] <Peng_> Bah.
[10:47] <Peng_> What's the point of rich roots then?
[10:47] <Peng_> They're enough for bzr-svn.
[10:47] <Peng_> Why?
[10:48] <fullermd> Because they store the root identity, which (AIUI) bzr-svn uses to keep from going nutbar coping with svn's soi-disant branching schemes.
[10:48] <Peng_> Heh, ok.
[10:53] <awilkins> Anyone using the eclipse bzr support? Any good?
[10:54] <brilliantnut> awilkins: not yet.
[10:55] <brilliantnut> awilkins: I tried it out, but it doesn't support the full range of eclipse team tasks that cvs/svn does.
[11:22] <jelmer> I thought split/join worked with rich-root too
[11:22] <jelmer> subtree is for by-reference nested tree
[11:25] <dato> oh
[11:25] <dato> Peng_: ^
[11:28] <Peng_> :D
[11:28] <Peng_> So subtrees are like svn externals?
[11:30] <jelmer> Peng_: Yep
[11:31] <Peng_> Ok.
[11:31] <Peng_> I think I finally understand the whole mess.
[11:32] <Peng_> Shouldn't rich-root-pack be named pack-0.92-rich-root?
[11:32] <fullermd> That would blow our 2-dash budget...
[11:33] <jelmer> fullermd: (-:
[12:25] <fullermd> Hm.  added seems to be b0rked...
[12:28] <Odd_Bloke> fullermd: !testcase ;)
[12:28] <fullermd> I'm more of an idea rat...
[12:51] <glyph> Hello bazaarians ... what do you call bazaar users?  bzrkers?  Anyway, I've got bzr 1.0 and bzr-svn installed from debs, and I just checked out a pretty massive svn project.  It seems to be working great (although I haven't tried a "push" yet), but I'd really like to use a shared repository locally
[12:51] <glyph> unfortunately shared repositories seem to be incompatible with bzr-svn
[12:52] <glyph> can someone explain how this could work to me?  I think I'm not understanding the vocabulary around how init-repository and formats work
[12:52] <jelmer> glyph: Shared repositories work
[12:52] <glyph> jelmer: Cool.  How do I do it? :)
[12:52] <jelmer> use the format bzr-svn needs: bzr init-repo --rich-root-pack
[12:52] <Odd_Bloke> glyph: How did you create the sha... oh, jelmer will save the day. :)
[12:53] <glyph> jelmer: also, may I say, you are a god among men
[12:53] <Odd_Bloke> +1
[12:54] <glyph> jelmer: Any chance you could make the error messages a bit more explanitory?  The fact that it talks about SubversionRepository and KnitRepository is a bit confusing - it made me think that the right thing to do was bzr init-repository --format subversion, which does... something else :)
[12:55] <rjek> heh
[12:55] <jelmer> glyph: The error is from bzr, not from bzr-svn unfortunately
[12:55] <glyph> oh, and also - I just spent like 3 hours checking out all 110MB of history; how can I convert this branch to use a shared repository without repeating that?
[12:55] <glyph> jelmer: sure, but I was assuming you could write patches for either :)
[12:55] <Peng_> glyph: bzr branch into the shared repo.
[12:55] <jelmer> glyph: Create the shared repository, then use "bzr branch" to clone that data into the shared repo
[12:55] <jelmer> glyph: True :-)
[12:56] <glyph> jelmer: OK, I was going to try that next
[12:57] <glyph> jelmer: also, I'm a little concerned about actually using "bzr push" to put stuff into the svn repository.  Should I be?  It seems to be working fabulously so far, but, uh
[12:58] <jelmer> glyph: Concerned about what specifically?
[12:58] <Lo-lan-do> I usually keep a bound branch for that
[12:59] <glyph> as far as I can tell it uses heuristics to determine what a "branch" is, and I'm not sure what the different URLs really mean to bzr.  Can I, for example, pull from an svn+ssh URL to a branch (a copy of /trunk, in /branches), then merge from that locally, then push to trunk, and get something in svn that looks about right?
[12:59] <Lo-lan-do> "bzr commit" commits both to bzr and svn, "bzr pull" from another branch does the right thing, etc.
[13:01] <glyph> Lo-lan-do: "the right thing" seems a little scary.  For example, if you merge trunk into a branch, can svn still tell what's going on? :)
[13:02] <Lo-lan-do> Actually, the bzr "merge" operation does strange things.  I usually keep to pull and push.
[13:03] <glyph> are you using bzr-svn for read-only operation?
[13:03] <Lo-lan-do> No
[13:03] <glyph> presumably "pull" won't work sometimes, if you have conflicts
[13:03] <Lo-lan-do> But I don't do advanced branch stuff in bzr.
[13:03] <Lo-lan-do> For the few non-svn branches I have, I usually rebase before pulling into svn.
[13:04] <glyph> rebase?
[13:04] <glyph> Pardon, I'm still a bit of a bzr newb
[13:04] <Lo-lan-do> It's another plugin
[13:04] <glyph> I'm playing with bzr-svn because it looks like it's finally getting to the point where I can do real development in bzr without actually disturbing any of the projects I work with (in svn)
[13:04] <Lo-lan-do> (Still one of jelmer's though :-)
[13:05]  * glyph reads the package description
[13:05] <glyph> I have no idea what this means :)
[13:05] <Lo-lan-do> It takes all the revisions you've committed since your branch diverged, then applies them on top of the tip of the remote branch and commits them back.
[13:05] <Lo-lan-do> So the history stays linear, and you can pull your branch into the svn one
[13:06] <glyph> hmm
[13:07] <glyph> Lo-lan-do: I *think* I know what you just said
[13:07] <glyph> actually no I don't.
[13:07] <Lo-lan-do> It's still not optimal, but that's what you get for using SVN :-)
[13:07] <glyph> "applies them on top of the tip"
[13:07] <glyph> diverged from ... what?
[13:07] <Lo-lan-do> Okay.  Assume a branch, that we'll call trunk, with revisions A, B, C and D.
[13:07] <Odd_Bloke> glyph: If you diverge from trunk, rebase takes your fork of the branch and reapplies it to HEAD.
[13:08] <Lo-lan-do> Assume another branch, called foo, started from trunk at point C.
[13:08] <glyph> Odd_Bloke: I think I like where Lo-lan-do's explanation is going ;)
[13:08] <Lo-lan-do> You commit E and F on top of foo.
[13:08] <Odd_Bloke> glyph: ^_^
[13:08] <Lo-lan-do> C is the last common ancestor for the branches, right?
[13:08] <glyph> Lo-lan-do: Yes, this makes sense
[13:09] <glyph> Lo-lan-do: It's helpful to use letters rather than numbers, because svn has given me nearly irreparable brain damage in this regard ;-)
[13:09] <Lo-lan-do> But you can't pull foo into trunk, because there's one rev on trunk not in foo (D)
[13:09] <glyph> (I have to keep repeating to myself, "directed graph of revisions" over and over again just so I don't start hemmorhaging blood out of my brain when I type "bzr branch")
[13:09] <Lo-lan-do> So what you do is rebase foo on trunk.
[13:10] <Lo-lan-do> What "bzr rebase ../trunk" does is this: it uncommits E and F, then pulls D, then re-applies E and F on top of D.
[13:10] <glyph> Lo-lan-do: OOoooooohhh...
[13:10] <Lo-lan-do> Of course, since D changed the tree, what it actually commits is E' and F', with slight changes.
[13:10] <Odd_Bloke> http://paste.pocoo.org/show/21271/ is my attempt to outdo Lo-lan-do. :D
[13:10] <glyph> Lo-lan-do: So this is trunk in SVN and foo in bzr
[13:11] <Lo-lan-do> Odd_Bloke: I think you got it wrong
[13:11] <Odd_Bloke> Lo-lan-do: How so?
[13:11] <glyph> Lo-lan-do: this is _seriously_ awesome.
[13:11] <glyph> Lo-lan-do: Does this, or can this work with branches in svn as well?
[13:11] <Lo-lan-do> glyph: Note you can get conflicts during rebasing, obviously, if D conflicts with E and/or F
[13:12] <spiv> glyph: the downside of rebase is that it throws away history
[13:12] <glyph> Lo-lan-do: for reference, here is what we do right now, without bzr, to do what would be in a bzr repository a straightforward merge from trunk: http://www.divmod.org/trac/wiki/MergedForward
[13:12] <glyph> spiv: you know me.
[13:12] <glyph> spiv: I _LOVE_ throwing away history.  So much.
[13:12] <Lo-lan-do> I use trunk as a branch bound to SVN
[13:12] <spiv> glyph: it generates a new history, but anyone who branched off your branch will be in a bit of a mess.
[13:12] <Lo-lan-do> Odd_Bloke: Missing primes, and/or wrong ordering
[13:12] <glyph> spiv: Oh.  That is unfortunate.  I guess they could rebase as well but it would cause them some pretty severe suffering.
[13:13] <spiv> glyph: no worse than keeping the same sort of branches-of-branches in plain SVN (which keeps no history in this sense at all, at least not in any useful way)
[13:13] <glyph> branches-of-branches in SVN is just not worth the trouble
[13:13] <glyph> the math required to not kill yourself is too hard for any human being to od
[13:14] <Odd_Bloke> Lo-lan-do: OK, you win. :p
[13:14] <glyph> spiv: I am starting to think of experimentally developing a few Twisted or Divmod branches in bzr
[13:15] <glyph> spiv: Trying to think about the best way to go about that so as not to be overly disruptive.  I am very excited right now because it looks like as of 1.0 and the matched release of bzr-svn, it's actually up to the task
[13:15] <spiv> basically, if you have a branch off F with revision G, and do the rebase Lo-lan-do described, you suddenly have two branches with different revisions making very similar changes.
[13:15] <glyph> spiv: It seems like the best way might just be to keep trunk in SVN, and push bzr branches elsewhere
[13:15] <spiv> So you're risking messy conflicts, as I'm sure you can imagine.
[13:15] <glyph> spiv: yes
[13:15] <Lo-lan-do> glyph: I've documented a setup I have on http://mail.gnome.org/archives/f-spot-list/2008-January/msg00035.html
[13:16] <Lo-lan-do> I don't do any rebasing in there, only merges, but that's not a problem since I don't have commit access to SVn anyway :-)
[13:16] <spiv> Lo-lan-do: ooh, you do f-spot dev with bzr?  I made a checkout of that with bzr-svn to start hacking on a bug I found, but never played with it much...
[13:16] <glyph> Lo-lan-do: *perfect*!
[13:16] <glyph> OK now I'm getting too excited.
[13:16] <spiv> Lo-lan-do: but I still want to fix that bug :)
[13:16] <Lo-lan-do> spiv: I do, but only locally.
[13:16]  * spiv reads
[13:17] <Lo-lan-do> spiv: Fix the bug, submit a patch to Bugzilla, and tell me the number so I'll create a new branch with it, and merge it into my superpatch branch
[13:17] <glyph> Squeeeeeeeee
[13:17] <glyph> OK I guess I need to propose this on the mailing list
[13:18] <Lo-lan-do> (I'm currently tracking 14 patches :-)
[13:20] <glyph> Hmm
[13:20] <glyph> The main reason I need to push to svn branches is to avoid disrupting our review process
[13:24] <glyph> oh right, now I remember other problem with using bzr here - when I push to trunk in svn, I want to destroy as much history as possible :)
[13:24] <glyph> Lo-lan-do: let's say I do
[13:25] <glyph> bzr get svn+ssh://.../trunk; bzr branch trunk foo; cd foo; bzr commit; bzr commit; bzr commit; bzr push ../trunk; cd ../trunk; bzr push
[13:25] <glyph> am I going to get 3 revisions in trunk, or 1?  It's important to me to be able to reduce that to 1 somehow
[13:26] <glyph> in the absence of SVN being able to understand that this is a single logical "merge" operation, our release manager is going to want to look at a log of trunk and see only one revision for each merge
[13:26] <luks> if you merge foo to trunk, instead of pushing foo to trunk, you will get only one
[13:27] <Lo-lan-do> What luks said
[13:27] <glyph> luks: Interesting
[13:27] <glyph> luks: That is pretty much exactly what I want
[13:27] <luks> bzr will still all of them, but svn only the merge
[13:27] <luks> er, still see
[13:27] <glyph> luks: "(08:02:51 AM) Lo-lan-do: Actually, the bzr "merge" operation does strange things.  I usually keep to pull and push."
[13:27] <glyph> luks: That worries me though ;)
[13:28] <Lo-lan-do> I think it does strange stuff when you merge from svn into bzr, then pull(or push) the result into svn.
[13:28] <luks> Lo-lan-do: what kind of strange things?
[13:29] <luks> I practically use bzr-svn only for merging svn branches, and it always worked fine for me
[13:29] <Lo-lan-do> svn sees a series of commits based not on D but on C (from my earlier scheme)
[13:30] <luks> if you merge, it sees only one commit
[13:30] <luks> as it pushes only the mainline
[13:30] <glyph> luks: is this documented somewhere?
[13:31] <luks> not sure, but bzr-svn will push always only the mainline commits
[13:31] <Lo-lan-do> Yeah, but if you merge from svn into bzr and then pull the result into svn again... you get surprises.
[13:31] <luks> that is, the non-indented ones from bzr log
[13:31] <luks> Lo-lan-do: pull into svn?
[13:31] <luks> you mean push?
[13:32] <Lo-lan-do> Whichever
[13:33] <Lo-lan-do> (I pull into a branch bound to svn)
[13:34] <luks> oh, I can see how that causes problems
[13:34] <luks> because pull can change the mainline
[13:34] <luks> but I personally wouldn't pull to a svn checkout
[13:34] <bialix> hi guys
[13:35] <bialix> I can't find 1.1 branch. Is it not public (yet)?
[13:35] <glyph> luks: hmm
[13:35] <luks> Lo-lan-do: push to the svn branch would complain about diverged branches
[13:35] <glyph> luks: what if I'm working in a bzr branch, and I want to merge in the svn trunk?
[13:36] <glyph> here's what I would think would not give me any surprises
[13:37] <luks> bzr branch svn+ssh:// trunk; cd ..; bzr branch trunk foo; cd foo; bzr ci; cd ../trunk; bzr merge ../foo; bzr ci -m 'Merged foo'; bzr push
[13:37] <luks> this should work without any surprises
[13:37] <luks> oh, you might want to add 'bzr pull' before the merge, to avoid the need for rebasing
[13:37] <glyph> bzr branch svn+ssh://.../trunk; bzr branch trunk foo; cd trunk; bzr pull; cd ../foo; bzr merge ../trunk; bzr ci; edit stuff; bzr ci; cd ../trunk; bzr merge ../foo; bar ci; bzr push;
[13:38] <glyph> hah, cool
[13:38] <glyph> I *think* we said the exact same thing
[13:39] <luks> you usually don't need the 'bzr merge ../trunk' step
[13:39] <luks> unless you have a long lived branch and you want to sync it with trunk
[13:39] <glyph> luks: that's exactly the case I'm thinking about
[13:39] <Peng_> bialix: It may not be on Launchpad, but http://bazaar-vcs.org/bzr/bzr.1.1/
[13:39] <luks> but either way, this should work fine
[13:40] <luks> just don't do: cd trunk; bzr pull ../foo; bzr push svn+ssh://...
[13:41] <luks> or the other way around: cd foo: bzr push --overwrite ../trunk
[13:41] <glyph> luks: OK.  *That*, I definitely don't want to do :)
[13:41] <glyph> luks: as I understand it, pulling and pushing generate multiple mainline revisions, which is exactly the case I don't want
[13:41] <luks> yes
[13:41] <glyph> luks: am I phrasing that properly?
[13:42] <luks> I think it's better to think of it in terms of mirrors
[13:42] <luks> bzr push/pull will mirror a branch
[13:42] <spiv> glyph: "generate" is a misleading verb for that, I think
[13:43] <licorna> hi
[13:43] <glyph> I really need a version of bzr-gtk that works with 1.0 so I can visualize this :(
[13:43] <spiv> glyph: the "new" revisions already exist in another branch, no new revisions are made.
[13:43] <brilliantnut> glyph: bzr-gtk dos work with 1.0
[13:43] <glyph> brilliantnut: Oh?
[13:43]  * glyph looks at a webpage
[13:43] <glyph> oh, so it does
[13:44] <glyph> I guess I'm just waiting for debs then
[13:46] <Lo-lan-do> They are in sid
[13:46] <bialix> Peng_: thanks
[13:46] <glyph> Lo-lan-do: I'm using gutsy
[13:46] <glyph> (and and bazaar-vcs.org's gutsy repository, and jelmer's personal unstable repository)
[13:47] <luks> https://launchpad.net/~bzr/+archive
[13:48] <luks> it seems to have 0.93 for gutsy
[13:48] <glyph> huh
[13:48] <glyph> good to know
[14:03] <glyph> luks: should I get rid of those other two repositories I just mentioned and go from PPA instead?
[14:05] <jelmer> afaik the ppa is not actively maintained
[14:07] <glyph> I guess I'll just download the one deb I want :)
[14:08] <glyph> hmm
[14:08] <glyph> man, I love gdebi
[14:09] <glyph> the experience of clicking on a web page and getting an "install" button is just awesome
[14:28] <licorna> if I want to make a local branch and push it to a central location, in this 'central location' is not necesary that bzr is installed, right=
[14:28] <licorna> ?
[14:28] <licorna> just need a ftp server?
[14:29] <LeoNerd> Indeed; anything that can host files in some way is sufficient.
[14:29] <LeoNerd> sftp and http work well
[14:29] <rjek> You can push to http?
[14:29] <rjek> Actually, I meant to ask that: can bzr use HTTP PUT to push to http:// URLs?
[14:30] <licorna> don't know. i'm new
[14:30] <ubotu> New bug: #182849 in bzr "bzr bind to unknown host causes internal error" [Undecided,New] https://launchpad.net/bugs/182849
[14:34] <licorna> how to use a non standard port in sftp (I'm using port 21 for firewall issues)
[14:34] <licorna> ??
[14:34] <licorna> I mean, bzr push sftp://...
[14:34] <Lo-lan-do> Declare it in your .ssh/options file?
[14:34] <Lo-lan-do> Or maybe sftp://foo:21/path
[14:35] <licorna> Oh, you're right, thanks
[14:47] <Odd_Bloke> licorna: For reference, which suggestion was correct?
[14:55] <Lo-lan-do> Both, I suppose :-)
[14:55] <arne^> hello, I'm trying to use bzrlib in a python script. I was able to figure out how to do things like bzr init, add, commit but I'm stuck with a way to do bzr cat for old revisions (working on a local workingtree). Can anybody give a pointer where to look?
[14:59] <rjek> Oooh, that reminds me: are there C bindings to bzrlib so I can call it from C programs, and easily bind it to other languages?
[15:01] <ubotu> New bug: #182856 in bzr "Error 2 during merge resulting in many conflicts" [Undecided,New] https://launchpad.net/bugs/182856
[15:07] <luks> arne^: tree.get_file_text(file_id)
[15:07] <luks> and tree.path2id(path) to get the file_id
[15:19] <wingo> congrats on 1.0 :)
[15:19] <wingo> question.
[15:20] <wingo> do by-reference nested branches work yet?
[15:21] <jelmer> wingo: They're still an experimental feature
[15:21] <jelmer> and will only work with the various -subtree formats
[15:21] <wingo> ok
[15:26] <rjek> Other than the speed issue, there's only been one issue I've had with my migration to bzr, and that's the apparent constant changing of the on-disc format. :-/
[15:26] <rjek> Oh, and the lack of ability to do what I want authentication-wise, but Kinni's looking into that for me :)
[15:28] <luks> why is changing of the format bad?
[15:29] <jelmer> maybe bzr should just do as some other vcs'es do and upgrade silently between on-disc like some other VCS' do :-)
[15:30] <luks> *cough*git*cough*? :)
[15:30] <rjek> luks: Because it's a ballache when you don't have a smart server to abstract the differences.
[15:34] <arne^> luks: thx, but I'm having problems to get a tree which represents the correct revision ...
[15:34] <luks> repository.revision_tree(revision_id)
[15:35] <arne^> repository can be a local working copy?
[15:35] <luks> no, tree.branch.repository
[15:36] <luks> if 'tree' is a working tree
[15:36] <arne^> ah, ok, I will try it. thank you
[16:36] <ubotu> New bug: #182899 in bzr "reconcile must be run in a branch root" [Undecided,New] https://launchpad.net/bugs/182899
[17:11] <arne^> luks: my code is working now, thanks for your help!
[17:13] <luks> you're welcome :)
[18:34] <ekimus> hmm can I somehow place Revision Identifiers in the source (looking for a substitute of subversions $Date$ $Author$... - svn:keywords) - or do I want something completely different like a custom plugin or hook?
[18:44] <ekimus> ok I just found the specs about KeywordExpansion, sadly "Implementation branch: none yet" - well I'll wait :)
[18:44] <fullermd> ekimus: The current solution is using 'version-info' in your build script to stuff the version somewhere.
[18:45] <fullermd> (or some similar mechanism; I do some sed'ery in one project to stick bits in a header file)
[18:54] <ekimus> well I guess we can live without that, since I carefully set up trac with hooks to react on commit messages a year ago so far they haven't used it. guess they can than live without svn:keywords too...
[19:00] <fullermd> Of course, now that you've said that, there'll be a peasant uprising tomorrow demanding keywords.
[19:02]  * brilliantnut wants keyword expansion
[19:04]  * fullermd does too.  And a pony.
[19:05]  * beuno points to Canonical's owned pony, Woody
[19:06] <beuno> (yes, the secret is out)
[19:11] <brilliantnut> Canonical has a pony?
[19:11] <brilliantnut> which project?
[19:12] <beuno> brilliantnut, they sponsor an actual pony
[19:12] <fullermd> Sponsor?  What does it do, figure skate?
[19:13] <beuno> but I'm not a Canonical person, so I don't know much more then that and a some picture I got and used in slides as a "Why use Ubuntu"
[19:13] <fullermd> Come to think of it, I would *totally* pay to see a donkey do a double axel.
[19:13] <beuno> lol, interesting, now we know where Canonical gets all that funding...   :p
[19:14] <deepjoy> fullermd: or a monkey do bzr checkout http://en.wikipedia.org/wiki/Infinite_monkey_theorem
[19:14] <beuno> "figure skating ponies"
[19:14] <deepjoy> :-)
[19:16] <beuno> btw, has anyone seen this: http://juliank.wordpress.com/2008/01/13/a-small-benchmark-bazaar-git-mercurial/
[19:16] <beuno> bzr seems to loose on all tests
[19:17] <beuno> which contradicts http://bazaar-vcs.org/Benchmarks/SpaceEfficiency
[19:18] <luks> well, you know how benchmarks work
[19:19] <fullermd> You pick up the computer, hold it at a carefully-chosen angle, let it fall, then measure the mark on the bench?
[19:19] <brilliantnut> speaking of peasant uprisings, demanding stuff, rumour had it that 1.1 was about to be released today? *cough*poolie*cough*
[19:21] <lamont> is it possible to edit the commit message on the most-recent commit?
[19:21] <luks> bzr uncommit, bzr commit
[19:21] <beuno> well, I just added a comment, but maybe someone a bit more knowledgable should contact the guy
[19:38] <minghua> How to undo a merge?  I can revert all the files that are changed, but the "bzr status" still shows "pending merges".
[19:38] <dato> bzr revert
[19:42] <minghua> dato: Ah, that works.    Thanks!
[19:51] <abentley> minghua: reverting specific files won't clear pending merges.  You should do "bzr revert" with no arguments to clear pending merges.
[19:52] <minghua> abentley: Yes, dato gave the same (although less elaborated) answer.  And it works, thanks!
[19:53] <abentley> minghua: I saw, I just wanted to make it really clear.
[20:56] <mtaylor> statik: where was it you were saying did the save-commit-messages already?
[20:56] <statik> mtaylor: qbzr
[20:56] <mtaylor> statik: I looked in qbzr and didn't see it
[20:56] <mtaylor> statik: I also didn't see a "save message and don't commit" button
[20:57] <statik> mtaylor: save_message() in commit.py. There is no button, it just works if you hit cancel
[20:58] <mtaylor> statik: ahhh
[20:58] <mtaylor> statik: ok. that's what I was missing. thanks
[21:04] <elmo> how fragile is bzr nested tree support right now?
[21:04] <elmo> I know there's a subtree format, but it (or publicizing it) seems relatively controversial
[21:04] <elmo> I don't care about performance, and I'm only dealing with local non-distributed branches
[21:05] <mtaylor> elmo: I don't believe nested tree support is ready-for-prime-time yet
[21:05] <elmo> mtaylor: may-eat-my-data not ready?
[21:05] <lifeless> elmo: with larstiqs patch it might work
[21:05] <mtaylor> elmo: not-even-pushed-into-trunk not ready
[21:05] <elmo> bother
[21:06] <lifeless> hi statik, guess what I'm going to ask you :)
[21:07] <statik> lifeless: :) sorry, don't have it yet, but it's still on the top of my todo list staring at me
[21:08]  * lifeless adds an i to it
[21:14] <mtaylor> statik: ok, found the code. thanks
[22:09] <jam> poolie: ping
[22:13] <lifeless> jam: hi
[22:13] <lifeless> jam: poolie is on some sort of call
[22:13] <jam> lifeless: yeah, I'm supposed to be on it with him
[22:13] <poolie> that's why he was pinging...
[22:13] <jam> he wasn't there yet :)
[22:13] <lifeless> poolie: lol
[22:34] <elmo> LarstiQ: ping?
[22:34] <LarstiQ> elmo: just-before-sleep pong
[22:34] <elmo> LarstiQ: can-wait-till-tomorrow-then
[22:35] <LarstiQ> elmo: well, I'll hang around for a couple more minutes
[22:36] <LarstiQ> elmo: ah hmm
[22:36] <LarstiQ> elmo: depends on how actively you want to exercise it
[22:37]  * LarstiQ hasn't spent time on it for too long though
[22:38] <elmo> LarstiQ: I'd just like to try it :)
[22:38] <elmo> LarstiQ: is there an easy way to get a patch that I might slap onto bzr 1.0?
[22:38] <elmo> or should I just suck it up and force your branch onto current bzr.dev?
[22:39] <LarstiQ> elmo: I think there will be quite a lot of conflict resolving you'd have to do
[22:39] <elmo> LarstiQ: either way?
[22:40] <LarstiQ> elmo: either way. You _could_ try playing with split/join as they are in 1.0, but in that case be sure to, in a given hierarchy, not have subtrees with the same name.
[22:40] <LarstiQ> ie, root/sub and root/sub/sub will give you problems.
[22:40] <elmo> ok, that shouldn't be a problem
[22:41] <elmo> LarstiQ: but, FWIW, if you cooked up a current bzr.dev or bzr 1.0 patch, I'd be happy to run on a bunch of servers and give you some real world testing
[22:41] <elmo> (if that'd be useful, if not, I'm happy to try just 1.0)
[22:42] <LarstiQ> elmo: how early on would you want to do testing?
[22:42] <elmo> LarstiQ: how do you mean?
[22:43] <LarstiQ> elmo: well, you could be comfortable with testing something I'd submit for bzr.dev inclusion but like some real world usage, but not earlier on when there are still bugs to iron out.
[22:44] <elmo> LarstiQ: if you're relatively confident bugs will be 'explode' bugs rather, than insidious non-obvious data corruption bugs, I'd be happy enough to test pretty early on
[22:44] <LarstiQ> cool
[22:44] <elmo> 'cos I can reset to last night's .bzr trivially enough
[22:44] <LarstiQ> elmo: I'll certainly take you up on that then.
[22:45] <elmo> LarstiQ: neato
[22:45] <elmo> tgabjs
[22:45] <elmo> err, thanks
[22:45]  * LarstiQ goes to bed now
[22:57] <dato> 23:34 <elmo> LarstiQ: can-wait-till-tomorrow-then
[22:57] <dato> 23:35 <LarstiQ> elmo: well, I'll hang around for a couple more minutes
[22:57] <dato> 23:36 <LarstiQ> elmo: ah hmm
[22:57] <dato> 23:36 <LarstiQ> elmo: depends on how actively you want to exercise it
[22:58] <dato> I think my ctrlproxy lost a line there.
[22:58] <elmo> dato: nah, larstiq just read scrollback to divine my intent
[22:59] <elmo> dato: (we're talking about his nested trees++ branch)
[23:04] <lifeless> spiv: I have replied to your reviews, there is one open question about the value of _returning; I propose 'next' and 'next_with_ghosts'
[23:05] <spiv> lifeless: that sounds fine to me
[23:33] <lifeless> poolie: jam: when do you want this call
[23:46]  * igc breakfast - bbiab


[12:14] <teknico> is anyone around today? :-) I need a second review of https://codereview.appspot.com/8094045/
[12:52] <dimitern> teknico: will take a look
[12:52] <fwereade> tkeLGTM
[12:53] <fwereade> teknico, LGTM
[12:53] <dimitern> :)
[12:53] <dimitern> sorry to be so late
[12:53] <fwereade> teknico, just one thing to think about and one test to add
[12:54] <teknico> fwereade, re: the args num removal, I removed it because of a request by rogpeppe, as you can see above in the code review
[12:54] <fwereade> teknico, I thought he suggested dropping it at the api layer
[12:54] <fwereade> teknico, I definitely agree with that
[12:55] <teknico> fwereade, oh, so I probably misunderstood his suggestion, I'll check
[12:55] <fwereade> teknico, it's just that the CLI can take a moment to connect, and failing fast there is nice for the user
[12:55] <teknico> fwereade, right
[12:55] <teknico> fwereade, and I'll add the test you mentioned, thanks for the review
[12:55] <fwereade> teknico, thanks for the code :)
[13:17] <fwereade> dimitern, a couple of things btw
[13:17] <dimitern> fwereade: yeah?
[13:17] <fwereade> dimitern, I have reviews up: https://codereview.appspot.com/8140044/ https://codereview.appspot.com/8154043/
[13:17] <dimitern> fwereade: I'll take a look a bit later - i'm deeply into status tests refactoring right now
[13:18] <fwereade> dimitern, and, in kanban, there is a defect card that you *might* want topick up after what you're doing now because it leads into it nicely
[13:18] <dimitern> fwereade: which one?
[13:18] <fwereade> dimitern, it's the machine-id-in-status one: it's in core's TODO lane but feel free to grab it if you want it :)
[13:19] <dimitern> fwereade: but i'm not yet changing what status outputs
[13:19] <fwereade> dimitern, it really is only a suggestion
[13:20] <dimitern> fwereade: it could be a follow-up though, after the status refactoring
[13:20] <dimitern> fwereade: thanks
[13:20] <fwereade> dimitern, if say at nearly-eod you think to yourself "what tiny follow-up branch do I feel like doing before I go"
[13:20] <dimitern> fwereade: sure :) sgtm
[13:20] <fwereade> dimitern, I agree it's not the same as what you're doing now and should certainly not be rolled into the same CL :)
[13:23] <dimitern> fwereade: yep
[13:24] <dimitern> fwereade: can I use export_test to provide access to the internals to some other module?
[13:25] <fwereade> dimitern, only to the associated foo_test package
[13:25] <dimitern> fwereade: I'm writing the cleanup stuff for the status tests, and one step is destroying all machines created
[13:25] <fwereade> dimitern, not to everything
[13:25] <dimitern> fwereade: but I cannot destroy (normally) machines with JobManageEnviron
[13:25] <dimitern> fwereade: yeah, that sucks.. any thoughts how to work around it?
[13:25] <fwereade> dimitern, maybe just Reset the test suite?
[13:26] <fwereade> dimitern, UniterSuite has the same sort of problem
[13:26] <dimitern> fwereade: ah, let me try
[13:26] <fwereade> dimitern, check what we do there
[13:43] <dimitern> fwereade: cool, it worked like charm, 10x :)
[13:43] <fwereade> dimitern, sweet
[15:16] <dimitern> fwereade: nice CLs - LGTM on both
[15:16] <fwereade> dimitern, tyvm
[15:16] <dimitern> fwereade: and I'm ready with the status stuff - would you take a look? https://codereview.appspot.com/8133045
[15:16] <fwereade> dimitern, soon I hope; thinking hard about something
[15:17] <dimitern> fwereade: sure, np. I'll go for a run and a short lunch afterwards
[17:02] <fwereade> dimitern, reviewed
[17:02] <fwereade> dimitern, not quite an LGTM but just because I want to know what you think about the change I suggest
[17:02] <dimitern> fwereade: cheers! I just made a small change to optimize test speed
[17:02] <fwereade> dimitern, if you're fine with it and clear about it then I'll LGTM it; let me know what you think
[17:02] <dimitern> fwereade: I'm running status --format {yaml,json} concurrently
[17:03] <dimitern> fwereade: i'll take a look
[17:03] <dimitern> fwereade: this change speeds up the tests about 50% (which is a bit better than they used to be, since changing them slowed them down - state is recreated each time)
[17:03] <fwereade> dimitern, excellent
[17:04] <fwereade> dimitern, very good idea
[17:06] <dimitern> fwereade: sweet! I'll implement your changes and repropose then
[17:50] <dimitern> fwereade: thinking about it, if I drop the output from the test case, the concurrency won't be even needed
[17:51] <fwereade> dimitern, ah, better still
[17:51] <dimitern> fwereade: and I can speed-up and simplify the tests even further by putting basically everything into one case with multiple expects
[17:51] <dimitern> fwereade: because the nature of the tests are incremental
[17:51] <fwereade> dimitern, I am a little bit suspicious here
[17:52] <dimitern> fwereade: but with the added benefit of independence between tests and multiple cases still possible
[17:52] <fwereade> dimitern, this sort of thing becomes a real hassle as the incremental chains grow
[17:52] <fwereade> dimitern, what's the speed/nastiness tradeoff?
[17:52] <dimitern> fwereade: yes, but my point is - you can still have small separate cases, well isolated
[17:53] <dimitern> fwereade: and have bigger aggregated cases which built incrementally and expect as they go
[17:53] <fwereade> dimitern, I agree that several of those test cases can be profitably combined into incremental ones
[17:53] <dimitern> fwereade: well, if most of the cases are incremental the speed will increase, because the state will be setup once
[17:54] <fwereade> dimitern, understood
[17:54] <dimitern> fwereade: but unlike before, you can easily add independent other cases with the same framework
[17:55] <fwereade> dimitern, but faster doesn't beat easier-to-modify, so ideally none of the cases should have more than a few expects
[17:55] <dimitern> fwereade: actually concurrency can still be there - but in expect{} only
[17:55] <fwereade> dimitern, yeah, that's probably worth it
[17:55] <dimitern> fwereade: ok, i'll try both and see how it looks
[18:05] <dimitern> fwereade: scratch that, having multiple expect is possible, but you still have a single summary, so it's not good to mix cases like that
[18:05] <fwereade> dimitern, comment field for the expects? :)
[18:06] <dimitern> fwereade: hmm.. why not
[18:08] <dimitern> fwereade: but then the summary is redundant - it'll be in expect only
[18:08] <fwereade> dimitern, that's probably fine, isn't it?
[18:08] <dimitern> fwereade: yeah, doesn't look so bad actually
[18:08] <fwereade> dimitern, but, well
[18:08] <dimitern> fwereade: will propose shortly
[18:08] <fwereade> dimitern, if you're gruping them yu probably ought to be able to explain why those tests need to go together
[18:09] <fwereade> dimitern, so maybe it's not so redundant :)
[18:09] <dimitern> fwereade: ah, good point
[18:33] <dimitern> fwereade: sweet! it improved the speed even further: now it's more than 100% better than the old tests (before refactoring)
[18:34]  * fwereade cheers
[18:40] <dimitern> fwereade: ah, actually no - they're about as fast as before, just checked - but the added functionality/flexibility is much greater
[18:40] <fwereade> dimitern, sounds like a win regardless
[18:40] <fwereade> dimitern, they were way nicer even at the first propose
[18:40] <dimitern> fwereade: reproposed
[18:41] <dimitern> fwereade: oh yeah - a joy to look at, rather than a disgust :)
[18:44] <hazmat> anybody can offer insight into this error.. on bootstrap --upload-tools ... error: cannot upload tools: build command "go" failed: exit status 2; # launchpad.net/juju-core/cmd/jujud
[18:44] <hazmat> pack: cannot open $WORK/launchpad.net/juju-core/cmd/jujud/_obj/_go_.8
[18:45] <hazmat> i'm using go tip.. and just did a recursive update via go get
[18:47] <dimitern> hazmat: can you try going inside cmd/jujud/ and running go install there ?
[18:48] <hazmat> dimitern, returns immediately.. juju version returns -> 1.9.13-quantal-i386
[18:48] <hazmat> ditto for jujud
[18:48] <dimitern> hazmat: also, if you switched to go-tip and using the same $GOPATH as with go-1.x it might be the issue - rm -fr $GOPATH/pkg/ and try again
[18:48] <dimitern> hazmat: ah, you're on i386?
[18:48] <hazmat> dimitern, that's probably it, thanks.. indeed re 32b
[18:49] <fwereade> dimitern, I think I see another avenue for niceness, potentially
[18:49] <fwereade> dimitern, there are quite a lot of duplicated chunks of data in the tests still
[18:49] <dimitern> hazmat: not sure if it'll ever work on i386 for now
[18:49] <hazmat> i should probably do separate gopaths for go tip vs release
[18:49] <hazmat> dimitern, it used to
[18:49] <dimitern> hazmat: yeah, that's best
[18:50] <dimitern> fwereade: yeah?
[18:50] <dimitern> fwereade: in the expected output?
[18:50] <fwereade> dimitern, I'm thinking things like var exposedService = M{"exposed":true, "charm": "cs:foo/bar-1"}
[18:51] <dimitern> fwereade: the output was the only thing I didn't want to touch, even with duplicated parts, because it helps to see what's there
[18:51] <fwereade> dimitern, and var machine0 = M{"dns-name": "dummyenv-0.dns", "instance-id": "dummyenv-0"}
[18:52] <dimitern> fwereade: it has to be explicit somewhere
[18:52] <dimitern> at least
[18:52] <fwereade> dimitern, I *think* there's enough duplication that a list of <10 building blocks will collapse the rest a lot
[18:52] <dimitern> fwereade: even if in subsequent cases it's short-circuited
[18:53] <fwereade> dimitern, but I'll leave it to your judgment
[18:53] <dimitern> fwereade: ok, I'll think about it
[18:53] <dimitern> fwereade: otherwise?
[18:54] <fwereade> dimitern, otherwise LGTM, I think, just skimming the rest again
[18:56] <fwereade> dimitern, sent
[18:56] <dimitern> fwereade: cool! tyvm
[18:57] <dimitern> fwereade: I think I prefer having the output unchanged first time we're testing a scenario, and use shortcuts afterwards, sane?
[18:57] <fwereade> dimitern, I'm fine with that
[18:57] <fwereade> dimitern, we can decide next pass
[18:58] <dimitern> fwereade: great, I'll do it like that then
[19:05] <dimitern> fwereade: looks nicer now I think
[19:05] <dimitern> fwereade: which status-related card were you referring to earlier? I can't seem to see it.
[19:24] <fwereade> dimitern, the big red one in core's TODO
[19:24] <dimitern> fwereade: right! thanks
[19:25] <fwereade> dimitern, np
[19:25] <dimitern> fwereade: so what's the idea in bug 1121916
[19:25] <_mup_> Bug #1121916: status compatibility <cmdline> <juju-core:New> < https://launchpad.net/bugs/1121916 >
[19:26] <dimitern> fwereade: changing the machine id to int?
[19:45] <hazmat> latest failure trying to bootstrap with constraints, no image found.. http://pastebin.ubuntu.com/5659178/
[19:46] <hazmat> if i already uploaded tools to the bucket, shouldn't it defer to those tools on subsequent bootstraps?
[19:47] <hazmat> dimitern, yeah.. that's the core
[19:48] <hazmat> perhaps constraints are working yet.. ?
[19:48] <hazmat> i though they worked for the bootstrap node
[20:00] <hazmat> hmm.. sans constraints, failed bootstrap it looks because it can't find/setup mongo http://juju-dist.s3.amazonaws.com/tools/mongo-2.2.0-quantal-i386.tgz
[20:00] <hazmat> 32bit client dictation
[20:01] <dimitern> hazmat: exactly, that was my point - there is no mongo 2.2 for i386
[20:01] <hazmat> oh.. thats why it can't find the image either.. its client dictating 32bit for tools and cascading to images.. mongo. etc
[20:02] <dimitern> hazmat: yeah, it's viral
[20:02] <dimitern> hazmat: you could try without --upload-tools
[20:03] <dimitern> hazmat: but i'm not sure there are i386 tools in the dist bucket at all
[20:06] <hazmat> dimitern, no matching tools version without the --upload
[20:07] <dimitern> hazmat: you can probably build mongo from source + ssl and put at the same path in your private bucket from environ
[20:07] <hazmat>    dimitern easier to fire up a 64bit vm
[20:07] <hazmat> but thanks for helping debug
[20:07] <dimitern> :) sure
[21:08] <fwereade> hazmat, sorry about that -- fixing up the tool-finding is in the backlog and I hope we will get there soon