[04:52] <mup> Issue operator#317 opened: use charm state for Juju 2.8 <Created by jetpackdanger> <https://github.com/canonical/operator/issues/317>
[08:29] <Chipaca> morning all
[08:33] <jam> morning Chipaca
[11:04] <facubatista> Muy buenos días a todos!
[11:12] <Chipaca> a wild facundo appears!
[11:14]  * facubatista puts some clothes on
[11:25] <Chipaca> better
[11:25] <Chipaca> facubatista: hola :)
[11:25] <facubatista> hola :)
[11:25] <Chipaca> i've just realised i spent all morning messing around with versioning :-(
[11:25] <facubatista> Chipaca, and this is the 3.1.2nd time it happes to you!
[11:26] <facubatista> *happens
[11:26] <Chipaca> well, i did do a bit of reviewing and such before diving down this rabbithole
[11:26] <facubatista> Chipaca, but at least you have a conclusion?
[11:26] <Chipaca> facubatista: I have something I like, I just need to check one more thing
[11:28] <Chipaca> hm, the files github gives us at https://github.com/canonical/operator/releases is already reasonably useless :-/ do we care about them?
[11:29] <facubatista> Chipaca, for `fades`, the person doing the debian packaging takes those
[11:30] <facubatista> Chipaca, anyway, I don't care about them, not even to take the action of removing them or something
[11:30] <Chipaca> heh
[11:31] <facubatista> Chipaca, re MANIFEST.in... "LICENSE": don't we need to package it? why do we have it in the first place? shall we remove it from the project?
[11:32] <Chipaca> facubatista: in the wheel, it's already there
[11:32] <Chipaca> facubatista: in the source dist, we reference it by name, isn't that enough?
[11:33] <Chipaca> i'm asking :)
[11:33] <facubatista> Chipaca, who put it in the wheel?
[11:36] <Chipaca> facubatista: wheel :)
[11:37] <Chipaca> facubatista: FWIW I don't object to it being there
[11:37] <facubatista> Chipaca, even if we don't specify to put it in the tarball?
[11:37] <Chipaca> facubatista: correct
[11:37] <facubatista> wow
[11:37] <Chipaca> facubatista: you can try it yourself :)
[11:37] <facubatista> nah, I trust you
[11:37] <Chipaca> facubatista: 'python setup.py bdist_wheel'
[11:37] <Chipaca> shaaame
[11:37] <Chipaca> oh dang lunch
[11:38]  * Chipaca rushes
[12:13] <Chipaca> so, it *looks* like github doesn't auto-add assets if you add them manually, so that might be a good way out
[12:15] <facubatista> Chipaca, what we do about LICENSE file, then?
[12:16] <Chipaca> facubatista: give me a bit
[12:16] <Chipaca> just digging into that :)
[12:16] <Chipaca> bah. i should probably shelve the version stuff first :-D
[12:16] <facubatista> ack, no rush
[12:21] <Chipaca> facubatista: so one approach is to add a setup.cfg with [metadata] license_file = LICENSE.txt
[12:21] <Chipaca> license_files*
[12:26] <facubatista> Chipaca, jam, now I pushed the files to where they belong, so I won't confuse again my directories: https://github.com/facundobatista/blog/tree/master/charm
[12:30] <Chipaca> i don't have a stick big enough to shake at how much i dislike the under-documentedness of setup.py and .cfg
[13:08] <jam> Chipaca, simple enough :)
[13:10] <Chipaca> grmbl
[13:10] <Chipaca> (tm)
[13:17] <facubatista> Chipaca, see, I created a clean venv, then `pip install -r requirements-dev.txt`, and I get:
[13:17] <facubatista> Installing collected packages: pycodestyle, toml, autopep8, mccabe, zipp, importlib-metadata, pyflakes, flake8, PyYAML, ops
[13:17] <facubatista> I don't like that "ops" at the end
[13:18] <facubatista> oh, mmm
[13:18] <facubatista> $ cat env/lib/python3.6/site-packages/ops.egg-link
[13:18] <facubatista>  /home/facundo/canonical/operator
[13:18] <facubatista> probably not harmful, though
[13:19] <Chipaca> yep, it's done a 'develop'
[14:03]  * Chipaca links to https://xkcd.com/1987/ on the README.md
[14:05] <jam> Chipaca, :)
[14:06] <jam> danger of using 'sudo' to install python packages, indeed
[14:08] <mup> PR operator#318 opened: Simplified the CharmBase init signature <Created by facundobatista> <https://github.com/canonical/operator/pull/318>
[14:09] <facubatista> never ever do "sudo pip"
[14:09] <jam> facubatista, do "curl | sudo bash" right?
[14:10] <facubatista> ja
[14:18] <facubatista> oh, Trello is down :/
[14:57] <Chipaca> facubatista: if trello is down, are you even working
[15:00] <facubatista> Chipaca, I'm not doing anything but pressing F5 every couple of minutes, staring at the empty browser page
[15:01] <Chipaca> facubatista: let's have our 1:1 now then :)
[15:02] <facubatista> je
[15:03] <facubatista> Chipaca, bah, I'm ok for the 1:1 now if you prefer it
[15:06] <Chipaca> facubatista: let's do it
[15:06] <facubatista> ok, 1'
[15:08] <facubatista> Chipaca, omw
[16:43] <Chipaca> soft EOD from me. brain = ded
[16:43] <Chipaca> migt bbl if it reactivates
[17:10] <facubatista> Chipaca, should we distribute ops docs inside its package?
[21:04]  * facundo__ eods
[22:24]  * Chipaca eods


[07:22] <gblazer> Hi there, I have an upstart script for Unicorn. I just upgraded Ubuntu and Upstart, and now it doesn't work because upstart has a new expect stanza that I didn't use. Can anyone help out with `expect fork` or `expect daemon` for Unicorn?


[19:53] <Robdgreat> hi
[19:54] <Robdgreat> D3f0: ping? :)
[20:00] <D3f0> Robdgreat: hola
[20:00] <D3f0> Robdgreat: hi
[20:00] <D3f0> there seems to be quite few ppl in the room
[20:04] <Robdgreat> yeah
[20:04] <Robdgreat> how are you?
[20:05] <Robdgreat> we're sadly fairly inactive. I'd like to see that change, though
[20:05] <Robdgreat> welcome


[00:50] <bazhang> surprise twist! he's using kali
[00:50] <Unit193> Ubuntu based these days, I believe.
[00:50] <tonyyarusso> bazhang: Who, caden__?
[00:50] <bazhang> thought they moved to dabain
[00:51] <Unit193> Backtrack was Ubuntu, then Kali was Debian, now I hear 2.0 is Ubuntu?  Or is this lies?
[00:51] <bazhang> tonyyarusso, yeah, who knows what he's running, the story keeps changing
[00:51] <tonyyarusso> lovely
[00:52] <Unit193> Nope, Debian testing.  So lies.
[00:58] <bazhang> true lies
 this is 4 srs help not 4 chitchat guyz
[01:17] <bazhang> * [isbotnetcool]<EMAIL_ADDRESS>[01:17] <bazhang> noooo waaaaa
[06:50] <Flannel> tonyyarusso: Fine, you want to discuss it.    When you accused him of effectively disagreeing with you, you then accused him of being crazy.  Disagreeing is not crazy.
[06:51] <Flannel> tonyyarusso: So yes, I removed the ban, because it was blatantly a bad ban, regardless of the fact that, if you were being reasonable, you would've incrementally catalyzed, kicked, etc, before banning.
[06:53] <Flannel> tonyyarusso: I'm assuming you're having a bad night, which is fine, it happens to all of us.  But if you want to discuss it further, you know how to get in touch with me.
[06:54] <Flannel> And, as a postscript, the concept of ban ownership is something we've always eschewed.
[06:54] <tonyyarusso> I didn't ban him for disagreeing with me - I banned him turning it into a weird tirade and then into just attacking me generally.
[06:55] <Flannel> tonyyarusso: There was no attack.  All he ever did was say "you're making a big deal out of nothing" and then, after you accused him of craziness, he made some comments about how you're attacking him for disagreeing with you.
[06:56] <Flannel> So sure, that could be an "attack", but as far as I can tell, it was, at its core, factual.
[06:57] <Flannel> Yes, there were embellishments, but you were embellishing yourself.
[06:58] <tonyyarusso> So you agree that I must never go outside and am incapable of thinking?
[06:59] <Flannel> tonyyarusso: No, I agree that you attacked him for disagreeing with you.
[07:00] <Flannel> The "incapable of thinking" is, like I said, on the same level as "triggered the crazy".
[08:17] <Unit193> Guest47262: Hello! Please identify when you get a sec.
[08:18] <Unit193> hggdh: Can you +Vv yofel?
[09:46] <bazhang> whats the record for a link given repeatedly and still no comprehension at all
[09:46] <bazhang> mine is around 8 I think
[09:58] <bazhang> criminy
[09:58] <bazhang> mark that system as completely unstable failure imminent
[17:51] <bazhang> !ebox
[17:52] <bazhang> zentyal is out of support?
[18:11] <ikonia> is it still an active project ?
[18:12] <bazhang> seveas said no
[18:15] <ikonia> didn't think it was


