[00:04] <lockheartmac> hello
[00:04] <lockheartmac> im new to bzr, but can it be used for Flash or Photoshop files?
[00:05] <rjek> Sure, but the diffs won't be very readable. :)
[00:05] <rjek> I don't know how efficent it is at storing binary files, but it certainly can.
[00:06] <lockheartmac> cool
[00:06] <lockheartmac> do you know of something else that might be better for tose types of files?
[00:07] <lifeless> bzr should be fine
[00:07] <lifeless> I have heard of people versioning iso's in bzr
[00:07] <lockheartmac> nice! im gonna give it a try, thanks!
[00:10] <rjek> lifeless: Why are they versioning ISOs rather than the files and the scripts to create the ISO from them?
[00:11] <lifeless> rjek: congenital insanity ?
[00:11] <rjek> I see. :)
[00:21] <Kinnison> night all
[00:36] <lifeless> spiv: ping
[00:38] <spiv> lifeless: pong
[00:42] <lifeless> can I slip that patch in with the single large test ?
[00:43] <spiv> lifeless: yes
[00:44] <spiv> lifeless: sorry, I should have said so explicitly
[00:44] <spiv> lifeless: I'd love to find a nice way to deal with that situation, because I have tests that would be improved too :)
[00:48] <edencane> Hi. Ive updated a library file in the tree; did a bzr remove <oldfile>; bzr add <newfile>; then bzr commit;
[00:48] <edencane> then bzr push;
[00:48] <edencane> THe files are not in the tree though? Why would that be?
[00:52] <edencane> anyone able to help?
[00:53] <bob2> what method are you using to push?
[00:53] <bob2> not all of them update the remote working tree
[00:53] <edencane> just bzr push
[00:54] <bob2> e.g. bzr+ssh, sftp, ...
[00:54] <edencane> sftp
[00:54] <bob2> I don't think sftp updates the tree (which seems reasonable, since it's not executing bzr on the other end)
[00:54] <bob2> does "bzr up" in the remote tree make the files appear?
[00:56] <edencane> how would I do that? bzr up sftp:<foo>?
[00:56] <bob2> "ssh remotehost '(cd /to/remote/dir ; bzr up)"
[00:56] <AfC> edencane: I think he meant ssh'ing to the machine in question and running `bzr update` in the branch
[00:57] <edencane> hmmm
[00:57] <AfC> (because I know that's what I do in the one external branch that I keep an up to date tree in)
[00:58] <edencane> maybe... bzr push  seems to push the changes Ive made to local files
[00:58] <lifeless> edencane: if you want the files to be visible there you need to run bzr at the far end; but other bzr users can pull from it already
[00:58] <lifeless> edencane: .bzr is a database
[00:59] <edencane> this is a replacement of a library...
[00:59] <AfC> eg the difference between http://research.operationaldynamics.com/bzr/java-gnome/mainline/ and say http://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/missing/
[01:01] <edencane> normally if I do a bzr add <file> or bzr remove <file> do I need to do bzr commit on <file> as well?
[01:01] <AfC> lifeless: sometimes I wonder if push shouldn't have updated when run locally. Of course, that's the confusing badness that most other systems force their users to deal with, but we sure do run into people not understanding the "remote push usually can't update remote working tree" thing.
[01:02] <bob2> edencane: yes, or just a commit of the whole tree
[01:02] <AfC> ... but maybe it would have taught people the difference between push and update (and the fact that push locally _does_ an update). Perhaps we should make that more explicit locally?
[01:03] <edencane> bob2: ohkay, I didnt do the bzr commit on both the old file (removed) and new file (added)
[01:03] <spiv> edencane: until you "bzr commit", no changes you've made will be recorded in the branch.  "bzr add <file>" is a change, just like editing a versioned file.
[01:03] <edencane> Ahhhh
[01:03] <edencane> Okay...
[01:03] <edencane> Thanks ever so much...
[01:04] <bob2> edencane: if it's a new version of some file, you could just copy it over and commit the modification of the file rather than its' replacement
[01:04] <AfC> edencane: [you threw us off when you said you'd committed]
[01:04] <AfC> edencane: [as commit without args commits all pending changes]
[01:05] <AfC> bob2: indeed. Far better to do that
[01:07] <edencane> hmmmm I see your point, but in many cases I have a lot of crud files kicking around that I dont want to commit...
[01:08] <TFKyle> edencane: if they're new files that you don't want to add just don't add them, for modifications to existing files possibly have a look at bzr shelve (part of bzrtools)
[01:08] <edencane> bob2: it wasnt a new version, it was a replacement library like: somelib1.3.3 replaced with someLib2.0.7
[01:08] <TFKyle> (well, shelve/unshelve)
[01:09] <lifeless> AfC: thats a good idea; just a printline would help
[01:10] <edencane> AfC: yea, I always commit specific files, sorry
[01:13] <AfC> lifeless: you want a bug for that, or is that a "just do it"
[01:13] <AfC> edencane: which would have been find had you committed all the files relevant to the change you were trying to capture
[01:21] <poolie> hm something odd is happening trying to get the .sig file...
[01:21] <lifeless> AfC: mail to the list
[01:24] <poolie> hm. the incorrect mime types make firefox pretty unhappy....
[01:37] <igc> ping spiv
[01:38] <igc> spiv: on a typical project, what sort of performance gain do you expect using the smart server vs plain http?
[01:38] <lifeless> igc: you'll need to benchmark it ;)
[01:39] <lifeless> igc: its probably marginally faster than sftp for packs today
[01:39] <igc> my benchmarks overnight are showing plain http is now quite quick with packs
[01:39] <igc> whereas bzr+ssh is a fair bit slower
[01:39] <lifeless> good
[01:39] <lifeless> ;)
[01:40] <igc> lifeless: downloading 33 projects on a LAN over plain http is 708 seconds
[01:40] <AfC> bzr:// use the same packs (and realizes the same efficiencies) as http://, right?
[01:41] <igc> lifeless: using bzr+ssh, it's taking 1908 secs
[01:41] <igc> so I'm wondering whether I'm doing something wrong :-)
[01:41] <TFKyle> igc: what version of openssh are you using?
[01:41] <lifeless> AfC: not quite; but due to bugs not design
[01:42] <lifeless> TFKyle: its not that
[01:42] <TFKyle> (probably not that, but you never know)
[01:42] <igc> whatever version comes with gutsy :-)
[01:42] <lifeless> igc: you are using bzr.dev on this end and 1.0 on the other
[01:42] <lifeless> igc: or something similar
[01:42] <igc> yep
[01:42] <AfC> lifeless: oh. That's discouraging
[01:43] <lifeless> igc: so you are not getting a streaming pull, you are falling back to VFS, and the bzr VFS does not do readv expansion so the index reads will be bisecting in 200 byte ranges, rather than 64K ones
[01:43] <igc> the remote machine is running bzr 1.0 on Leopard
[01:43] <lifeless> AfC: they are being fixed right now
[01:43] <igc> the local machine is bzr.dev on gutsy
[01:44] <lifeless> igc: yes, this fits my prediction
[01:44] <lifeless> igc: for benchmarks always have the server be a >= bzr than the client
[01:44] <AfC> lifeless: sweet [We invested considerable effort circa 0.91 to get the server running and to get everyone converted to bzr:// URLs, so I was hoping that all that hadn't been deprecated]
[01:44] <lifeless> AfC: heck no
[01:44] <lifeless> AfC: just teething problems between VFS changes and smart server changes not lining up quite right
[01:45] <igc> lifeless: fwiw, we whip hg now on plain http serving: 708 secs vs 2200 secs
[01:45] <lifeless> what latency are you benching with?
[01:45] <lifeless> ratchet it up to 150ms or so
[01:45] <AfC> lifeless: (I came across this question more as an offshoot when I was researching what would be involved in switching people to packs)
[01:45] <igc> it's a 100Mb LAN
[01:46] <AfC> igc: that's excellent news.
[01:46] <igc> lifeless: I'm looking at netem today
[01:46] <AfC> igc: (we should publish that somewhere)
[01:47] <lifeless> AfC: if you have a server version that is >= your bzr client version you'll get a streaming pull which should be faster than packs; or at least close to
[01:47] <lifeless> we're working on making it faster
[01:47] <igc> AfC: it's nice to know. The smart server comparison is more meaningful though I suspect
[01:47] <AfC> igc: yeah
[01:47] <AfC> igc: they did after all go there from the very beginning.
[01:48] <AfC> lifeless: [both are 1.0 atm]
[01:48] <igc> and configuring Hg is more painful than I expected so my main focus is our benchmarks, not theirs
[01:49] <AfC> sure
[01:50] <AfC> "configuring Hg is more painful" ... that's the sort of critique that while subjective nevertheless resonates widely. I would encourage you to put that into a blog post with some details.
[01:50] <AfC> (which people like me could link to)
[01:50] <igc> AfC: coming from someone that works at Canonical, people expect me to say that
[01:51] <igc> AfC: better if you blog that I think :-)
[01:52] <AfC> igc: I didn't do the tests, I didn't have the experience. You did. You're the one that found hg cumbersome to use. I'd be interesting in hearing why (and why you think bzr takes a better approach to $whatever). You are more than eminently qualified to report on such things
[01:52] <igc> AfC: in the end, I gave up trying to find out how to push over sftp with Hg, particularly initial push
[01:52] <AfC> And more to the point, if you guys don't blow your own horn, no one else will.
[01:53] <igc> so I went with scp to just get the files pushed across
[01:53]  * AfC laments that he has several tens of draft blog posts of this sort of critique/experience across many projects that he hasn't quite gotten around to tying together into a cohesive point yet
[01:54] <igc> it really is sweet how Bazaar doesn't require anything on the server bar ssh access
[01:56] <AfC> Café
[01:57] <lifeless> igc: hg wants a smart server always unless you do speciall stuff
[02:03] <igc> lifeless: yeah - it's really annoying
[02:34] <lifeless> poolie: jam: ping?
[02:35] <poolie> ready when you are
[02:36] <jam> hi lifeless, poolie  are we doing a conference call?
[02:38] <lifeless> conf centre?
[02:38] <jam> sure, dialing now
[02:39] <jam> waiting for the "leader"
[02:40] <lifeless> standing by
[02:41] <jam> poolie: you coming?
[02:41] <poolie> sure
[03:07]  * igc lunch
[03:43] <fullermd> lifeless: How much of that streaming SS capability is making 1.1?
[04:24] <lifeless> fullermd: none
[04:24] <fullermd> Oh.  Well, that makes it easy to quantify   :)
[04:28] <abentley> jelmer: ping
[04:29] <abentley> Or anyone-who-groks-pygtk: ping
[04:29] <spiv> jamesh: I hear you know a little about pygtk ;)
[04:30] <jamesh> I've heard that rumour too
[04:30] <abentley> jamesh: I'm using a VBox to add a toolbar to a diff window, and I'm getting some strange sizing issues.
[04:31] <abentley> It seems like pack_start isn't honoring the expand parameter.
[04:32] <abentley> I do self.vbox.pack_start(scrollwin, expand=True, fill=True)
[04:32] <abentley>         self.vbox.pack_start(merge_button, expand=False, fill=False)
[04:32] <abentley> And the button and the scrollwin take equal amounts of space.
[04:33] <jamesh> that should make scrollwin take any space above the requested minimum
[04:33] <jamesh> what's the vbox packed inside of?
[04:33] <abentley> That's what I thought, but it's not what I'm seeing.
[04:33] <jamesh> (i.e. what is its sizing policy?)
[04:35] <abentley> The vbox is in a subclass of Window.  That subclass has set_default_size invoked to set it to 66% of screen width, 66% of screen height.
[04:35] <jamesh> is the code available somewhere?
[04:36] <abentley> I'll put it up.
[04:37] <abentley> Also strange is that the fill parameter has an effect even when expand=False.
[04:37] <jamesh> well, fill would generally affect only the horizontal space used by the child in a vbox
[04:37] <abentley> Okay, it's up at http://code.aaronbentley.com/bzr/bzrrepo/bzr-gtk-meld
[04:38] <abentley> Right, but the docs say it has no effect when expand=False.
[04:38] <jamesh> that doesn't sound correct
[04:38] <abentley> Or do I have it backwards?
[04:38] <poolie> spiv, i guess i'm not coming up today...
[04:39] <abentley> "The fill argument to the pack methods control whether the extra space is allocated to the objects themselves (True), or as extra padding in the box around these objects (False). It only has an effect if the expand argument is also True."
[04:41] <abentley> The branch I put up is bzr-gtk.
[04:41] <lifeless> whee that was a call
[04:41] <jamesh> abentley: http://developer.gnome.org/doc/GGAD/sec-containers.html <- it's a bit old, but it is a good description of box packing
[04:42] <jamesh> abentley: if expand=False for a child of a vbox, it won't be allocated any more height than it requested
[04:43] <jamesh> abentley: but the width of the vbox may be wider than what the child requested -- the fill setting comes into play here
[04:43] <abentley> jamesh: That's what I would expect.
[04:44] <abentley> jamesh: What I am seeing is that the button is always full-width.
[04:44] <jamesh> found it:
[04:44] <jamesh>         self.vbox = gtk.VBox(True)
[04:44] <spiv> poolie: not a problem
[04:45] <jamesh> you've created a homogeneous vbox, where each child is allocated equal size
[04:45] <jamesh> change that to self.vbox = gtk.VBox() and you should be set
[04:45] <abentley> Thanks.
[04:45] <abentley> I must have copied-and-pasted without realizing I was breaking myself.
[04:45] <abentley> I confirm that fixes it.
[04:53] <lifeless> this carpet install is driving me bats
[04:56] <abentley> My mind is sufficiently warped that I wondered whether that was a derogatory term for apt-get dist-upgrade.
[04:56] <abentley> Installation as carpet-bombing
[05:00] <lifeless> lol
[05:00] <lifeless> no the apartment above is being renovated
[05:00] <lifeless> bastards
[05:01] <lifeless> next week would have been fine
[05:03] <bob2> for you!
[05:05] <spiv> lifeless: any ideas on how to test the socket connection error handling?
[05:05] <spiv> lifeless: the obvious thing is to just try connecting to "bzr://unknown.local/" or something.
[05:06] <spiv> lifeless: But I fear sufficiently badly configured systems will manage to resolve it, leading to spurious test failures...
[05:06] <spiv> lifeless: I suppose I coudl write Feature that checks that some impossible host name really does fail to resolve...
[05:07] <fullermd> It's not spurious.  It points to a real problem   ;)
[05:07] <spiv> fullermd: it's a real problem, but not the one the test is trying to catch :P
[05:08] <spiv> fullermd: I think probably the user in that case would be better served by a "missing feature" message telling them not to have crazy wildcard resolvers
[05:08] <fullermd> Well, it's not like you're often going to get random people running selftest and watching their system nail itself to the wall for 45 minutes...   selftest is mostly a dev tool.
[05:09] <fullermd> I'd use "nonexistent.invalid" or something like that, since .invalid is spec'd to not exist.
[05:10] <spiv> Hmm, I think a Feature is probably right for it.
[05:11] <dysinger> Hey
[05:11] <spiv> Given that it's a property of the environment running the tests that is needed to run a particular test.
[05:11] <dysinger> Congrats on the 1.1
[05:11] <spiv> But it's also something that doesn't make bzr itself behave incorrectly.
[05:12] <fullermd> Reasonable enough, I s'pose.
[05:12] <fullermd> Just my Long-Suffering Sysadmin hat makes me want to inflict immediate pain on people with b0rked setups   :p
[05:12] <spiv> fullermd: thanks for the "nonexistent.invalid" suggestion.
[05:14] <jamesh> spiv: you could try something under example.com
[05:15] <spiv> jamesh: is that likely to be any better than something under .invalid?
[05:15] <fullermd> Well, ICANN _could_ make hosts under example.com.  The .invalid TLD is specifically for nonexistence.
[05:16] <jamesh> fullermd: ... and so is available for local host names
[05:16] <spiv> http://www.rfc-editor.org/rfc/rfc2606.txt seems to suggest that .invalid is a better fit than .example or example.com
[05:16] <jamesh> the machines on my local network have .henstridge.invalid hostnames
[05:17] <lifeless> lol, rather than .local ?
[05:17] <jamesh> lifeless: the ones with zeroconf setup also have .local names asserted via mDNS
[05:19] <lifeless> I think fullermd is right
[05:19] <lifeless> a feature that depends on an unresolvable hostname
[05:19] <fullermd> Surely you can't be implying that there are people in the world who don't own their own vanity domain already?   ;)
[05:20] <jamesh> spiv: you could also try picking a syntactically invalid domain name, I guess
[05:20] <jamesh> e.g. one with underscores
[05:21] <spiv> jamesh: I could even do both!
[05:21] <fullermd> An implementation could conceptually throw a different error for that...
[05:22] <dysinger> so does anyone have bzr-svn working on the mac ?
[05:22] <jamesh> spiv: http://www.rfc-editor.org/rfc/rfc2606.txt <- that's the relevant RFC
[05:22] <dysinger> I couldn't get it to work on leopard
[05:22] <spiv> jamesh: I know, I gave that link 6 minutes ago ;)
[05:23] <jamesh> garr
[05:23] <spiv> lifeless: thanks
[05:23]  * spiv writes the test + feature
[05:27] <jamesh> hah.  Microsoft has a knowledge base article stating "Make sure if you choose not to register a name that you choose a name that is unique. You can review existing names at http://www.networksolutions.com (http://www.networksolutions.com)."
[05:27] <jamesh> maybe you could do the same for your test, and pick a .com that is not currently registered
[05:28] <fullermd> Well, if we're going that way, we could just set up invalid.bazaar-vcs.org.
[05:28] <fullermd> (well, or not set up, depending on your semantics ;)
[05:29] <jamesh> then we could monitor who is running the Bazaar test suite by tracking nameserver logs
[05:29] <fullermd> Going to .invalid should finish in just a query to the roots, though.  Elsewhere might take several steps, wasting a bit of time and a bit more load on various servers along the way.
[05:30] <fullermd> Oh, well, you want monitoring, then you want ${bzrlib_vesion}.invalid.b-v.o.
[05:30] <jamesh> or ${username}.${bzrlib_version}.invalid.b-v.o
[05:31] <fullermd> % bzr selftest
[05:31] <fullermd> Please enter your credit card number: _
[05:37] <spiv> lifeless: http://rafb.net/p/svj9Hw22.html
[05:37] <dysinger> So this no-way-to-import-svn and no-way-to-work-on-top of svn is keeping me on Git.  I sure wish there was a way to get it working on OS X Leopard.  It probably works fine with Tiger (becasue SVN & svn-python doesn't come pre-installed)
[05:37] <spiv> lifeless: does that test + feature look ok?
[05:37] <spiv> lifeless: should I move the feature to bzrlib/tests/__init__.py?
[05:38] <spiv> fullermd: it could be "Please enter your licence key: _" ;)
[05:39] <keir> i want to have a make (ok, scons) rule which bakes the bzr version into a header file, so that gets baked into every binary. is there a 'best practice' way to do this with bzr?
[05:41] <spiv> keir: how about "bzr revision-info"?
[05:42] <lifeless> I think the feature is fine in place
[05:42] <keir> spiv, great, thanks.
[05:42] <bob2> should that command be hidden?
[05:43] <keir> spiv, hmm; i want to also reflect if there are local changes. something like revision-info with '+local mods'
[05:44] <lifeless> spiv: +1
[05:44] <dysinger> ok thanks for the help.  Talk to you later.
[05:44] <spiv> lifeless: thanks!
[05:44] <lifeless> keir: also, consider bzr version-info
[05:44] <lifeless> keir: which is more comprehensive, can output C etc etc
[05:45] <keir> ah, cool; almost perfect
[05:45] <keir> --clean requires no unknown files?
[05:51] <keir> wow, 1.1! congrats
[05:52]  * spiv figures if the website announces it, the IRC topic might as well announce it too :)
[05:53]  * fullermd blinks.
[05:53] <fullermd> Did I miss an announcement?
[05:54] <spiv> fullermd: I haven't seen an email yet, but the website has been linking to it for a couple of hours now
[06:00] <AfC> Gentoo rev bump filed.
[06:01] <ubotu> New bug: #183079 in bzr "added fails when not run in tree root" [Undecided,New] https://launchpad.net/bugs/183079
[06:08] <fullermd> FreeBSD port update, ditto.
[06:44] <poolie> thanks
[06:44] <poolie> i did send an announcement mail
[06:44] <poolie> might be held?
[08:38]  * igc dinner
[09:04] <matkor> Hi ! How to perform such task. How to uncommit changes to one given file back to given revision ?
[09:06] <matkor> I during commit I commited mostly valid changes except one file, later a did a lot of commits, now I would like to revert changes introduced by that old commit but only intoruduced to one specific file ?
[09:07] <matkor> I short, hot to say in bzr: bzr want-now-that-file-as-it-was-than <filename> -r <revno> ?
[09:07] <fullermd> bzr revert -rwhatever $FILE
[09:08] <lifeless> spiv: ping
[09:08] <lifeless> a = [('call_expecting_body',
[09:08] <lifeless>   'Repository.get_parent_map',
[09:08] <lifeless>   ('///quack/', '\xe0\xb6\xab'))]
[09:08] <lifeless> b = [('call_expecting_body',
[09:09] <lifeless>   'Repository.get_parent_map',
[09:09] <lifeless>   ('quack/', '\xe0\xb6\xab'))]
[09:09] <lifeless> after your most recent commit to bzr.dev.
[09:09] <lifeless> (you reviewed myy patch with this test in it; is it sane to replace /// with '' in my test and thats all ?
[09:15] <matkor> fullermd: Yah. So simple ... Thank you very much.  As far bzr has highest question to answer size ratio for me ;)
[09:35] <Peng> Omgyay! The bzr+http path issue really was fixed!
[09:35]  * Peng hugs spiv.
[09:45] <Peng> Hm, now that the pack format exists, I guess it's not so useful..
[09:45] <Peng> I do still have one project in dirstate though.
[09:47] <AfC> bzr 1.1 now in Gentoo
[09:53] <Peng> Hmmm.
[09:55] <Peng> What the heck? .bzr/smart for one branch gives a 404.
[09:55] <Peng> It works fine for every other one.
[09:56] <Peng> .htaccess issue. Apparently "RewriteEngine on" in a child .htaccess negates rewrites in parents?
[09:57] <Peng> Or any mod_rewrite stuff at all, I guess.
[10:03] <Peng> RewriteOptions inherit. Okies.
[10:03] <Peng> I know, it was never on-topic, but I'm afraid of #apache and wanted somewhere to think out loud. :P
[10:09] <spiv> lifeless: right
[10:10] <Peng> spiv: You rock!
[10:10] <spiv> Peng: it's not totally fixed yet
[10:10] <Peng> What's still wrong?
[10:10] <spiv> Peng: but the client part of it was a pretty big part.
[10:10] <Peng> It's fixed enough that it works for me.
[10:11] <spiv> Peng<EMAIL_ADDRESS>[10:11] <spiv> Peng: yeah
[10:11] <spiv> Peng: that's the main thing :)
[10:11]  * Peng watches hundreds of POSTs scroll by during a "bzr branch".
[10:13] <Peng> All the recent ones are for 680-690 bytes.
[10:15] <Peng> Oh, good, two 60 KB ones were thrown in.
[10:15] <fullermd> I can just see the paper...  "bzr smart requests as a PMTU discovery tool"
[10:16] <spiv> Peng: yeah, the readv stuff with the smart protocol isn't particular, um, smart for some reason.
[10:16] <Peng> So I've noticed.
[10:17] <Peng> Oh, good, it finished in 8m36.343s.
[10:17] <Peng> Dumb http only took 1m14.493s.
[10:17] <spiv> Yeah, that's mainly the readv borkage I belive.
[10:18] <spiv> Especially now that lifeless has starting improving the remote graph stuff.
[10:18] <Peng> The remote graph stuff is making it better or worse?
[10:18] <spiv> Better.
[10:19] <Peng> Oh, good.
[10:19] <Peng> That's a client-side thing?
[10:19] <spiv> Both.
[10:20] <spiv> New smart verbs to more efficiently fetch graph info to find graph differences.
[10:21] <Peng> Ok.
[10:22] <spiv> If you have the latest bzr.dev on both ends you shouldn't get much readv borkage, I think.
[10:22] <spiv> (because it'll get the info it needs using other methods, rather than because readv has been fixed in bzr.dev)
[10:22] <Peng> I do have the latest bzr.dev on both ends.
[10:23] <spiv> Oh.  Hmm.
[10:23] <Peng> And it took 450 mostly-sub-KB requests to make a branch of a smallish project of 150 revisions.
[10:23] <spiv> Ah well, more to do then :)
[10:23] <Peng> (pytz).
[10:23] <spiv> Peng: those requests were readv, I presume?
[10:23]  * spiv is just double-checking
[10:23] <Peng> Using FastCGI definitely speeds it up.
[10:24] <Peng> spiv: I dunno. They read a few hundred bytes.
[10:24] <Peng> I ran locally with lots of -D options so I can probably figure it out.
[10:24] <spiv> -Dhpss should give you plenty of info
[10:24] <Peng> I used -Dhpss -Dhttp.
[10:25] <Peng> It appears to have recorded the full request and response headers of every request.
[10:25] <Peng> You want to sort through it? :D
[10:25] <spiv> Heh.
[10:25] <spiv> Just -Dhpss is probably a better bet in this case :)
[10:26] <Peng> Yeah. I did both because I was testing both http and bzr+http and wanted to use the same args for both of them.
[10:26]  * spiv nods
[10:31]  * Peng wonders how much the debug data contributed to those times.
[10:35] <spiv> Peng: probably a bit  :)
[10:37] <Peng> http on a dirstate branch took 392 requests. bzr+http took 422.
[10:38] <spiv> Peng: what took up the bulk of the bzr+http requests?  Was this a push or pull?
[10:38] <Peng> spiv: "bzr branch".
[10:38] <Peng> http://bzr.mattnordhoff.com/bzr/pytz/pytz-current/ , FWIW.
[10:38] <spiv> Ta
[10:39] <fullermd> Every time I look at the bzr+http setup, I get skeered   :|
[10:40] <spiv> Peng: you don't seem to have the most recent bzr.dev on the server
[10:40] <Peng> Eeerrrr.
[10:40] <spiv> Peng: if you did, you'd see the number of requests drop dramatically
[10:40] <Peng> You know what?
[10:40] <Peng> bzr.dev isn't in my PYTHONPATH.
[10:40] <Peng> That's 1.1.
[10:40] <spiv> Right :)
[10:40] <Peng> I knew that would bite me eventually.
[10:40] <spiv> Peng: The "   result:    0.666s  'error', "Generic bzr smart protocol error: bad request 'Repository.stream_revisions_chunked'"
[10:40] <spiv> "
[10:40] <spiv> gave it away
[10:40] <Peng> Humm.
[10:41] <spiv> That verb is in bzr.dev, but not 1.1
[10:41] <Peng> How do you think I should solve this?
[10:41] <spiv> Apache?
[10:41] <Peng> Add the path to bzr.dev to sys.path? "setup.py install" bzr.dev and remember to rerun it every time I update?
[10:42] <spiv> Peng: you're using FastCGI, IIRC?
[10:42] <Peng> spiv: Yessir.
[10:42] <spiv> Peng: you could put some sys.path hackery in the little glue script.
[10:42] <Peng> That's what I was thinking.
[10:42] <Peng> Will do.
[10:42] <spiv> Or build nightly debs of bzr.dev for us ;)
[10:43] <fullermd> I s'pose someday I should apply some of my CFT to seeing if it's setupable...
[10:44] <spiv> fullermd: wait till bug 129089 is fully fixed first
[10:44] <ubotu> Launchpad bug 129089 in gnome-system-tools "Modified user not listed" [Low,Invalid] https://launchpad.net/bugs/129089
[10:44] <spiv> Er
[10:44] <spiv> 124089
[10:44] <spiv> Ahem, bug 124089
[10:44] <ubotu> Launchpad bug 124089 in bzr "wsgi smart server chrooting does not manage additional paths" [High,In progress] https://launchpad.net/bugs/124089
[10:44] <spiv> Thanks ubotu
[10:45]  * spiv wishes IRC bots were telepathic
[10:45] <dato> just live long enough ;)
[10:45] <Peng> Ok, fixed.
[10:45] <fullermd> Well, it just seems like it would be painful to do well enough.  Glancing over the doc, it's full of hardcoded paths.
[10:45] <Peng> spiv: How do I check if it's using bzr.dev?
[10:46] <fullermd> I don't think that bug would change that...
[10:47] <spiv> Peng: judging by my -Dhpss output, it is :)
[10:47] <spiv> Peng: also,
[10:47] <spiv> andrew@steerpike:/tmp$ time bzr -Dhpss branch bzr+http://bzr.mattnordhoff.com/bzr/pytz/pytz-current/
[10:47] <spiv> Branched 151 revision(s).
[10:47] <spiv> real    0m39.611s
[10:47] <Peng> Lucky low-latency/high-speed Internet connection bastard.
[10:47] <spiv> I'm in .au
[10:47] <Peng> Wait, it took 27 seconds for me.
[10:47] <spiv> I don't think the latency is low :)
[10:48] <Peng> 27 seconds is awesome.
[10:48] <spiv> I think it's the new smart verbs doing what they're supposed to do :)
[10:48] <fullermd> Branched 151 revision(s).
[10:48] <fullermd> 2.262u 0.571s 0:21.20 13.3%     113+146k 0+0io 0pf+0w
[10:49] <fullermd> Looks like ~93ms latency from here.
[10:50] <Peng> Blahg, 2 or 3 of us did things at once.   I should be able to move that much data in about 3 seconds   :p
[10:51] <spiv> dato: I think you probably need a fix that landed earlier today.
[10:51] <dato> spiv: ah, I didn't pull today
[10:51] <spiv> fullermd: yeah, there's still a heap of unnecessary roundtrips in there
[10:51] <dato> spiv: btw, do you plan to make http (as opposed to bzr+http) look if there's a smart server available?
[10:52] <dato> or is that done already?
[10:52] <spiv> dato: I think that would probably be nice
[10:52] <spiv> dato: Although I'm a bit scared to do that until bzr+http is a little more mature.
[10:52] <dato> spiv: yeah, "at some point in the future"
[10:52] <spiv> Right.
[10:53] <dato> ok
[10:53] <fullermd> Would it be a fair bet that we couldn't really dump some of those absolute paths in the config until we could turn off VFS methods altogether in the SS?
[10:53] <Peng> What about making bzr+http fall back to http?
[10:56] <fullermd> Or maybe there's some way to get Apache to pass down paths for the chrooting?  Seems like it would dig deep into FCGI messes real quick, though   :|
[11:01] <Peng> FWIW, I put up a copy of that branch in packs at http://bzr.mattnordhoff.com/bzr/pytz/pytz-current.packs/
[11:02] <Peng> Took 13.7 seconds to branch.
[11:02] <Peng> That is, over http.
[11:02] <Peng> 22 over bzr+http.
[11:03] <Peng> Fewer requests over http too.
[11:04] <spiv> Peng: yeah, there's still plenty of dumb things to fix in the smart server.
[11:06] <Peng> Those times count building the working tree too.
[11:06]  * spiv nods
[11:07] <Peng> So bzr+http is a huge win for dirstate with bzr.dev, but not so much for packs.
[11:10]  * Peng notices that the developer of the project is using dirstate while I am using dirstate-tags.
[11:13] <Peng> Um, did any of you poke my site from t-ipconnect.de, or do I have a bot on my hands?
[11:14] <fullermd> I'm a long way from anything .de...
[11:15]  * dato too
[11:15] <spiv> Not me.
[11:16] <Peng> Also, the user-agent was "CFNetwork/220", some library or something.
[11:16] <Peng> Huh.
[11:17] <Peng> How can I switch a branch from dirstate-tags to dirstate?
[11:18] <dato> Peng: b init --dirstate foo; cd foo; b pull /path/to/dirstate-tags
[11:19] <spiv> Peng: http://rafb.net/p/LS6bB821.html may make bzr+http with packs faster
[11:19] <Peng> Hm, what would Launchpad think if I did that?
[11:19] <spiv> Peng: launchpad will cope just fine
[11:20] <Peng> Will it change the format of the mirrored branch
[11:20] <Peng> ?
[11:20] <spiv> Yep.
[11:20] <Peng> Ok.
[11:21] <fullermd> Are you sure you need to, though?
[11:21] <Peng> Of course I don't need to.
[11:21] <fullermd> I mean, they won't be able to get your tags, but the repo format is still the same and all, so...
[11:21] <Peng> I don't use any tags.
[11:21] <Peng> Upstream uses dirstate and I want to use the same format.
[11:21] <fullermd> And going down to branch5 means your locations.conf gets all polluted again.
[11:22] <Peng> It's just the remote branch. Locally I use packs.
[11:27] <spiv> Peng: FWIW, with that patch, time to branch pytz-current.packs with bzr+http drops to 29.7s from 38.3s.
[11:27] <spiv> Peng: (vs 15.2s for plain http)
[11:28]  * fullermd is very glad to see all the SS work lately.
[11:29] <spiv> Me too!
[11:29] <spiv> :)
[11:30] <Peng> spiv: Send the patch in, then? :)
[11:32] <fullermd> Yeah, we'll alibi you   ;)
[11:32] <fullermd> "No sir, he couldn't have sent anything to PQM.  He was sitting with us waiting for the smart server to finish branching a pack repo, see..."
[11:32] <spiv> Peng: I am :)
[11:32] <Peng> Cool.
[11:37] <Peng> Well, this has been a fun and bandwidth-wasting night. :)
[11:37] <spiv> Peng: thanks for the feedback!
[11:38] <dato> Peng: oh, I thought you were in Europe?
[11:38] <Peng> dato: No, I'm just a bat.
[11:39] <fullermd> If you can hear this, you're a bat:
[11:50] <poolie> night...
[12:02] <lifeless> spiv: is the client path change compatible with older servers?
[12:25] <ubotu> New bug: #183156 in bzr "bzr branch uses too much RAM when not using a shared repository" [Undecided,New] https://launchpad.net/bugs/183156
[12:36] <fullermd> Well, I've pushed over bzr+ssh to a 1.0 server once or twice since I pulled down the change...
[14:48] <beuno> anyone know where I can get a bzr 1.0 .deb for feisty?
[14:57] <beuno> http://rafb.net/p/yPNFTT74.html
[14:57] <beuno> hmmmm, I'm having a recurring problem with a packs repository, anyone know why this might be happening:  http://rafb.net/p/yPNFTT74.html
[14:59] <luks> https://launchpad.net/~bzr/+archive
[15:00] <beuno> luks, thanks!  (that should be added on the /Downloads page, shouldn't it?
[15:01] <luks> I don't know, for some reason everybody keeps talking how unofficial PPA is, but it's the only place with actually updated packages
[15:02] <beuno> alright, let's take this to the mailing list then
[15:04] <mdz_> I need to create some diagrams to explain how a set of branches are arranged.  Can anyone offer advice regarding suitable tools?
[15:05] <Kinnison> inkscape?
[15:05] <beuno> mdz_, related branches?   bzr-gtk has a neat tool, "visualize"
[15:05] <Kinnison> inkscape can do 'attachment' lines
[15:05] <Kinnison> otherwise I'd suggest something like visio
[15:06] <Kinnison> I think OO's draw thingy can do flowchart type stuff too
[15:06] <mdz_> these happen to be branches I haven't created yet, so I was thinking diagramming tools, but I suppose I could create them and try "visualize"
[15:06] <mdz_> what does the output look like?
[15:07] <Kinnison> of visualise?
[15:07] <mdz_> yes
[15:07] <luks> I think bzrtools has something to produce a graphviz sources?
[15:08] <Kinnison> http://users.pepperfish.net/dsilvers/vis-example.png
[15:08] <mdz> thanks
[15:08] <mdz> I think bzr visualize would do what I want
[15:08] <mdz> I can just set up some dummy branches and do it that way
[15:09] <mdz> thanks
[15:09] <Kinnison> no problem
[15:09] <beuno> mdz, the branches have to be related, make sure you explicitly branch from each other and merge back into the parent so you get that kind of output
[15:09] <beuno> (eg. don't "cp" the repositories)
[15:09]  * Kinnison ponders screenshotting the bit of aranha's history where unrelated branches are merged together :-)
[15:10] <mdz> beuno: will do, thanks
[15:10] <jdahlin> How can I set the default branch bzr push will use if I don't provide a branch argument?
[15:10] <Kinnison> jdahlin: pardon?
[15:10] <mtaylor> hey guys... in cmd_commit(), there's a bit near the end where it calls tree.commit()
[15:10] <beuno> jdahlin, you can do an empty push with --remember
[15:10] <mtaylor> but I can't seem to find the definition of the commit method that takes a callback object as a param
[15:11] <jdahlin> beuno, excellent, thanks!
[15:11] <beuno> :D
[15:11] <mdz> will bzr visualize show tags?
[15:12] <jelmer> mdz: it will show them once you've selected a revision
[15:12] <jelmer> mdz: it doesn't put them in the tree view yet
[15:12] <mdz> oh
[15:13] <jelmer> and there'
[15:13] <jelmer> s a menu item for going to a specific tag
[15:13] <rjek> Today's questions: 1) Can you export a SVG or similar from bzr vis?  2) Can bzr use HTTP PUT to push to http:// URLs?  3) Is there a C interface to bzr such that you can drive it from C or another language that can bind to C?
[15:13] <mdz> jelmer: would be great to see them in the tree view, but I can fake it for my purposes
[15:15] <beuno> rjek, you *can* use http to push AFAIK, but I know it's not recommended (not ideal way to transport that amount of data)
[15:16] <rjek> Why is it not ideal?
[15:16] <rjek> I'm beginning to get bored with having asymetrical respository access URLs.
[15:17] <beuno> rjek, I'm not that familiar with it, but I think it's just not what it's built for
[15:17] <Kinnison> it'd be fine if bzr smart server over http worked sanely
[15:17] <beuno> rjek, why not use sftp/ssh instead?
[15:17] <rjek> beuno: Because they don't allow for public access to a subset of my branches.
[15:18] <beuno> rjek, and how does http solve that?
[15:18]  * rjek idly wonders for a moment if HTTP PUT supports byte ranges.
[15:18] <rjek> beuno: Err, it trivially provides unauthenticated access to a subset of my branches for reading.
[15:18] <rjek> Where sftp and ssh cannot possibly
[15:19] <mtaylor> rjek: yeah - but you can push using ssh to a location that people can HTTP get from to branch
[15:19] <rjek> mtaylor: That's what I'm doing at the moment.
[15:19] <rjek> (well, read via HTTP, write via sftp)
[15:19] <beuno> rjek, well, anonymous read-only sftp could work, couldn't it?
[15:20] <rjek> beuno: Not that I know of, given sftp is based on top of ssh.
[15:20] <fullermd> Well, of course it _could_.  But it's not trivial.
[15:20] <beuno> and plain old ftp?
[15:21] <beuno> you can give read/write access to different users trivially
[15:21] <rjek> That'd involve me wanting to use ftp. :)
[15:21]  * fullermd takes FTP out back behind the woodshed.
[15:21] <mtaylor> fullermd: do you happen to know what the status is of adding a commit hook to inject or modify commit messages?
[15:21] <rjek> I suppose the issue will be solved when the smart server works.
[15:21] <mtaylor> fullermd: I see a TODO in the source...
[15:21] <fullermd> Not really, though I don't recall anybody mentioning working on or thinking heavily about it.
[15:22] <mtaylor> ok... so if I did some hacking on it, I wouldn't be stepping on anyone's toes that you know of?
[15:23] <fullermd> Wouldn't expect so.
[15:34] <jdahlin> Is there support for something like svn:externals in bzr?
[15:34] <Peng> Not yet.
[15:35] <jdahlin> When is it planned to be included?
[15:35] <Peng> In the fyooture.
[15:36] <Peng> I dunno.
[15:53] <mw> when was 1.1 released?  i don't see the announcement on the mialing list
[15:53] <jdahlin> today, it seems
[15:53] <mw> yeah
[15:54] <mw> maybe mail's just taking a while to come through
[15:54] <mw> it wouldn't be the first time :)
[16:05] <Peng> Yeah, I've seen it on the list.
[16:05] <Peng> The announce list, at least.
[17:10] <ubotu> New bug: #183244 in bzr "push aftp crash,  socket.error: (10054," [Undecided,New] https://launchpad.net/bugs/183244
[17:35] <vagrantc> is there a way to add the --append-revisions-only flag to a branch after it's been created ?
[17:35] <vagrantc> and is there a way to set it globally ?
[17:36] <vagrantc> i tried adding "append_revisions_only = True" to ~/.bazaar/bazaar.conf, but that didn't seem to work
[17:36] <dato> for the former, add it to foo/.bzr/branch/branch.cof
[17:36] <dato> branch.conf
[17:38] <vagrantc> dato: is there a way to add it to a remote branch using bzr itself? or do i need shell access to do so?
[17:46] <fullermd> There's no way to do it via bzr, no.
[17:46] <vagrantc> gah.
[17:46] <fullermd> You don't necessarily need shell access; you can just copy down the file, edit it, and copy back up, using sftp or however you're pushing.
[17:46] <vagrantc> pusshing using bzr+ssh
[17:47] <fullermd> Well, so you probably have sftp and scp available.
[17:48]  * vagrantc is trying to work with branches on launchpad
[17:49] <fullermd> Launchpad supports sftp.
[17:49] <Peng> In Soviet Launchpad, branches work with you.
[17:49] <Peng> I'm sorry.
[17:49] <vagrantc> supports it, but do i have any idea where any of the branches paths are?
[17:50] <fullermd> Well, if you're pushing to them, I should hope so   :)
[17:50] <vagrantc> well, it wasn't clear to me that the http/bzr+ssh/sftp URLs were basically the same paths
[17:51] <fullermd> AFAIK, the sftp and bzr+ssh paths are exactly the same, just with the different protocol specifier.
[18:34] <vagrantc> thanks for help regarding append_revisions_only
[18:34] <vagrantc> so there's no global way to make this the default for a given user?
[18:43] <hendrixski> :-( I'm having some trouble pulling from an svn repository... I have bzr-svn installed... and I've tried a few things in the ~/.bazaar/subversion.conf file... though I'm not sure it's the right thing
[18:44] <hendrixski> It keeps saying that it's not a valid subversion branching scheme... I'm totally lost
[18:54] <hendrixski> oh... heh, I just deleted the damn file and it seems to have worked
[19:05] <abentley> vagrantc: Sounds like a bug to me.  I certainly intended it to work in bazaar.conf and locations.conf
[19:06] <vagrantc> abentley: i'll test it a little more just to make sure, then. i'm using 1.0-1~bpo40+1 from backports.org on debian etch
[19:07] <abentley> Make sure you're using a branch format that supports it.
[19:07] <vagrantc> ah.
[19:07] <abentley> dirstate-tags and later support it.
[19:07] <abentley> dirstate and knit do not.
[19:08] <vagrantc> cat .bzr/branch-format
[19:08] <vagrantc> Bazaar-NG meta directory, format 1
[19:08] <vagrantc>  ?
[19:08] <vagrantc> bzr info seems to think it's dirstate-tags
[19:09] <dato> cat .bzr/branch/format fwiw
[19:10] <vagrantc> cat .bzr/branch/format
[19:10] <vagrantc> Bazaar Branch Format 6 (bzr 0.15)
[19:11] <dato> right, dirstate-tags
[19:12] <vagrantc> it's a little hard to keep up with all the branch formats
[21:26] <Odd_Bloke> Wow, I'm just updating bzr.dev with packs and knits, and the difference is astounding.
[21:26] <Odd_Bloke> Until now I'd never really seen them side-by-side.
[22:14] <hendrixski_> GGGGRRRRRRRRRRRrr
[22:14] <hendrixski_> ok, this really sucks.  I've been trying to get a branch from an svn repo
[22:15] <hendrixski_> I've pulled off of there before
[22:17] <hendrixski_> svn.asdf.org/svn/branches/release-##/directory   and the error message is "not a branch: trunk/asdf"  EVEN THOUGH NOWHERE in there am I trying to get anything from trunk, I'm trying to pull from tags
[22:17] <hendrixski_> what the hell is going on?  Where is it getting the "trunk" b.s. from????
[22:18] <lifeless> hendrixski_: have you changed bzr versions on the way?
[22:18] <lifeless> hendrixski_: was the branch copied from trunk?
[22:19] <lifeless> Odd_Bloke: we do try to improve things :)
[22:20] <hendrixski_> lifeless,  nope... it's still version .90
[22:21] <hendrixski_> and I cleaned out ~/.bazaar/subversion.conf, so it shouldn't be looking for trunk anywhere in there
[22:21] <hendrixski_> this is infuriating
[22:22] <Odd_Bloke> hendrixski_: Nothing funky rewrite-wise happening on the server?
[22:22] <radix> hendrixski_: This is just speculation, but maybe it needs to read trunk if the branch has ancestry there. Not that I know anything about bzr-svn.
[22:22] <hendrixski_> Sooo. the tags on svn used to at one point have been called trunk/ and that's screwing up bzr-svn from reading it????
[22:23] <Odd_Bloke> jelmer might save us.
[22:23] <Odd_Bloke> (SUBTLE PING)
[22:23] <poolie> spiv, did you fix, or have a fix in progress, for bug 82634?
[22:23] <ubotu> Launchpad bug 82634 in bzr "smart server gives traceback on connection errors" [High,Confirmed] https://launchpad.net/bugs/82634
[22:23] <poolie> otherwise i might tackle it today
[22:26] <jelmer> Odd_Bloke: hi
[22:26] <jelmer> hendrixski_: tags was at one point named trunk?
[22:26] <fullermd> Man, what a great technique.  You sacrifice a goat on the proper altar, and jelmer appears.
[22:27] <jelmer> fullermd: I know sir, I should spend less time on IRC... :-P
[22:27] <hendrixski_> jelmer, I have no idea.  I'm asking if I understood the problem correctly.  That before it became tags, it was at one point trunk.  Is that where this "trunk" thing is coming from?
[22:28] <jelmer> hendrixski_: Yes, I think so.
[22:28] <jelmer> hendrixski_: is this repository public?
[22:29] <hendrixski_> jelmer, yeah.... lemme copy and paste that link
[22:29] <hendrixski_> http://svn.mythtv.org/svn/branches/release-0-20-fixes/mythtv/
[22:31] <hendrixski_> somebody else did something cool with that a while back, so I want to find the release that happened closest to the date they pulled from svn, then copy over their changes, then update to the latest... and then make a .deb package... but I can't even get started for some reason
[22:35] <jelmer> hendrixski_: At least I can confirm it doesn't work
[22:35]  * hendrixski_ slams head on keyboard
[22:35] <hendrixski_> jelmer, thanks :-)
[22:35] <jelmer> hendrixski_: any chance you can file a bug about this?
[22:36] <hendrixski_> now at least I know to try a different strategy
[22:36] <jelmer> I don't have time to fix this bug at the moment, but I may have time later this week
[22:36] <hendrixski_> jelmer, I have the time to file one, yes
[22:36] <jelmer> thanks, that would be much appreciated
[22:36] <hendrixski_> !bugs
[22:36] <ubotu> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.launchpad.net/ubuntu  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/ubuntu-bots
[22:37] <jelmer> https://bugs.launchpad.net/bzr-svn/+filebug is the link you want
[22:37] <hendrixski_> lol, I was about to say, this doesn't look like an ubuntu bug :-p
[22:40] <hendrixski_> jelmer, is it like this one that you're already assigned on? https://bugs.launchpad.net/bzr-svn/+bug/67010
[22:40] <ubotu> Launchpad bug 67010 in bzr-svn "Branch copies from non-branches don't work" [Medium,Fix released]
[22:41] <hendrixski_> or would it be best to file a new one, and submit a log message or two?
[22:41] <jelmer> hendrixski_: no, bug 67010 is a different issue
[22:42] <jelmer> hendrixski_: please file a new one, and mention the URL
[22:42] <hendrixski_> will do :-)
[22:49] <hendrixski_> jelmer, https://bugs.launchpad.net/bzr-svn/+bug/183361   :-)  is there any other info that would help?
[22:49] <ubotu> Launchpad bug 183361 in bzr-svn "bzr-svn on a branches not working" [Undecided,New]
[22:50] <jelmer> thanks!
[22:50] <jelmer> looks complete
[22:50] <hendrixski_> cool
[22:50] <hendrixski_> well, now I have to reformat my strategy of how I'm going to do this... well, vendor drop essentially
[22:51] <hendrixski_> jelmer, good luck
[22:51] <jelmer> thanks
[22:57] <igc> morning
[22:57] <foom> hendrixski_: perhaps branching from http://svn.mythtv.org/svn/branches/release-0-20-fixes/ instead would work?
[22:57] <spiv> poolie: no, I don't think I have started on 82634
[22:58] <poolie> thx
[22:59] <spiv> poolie: I thought I remembered abentley had a patch for it that got rejected, but I can't find it now.  It might have been a good starting point.
[23:01] <foom> hey um, i'm looking at the bazaar-vcs.org site and I can't find any links to what changed in 1.1
[23:04] <poolie> http://doc.bazaar-vcs.org/bzr.1.1/en/release-notes/NEWS.html#bzr-1-1-2008-01-15
[23:04] <hendrixski_> foom, lemme try that
[23:05] <hendrixski_> foom, that's ridiculous... that seems to be branching
[23:06] <hendrixski_> and  that's a TON of extra files
[23:06] <hendrixski_> way, more of the project than I need
[23:08] <foom> hendrixski_: in that case, you can probably do bzr svn-branching-scheme --set http://svn.mythtv.org/svn and then in the editor, put two lines: "trunk/*" and "branches/*/*"
[23:08] <foom> then use your original command
[23:08]  * hendrixski_ tilts head
[23:09] <poolie> spiv, re that patch
[23:09] <poolie> is it necessary to use bzr+http at all?
[23:10] <spiv> poolie: I don't quite understand the question.  You mean instead of http?
[23:10] <Peng> bzr+http is great for a dirstate branch.
[23:10] <Peng> s/dirstate/knit/
[23:11] <Peng> Not so great for a pack branch.
[23:11] <Peng> s/branch/repo/g
[23:12] <spiv> poolie: Hmm,
[23:13] <spiv> poolie: there are a few significant speed improvements to the smart server in bzr.dev that aren't in 1.1
[23:13] <poolie> i'm asking: in what way is 1.1 broken without this fix?
[23:14] <hendrixski_> foom, son of a gun.  That seems to have done it
[23:15] <spiv> bzr+http:// URLs don't work (except in very unlikely circumstances, where the URL paths correspond directly to filesystem paths IIRC).
[23:15] <hendrixski_> I'm gonna go read about this branching scheme stuff... see what I missed,  but something about having to set up all that stuff doesn't seem right.
[23:15] <poolie> foom, i added a link to the changelog from the download page
[23:15] <poolie> do you think it should be anywhere else?
[23:16] <foom> poolie: I'd like to see a (much shorter) list of what changed on the main page with the release announcement.
[23:16] <spiv> poolie: so one thought that just occurred to me is that without the speed improvements in bzr.dev, perhaps there's not much practical benefit to bzr+http over http (assuming the webserver supports Range requests).
[23:17] <spiv> poolie: e.g. Peng last night reported that with a bzr.dev client and 1.1 on a bzr+http server that branching a knit branch was a bit slower (~10% IIRC) than plain http.
[23:18] <spiv> poolie: (with bzr.dev both ends, bzr+http was much faster)
[23:19] <spiv> poolie: (and for packs, plain http always won, but bzr.dev on the server was still a large improvement over 1.1)
[23:20] <jam> igc: ping, do you want to give me a call so we can make sure ssh is working?
[23:20] <igc> shall do in a few minutes if that's ok - family on phone currently
[23:23] <poolie> spiv, ok, so iiuc, this patch enables a feature that is not itself very useful yet?
[23:23] <poolie> therefor making a new release with this patch would not be a priority?
[23:25] <igc> poolie: I think x.y.1 releases ought to be kept for critical bug fixes
[23:25] <spiv> poolie: yeah, I think so
[23:25] <igc> if the feature wasn't working previously, I don't think a 1.1.1 should be released to enable it
[23:26] <igc> with a 4 week cycle, 1.2rc isn't far away
[23:26] <igc> if someone needs the fix before then, they can run on bzr.dev right
[23:26] <igc> ?
[23:27] <spiv> Right.
[23:28] <jam> igc: I sent you the details in an email. Try them out first, and then call me if you need to
[23:28] <jam> I'm going to be AFK
[23:28] <igc> jam:ok
[23:31] <lifeless> spiv: packs FTW huh ? :)
[23:35] <spiv> lifeless: yep!
[23:37] <poolie> igc, i agree, i was just trying to determine if this was
[23:52] <lifeless> spiv: just wait till I get time to do the next index design
[23:57] <spiv> lifeless: hmm, I seem to be getting worse performance with get_parent_map on an initial branch of bzr.dev, compared to using bzr.dev + recommended_page_size fix for RemoteTransport.
[23:58] <lifeless> spiv: bet you the remote end is 1.0 or so and the chunked stream is falling back to manual get_data_stream
[23:59] <spiv> lifeless: -Dtimes -Dhpss says 187s to get up to Repository.stream_revisions_chunked, vs. 72s.
[23:59] <spiv> lifeless: no, remote is bzr.dev
[23:59] <lifeless> ok


