[00:01] <jelmer> hey poolie, fullermd
[00:02] <j1mc> hi - is there a bzr equivalent to 'git pull --rebase'?
[00:03] <LeoNerd> Possibly  bzr rebase ?
[00:03] <LeoNerd> Though not knowing quite what that  git pull --rebase  does I'm not sure
[00:04] <j1mc> git pull --rebase allows you to update your branch with the current commits before you push your own commits
[00:04] <j1mc> LeoNerd: unfortunately, there doesn't appear to be a bzr rebase command
[00:04] <LeoNerd> Well, the usual way to do that in bzr would be to merge trunk into your branch first
[00:04] <poolie> j1mc: the equivalent is 'bzr rewrite'
[00:04] <LeoNerd> You -can- rebase, but that's somewhat rude as it rewrites history
[00:04] <poolie> from the bzr-rewrite plugin
[00:04] <poolie> i don't know if there is a specific one-shot command to do that
[00:05] <LeoNerd> It's generally much nicer to merge from the trunk into the branch, so that branch merges back into the trunk afterwards
[00:05] <LeoNerd> It doesn't involve any history-rewriting that way
[00:05] <LeoNerd> But still, if you want rebase, you'll find it in the  bzr-rewrite  plugin
[00:05] <jelmer> j1mc: "bzr rebase" does the same thing as "git pull --rebase"
[00:05] <jelmer> as LeoNerd and poolie point out, that command requires the bzr-rewrite plugin
[00:07] <j1mc> thanks for your help, all. i will give the bzr-rewrite plugin a try.
[00:08] <maxb> jelmer: Hi. I have been bitten by the broken not-quite-dpushed commits in dulwich again.
[00:08] <maxb> I would like to suggest deleting lp:~dulwich/dulwich/trunk from existence so that they cannot propagate further
[00:09] <maxb> I am currently wondering if I should manually recommit the recent history of the dulwich bzr-ppa branches for hardy/jaunty/karmic to excise them
[00:10] <poolie> hi maxb
[00:10] <maxb> hello
[00:15]  * maxb hugs the lp api and lpshell
[00:16] <maxb> having just been able to do a loop over all ~bzr recipes calling r.distroseries.remove(karmic) on them all
[00:18] <maxb> hm
[00:18] <maxb> but it doesn't seem to have taken effect
[00:20]  * maxb is less impressed now
[00:21] <jelmer> poolie: Thanks for also looking at Vincent's config patches
[00:21] <jelmer> maxb: The same commits or different ones?
[00:21] <poolie> that's ok
[00:21] <poolie> do you want to talk about it?
[00:21] <poolie> i'm wondering if we should in fact do per-file configuration on the way i discussed in the overall mp
[00:21] <jelmer> maxb: please note that that branch is just a mirror of another one
[00:21] <maxb> jelmer: same ones causing problems in new scenarios
[00:21] <jelmer> maxb: So it's all old stuff?
[00:22] <maxb> jelmer: OK, let's delete all branches in the world with the dodgy commits :-)
[00:22] <knighthawk> I'm thinking a work around may be to just to add a working tree to A
[00:22] <knighthawk> but yeah fullermd that's my situation.
[00:23] <maxb> jelmer: 2011-01-14 is the most recent problem revision
[00:23] <jelmer> maxb: if it's all old commits I'm happy to delete and repush those branches, if there are new commits involved as well we should probably investigate further
[00:23] <jelmer> maxb: That's old enough for me :)
[00:24] <jelmer> poolie: I think the idea of mixing config and rules is interesting
[00:24] <poolie> if they're going to stay separate, i'd like to have a clear idea of why they're separate
[00:24] <poolie> beyond just 'rules are per-file'
[00:24] <maxb> I'm currently trying to decide whether it would be quicker to manually recommit the history for the bzr-ppa branches, vs. hack up reconcile with "where you see this text parent, change it to that one" logic
[00:26] <maxb> knighthawk: If you'd followed the exact sequence of commands you mentioned earlier, I don't see how you could have diverged branches
[00:26] <jelmer> poolie: My impression of it is that rules are things that could potentially apply to everybody accessing a particular branch
[00:26] <jelmer> whereas config is specific to a specific machine or user
[00:26] <jelmer> That's how I think of them at least, not sure if it necessarily makes sense.
[00:26] <maxb> knighthawk: Perhaps a pastebin of your console session would explain things best
[00:28] <knighthawk> maxb I did do a commit of new code in my branch before trying to do the pull from svn
[00:28] <poolie> that is true
[00:28] <jelmer> poolie: I realize that doesn't entirely match our current use, as we don't currently allow you to declare "doc/en/release-notes/*.txt" as changelog files that should be processed with the custom changelog merger
[00:28] <poolie> but perhaps they should just be different layers that stack together
[00:28] <maxb> knighthawk: In that case I think you misunderstand the nature of "pull"
[00:28] <poolie> perhaps it's too confusing if some are trusted and some not
[00:29] <maxb> knighthawk: "pull" is for making a local branch be identical to some remote one. Once you've committed stuff locally, that's no longer possible. You want to merge, I guess, instead.
[00:29] <knighthawk> maxb quite possible, I went ahead and created a working tree in 'A' now I'm going to try to merge 'A' and 'B'
[00:29] <jelmer> poolie: yeah, trust is indeed an interesting thing in this too
[00:30] <knighthawk> maxb I guess what I want to do is like a update of the local branch to the central repo before I try to commit my changes back into svn.
[00:31] <maxb> knighthawk: Right. "bzr merge svn+ssh://my.svn.server/svn/repository/project/trunk" for example
[00:32] <knighthawk> maxb can I just merge to a svn repo? (I don't know why but I assumed I couldln't do that)
[00:32] <maxb> No, because you can only merge into a working copy
[00:33] <knighthawk> ah. okay I just merged my changed from B into A so now I want to merge from the svn repo into A then do a commit (I think)
[00:37] <jelmer> poolie: food for thought :)
[00:37]  * jelmer gets some sleep
[00:37] <poolie> :) sleep well
[00:52] <spiv> jelmer: I'd like to update news_merge to use rules, actually
[00:53] <poolie> hi there spiv
[00:54] <poolie> so spiv, what do you think of unifying them?
[00:54] <stewart> help help! "permission denied" using 'bzr switch' ? http://paste.drizzle.org/show/481/
[00:54] <poolie> hi stewart
[00:54] <stewart> poolie, hi!
[00:55] <poolie> the eperm is a distraction just meaning you don't have a /var/crash or something
[00:55] <poolie> looks like https://bugs.launchpad.net/bzr/+bug/623152
[00:56] <stewart> huh...
[00:56] <poolie> > That traceback suggests the .bzr/branch/last-revision file is corrupt, probably blank. What does it contain?
[00:56] <stewart> poolie, it's 0 bytes long
[00:57] <stewart> poolie, so probably something that wasn't written out during one of the "damn laptop hung... probably due to intel wireless drivers" events last week
[00:57] <poolie> sorry, yeah
[00:57] <poolie> we should almost just fsync everything, except that would make things pretty slow for people whose machine aren't crashing
[00:57] <poolie> can you see if 'bzr reset-dirstate' fixes it?
[00:58] <stewart> poolie, unknown command... some plugin i'm missing?
[00:58] <poolie> ah it might only be in bzr 2.4
[00:59] <stewart> ahh.. .and i'm 2.3.1
[00:59] <poolie> do you have a lot of uncommitted work?
[00:59] <poolie> it might be faster to just make a new tree
[00:59] <stewart> poolie, no.
[00:59] <stewart> poolie, wiping away the checkout is fine.
[00:59] <poolie> i will update that bug to say there should be an easier way to recover
[00:59] <teratorn> does the windows installer support bzr+ssh urls out of the box?
[00:59] <teratorn> tortoisebzr?
[00:59] <poolie> teratorn: i think so yes
[01:00] <stewart> poolie, i have no problems with it fsyncing such things. nooo problem with that at all :)
[01:00] <poolie> maybe at least an option would be good
[01:00] <poolie> in fact an option that just globally fsync'd on close could be good
[01:00] <spiv> poolie: my understanding of the purpose of rules is the same as jelmer's
[01:00] <poolie> at least as 'fool me twice' prevention
[01:01] <poolie> that's my understanding too
[01:01] <spiv> well, versioned-in-tree config about that tree
[01:01] <poolie> however, i'm not sure we need a separate and somewhat parallel api to get it
[01:01] <spiv> It definitely has a lot in common with other kinds of config
[01:03] <spiv> We have perhaps slightly different concerns about versioning the format of rules vs configs, but in terms of API it sounds reasonable to have as much commonality as possible.
[01:03] <stewart> poolie, attempted new lightweight checkout for my working dir... http://paste.drizzle.org/show/482/
[01:04] <spiv> There is also a difference that in practice rules are used for per-file stuff, or at least 'per-thing in tree as matched by globs', and mostly other configs don't do that.
[01:04] <poolie> stewart ah the problem is actually in the branch not the tree
[01:05] <stewart> poolie, oh yeah, last-revision is empty there too
[01:05] <poolie> if that's your trunk, delete the branch directory
[01:05] <poolie> and pull from the server again
[01:05] <stewart> poolie, i have a mirror of it on lp...
[01:05] <stewart> (of that branch)
[01:05] <poolie> it's actually lost its idea of what the tip is
[01:05] <poolie> you don't need to delete the repo, only the branch
[01:05] <poolie> so it should be quite fast to fetch
[01:05] <stewart> yep. branch going away.
[01:07] <stewart> poolie, FYI it left the lightweight checkout dir in an odd state...just wiping it and trying again
[01:09] <stewart> poolie, question, is there any efficiency in packing binary data in the repo apart from simple compression? e.g. if we had X number of 10MB files that were *mostly* the same, would we get anything better than X*10MB disk usage?
[01:10] <poolie> yes you would
[01:10] <stewart> poolie, I'm wanting to have various InnoDB data files in the tree for backwards compatibility testing.
[01:10] <stewart> without having people whine at me that the repo is now 400MB :)
[01:10] <poolie> one caveat is that compression only hppens within pack files
[01:10] <poolie> so if you successively commit 10 additions of those files, you will have 10 pack files each ~10MB
[01:11] <stewart> poolie, i can deal with that. (i gather a repack would reclaim a lot of space)
[01:11] <poolie> however, the compression on the 10th commit should shrink them all into one pack somewhat less than 100MB
[01:11] <poolie> right
[01:11] <stewart> 10x10MB files with only about 1MB difference should be closer to 20MB on disk than 100MB
[01:11] <lifeless> stewart: yes, thats right. Do an experiment :)
[01:11] <stewart> nice :)
[01:12] <stewart> we were discussing if we would gzip these in tree or not, rather convinced we should just store them in there now.
[01:12] <stewart> it turns out some people care not to have to sql dump and restore their database :)
[01:15] <poolie> bzr will be able to compress them better if they're not individuall gzipped
[01:15] <poolie> which will hide any similarities
[01:16] <lifeless> lp stores a SQL dump of some MBs of data in tree
[01:16] <lifeless> it compresses pretty well
[01:16] <lifeless> its a tad fugly, but if you need it you need it.
[01:17] <lifeless> I would suggest having it in a dedicated tree perhaps
[01:19] <poolie> that sounds like a good idea
 This fixes a bug that Mark Shuttleworth pointed out to me (bug #765881)
[01:43] <poolie> nice
[02:06]  * spiv gives his wireless router a kick
[02:36] <poolie> stewart also https://bugs.launchpad.net/bzr/+bug/766735
[02:36] <poolie> spiv do you have any ideas about https://bugs.launchpad.net/bzr/+bug/721163
[02:43] <spiv> poolie: hmm, no
[02:44] <spiv> poolie: I think we need the server-side log
[02:44] <spiv> I can't think of any likely causes, and I don't think any hooks are triggered by insert_stream so it's unlikely to be a buggy plugin
[03:06] <poolie> so can you say so?
[03:36] <spiv> Sure.
[06:16] <johnf> Is it possible to find all the dangling revisions in a repository created by uncommit?
[06:18] <lifeless> bzr heads --all
[06:19] <KombuchaKip> Is there any way to setup a post commit hook for bzr to send an email when using it with Launchpad?
[06:20] <johnf> lifeless: cheers
[06:20] <lifeless> KombuchaKip: if your branch is on launchpad you can just click on subscribe in the UI
[06:20] <poolie> KombuchaKip: the people interested in the branch can just subscribe to it in lp
[06:20] <poolie> or you can use bzr-email
[06:20] <poolie> o/ johnf
[06:20] <lifeless> KombuchaKip: if you want the mail sent to a list, you can subscribe a team with a contact address of the mailing list (or the team itself if its a launchpad hosted list) and LP will mail that directly.
[06:21] <KombuchaKip> poolie: I'd like to use bzr-email, but not sure if you can use that with launchpad since you won't have access to server?
[06:21] <KombuchaKip> lifeless: Thanks. I think that's what I will do.
[06:21] <poolie> it runs on the client
[06:21] <poolie> sending it from lp seems easier
[06:24] <KombuchaKip> poolie: Thanks.
[06:39] <KombuchaKip> This is always a friendly and helpful channel.
[07:07] <poolie> thanks
[07:09] <maxb> poolie: Thanks for the pointer to deryck's bzr issue. As it turned out, it was actually a launchpad-specific bzr plugin that was at fault, so no problem for us on the #bzr side of things :-)
[07:11] <poolie> o/ bialix
[07:12] <poolie> hooray
[08:58] <poolie> spiv, jelmer, jam, hi?
[08:58] <jam> hi poolie
[08:58] <jam> "Are you ready to Muuuummblllllllllleee" ?
[08:59] <jam> (said w/ a WWE announcer voice)
[08:59] <poolie> :) :)
[09:00] <poolie> be back in a sce
[09:08]  * jelmer is still setting up
[09:21] <spiv> poolie, jelmer, jam: damn, forgot what day it was
[09:22] <poolie> np, want to join us now?
[09:22] <spiv> Ok
[09:26] <jam> spiv: pack retry attacked back
[09:34] <jam> poolie: this one? https://wiki.canonical.com/Bazaar/Plan/2011
[10:02] <jam> spiv: yeah, we don't hear you
[10:33] <poolie> jam re bug 746237 i was just going to check if there's a new bug
[10:34] <jam> poolie: sure
[10:34] <jam> I don't think there is a new one
[10:35] <poolie> i'll do a pass over all of ~mbp inprogress today or tomorrow
[10:40] <jam> poolie: what is our current 'bug fix' policy
[10:40] <jam> it should always target 2.3?
[10:40] <jam> or 2.2?
[10:40] <jam> or ...?
[10:40] <jam> I have a fairly trivial fix for bug #760152 which I can backport as far as we want
[10:40] <jam> the main issue is just how much effort do we want to spend merging-up
[10:41] <poolie> serious bugs with safe fixes in 2.1
[10:41] <poolie> bugs worth fixing with safe fixes in 2.3
[10:41] <poolie> i guess
[10:41] <poolie> 2.0 basically dead except by request
[10:42] <poolie> iow i think the safety bar is equally high
[10:42] <poolie> but, merging into 2.1 is a bit more work, so we should only do it when we specifically think it'll please someone
[10:42] <jam> poolie: sure. I guess my issue here is how to handle the merge-up and the RELEASE NOTES
[10:42] <poolie> on lts
[10:42] <poolie> right
[10:54] <jam> Yay, closing a 4-digit bug
[10:54] <jam> bug #5135
[10:55] <jam> I tested it, and it works fine here
[10:55] <jam> ubot5: you're getting slow, man
[10:57] <poolie> way to go!
[10:57] <poolie> if there were badges, you would get at least a silver one
[11:05] <jam> poolie: well, closed because it has already been fixed. But still feels good.
[11:14] <jelmer> :)
[11:21] <poolie> maybe we should just make a web page with badges if we can't do it automaticaly
[11:33] <spiv> poolie: or a greasemonkey script?
[12:02] <jelmer> spiv: if you're still around and interested, we're having a udd meeting #ubuntu-meeting
[12:03] <jelmer> *in
[12:03] <poolie> jam: hi?
[13:50] <mrevell-lunch> Morning/nick mrevell
[13:51] <mrevell-lunch> sorry
[13:51] <mrevell> :)
[14:23] <jkakar> Hi ntoll! :)
[14:23] <ntoll> hi jkakar
[14:23] <ntoll> fancy seeing you in here ;-)
[14:23] <jkakar> ntoll and I have discovered something funky in our branches...
[14:23] <jkakar> We have trunk, staging and production branches, each of which is meant to be older than the last (and we're careful with merges).
[14:24] <jkakar> We have a situation where production doesn't contain content in a file that, after carefully analyzing the logs, we think should be there.
[14:24] <jkakar> So I ran 'bzr check' and got this:
[14:24] <jkakar>   3838 revisions
[14:24] <jkakar>   1360 file-ids
[14:24] <jkakar>      3 inconsistent parents
[14:24] <jkakar> I'm wondering what '3 inconsistent parents' means...?
[14:24] <jkakar> Could it be that some flummox in merging could have removed the content we expect...
[14:25] <jkakar> For example, I seem to remember reverting a revision could produce strange results when you merged it back...?
[14:26] <jkakar> abentley: ^^ Any ideas?
[14:39] <abentley> jkakar: No, inconsistent parents are mostly harmless.  They are usually due to ghost revisions or bzr bugs.
[14:39] <jkakar> abentley: Okay, thanks. :)
[14:40] <jkakar> abentley: I guess bzr bugs are mostly harmless? ;b
[14:40] <jkakar> abentley: Anyway, I think we figured out the issue is an EPEBKAC error. :)
[14:40] <abentley> Ah, okay.
[14:40] <jkakar> abentley: Thanks for your feedback, much appreciated... these kinds of "WTF?" moments are always a bit scary. :)
[14:42] <abentley> jkakar: no problem.
[14:43] <fullermd> I think 'reconcile' will often fix inconsistent parents.
[14:44] <jkakar> fullermd: Yeah, I was wondering about it... but 'bzr help reconcile' says, "You should only need to run this command if 'bzr check' or a bzr developer advises you to run it."
[14:44] <jkakar> fullermd: Neither of those things happened so I didn't run it.
[14:47] <maxb> What exactly is an "inconsistent parent"? Is this described anywhere?
[14:47] <jkakar> maxb: I was wondering the same... I couldn't easily find anything about it.
[14:49] <maxb> I gather it's something to do with consistency between the overall revision graph and the ancestry attributed to individual files
[14:50] <jkakar> maxb: I gathered the same, yeah.
[15:39] <diwic> What do I do about this: "bzr bd" gives error "Unable to determine the previous upload for --package-merge"?
[15:43] <james_w> diwic,  "bzr branch lp:bzr-builddeb /tmp/builddeb; BZR_PLUGINS_AT=builddeb@/tmp/builddeb bzr bd"
[15:44] <diwic> james_w, iow this is a known bug that is fixed in trunk?
[15:44] <james_w> diwic, indeed
[15:45] <diwic> thanks!
[17:56] <knighthawk> I've seen a few places that mention rebase. perhaps as a solution to my problem committing to svn. But when I try to run 'bzr rebase' or 'bzr help rebase' it says it doesn't exist. am I doing something wrong?
[17:57] <niemeyer> Hey there
[17:57] <knighthawk> looks like I'm running bzr 2.1.1-4
[17:57] <jelmer> knighthawk: rebase is in the bzr-rewrite plugin
[17:57] <niemeyer> Getting some issues with bzr-fastimport related to an AttributeError on _find_ancestors
[17:57] <knighthawk> jelmer thanks
[17:57] <niemeyer> On natty, specifically
[17:58] <niemeyer> Is that a known issue?
[17:58] <jelmer> hi Gustavo
[17:58] <jelmer> niemeyer: it sounds vaguely familiar - can you pastebin the backtrace?
[17:58] <niemeyer> jelmer: Hi!
[17:58] <niemeyer> Sure
[17:58] <niemeyer> jelmer: http://pastebin.ubuntu.com/596621/
[18:01] <jelmer> niemeyer: thanks
[18:01] <jelmer> niemeyer: it's indeed something I've seen before
[18:03] <jelmer> https://bugs.launchpad.net/bzr-fastimport/+bug/541626
[18:05] <jelmer> I'm not too familiar with the index code, perhaps John can comment on it tomorrow.
[18:05] <jelmer> it looks shallow
[18:07] <niemeyer> jelmer: Cool, thanks
[18:40] <mgz> jelmer, did you have a branch that had some code doing isinstance(revision_id, basestring) up for review? I now can't find the mp and think I may have imagined it.
[18:41] <jelmer> mgz: perhaps the branch that forbade using None as alias for "null:" in Branch.set_last_revision_info() ?
[18:42] <mgz> maybe. do you have a link? I meant to ask whether said variable should actually be bytes or unicode.
[18:42] <jelmer> mgz: that was inspired by some other code in bzrlib.revision that did the same thing IIRC
[18:43] <mgz> I thought it was one of the ones removing the inventory stuff and switching a param to be a tree or something instead
[18:43] <jelmer> tjatlp:~jelmer/bzr/testament-tree ?
[18:43] <jelmer> that's lp:~jelmer/bzr/testament-tree ?
[18:44] <jelmer> bzrlib.revision.is_reserved_id() checks against basestring
[18:46] <jelmer> mgz: it happens in more places, e.g. Repository._iter_revisions
[18:46] <mgz> must have confused two different diffs. I've not been keeping up with for coding. :)
[21:44] <ironmagma> does bzr require you to download the whole repository history, like git/hg do?
[21:45] <Odd_Bloke> ironmagma: You can use lightweight checkouts, which do not.
[22:06] <knighthawk> svn users aren't too happy with me right now, somehow I blew away the svn history for a few days with my push. is this because in my ~/.bazaar/suvbersion.conf I added append_revision_only = False?
[22:07] <lifeless> push shouldn't even be destructive, unless you used --overwrite
[22:07] <lifeless> s/even/ever/
[22:07] <knighthawk> did *not* use overwrite
[22:07] <lifeless> jelmer: ^ around ?
[22:10] <knighthawk> I did a bzr merge to merge my working tree to what was supposed to be the latest version of the svn repo (only it seems it wasn't) then I commited my changes and tried to do a push that didn't work until I added append_revision_only = False but then it seems I blew up some stuff. I've since installed bzr-rewrite and now I'm trying rebase instead of append_revision_only = False. but since I'm not *sure* that's what created the problem I'm not sure if I'm
[22:10] <knighthawk>  going to do it again.
[22:12] <lifeless> yeah, I can understand that
[22:12] <lifeless> sadly, I've only used bzr svn a very few times myself, so I don't really have a clue about whats up there
[22:17] <jelmer> re
[22:18] <jelmer> hi lifeless, knighthawk
[22:19] <knighthawk> hey jelmer
[22:19] <jelmer> knighthawk: yes, if you set "append_revisions_only = False" that means bzr-svn will push even if that removes existing revisions from the mainline (the revisions are still in the repository, just not in the mainline of the branch)
[22:20] <jelmer> knighthawk: The default of append_revisions_only=True is intended to prevent you from shooting yourself in the foot
[22:21] <knighthawk> jelmer, okay it *sounds* like now that I have bzr-rewrite working I can use rebase and don't need append_revision_only=False anymore (I think)
[22:21] <jelmer> knighthawk: you can restore the old mainline using either "svn cp -r ..." or "bzr push --overwrite ..."
[22:22] <jelmer> knighthawk: right, rebase will preserve the upstream branch mainline
[22:22] <knighthawk> jelmer sorry I'm not sure what is meant by mainline is that the trunk?
[22:22] <jelmer> knighthawk: mainline are basically the revisions shown by "bzr log -n1"
[22:22] <jelmer> knighthawk: non-mainline revisions will be shown too if you use "bzr log -n0"
[22:31] <knighthawk> thanks jelmer that clears up a lot. but now did I just destroy my changes of restoring the mainline by running rebase?
[22:32] <jelmer> knighthawk: it depends on what exactly you rebased


[00:05] <KGB-1> gdm ubuntu/master f740f4b Marco Trevisan * pushed 27 commits (first 5 follow) * https://deb.li/LuVl
[00:05] <KGB-1> gdm ubuntu/master c01efbc Simon McVittie debian/changelog * Merge branch 'debian/unstable' into debian/master * https://deb.li/31DlI
[00:05] <KGB-1> gdm ubuntu/master 88a04bb Simon McVittie debian/watch * Revert "debian/watch: Monitor unstable versions" * https://deb.li/3pxgE
[00:05] <KGB-1> gdm ubuntu/master 1d8ebd2 Simon McVittie debian/upstream/metadata * d/upstream/metadata: Add * https://deb.li/iQIIe
[00:05] <KGB-1> gdm ubuntu/master af4a4da Simon McVittie debian/changelog * Release to unstable * https://deb.li/wu5G
[00:05] <KGB-1> gdm ubuntu/master 4634783 Felix Yan daemon/gdm-x-session.c * Correct a typo in gdm-x-session.c * https://deb.li/d1Fs
[01:01] <callmepk> good morning
[01:05] <duflu> Morning callmepk
[01:05] <callmepk> morning duflu
[04:50] <jibel> Good morning
[04:59] <callmepk> hey jibel
[05:01] <duflu> Hi jibel
[05:01] <jibel> hi duflu callmepk
[06:27] <ricotz> good morning desktopers!
[06:28] <ricotz> could someone restart https://launchpad.net/ubuntu/+source/libreoffice/1:7.0.2-0ubuntu1/+build/20144206
[06:28] <ricotz> this looks pretty much stuck
[06:28] <oSoMoN> good morning desktoppers
[06:29] <ricotz> oSoMoN, hey
[06:29] <oSoMoN> ricotz, I just cancelled, I'll restart it
[06:29] <ricotz> oSoMoN, ty
[06:32] <oSoMoN> done
[06:42] <didrocks> good morning
[06:42] <duflu> Morning ricotz, oSoMoN, didrocks
[06:48] <didrocks> hey duflu
[06:49] <oSoMoN> salut didrocks
[06:49] <oSoMoN> hey duflu
[06:58] <didrocks> salut oSoMoN
[07:14] <marcustomlinson> morning callmepk duflu jibel ricotz oSoMoN didrocks and ye other desktoppers
[07:15] <duflu> Morning marcustomlinson
[07:16] <didrocks> hey marcustomlinson
[07:32] <jibel> Salut didrocks marcustomlinson and all
[07:36] <callmepk> hey marcustomlinson
[07:36] <callmepk> and morning ricotz oSoMoN duflu
[07:37] <duflu> Umm, afternoon callmepk
[07:37] <duflu> for both of us
[07:38] <duflu> Unless you follow https://www.google.com/search?q=universal+greeting+time
[07:39] <didrocks> salut jibel
[07:40] <oSoMoN> good morning marcustomlinson, salut jibel, good afternoon callmepk
[07:41] <seb128> hey ricotz , duflu , marcustomlinson
[07:41] <seb128> lut jibel , didrocks , oSoMoN
[07:41] <seb128> how are you?
[07:41] <seb128> oh and hey callmepk, almost forgot you :-(
[07:42] <jibel> Salut seb128
[07:42] <oSoMoN> salut seb128, ça va, et toi?
[07:42] <jibel> good as usual :)
[07:42] <jibel> ready for a new release in a week
[07:42] <duflu> Hi seb128
[07:44] <seb128> oSoMoN, ça va bien, j'ai réussi à dormir jusqu'à 7h sans être réveillé et mon rhume est presque passé :-)
[07:44] <oSoMoN> \o/
[07:45] <didrocks> salut seb128
[07:50] <callmepk> duflu oops
[07:51]  * callmepk needs more coffee
[08:02] <Laney> hey ho
[08:02] <seb128> didrocks, jibel , oSoMoN , une idée du vocable usual pour 'directory' en context d'AD en français ?
[08:02] <seb128> les suggestions actuelles sur launchpad sont
[08:02] <seb128>  S'authentifier auprès d'un répertoire
[08:03] <seb128>  Authentification d'après un dossier
[08:03] <seb128> unsure translators got the 'directory' was in AD context
[08:03] <seb128> (I assume it is since it's untranslated)
[08:03] <seb128> hey Laney , how are you today?
[08:04] <oSoMoN> hey ho Laney
[08:05] <oSoMoN> seb128, "annuaire"?
[08:06] <didrocks> I would have said annuaire as well
[08:06] <didrocks> you say "annuaire LDAP" for instance
[08:07] <seb128> maybe it's worth adding some # gettext context next to the string next time you do an editor around there
[08:07] <didrocks> there is no AD in that string?
[08:07] <seb128> didrocks, oSoMoN , thanks, I will go with annuaire, sounds fine to me
[08:07] <seb128> 'Authenticate against a directory'
[08:07] <seb128> is the string
[08:08] <jibel> seb128, I wouldn't translate "Active Directory" it's a product. Do you have a link to the sentence that contains only "directory"?
[08:08] <didrocks> yeah, some gettext context would help
[08:08] <jibel> otherwise "Annuaire" is correct
[08:10] <seb128> jibel, https://git.launchpad.net/ubiquity/tree/debian/ubiquity.templates#n1647
[08:11] <seb128> jibel, didrocks, oSoMoN , 'S'authentifier auprès d'un annuaire' ?
[08:11] <jibel> oui
[08:11] <seb128> merci
[08:12] <jibel> but it doesn't really matter this string is not displayed in the UI it's just a debconf entry to store whether we use AD or not
[08:13] <seb128> ah ok
[08:13] <jibel> the way ubiquity is done all the strings are stored in debconf and there is not really a way to distinguish what is really displayed and what is not
[08:14] <jibel> OTOH if you don't write a description in the template you're quickly lost
[08:24] <duflu> Oh I forgot to look... seb128, jamesh, did you find out why pulseaudio 13.99.2 was tagged?
[08:25] <seb128> duflu, tagged you mean?
[08:25] <duflu> why it exists
[08:25] <duflu> There is no recent NEWS
[08:25] <jamesh> duflu: no idea.
[08:25] <duflu> Maybe I will diff it later and look for interesting things
[08:26] <jamesh> duflu: there is a release tarball at https://freedesktop.org/software/pulseaudio/releases/
[08:27] <duflu> jamesh, yeah but the NEWS file is untouched
[08:27] <duflu> Maybe it will be in 14.0
[08:27] <jamesh> duflu: it wasn't updated for 13.99.1 either.  Perhaps due to treating them as pre-releases
[08:27] <duflu> yep
[08:28] <jamesh> there's nothing in there for the 12.99.x releases either
[08:32] <seb128> duflu, I did the update in Debian and merged to Ubuntu, I used the upstream tarball
[08:32] <seb128> but I've no idea how they handle NEWS and tags
[08:32] <seb128> afaik the update is correct though
[08:32] <duflu> seb128, yeah it looks good. Just wondering why the point release now
[08:33] <duflu> I guess as a release candidate or whatever it makes sense
[08:33] <seb128> it's a new rc on their way to get a stable out
[08:33] <seb128> the changes seemed to make sense for us as well
[08:33] <seb128> mostly fixes
[08:37] <marcustomlinson> hey jamesh
[08:37] <jamesh> hi marcustomlinson
[08:51] <juliank> tkamppeter: Reading https://www.linux-magazin.de/news/ist-die-cups-entwicklung-eingeschlafen/ made me look at cups and get scared at its upstream state. Apple dumped one release on github in April and ignores anything going on in the repo. scary
[08:54] <tkamppeter> juliank, I do not know whether you followed my weekly updates for my Canonical work, on https://discourse.ubuntu.com/c/desktop/team-updates and my monthly news posts on OpenPrinting, https://openprinting.github.io/news/ where I already mentioned the situation.
[08:55] <juliank> tkamppeter: No I don't I just got scared this morning :) But I see now a https://github.com/OpenPrinting/cups fork
[08:55]  * juliank is happy
[08:56] <tkamppeter> We (Michael Sweet and me) finally came up to do a fork of CUPS on the OpenPrinting GitHub, https://github.com/OpenPrinting/cups
[08:56] <tkamppeter> Yes, you have seen it.
[08:57] <juliank> tkamppeter: Yeah I found it via your openprinting link :D
[08:58] <juliank> I love how it says (temporary)
[08:58] <juliank> in the September blog post
[08:59] <tkamppeter> There is also a thread on https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1212363-cups-printing-system-open-source-development-has-seemingly-dried-up
[08:59] <tkamppeter> I have answered to all the doubts of the poster and the users who have answered before me.
[09:00] <tkamppeter> For me it more and more looks like that the "(temporary)" was wrong and will disappear in later mentions on OpenPrinting ...
[09:01] <juliank> So we'll end up with two "C"UPS
[09:01] <juliank> One that Apple uses, and one that everyone else uses
[09:01] <juliank> It'll be fun
[09:01] <tkamppeter> This is currently my biggest fear, as I am already doing a lot for printing and if I also have to maintain CUPS upstream ,...
[09:01] <tkamppeter> Seems so.
[09:03] <tkamppeter> Or Apple has quit CUPS and on their new ARM Mac generation they will do without, but see on Launchpad, or on Debian, or on anybody's Raspberry Pi or other SBC, CUPS WORKS ON ARM!!
[09:04] <tkamppeter> Something like 10 or more years ago I got a Nexus 7 tablet on a UDS, installed a complete Ubuntu Desktop on it, including CUPS and HPLIP and it printed perfectly on an HP inkjet, connected via USB OTG cable.
[09:05] <Laney> tkamppeter: I thought Mike Sweet worked for apple, or no?
[09:05] <juliank> I expect Apple builds like new printer driver framework and kills of support for old drivers one macOS release later :)
[09:06] <juliank> Or they say "screw that, we only support AirPrint now, and have a minimal thing to make that work"
[09:07] <juliank> Laney: he did until nov
[09:07] <juliank> 2019
[09:07] <Laney> I see
[09:07] <Laney> probably a sign ;-)
[09:08] <juliank> oh dec 20
[09:15] <jamesh> juliank: didn't they already come up with a new driver framework that is essentially "implement an IPP server"?
[09:15] <juliank> jbicha: yes pappl
[09:16] <jamesh> at which point your printing framework is essentially an IPP multiplexer with some queuing logic.  It's not clear how much of classic CUPS you'd need
[09:17] <tkamppeter> Laney, he left in the beginning of this year and created his own company, Lakeside Robotics in Canada, it is all about 3D printing.
[09:17] <Laney> CU3PS
[09:18] <juliank> NUPS
[09:18] <juliank> s/common/new/
[09:18] <juliank> :D
[09:18] <juliank> or SUPS
[09:18] <juliank> The simple unix printing system :D
[09:19] <tkamppeter> jamesh, yes, as Mike was still at Apple he created the idea of Printer Applications, first mention on OpenPrinting Summit April(May?) 2018.
[09:19] <tkamppeter> He already deprecated PPD files more than 10 years ago but did not have an idea to replace them.
[09:21] <tkamppeter> With driverles IPP printing (AirPrint is one flavor of this) he came up with Printer Applications, an IPP server on a computer (usually local) emulating an IPP network printer with all pipes and whistles (print, scan, fax, web admin).
[09:22] <tkamppeter> In the beginning there was only printing and the web admin interface, but the PWG created also IPP Scan for driverless scanning and this made me introducing the concept of Scanner Applications and so getting a new snappable scanning architecture for Linux.
[09:22] <tkamppeter> Now to students are implementing it.
[09:23] <tkamppeter> And, PAPPL is not a spooler, nor a general network print server.
[09:23] <tkamppeter> PAPPL is a library for easy creation of Printer and Scanner applications.
[09:23] <jamesh> Right.  But if you're not pushing IPP as the API applications use to submit jobs, it doesn't sound that crazy to replace the multiplexer/queue daemon.
[09:24] <tkamppeter> CUPS is still needed, to spool, to turn incoming PDF into the format the printer (or Printer Application) needs, shares printers on network.
[09:26] <tkamppeter> If print dialogs would support IPP disrectly (instead of using a CUPS API) one can theoretically print without CUPS, but it is awkward, first you have no spooling, dialog blocks until printer has swallowed all the data.
[09:26] <tkamppeter> Second, only printers or Printer Applications which accept PDF as input format will work.
[09:27] <jamesh> If the operating system's printing API involves driving a graphics context (i.e. whatever is Apple's equivalent of a cairo context), there's not much reason to go through PDF or PS as an intermediate.  You could just render straight to Apple or PWG raster
[09:28] <jamesh> so the multiplexer wouldn't necessarily need to be in the business of format conversion
[09:28] <tkamppeter> We could theoretically let print dialogs spool or output alternative formats to PDF, but this is the task of the operating system and for this the operating system Linux (and anything else which is not Mac or Windows) uses CUPS.
[09:33] <tkamppeter> Also, who will implement changes in the print dialogs? For years I struggled with print dialog developers and GSoC students to get print dialogs simply using the latest CUPS API so that they at least support CUPS' temporary queues.
[09:34] <tkamppeter> I need volunteers!! contributors!!
[09:40] <jamesh> Sure.  I was more speculating about why Apple might cut CUPS loose once all the esoteric details were hidden behind the printer application framework
[11:31] <Laney> anyone remember if there is a gsetting or something to disable the suspend option? something something logind?
[11:31] <Laney> apparently the pi allows you to suspend but that breaks it, would like to at least turn off the options
[11:36] <seb128> Laney, try https://bugs.launchpad.net/ubuntu/+source/policykit/+bug/1300460/comments/3 ?
[11:58] <Laney> yesssss
[12:00] <Laney> thanks seb128!
[12:01] <seb128> Laney, np!
[12:06] <waveform> Laney, that works very nicely! (even seemed to work *before* a reboot)
[12:12] <Laney> waveform: nice
[12:12] <Laney> can you do a merge proposal for https://code.launchpad.net/~ubuntu-desktop/ubuntu/+source/ubuntu-settings/+git/ubuntu-settings to add those?
[12:12] <waveform> Laney, will do
[12:12] <Laney> cheers
[13:57] <hellsworth> good morning desktopers
[13:57] <oSoMoN> good morning hellsworth
[13:58] <kenvandine> good morning hellsworth
[13:58] <hellsworth> hi there oSoMoN , kenvandine :)
[13:59] <seb128> hey Heather! how are you?
[14:00] <jibel> Good morning hellsworth
[14:01] <hellsworth> o/ seb128 jibel i'm good thanks :)
[14:13] <KGB-0> gdm ubuntu/master ec9e9f7 Marco Trevisan (Treviño) debian/changelog * Update changelog * https://deb.li/3VX20
[14:17] <marcustomlinson> hey hellsworth and kenvandine
[14:17] <hellsworth> sup marcustomlinson
[15:01] <waveform> Laney, as requested - https://code.launchpad.net/~waveform/ubuntu/+source/ubuntu-settings/+git/ubuntu-settings/+merge/392237
[15:04] <Laney> merci merci
[15:06] <Laney> waveform: you mentioned some other uploads, are you ok for sponsorship for those e.g. from sil2100?
[15:07] <sil2100> o/
[15:09] <waveform> yes - I've got the flash-kernel one ready ... erm ... <goes looking>
[15:24] <seb128> waveform, you have a netplan change in there that seems unrelated?
[15:25] <waveform> seb128, ah I must've left in my confused "what is that operator?" experiment - it's a null-change - doesn't affect the built deb
[15:25] <seb128> right, still it's a different logical change and is undocumented
[15:25] <waveform> I'll push a commit updating the changelog - thanks
[15:26] <seb128> thanks
[15:27] <waveform> done - do you need me to rebuild the test package in the PPA or is the MP enough?
[15:29] <seb128> the MP is enough
[15:29] <seb128> well, I trust it is, I was not going to sponsor but I'm just sil2100  or Laney  whoever does the sponsoring don't need the ppa
[15:30] <Laney> yeah, not needed
[15:31] <Laney> using the / operator there is really not necessary, it would be ok to drop it in a separate commit if you wanted (but fine either way)
[15:33] <waveform> yeah - I've never used meson so I was mostly interested in exactly what it did, but also why it was different from the subsequent line so tried a test build with it changed to a regular string while I went digging into the docs for the "Right Way (tm)" to do things in meson
[15:34] <waveform> (and was then amused to learn it's literally just (paraphrasing) "inserts a / on all platforms" - so not even python's /-operator in pathlib :)
[15:39] <Laney> heh
[15:39] <Laney> it's nice if one side of it is a variable
[15:47] <waveform> certainly, especially if you're not sure about "/" prefixes or suffixes in the things being joined
[15:59] <juliank> So, custom keybindings are lost in GNOME right now from time to time, like they're not reapplied after screen lock or sth
[15:59] <juliank> Do you guys know a bug report for that already?
[16:00] <juliank> oh this I guess https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1893729
[16:00] <juliank> but I thought I reverted
[16:00] <juliank> it's at 3.38 now
[16:02] <Laney> It's not that, that was a mismatch between different GNOME components, doesn't happen now they are all in sync
[16:02] <Laney> that particular bug should be closed
[16:27] <Laney> waveform: I'm going to just tweak your MP to follow https://www.freedesktop.org/software/polkit/docs/0.105/pklocalauthority.8.html and install to /var/lib/polkit-1/localauthority/10-vendor.d/ but then I will upload
[16:30] <waveform> Laney, okay - thanks!
[19:13]  * ricotz eyes on https://launchpad.net/ubuntu/+source/libreoffice/1:7.0.2-0ubuntu1/+build/20144206
[19:15] <ricotz> this flaky test is not meant to fail on this arch :\ -- could someone retry it, please ^
[19:30] <ginggs> ricotz: .
[19:31] <ricotz> ginggs, cheers
[19:41] <ginggs> ricotz: yw!


