[20:24] <Schwitzd> hello
[20:24] <Schwitzd> any wiki editors?
[21:26] <bimberi> Schwitzd: Which /whois Schwitzd
[21:26] <bimberi> blah :)
[21:29] <Schwitzd> bimberi: yes :D
[21:36] <bimberi> (we ended up PMing)


[01:56] <schierbeck> jelmer: hi
[01:57] <jelmer> schierbeck: hi
[01:57] <schierbeck> shit, i'm high as hell
[01:57] <schierbeck> these two american dudes are subverting me
[01:57] <schierbeck> they managed to get hold of a bong
[01:58] <schierbeck> now they're trying to take it out on me
[01:58] <schierbeck> sorry about the rant
[02:02] <Peng> .........
[02:04] <abentley> lifeless: Was it just delayed or am I confused?
[02:04] <jelmer> Peng: ... indeed
[02:10] <lifeless> abentley: was what delayed?
[02:11] <abentley> find_text_key_references
[02:11] <lifeless> I sent it in first
[02:12] <abentley> Okay, I was confused earlier, and thought I needed to look for [MERGE] _generate_text_key_index
[02:12] <abentley> It appears I haven't received any email about find_text_key_references
[02:14] <Peng> Gack!
[02:14] <Peng> First time I try to push the pack repo, and I get an error!
[02:15] <abentley> lifeless: Okay, found it.
[02:15] <abentley> It got marked superseded.
[02:15] <abentley> Which is my bug, not your fault.
[02:15] <Peng> bzr: ERROR: Could not understand response from smart server: ('error', "<bound method KnitPackRepository.leave_lock_in_place of KnitPackRepository('chroot-1082717612:///path/to/.bzr/repository/')>")
[02:19] <Peng> Woah! bzr serve is still running.
[02:21]  * Peng pokes lifeless.
[02:21] <Peng> Seems it's a NotImplementedError.
[02:22]  * Peng wanders off.
[02:25] <Peng> server's .bzr.log: http://paste.pocoo.org/show/10721/
[02:25]  * Peng wanders off.
[02:43]  * Peng pushes over sftp.
[02:44]  * Peng wanders off.
[02:54]  * beuno is playing around with bug #162264 and woders if "Transfer phase" isn't better then "Fetch phase" considering it uses the same for push/pull. Hacking around to display different things for each seems like an overkill
[02:54] <ubotu> Launchpad bug 162264 in bzr "Push progress bar shouldn't say "Fetch..."" [Undecided,New] https://launchpad.net/bugs/162264
[03:11] <lifeless> Peng: I have a faster reconcile patch -> list
[03:12] <lifeless> Peng: pack reconcile on monday I hope
[03:16] <Peng> What about this traceback?
[03:17]  * Peng wanders off.
[05:22] <YGingras> I'm playging with bzrlib.merge3, I don't get the same merge as GNU diff3.  Anyone can tell what kind of differences to expect?
[05:28] <igc> YGingras: I believe our merging is based on Codeville's merge algorithm which is a bit more intelligent
[05:29] <YGingras> igc: you don't seem to have the "|||||||" section when there is a conflict
[05:29] <YGingras> any way to change the labels?
[05:30] <igc> I'm not sure if it's packaged separately to "bzrlib.merge3" or just included within it. abentley can tell you the details
[05:30] <igc> no idea sorry
[05:30] <YGingras> ok, I found the lables
[05:31] <poolie> YGingras, you can get that with --show-base i think
[05:31] <YGingras> print "".join(m.merge_lines(base_marker="|||||||"))
[05:32] <YGingras> this gets me more or less the same stuff
[05:32] <YGingras> poolie: I'm integrating with the API only, I don't use bzr (yet?)
[05:33] <abentley> YGingras: diff3 and merge3 used in that way don't minimize conflicts, because minimizing conflicts destroys the correlation between the base and the conflicted region
[05:34] <YGingras> abentley: but the diff is much easier to read
[05:35] <YGingras> maybe try without base and call with the base when there are conflicts anyway
[05:35] <YGingras> that should be done on a hunk by hunk basis
[05:35] <YGingras> humm I won't sleep early tonight
[05:36] <abentley> No, you're not getting what I mean.
[05:36] <abentley> showing the base will not cause a merge to conflict when it would otherwise not conflict.
[05:36] <abentley> But it will make the conflict regions longer than they have to be.
[05:36] <YGingras> oh
[05:37] <abentley> btw, long time no see.
[05:37] <YGingras> so, the only non-crap solution is visual side-by-side?
[05:37] <YGingras> abentley: indeed : )
[05:37] <abentley> Visual side-by-side will have the same issue if you're showing the base.
[05:38] <YGingras> abentley: but you can hightlight what is a conflict and what is context with the base
[05:39] <YGingras> kdiff3 has a not too confusing color code
[05:39] <abentley> Well, just be aware that in some places you'll have the base in conflict with THIS and OTHER, while THIS and OTHER are in harmony.
[05:41] <abentley> Personally, I'll take a merge3 with minimized conflicts over side-by-side any day.
[05:41] <YGingras> abentley: this is for a wiki, most of the time this should be easy to merge anyway but I plan full-namespace branching later on: this one will require good merge and conflict resolve gui
[05:41] <abentley> Yes, a colleague pointed out your wiki.
[05:41] <YGingras> abentley: you mean with the makers?
[05:42] <YGingras> since I force long lines spliting, markers are no too bad
[05:42] <abentley> I'm not sure what you mean.
[05:42] <abentley> Are you asking what I mean by merge3?
[05:42] <YGingras> it was the complete hell when I allowed one line per para
[05:43] <YGingras> abentley: yes
[05:43] <YGingras> I mean, by merge3 you mean merge with conflicts makers?
[05:44] <abentley> by merge3, I mean the kind of merge output that Bazaar gives by default.
[05:44] <abentley> Yes, with conflict markers.
[05:44] <YGingras> and without the base
[05:44] <abentley> Right, and with conflict reduction enabled.
[05:45] <abentley> So that only lines that differ between THIS and OTHER can conflict.
[05:46] <YGingras> abentley: asside from the fact that GNU diff3 defaults to show the base, any note worthy differences in the acutal merge?
[05:47] <YGingras> can diff3 even hide the base?
[05:47] <abentley> We use a sequence matcher that finds the longest common subsequence, instead of the longest common substring.
[05:47] <abentley> YGingras: Sure.  Remember Arch?
[05:47] <YGingras> yes
[05:47] <YGingras> It used diff3?
[05:47] <abentley> Yes.
[05:48] <abentley> I don't remember the exact commandline it used.
[05:48] <YGingras> I'll dig the source
[05:49] <YGingras> thanks for the pointers
[05:49] <abentley> No problem.
[05:50] <YGingras> I keep you posted, bzrlib will be the fallback if I can't find diff3, or should it be the other way around?
[05:51] <abentley> I think either is a worthy choice.  We didn't want a dependency on diff3, so we built our own.
[05:51] <YGingras> the magic spell is: diff3 -E -m my.txt base.txt your.txt
[06:39] <YGingras> can I know if there was a conflict or do I have to parse the merge?
[06:46] <YGingras> oh, it's "base, my, your", not "my, base, your".  No wonder I didn't get the right merge...
[06:47] <YGingras> but the command line is "my, base, your".  You guys are playing tricks to the API users? ; )
[06:50] <YGingras> and you flipped it the otherway around for merge_lines()
[06:53] <fullermd> Just making sure you're paying attention   ;)
[06:55] <YGingras> would you merge a patch straightening this up a bit?
[06:55]  * YGingras imagine the havok
[07:09] <YGingras> is this the right error message: exceptions.TypeError: sequence item %zd: expected string, %.80s found
[07:24] <YGingras> anyone sees what I did wrong: http://pylonshq.com/pasties/553
[07:28] <YGingras> seems to be a proble with workingenv
[07:28] <YGingras> virtualenv seems to be just fine
[07:32] <lifeless> YGingras: we'd definately consider a patch making things more clear in the api
[07:35] <poolie> ok, i'm signing off
[07:35] <YGingras> lifeless: that will silently break all existing code
[07:36] <lifeless> YGingras: we have good support for versioning API's. See our developers documentation and the symbol_versioning module.
[07:36] <lifeless> poolie: night!
[07:36] <lifeless> poolie: I don't have transport to john's thing ...
[07:36] <poolie> and therefore you're wanting transport, or you're not going?
[07:37] <YGingras> lifeless: I'll see what it involves.  What do you prefer? (my, old, your)?
[07:37] <lifeless> it could go either way :)
[07:37] <lifeless> YGingras: I haven't looked closely enough at the situation to tell why its unclear.
[07:38] <lifeless> YGingras: e.g. maybe it just needs a better docstring, or - whatever.
[07:38] <YGingras> lifeless: the order change gratuitouly from one call to the other
[07:38] <YGingras> I'd pick one order and stick to it
[07:39] <lifeless> YGingras: that sounds fair to me
[07:39] <YGingras> instead of requiring to read the docstring for every single method call
[07:39] <lifeless> anyhow, I don't have an opinion
[07:39] <lifeless> on the 'right' order yet
[07:39] <lifeless> I think left/right/base makes most sense
[07:39] <YGingras> (my, old, your) is easier to remember, there is a mnemonic
[07:40] <YGingras> but I forget what is was... : \
[07:40] <lifeless> because 2-way is left/right only
[07:40] <lifeless> so this makes three-way an extension
[07:40] <lifeless> OTOH for diff you have old/new so base/left/right might be better
[07:40] <lifeless> :)
[07:41] <lifeless> no help at all I realise :)
[07:41] <YGingras> "diff3 MINE OLDER YOURS" "
[07:41] <YGingras> You can remember the order of the arguments by noting that they are in
[07:41] <YGingras> alphabetical order.
[07:41] <YGingras> "
[07:41] <YGingras> ok, the mnemonic is crap
[07:42] <lifeless> I'm off for family time
[07:42] <lifeless> ciao
[07:42] <YGingras> later
[08:08]  * igc food
[08:22] <Peng> lifeless: Now that packs are in bzr.dev, is your repository branch abandoned?
[08:22]  * Peng wanders off.
[09:07] <lifeless> Peng: no, it has various not-yet-merged improvements
[14:59] <TeXitoi> hi
[15:00] <TeXitoi> bug: try this:
[15:00] <TeXitoi> pinot@pc-pinot:~/tmp$ mkdir Thèse
[15:00] <TeXitoi> pinot@pc-pinot:~/tmp$ cd Thèse/
[15:00] <TeXitoi> pinot@pc-pinot:~/tmp/Thèse$ bzr init .
[15:00] <TeXitoi> pinot@pc-pinot:~/tmp/Thèse$ echo foo > bar
[15:00] <TeXitoi> pinot@pc-pinot:~/tmp/Thèse$ bzr add .
[15:00] <TeXitoi> added bar
[15:00] <TeXitoi> pinot@pc-pinot:~/tmp/Thèse$ bzr commit
[15:01] <TeXitoi> bzr seems unable to commit in a directory with non-ascii character.
[15:02] <LeoNerd> Works for me
[15:02] <TeXitoi> LeoNerd: devel or last stable version?
[15:03] <TeXitoi> I have debian's 0.92.0
[15:03] <beuno> TeXitoi, what error are you getting?  traceback?
[15:03] <LeoNerd> Bazaar (bzr) 0.92.0.candidate.1
[15:03] <TeXitoi> yes
[15:03] <LeoNerd> From debian/unstable
[15:04] <beuno> maybe it's bug #63324?
[15:04] <ubotu> Launchpad bug 63324 in bzr "exceptions.UnicodeEncodeError: 'ascii' codec can't encode character" [Medium,Confirmed] https://launchpad.net/bugs/63324
[15:04] <beuno> or #77533
[15:04] <beuno> bug #77533
[15:04] <ubotu> Launchpad bug 77533 in bzr "bzr crashes with invalid filenames" [Low,Confirmed] https://launchpad.net/bugs/77533
[15:06] <TeXitoi> http://pastebin.com/m60424600
[15:06] <LeoNerd> http://paste.leonerd.org.uk/?show=1866  <== output from my successful run
[15:06] <LeoNerd> What's $LANG set to..? Mine has en_GB.UTF-8
[15:07] <TeXitoi> see the pastebin
[15:07] <TeXitoi> fr_FR.UTF-8
[15:09] <beuno> TeXitoi, you're not running Cygwin, are you?
[15:09] <TeXitoi> no
[15:09] <TeXitoi> debian testing
[15:10] <TeXitoi> It work with bzr ci -m "bla" but not with bzr ci
[15:10] <TeXitoi> LeoNerd: try
[15:10] <TeXitoi> echo foo > bar
[15:10] <beuno> TeXitoi, would you mind filing a bug with all this information?
[15:10] <TeXitoi> bzr ci
[15:11] <LeoNerd> Ahh... yes
[15:11] <TeXitoi> beuno: If you think the bug is not yet reported, sure
[15:11] <TeXitoi> Mmm
[15:11] <LeoNerd> edit_commit_message_encoded() in the stack trace
[15:11] <LeoNerd> Whereas, ci -m "message"  doesn't
[15:11] <beuno> TeXitoi, it does sound like an unreported bug, yes
[15:11] <TeXitoi> I need to create a lanchpad account for that?
[15:12]  * TeXitoi hates creating accounts
[15:12] <beuno> I might be wrong, but the worst that can happen is it gets marked as a duplicate
[15:12] <beuno> TeXitoi, it's a one time thing  :p
[15:13] <TeXitoi> beuno:<troll> I know, but I don't like to use non free software</troll>
[15:13] <TeXitoi> I'll ask a friend that have an account
[15:15] <beuno> TeXitoi, I can file it for you, I'll try and reproduce it here
[15:17] <beuno> TeXitoi, I can reproduce it perfectly, I'll file it now
[15:18] <TeXitoi> nop
[15:18] <beuno> TeXitoi, nop?
[15:18] <TeXitoi> or it will be duplicated
[15:18] <beuno> oh, you're filing it already?
[15:18] <TeXitoi> A friend is doing the bug report
[15:18] <vila> I think it's bug 84403
[15:18] <ubotu> Launchpad bug 84403 in firefox "Firefox crashes unexpectedly  (dup-of: 73536)" [Undecided,Incomplete] https://launchpad.net/bugs/84403
[15:18] <ubotu> Launchpad bug 73536 in firefox "MASTER Firefox crashes on instant X server shutdown" [Medium,In progress] https://launchpad.net/bugs/73536
[15:19] <vila> ghaa I meant 84043
[15:19] <vila> ghaa I meant bug 84043
[15:19] <ubotu> Launchpad bug 84043 in bzr "commit fails to invoke external editor in non-ascii directory" [Medium,Confirmed] https://launchpad.net/bugs/84043
[15:19] <beuno> vila, that sounds about right
[15:19] <vila> traceback looks pretty similar
[15:20] <vila> please add a comment inside that bug instead of creating a new one if it's still possible
[15:22] <vila> Oh, and the obvious work-around is to not use accented letters in the directory name (TeXitoi)
[15:24] <TeXitoi> vila: I know ;-)
[15:25] <vila> TeXitoi: ok, just wanted to be sure. I'm pretty sure I've seen the subject discussed recently so rest assured that the problem is taken care of
[15:26] <TeXitoi> vila: are you sure that it must be a comment to that bug?
[15:26] <TeXitoi> it seems closer, but the trace is much longer in my case
[15:27] <vila> the important part is the end so if they match you can be pretty sure it's the same root cause, if you're unsure file a new bug but mention the old one so that anyone fixing one will not miss the other
[15:27] <TeXitoi> ok
[15:27] <TeXitoi> it will be a comment
[15:31] <TeXitoi> or not finaly, but with ref : https://bugs.launchpad.net/bzr/+bug/163123
[15:31] <ubotu> Launchpad bug 163123 in bzr "Crash when repository is in a directory with non ascii characters" [Undecided,New]
[16:06] <ubotu> New bug: #163123 in bzr "Crash when repository is in a directory with non ascii characters" [Undecided,New] https://launchpad.net/bugs/163123
[16:27] <YGingras_> lifeless: so, did you find enlightenment on the right order in your sleep?
[16:32] <jam-laptop> YGingras_: lifeless is in Australia, so won't be online for another couple hours
[16:32] <jam-laptop> (he just got back, so he may still be jetlagged and come online a bit earlier than usual)
[16:32] <jam-laptop> YGingras_: you were here yesterday talking about using the code for a wiki, right?
[16:33] <YGingras_> jam-laptop: oh, I'll wait a bit then : )  Yes, I do use the code in the wiki now
[16:33] <jam-laptop> By the way, while git may be fast, I found that spawning it in a pipe isn't all that, at least I was working on a converter, and spawning it 16 times to set up a branch put data in, etc was quite slow
[16:33] <jam-laptop> the 'git fast-import' stuff was pretty quick, though
[16:34] <jam-laptop> So it might just be process spawn overhead on this machine
[16:34] <jam> YGingras_: I can try to help. I'm not sure what the "right order" you are talking about (I don't see it in your earlier conversation.)
[16:35] <jam> what wiki is it, by the way
[16:35] <YGingras_> jam, in merge3.py, many function calls take the 3 params (mine, old, yours)
[16:35] <YGingras_> jam: but they keep changing the orger
[16:35] <YGingras_> order
[16:36] <YGingras_> so, we think that a bit of uniformito might help
[16:36] <YGingras_> jam: Gazest: http://ygingras.net/gazest
[16:37] <jam> well, if you use our code, can you at least put up our name on the About section :)
[16:38] <YGingras_> jam: sure : )
[16:38] <jam> in merge3.py I only see 2 places that a user would call
[16:38] <jam> Merge3(base, a b)
[16:38] <jam> and Merge3.merge_lines()
[16:38] <jam> Though I agree that merge_lines(name_base, name_a, name_b) would probably be better
[16:39] <jam> I think it is expected that you would explicitly call the parameters
[16:39] <jam> so
[16:39] <jam> merge_lines(name_base='foo', name_a='a', name_b='b', ...)
[16:39] <jam> In which case you can supply them in any order.
[16:39] <YGingras_> jam: the command line interface has yet another order
[16:40] <jam> YGingras_: the command line order is because that is what diff3 and other tools expect
[16:40] <jam> so better to be compatible
[16:40] <jam> that way you can be a 'drop-in' replacement
[16:40] <jam> But I think "base, mine, other" is probably a more logical layout
[16:40] <jam> I suppose we could go either way
[16:41] <jam> though  if we call them 'a' and 'b' it is a bit odd
[16:41] <jam> 'a', 'base', 'b'
[16:41] <jam> If they were renamed it would probably be okay
[16:41] <jam> I think we generaly use
[16:41] <jam> THIS, BASE, OTHER
[16:41] <YGingras_> jam: no order is really good and mnemonic but the diff3 one has been with us for so long that we assume it
[16:41] <jam> which makes it clearer anyway.
[16:42] <jam> I think the problem is calling them 'a' and 'b' doesn't give you a hint about them
[16:42] <YGingras_> jam: yeah, a rename would probably be in order
[16:44] <jam> hmm... it seems like python merge3.py isn't really meant to be a diff3 substitute
[16:44] <jam> since it always annotated
[16:44] <jam> annotates
[16:44] <jam> probably more for Aaron (who wrote the code) to see what was going on
[16:45] <YGingras_> the api is ok
[16:45] <YGingras_> I do merge = list(m3.merge_lines(MY, YOUR, OLD, MARKERS[0], MARKERS[2], MARKERS[-1]))
[16:46] <YGingras_> which gives me mostly the same stuff as diff3 -E -m
[16:47] <jam> right
[16:50] <jam-lapto> YGingras_: when going to pages like http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/hist?rev_id=6
[16:50] <jam-lapto> How do you populate the 'rev_id' ?
[16:50] <jam-lapto> At least it seems like you are using the number 6, but there are only 3 revisions
[16:51] <jam> silly chat program...
[16:51] <jam> anyway, When you look at: http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/rev/6
[16:51] <jam> it says that it might differ
[16:51] <jam> but it seems to be the most up-to-date version
[16:52] <jam> jam-lapto: YGingras_: when going to pages like http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/hist?rev_id=6
[16:52] <jam> [10:50am] jam-lapto: How do you populate the 'rev_id' ?
[16:52] <jam> [10:50am] jam-lapto: At least it seems like you are using the number 6, but there are only 3 revisions
[16:52] <jam> [10:51am] You are now known as jam.
[16:52] <jam> [10:51am] jam: silly chat program...
[16:52] <jam> [10:51am] jam: anyway, When you look at: http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/rev/6
[16:52] <jam> [10:51am] jam: it says that it might differ
[16:52] <jam> [10:51am] jam: but it seems to be the most up-to-date version
[16:52] <jam> I was trying to go to the history page to see what the current version is
[16:52] <jam> and it was pretty unclear
[16:52] <jam> that I was already at the most recent
[16:53] <YGingras__> jam: just wave me when abentley and lifeless are around; we'll see if a patch is really in order
[16:53] <jam> sure
[16:54] <jam> I'm guessing that our "maintain backwards compatibility" general rule will outweigh the benefit of renaming... but maybe not
[16:56] <YGingras__> "?rev_id=6" is an artefact of Routes memory
[16:57] <YGingras__> I'm using Routes as the dispatcher and it recalls stuff so I can do "< a href=%s..." % url_for(action="edit")
[16:57] <YGingras__> and forget about the other params
[16:57] <YGingras__> but once in a while, it recalls too much and that clutters the URLs
[16:58] <YGingras__> jam: yeah I'm not sure about the patch either but lifeless seems to imply that you have a super flexible versionning system that will brevent any breakage
[16:58]  * YGingras__ shrugs
[16:59] <jam> its more about having people like you who might be using it outside of the scope of our little project :)
[16:59] <jam> and not wanting to cause you grief because of arbitrary parameter renaming
[17:04] <YGingras> I hate my ISP
[17:29] <YGingras> jam: did by remarks on routes memory made it through?
[17:37] <jam> YGingras: "that sometimes it remembers too much" yes
[17:37] <jam> YGingras__: but once in a while, it recalls too much and that clutters the URLs
[17:37] <YGingras> good : )
[17:47] <vila> jam: ping
[17:47] <jam> hi vila
[17:48] <vila> hi :) I just run the bzr test suite and get 31 errors related to gtk (up to date from  http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk/)
[17:48] <vila> but if I run bzr test-gtk I got: Ran 63 tests in 2.896s
[17:49] <vila> I thought test-gtk was running all gtk tests >-/
[17:49] <vila> by the way they all failed with:  'int' object is not callable
[17:50] <vila> with a traceback ending with:  file_label = gtk.Label(_('Files'))
[17:50] <vila> Does that ring a bell or should I investigate ?
[17:54] <vila> hmmm, I smell a gtk initialization pb again...
[17:59] <vila> hmm, I bet cmd_gselftest.run taking care of sys.getdefaultenconding() may have something to do with it...
[18:02] <vila> jam: bzr selftest --no-plugins works and bzr selftest gtk works too :-) They just can't agree when running together.
[18:02] <jam> vila: something is overwriting _
[18:02] <jam> and gtk sets it as a builtin
[18:02] <jam> I'm guessing that we have code which does
[18:02] <jam> _, foo, bar = ...
[18:03] <lifeless> hmm
[18:03] <lifeless> import gtk
[18:03] <lifeless> import builtins
[18:03] <vila> In the global name space ?
[18:03] <lifeless> del builtins._
[18:03] <vila> :)
[18:04] <lifeless> import __builtin__
[18:04] <lifeless> >>> import __builtin__
[18:04] <lifeless> >>> import gtk
[18:04] <lifeless> >>> __builtin__._
[18:04] <lifeless> Traceback (most recent call last):
[18:04] <lifeless>   File "<stdin>", line 1, in <module>
[18:04] <lifeless> AttributeError: 'module' object has no attribute '_'
[18:04] <lifeless> >>> print _
[18:04] <lifeless> Traceback (most recent call last):
[18:04] <lifeless>   File "<stdin>", line 1, in <module>
[18:04] <lifeless> NameError: name '_' is not defined
[18:05] <jam> yeah, I'm not seeing where it is actually triggering yet
[18:06] <jam> it might be gobject or pango
[18:06] <jam> pango is pretty likely
[18:07] <lifeless> >>> import pango
[18:07] <lifeless> >>> __builtin__._
[18:07] <lifeless> Traceback (most recent call last):
[18:07] <lifeless>   File "<stdin>", line 1, in <module>
[18:07] <lifeless> AttributeError: 'module' object has no attribute '_'
[18:07] <lifeless> >>> print _
[18:07] <lifeless> Traceback (most recent call last):
[18:07] <lifeless>   File "<stdin>", line 1, in <module>
[18:07] <lifeless> NameError: name '_' is not defined
[18:07] <lifeless> >>>
[18:08] <jam> I don't see anything in the bzr-gtk code which is doing it
[18:08] <jam> maybe it is a side effect of creating a window?
[18:08] <jam> I'm trying to find it
[18:09] <lifeless> it gets put in builtins right ?
[18:09] <lifeless> bleh
[18:09] <jam> as near as I can tell
[18:09] <lifeless> ok try this
[18:09] <jam> it certainly isn't being put into the local namespace each time
[18:09] <lifeless> create a fake module
[18:09] <jam> (Pdb) _
[18:09] <jam> <bound method NullTranslations.gettext of <gettext.NullTranslations instance at 0x31b9968>>
[18:09] <lifeless> put that in sys.modules
[18:09] <lifeless> jam: check in __builtin__
[18:09] <jam> (Pdb) import __builtin__
[18:09] <jam> (Pdb) __builtin__._
[18:09] <jam> <bound method NullTranslations.gettext of <gettext.NullTranslations instance at 0x31b9968>>
[18:09] <jam> yep
[18:09] <jam> it is in __builtin__
[18:10] <vila> jam: don't add pdb to the equation
[18:10] <lifeless> anyhow, put a module which is a regular object with setattr hooked to pdb
[18:10] <vila> import gettext
[18:10] <lifeless> in sys.modules['__builtin__']
[18:10] <jam> I'm pretty sure that gettext doesn't do it automatically
[18:10] <jam> but I'll check that too
[18:10] <lifeless> it will need to hold a reference to the original __built__
[18:10] <lifeless> and answer getattr from that
[18:10] <lifeless> if you do that, then when gtk setattrs _ on __builtin__, it should trap
[18:10] <lifeless> and you can get a backtrace
[18:11] <lifeless> woot, my string.find bug has been fixed
[18:11] <lifeless> so in about 5 years we can use it
[18:12] <lifeless> http://bugs.python.org/issue1259
[18:14] <lifeless> later, wow calls
[18:15] <vila> later, dinner with friends calls :)
[18:16] <vila> jam: I'll read the log if you find any fix or work-around (not urgent anyway)
[18:16] <jam> vila: sure, I'm trying to track it down
[18:16] <jam> but yeah, having a __builtins__._() is not a great way to do i18n
[18:17] <jam> but it also means we should change our code base to avoid the '_' object
[18:17] <jam> lifeless: have fun
[18:17] <jam> It seems, though, that doing __get_attribute__ seems to cause problems with __import__ not being found :(
[18:17] <jam> still looking
[18:21] <vila> What about using 'i18n' instead of '_' ?
[18:21] <jam> I would be happy enough with that, it just isn't the standard 'gettext()' way
[18:21] <jam> and it just happens that gettext conflicts
[18:21] <jam> with a common python idiom
[18:21] <jam> of using '_' as a "I don't care about this" variable
[18:21] <jam> (and as a last action variable)
[18:21] <vila> yup, perl heritage :)
[18:22] <jam> trying to wrap __builtin__ I'm still getting "has no member __import__" ...
[18:22] <jam> which breaks everything
[18:24] <jam> hmm.. it seems to have triggered by the time plugins have imported
[18:24] <jam> which is *before* gtk should be imported
[18:24] <jam> maybe in 'gettext.install('olive-gtk')' ?
[18:24] <jam> yep
[18:24] <jam> gettext.install does bad things
[18:27] <jam> vila: 'grep -rnI "\<_\>" bzrlib' shows it being used in quite a few places in our codebase
[18:27] <jam> dirstate.py
[18:27] <jam> fetch.py
[18:27] <jam> and a few others
[18:32] <Zenom> If we have 3 programmers constantly working on the same project (for instance a new project) and we are a kind of jack of all trades, can bzr still help us ?
[18:34] <beuno> Zenom, absolutely, it does the same (and more) as other VCS
[18:35] <Zenom> beuno: i guess my concern is like 2 of us could be working on the same code
[18:35] <Zenom> i am worried about merging changes appropriately etc
[18:35] <Zenom> and the time it takes to merge all these changes or reviewing them
[18:36] <beuno> Zenom, you will have to do it eventually, so it's probably best if you have a VCS
[18:36] <beuno> we work on the same files here all the time
[18:36] <beuno> and rarely have conflicts
[18:36] <Zenom> we use svn now bu we are  tired of like "hey billy are you in index.py"
[18:36] <Zenom> lol
[18:36] <beuno> and when we do, they are easily resolved in 1 or 2 minutes
[18:37] <Zenom> how often are you guys committing your changes?
[18:37] <Zenom> to the main repo?
[18:37] <beuno> Zenom, it varies, but I tend to commit and push every time I finish a specific task
[18:37] <beuno> logical blocks of changes
[18:37] <beuno> sometimes I commit for a while and then send
[18:37] <Zenom> so you would commit to local branch, then push the  changes to the main repo for review
[18:38] <beuno> but I try yo keep it to the least amount of time possible so we don't diverge as much
[18:38] <jam> Zenom: well, you could use a checkout so that the push is automatic
[18:38] <beuno> Zenom, yeap, I do bzr branch
[18:38] <jam> I usually commit 10+ times per day ...
[18:38] <beuno> work locally, then push when needed
[18:38] <Zenom> i guess no matter what there still needs to be communication
[18:38] <jam> you could work locally, commit, and then merge your changes back into trunk
[18:38] <Zenom> ie., im going to fix the connection bug or whatever
[18:38] <beuno> we have a different workflow here (web development), so I think, between all the projects, I commit close to 50 a day, and push 15-20 times
[18:38] <Zenom> so that others don't try and correct the same bug i am assuming
[18:39] <jam> Zenom: yah, Bazaar can't solve social issues, but it does make it easier to resolve some conflicts
[18:39] <beuno> Zenom, yes, but that is out of the scope of bzr, although if you read the commits you might have an idea of what is going on
[18:39] <Zenom> do you guys typically have 1 package maintainer?
[18:39] <Zenom> or just let anyone push to trunk
[18:40] <beuno> Zenom, here, we let everyone push to trunk
[18:40] <jam> Zenom: The Bazaar project has about 10 people that can push to trunk, but all pushes go through a Patch Queue Manager
[18:40] <jam> which forces the test suite to pass before it accepts anything
[18:40] <beuno> (here == my office, not bzr development)
[18:40] <Zenom> right
[18:40] <Zenom> i want to try something as i hate the situation with svn (ie, when no internet, on a plane etc)
[18:40] <jam> which works very well for having a stable trunk
[18:41] <jam> Zenom: with bzr-svn you can give Bazaar a try
[18:41] <Zenom> but i worry about some of our programmers who don't know squat but how to click commit :)
[18:41] <jam> and still push your changes back into svn
[18:41] <beuno> you can always revert changes, so I don't mind going over to someones desk and kicking them in the face for deleting my file  :p
[18:41] <Zenom> interesting, we want to give it a shot gonna mess with it a bit now
[18:41] <Zenom> are there any mac osx guis for bzr?
[18:41] <beuno> Zenom, as jam proposes, bzr-svn can work for you, with checkouts and using --local when commiting you can have both workflows, and choose the apropriate one as needed
[18:42] <Zenom> well i have this need to use everything how it is intended
[18:42] <Zenom> and i would like to have a more distributed environment
[18:42] <jam> well, for people who need it, they can have just a checkout of 'trunk'
[18:42] <Zenom> my concern was mostly with interaction with merges, but i guess its no different, i could commit, someone could checkout and break my code
[18:42] <jam> so that "just commit" works
[18:42] <beuno> Zenom, sounds like bzr is a perfect match  :D
[18:43] <jam> and then for people who want more distributed
[18:43] <jam> they can do local branches, etc.
[18:43] <Zenom> ok so for a beginner at bzr what is the way you guys suggest?
[18:43] <beuno> Zenom, people will be able to break your code no matter what. Unless you use seperate branches and merge with each other to make sure before sending to trunk
[18:43] <Zenom> just look at the tutorial and go for broke?
[18:44] <Zenom> beuno: true, i guess really its no diffferent in that sense
[18:44] <beuno> Zenom, yeap, you should get used to it very quickly
[18:44] <Zenom> if it breaks it needs to be fixed or revert back
[18:45] <beuno> the only times I end up manually fixinf merges is when two of us edit the same line, which isn't that often. bzr is pretty smart about merges
[18:45] <beuno> the patch queue manager workflow jam proposed isn't a bad idea either
[18:46] <beuno> you can write up some tests to ake sure nothing breaks trunk before committing to it
[22:58] <beuno> lifeless, you wouldn't happen to bored, would you?   we're trying to figure out how you guys do a wierd merge in bzr.dev for our XML tests, but we're out of ideas
[22:58] <beuno> (or anyone else for that matter)