[00:02] <caravel> BlazingSun: I'm researching this since I may have the same issue -- we're really off-topic now, we'll be kicked out soon :)
[00:02] <caravel> BlazingSun: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434
[00:33] <BlazingSun> caravel: yeah i found that too, but i cant find where to change the umask
[00:35] <BlazingSun> caravel: i think bzr+ssh and bzr over sftp are different, not 100%sure thou
[00:35]  * caravel didn't know about the bzr+ssh prefix ^^ and -- finally, understands BlazingSun ^^
[00:36] <caravel> BlazingSun: well, my little brain can't see how else that could work
[00:37] <caravel> have you tried the Subsystem command ? found another one for more recent version of openssh, hold on
[00:38] <caravel> (since 5.4p1) Subsystem sftp /usr/lib/openssh/sftp-server -u 022
[00:40] <caravel> BlazingSun: found this too http://forums.debian.net/viewtopic.php?f=30&t=59365#p344998
[00:40] <caravel> BlazingSun: but really, I think you should ask on #debian :)
[00:41] <BlazingSun> caravel: yeah if i dont find whats wrong i will probably do
[00:41] <caravel> BlazingSun: look at /etc/login.def still, see my last link
[00:43] <caravel> Could anyone confirm everybody, how bzr+ssh works ? Can hardly find any doc about smartserver on official doc, and that's two of us who are interested. Does this not result in using sftp ?
[00:43] <BlazingSun> caravel: changing umask in login.def didnt change anything
[00:44] <BlazingSun> caravel: everything working fine, except creating new branches :(
[00:45] <caravel> BlazingSun: did you try Subsystem and restart sshd ?
[00:45] <BlazingSun> caravel: not yet
[00:45] <BlazingSun> caravel: but sftp isnt ssh, as far as i know it only uses the permissions of ssh
[00:49] <fullermd> sftp is a protocol that runs over ssh.
[00:49] <fullermd> bzr+ssh doesn't use sftp at all, it just talks to bzr.
[00:50] <caravel> thanks fullermd: I couldn't find anything about how the "smart server" mode works, from what I read there are basically two instances of bzr talking to each other, hence "optimizing" transfers by doing as much server side work as possible -- so I take it as similar to rsync, right ?
[00:51] <caravel> is there ANY doc avail any where ? been digging the whole of canonical, yet (I believe !)
[00:51] <fullermd> Well, insofar as you've got bzr talking to bzr, like rsync talking to rsync.  The protocols don't have any resemblance to each other...
[00:51] <fullermd> At the protocol level?  I think there are some (probably outdated) docs in the tree...  it's mostly just in the code.
[00:53] <BlazingSun> fullermd: you have any idea how to get bzr+ssh to work? the write-permission doesnt get set right when creating a new branch. not directly bzr relatet
[00:53] <BlazingSun> *related
[00:53] <caravel> fullermd: sure. so who's writing on disk, is this the bzr executable on the server side, and doing the entire rsync-like file combination ? or is it just telling the bzr client what files to upload over sftp ?
[00:54] <fullermd> No, it's all bzr-bzr.  There's no sftp involved in bzr+ssh.
[00:54] <fullermd> BlazingSun: What's "not right"?
[00:54] <caravel> fullermd: ok thanks
[00:56] <BlazingSun> fullermd: i want to have several users that can access the same branch, but when i create the branch with one, the write-permission for the group does not get set
[00:56] <BlazingSun> fullermd: so the other users cant push
[00:56] <BlazingSun> fullermd: seems umask-related
[00:56] <caravel> fullermd so BlazingSun may face a bzr issue, right ? bzr is the process receiving the user perms from ssh login, and applying them wrongly when writing ?
[00:56] <fullermd> Creating a new branch follows umask.  You'd need to reset it after creating for group write or the like.
[00:57] <fullermd> Well, "wrongly" is a matter of perspective.  It's certainly inconvenient in this case.
[00:58] <BlazingSun> fullermd: i am using debian6 but setting the umask in login.def doesnt change anything
[00:58] <BlazingSun> fullermd: and cant find any other place, that may overwrite the setting there
[00:58] <caravel> BlazingSun: tried it first over simple ssh login ?
[00:59] <BlazingSun> sure
[00:59] <BlazingSun> same problem
[00:59] <BlazingSun> everything working, only the w-flag doesnt get set
[01:00] <fullermd> Got me.  I always just use shell rc files.
[01:04] <caravel> BlazingSun: look at this : Another solution to set the permissions would be to use dnotify. Create /usr/local/sbin/dnotify_handler-reset_perms.sh script with the following
[01:04] <caravel> http://serverfault.com/questions/127658/how-do-i-set-permissions-structure-for-multiple-users-editing-multiple-sites-in/127686#127686
[01:07] <caravel> BlazingSun: fullermd's rc files sound a bit, well, lighter ^^
[01:07] <fullermd> But not without ugliness.  You probably wouldn't want to permanently wire umask that far open.
[01:07] <fullermd> At least if the account is used for anything other than bzr.
[01:08] <caravel> fullermd: right
[01:08] <BlazingSun> hmm yeah, i only want to have files ctreated in my bzr-repository have rw-flags for the group
[01:09] <BlazingSun> and i dont want to change them manually for every new branch
[01:09] <BlazingSun> (changing manually works)
[01:09] <BlazingSun> i just want that everyone is h his groupable to create new branches and share them wit
[01:10] <BlazingSun> i just want that everyone is able to create new branches and share them with his group
[01:10] <caravel> then dnotify may help, again you should ask #debian what to do better, but that should work
[01:11] <fullermd> As ugly hacks go, you could just setup a chmod in cron to whack it every hour or something.
[01:11] <caravel> fullermd: ^^ I'll go now, can you confirm there is no official doc about the "SmartServer" mode ?
[01:11] <BlazingSun> then it wouldnt be instantly
[01:11] <fullermd> I'm not sure what sort of doc you want...
[01:12] <caravel> fullermd: user doc for a start
[01:12] <fullermd> "Use bzr+ssh://whatever and have bzr installed on the server"
[01:12] <fullermd> 's about all there is...
[01:13] <caravel> fullermd: right -- so it's just executed by the ssh user, no daemon whatsover running on the host ?
[01:13] <BlazingSun> not really :(
[01:13] <fullermd> Yes.
[01:14] <BlazingSun> hm you dont have to set anything up, but setting permissions right seems a little bit complicated
[01:14] <fullermd> Much like CVS :ext: mode, etc.
[01:14] <BlazingSun> im no expert but still have some knowledge and im trying for a few hours now...
[01:15] <caravel> fullermd: thanks a lot, gotta go now. Bye & BlazingSun, good luck ^^
[01:16] <BlazingSun> hmm maybe acl would be a solution
[01:16] <BlazingSun> caravel: gn8
[01:17] <spiv>  [5~[6~[6~[6~ / .http://doc.bazaar.canonical.com/latest/en/admin-guide/simple-setups.html#smart-serverhttp://doc.bazaar.canonical.com/latest/en/admin-guide/simple-setups.html#smart-server  is the doc
[01:17] <spiv> Ugh, bad connection.
[01:17] <BlazingSun> the doc doesnt mention anything that would help setting up a bzr-system with multiple users
[01:19] <BlazingSun> over ssh
[03:26] <caravel> spiv: thanks! I wonder how I could miss it. Before I left I had found this doc also, a bit closer to my search http://wiki.bazaar.canonical.com/Specs/SmartServer Also, BlazingSun's issue would deserve being documented here http://wiki.bazaar.canonical.com/Bzr_and_SSH ...but isn't either. Night'
[04:49] <spiv> Woo, I have bzr-loom passing tests with bzr.dev and fetching all threads in one operation.
[04:50] <spiv> Only slightly nasty hackery required :/
[04:52] <lifeless> spiv: \o/
[04:52] <lifeless> thats -awesome-
[04:52] <lifeless> spiv: would you like a job working on bzr ?:)
[04:59] <spiv> lifeless: right now I'd settle for a working car and less bouts of gastro being brought home by my son... do you think you can arrange that? :)
[05:00] <spiv> It was a bit thornier to do than I expected, actually.
[05:00] <lifeless> spiv: let me wave my magic wand
[05:00] <lifeless> spiv: good test case for the API though, right? ;)
[05:00] <spiv> It mostly went smoothly, more code deleted than added, etc.
[05:00] <spiv> Yeah, it was, the API will need a small tweak :)
[05:01] <spiv> But then the hpss acceptance tests broke...
[05:02] <spiv> The tension is that we'd like to ask the remote side which heads to fetch: for built-in formats it's tip + tags, but for loom it's different, so we need the ability for loom to give a different answer there.
[05:03] <spiv> But ideally without adding in an extra round-trip that we didn't need before (for the built-in formats0.
[05:05] <spiv> So it's easy to add a heads_to_fetch RPC, but usually we don't want to call it because it'll be an extra roundtrip.
[05:07] <spiv> At the moment I have an ugly hack that looks at the branch format, and if it's a metadir format then it checks the _branch_class.heads_to_fetch, and if it's the same as the base Branch.heads_to_fetch, it just uses that.
[05:07] <spiv> Otherwise it asks the remote instance.
[05:10] <spiv> I'm not especially happy with that.  Somehow our layering isn't working so nicely for us: the caching of the tags dict and last-revision-info etc isn't completely automatically accelerating everything that would use them.
[05:11] <spiv> There's also the aspect where we aren't very clear about where exactly the division of responsibility is for local vs. remote.  Is it up to the client to calculate the heads to fetch by itself, or should the server always be in control?
[05:12] <spiv> Anyway, I've hacked around this case.   Hopefully we don't need many more like it :)
[06:00] <lifeless> spiv: why would the receiver know the tags
[06:00] <lifeless> spiv: I mean - surely the server should be determining the heads
[06:01] <lifeless> optionally constrained by the client - 'Oh, and I want X also, kthanxfetch'
[06:01] <lifeless> or 'but not tags today'
[06:03] <spiv> Well, all of branch/pull/merge fetch tags already today.
[06:03] <spiv> (And after recent fixes they fetch the revisions those tags refer to as well)
[06:04] <lifeless> which is great
[06:05] <spiv> So, currently in lp:bzr, there's no 'heads_to_fetch' RPC or anything like that: it's entirely up to the client to inspect the branch and decide what heads to fetch based on that.
[06:07] <lifeless> sure
[06:07] <spiv> I have a branch now that adds a heads_to_fetch method and RPC, and a branch of bzr-loom to override that to add in the threads' heads...
[06:07] <lifeless> I'm just riffing on the long term concepts
[06:07] <lifeless> this is great stuff
[06:07] <spiv> ...but my issue today is that actually using that RPC unconditionally regresses the HPSS call count tests.
[06:07] <fullermd> That sounds...  oddly backward to my uninformed speculation...
[06:08] <spiv> fullermd: which part?
[06:09] <fullermd> Well, the whole 'heads_to_fetch' concept/workflow.
[06:10] <fullermd> I mean, from the cheap seats (they're very comfortable, thank you) it seems like it's just a single request/response:  "I want branch XYZ, here are the heads I already have"  "OK, your new head is X, and here's a stream of the revs you need to get there"
[06:10] <fullermd> (I guess even the 'your new head is' bit is technically redundant, but...)
[06:10] <spiv> There's a couple of issues there.
[06:10] <fullermd> Jumping through a "what heads should I fetch?"   "OK, now I'll fetch 'em" sounds like a long way to carry the water.
[06:10] <spiv> One is that "here are the heads of my repo" isn't a cheap operation
[06:11] <fullermd> Yeah.  But you need to do it anyway (or just accept potentially fetching more than you need; and you could do that in this case too)
[06:11] <spiv> Arguably it should be, but it isn't and we haven't decided to make the format changes necessary to maintain an up-to-date cache of current heads.
[06:12] <spiv> Also, sending the remote side "here are all my heads" doesn't necessarily help you at all if the remote side has none of those revisions.
[06:12] <spiv> e.g. if you are pushing a new revision.
[06:13] <spiv> Anyway, I think this is actually a bit tangential to the original topic
[06:13] <spiv> You're talking about how to implement "I want the data for X, and I already have Y"
[06:13] <spiv> I'm talking about how you determine what X is in the first place.
[06:14] <spiv> It's not (necessarily) a single revision.
[06:15] <fullermd> Well, if you're pushing, you're not pulling   :)   I hold dark thoughts about the utility of turning that sort of conceptual symmetry into codepath symmetry.
[06:17] <fullermd> In my sense, X is the branch, not a rev; passing whatever that calls for can be known by the client saying what it has.  A second pass may be needed to fill in unknown tag revs, but that's a 1% (if that) case that I'd be perfectly happy to punt to extra RTT's when needed.
[06:17] <spiv> Also, it's not hard to construct plausible scenarios where two repos have 99% of their graph in common, but have zero overlap in their heads.
[06:18] <fullermd> But yeah, it's all tangential.
[06:20] <spiv> It might be nice to have RPCs that work along those lines.
[06:20] <spiv> Stacking would complicate it somewhat.
[06:21] <fullermd> That falls into "what cases do you optimize for".  Anyway.  It just Seems To Me(tm) that having the client try and grab both graphs and combine them is a lot of indirection, compared to both sides talking graph subsets at each other until one or the other finds a common point.
[06:21] <spiv> (Not to mention the friction with the current bzrlib APIs, although perhaps that will change)
[06:21] <fullermd> Especially since the 90% (99%?) case of pull would be right there when the client first says 'hey, here's my current head'.
[06:22] <spiv> Both sides do talk graph subsets to each other, take a look at the get_parent_map RPC.
[06:22] <fullermd> That, too.  This is where us non-OO personages leave the train   :p
[06:22] <spiv> And we already cope with the 9x% case of pull just fine :P
[10:21] <jelmer> maxb: bzr-svn should be compatible with older versions of bzr
[10:21] <jelmer> maxb: if it's not, that's a bug
[10:21] <maxb> jelmer: hmm?
[10:22] <jelmer> maxb: Also, do you know about debian/update-deps.py ?
[10:23] <maxb> jelmer: Ah, you're referring to my packaging branch commit? My *intention* was to add 2.4 as compatible in debian/control, not disown compatibility with previous versions
[10:27] <maxb> I did not know about debian/update-deps.py, though I appear to have updated manually to the same end result
[10:33] <jelmer> yeah, it does things like preserve ordering
[10:58] <vila> wow, I thought it was due to some bug but we really have an import consuming 4.6GB :-/ (nexuiz-data)
[10:58] <vila> no time to investigate now
[10:59] <jelmer> that's a very large package
[10:59] <jelmer> the binary package alone is a couple of hundred Mb
[11:07] <vila> jelmer: if we the host replacing jubany has less memory, we'll have a serious problem
[11:09] <jelmer> vila: It's unfortunate some things scale with the size of the tree at the moment :-(
[11:12] <vila> jelmer: could be, but I suspect there is more than the tree size involved here
[11:14] <jelmer> vila: it doesn't seem coincidental that this is one of the largest source packages in Debian/Ubuntu that's causing us problems
[11:15] <vila> right, as I said in bug #724890, this needs more investigations than I can provide right nwo
[11:16] <jelmer> the size of the compressed tree is 1G
[11:16]  * jelmer comments on the bug
[11:17] <vila> jelmer: thanks !
[11:18] <vila> jelmer: may be worth bubbling up to the losas, the migration is planned for 1st March and I'll be in vacations starting in a few hours, I'd like to concentrate on filing bugs about what I've seen yesterday experimenting with the new driver
[11:20] <jml> what's the difference between switch and update?
[11:21] <jml> or, actually what I mean is,
[11:21] <jml> a friend of mine has pushed a feature branch over the top of trunk rather than merging it in, he wants to get trunk back...
[11:21] <jml> I'm telling him to use 'bzr heads' to get the revid of the trunk tip
[11:21] <jml> and now I'm about to tell him to run something with that revid
[11:22] <jml> but I don't know whether that should be 'switch' or 'update'
[11:22] <jml> (also, is there a FAQ for this? it seems like a common rookie mistake)
[11:22]  * jelmer waves to jml
[11:22] <jml> jelmer: hi
[11:23] <jelmer> jml: I'm not aware of an FAQ for it, but you're right that there probably should be one.
[11:23] <jelmer> "bzr update -r" seems like the right solution now
[11:23] <jml> jelmer: thanks.
[11:23] <jelmer> I've always used "bzr pull --overwrite -r<revid> ." previously
[11:23] <jelmer> but that's not really intuitive
[11:24] <jml> so many ways to do what feels like the same thing.
[11:25] <jelmer> jml: "echo revid > .bzr/branch/last-revision" ? :)
[11:25] <jml> :)
[12:01] <maxb> jml: update: change the revno of a working tree; switch: change the branch and revno of a working tree
[12:01] <jml> maxb: I guess that means switch is a superset of update
[12:01] <maxb> yes
[12:02] <jelmer> not entirely, "bzr up" without arguments will update the working tree
[12:02] <jelmer> I don't think if you give switch the current revision it will touch the working tree, even if it is out of date
[12:02] <maxb> If a feature branch has been pushed (without --overwrite) into trunk then `bzr heads` will not help, as the old head of trunk will no longer be a head
[12:03] <jelmer> maxb: "bzr heads --dead" should still show it
[12:03] <jelmer> ah, sorry
[12:03]  * jelmer should learn to read
[12:03] <jelmer> maxb: Sorry, that's the second time this morning.
[12:04] <maxb> :-)
[12:04] <maxb> More coffee needed?
[12:04] <jelmer> I guess so :)
[12:06] <jml> maxb: so how do I figure it out then?
[12:08] <maxb> I'd fire up qlog
[12:09] <maxb> And locate the second parent of the last merge from trunk into the feature branch.
[12:14] <vila> jelmer: I've got a fix up for review regarding the import driver getting killed by an exception from a import thread
[12:15] <vila> jelmer: I would love to leave for vacations (RSN now ;) with such a fix landed on jubany
[12:15] <vila> jelmer: but no pressure really ;D
[12:15] <jelmer> vila: hehe
[12:15] <jelmer> vila: happy to have a look
[12:15] <jelmer> we really should make udd a part of the "bazaar" superproject..
[12:15] <vila> https://code.launchpad.net/~vila/udd/724898-driver-catch-importer-exceptions/+merge/51284
[12:21] <vila> jelmer: for the reviews you mean ? Cos' I'm thinking about turning it into a bzr plugin too... ;)
[12:21] <jelmer> vila: yeah - my life is driven by http://code.launchpad.net/bazaar/+activereviews
[12:22] <vila> I was suspecting that and I think we should change the patch pilot instructions to switch to that page too
[12:22] <vila> if only to be aware of the mp we're missing therre otherwise
[12:24] <jelmer> vila: Yeah, I think that'd be useful
[12:37] <vila> jelmer: Thanks for the review !
[12:38] <vila> jelmer: I've landed it on jubany but I feel bad asking for a restart while nexuiz-data has already run for 165 mins CPU
[12:39] <vila> jelmer: could you check it once in a while (while == day will be enough) and ask a losa to restart it then ?
[12:39] <jelmer> vila: ok
[12:39] <vila> jelmer: 1e6 thanks :)
[12:39] <jelmer> :)
[12:45] <jelmer> vila: I guess it'll be quiet early next week then :-/
[12:46] <vila> jelmer: hmm, yeah, forgot to mention that: you're the house keeper, so please don't forget the spider webs in the attic :-D
[12:46] <jelmer> hehe
[12:47] <vila> jelmer: and here are some votes for your mps: +1 +1 +1 +1 +1, use them wisely ;D
[12:47] <jelmer> vila: lol :)
[12:59] <montywi> vila: after 2600 minutes, I got this from bzr check: http://monty.pastebin.com/zZRryR4R
[12:59] <montywi> (internal error)
[13:16] <vila> montywi: that's just ... file a bug please :-( I don't remember off-hand if the check order has changed in more recent versions but I suspect this one could reported far earlier
[13:17] <vila> the revision seems a bit old, tht's even more worrying
[13:17] <vila> it's even from the initial migration, how odd
[13:18] <vila> montywi: but above all check shouldn't fail with an internal error :-(
[13:19] <vila> montywi: I won't be able to do anything, I'm leaving for a one week vacation but keep this repo safe
[14:06] <montywi> will do
[14:06] <montywi> thanks
[14:27] <burli> hi
[14:39] <burli> I want to use Bazaar on Lauchpad, but I have problems to setup launchpad and my computer
[14:40] <alf> burli: What exactly is the problem?
[14:40] <burli> ok, I have a launchpad account and I add an OpenPGP and SSH Key
[14:42] <burli> But if I try to create a branch I got just something that starts with /+junk/
[14:42] <burli> like this https://code.launchpad.net/~mb-embedit/+junk/mystock
[14:44] <alf> burli: +junk is the prefix for personal branches (not associated with a project), so this is normal
[14:45] <alf> burli: https://code.launchpad.net/~mb-embedit/+junk/mystock is empty though, have you pushed something to it?
[14:45] <burli> alf, right
[14:46] <burli> I want to push something into it
[14:46] <burli> what is my user id??
[14:47] <burli> bzr launchpad-login userid
[14:47] <alf> burli: mb-embedit
[14:47] <burli> ah, without ~
[14:47] <burli> damn
[14:51] <burli> what can I do if I use different computers or make a new installation?
[14:52] <burli> Can I take the keys with me? Or Import the Keys?
[14:52] <burli> I don't really understand the concept of OpenPGP or SSH Keys
[14:56] <alf> burli: yes, you can copy the keys if you like, but you can also register multiple keys in Launchpad, too
[14:56] <burli> Its a little bit confusing for me
[14:59] <burli> brb
[15:07] <burli> alf, I think it works now
[15:08] <alf> burli: great :)
[15:16] <burli> alf, another question. I want to fork a project and I want to merge changes from the original project. I create a clone, run "bzr pull" in the original project and than "bzr merge" in my fork. Now I have some conflicts.
[15:16] <jelmer> vila: we need a Debian GNU/kFreeBSD vm in babune :)
[15:16]  * jelmer was just made aware of some test failures
[15:17] <burli> I have now some files like *.BASE, *.in, *.OTHER and *.THIS
[15:17] <burli> what should I do now?
[15:18] <burli> ah, resolve
[15:19] <jelmer> burli: resolve the conflicts by editing the file/overwriting it with one of the *.{BASE,OTHER,THIS} files and then run bzr resolved
[15:20] <burli> jelmer, thx. done
[15:20] <alf> burli: yes, and note that *.in is a normal source file, not produced by the conflict
[15:21] <burli> I guess, I got it.... I hope so
[17:09] <cr3> what's the proper way to merge diffs between releases from one branch to an unrelated branch, like lp:foo to lp:ubuntu/foo for example. I keep doing something like (cd /path/to/foo; bzr diff -r1..2) | patch -p0, but that's aweful :(
[17:11] <jelmer> cr3: hi Marc
[17:11] <jelmer> cr3: Unfortunately if the branches don't have any related history we don't really have any better alternatives at the moment.
[17:12] <cr3> jelmer: darn, using patch is unfortunately error prone, like permissions not being preserved and so forth
[17:13] <jelmer> cr3: We're aware of the problem and would really like to fix it (it's common in the UDD use case, where upstream, debian and ubuntu all have different imports of essentially the same data)
[17:15] <cr3> jelmer: I'm sure if it's not implemented yet there's a good reason, like very complicated problem to solve :) I wish you best of luck solving that problem then!
[17:17] <jelmer> it's a very hard problem to solve right, but we could at least provide you some tools to make it a bit less painful
[17:31] <burli> can I make a private bazaar branch on launchpad?
[17:31] <jelmer> burli: only with a commercial launchpad subscription
[17:31] <burli> hm
[17:34] <burli> is it possible to install my own bazaar server? I have one project, that is not public, but I want to use bazaar for versioning
[17:37] <jelmer> burli: yes, you can run your own server using bzr itself and set up a web interface using loggerhead
[17:37] <briandealwis> hi jelmer.  Is there a bzr-svn newer than 1.0.4?   bzr 2.3.0 complains about api versions with 1.0.4
[17:37] <jelmer> briandealwis: there is going to be a 1.1.0, but it's not out yet
[17:37] <briandealwis> ahok
[17:38] <burli> jelmer, is there a documentation/tutorial how to install/setup such a server?
[17:38] <briandealwis> burli: see the docs.  http://doc.bazaar.canonical.com/latest/en/user-guide/server.html
[17:39] <burli> briandealwis, thx
[17:40] <burli> is there any problem if I use different versions of bzr? My server is running Maverick and on some computers I run Natty
[17:44]  * jelmer heads off for some weekend
[17:59] <maxb> hrm
[17:59] <maxb> subvertpy appears to be repeatably segfaulting in its tests on maverick/amd64
[18:07] <mgz> jam or someone, does this diff actually make any sense?
[18:07] <mgz> http://www.physics.drexel.edu/~wking/code/git/gitweb.cgi?p=be.git;a=commitdiff;h=1e0967ab82d8541413e1dfe4d2e78f1008aa9c5b;hp=6eeb62d99a40f8644ac0840ac1291ef92b3d836f
[18:08] <mgz> as the path is always inside the repo, won't the base_tree and tree always be the same, so he *could* just omit the 'file_ids_from' param?
[18:09] <mgz> ...there is no jam.
[19:09] <mgz> ...that doesn't make any sense, why did I type that...
[19:12] <lifeless> the shadow knows
[19:17] <mgz> meh, I've never known the c standard that well anyway.
[21:16] <burli> hm, what's wrong? I created on my server a new bzr project with bzr init. I can create a branch on different computers, can pull and push. everything works. But the project folder on the server is empty
[21:19] <Peng> burli: It's not empty; it has a .bzr directory full of data. It just doesn't have a working tree.
[21:34] <burli> Peng, ah, ok, thx