[03:49] <Ahmuck-Sr> something odd's going on with the server.  photos that are copied to the folder are not all there
[03:49] <Ahmuck-Sr> i've got a raided drive, and every now and then it says drive numbering has changed.  could this be the cause, it's not mirroring correctly ?
[03:55] <sbalneav> yeah, sounds like data corruption.
[03:55] <sbalneav> You've got backups, yes?
[03:59] <sbalneav> If not:
[04:00] <sbalneav> 1) stop writing right now.
[04:00] <sbalneav> 2) take a backup
[04:00] <sbalneav> 3) take another backup
[04:00] <sbalneav> 4) fix raid array
[04:05] <sbalneav> New builds for Sabayon being published in my ppa
[04:07] <mhall119> sbalneav: is Sabayon for Gnome only?
[04:20] <sbalneav> mhall119: yep
[04:20] <mhall119> anything like it for XFCE?
[04:21] <mhall119> I assume Sabayon just works on gconf?
[04:23] <sbalneav> Does gconf magic, allows you to place default files in home directory, some mozilla and openoffice defaults too.
[04:54] <sbalneav> Evening ace
[14:41] <alkisg> !seen LaserJock
[14:42] <sbalneav> Morning all
[14:42] <sbalneav> alkisg: That cool command is only in #ltsp
[14:43] <alkisg> Good afternoon. Bah, the bot here sucks :-/
[14:44] <sbalneav> not in the ghetto ubuntu channels where they can't run a decent bot :)
[14:46] <alkisg> To be fair, this one also has some nice things, like...
[14:46] <alkisg> !info sabayon
[16:27] <Ahmuck-Sr> has anybody here seen the progress  made on the sabayon editor, lockdown, and deskto editor ?
[16:42] <sbalneav> per your question, no.
[16:42] <sbalneav> At least, not entirely
[16:43] <Ahmuck-Sr> sabayon working now is a great achievement imho.  kudos to you
[16:43] <sbalneav> Firefox and OpenOffice.org are part of the the "new breed" of applications that don't simply read their config files, but need to write to them too.
[16:43] <sbalneav> What you would be able to do with firefox would be to provide a "user.js" file for some defaults/
[16:44] <sbalneav> Anything in your .xsession-errors about sabayon-apply?
[16:44] <Ahmuck-Sr> i know that some peeps, lns, alkisg (?) had been working on something similar.  sabayon works great for what it's doing but i'm wondering about the expandability of it
[16:44]  * Ahmuck-Sr grumbles about applications changing the way things worked
[16:44] <sbalneav> AFAIK, they're reviving TCM which controls terminalsm not profiles.
[16:45] <sbalneav> but where's their website?
[16:45]  * alkisg has no part in tcm-ng
[16:45] <Ahmuck-Sr> anywho, the whole menu is wonderful
[16:45] <Ahmuck-Sr> the lockdown is wonderful
[16:46] <Ahmuck-Sr> i'm wondering how far now sabayon can be taken.  i understand it is a complicated beast
[16:46]  * alkisg would like to develop a user-manager coupled with locked down capabilities some day...
[16:46] <sbalneav> Yes it is.
[16:48] <Ahmuck-Sr> i guess i'm looking down the road, and wondering if a push shouldn't be started to get a flexible type of user/group/class, etc manager with plugin in options for apps
[16:48] <Ahmuck-Sr> for example, i'd like to be able to lock scribus options to start, ie page size, margins, auto text frames, etc.  (dont' even know if this is possible)
[16:49] <alkisg> Ahmuck-Sr: sure, that's what I'm thinking about, but what do you mean "push"? Push who?
[16:49] <sbalneav> It can be taken as far as people have time, and effort, to move it.  I'm basically committed to becoming an upstream contributor for sabayon
[16:50] <sbalneav> Ahmuck-Sr: Unless you'd like to write something new from scratch, I think sabayon's it.  :)
[16:50] <Ahmuck-Sr> alkisg: in general, a push in that direction
[16:50]  * alkisg thinks developers are needed, not pushing :)
[16:50] <Ahmuck-Sr> i think sabayon is wonderful, and i'll be using it to death, but i'm wondering how complicated it is to modify
[16:50] <sbalneav> Hugely
[16:51] <Ahmuck-Sr> alkisg: i think you misunderstand "push" in the context i'm using it in
[16:51] <Ahmuck-Sr> push == define direction
[16:51] <sbalneav> Sigh.
[16:51] <alkisg> Yeah I get what you mean..
[16:51] <alkisg> There's a lot of "defining directions" in edubuntu, and only a little "implementing" - like sbalneav does
[16:51] <sbalneav> I've been over this about 1*10^999999999 times
[16:51] <mhall119|work> I bet that's exageration
[16:51] <sbalneav> People can "push" all they want.
[16:52] <sbalneav> Butt. In. Chairs. Writing. Code.
[16:52] <sbalneav> THAT gets things done.
[16:52] <mhall119|work> Ahmuck-Sr: why don't you start a Launchpad project and start making blueprints
[16:52] <Ahmuck-Sr> lot's of us have no coding ablities at all
[16:52] <sbalneav> My butts in my chair working on Sabayon.  Lets concentrate on THAT for the moment.  Like I say, anything in your .xsession-errors?
[16:53]  * mhall119|work 's butt is coding for employment at the moment
[16:53] <Ahmuck-Sr> but we understand teachers, administrators and their needs, and what it's going to take to get it into the school systems
[16:53] <sbalneav> Ahmuck-Sr: And lots of us who do don't want to have to start projects from scratch again, but would rather fix things that are already there.
[16:54] <sbalneav> Can you see anything in your .xsession-errors file regarding an error from sabayon-apply?
[16:59] <sbalneav> Ahmuck-Sr?
[17:04] <Ahmuck-Sr> brb
[17:10] <Ahmuck-Sr> http://pastebin.be/20404
[17:11] <Ahmuck-Sr> does sabayon save settings, ie, proxy settings in firefox?
[17:13] <Ahmuck-Sr> one of the things were going to encounter is needing a proxy for all kids under 18, but customized bookmarks for children between age groups, ie, 0-5, 6-8, 9-12, 13-16, 17-18
[17:14] <sbalneav> Ahmuck-Sr: AFAIK, proxy's are not saved by sabayon, but, as I indicated before, you COULD use sabayon (i think) to distribute a custom user.js file.
[17:15] <sbalneav> Or, even better, and much more fool proof: just set up transparent proxying.
[17:23] <Ahmuck-Sr> we've got a box with ipcop and transparent proxy.  our isp offers two different types of proxy, one for adults, and one for kids
[17:24]  * Ahmuck-Sr thinks that a custom user.js file might be best
[17:24] <Ahmuck-Sr> mhall119|work: blueprints for classroom managment?
[17:25] <Ahmuck-Sr> http://www.pbs.org/kcet/wiredscience/video/231-touchtable.html
[17:31] <Ahmuck-Sr> 59,000, however this table is possible for about 300.00
[17:41] <mhall119|work> Ahmuck-Sr: blueprints for whatever management tool you want
[18:14] <Ahmuck-Sr> sbalneav: did you get my pastebin?
[18:58] <sbalneav> Ahmuck-Sr: Yes.  Doesn't appear that the profile for "user" was found.
[18:59] <Ahmuck-Sr> not sure what that means
[18:59] <sbalneav> What's the contents of /etc/desktop-profiles/users.xml, and what zip files do you ahve in that directory?
[18:59] <sbalneav> Well, you're logging in as "user" right?
[19:18] <Ahmuck-Sr> no, as myself.  i did a search and replace and replaced me with user
[19:19] <sbalneav> ok, so what does the contents of your user.xml look like?
[19:31] <Ahmuck-Sr> http://pastebin.be/20406
[19:33] <Ahmuck-Sr> often we get parents in that have trouble getting their kids to quit.  i'm thinking i can terminate their session with iTalc
[19:33] <sbalneav> ok, so you said you were logging as yourself, which you've mapped to "user" in your pastebin.  In the users.xml, you've got users "class1, class2, and class3" mapped to the profile.  So unless you also add YOURSELF as using the profile, you won't get it.
[19:34] <Ahmuck-Sr> i logged in as class1
[19:34] <Ahmuck-Sr> so i need to add myself so class1 can see the profile?
[19:34] <sbalneav> ok, I'm confused.
[19:34]  * Ahmuck-Sr knows
[19:35] <sbalneav> When you pasted the .xsession-errors, you pasted as yourself, correct?
[19:35] <Ahmuck-Sr> created profile "Children"
[19:35] <Ahmuck-Sr> then added users class1 - 3
[19:35] <Ahmuck-Sr> then booted thin client, and logged in as class1
[19:35] <Ahmuck-Sr> profile is default, not modified with sabayon
[19:35] <Ahmuck-Sr> ah, yes
[19:35] <Ahmuck-Sr> pasted as myself.  so ur wanting the thin client .xsession-errors
[19:36] <sbalneav> ok, and could you then paste class1's .xsession-errors so I can see if there's any errors from sabayon-apply?
[19:39] <Ahmuck-Sr> http://pastebin.be/20407
[19:40] <sbalneav> Ah, that's better.
[19:40] <sbalneav> #
[19:40] <sbalneav> MainThread 2009/08/19 12:16:02.4299 (sabayon-apply): Applying profile '/etc/desktop-profiles/Children.zip' for user 'class1'
[19:40] <sbalneav> #
[19:40] <sbalneav> MainThread 2009/08/19 12:16:02.7594 (sabayon-apply): Fatal exception!  Exiting abnormally.
[19:41] <sbalneav> #
[19:41] <sbalneav> MainThread 2009/08/19 12:16:02.7606 (sabayon-apply): Traceback (most recent call last):
[19:41] <sbalneav> #
[19:41] <sbalneav>   File "/usr/sbin/sabayon-apply", line 111, in <module>
[19:41] <sbalneav> #
[19:41] <sbalneav>     profile.apply (is_sabayon_session)
[19:41] <sbalneav> #
[19:41] <sbalneav>   File "/var/lib/python-support/python2.6/sabayon/userprofile.py", line 392, in apply
[19:41] <sbalneav> #
[19:41] <sbalneav>     delegate.apply (is_sabayon_session)
[19:41] <sbalneav> #
[19:41] <sbalneav>   File "/var/lib/python-support/python2.6/sabayon/sources/mozillasource.py", line 454, in apply
[19:41] <sbalneav> #
[19:41] <sbalneav>     target_pref.read()
[19:41] <sbalneav> #
[19:41] <sbalneav>   File "/var/lib/python-support/python2.6/sabayon/sources/mozillasource.py", line 664, in read
[19:41] <sbalneav> #
[19:41] <Ahmuck-Sr> ?
[19:41] <sbalneav>     self.parse()
[19:41] <sbalneav> #
[19:41] <sbalneav>   File "/var/lib/python-support/python2.6/sabayon/sources/mozillasource.py", line 718, in parse
[19:41] <sbalneav> #
[19:41] <sbalneav>     (match.start(), match.end(), key, value))
[19:41] <sbalneav> #
[19:42] <sbalneav>   File "/var/lib/python-support/python2.6/sabayon/sources/mozillasource.py", line 76, in dprint
[19:42] <sbalneav> #
[19:42] <sbalneav>     debuglog.debug_log (False, debuglog.DEBUG_LOG_DOMAIN_MOZILLA_SOURCE, fmt % args)
[19:42] <sbalneav> #
[19:42] <sbalneav> TypeError: not enough arguments for format string
[19:42] <sbalneav> So, looks like there's a munched dprint somewhere
[19:42] <sbalneav> mozillasource.py line 76
[19:42] <sbalneav> checking
[19:44] <Ahmuck-Sr> ALSA lib pcm_hw.c:1429:(_snd_pcm_hw_open) Invalid value for card
[19:44] <Ahmuck-Sr> ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: Connection refused
[19:44]  * Ahmuck-Sr thinks that's my sound issue
[19:44] <Ahmuck-Sr> well, i'll be here, but need to step away for a bit and get some pressing issues elsewhere corrected
[19:50] <sbalneav> Ahmuck-Sr: ok, found the bug.
[19:50] <sbalneav> I'll fix it, and push a new version
[19:50] <Ahmuck-Sr> u r so kewl
[21:07] <alkisg> Yey! After struggling for some hours, I finally got gnome-app-install to recognize my edu-app CD as an add-on :) http://users.sch.gr/alkisg/temp/gnome-app-install.png
[21:09]  * alkisg wishes there was documentation on how to build such an add-on CD :-/
[21:09] <sbalneav> Ahmuck-Sr: Ping
[21:10] <Ahmuck-Sr> pong
[21:10] <sbalneav> Hey, should be a 0ubuntu3 package for sabayon
[21:10] <Ahmuck-Sr> what is your app?
[21:11] <sbalneav> if you've got a minute, give it a go, see if it works.  Hopefully sabayon-apply should succeed now.
[21:11] <sbalneav> My PPA?
[21:11] <sbalneav> Have you added it to your sources.list yet?
[21:12] <sbalneav> If you do that, then you'll just get the updates as I make 'em
[21:25] <Ahmuck-Sr> sbalneav: see custard ?
[21:25] <Ahmuck-Sr> sbalneav: working on it
[21:27] <sbalneav> Ahmuck-Sr: See my response?
[21:27] <sbalneav> Not even worth worrying about until we see source.
[21:28] <Ahmuck-Sr> source posted
[21:29] <sbalneav> Ah, ok, he's just done it.
[21:29] <sbalneav> At this point, I've got 3 months worth of work invested in Sabayon.
[21:29] <sbalneav> If I stop working on it now, to try to learn a new codebase, we won't have anything for karmic.
[21:30] <Ahmuck-Sr> i wouldn't advise ditching sabayon yet
[21:30] <sbalneav> So at this point, I'm just going to continue on with getting Sabayon going.
[21:30] <sbalneav> After karmic's out the door, then we can evaluate what'll be better.
[21:33] <Ahmuck-Sr> well, i wasn't saying one was better than the other, and i'm using sabayon right now
[21:33] <Ahmuck-Sr> no go
[21:35] <Ahmuck-Sr> sbalneav: no change on client
[21:36] <sbalneav> Clean out class1's .xsession-errors with a :> .xsession-error, log out and in again as class1, and pastebot the .xsession-error
[21:36] <sbalneav> prolly another crasher in there.
[21:36] <sbalneav> I'm at work, and we're running hardy here, so I can't test it myself until later.
[21:45] <sbalneav> hey dgroos
[21:46] <sbalneav> You available tonight?
[21:46] <dgroos> howdy sbalneav!
[21:46] <dgroos> Well... it's my wife's birthday :)
[21:46] <sbalneav> Ah
[21:46] <dgroos> What you working on?
[21:46] <dgroos> Just kidding
[21:47] <sbalneav> Well, as someone who's been married 18 years, I can sympathise that that would be more important :)
[21:47] <Ahmuck-Sr> wife's birthday == !available
[21:47] <dgroos> Sabayon :)
[21:47] <sbalneav> Old joke:
[21:47] <sbalneav> Two Vikings are sitting in a pub
[21:47] <Ahmuck-Sr> http://pastebin.be/20409
[21:47] <dgroos> Ah good, a Viking Joke for a Minnesotan!
[21:48] <sbalneav> One says to the other: "I want to perform a deed that will be remembered and talked about for the rest of my days!!"
[21:48] <sbalneav> Other viking says: "That's easy: just forget your wife's birthday"
[21:48] <sbalneav> :)
[21:48] <dgroos> :)
[21:49] <sbalneav> Ahmuck-Sr: LOL
[21:49] <dgroos> Yes, in our 21 years married I've made more than 1 memorable act :)
[21:49] <sbalneav> Fixed ONE bug in that line, now there's another one.
[21:49] <dgroos> How's Sabayon going?
[21:49] <sbalneav> OK
[21:49] <sbalneav> Well, we're definitely making progress
[21:49] <dgroos> YES!
[21:49] <sbalneav> Ahmuck-Sr: OK, how you feel about a little direct editing? :)
[21:49] <sbalneav> lets go to:
[21:50] <dgroos> It has been exciting.
[21:50] <sbalneav> /var/lib/python-support/python2.6/sabayon/sources
[21:50] <sbalneav> and open up mozillasource.py
[21:50] <sbalneav> right, and now joshiggins (hi josh, I see you there) has another new toy to play with
[21:51] <joshiggins> Hello
[21:51] <dgroos> Yes, hi Josh
[21:51] <Ahmuck-Sr> been there
[21:51] <Ahmuck-Sr> er there already
[21:51] <sbalneav> hokiedoke
[21:52] <dgroos> and Ahmuck-Sr.
[21:52] <sbalneav> lets go down to line 717
[21:52] <sbalneav> and just comment out the two lines that compose the dprint
[21:53] <sbalneav> joshiggins: I'd love to look at custard, but I'm far enough into sabayon that at this point, it makes more sense to   continue that on for the moment.
[21:53] <joshiggins> No problem
[21:54] <Ahmuck-Sr> joshiggins: i've tested it, and it crashes
[21:54] <joshiggins> ah
[21:54] <joshiggins> A good sign
[21:54] <joshiggins> Any message?
[21:55] <Ahmuck-Sr> sbalneav: # iirc ?  for commenting out
[21:55] <Ahmuck-Sr> joshiggins: not sure yet.  when it didn't worked i purged it
[21:55] <Ahmuck-Sr> joshiggins: will it work on a system that has sabayon on as well?
[21:56] <sbalneav> # is correct
[21:56] <Ahmuck-Sr> or is there a conflict
[21:56] <Ahmuck-Sr> sbalneav: and now save ?
[21:56] <sbalneav> Yessir
[21:56] <joshiggins> Ahmuck-Sr: Shouldn't conflict...
[21:56] <sbalneav> joshiggins: Did you just write this?
[21:56] <sbalneav> Or has this been in development for a bit?
[21:57] <joshiggins> sbalneav: I wrote some scripts a while back but packaged it up recently with a GUI in Gambas
[21:58] <sbalneav> You committed to the idea of gambas?  Or if we were to look at getting a python/glade interface going, would that be ok with you?
[21:58] <sbalneav> Reason why is: gambas isn't in main
[21:59] <joshiggins> sbalneav: Sounds like a better idea
[21:59] <sbalneav> So if we switch at some point to custard, it means pulling in/having to promote a bunch more packages.
[21:59] <sbalneav> ok
[21:59] <joshiggins> Yeah I see what you mean
[22:00] <sbalneav> Ahmuck-Sr: Any improvement?
[22:01] <sbalneav> I'm definitely interested.  I'll have a look at it tonight, for sure.
[22:01] <sbalneav> I think I saw someone ask.  GPL?
[22:01] <joshiggins> Yes its all GPL
[22:01] <sbalneav> And the really *big* question: you in this for the long haul? :)
[22:01] <joshiggins> Definately
[22:02] <sbalneav> Well, that's a + in custard's favour then :)
[22:02] <joshiggins> :)
[22:02] <sbalneav> Here's what I'd suggest we do:::::
[22:02] <sbalneav> why are my keys reeeepeating sometimes?
[22:02] <sbalneav> bleh
[22:03] <sbalneav> Lets get sabayon working to the point where we have SOMETHING for karmic.  Getting a brand-new-never-seen-before package in the door at this point's going to be next to impossible.
[22:04] <Ahmuck-Sr> no change
[22:04] <sbalneav> Still dying on that line in xsessiooooon-erros?
[22:04] <sbalneav> ahhhhhh
[22:04] <sbalneav> gh
[22:06] <sbalneav> Ahmuck-Sr: Email me your .zip profile in /etc/destop-profiles, so I can play with it tonight.
[22:06] <Ahmuck-Sr> no change
[22:06] <Ahmuck-Sr> pm ur e-mail
[22:06] <sbalneav><EMAIL_ADDRESS>[22:06] <sbalneav> it's pretty public :)
[22:07] <Ahmuck-Sr> joshiggins: what i saw about using the .config files is what interested me
[22:07] <sbalneav> joshiggins: then, post karmic, lets re-do the interface python/glade, and we'll want to switch to Xephyr from Xnest.  Xnest's "dead upstream", and Xephyr handles more of the X extentions than Xnest does.
[22:08] <sbalneav> If custard's going to fit the bill, lets push to get it ready to rock-and-roll for the LTS release.
[22:08] <joshiggins> Sounds like a plan
[22:08] <Ahmuck-Sr> sbalneav: i've a question, does sabayon deal with kde apps?  and other adds?
[22:08] <sbalneav> no, sabayon's Gnome only
[22:09] <dgroos> sbalneav: I've got commitments through much of tomorrow but can put in an hour or two starting at 5:30 or 6:30 tomorrow morning.  Also, can do an hour or two tomorrow night.  I think you are in the same time zone as I? (4:08 PM here).
[22:09] <sbalneav> Yep
[22:09] <sbalneav> I'm in Winnipeg Manitoba Canada
[22:09] <sbalneav> Tomorrow night would be fine.
[22:10] <dgroos> Yes, I've seen your sig--I'm in Minneapolis, Minnesota, USA
[22:10] <Ahmuck-Sr> sbalneav: u going to the conference in september?
[22:10] <dgroos> Good, I'll get on line...
[22:10] <sbalneav> Ahmuck-Sr: Which, Ubuntu?
[22:10] <dgroos> hmmm... let me show my ignorance--which conference?
[22:10] <Ahmuck-Sr> joshiggins: would custard allow me to do kde and gnome ?
[22:10] <sbalneav> Nah, rocket man doesn't like me anymore :)
[22:11] <joshiggins> Ahmuck-Sr: yes, as long as everything is put in .dot files in the user's home dir
[22:12] <alkisg> joshiggins: how do you deal with paths? E.g. if a configuration file contains /home/username1, does that change to /home/username2 when it's applied to user2?
[22:12] <alkisg> (e.g. wallpaper=/home/username1/firefox_wallpaper.png ==> wallpaper=/home/username2/firefox_wallpaper.png)
[22:13] <joshiggins> alkisg: put simply, not yet
[22:13] <alkisg> k..
[22:13] <joshiggins> i'd imagine that paths such as that should use $home in place of username1,2 etc
[22:13] <Ahmuck-Sr> i saw it psoted in ltsp yesterday
[22:13] <sbalneav> Okay peoples, I'm heading off home for dinner.  Be on in the evening.
[22:13] <sbalneav> Ahmuck-Sr: I'll look at your profile, see if I can duplicate your error.
[22:14] <Ahmuck-Sr> alkisg: weren't u or lns working on something?
[22:14] <sbalneav> Keep watching (the skies|my PPA)
[22:14] <sbalneav> cheers
[22:14] <alkisg> joshiggins: that would be ideal, but unfortunately when a user sets the wallpaper, $HOME isn't used...
[22:14] <Ahmuck-Sr> i'm stepping out for a bit myself
[22:14] <alkisg> ciao sbalneav
[22:14] <dgroos> sbalneav--conference?
[22:14] <joshiggins> alkisg: ah, okay....
[22:15] <alkisg> Ahmuck-Sr: no, Lns is working on tcm-ng, and I'm thinking of starting a task-based profile editor, but it's months or years away...
[22:15] <Ahmuck-Sr> task based ?
[22:15]  * Ahmuck-Sr looks up tcm-ng
[22:15] <alkisg> Yeah, to avoid problems with paths etc
[22:15] <alkisg> E.g. a specific plugin to change the gnome-wallpaper, another one for kde wallpaper,
[22:16] <alkisg> another one to clear the firefox cache etc
[22:17] <Ahmuck-Sr> isn't a desktop just a desktop in ubuntu
[22:17] <Ahmuck-Sr> kinda "unified" or "ubuntu-fied"
[22:17] <alkisg> ubuntu != kubuntu
[22:17] <alkisg> (gnome != kde)
[22:19] <joshiggins> alksig: if these paths are stored in text files( e.g. dump of gconf tree) surely a script could run through and replace occurences of username1 with username2
[22:19] <alkisg> joshiggins: the problem is that search and replace won't know the context, where to actually do the replacing
[22:20] <alkisg> So if a user is named "a" and the second user "b", there's going to be a problem... :)
[22:20] <alkisg> banana => bbnbnb :D
[22:21] <joshiggins> alksig: Ah yes, we're assuming each username is going to be unique
[22:21] <joshiggins> which wouldn't work
[22:22] <dgroos> alksig--not following all you are saying, can you manage privledges by groups, such as a 'level1' group, level2 group etc, then just move students in and out of groups?  or, is that kind of the way the Sabayon works?
[22:23] <alkisg> dgroos: applying the profiles is a totally different problem
[22:23] <dgroos> That way one could just manage users with a program such as 'users and groups'.
[22:23] <dgroos> I'm thinking about how Apple does it with their Workgroup Manager.
[22:24] <dgroos> They may have changed it since I used it regularly 3 years ago.
[22:24] <alkisg> dgroos: yeah, that's what I was thinking, e.g. see here a mocup i've made: http://users.sch.gr/alkisg/temp/users-manager.png
[22:26] <dgroos> second to last column PID, last GID?
[22:26] <alkisg> Yeah but columns should be configurable, so not really important
[22:26] <dgroos> sure
[22:26] <alkisg> Users should be able to be read from passwd or ldap etc...
[22:27] <Ahmuck-Sr> manage groups, users, machines
[22:27] <Ahmuck-Sr> and appliations
[22:27] <dgroos> 'read from' = 'authenticate'???
[22:28] <joshiggins> this seems like its rolling 3 utilities into 1
[22:28] <joshiggins> explaination:
[22:28] <alkisg> I meant that the program should be able to retrieve the user list from either /etc/passwd, or ldap, or other sources
[22:28] <Ahmuck-Sr> i had an outline once, but i'm a bit sleepy and tired currently
[22:28] <dgroos> Teachers like parallel structure--less to learn...
[22:29] <Ahmuck-Sr> server boots, identifies machines & hardware
[22:29] <alkisg> joshiggins: yes, I think that profile management is better if integrated with users/groups management
[22:29]  * alkisg is a teacher
[22:29] <Ahmuck-Sr> user manager or group manager allows lock of certian devices
[22:29] <Ahmuck-Sr> applications, etc.
[22:29] <Ahmuck-Sr> we hit the problem of managing groups and on occasion an errant user
[22:30] <Ahmuck-Sr> so user needs to belong to multiple groups
[22:30] <dgroos> alkisg: cool--what/where do you teach?
[22:30] <alkisg> dgroos: Greece, Ioannina
[22:30] <joshiggins> alkisg: I'd agree with that
[22:31] <alkisg> joshiggins: the problem is that users-admin is C-based, and won't easily support plugins, and isn't easily extensible
[22:31] <alkisg> So a new users manager should be written first, and the profile-editing plugins would come later...
[22:32] <alkisg> Fedora has such a manager, but it's too distro specific :-/
[22:33] <dgroos> alkisg: At the University?  Computer science might I guess :)
[22:33] <alkisg> dgroos: no, secondary schools (12-18 y.o.), and yes, I teach computer-related lessons
[22:35] <joshiggins> I'm currently at secondary school in England
[22:35] <dgroos> alkisg: cool.  You have a link to your program and can it localize in English or Spanish?
[22:36] <dgroos> joshiggins: you teaching or studying there?
[22:36] <alkisg> dgroos: it's not a complete program yet; I was just trying out pygtk. It'll take me months to write such a program
[22:36] <Ahmuck-Sr> i understand pardus has an editor as well as suse
[22:36] <Ahmuck-Sr> are they distro specific as well?
[22:36] <joshiggins> studying there, although the ICT faculty is a joke
[22:36] <dgroos> I actually meant info about your school/classes.
[22:37] <joshiggins> Well I'm studying ICT here, 1 year left
[22:38] <dgroos> joshiggins: cool, secondary in England is 15-18 year olds? or ?
[22:39] <joshiggins> yes, I'm 17 :)
[22:40] <dgroos> alkisg: actually, I was asking if you had a link to a page telling about your school (by program I meant your department or curriculum or classes).
[22:40] <alkisg> Ah ok sorry
[22:41] <alkisg> Well I don't have one specific school - in Greece most schools are public, and some teachers go to a different school each year
[22:41] <alkisg> ...and all of them have the same classes
[22:42] <dgroos> joshiggins--you know, one thing so cool about irc (ok I'm a newB) is that it provides a space for us all to meet, and what one thinks and says is what matters :)
[22:43] <dgroos> joshiggins: nice to have you at #edubuntu, hope you stick around.
[22:44] <dgroos> alkisg: teachers move around here as well, though not so much.
[22:44] <joshiggins> dgroos: Nice to meet you, I've been using irc for 43 mins now :)
[22:44] <alkisg> dgroos: here's some stuff about the greek edu system: http://www.ekep.gr/english/education/deuterobathmia.asp
[22:45] <dgroos> Also, every teacher has his/her own curriculum, more or less, but the educational goals--called 'standards' at the moment, are mandated as are testing.
[22:45] <alkisg> dgroos: at some point teachers here go to a specific school until they retire; but in my city there are too many informatics teachers, and I'll need maybe 20 years to be appointed to a specific school :( (I've been a teacher for 10 years so far)
[22:46] <dgroos> alkisg: thanks I'll check it out.
[22:46] <joshiggins> alkisg: Do you use Linux for teaching?
[22:47] <alkisg> Yes, I've been using ubuntu/ltsp in the last 2 years, in 2 different schools
[22:47] <Ahmuck-Sr> we do
[22:47] <dgroos> Your situation is similar to here then, for ICT teachers, that is.  Sorry to hear about that.
[22:48] <dgroos> joshiggins: cool, someone even newer than I! ;)
[22:49] <dgroos> Ahmuck-Sr--ever get your server going again after the power outage in the community space you have developed?
[22:49] <Ahmuck-Sr> yes, i'm on it :)
[22:50] <Ahmuck-Sr> ordered to fast, and ordered the wrong psu, so i was down a week
[22:50] <Ahmuck-Sr> and a half
[22:51] <dgroos> :(
[22:52] <Ahmuck-Sr> *shrugs* ... it works now.  mostly
[22:53] <joshiggins> Ahmuck-Sr: back to sabayon now?
[22:53] <dgroos> and I'm heading home.  Nice chatting.
[22:54] <Ahmuck-Sr> joshiggins: for the time being, yes