[14:37] <bac> hi adeuring
[14:37] <adeuring> hi bac!
[14:37] <bac> adeuring: how much longer are you around here today?
[14:38] <adeuring> until 1700UTC or so
[14:38] <adeuring> bac doy ou need an urgent review later toady?
[14:38] <bac> adeuring: ok.  would you mind pinging me just before checking out?  i'm OCR and CHR today so i'm juggling
[14:38] <adeuring> bac: OK
[14:38] <bac> thanks abel
[16:28] <noodles775> Hi adeuring, do you have time for another? https://code.edge.launchpad.net/~michael.nelson/launchpad/588684-builders-timeout/+merge/26818
[16:28] <noodles775> 280 lines.
[16:28] <adeuring> noodles775: sure
[16:28] <noodles775> Thanks!
[16:51] <noodles775> adeuring: I need to run, but will check back (or reply to emails) later, if that's ok.
[16:52] <noodles775> adeuring: also, I updated the bug with some local testing of the sql performance.
[16:52] <adeuring> noodles775: sure, np
[17:20] <adiroiban> ls
[18:01] <adeuring> bac: I'll leave soon and I'm now declaring myself to be no longer on call.
[18:02] <bac> ok, adeuring.  thanks for the reviewing.
[18:02] <bac> adeuring: have a nice weekend
[18:02] <adeuring> bac: thanks, a nice weekend to you too!
[19:26] <abentley> rockstar, could you review https://code.edge.launchpad.net/~abentley/launchpad/build-quota/+merge/26821 ?
[19:48] <EdwinGrubbs> bac: can you review https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-535430-needspackaging-timeout-part2/+merge/26830
[19:48] <bac> EdwinGrubbs: yep
[20:25] <sinzui> bac: I have a trivial branch for review if you have time today: https://code.launchpad.net/~sinzui/launchpad/mental-health-0/+merge/26832
[20:26] <bac> rt, sinzui
[20:32] <rockstar> abentley, looking now.
[21:19] <bac> hi EdwinGrubbs
[21:20] <EdwinGrubbs> bac: hi
[21:20] <bac> EdwinGrubbs: why did the bug reporting guidelines stuff get deleted from DSP?
[21:20]  * EdwinGrubbs looks
[21:23] <EdwinGrubbs> bac: I believe you're looking at the DistributionSourcePackage class. The bug_reporting_guidelines were converted to a DistributionSourcePackageProperty on line 428 of the diff in the mp.
[21:24] <bac> EdwinGrubbs: hey, i glazed right over that.  and i had double checked!  sorry .
[21:24] <bac> nm
[21:27] <bac> EdwinGrubbs: i approved the code review.  you need to add bjorn and/or stub for db now.  (stating the obvious)
[21:31] <EdwinGrubbs> bac: they reviewed the schema changes already, but I guess I still need them for the security.cfg changes.
[21:35] <bac> a million thank yous sinzui.  a lovely branch.
[21:36] <sinzui> I still have no brain
[21:37] <sinzui> I am seriously thinking of setting a 4 hour timebox a and redesigning the team participation page to be useful
[21:44] <rockstar> abentley, so, I've got a question for you about your branch.
[21:44] <abentley> rockstar, okay, shall we mumble?
[21:44] <rockstar> (It took me this long to formulate the question itself)
[21:44] <rockstar> abentley, sure.
[22:15] <gary_poster> ...If anyone wanted to review https://code.edge.launchpad.net/~gary/launchpad/bug589010/+merge/26842 that would be nice.
[22:17] <sinzui> gary_poster, I'll take it
[22:21] <gary_poster> thank you muchly sinzui
[22:31] <sinzui> gary_poster, approved with some trivial remarks
[22:31] <sinzui> gary_poster, are you aware that we wanted to remove launchpad.conf from our configs?
[22:32] <gary_poster> sinzui, thank you!
[22:32] <gary_poster> no, I was not
[22:32] <sinzui> gary_poster, it defines servers and logs. We wanted to use  lazr.config. but we needed to hook our config into zope startup
[22:34] <gary_poster> sinzui: I'm afraid I don't know where launchpad.conf is hooked in now, but I'm trying to educate myself...
[22:34] <gary_poster> do we/you already have a plan on how to do this?
[22:34] <sinzui> We did, but this was not as important as application config.
[22:35] <gary_poster> gotcha
[22:35] <sinzui> launchapd.conf is essentially site.zcml to define the address or servers and where the logs are
[22:36] <gary_poster> OK, makes sense.
[22:37] <sinzui> I wonder if initialization.py or lp_sitecustomize run at the right time for us to register a handler that will read lazr.config  to setup the servers and logs
[22:39] <gary_poster> It would be lovely if we could settle on some standards, yes.  So it looks like importing canonical.config makes the parsing happen now, right?  So presumably it effectively happens during zcml processing as a side effect?  Or is there some other mechanism?
[22:40] <gary_poster> AFAICT, you set up this configuration object without any ZCML registration.  If that's true, then lp_sitecustomize might be a great place
[22:42] <gary_poster> sinzui: ^^^
[22:46] <sinzui> gary_poster, yes, thanks. It is effectively python created on import. I did not/and do not understand when those the zcml style conf files are read and how to register something to handle servers and logs. Monkey patches are not allowed
[22:48] <gary_poster> Yeah, I don't think the zcml machinery allows you get in there (other than defining your own markup, of course, which would certainly be another option--a zcml tag which specifies that a file be parsed using lazr.config, with the data stored somewhere or other)
[22:48] <gary_poster> But, yeah, lp_sitecustomize looks promising