[00:38] <rickspencer3> default alt-tab behavior on Kubuntu is very nice
[00:41] <yuriy> what is the default? with or without effects?
[00:44] <smarter> yuriy: with effects if it detects that it works nicely
[00:45] <smarter> detection that has been disabled by default on 4.3 because it causes the screen to flicker if I'm not mistaken
[00:46] <JontheEchidna> I thought the SuSE randr module caused flicker. Maybe they both did ;P
[00:46] <smarter> JontheEchidna: that randr thingy got ditched in 4.2 no?
[00:46] <yuriy> i meant the default alt-tab behavior
[00:46] <JontheEchidna> yeah, it did
[00:46] <smarter> cause I still see flicker
[00:46] <JontheEchidna> every 10 seconds?
[00:46] <rickspencer3> yeah, I'm 99% certain it's a compiz effect with a reflective table
[00:47] <smarter> JontheEchidna: no, when KDE start
[00:47] <JontheEchidna> oh, yeah I see that too
[00:47] <smarter> I'd be blind else :p
[00:47] <yuriy> oh so it's the cover flow thing? I don't like that much
[00:47] <rickspencer3> meh
[00:47] <rickspencer3> I likes
[00:47] <smarter> yuriy: it's like 4 clicks to change it :p
[00:47]  * smarter liek it too
[00:47]  * JontheEchidna wonders if we still have coverwitch and boxswitch activated at the same time...
[00:48] <smarter> O_o
[00:48] <JontheEchidna> by default
[00:48] <JontheEchidna> oh, that was fixed
[00:48] <smarter> unfortunately coverswitch doesn't work with XRender :/
[00:48] <smarter> or at least, not here
[00:49] <JontheEchidna> I tried it, nor here
[00:49] <JontheEchidna> XRendr is 2D accel only iirc
[00:49] <smarter> oh, might explain it then :p
[00:51]  * JontheEchidna finally got around to removing all the stuff deborphan said he had laying around
[00:51] <JontheEchidna> /me -- the original twitter client
[00:51] <seele> rickspencer3: if you like quassel, you should have seen it before the last release
[00:52] <smarter> JontheEchidna: never thought of it that way :p
[00:53] <smarter> JontheEchidna: deborphan is supposed to be dead since a few release no?
[00:53] <smarter> apt-get autoremove/aptitude whatever should do the same
[00:53] <JontheEchidna> apt-get autoremove is insane
[00:53] <JontheEchidna> I removes stuff I actually need
[00:54] <JontheEchidna> deborphan's still in universe by the looks of it
[01:10] <DreadKnight> omg, blender can't be installed anymore...
[01:12] <DreadKnight> https://www.getdropbox.com/referrals/NTEyMjU2MTk
[01:12] <DreadKnight> ops
[01:12] <DreadKnight> The following packages have unmet dependencies:
[01:12] <DreadKnight>   blender: Depends: python (< 2.6) but 2.6.1-0ubuntu1 is to be installed
[01:14] <DreadKnight> T_T
[01:25] <ScottK> DreadKnight: Relax.  We're in the middle of a Python transition right now.
[01:25] <DreadKnight> installed blender on wine already >_<
[03:12] <maco> any reports of kmail plowing through cpu cycles? kio_imap4 is using 100% cpu, and kmail's not even checking for mail right now!
[03:13] <JontheEchidna> I haven't seen any yet
[03:13] <maco> ok then
[03:14] <maco> >< killing kmail didn't make it stop
[03:17] <ScottK> ergo it's not kmail.
[03:17] <JontheEchidna> the kio slaves run independent of programs, usually
[09:50] <Quintasan> \o
[11:34] <mkulke_> anyone using pyqt/kde? i have a problem that when i want to connect a signal of my qobject derived python object, to a slot in a kmainwindow, python bails out w/: QObject.connect(self.session, SIGNAL("whop(int)"), self.transfer), RuntimeError: underlying C/C++ object has been deleted
[11:34] <mkulke_> what am i doing wrong here?
[11:39] <smarter> Sime is probably the guy to ask ;)
[11:44] <Riddell> mkulke_: able to give us the code to run?
[11:45] <mkulke_> uhm, yes
[11:45] <mkulke_> 1 sec
[11:47] <smarter> what type of objects are self.session and self.transfer?
[11:47] <smarter> this thread may be relevant: http://markmail.org/message/si3imcn7k4anefqw#query:pyqt "RuntimeError+page:1+mid:xmx6b2hqmnk7gsvb+state:results
[11:47] <mkulke_> Riddell: http://svn.berlios.de/svnroot/repos/kasablanca/kasablanca-python/trunk/
[11:47] <mkulke_> it's kasablanca.py
[11:47] <mkulke_> smarter: self.session is a Session object, derived from QObject
[11:48] <smarter> mkulke_: does a print self.session works?
[11:48] <smarter> (instead of the connect)
[11:48] <mkulke_> yes
[11:49] <mkulke_> <session.Session object at 0xb4a1de6c>
[11:49] <Riddell> what about QObject.connect -> self.connect
[11:49] <mkulke_> self.transfer is a KasablancaMainWindow method
[11:50] <mkulke_> tried that
[11:50] <mkulke_> logically it should be self.session.connect i guess
[11:50] <mkulke_> but it does not matter really
[11:50] <mkulke_> non custom signal/slot stuff works
[11:51] <smarter> what if you remove the second arg to self.transfer in kasablanca.py?
[11:51] <smarter> def transfer(self): ...
[11:52] <mkulke_> no effect
[11:52] <mkulke_> i wonder whether there's more to it, than just deriving an object from QObject to make it issue signals?
[11:53] <smarter> in C++ you have to add the macro Q_OBJECT, no idea if there's something like that in PyQt :p
[11:53] <mkulke_> yeah i know, i am used to c++ qt
[11:54] <Riddell> mkulke_: how do I get settingswidget.py ?
[11:55] <mkulke_> pyuic4 settingswidget.ui > ui_settingswidget.py
[11:55] <mkulke_> i guess you meant that
[11:56] <mkulke_> smarter: so far converting to "rapid development" thingie w/ python hasn't worked out for me. i spent hours to figure out stuff like this :)
[11:56] <smarter> hehe
[11:57] <Sime> mkulke_: what is self.session?
[11:58] <smarter> Sime: http://svn.berlios.de/svnroot/repos/kasablanca/kasablanca-python/trunk/ kasablanca.py
[11:58] <mkulke_> Sime: a Session object (class derived from QObject)
[11:59] <mkulke_> maybe i need some kind of "super" call in the Session constructor to make Session signal/slot-able
[11:59] <Riddell> mkulke_: I get http://paste.ubuntu.com/124227/
[11:59] <Sime> mkulke_:  that old chess-nut. Your Session object doesn't have a QObject because you didn't call QObject.__init__()
[12:00] <Sime> mkulke_: more or less what you just said. ;-)
[12:00] <Riddell> what a really confusing error message
[12:01] <Sime> not really, when you keep in mind that the python objects 'wrap' matching c++ objects.
[12:06] <mkulke_> heureka!
[12:06] <mkulke_> that's it. thanks alot Riddell, smarter, Sime
[12:06] <smarter> you're welcome :)
[12:06]  * smarter will keep that in mind next time he does pyqt :p
[12:07] <mkulke_> Riddell: why you do not get settingswidget.py remains a mystery to me tho
[12:08] <mkulke_> i just checked out svn co http://svn.berlios.de/svnroot/repos/kasablanca/kasablanca-python/trunk
[12:08] <Riddell> mkulke_: well you told me to name it ui_settingswidget.py
[12:08] <mkulke_> no
[12:08] <mkulke_> the settingswidget.ui file is compiled (or whatever) into a ui_*.py file using pyuic4
[12:10] <Riddell> so where does settingswidget.py come from?
[12:10] <Riddell> aah
[12:10] <Riddell> it's in svn
[12:10] <Riddell> but I overwrote it when I first compiles the .ui file
[12:11] <mkulke_> ah,k
[12:12] <mkulke_> how do i package this python stuff btw?
[12:12] <Riddell> into a .deb?
[12:12] <mkulke_> yeah, but also generally
[12:13] <mkulke_> should the the .py files  be put into a module or sth?
[12:13] <Riddell> you can use cmake, take a look at printer-applet in kdeadmin for example
[12:13] <Riddell> kdeutils rather
[12:14] <Riddell> or system-config-printer-kde in kdeadmin
[12:14] <mkulke_> and as the backend of the app is a c++ kio-slave, can i deliver it w/ the python app or should they be seperate packages
[12:14] <Riddell> it'll just install the files to /usr/share/kde4/apps/<appname>/<filename> and install a symlink from /usr/bin
[12:14] <Riddell> they should be fine together
[12:15] <mkulke_> ok
[12:18] <smarter> anyone could give me an account on a server somewhere to run QuasselCore? People are getting annoyed with my disconnections :p
[12:19]  * Hobbsee wonders what quasselcore requires to run
[12:27] <smarter> Hobbsee: Depends: libc6 (>= 2.2.5), libgcc1 (>= 1:4.1.1), libqt4-network (>= 4.4.3), libqt4-script (>= 4.4.3), libqt4-sql (>= 4.4.3), libqtcore4 (>= 4.4.3), libstdc++6 (>= 4.1.1), adduser, openssl, libqt4-sql-sqlite
[12:27] <smarter> so, no X11
[12:27] <Hobbsee> hrm
[12:28]  * Hobbsee wonders why it depends on adduser?
[12:28] <smarter> because it creates a quassel/quassel user/group
[12:28] <smarter> to runs the daemon
[12:29] <smarter> like apache and others do
[12:29] <smarter> *run
[12:33] <mkulke_> a.emit(QtCore.SIGNAL("pySig"), "Hello", "World") <- this is wrong, i guess
[12:33] <mkulke_> i got the line from the riverbankcomputing reference
[12:33] <mkulke_> self.emit(SIGNAL("transfer(PyQt_PyObject, QString)"), self, fileName) works for me
[12:34] <Sime> that looks better
[12:34] <mkulke_> but self.emit(SIGNAL("transfer"), self, fileName) doesn't
[12:34] <mkulke_> http://www.riverbankcomputing.com/static/Docs/PyQt4/pyqt4ref.html#emitting-signals
[12:36] <Sime> are you going from a python object to another python object?
[12:36] <Sime> connecting to a c++ might require mroe specific args in the signal
[12:36] <mkulke_> both are python objects
[12:37] <Hobbsee> smarter: yeah....but....there's no need to depend on something in minimal ;)
[12:37] <Sime> BRB
[12:37]  * Hobbsee hopes it's not a hardcoded dependancy
[12:37] <smarter> Hobbsee: oh, probably :p
[12:38]  * Hobbsee twitches
[12:38]  * Hobbsee wonders if it has any other interesting packaging bits in it, then
[12:50] <JontheEchidna> holy crap
[12:50] <JontheEchidna> my inbox just got flooded with translation imports
[12:50] <Hobbsee> welcome to launchpad!  ;)
[12:51]  * Hobbsee advocates blackholing anything from launchpad, and then pulling out specifically based on headers things you're interested in
[12:53] <JontheEchidna> well, at least I know that ktorrent should be good for translations except Bulgarian
[12:54] <Hobbsee> hehe
[12:56] <a|wen-> JontheEchidna: you're a MOTU right?
[13:01] <JontheEchidna> a|wen-: yes
[13:15] <a|wen-> JontheEchidna: i have a new svn snapshot of kile ready; is that something you could upload?
[13:15] <JontheEchidna> Yeah, I could sponsor that
[13:15] <a|wen-> JontheEchidna: cool ... http://awen.dk/packages/kile/
[13:17]  * JontheEchidna looks
[13:20] <JontheEchidna> Looks good, I can upload after it pbuilds
[13:22] <ScottK> JontheEchidna: Please pile onto Bug 335831
[13:22] <ScottK> Good $TIMEOFDAY all.
[13:23] <ScottK> Riddell: Did you get a chance to look at my proposal for pkg-kde-tools (see my PPA - https://launchpad.net/~kitterman/+archive/ppa/)?
[13:25] <a|wen-> good weekend (that should be agreeable at least) ScottK
[13:33] <JontheEchidna> a|wen-: I have to go in a bit, I may not have enough time to finish the testbuild so I might have to upload when I get home. (Unless you can find someone else to sponsor it)
[13:34]  * JontheEchidna will try to to it before he goes, though
[13:34] <a|wen-> JontheEchidna: no problem; it can wait till you get home if it is
[13:38] <JontheEchidna> I'm going up to Portland, Maine to visit relatives, so I may not get back until late. (FYI)
[13:38] <JontheEchidna> doesn't look like it will be built in time :(
[13:40] <Tonio_> hi there
[13:41] <a|wen-> JontheEchidna: oh, okay... the large part is downloading, the build in itself only takes a few minutes
[13:41] <a|wen-> hi Tonio_
[13:42] <Tonio_> isn't anyone reviewing NEW now ? knemo is stuck there for a couple of weeks now...
[13:43] <smarter> Tonio_: ask Riddell :)
[13:43] <Tonio_> smarter: yeah, but he already has so much to do...
[13:44] <Tonio_> Riddell: well, when you have a moment, knemo used to be a very popular kde3 app, getting the kde4 version in the repos could be interesting !
[13:44] <smarter> that's why Canonical is hiring KDE devs
[14:55] <ScottK> smarter: No.  It's not.  These people are specificially not being hired to work on the Kubuntu work we already do.  They are being hired to "improve the desktop experience".
[14:56] <smarter> ScottK: which means...? :)
[14:56] <ScottK> Hopefully something better for us than what it's currently meaning for Ubuntu.
[14:57]  * ScottK heads out ....
[14:57] <smarter> haha*
[14:57] <smarter> see you
[15:02] <Hobbsee> good thing a lot of the people who have tried it like it, then.
[15:14] <freeflying> when enable desktop effect(intel's graphic card), toolbar from a lot kde4 applicatons won't be re-drawn
[15:14] <freeflying> any of you encountered?
[15:32] <Tonio_> freeflying: I have lots of redraw issues since we went to use qt4.5
[15:33] <Tonio_> freeflying: I suspect qt is the guilty there
[15:34] <ScottK> Hobbsee: I also pretty fundamentally object to changing long standing system functions with little notification (pun intended) and then declaring all applications which don't conform t the new assumptions broken.
[15:35] <ScottK> Fortunately, at least for the one who's announced himself, the KDE people actually have FOSS experience so I expect it will go better for us.
[15:41] <freeflying> Tonio_: this sound make sense :)
[17:34] <Quintasan> \
[17:34] <Quintasan> erm.. Hi
[17:45] <DaSkreech> hi
[17:45] <ScottK> a|wen: Please have a look at https://launchpad.net/ubuntu/+source/xmp/2.5.1-1ubuntu1/+build/864804/+files/buildlog_ubuntu-jaunty-ia64.xmp_2.5.1-1ubuntu1_FAILEDTOBUILD.txt.gz - if I read it right audacious-plugins still has some attachment to arts.
[17:48]  * a|wen looks
[17:53] <a|wen> ScottK: have we been through some libjack-transition as well in jaunty?
[17:54] <ScottK> Not AFAIK.  It is broken on some of the ports archs.  I don't know enough to fix it.
[17:54] <a|wen> the problem is that the new audacious-plugins with arts removed didn't get build due to libjack problems
[17:55] <a|wen> ScottK: https://launchpad.net/ubuntu/+source/audacious-plugins/1.5.1-2ubuntu3/+build/864972/+files/buildlog_ubuntu-jaunty-ia64.audacious-plugins_1.5.1-2ubuntu3_FAILEDTOBUILD.txt.gz
[17:55]  * ScottK idly whistles and wonders who might have a look at that.
[17:56] <ScottK> a|wen: I dont know how to fix it.
[17:57] <Nightrose> weeeeeeeee
[17:58] <Nightrose> got my Kubuntu stickers!
[17:58] <Nightrose> thanks Riddell :)
[18:01]  * Tm_T has big issues with dbus
[18:01] <Tm_T> who knows where does dbus session get its path and other variables?
[18:02] <Tm_T> in KDE session that is
[18:02] <a|wen> ScottK: seems it might be due to libffado not building on a lot of arches
[18:03] <ScottK> OK.  Can that be fixed?
[18:07] <a|wen> it spits out some int/long/uint32/64 mismatch ... not exactly something i know anything about; so bring in the ports experts
[18:11] <ScottK-palm> Battery just went on my laptop.
[18:11] <ScottK-palm> NCommander is the one you want.
[18:11] <ScottK-palm> I expect getting that one fixed would enable a lot of stuff to get built on these archs.
[18:20] <a|wen> i'll put my faith in NCommander :)
[18:25] <Lure_> Riddell: thanks for stickers
[18:26]  * Lure_ did not know that even his daughters would love to have some ;-)
[18:27] <Quintasan> Hmm can anyone (jaunty) install skim and tell me if kmenu icon appears for him?
[18:28] <Quintasan> hmm still not fixed
[18:35] <DaSkreech> Anyone here uses lancelot ?
[18:36] <DaSkreech> Though Kickoff has a slightly similar bug
[18:40] <Quintasan> hmm, in which file I can check for filesystem error? dmesg logs dont contain any
[18:45] <Quintasan> grr something freezes my system it usually occurs when copying or deleting files, I can't tell whats the cause
[18:53] <smarter> Tonio_: kpackagekit binary package still needs to have a dep on packagekit added :)
[18:54] <Tonio_> smarter: I know :)
[18:54] <smarter> ok
[18:54] <Tonio_> smarter: that'll happen when I upload version 0.4
[18:54]  * smarter just upgraded to Jaunty and that confused him
[18:55] <rgreening> Tonio_: yay
[18:55] <Tonio_> rgreening: e just have to wait for glatzor ;)
[18:55] <rgreening> ty. Tonio_can you also ping the guys who manage packagekit lp and get them to auth my request to join the team.
[18:55] <rgreening> :)
[18:56] <smarter> I installed packagekit, killall-ed kpackagekit, but when I try to do anything I get "Authentication failed"
[18:56] <rgreening> smarter, even teh smart icon one?
[18:56] <smarter> hmm, I didn't check if it was really killed
[18:56] <rgreening> try a reboot to be sure
[18:57] <smarter> ok
[18:57] <rgreening> and they run as root
[18:57] <rgreening> so you have to kill via sudo
[18:57] <rgreening> if you missed that
[19:02] <ScottK> rgreening: Get your app done?
[19:04] <rgreening> fell asleep. then got a call 4 hrs later. network probs at work.
[19:04] <rgreening> and Im still at work now.. grrr...
[19:04] <rgreening> stupid failing fiber bulkheads.
[19:04] <rgreening> hairline fracture in the ceramic core. was a pain to troubleshoot and find
[19:05] <rgreening> at least it seems resolved and I can get back to this.
[19:39] <claydoh> w00t! stickers!  air mail from London, wow
[19:40] <claydoh> thanks Riddell!!
[19:41] <ghostcube> anyone needs an wlan get hacked :D
[19:41] <ghostcube> aircrack has an new iso on the road
[19:41] <DaSkreech> smarter: ping
[19:42] <nixternal> claydoh: send me some stickers
[19:44] <claydoh> nixternal: got plenty, more than happy to
[19:44] <DaSkreech> Quintasan: File system ?
[19:45] <Quintasan> DaSkreech: yeah, I've found a bug on launchpad for it
[19:45] <DaSkreech> Quintasan: ok
[19:45] <DaSkreech> nixternal: When you get some stickers. Send me some stickers :)
[19:45] <claydoh> lol
[19:46] <Quintasan> My system freezes while deleting or moving big portions of data, using 2.6.28-8 and ext4, no errors in dmesg log or any other. Last time my .kde was eaten by it
[19:47] <Quintasan> I didn't want stickers, but now I do -_-'
[19:47] <seele> i think theyre on the ubuntu store now
[19:47] <seele> or will be soon
[19:47] <nixternal> seele: they don't have any Kubuntu stuff on the US store :(
[19:47] <nixternal> yet that is
[19:47] <jjesse> nixternal: did you go hang out at the chicago tea party today?
[19:48] <nixternal> jjesse: that was yesterday and I totaly missed
[19:48] <nixternal> it
[19:48] <jjesse> bummer :)
[19:48] <Quintasan> seele: http://shop.canonical.com/product_info.php?products_id=418&osCsid=b2d2b1bdeec1298a90588edbeddf43e7
[19:48] <Quintasan> :P
[19:49] <nixternal> jjesse: from what I saw on the news, they had a good crowd too
[19:49] <jjesse> that's what i heard as well, but don't want to go too far off topic anymore:)
[19:49] <nixternal> hehe
[19:52] <seele> Quintasan: ive got stickers :P
[19:52] <Quintasan> seele: :3
[19:53] <smarter> DaSkreech: pong
[19:53] <DaSkreech> nixternal: Whoot
[19:53] <DaSkreech> smarter: kvkbd
[19:54] <smarter> yes? :)
[19:54] <DaSkreech> how many languages does it do
[19:54] <DaSkreech> Or rather how many keyboard layouts?
[19:54] <smarter> it gets the mapping from X
[19:55] <DaSkreech> Ah so as many as X does
[19:55] <smarter> yep
[19:55] <smarter> I'll probably change that
[19:55] <smarter> since the KDE thing to change keyboard layout doesn't use whatever kvkbd use to retrieve the layout
[19:56] <DaSkreech> Yeah that was my next question
[19:56] <DaSkreech> damn it
[19:56] <DaSkreech> Now I have to think of a new one
[19:56] <DaSkreech> ummmm
[19:56] <DaSkreech> How about them SVGs? :-)
[19:58] <ghostcube> anyone here writing for wiki.ubuntuusers.de ??
[19:58] <ghostcube> best wiki ever
[19:58] <ghostcube> !!!!!!!!!!!!!!
[19:58] <ghostcube> :)
[19:59] <smarter> DaSkreech: First, i'll make the background color configurable, svgs will come after :p
[19:59] <smarter> but first first first thing is to document it/fix it a bit
[20:00] <DaSkreech> ok I just really wanted to know about keyboard layout
[20:00] <DaSkreech> in case I'm going to some strange country I can figure out the keybaords before I go :)
[20:00] <DaSkreech> boards
[20:02] <smarter> I haven't touched it since october, and I've become quiet a lot better in coding since then :)
[20:03] <smarter> setxkbmap fr
[20:03] <smarter> you get french keyboard: p
[20:03] <smarter> actually, the default for France is setxkbmap fr oss
[20:03] <smarter> oh, the custom about:konqueror is feeling a bit... empty :]
[20:37] <DaSkreech> jjesse: how goes?
[21:02] <quassel208> guys a boot up time from 20 sec with alpha software from intel
[21:04] <smarter> what alpha software?
[21:07] <a|wen> DreadKnight: your missing buddy icons with yahoo in kopete is fixed in kde 4.2.1
[22:13] <quassel208> smarter moblin aplha 20, i booted up in 20 sec with a normall sata 3 hd
[22:14] <smarter> quassel208: pretty cool
[22:15] <quassel208> trying with fedora sources to get kde4.2 on it, because xfce isnt my thing
[22:21] <DreadKnight> a|wen: i know that bug has been fixed quite a few days now
[22:22] <DreadKnight> but teoretically it will take about 10 months to have it fixed in official kubuntu i think (unless ported to a .1 version)
[22:23] <a|wen> DreadKnight: it will be in 4.2.1 due out in less than a week
[22:23] <DreadKnight> or will get into 9.04?
[22:23] <DreadKnight> cool
[22:23] <DreadKnight> last time i checked file transfer was phail in kopete over yahoo as well
[22:24] <DreadKnight> even crashed it
[22:24] <DreadKnight> haven't checked the status in bugzilla about that one
[22:24] <a|wen> so will be in 9.04 ... and you should be able to get it from the kubuntu-experimental ppa for intrepid in ~week
[22:25] <DreadKnight> and as far as i noticed, i don't even receive offline messeges over MSN protocol.. that's scary
[22:26]  * DaSkreech doesn't recieve any messages over MSN protocol
[22:26] <rgreening> seele: hey seele
[22:26] <DreadKnight> anyway, i think kopete is rather ugly when it comes to usability and even default settings
[22:27] <DreadKnight> i can't even copy or click links from my contact's status messeges.. not cool
[22:32] <DaSkreech> DreadKnight: I can
[22:33] <DreadKnight> DaSkreech: how? :P
[22:33] <DaSkreech> DreadKnight: Normally I either click on the link or I drag it to where I want it
[22:34] <DreadKnight> DaSkreech: from the contact list? :P
[22:36] <DreadKnight> i said from status messege, not conversation
[22:37] <DaSkreech> Oh I don't know
[22:37] <DaSkreech> I don't have anyone who has a URL in the status message
[22:37] <DaSkreech> can't think of when last I saw on
[22:37] <DaSkreech> one
[22:38] <DreadKnight> :P
[22:38] <DreadKnight> kopete is damn awefull atm no matter what you guys say
[22:39] <DreadKnight> typical case scenario is that people place links in statuses "i love this song" and some youtube link; or "new post on my blog" and yet again link
[22:39] <DreadKnight> etc
[22:40] <DreadKnight> and by default people want to see the avatars in contact list, like in every other IM application out there
[22:40] <DreadKnight> which wasn't default for me
[22:40] <DreadKnight> finding the account manager is sort of like hidden... somewhere in the menus.. in settings or something
[22:41] <DaSkreech> huh?
[22:41] <DreadKnight> i can go on with a lot of things; might as well make a blog post and put feed into k/ubuntu planet
[22:41] <DaSkreech> It's the first thing that pops up when ou open Kopete
[22:42] <DreadKnight> that's first time wizard :P
[22:43] <DaSkreech> Yeah
[22:43] <DaSkreech> After that it's at the bottom of your contact window
[22:44] <DreadKnight> can you add a new account from there etc?
[22:45] <DaSkreech> i would guess so it takes you to account management
[22:46] <DreadKnight> i closed it a while ago... made me phail exams even more than pidgin xD
[22:46] <DaSkreech> I'm not aruging that kopete doesn't need help. My arguement is who will help them
[22:47] <DreadKnight> i agree
[22:47] <DreadKnight> but i'm trying to pinpoint things that are fugly with them and how to make them better
[22:47] <DaSkreech> They have a set of Juniour Jobs on Techbase
[22:47] <DaSkreech> Just add them to it with a starter for how to make it better
[22:48] <DreadKnight> perhaps swap the crappy 'account manager' thingy at the botton and have an icon in the main toolbar that takes you to the real account manager thingy
[22:48] <DreadKnight> juniour jobs?
[22:48] <DaSkreech> Small things that need changing
[22:48] <DreadKnight> hmm
[22:48] <DaSkreech> there are only  a few Kopete developers
[22:49] <DaSkreech> and they focus mostly on protocol stuff which isn't easy
[22:49] <DaSkreech> GUI stuff can be done my someone who isn't that specialized
[22:49] <DreadKnight> in most of the kubuntu planet blog posts containing images of kde desktops... most of them had pidgin in them
[22:49] <DaSkreech> Yeah well they have 3 paid developers working on it
[22:50] <DaSkreech> That's three more paid developers than work on Kopete
[22:50] <DaSkreech> and more devs than continuiously work on kopete
[22:50] <DreadKnight> ok found the junior jobs
[22:50] <DreadKnight> well, GUI really sucks overall atm
[22:51] <DaSkreech> Make it as detailed as possible and outline what the participant will need
[22:51] <DaSkreech> to know to start
[22:52] <DreadKnight> and saying it's how things are supposed to be because kopete supports so many protocols is a lame argument (someone here said that argument)
[22:52] <DreadKnight> there was a closed source IM app supporting multiple protocols and it was looking quite good... miranda i think... there are also some new ones out there.. even crossplatform
[22:52] <DreadKnight> ok
[22:54] <DaSkreech> Miranda is closed source?
[22:54] <DaSkreech> !info miranda
[22:56] <DreadKnight> DaSkreech: yeah... for windowz.. or was it mirana... let me google for some stuff
[22:56] <DaSkreech> No it's miranda
[22:56] <DaSkreech> It's open source I just didn't know it's Windows only
[22:57] <DreadKnight> http://www.miranda-im.org/
[22:57] <DreadKnight> open source indeed
[22:57] <seele> rgreening: pong
[22:57] <DaSkreech> I like the Identity paradigm in kopete better than that
[22:59] <DreadKnight> hmm http://www.trillian.im/
[22:59] <DreadKnight> there are others i don't remember the name
[23:00] <DaSkreech> I know trillian
[23:01] <DreadKnight> http://www.trillian.cc/
[23:01] <DreadKnight> 2 versions
[23:01] <DaSkreech> I know one you have to purchase
[23:01] <DreadKnight> or 3
[23:01] <DaSkreech> a different interface for one that you don't
[23:02] <DaSkreech> AIR they have a third interface that's the new rewrite
[23:02] <DreadKnight> so basic... pro.... and astra (beta)
[23:02] <DaSkreech> Yes
[23:03] <DreadKnight> a bit confusing with all those versions; but they could serve a little bit as inspiration (how trillian and others handle GUI related stuff)
[23:05] <DaSkreech> You could submit stuff to kopete :)
[23:06] <DreadKnight> getting now a techbase account
[23:07] <DreadKnight> i sort of hate it that all IM apps use plain lists and categories.. i find it so crappy...
[23:08] <DreadKnight> would be cool to manage  contacts with tags (like files with akonady) and um... see them like icons in dolphin
[23:09] <DaSkreech> DreadKnight: planned as I understand it
[23:09] <DreadKnight> :)
[23:10] <DaSkreech> again there are very few devs on Kopete and stuff like Nepomuk integration is heavy lifting
[23:10] <DreadKnight> i'll see what's up with the kopete irc channel
[23:10] <DreadKnight> cool
[23:10] <DaSkreech> really what they need is a group of smaller devs dealing with less "important" stuff
[23:11] <DreadKnight> mhm
[23:11] <DaSkreech> If you would like to do mockups of ideas that would help as it would give new contributors a clear idea as to what to do
[23:11] <DaSkreech> as long as it's not a drive by mockup :)
[23:13] <DreadKnight> yes
[23:26] <quassel208> guys can you do that with kubuntu boot up within 20 sec?
[23:29] <DreadKnight> not me at least T_T
[23:51] <sebas> My BIOS alone takes 30-ish seconds
[23:51] <sebas> That makes my cry (and use suspend)