[08:24] <os2mac> any chance someone here can help get me unbanned from the Ubuntu channels now that I have fixed my connection?
[08:25] <rww> os2mac: which channels? If you mean #ubuntu, #ubuntu-offtopic, or other core channels, you want #ubuntu-ops
[19:17] <vish> Pici: the discussion seems to be offtopic on +1 , if i'm not mistaken?  wouldnt -offtopic be a better place?
[19:21] <persia> vish: +1 tends to drift a bit on the weekends.  As long as it drifts back soon enough, no worries.
[19:21] <vish> persia: P_ici just got it back in control :)
[19:21] <Pici> It was getting a bit out of control.
[19:22] <persia> If there are people really trying to exchange hints & tricks that are being disturbed, then yeah, that's bad.
[19:22] <Pici> Going on about buttons and ppas...
[19:22] <persia> Yeah, that's a bit off.
[19:22] <vish> ppa security .. was really being meh topic ;p


[21:59] <ogra_> moo
[22:00] <NCommander> #startmeeting
[22:00] <MootBot> Meeting started at 16:00. The chair is NCommander.
[22:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[22:00]  * GrueMaster grunts in acknowledgement.
[22:01] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090507
[22:01] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090507
[22:01] <NCommander> [topic] Action Items Review
[22:01] <MootBot> New Topic:  Action Items Review
[22:01] <NCommander> [topic] NCommander to investigate #338148
[22:01] <MootBot> New Topic:  NCommander to investigate #338148
[22:02] <NCommander> Poked it with a stick, VNC4's package is ... strange. Will see about solving after karmic kernel is descrewed.
[22:02] <NCommander> [topic] lool to spec ec2-package-builder for karmic
[22:02] <MootBot> New Topic:  lool to spec ec2-package-builder for karmic
[22:03] <GrueMaster> isn't he out on holiday?
[22:03] <ogra_> lool is on holiday
[22:03] <NCommander> Oh
[22:03] <NCommander> [topic] #
[22:03] <NCommander> GrueMaster to test newer version of Hildon Desktop to see if it resolves cat kills MID bug (co)
[22:03] <MootBot> New Topic:  #
[22:03] <GrueMaster> co
[22:03] <NCommander> [topic] NCommander and GrueMaster to debug #337809
[22:03] <MootBot> New Topic:  NCommander and GrueMaster to debug #337809
[22:04] <NCommander> (I believe thats the APIC 0 issue, LP is currently timing out for me)
[22:04] <ogra_> yes it is
[22:04] <ogra_> according to the roadmap
[22:04] <GrueMaster> yes it is.  CO.  I've been focusing on other issues this week.
[22:04] <NCommander> Same here
[22:04] <NCommander> [topic] StevenK to follow up with Tim on lpia kernel configuration
[22:04] <MootBot> New Topic:  StevenK to follow up with Tim on lpia kernel configuration
[22:05] <ogra_> hmm, no StevenK
[22:05]  * NCommander just noticed
[22:05]  * NCommander will note ATM I'm half dead :-/
[22:06] <ogra_> can you ping him in the other channel ?
[22:06]  * ogra_ is in another machine atm
[22:06] <ogra_> *on
[22:06] <NCommander> ogra, he's /away ATM
[22:06] <NCommander> But I pinged him
[22:06] <ogra_> ah
[22:07] <NCommander> [topic] HIgh priority bugs
[22:07] <MootBot> New Topic:  HIgh priority bugs
[22:07] <ogra_> looks like most of the team is missing btw
[22:07]  * ogra_ doesnt see dyfet either
[22:07] <NCommander> This is the right time for the IRC meeting, right?
[22:08]  * NCommander just wants to make sure he's not loosing it
[22:08] <ogra_> yes
[22:08] <ogra_> it didnt change according to my gcal
[22:08] <GrueMaster> same here.
[22:08] <GrueMaster> I pinged dyfet.
[22:08] <ogra_> davidm, plars ?
[22:08] <plars> ogra_: yes?
[22:09]  * ogra_ isnt sure persia is supposed to attend atm
[22:09] <ogra_> plars, just checking who of us is actually here :)
[22:09] <NCommander> Anyway, a heads up on https://bugs.edge.launchpad.net/ubuntu/+source/linux-ports/+bug/373214
[22:09] <NCommander> ATM the armel kernel headers are completely hosed, so any build that needed the kernel headers will fail on armel, amd64, i386, lpia, and powerpc
[22:09] <ogra_> thats totally not bound to armel as i understood
[22:09] <NCommander> This bug is on cjwatson and on my plate, as well as members of the kernel team, but until its resolved, please expect any upload to fail on these architecture.
[22:10] <ogra_> its broken on all arches
[22:10] <ogra_> or not?
[22:10] <NCommander> ogra_, ia64, sparc and hppa are unaffected
[22:10] <NCommander> (aka, only the archs people use are affected :-))
[22:10] <ogra_> heh
[22:10] <NCommander> It looks like its a bug in find in some very rare cirmstances
[22:11] <NCommander> Oh, cjwatson isolated it, so it should be fixed soonish
[22:11] <ogra_> great
[22:11] <lool> NCommander: Not sure why specing ec2-package-builder is still on the agenda; it's registered for karmic
[22:11] <NCommander> lool, its an action item, I just haven't scratched it yet
[22:12] <NCommander> So that's pretty much all I have on bug and annoucements affecting the team.
[22:12] <ogra_> on a sidenote we have a massive issue on armel with c++ it seems
[22:12] <NCommander> ogra, ?
[22:12] <davidm> I'm here sorry
[22:12] <ogra_> but afaik lamont is working on libstdc++
[22:12] <NCommander> ogra_, what's the issue? (I haven't heard anything)
[22:13] <plars> ogra_: bug#?
[22:13] <ogra_> totem, python-apt and some libgnome stuff ftbfs'ed
[22:14] <ogra_> i talked with cjwatson about it, seems lamot is doing a build that fixes it atm ... i dont think there is a bug open for it
[22:14] <lamont> ogra_: the linux-libc-dev issue is probably going to be an issue for the libstdc++ thing, but yes, libstdc++ is actively on my list
[22:14] <ogra_> on rimu there is a local build from doko if you need to testbuild any packages
[22:15] <ogra_> lamont, do you think it will be solved in time for alpha1 (so we can build images)
[22:15] <ogra_> ?
[22:15] <davidm> StevenK will be here shortly
[22:15] <ogra_> currently livecd-rootfs fails
[22:15] <cjwatson> I just sent a patch to findutils upstream to fix the linux-libc-dev bug
[22:15] <cjwatson> it'll be fixed in Ubuntu as soon as I can manage it
[22:15] <ogra_> cjwatson, yay, one down the list
[22:15] <NCommander> cjwatson, +1 :-)
[22:16] <ogra_> so we only have libstdc++ left ...
[22:16] <lamont> cjwatson: the expectation is that said bug will probably get in the way of libstdc++ - tell me that's happy and it'll definitely get time from me
[22:16] <NCommander> hey StevenK
[22:16] <NCommander> [topic] # StevenK to follow up with Tim on lpia kernel configuration
[22:16] <MootBot> New Topic:  # StevenK to follow up with Tim on lpia kernel configuration
[22:17] <StevenK> Please carry over, I think that should be discussed at UDS
[22:17] <cjwatson> lamont: (-> #ubuntu-devel)
[22:18] <NCommander> fair enough
[22:18] <NCommander> [topic] Specification Discussion
[22:18] <MootBot> New Topic:  Specification Discussion
[22:18] <NCommander> if any :-P
[22:19] <NCommander> Going once
[22:19] <NCommander> Going twice
[22:19] <NCommander> Going three times ...
[22:19] <NCommander> [topic] Open Discussion
[22:19] <MootBot> New Topic:  Open Discussion
[22:19] <davidm> I think you can remove that from the agenda
[22:19] <davidm> Specification Discussion that is
[22:20] <NCommander> davidm, I will when I write up the next weeks wiki pages
[22:20] <davidm> That works
[22:20] <NCommander> No open discussion?
[22:21] <NCommander> Ok ...
[22:21] <NCommander> [topic] Any Other Business ...
[22:21] <MootBot> New Topic:  Any Other Business ...
[22:21] <ogra_> doesnt look like
[22:21] <davidm> Nope
[22:22] <NCommander> Well
[22:22] <bradf> good meeting!
[22:22] <NCommander> I think we're about to set a record for fastest mobile meeting ever
[22:22] <davidm> Nah, we had one in 10 minutes once
[22:22] <plars> heh
[22:22] <StevenK> First one with the new format, if I recall
[22:22] <davidm> that was a while ago however
[22:22] <ogra_> heh, well, i dont remember but i think the last pre-UDS ones were as short as well
[22:23] <NCommander> Ok, I think we're done
[22:23] <StevenK> We went from a meeting that took 70 minutes to 10, and we all went "WTF?"
[22:23] <NCommander> Going once
[22:23] <ogra_> yeah
[22:23] <NCommander> twice
[22:23] <NCommander> three times
[22:24] <NCommander> And we're out of here!
[22:24] <StevenK> Sold!
[22:24] <NCommander> #endmeeting
[22:24] <MootBot> Meeting finished at 16:24.
[22:24]  * StevenK coughs
[22:24] <ogra_> who pays it ?
[22:25] <StevenK> The bidder, we were just selling it
[22:28]  * ogra_ didnt see any hands up ... but NCommander sold it
[22:28] <NCommander> ogra_, I dunno who to :-)
[22:29] <ogra_> damned ... then you have to keep it and pay the storage costs :P
[22:29] <GrueMaster> judging by the scroll log, I think it went to a silent bidder.
[22:29] <ogra_> ah
[22:30] <ogra_> these quiet guys buy the world :)