[02:28] <xhhwdn> 只因你太美
[02:29] <Unit193> Hi, this is an English support channel but if Chinese would be better for you then...
[02:29] <Unit193> !cn
[02:30] <xhhwdn> caixukun
[02:30] <xhhwdn> 你们都是小黑子
[09:54] <xitix> ello
[09:54] <gnrp> xitix: hi
[12:42] <rrr> I managed to impair apt by trying to install a cuda tool kit. This failed to install because it could not overwrite /usr/bin/nvidia-powerd provided by nvidia-kernel-common-515.. I would like to manage to fix this but apt --fix-broken install still fails to correct the issue. What can I do, may I uninstall the toolkit somehow and use apt properly?
[12:48] <gnrp> what does it mean, it fails to correct?
[12:49] <gnrp> rrr: You have to provide a more precise error message
[12:49] <gnrp> anyway, I'm afk for now
[12:51] <rrr> https://pastebin.com/2UBtAep1
[12:53] <rrr> libnvidia-compute-520 conflicts with nvidia-kernel-common-515
[12:53] <rrr> and I would like to backtrack by removing the former installation candidate
[13:20] <tomreyn> "This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff."
[13:25] <tomreyn> rrr: please point it out when you choose to seek help in a different place instead.
[13:29] <rrr> yes. Oh, I am still working out if it worked since clang++ cannot find iostream but I resolved my issue.
[13:30] <emir> hey