[10:42] <lxsu> hmmm.. är detta en svensk kanal?
[14:21] <cody-somerville> Hey
[14:21] <cody-somerville> I'm having trouble getting the Xubuntu docs to build
[14:22] <cody-somerville> Is this a known issue?
[14:22] <cody-somerville> "make -C xubuntu" seems to work...
[14:30] <mdke> cody-somerville: "make all" works alright. Xubuntu docs are done slightly oddly though. What seems to be the problem?
[14:31] <cody-somerville> Well, it turns out I can build it just fine if I type "make -C xubuntu"
[14:31] <cody-somerville> It seems that the Makefile in the xubuntu branch needs updating
[14:31] <cody-somerville> mdke, Also, I've just regenerated the pot files. So I need to upload them to launchpad right?
[14:33] <mdke> no, they will be imported fine if you do an upload
[14:33] <cody-somerville> For example, I'd visit https://translations.edge.launchpad.net/ubuntu/hardy/+source/xubuntu-docs/+pots/about-xubuntu/+upload and upload the pot for about-xubuntu
[14:33] <mdke> cody-somerville: so "make all" didn't work for you?
[14:33] <cody-somerville> There is no taget all :)
[14:33] <mdke> sure there is
[14:33] <mdke> I just did it
[14:33] <cody-somerville> I'm running this from the top directory
[14:33] <cody-somerville> not in xubuntu/
[14:34] <mdke> all: clean style index
[14:34] <mdke> right, you need to do it from xubuntu/
[14:34] <cody-somerville> Okay, so can I update the Makefile in the top directory to do just that?
[14:34] <cody-somerville> Or will that break things?
[14:34] <mdke> I doubt the Makefile in the top directory is used at all
[14:34] <mdke> we can remove it
[14:35] <cody-somerville> Okay, sounds good
[14:36]  * cody-somerville does some tidy work
[14:38] <cody-somerville> mdke, Do the xubuntu-docs really need to depend on the ubuntu-docs? :)
[14:38] <cody-somerville> in the build-depends
[14:39]  * cody-somerville will try building without it.
[14:40] <mdke> cody-somerville: no idea I haven't ever touched xubuntu-doc packaging. Can't think of a reason though
[14:40] <mdke> is it including a document from /usr/share/ubuntu-docs maybe?
[14:40]  * mdke leaves for a bit
[14:41] <cody-somerville> OooOoo... it probably is
[14:42] <mdke> serverguide?
[14:48] <cody-somerville> the serverguide doesn't seem to be in the bazaar branch
[14:50] <cody-somerville> mdke, Shouldn't xml2po be in the make all rule?
[14:51] <cody-somerville> or atleast src-tarball?
[14:53]  * cody-somerville assumes you want update pot files when you create the src-tarball
[14:59]  * cody-somerville wonders if teamstuff needs to be in the xubuntu branch
[15:15] <cody-somerville> mdke, the dependency is:
[15:15] <cody-somerville> /usr/share/ubuntu-docs/common/prepare-firefox-startpage-translations
[16:49] <mdke> cody-somerville: no, we don't update pot files when building the source
[16:50] <cody-somerville> So how goes launchpad get the pot files again?
[16:50] <cody-somerville> *does
[16:50] <mdke> it imports them from the source package
[16:53] <mdke> cody-somerville: why did you remove build/ ?
[16:53] <cody-somerville> mdke, Because it isn't required
[16:54] <cody-somerville> mdke, When you tell it to build, it'll re-add it
[16:54] <mdke> but having it at least shows people where stuff is building
[16:55] <mdke> all the other branches use it...
[16:55] <cody-somerville> It is superfluous
[16:55]  * mdke shrugs
[16:56] <cody-somerville> I don't have a strong feeling about it
[16:56] <cody-somerville> I was just cleaning things up
[16:56] <cody-somerville> It should be as close to what I would take to package as possible
[16:56] <cody-somerville> IMHO
[16:57] <mdke> well, the branches *are* what you package
[16:57] <mdke> they build straight out of the branch, that's the whole point
[16:57] <mdke> I have no problem with cleaning up, but I'm just surprised you removed it while all the other branches use it
[17:04] <cody-somerville> Xubuntu continues to use it
[17:04] <cody-somerville> It just doesn't exist in the clean branch
[17:04] <mdke> cody-somerville: yes, I understand what you've done
[17:04] <mdke> dsas: thanks for the work on the browser homepage - works great
[17:05] <cody-somerville> mdke, Would you prefer that I put it back? :)
[17:07] <mdke> cody-somerville: I just think that having it there means that people will be aware of where they can find the html if they build it. It's not a big thing though
[17:08] <cody-somerville> I'll put it back because the clean rule in debian/rules deletes it for me anyhow
[17:10] <mdke> cody-somerville: thanks
[17:11] <cody-somerville> Pushed up to revision 3663.
[17:14] <cody-somerville> mdke, What do you think of my proposal to ubuntu-doc?
[18:21] <mdke> cody-somerville: I'm not sure about it
[18:28] <cody-somerville> The fact that I can't properly associate the package with a series is annoying
[18:28] <mdke> cody-somerville: does it prevent you from doing anything?
[18:29] <mdke> i think that launchpad eventually will support having more than one branch associated with a series
[18:29] <cody-somerville> It makes my life easier as a packager :)
[18:29] <mdke> cody-somerville: is there anything more than simply the lp: shortcut?#
[18:30] <cody-somerville> When I'm in the source package pages, I can quickly jump to the appropriate bazaar branch
[18:31] <mdke> cody-somerville: can a source package page not be linked to a branch which isn't associated with a series?
[18:31] <cody-somerville> Sadly, no
[18:31] <mdke> brb
[18:31] <cody-somerville> It has to do with bug reporting and stuff too
[18:31] <cody-somerville> launchpad is complicated
[18:31] <cody-somerville> but neat
[19:22] <mdke> cody-somerville: yes. It is doable I suppose, but I'm a bit sceptical about whether it is likely to cause any further fragmentation between the various branches
[19:23] <mdke> cody-somerville: also I'm concerned that a project which doesn't really exist outside of Ubuntu should have so many separate projects and even an umbrella project
[19:23] <mdke> cody-somerville: I just wonder whether the correct solution isn't to get Launchpad to support more than one branch per series
[19:23] <mdke> or open more series...
[19:24] <cody-somerville> You could get rid of the current model, yes.
[19:24] <cody-somerville> instead of by release, by derivative
[19:24] <mdke> or by both
[19:26] <cody-somerville> Why not just have separate products then?
[19:26] <mdke> because different projects means different urls, different teams associated, and more maintenance
[19:27] <cody-somerville> What maintenance do you have to do now?
[19:29] <mdke> cody-somerville: bug lists and release series, I guess
[19:29] <cody-somerville> Currently you can only manage the release series for Ubuntu's docs
[19:30] <mdke> that's right
[19:30] <cody-somerville> Launchpad was not designed to work this way
[19:30] <cody-somerville> Xubuntu docs and Ubuntu docs are separate products
[19:31] <cody-somerville> So there should be two products
[19:31] <cody-somerville> Branch ownership will remain the same, etc. etc.
[19:31] <mdke> that's where we differ
[19:31] <mdke> I think they aren't separate projects :)
[19:31] <cody-somerville> But we'll be able to take advantage of the launchpad infrastructure
[19:31] <cody-somerville> I'm not saying they're separate projects, mdke :)
[19:32] <cody-somerville> I'm saying they're separate products
[19:32] <cody-somerville> And thats why launchpad offers the super-project
[19:32] <mdke> that's just linguistics
[19:32] <mdke> Launchpad calls them projects though
[19:32] <cody-somerville> They have transitioned to that language, yes.
[19:33] <cody-somerville> How about I get some sleep before we discuss this further? :)
[19:33] <cody-somerville> Because I know what I want to say but I can't seem to get it out right
[19:34] <mdke> that's fine, I haven't made my mind up either
[19:34] <cody-somerville> mdke, Did you see the Xubuntu meeting announcement on the ml?
[19:34] <mdke> I don't think so
[19:35] <cody-somerville> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-March/003620.html
[19:35] <cody-somerville> It would be really cool if you could come
[19:37] <mdke> cody-somerville: I'll see, although i don't know much about xubuntu or its direction
[19:38] <mdke> what's the basic problem?
[19:38] <cody-somerville> Lack of direction
[19:38] <cody-somerville> :)
[19:39] <mdke> from your email it sounds like there are more than one competing directions
[19:40] <mdke> not too sure about the grammar of that, but you get the idea
[19:40] <cody-somerville> I would agree with that statement
[19:41] <mdke> about grammar?
[19:41] <cody-somerville> We have the "lets provide a lightweight desktop" crew and the "lets provide an xfce4 extremist desktop" crew
[19:41] <cody-somerville> no, about the competing directions
[19:41] <mdke> i see. is an xfce4 extremist desktop lighter than the first type?
[19:41] <mdke> or heavier?
[20:01] <cody-somerville> much lighter
[20:01] <cody-somerville> And buggier :(
[20:12] <mdke> cody-somerville: i understand
[20:13] <cody-somerville> I'd like Xubuntu to be useful
[20:13] <cody-somerville> So have community input (ie. not just xubuntu-specific people) would be a Good Idea (TM) IMHO
[20:14] <mdke> i'll see what I can do
[20:14] <cody-somerville> *having
[22:22] <mdke> sommer: what's the status of that new material for the serverguide?
[22:24] <sommer> working on it... do you mean the bacula section?
[22:24] <mdke> sommer: yeah
[22:24] <mdke>  far away?
[22:24] <sommer> ya... haven't started converting the wiki article to docbook yet
[22:24] <mdke> ah ok
[22:25] <mdke> sommer: did you see my email to the list about the test wiki for wiki->docbook conversion?
[22:25] <sommer> ya, haven't had much time to try it out though
[22:25] <mdke> that should quicken things up, you just need to run it through tidy afterwards... and last time I looked there were some problems with whitespacing
[22:25] <sommer> I usually do the conversion by hand, because it also allows for proof reading :-)
[22:26] <mdke> fair enough
[22:26] <sommer> the new section should be ready in a couple of hours at most
[22:26] <mdke> perfect
[22:26] <mdke> I was going to request an ubuntu-docs upload tomorrow
[22:26] <sommer> if for whatever reason it's not I'll let you know... definitely by tomorrow morning
[22:27] <mdke> no worries, if not possible we can upload the pot template manually to rosetta to start people working on it
[22:27] <sommer> there's still a couple of updates... installation section, likewise-open, and jeos section as well
[22:27] <mdke> I removed generic/server this evening
[22:27] <sommer> ya, noticed the commit message, cool
[22:27] <mdke> sommer: by update do you mean new material?
[22:28] <sommer> nope mostly corrrections/updates to commands
[22:28] <mdke> fine
[22:29] <mdke> looking pretty good for string freeze on thursday
[22:29] <sommer> the jeos section update may be some significant content though... it was orginally written with vmware in mind, but now jeos supports kvm really well
[22:29] <mdke> if only we can sort that dvd stuff out
[22:29] <sommer> ya, I was thinking that when I'm done with the server stuff I could take a look at it
[22:29] <mdke> isn't jeos a different flavour of Ubuntu to the server edition?
[22:29] <mdke> what's the relationship?
[22:29] <sommer> yes and no
[22:30] <sommer> jeos is a customized server edition flavour geared toward running as a virtualized guest os
[22:30] <sommer> basically it's only the drivers and software needed to load into vmware, qemu, kvm, etc
[22:30] <sommer> it's pretty cool stuff
[22:30] <mdke> and it is used as a server?
[22:31] <sommer> it can be no dooubt about it
[22:31] <mdke> interesting
[22:31] <sommer> doubt even
[22:31] <mdke> so it's like a virtual server :)
[22:31] <sommer> precisely
[22:31] <sommer> the total install is like 300M, or there abouts it's pretty slick
[22:32] <mdke> do you think it's better to be included in the serverguide, or as a separate document? is it something people running the server or desktop editions will use?
[22:32] <sommer> heh... I've wondered that myself
[22:33] <sommer> I think it can be either, but at this point I'd say mostly centered around server
[22:34] <mdke> so you can use it from one of those two editions?
[22:34] <mdke> or at least install it
[22:35] <mdke> the serverguide is pretty enormous right now so I'm just concerned to ensure everything is appropriately placed in there
[22:35] <sommer> sure, but the server edition has more virtualization optimizations then desktop, so it will probably run better using server
[22:35] <mdke> ok
[22:36] <mdke> it takes ages to load the doc in yelp :(
[22:36] <mdke> should the jeos section be inside the Virtualisation section?
[22:37] <sommer> maybe, but since there are so many subsections it's a little hard to navigate
[22:38] <mdke> it's a little hard to tell what it is from the title unless you know already
[22:39] <mdke> still, not a bit issue
[22:39] <mdke> big*
[22:40] <sommer> since it's getting pretty late in the game for hardy, do you want to leave it as is for now, and if there's need we can move it for ibex?
[22:41] <mdke> I guess it would be difficult to move it?
[22:42] <mdke> yes, let's leave it, we have enough to do
[22:43] <sommer> shouldn't be too bad, just changing sect1 > sect2; sect2 > sect3
[22:43] <mdke> argh
[22:44] <sommer> ?
[22:44] <mdke> i hate that stuff :)
[22:45] <sommer> heh
[23:08] <sommer> sigh... bacula package is still borded
[23:08] <sommer> borked even
[23:08] <sommer> mdke: when's the latest I can submit the new bacula section?
[23:08] <sommer> aside from the 20th :-)
[23:09] <sommer> mdke: at this point I'm thinking bacula section will have to wait for ibex
[23:53] <j1mc> mdke: are you around?