[02:44] <micahg> knome: we had issues with mousetweaks in precise and onboard was fixed to not require it for precise
[07:31] <ochosi> knome: the description of xubuntu-artwork on lp should prolly be re-thought: "Xubuntu desktop themes, GDM themes and Usplash artwork." (more than 2/3 of that is not accurate anymore ;))
[07:31] <ochosi> s/more than/exactly/ :)
[08:34] <knome> micahg, ok, yeah, but it's still just recommends. or shouldn't be even that anymore...
[08:34] <knome> ochosi, can you change that?
[08:34] <knome> ochosi, i mean, do you have the permissions? if you do, feel free to simply go ahead
[08:39] <knome> astraljava, what about that display-dialog code? did you find it already?
[08:45] <astraljava> I had no chance to look for it, yet. I'll check it most probably on Friday evening, or during the weekend the latest. I'm not much at home before that.
[09:30] <ochosi> astraljava: ahoi! and: about how much of it had you done already?
[09:48] <astraljava> ochosi: Howdy, how are you? I didn't make any progress since the last time we spoke, my machine broke sometime soon after I got the layout changes done, and then when I got that fixed, xserver broke. :) I haven't gotten dual-head working since, though I haven't had time to play with it much either.
[09:49] <ochosi> astraljava: welcome back! i'm doing ok, obviously not working as much as you recently ;)
[09:49] <ochosi> astraljava: humm, so you haven't touched the xrandr stuff yet at all i guess?
[09:49] <astraljava> Danke!
[09:49] <astraljava> ochosi: It's not just work, mind you...
[09:49] <ochosi> right...
[09:49] <astraljava> ochosi: Nope, never got deep into that part at all.
[09:50] <ochosi> ok, then don't mind to look for the code. the UI parts are quickly changed and much of that is done already in xfce-git
[09:50] <astraljava> Yeah, I expected as much.
[09:51] <astraljava> Sorry for dropping the ball on this.
[09:51] <ochosi> hope bluesabre and me get some time soon to get the xrandr stuff going
[09:51] <ochosi> no problem, it happens ;)
[09:52] <astraljava> I'm shifting the emphasis of my contribution now, though, so development is going to be where I'll play from now on. Or at least after this cycle.
[09:52] <ochosi> very cool
[09:52] <ochosi> i really hope we can get a few things going during the next cycle
[09:53] <astraljava> Are you going to be online during this weekend?
[09:53] <ochosi> but i guess mostly we'll have to try to deal with gtk2 -> gtk3 problems
[09:53] <ochosi> hmm, not much i'm afraid
[09:53] <astraljava> Ok.
[09:53] <ochosi> a friend of mine turns 30...
[09:53] <ochosi> and i have quite a few meetings on frida
[09:53] <ochosi> y
[09:53] <ochosi> but i guess sunday evening i'd be back
[09:54] <bluesabre> ochosi: I might get some time soon
[09:54] <astraljava> My weekdays' nights are still busy until this upcoming weekend, but then the whole of the weekend is free, so I can dedicate parts of it for our stuff. But I'm not going to spend (or even plan to) as much as before, I need to have other kind of things in my life as well. :)
[09:54] <ochosi> o hai bluesabre :)
[09:54] <astraljava> Hey Sean!
[09:54] <ochosi> bluesabre: good morning to you!
[09:54] <bluesabre> Good day everyone!
[09:55] <ochosi> astraljava: yeah, that sounds like a sane plan
[09:55] <ochosi> i guess my next project is code-commenting for parole
[09:55] <astraljava> I noticed I'm going insane if I hack only, both at work and at home.
[09:55] <ochosi> heh
[09:55] <ochosi> definitely
[09:55] <bluesabre> Sanity... who needs it?  :)
[09:55] <ochosi> oh, also right now there's no stress at all, most of our workitems for 12.10 are either done or postponed
[09:55] <ochosi> hehe
[09:56] <astraljava> bluesabre: It's part of insanity, so I suppose quite many. :D
[09:56] <ochosi> astraljava: oh also, as i'm not attending UDS i might come to .fi for a RL meeting at some point
[09:57] <astraljava> ochosi: Yeah, but I'd have liked to do those that sadly are now postponed. But oh well, I guess it's better late than not even then, which could happen if I pushed like previously. :)
[09:57] <astraljava> ochosi: Super!
[09:57] <Sysi> I could try to get to south then too
[09:58] <ochosi> yeah, that'd be nice
[09:58] <astraljava> Totally.
[10:23] <ochosi> knome: i'm afraid i won't be able to make today's meeting...
[10:25] <knome> ochosi, you suck
[10:26] <ochosi> :)
[10:26] <ochosi> anyway, there's not much to update for now
[10:26] <knome> y
[10:26] <ochosi> our themes should be mostly bugfree after mr_pouit has uploaded them
[10:27] <ochosi> i'm wondering whether we should drop the USC icon from our icon-theme
[10:27] <ochosi> since we're already doing an upload, i guess it wouldn't be hard to include that
[10:27] <knome> showertime.
[10:27] <knome> your call.
[10:27] <ochosi> feel free to discuss that with bluesabre and mr_pouit today ;)
[10:27] <ochosi> i'd drop it i think
[10:27] <ochosi> or update it with a better icon
[10:28] <ochosi> better or different
[10:36] <ochosi> bluesabre: what do you think about this? http://imagebin.org/228946
[10:37] <ochosi> (still better than original USC icon and different enough from synaptic imo)
[10:38] <bluesabre> ochosi: Sure, not bad.  It's purple, so ubuntu-y
[10:38] <ochosi> yeah, that was the idea behind it
[10:38] <ochosi> orange looked a bit too "critical"
[10:38] <ochosi> (colors were borrowed from humanity-icontheme)
[10:39] <bluesabre> Even better
[10:39] <ochosi> i could re-color them and push them to git
[10:39] <bluesabre> I'd say go for it
[10:39] <ochosi> okeydokey
[10:40] <bluesabre> :)
[10:40] <ochosi> if you're around in the meeting, would you mind talking mr_pouit into uploading a new snapshot to 12.10?
[10:40] <bluesabre> If I'm around and I remember.  I have a real life meeting at that time too
[10:40] <ochosi> oh right, then nvm
[10:56] <astraljava> knome: To enhance the suckage, I can't attend either.
[10:56] <astraljava> ...or maybe that's a relief, I don't know.
[10:56] <knome> :P
[11:05] <ochosi> knome: xubuntu-artwork description updated
[11:05] <knome> ochosi, ta
[13:14]  * ochosi might make the meeting after all (at least there's a slight chance)
[13:15]  * smartboyhw thinks he should congratulate elfy
[13:40] <ochosi> ok, looks i can't attend after all...
[13:40] <smartboyhw> ...
[13:40]  * elfy will dust the channel for while
[13:41] <smartboyhw> lol elfy
[13:41]  * smartboyhw find it weird that elfy wants to dust the channel since he isn´t an op of the channel...
[13:48] <pnarciso> hey guys
[13:48] <smartboyhw> Hi pnarciso
[13:49] <pnarciso> so, there's a meeting today
[13:49] <smartboyhw> Yes:)
[13:50] <pnarciso> when is beta 2 be released?
[13:51] <smartboyhw> pnarciso: Er I think https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock has the answer
[13:52] <smartboyhw> Next thursday precisely
[13:52] <pnarciso> thank you
[13:53] <smartboyhw> NP pnarciso
[13:53] <pnarciso> Xubuntu 12.10 is working pretty nice now
[13:53] <smartboyhw> :)
[13:53] <pnarciso> but there's still the duplicated drives problem
[13:54] <smartboyhw> That´s the big one
[13:55] <elfy> I'd rather seem messaaging than drives fixed
[13:55] <pnarciso> sound plugin is working now
[13:56] <elfy> mmm - not here it's not - but might have missed an update
[13:56] <pnarciso> you must add it manually
[13:56] <elfy> oh - right click add etc ?
[13:56] <pnarciso> must add plugin indicator to xfce panel
[13:57] <elfy> already have it
[13:57] <ochosi> the indicator-plugin should still be in the panel, you might have to install the indicator-sound package though
[13:58] <pnarciso> in my case the plugin indicator was not in the panel and I add it manually
[13:58] <pnarciso> the latest updates added the gtk2 sound indicator
[13:59] <ochosi> totally possible, i haven't checked yet
[14:00] <pnarciso> USC is working for a while now
[14:00] <ochosi> i hope we'll get the themes updated soon, and maybe the new USC icon with it
[14:00] <elfy> got the sound one now
[14:00] <pnarciso> also, I´ ve seen that you just committed a fix for the USC icon
[14:00] <ochosi> then my share is more or less done for this cycle
[14:01] <ochosi> not sure the icon will land in 12.10
[14:01] <pnarciso> have you done more changes to the theme?
[14:02] <ochosi> the icon theme or the gtk themes?
[14:02] <elfy> usc?
[14:02] <ochosi> Ubuntu Software Center
[14:02] <ochosi> (aka the one and only, ugly, slow memory hog)~
[14:02] <elfy> oic - I'd not see that then
[14:02] <ochosi> it's this one: http://imagebin.org/228946
[14:03] <pnarciso> USC is a mess, I can't even install an external deb without it crashing
[14:03] <elfy> nice - not enough to make me install it though ochosi :D
[14:04] <pnarciso> gdebi should be default :)
[14:04] <ochosi> elfy: thanks, it was just the obvious fix for distinguishing it from the (blue) synaptic icon ;) and yeah, i could see why you wouldn't wanna install/use it
[14:04] <ochosi> pnarciso: afaik gdebi is unmaintained for a while already
[14:04] <elfy> :)
[14:04] <ochosi> so it's not an option
[14:05] <pnarciso> but it works :)
[14:05] <elfy> luckily it works though :)(
[14:05] <ochosi> and installing external debs doesn't really work with synaptic
[14:05] <ochosi> also i wouldn't wanna point new users to manually downloading and installing debs
[14:05] <davmor2> pnarciso: when USC fails to install a deb do you report the bug?
[14:05] <ochosi> everyone who can do that can use dpkg cli
[14:05] <pnarciso> yes I do
[14:06] <pnarciso> but I can only do it once :)
[14:06] <davmor2> pnarciso: do you have a bug number
[14:06] <pnarciso> no
[14:07] <pnarciso> but it shouldn't be too hard to search in ubuntu bugs
[14:08] <pnarciso> there's a lot of reports
[14:08] <ochosi> davmor2: are you involved in USC?
[14:09] <davmor2> pnarciso: next time if you can open USC from the terminal then trigger the deb install and add the terminal info to the bug report.  A lot of the time the issue is the package fails lintian checks, we are working on a fix for this though
[14:09] <davmor2> ochosi: I might be
[14:10] <pnarciso> ok, I will do it next time
[14:10] <ochosi> davmor2: then excuse my previous harsh comments ;) but really, i have the feeling that the previous version wasn't as slow and sluggish...
[14:10] <pnarciso> But I'm glad you are aware of this issue
[14:12] <davmor2> ochosi: Quantal's opens installs an close 2 and half to 4 second faster than in precise and precise was only 2 seconds slower than the gtk2 version.  The big issue might be the fact that it is all gtk3 now that is causing issues on xubuntu maybe, it is only really tested and supported for Ubuntu
[14:13] <ochosi> davmor2: gtk3 isn't a problem in itself in xubuntu, it's only gtk3-only plugins (like the indicators) that cause problems/work
[14:13] <micahg> well, if upstream GTK cared enough to fix their speed regressions and make improvements, then Xfce might make it more of a priority to switch
[14:13] <ochosi> +1
[14:14] <davmor2> ochosi: oh and to be fair in precise it was a real memory hog it had a memory leak if you installed more than one app, that has been resolved for quantal 3-8 meg increase instead of 3-600 meg for 4 apps :)
[14:14] <ochosi> hehe
[14:15] <ochosi> davmor2: right, well in all fairness i've only tested it on quantal in vboxes, not real installs...
[14:15] <pnarciso> I just made USC crash
[14:15] <pnarciso> I'll make a report now
[14:17] <pnarciso> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1044141
[14:38] <ochosi> gotta run now, have a good meeting everyone!
[14:38] <bluesabre> seeya ochosi
[14:38] <elfy> cya ochosi
[14:38] <ochosi> o/
[14:39] <elfy> hi bluesabre
[14:39] <smartboyhw> cya ochosi
[14:39] <bluesabre> hey elfy
[14:39] <bluesabre> how are you?
[14:39] <davmor2> pnarciso: ah yeap known chrome has 3 issues we are killing them slowly with FIRE!!!!! :D
[14:40] <elfy> bluesabre: all good here thanks :)
[14:40] <davmor2> pnarciso: the lintian for chrome seems to of gone though so that is a start
[14:42] <pnarciso> Well, I installed HIB Osmos game deb through software center and it crashed like I reported, so it's not a chrome issue
[14:51] <davmor2> pnarciso: no I mean it was an issue that chrome brought to light in USC
[14:52] <knome> meeting in less than 10 minutes
[14:52] <knome> pleia2, morning
[14:52] <knome> micahg, hullo
[14:52] <knome> mr_pouit, allö
[14:52] <smartboyhw> Hello all
[14:54] <pleia2> morning
[14:54] <elfy> hi pleia2
[14:55] <knome> hey jjfrv8, elfy, smartboyhw
[14:55] <elfy> good day good sir
[14:55] <smartboyhw> Hi knome:))
[14:55] <jjfrv8> Hi.
[14:55] <micahg> hi knome
[14:55] <SkippersBoss> afternoon
[14:56] <knome> hey SkippersBoss
[14:56] <knome> since we seem to be here, i'll start the meeting now and run through the old stuff
[14:56] <knome> #startmeeting Xubuntu community meeting
[14:56] <meetingology> Meeting started Wed Sep 19 14:56:38 2012 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:56] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[14:56] <knome> #chair pleia2
[14:56] <meetingology> Current chairs: knome pleia2
[14:56] <knome> #topic Items carried on
[14:57] <knome> #subtopic Open action items from previous meeting
[14:57] <knome> seems to be none that are still appropriate/not obsolete
[14:57] <knome> #subtopic Disable compositor in live CD
[14:57] <knome> #info Compositor is disabled in the "Install Xubuntu" mode in the live CD
[14:58] <bluesabre> yay
[14:58] <knome> #subtopic Do we want to run encryption -tests for milestones?
[14:58] <knome> #info Postponing until R
[14:58] <knome> #subtopic Testcases feedback
[14:59] <knome> #info New testcases up at the ISO tracker, please see eg. http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/23726/testcases
[14:59] <knome> #info If something is inaccurate, please send email to the xubuntu-devel mailing list
[14:59] <knome> #subtopic Xfce4 display dialog
[14:59] <knome> #info Postponed until R
[14:59] <knome> #subtopic Strategy Document review
[15:00] <knome> #info The new Strategy Document is published at https://wiki.ubuntu.com/Xubuntu/StrategyDocument
[15:00] <knome> #topic Team updates
[15:00] <knome> #subtopic Development
[15:00] <knome> is there anything worth mentioning since the last meeting?
[15:00]  * micahg wonders why the meeting started early...
[15:00] <knome> (eg. in the last month)
[15:01] <pleia2> knome got excited :)
[15:01] <knome> micahg, because i was simply running the old stuff away :)
[15:01] <knome> micahg, i knew there wasn't anything to comment on those really...
[15:01] <bluesabre> indicator-messages won't be making it, but that's not really news-worthy
[15:01] <knome> #info Re-introducing indicators, except indicator-messages
[15:02] <knome> i believe it's mostly been bugfixes and fighting agains the windmills after FFe
[15:02] <knome> #subtopic QA
[15:02] <knome> #info New testcases up at the ISO tracker
[15:03] <knome> #info We need more tests for Beta 2, since we skipped Beta 1
[15:03] <knome> #subtopic Marketing, Promotion and Artwork
[15:03] <knome> #info Xfwm window borders fixed (2px for Q)
[15:03] <knome> #info Lots of other bugfixes in too
[15:03] <pleia2> #info sent off a request for quote on some casebadge stickers
[15:04] <knome> #info Countdown banners designed, see http://temp.knome.fi/xubuntu/branding_exports/countdown_quantal.png for a quick preview
[15:04] <bluesabre> +1
[15:04] <bluesabre> brb
[15:04] <pleia2> #fleshed out our "marketing audience" on the wiki https://wiki.ubuntu.com/Xubuntu/Marketing so we can work on some flyers for events
[15:05] <pleia2> #info fleshed out our "marketing audience" on the wiki https://wiki.ubuntu.com/Xubuntu/Marketing so we can work on some flyers for events
[15:05] <knome> hehe:)
[15:05] <pleia2> #action pleia2 to draft text for flyers this week
[15:05] <meetingology> ACTION: pleia2 to draft text for flyers this week
[15:05] <knome> #action knome to draft flyer looks hopefully before UDS
[15:05] <meetingology> ACTION: knome to draft flyer looks hopefully before UDS
[15:06] <knome> #action knome to get new countdown banners uploaded
[15:06] <meetingology> ACTION: knome to get new countdown banners uploaded
[15:06] <pleia2> #info website, wiki and help.ubuntu.com/community docs are looking good! we'll probably revisit them as a review next cycle
[15:06] <knome> #action mr_pouit to upload updates to xubuntu-artwork (theme bugfixes and elementary-xfce USC icon change)
[15:06] <meetingology> ACTION: mr_pouit to upload updates to xubuntu-artwork (theme bugfixes and elementary-xfce USC icon change)
[15:07] <knome> is that it for m&p&a ?
[15:07] <pleia2> I think so
[15:07] <knome> oh
[15:08] <knome> #info "Dotless" wallpaper uploaded for LightDM and Plymouth since they don't scale wallpapers well
[15:08] <knome> #subtopic Documentation and Website
[15:08] <pleia2> ah well, got website :)
[15:08] <knome> #info The documentation is now written, reviewed and converted to DocBook
[15:09] <knome> #info The docs will most probably land into B2, they'll be reviewed today to granted an upload permission
[15:09] <knome> *to grant?
[15:09] <knome> oh well..
[15:09] <pleia2> \o/
[15:09] <SkippersBoss> :-)
[15:09] <pleia2> thanks for your work, everyone :)
[15:10] <knome> #info Thanks for everybody contributing to the docs; bluesabre, elfy, jjfrv8, myself :P, ochosi, pleia2, SkippersBoss, smartboyhw, and others that are not online and/or i've forgotten
[15:10] <smartboyhw> :)
[15:10] <knome> #topic Announcements
[15:10] <knome> oh, did somebody have general updates?
[15:11] <pleia2> not strictly project news, but I'm going to be out of the country from Oct 10 through UDS, so someone else will need to handle release notes
[15:11] <pleia2> and any other website stuff that comes up :)
[15:11] <knome> i talked with ochosi about that, and i think well get that sorted
[15:11] <pleia2> great
[15:11] <knome> yes ma'am, ready to work o>
[15:12] <knome> #info Release notes need writers, for Beta 2 and Final release
[15:12] <knome> #info Beta 2 freeze is TOMORROW 21UTC
[15:13] <SkippersBoss> if i can help OOPS that's quick
[15:13] <smartboyhw> :)
[15:13] <knome> SkippersBoss, that's just the freeze, b2 release is next thursday :)
[15:13] <SkippersBoss> let me knmow what to do and where i can find it
[15:13] <knome> SkippersBoss, we'll send email to the -devel list
[15:14] <micahg> oversizedness
[15:14] <knome> ok, let's advance
[15:14] <knome> micahg, yeah
[15:14] <knome> #topic New and emerging items
[15:14] <knome> #subtopic ISO oversizedness
[15:15] <SkippersBoss> for the amd64 variant only
[15:15] <knome> #info We are currently at 708MB for amd64 and 693MB for i386
[15:15] <pleia2> I love it and it would make me sad, but dropping gimp?
[15:15] <knome> pleia2, that's dropped already \o/
[15:15] <pleia2> oh now I am sad!
[15:15] <knome> pleia2, so is gnumeric \o/
[15:15] <micahg> it gave us 20MB
[15:15] <SkippersBoss> so is gnumeric
[15:15] <micahg> knome: drop 1 more langauage?
[15:15] <micahg> on amd64 that is
[15:15] <knome> np: Hans Zimmer (Gladiator OST) / Barbarian Horde
[15:15] <knome> suits very well for the situation
[15:15] <micahg>  * Languages: es pt zh-hans
[15:15] <knome> micahg, yeah, i was simply thinking the same.
[15:16] <micahg> that gets us proper sized for beta 2, if we can find more room before final, we can add it back
[15:16]  * pleia2 makes note for updating websites and info about gnumeric
[15:16] <knome> micahg, pt has less native speakers by far, so it'd be that
[15:16] <knome> micahg, what are the other things we are looking at?
[15:17] <smartboyhw> Yay zh-hans is not deleted...
[15:17] <SkippersBoss> remeber that with the es pt versions you are going to alianate a large group of users
[15:17] <knome> we could cut some slack removing some games
[15:17] <knome> SkippersBoss, well, we already had to drop fr...
[15:17] <micahg> SkippersBoss: i386 still has them
[15:17] <SkippersBoss> I can understand the logic
[15:17] <knome> SkippersBoss, most people fortunately have a decent internet connection, so they're able to download the langpacks
[15:17] <micahg> #Enough room on i386, not enough on amd64:
[15:17] <micahg>  * Languages: xh fr pt
[15:18] <knome> #info Languages that we'll keep for i386 but drop for amd64 to get more space: xh, fr, pt
[15:18] <knome> ok, so is that as easy as that? :P
[15:19] <micahg> yep
[15:19] <knome> ok, great
[15:19] <micahg> if we dropped something else from the default install, we could probably add another language to i386
[15:19] <knome> gnome-sudoku?
[15:19] <micahg> or found another spurious recommends
[15:20]  * micahg takes it knome doesn't like sudoku
[15:20]  * smartboyhw thinks sudoku is ok to be dropped
[15:20] <knome> well i do, but it's less essential than one more language
[15:20] <micahg> yeah, that would do it
[15:20] <knome> and with the current config, we're about 10MB undersized, and that's waste of time
[15:21] <knome> do we have a backlog of what language we would like to reintrodue?
[15:21] <micahg> we might be able to get away with it w/out dropping anything
[15:21] <knome> maybe fi, since it's so widely spoken
[15:21] <knome> ;]
[15:21] <pleia2> lol
[15:21] <micahg> de seems to be it
[15:21] <knome> micahg, i really don't want to be oversized for b2, so i'd rather do that tweaking after b2
[15:21] <SkippersBoss> at least amongs the Xu developers
[15:22] <knome> micahg, unless you're willing to handle the respin requests and stuff
[15:22] <micahg> knome: it doesn't require an upload, so we can flip the bit and see what happens tomorrow
[15:22] <knome> micahg, oh, right, yeah, we have enought time to revert
[15:22] <knome> sounds good
[15:23] <knome> #action micahg to drop 'pt' from amd64 and reintroduce 'de' for i386
[15:23] <meetingology> ACTION: micahg to drop 'pt' from amd64 and reintroduce 'de' for i386
[15:23] <knome> #action micahg to make sure i386 doesn't go oversized, and if it goes, drop gnome-sudoku tomorrow before freeze
[15:23] <meetingology> ACTION: micahg to make sure i386 doesn't go oversized, and if it goes, drop gnome-sudoku tomorrow before freeze
[15:24] <knome> i believe that's it for the beta 2 prepping altogether!
[15:24] <knome> #subtopic Schedule next meeting
[15:24] <pnarciso> so pt which have a much more userbase is being droped for de?
[15:24] <knome> pnarciso, no.
[15:25] <knome> pnarciso, pt is dropped from amd64, de introduced to i386
[15:25] <smartboyhw> pnarciso: pt is dropped in amd64 and de is introduced in i386
[15:25] <smartboyhw> Or am I wrong?
[15:25] <pnarciso> okok, I read wrong, sorry
[15:25] <knome> pnarciso, we're oversized for amd64, but have a bit extra spae for i386
[15:25] <bluesabre> that was scarily similar, knome & smartboyhw
[15:25] <knome> pnarciso, np, good to have it sorted
[15:25] <knome> bluesabre, :P
[15:26] <smartboyhw> I pressed ënter 1 sec slower than knome, bluesabre you know:(
[15:26] <knome> bluesabre, i believe it is the same than with great minds and idiots - they all think the same
[15:26]  * knome hides
[15:26]  * smartboyhw hides
[15:26]  * smartboyhw thinks knome is saying that he is an idiot:(
[15:26] <knome> hsst, don't take the same hideaway, they'll notice us idiots here
[15:26] <knome> smartboyhw, i was saying we both are, but i was just kidding :P
[15:26]  * bluesabre is king when everyone else hides
[15:27] <smartboyhw> ;P
[15:27] <knome> mostly referring to myself...
[15:27] <knome> so, next meeting
[15:27] <knome> should we have one just before B2 release?
[15:27] <smartboyhw> +1
[15:27] <knome> i will not take "we will not release B2" as an answer, so...
[15:27] <bluesabre> Yeah, who knows what will change at the last minute for us to panic about
[15:28] <smartboyhw> If we don´t have B2 we don´t even HAVE a beta.....
[15:28] <knome> #info Next meeting: September 26th, 15UTC
[15:28] <SkippersBoss> that's not an option
[15:28] <knome> #endmeeting
[15:28] <meetingology> Meeting ended Wed Sep 19 15:28:18 2012 UTC.
[15:28] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/xubuntu-devel/2012/xubuntu-devel.2012-09-19-14.56.moin.txt
[15:28] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/xubuntu-devel/2012/xubuntu-devel.2012-09-19-14.56.html
[15:28] <knome> thanks!
[15:28] <bluesabre> yay
[15:28] <knome> i'll update the minutes later
[15:28] <smartboyhw> yay thanks knome
[15:28] <SkippersBoss> H
[15:28] <smartboyhw> bye now gotcha sleep
[15:28] <knome> np
[15:28] <SkippersBoss> THAT WAS A QUICKY
[15:28] <pleia2> I won't be around for the next meeting
[15:28] <SkippersBoss> NITE nite smartboyhw
[15:28] <SkippersBoss> pleia2, don't say that
[15:29] <knome> pleia2, heh, yeah. TRAITOR!
[15:29] <SkippersBoss> youl b fine in africa
[15:29] <pleia2> I said last week when we scheduled this one that I wouldn't be :P
[15:29] <SkippersBoss> besides there is excelent 3g cover in ghana
[15:29] <pleia2> SkippersBoss: nah, holiday
[15:29] <SkippersBoss> oops
[15:29] <SkippersBoss> sure
[15:29] <pleia2> ghana isn't until October :)
[15:29] <knome> pleia2, well, you can make it up by carrying all my stuff during uds, and taking care of my, eh... hydration
[15:29] <pleia2> lol
[15:30] <SkippersBoss> just realised
[15:30] <knome> :]
[15:30] <knome> SkippersBoss, yes?
[15:30] <SkippersBoss> knome, rub it in
[15:30] <pleia2> I think it's more like your dehydration
[15:30] <knome> lol
[15:30] <knome> i was thinking about the barley-sort
[15:30] <pleia2> yep
[15:30] <knome> :)
[15:30] <knome> well yeah, you're right
[15:31] <knome> SkippersBoss, was there something you just realized? :)
[15:31] <knome> SkippersBoss, or was that about pleia2/ghana/october
[15:32] <SkippersBoss> last thing
[15:32] <knome> sure
[15:32]  * micahg also won't be here for the next meeting
[15:32] <knome> oh, right
[15:32]  * knome is on a misunderstanding-streak
[15:32] <knome> micahg, yeah, i hope there's no need for you to be :)
[15:32] <knome> or else i'll kick the release team in the ankles :)
[15:32] <pleia2> hehe
[15:33] <knome> micahg, btw, something we should get fixed for R: bug 996791
[15:33] <knome> micahg, that has quite high heat
[15:34] <pnarciso> Duplicated drives in thunar and desktop bug is still there
[15:34] <knome> pleia2, how confusing it is that your LP nick is lyz.
[15:34] <pleia2> indeed
[15:35] <micahg> knome: not a xubuntu specific issue (should be fixed upstream ideally)
[15:35] <pleia2> all my email addresses are lyz@ so it has to be that way :)
[15:35] <knome> micahg, yeah, "we should get fixed" :)
[15:37] <knome> pnarciso, # ?
[15:37] <SkippersBoss> need to some boring grownup stuff ((c) Pleia)
[15:38] <SkippersBoss> CU all l8r
[15:38] <knome> SkippersBoss, see you :)
[15:38] <knome> https://blueprints.launchpad.net/ubuntu/+spec/other-r-xubuntu-bugs
[15:39] <knome> go to visit the "gentlemens'"
[15:39] <pnarciso> https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1039375
[15:40] <pnarciso> https://bugs.launchpad.net/ubuntu/+source/xfce4/+bug/1044896
[15:44] <pnarciso> a small bug that I detected and reported directly to xfce devs https://bugzilla.xfce.org/show_bug.cgi?id=9280 , x-chat icon dissapears when I disable the compositor
[15:44] <knome> yeah, that's not for this list :)
[15:47] <pnarciso> do you have any contact with xfce devs? their mailing list is very quiet
[15:47] <knome> #xfce-dev is your best bet, but that's not too good
[15:48] <elfy> knome: which is not for this list - xchat or thunar
[15:48] <knome> i mean, summer was really quiet, but it's starting to be a bit more active again
[15:48] <knome> elfy, xchat
[15:48]  * micahg wants to drop xchat, but no one else seems to agree :)
[15:48] <knome> micahg, maybe for R if we're still struggling with space :)
[15:48] <micahg> well, I'd like to get rid of one of our excess stacks if we can for R
[15:48] <pnarciso> I like x-chat better than pidgin for irc
[15:49] <knome> micahg, well yeah, sure.
[15:57] <elfy> pnarciso: trouble is xchat is not good for anything else :)
[15:57] <elfy> but I agree :)
[16:08] <knome> pidgin is "okay" for irc, if you join now and then, and don't want too complex configuration
[16:14] <Sysi> since you're probably online if you want irc and there's pidgin for emergency live-sessions I think dropping xchat should be considered
[16:14] <elfy> knome: +1 I use it when I'm in and out of live sessions
[16:15] <elfy> and as pidgin can be used for other things - makes sense to drop xchat to me
[16:15] <knome> yeah, then we also should consider gthumb/ristretto too
[16:16] <elfy> might have been good to consider that prior to the doc change :)
[16:23] <bluesabre> I think pidgin works pretty well for irc, with the exception that you can't set masks and stuff.
[16:23] <bluesabre> For R, I'm in favor of getting rid of gthumb and ristretto, and bringing in shotwell.  It's standalone viewer works like a charm for everything I've thrown at it.
[16:25] <knome> elfy, for R definitely, not for Q
[16:25] <knome> bluesabre, what about CMYK PSD's? ;]
[16:26] <bluesabre> knome: haven't tried that, but since ristretto dies on SVGs, I'd say it doesn't do too well with that
[16:26] <knome> heh :)
[16:28] <Sysi> I like ristretto except for svgs, but I don't need very extensive functionality
[16:28] <knome> i'm thinking the same, anything that shows jpg/png well is fine for me
[16:29] <pnarciso> makes sense
[16:29] <pnarciso> we don't need two photo viewers
[16:31] <pnarciso> ristretto is enough
[16:33] <elfy> depends if you just want a viewer
[16:33] <elfy> gthumb is enough to do a bit of fiddling with - without installing gimp
[16:34] <Sysi> isn't it needed for importing photos from some cameras too
[16:34] <knome> yeah
[16:34] <elfy> which - ristretto or gthumb
[16:34] <knome> gthumb
[16:34] <elfy> k
[16:34] <knome> those with PTP mode or stf, iirc
[16:35] <elfy> logically it would make sense to me to lose ristretto of the two - but I'm just this guy you know ...
[16:35] <pnarciso> ristretto is part of xfce apps
[16:35] <pnarciso> as it's light
[16:36] <pnarciso> and it's light
[16:37] <elfy> is gnumeric part of xfce apps - cos that's gone ...
[16:37] <bluesabre> gnumeric is a gnome office app, right?
[16:37] <bluesabre> or
[16:37] <bluesabre> used to be
[16:37] <bluesabre> ;)
[16:37] <elfy> no idea - I just remove it on an install anyway
[16:37] <bluesabre> does anyone even know about gnome-office now
[16:38] <bluesabre> basically abiword, gnumeric, and dia
[16:38] <knome> not really
[16:38] <knome> most just want libreoffice anyway
[16:38] <elfy> never used any of them in 5 or 6 years bluesabre
[16:38] <knome> but it would be quite weird to not ship a document editor
[16:38] <elfy> agreed
[16:38] <bluesabre> yeah
[16:39] <knome> being a "part of xfce (apps)" is no argument for inclusion, and gets next to no preference
[16:39] <knome> delivering a feature we need is the most important thing
[16:39] <mips1911> why does the image have to fit on a cd if you don't mind me asking? What's wrong with a 800MB image?
[16:40] <knome> micahg, many of our users still use CDs, we believe.
[16:40] <knome> mips1911, ^
[16:40] <knome> mips1911, sorry, autocomplete fail
[16:40] <knome> micahg, ^
[16:40] <knome> ARGH.
[16:40] <Sysi> if your computer doesn't boot from usb, you don't have one or making one fails
[16:40] <knome> yup.
[16:41] <mips1911> if your computer does not boot from usb it's probably to slow for xubuntu
[16:41] <knome> mips1911, not really, there are a lot of machines that don't boot from usb but are fast enough
[16:41] <Sysi> not really, I have one totally usable like that
[16:41] <Sysi> actually maybe two
[16:41] <knome> and your usb ports might just be broken.
[16:42] <knome> or you didn't have extra usb sticks available
[16:42] <mips1911> Dunno, I have a 2004 laptop here that can boot from usb but it's to slow in my opinion
[16:42] <mips1911> let them eat cake I say :)
[16:42] <knome> mips1911, we're not saying that couldn't happen too
[16:43] <mips1911> even lubuntu is to slow for it
[17:01] <pnarciso> I've noticed the other day that clutter was downloaded as an update, do xubuntu have any apps that needs clutter?
[17:09] <knome> pnarciso, it should be off from today's images.
[18:55] <knome> mr_pouit, hey :)
[20:39] <knome> https://wiki.ubuntu.com/Xubuntu/Meetings
[20:39] <knome> meeting minutes for today's meeting are up
[20:39] <pleia2> I saw you working with mdke, yay!
[20:39] <knome> yeah
[20:40] <knome> feel free to join us :P
[20:40] <pleia2> also I just died a little inside when I realized I was so excited about documentation
[20:40] <pleia2> :P
[20:40] <knome> awwwh1
[20:40] <knome> hmm
[20:40] <knome> s/1/!/
[20:40] <pleia2> working working
[20:40] <knome> bad excuse miss ;)
[20:40] <pleia2> I fixed a 10 year old php form
[20:40] <pleia2> it was awful :)
[20:41] <knome> i'm sure
[20:41] <knome> i created a "patch" for the ubuntu wiki today :P
[20:41] <knome> italics wasn't italics
[20:41] <knome> need css fix :P
[20:41] <knome> and other similar
[20:42] <pleia2> ah
[20:42] <knome> mmh, fixed window borders in quantal <3
[20:43] <knome> there's still something weird with vbox and dragging with mouse
[20:43] <knome> disabling mouse integration seems to fix it though
[21:51] <knome> pleia2, docs uploaded
[21:52] <pleia2> :D :D
[21:52] <knome> hoo-rahhh
[21:52] <knome> time for a bottle of rum
[21:52] <knome> err..
[21:52] <knome> ;)
[21:54] <pleia2> hehe
[22:28] <knome> pleia2, see #ubuntu-doc
[22:30] <pleia2> I hate useless lp teams
[22:31] <knome> well, considering our new strategy document, it's not completely useless
[22:31] <knome> since people are promoted as xubuntu team members after probation periods on subteams
[22:32] <pleia2> fair enough
[22:32] <knome> and i don't know if there is any other team that could really "host" documentation contributors
[22:32] <knome> do you have a minute and access to the wiki logs?
[22:33] <pleia2> http://dagobah.princessleia.com/Xubuntu/RecentChanges?max_days=90 has everything
[22:33] <knome> right...
[22:35] <knome> humm, should i be able to browse that?
[22:36] <pleia2> let me do a grep against the log file to get something prettier
[22:36] <knome> somehow, that doesn't look right
[22:36] <knome> thanks
[22:37] <pleia2> heh, of course the raw log files don't have usernames coorelated to edits
[22:37] <knome> heh
[22:37] <pleia2> just user ids, which are x-referenced to the directory with users
[22:38] <knome> lol
[22:38] <knome> hmm, i'll PM
[22:47] <knome> some people have been approved/added to ~xubuntu-doc a moment ago, rejoice
[22:47] <knome> pleia2, bug 967878 ?
[22:49] <knome> mr_pouit, stop lurking. we need a new xubuntu-artwork upload.
[22:50] <pleia2> knome: ah yes, adding to my todo list to think about
[22:51] <knome> pleia2, it's linked to the website blueprint too
[22:51]  * pleia2 nods
[22:51] <knome> i'm thinking we're covering that quite well in "get help & support" and "get involved"
[22:52] <knome> and that anything else would be duplication
[22:52] <knome> those pages are directed to different subsets of people, and once you go to either one, you'll get the contact information you need
[22:52] <knome> (eg. if you need help, we don't want them to subscribe to xubuntu-devel and apply for ~xubuntu-team)
[22:53] <knome> s/them/you/
[22:53] <pleia2> well, you probably have the best idea of what the OP had in mind for this bug :)
[22:53] <knome> we were still working on the wiki and all
[22:53] <pleia2> yeah
[22:53] <knome> maybe we don't need that after all.
[22:53] <pleia2> I think what we have is sufficient
[22:55] <knome> one more work item gone away
[22:56] <knome> AND
[22:56] <knome> we don't have any more time-specific items
[22:56] <knome> except the countdown banners should be up soonish, and so; but nothing affecting freezes
[22:56] <pleia2> we win at blueprints!
[22:56] <knome> haha yeah
[22:57] <knome> looking at the overview of flavors, yeah
[22:57] <knome> lubuntu is second at 53%, we have 92% listed, but have more, because that's before our DONE's today
[22:57] <pleia2> I'm really quite pleased about docs, I had my doubts about timing
[22:57] <knome> haha
[22:57] <knome> don't worry baby, i'm an expert...
[22:57] <pleia2> it was a lot of work, and we didn't have so many volunteers early on
[22:57] <pleia2> :P
[22:58] <knome> well, yeah. fortunately we had people who actually wrote and reviewed stuff
[22:58] <knome> we also needed some docbook conversion madness by knome :P
[22:58] <pleia2> hehe
[22:59] <knome> pleia2, btw
[23:00] <knome> https://lists.ubuntu.com/archives/ubuntu-release/2012-September/001946.html
[23:00] <pleia2> haha, yeah I saw
[23:00] <knome> yeah...
[23:00] <pleia2> we got it in just in time! ...oh and then they extended it
[23:00] <knome> yep
[23:00]  * pleia2 shakefist
[23:00] <pleia2> :)
[23:01] <knome> well yeah, it's quite sad that if desktop team needs extended time, freezes are simply postponed
[23:01] <pleia2> sad for translators
[23:01] <knome> i thought the freezes were there for everybody to meet deadlines
[23:01] <knome> well yeah, not for xubuntu translators
[23:01] <knome> we won't have translations for Q
[23:01] <knome> we didn't have them before either...
[23:01] <pleia2> someday we shall learn how?
[23:02] <knome> yeah, something to do during the R cycle too
[23:02] <pleia2> that's good
[23:02] <knome> jbicha and mdke can most probably help with that
[23:03] <pleia2> jbicha mentioned on g+ that he is really going to try to get more people involved with docs next cycle, so I hope that means explaining some more to some of us so we can help
[23:03] <knome> hehe
[23:03] <knome> well, everybody told mdke is super busy
[23:03] <knome> and his idle time was 60 days
[23:04] <pleia2> yeah
[23:04] <knome> when i poked him a bit he was just "oh, i just haven't done anything for ubuntu for ages; of course i'll help you, and hopefully i'll get more motivation too for coming cycles"
[23:04] <pleia2> :)
[23:04] <knome> "oh ok"
[23:05] <pleia2> he does hold all the docs keys
[23:05] <pleia2> nice that he's at least pingable
[23:05] <knome> except that he doesn't have upload rights to xubuntu-doc ;]
[23:05] <knome> so that's it for all the keys
[23:05] <pleia2> doh