[00:06] <__monty__> Mmm, socket.error is a child class of IOError, so should the test for socket.error happen before the test for IOError?
[00:10] <poolie> i wonder why it isn't being handled by the existing code that tries to treat IOError as a user error?
[00:10] <mgz> in python 2.6 and later.
[00:11] <poolie> hi mgz
[00:11] <poolie> ah, perfect
[00:11] <__monty__> Ah, yes the user was using 2.5
[00:11] <poolie> in that case you could just list it in the same exception clause, and perhaps add a comment why it's being caught separately
[00:12] <__monty__> What do you mean by listing it in the same exception clause?
[00:14] <mgz> having it before with a special note about connectivity would also be reasonable
[00:17] <poolie> i meant having (OSError, IOError, socket.error)
[00:17] <poolie> you should also add a test
[00:17] <poolie> i think this is pretty well covered in test_trace so you can go from those examples
[00:19] <__monty__> What would be the best solution, testing it first with a specific message about connectivity or making the message for IOError more general and including OSError and socket.error?
[00:22] <poolie> can you explain the second alternative more?
[00:22] <__monty__> The second alternative is what I understood you were proposing.
[00:23] <poolie> add a test that raises socket.errer
[00:23] <poolie> *error
[00:23] <poolie> check it does not print a traceback
[00:24] <poolie> the easiest way to make this test pass is probably to just also catch that exception in the same way as for IOError
[00:24] <poolie> hm
[00:24] <poolie> actually, on trunk, since we need py2.6 now, this bug may be obsolete
[00:24] <poolie> you could just interactively test that it works
[00:25] <__monty__> How exactly do I test it? How do I try to get a socket.error?
[00:25] <poolie> look at eg test_format_io_error
[00:26] <poolie> probably a good way to get a realistic one is to try to connect to some unlikely port on localhost
[00:26] <poolie> like tcp port 2
[00:29] <mgz> it's safe to just construct your own socket.error
[00:29] <poolie> it is
[00:30] <__monty__> Yes, but how?
[00:30] <poolie> i feel if you do it yourself, you may miss quirks in how python constructs them
[00:30] <poolie> for instance there have been some bugs along the lines of actual python not setting named attributes on errors the way we expected, iirc
[00:30] <poolie> so if it's easy i'd lean towards generating a real owne
[00:30] <poolie> *one
[00:32] <__monty__> I should write a new method in test_trace.py to test if this is no longer a problem in python 2.6, right?
[00:32] <poolie> yes
[00:33] <mgz> so, for instance, in bzrlib.tests.test_trace use test_format_pywintypes_error as a template but raise a likely looking socket.error instead
[00:33] <mgz> ...and I note there I did do what poolie said rather than what I suggested
[00:33] <mgz> in that I called a function that will raise a real error rather than constructing my own
[00:35] <poolie> this will probably cover bug 598158
[00:35] <poolie> well, it's probably a dupe
[00:36] <poolie> in fact both are probably dupes of bug 393173
[00:38] <poolie> sorry bug 393713
[00:39] <mgz> some socket errors are deeply unhelpful so some extra text in the advice param is probably a good idea
[00:41] <__monty__> As extra text just point to bzr.log or something more helpful?
[00:41] <mgz> socket.socket(0) gives me a nice fast error, but that's probably a bad idea
[00:41] <mgz> depends if the constants are standardised at all I guess
[00:42] <poolie> i think there probably the thing is to catch them close to the point they're raised and rethrow something more meaningful
[00:42] <poolie> like try: socketblah: except socket.error:
[00:42] <poolie> raise something("failed to connect to smtp server %s:%d: %s" % (host, port, e))
[00:44] <mgz> ehehe, funny mail from jam about the 2.4b3 release
[00:44] <poolie> :)
[00:44] <poolie> that was such a fun sprint
[00:46] <__monty__> So, the error should be caught before we have to handle it in trace.py? Or did you mean something else poolie?
[00:46] <mgz> poolie, I've got half a thing written trying to convey that sense of fun, if I mail it to you will you proof read?
[00:46] <poolie> sure
[00:46] <poolie> i'd kind of like to consciously understand what we (or i) did right
[00:46] <poolie> to reproduce it
[00:47] <poolie> it seemed like there was just enough focus on having a hit list, but it wasn't overstructured
[00:54] <__monty__> How does the test method work, I make sure an error is raised in the try block, then 'pass' the except block, then 'msg = _format_exception()', then self.assertContainsRe(msg, r"The string for the error here")?
[00:57] <poolie> that sounds right
[00:58] <__monty__> Still how do I raise a socket.error that's realistic?
[00:59] <poolie> like mgz said just a socket.socket(0) could be a good start
[00:59] <spiv> __monty__: hmm, perhaps try to call sock.accept without first calling sock.listen?
[00:59] <poolie> o/ spiv
[00:59] <mgz> or socket.socket() then socket.send("something") yells at you for not being connected
[01:00] <mgz> really realistic ones like timeouts are probably not something we want in the test suite :)
[01:00] <spiv> mgz's idea sounds good too.
[01:00] <spiv> Hi poolie
[01:01] <__monty__> Which one of these is least likely not to fail?
[01:02] <mgz> they should all fail! :)
[01:02] <poolie> either of those last two should be reliable
[01:02] <poolie> if it turns out they're not we can fix it
[01:05] <__monty__> What would the error string look like for the socket.socket() socket.send("string") scenario?
[01:06] <poolie> just try it :)
[01:06] <spiv> python -c "import socket; s = socket.socket(); s.send('string')"   :)
[01:10] <__monty__> Is this correct for the string? Are the backslashes necessary since it's a raw string?
[01:12] <__monty__> r"^bzr: ERROR: \[Errno .*\] Socket is not connected"
[01:15] <poolie> the backslashes are needed if you're trying to match it as a regexp
[01:16] <__monty__> so it's not really necessary in this case since the error will always be: socket.error: [Errno 57] Socket is not connected
[01:17] <poolie> i don't think it's guaranteed to be error 57 on all platforms
[01:17] <poolie> spiv could i mumble at you about bug 220464?
[01:19] <__monty__> Then this is good? r"^bzr: ERROR: \[Errno .*\] Socket is not connected"
[01:19] <poolie> yup
[01:19] <poolie> does it pass?
[01:19] <poolie> try running ./bzr selftest -s bt.test_trace
[01:20] <__monty__> I get this: bzr: ERROR: No module named testtools
[01:20] <__monty__> You may need to install this Python library separately.
[01:20] <__monty__> bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
[01:20] <poolie> yes, you'll need testtools to run the tests
[01:21] <poolie> on ubuntu or debian, apt-get install python-testtools
[01:26] <__monty__> This is the output:
[01:26] <__monty__> bzr selftest: /Users/toon/src/bzr/connection-timed-out-364462/bzr
[01:26] <__monty__>    /Users/toon/src/bzr/connection-timed-out-364462/bzrlib
[01:26] <__monty__>    bzr-2.4.0dev4 python-2.6.5 Darwin-9.8.0-i386-32bit
[01:26] <spiv> poolie: sure; via which medium?
[01:26] <__monty__> ----------------------------------------------------------------------
[01:26] <__monty__> Ran 25 tests in 0.577s
[01:26] <__monty__> OK
[01:26] <__monty__> Missing feature 'meliae' skipped 1 tests.
[01:26] <__monty__> Missing feature 'pywintypes' skipped 1 tests.
[01:26] <__monty__> bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
[01:27] <__monty__> Sorry for the excessive pasting.
[01:28] <poolie> rockin
[01:28] <poolie> spiv, here, or mumble, or the phone
[01:28] <poolie> mostly it's been a while since i touched it so i can't recall if i meant to do anything else before proposing it
[01:29] <poolie> actually if you could just review it now that would be nice
[01:29] <__monty__> Should I submit the change now?
[01:29] <poolie> yes please
[01:29] <spiv> poolie: sure, already started reading
[01:30] <spiv> poolie: So far it looks very nice!
[01:31] <poolie> there's another thing connected but just out of scope
[01:31] <poolie> which is to do with trying to release locks as we terminate
[01:31] <poolie> and there was some discussion at the sprint
[01:32] <poolie> which leaned me a bit closer towards a crash-only design
[01:32] <poolie> iow better to just pretty much terminate when something unexpected happens and then pick up next time
[01:38] <poolie> __monty__: all ok?
[01:39] <__monty__> Yes, I'm composing the cover letter(?) I should mention all three of the bugs right?
[01:39] <poolie> since they're all dupes only the master is enough
[01:39] <poolie> thanks for fixing thins!
[01:39] <poolie> *this
[01:40] <mgz> poolie: I've emailed you a thingy.
[01:40] <poolie> ta
[01:41] <poolie> that's really nice, thanks!
[01:41] <poolie> i didn't know about bialix's shirt
[01:41] <poolie> i don't have any particular corrections or suggestions
[01:41] <poolie> i'd like to put it on the blog too
[01:42] <poolie> which will make it easy to add links
[01:42] <poolie> do you have access?
[01:43] <mgz> not currently.
[01:44] <poolie> ok sent
[01:47] <__monty__> Merge proposed. Thank you for all the help poolie, mgz. :)
[01:48] <mgz> thanks poolie, and thanks monty :)
[01:48] <poolie> np, thanks for your contribution
[01:49] <__monty__> See you later!
[01:51] <mgz> okay, gzlist on wordpress is now me.
[01:51] <mgz> darn minimum four character username restrictions :)
[01:56] <spiv> mgz: your nick is too compressed :)
[01:57] <spiv> poolie: branch reviewed, very nice
[02:06] <poolie> thanks spiv
[02:07] <mgz> okay, I think the post should be in the review queue on the blog
[02:07] <mgz> feel free to edit or change if anyone spots something that could do with improving
[02:14] <james_w> mgz, it looks like it is published
[02:14] <james_w> "Someone even" in the second sentence a mistake?
[02:15] <mgz> *how
[02:15] <mgz> dammit, I thought I'd changed that :)
[02:15] <poolie> i published it
[02:15] <poolie> well spotted
[02:15] <poolie> you should still be able to edit it?
[02:15] <poolie> spiv interesting question about reraising incidental errors
[02:16] <poolie> hm
[02:16] <mgz> hm I don't see the edit button
[02:20] <poolie> i'll fix it
[02:21] <mgz> I've got some fixes for your lock breaking branch in return :)
[02:22] <poolie> :)
[02:39] <poolie> mgz are you going to comment on the mp - should i wait for you?
[02:39] <mgz> yes please.
[02:39] <mgz> will try and be fast.
[02:40] <poolie> np
[02:40] <poolie> just didn't want to stand around looking silly
[02:48] <mgz> okay, nearly there
[02:49] <mgz> I don't really need to implement this twice...
[02:49] <mgz> requiring 2.6 means has_ctypes should always be true
[03:14] <mgz> okay, tests pass
[03:15] <poolie> i wonder if i should change this to cast to unicode to get the human form, rather than to str
[03:15] <poolie> to make it safer for py3 and indeed also for unicode values
[03:22] <mgz> it's generally the right thing to do
[03:23] <mgz> but it's a little annoying in Python 2 because it can be dangerous to pass somethings unicode rather than str
[03:23] <mgz> it can break exceptions and such like
[03:29] <mgz> okay, posted branch poolie
[03:29] <poolie> thanks mgz
[03:30] <mgz> I'm a bit past a coherant review, hopefully the changes make sense, otherwise it'll have to wait till tomorrow :)
[03:31] <poolie> sure
[03:31] <poolie> i have some other things to fix in it anyhow
[03:31] <poolie> have a good night
[03:31] <mgz> I got a few of them in the branch I think. Night poolie!
[07:02] <vila> woohoo, nice blog post mgz !
[07:52] <poolie> it is isn't it
[07:52] <poolie> hi vila
[07:53] <poolie> i might call it a day though
[07:53] <vila> poolie: heya
[07:53] <poolie> thanks for the release
[07:53] <poolie> vila i don't know if you saw the mail from https://bugs.launchpad.net/bzr-cvsps-import/+bug/788914
[07:53] <poolie> but it would be nice to review and merge his patch
[07:53] <poolie> *yawn*
[07:54] <vila> hmm, never touch this code so far :-/
[07:54] <poolie> they should be shallow fixes
[07:54] <poolie> or maybe we can get lifeless to review them
[07:55] <poolie> anyhow i should really go
[07:55] <poolie> have a good day
[07:55] <poolie> will try to be online later next week
[07:55] <vila> have a nice weekend
[07:55] <poolie> you too
[08:02] <spiv> vila: you might enjoy https://code.launchpad.net/~spiv/bzr/subprocess-log-in-test-details/+merge/62612
[08:03] <spiv> It might help demystify some babune failures.
[08:04] <vila> spiv: amazingly, I just found a trick to avoid the hangs...
[08:04] <spiv> Heh.
[08:04] <spiv> What's the trick?
[08:04] <vila> redirecting *selftest* stderr at the invocation seems to be enough (how that's inherited is yet unclear, but probably works for all cases where we don't explicitly handle stderr)
[08:05] <vila> so, what did I collect there ?
[08:05] <vila> I'm glad you asked: http://paste.ubuntu.com/613637/
[08:06] <vila> *2* deprecation warnings... sound very small to block a pipe no ?
[08:06] <spiv> Well, depends on what the pipe's buffer size is
[08:06] <vila> hmm, 277 chars...
[08:06] <vila> awfully close to 256 :)
[08:06] <spiv> And how close we were to hitting the buffer limit without the extra noise :)
[08:07] <spiv> Yeah.
[08:08] <spiv> That worryingly suggests that jenkins or whatever is driving selftest in the slave isn't draining both stdout and stderr concurrently.
[08:09] <vila> my head spins a bit trying to understand the ramifications...
[08:09] <vila> dosen't clearly explain why your patch for osx/windows didn't work, I should retry that now
[08:10] <spiv> It also appears to disprove my optimism in saying “It's hopefully safe to assume that the terminal or whatever is draining both our stdout and stderr reliably!” :(
[08:11] <vila> yup, that remark triggered my trick test
[08:11] <vila> on the other hand, selftest is not supposed to output anything on stderr other than potential issues that needs to be addressed
[08:11] <vila> does that sound correct ?
[08:12] <spiv> vila: well, deprecation warnings sound like fair game for stderr to me
[08:12] <vila> yes, as things that should be addressed
[08:12] <spiv> And it's always possible to have lots of them
[08:12] <vila> hmm
[08:12] <vila> let me clarify
[08:13] <vila> we seem to encounter various issues with anything that appears on stderr
[08:13] <spiv> And there's some value in testing that we work in environments that do emit deprecation warnings.
[08:13] <spiv> i.e. with older libraries
[08:13] <vila> jenkins and subunit being brittle there
[08:14] <vila> so diverting stderr at the top level and investigating issues found there separately may help us reach a more robust babune
[08:15] <spiv> And in extreme situations (i.e. sufficiently bad bugs) we might even get subprocesses exploding with tracebacks on stderr
[08:15] <vila> I agree there is valuable information there, I don't mean to redirect to dev/null !
[08:15] <spiv> Sure I didn't take it to mean that.
[08:15] <vila> right, my guess is that this should trigger test failures nevertheless
[08:15] <spiv> I'm just saying we can't rely on driving stderr output in babune down to zero either
[08:16] <spiv> We have to be able to cope with it (even if we do manage to get it down to zero normally, bugs happen)
[08:16] <vila> oh, right, may be not in the short term, but that's still a good target ;)
[08:16] <vila> I don't feel especially at ease with this deprecation warnings
[08:16] <spiv> It's probably a good target, but we can't depend on it. :)
[08:16] <vila> indeed
[08:17] <vila> so 2>selftest.stderr and cat selftest.stderr may be a useful trick
[08:17] <spiv> In the extreme case imagine someone introduces a syntax error in lazy loaded code that is only hit by a test subprocess
[08:17] <spiv> vila: +1
[08:17] <spiv> buildbot gets this right :/
[08:17] <vila> ?
[08:18] <vila> oh, you mean by handling it by default ?
[08:18] <spiv> It reads stdout and stderr from the subprocess just fine (and even shows stderr in red in the default console output display)
[08:18] <spiv> Right
[08:19] <vila> I can't believe (yet) the solution to so many babune problems could be that simple...
[08:19] <vila> time for more coffee :)
[08:19] <vila> hmm, by the way...
[08:20] <vila> OMG !
[08:20] <vila> fullermd is not there !
[08:20] <vila> Hell must be frozen !
[08:21] <vila> ok, so plan: 1) more coffee, 2) look at spiv's stderr handling patch..... 4) profit !
[08:28] <spiv> vila: given the state of http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-merged-reviews.derivative%29 you have quite a challenge as patch pilot today :)
[08:29] <spiv> Hangover from the sprint I guess!
[08:29] <vila> well, I backuped jelmer so I have a bit of lag, but I'm also waiting for reviews for my own proposals...
[08:30] <vila> may be I should just land them pretexting a user error while landing and approved one without realizing some pre-requisites weren't approved ;-D
[08:47] <vila> spiv: still hanging on OSX :-/
[08:49] <spiv> vila: :/
[08:49] <spiv> vila: does subprocess-log-in-details help at all?
[08:49] <vila> not tried that one yet
[08:49] <spiv> (Obviously it won't help the hang, but maybe it'll give better info if you interrupt the hang)
[08:50] <spiv> vila: I just did a couple of very quick reviews for you
[08:50] <spiv> And now I'm off!
[08:50] <vila> great !
[08:50] <vila> have a nice week-end !
[08:50] <spiv> Happy hacking, piloting, and babune-wrangling.
[08:51] <spiv> And have a nice weekend when you finally get there :)
[09:21] <vila> Riddell: hello there !
[09:22] <vila> Riddell: I realized my comment on your https://code.launchpad.net/~jr/bzr/330063-merge-non-existing/+merge/61728 may need explanations about bb:tweak
[09:22] <vila> Riddell: or do you understand the meaning already ?
[09:22] <Riddell> it means tweaking the blackbox tests?
[09:22] <vila> hehe no
[09:23] <vila> BB == bundle buggy, that's what we used before reviews were available on lp
[09:23] <vila> different votes were available there and we still miss the 'tweak' one on lp
[09:23] <Riddell> ah
[09:24] <vila> we use it to convey: your patch looks good, you can land it without an additional review as long as you agree with the modifications asked by the reviewer and implement them
[09:24] <vila> but shorter ;)
[09:25] <vila> since this doesn't exist on lp, we use an idiom which is: review: needsfixing, status: approved
[09:26] <vila> Riddell: do you need further help with this proposal ?
[09:26] <Riddell> hopefully not, I'll get to it shortly once I've looked at my e-mail (I was taking a swap day yesterday)
[09:27] <Riddell> but I'll let you know if i do :)
[09:27] <vila> Riddell: ok, cool, welcome back :)
[10:43] <spiv> vila: heh, TestImportTariffs.start_bzr_subprocess_with_import_check explicitly uses the real $HOME!
[10:44] <spiv> vila: so you could argue that including ~/.bzr.log in the details is therefore appropriate ;)
[10:44] <vila> oh my, I routinely have Megs there !
[10:45] <vila> I just didn't look at the result of my first run even if it was limited to ~10 tests, imagine what it will contain for a whole test suite !
[10:46] <spiv> vila: it's just TestImportTariffs
[10:46] <vila> Megs * ~20.000, we will end up with GOs !
[10:46] <vila> ha right, still we will end up with gOs :)
[10:47] <spiv> It shouldn't be much:
[10:47] <spiv> * details are discarded for passing tests
[10:47] <spiv> * only TestImportTariffs uses start_bzr_subprocess with a real $HOME
[10:47] <spiv> Worth checking my assumptions are right, of course.
[10:48] <vila> why not make them use a temp home then ?
[10:48] <spiv> But they should be ;)
[10:48] <spiv> “        # Normally we want test isolation from the real $HOME but here we
[10:48] <spiv>         # explicitly do want to test against things installed there, therefore
[10:48] <spiv>         # we pass it through.
[10:48] <spiv> ”
[10:48] <vila> argh
[10:48] <spiv> i.e. test_import_tariffs wants to make use ~/.bazaar/plugins
[10:48] <spiv> There's probably a better way to do that
[10:49] <vila> we rotate at 4M I think
[10:49] <spiv> Maybe set BZR_PLUGIN_PATH for the subprocess to explicitly be exactly what the parent uses
[10:49] <vila> that's 2M of noise on average ;-/
[10:52] <Riddell> vila: should I be on the patch pilot schedule?
[10:52] <spiv> vila: I don't follow
[10:52] <spiv> vila: it only keeps the log contents if the test fails
[10:53] <spiv> vila: so normal cost: 0
[10:53] <spiv> vila: no matter how large ~/.bzr.log is for that one test
[10:53] <vila> Riddell: up to you, feeel free to insert yourself, probably at the end of the cycle so you get some time to accomodate
[10:54] <vila> spiv: meh, maybe I misread your patch but I thought your were installing some automatic trigger for all subprocess calls ?
[10:55] <spiv> vila: for all start_bzr_subprocess calls
[10:55] <spiv> vila: but for all tests *except* TestImportTariff $HOME is some temporary directory
[10:55] <spiv> vila: and all in-process logging goes to an in-memory log during selftest
[10:56] <spiv> vila: so the only contents it will find are from test subprocesses, with the exception of TestImportTariff
[10:56] <spiv> (Ok, the doctests use real bzr $HOME too, but I don't think they use start_bzr_subprocess)
[10:59] <vila> spiv: right, worth adding as comments then, I'll look into it again later (I thought I said that in the review no ?)
[10:59] <vila> anyway, thanks for the explanations, will avoid useless roundtrips
[11:00] <spiv> vila: sure, just some drive by info as I was peeking at my mail :)
[12:57]  * Riddell blogs http://www.kdedevelopers.org/node/4435
[13:37] <Morbus> here's an odd question: is there anyways, from bzr command line, to "know" if someone has proposed a merge request?
[13:37] <maxb> Riddell: 1) Nice. 2) I'm confused by your user icon. 3) s/zx/xz/
[13:37] <Morbus> i have a private lp account, and I need to integrate it with some CI tools, and it requires me knowing merge requests.
[13:37] <maxb> Not via the bzr command line, no
[13:38] <Morbus> damn. ok.
[13:38] <Morbus> so i instead need to figure out some way of automating a browser request to the LP MR page.
[13:38] <Morbus> which would normally be easy if it were public, but it's private.
[13:38] <Riddell> maxb: the user icon comes from Umbrello which was my university project back in the day
[13:39] <Riddell> Morbus: can't you use launchpad APIs?
[13:39] <Morbus> Riddell: didn't even know LP had APIs :)
[13:39] <Riddell> take a look at https://help.launchpad.net/API/launchpadlib
[13:39] <Riddell> I'm not sure if merges have APIs, but they ought to if there's any justice in the world
[13:40] <Morbus> heh, heh.
[13:40] <Riddell> ask in #launchpad to find out
[13:40] <maxb> Morbus: You probably want to look at the Launchpad Web Services API, and in particular, if you use python and launchpadlib, lp.branches.getByUrl(url="lp:.......").getMergeProposals(...)
[13:40] <Morbus> of course, i don't know any python, but i could figure it outl, I suspect.
[13:40] <Morbus> maxb: thanks!
[13:40] <Morbus> Riddell: you too :D
[13:41] <Morbus> hrm. if it's just a webservice that seems to export JSON, I shouldn't have to use python lib...
[13:42] <maxb> Python is not the only integration possibility, but it is the one with the most advanced client libraries
[13:42] <Morbus> sure.
[13:42] <Morbus> i don't necessarily need a whole shebang - i /just/ need the list of branches that have a merge request in.
[13:42] <Morbus> everything else i can handle from the command line locally.
[13:43] <maxb> Morbus: Try hitting this URL, then: https://api.launchpad.net/1.0/~bzr-pqm/bzr/bzr.dev?ws.op=getMergeProposals&status=Approved
[13:44] <Morbus> maxb: right. i presume that's protected by the same cookie auth as a private project is?
[13:44] <Morbus> cookie/session auth?
[13:45] <maxb> If it works, that's accidental.
[13:45] <Morbus> how do you mean?
[13:45] <Morbus> private thingies aren't supposed to be in the API?
[13:45] <maxb> The api.launchpad.net vhost is supposed to be accessed via OAuth tokens for authorization
[13:46] <Morbus> ah.
[13:46] <Morbus> does the pythonlib handle that too?
[13:47] <maxb> yes
[13:47] <maxb> Launchpad.login_with is the main entry point for authenticated access
[13:48] <Morbus> hrm. i think i tweaked this wrong: https://api.launchpad.net/1.0/~morbusiff/examiner/trunk?ws.op=getMergeProposals&status=Approved
[13:49]  * maxb disappears for lunch, back ~15mins
[13:49]  * Morbus heads off to try the pythonlib.
[13:56] <maxb> or 5mins as the case may be
[13:56] <maxb> Morbus: Try hitting https://launchpad.net/api/1.0/~morbusiff/examiner/trunk?ws.op=getMergeProposals&status=Approved with your cookie
[13:56] <Morbus> same error.
[13:56] <Morbus> Object: <lp.registry.model.personproduct.PersonProduct object at 0x12fd1fd0>, name: u'trunk'
[13:57] <maxb> Hm
[13:57] <maxb> No idea then, sorry
[13:57] <Morbus> i woudln't worry too much about it now. got launchpadlib installed and i'm gonna fiddle with that for a bit.
[13:57] <maxb> Probably time to hop over to #launchpad for any further questions
[13:58] <__monty__> If I want to rename a branch can I just rename the directory?
[13:59] <__monty__> Or can I use bzr mv oldbranch/* newbranch/   ?
[14:00] <maxb> just rename the directory
[14:00] <__monty__> ty
[14:07] <Morbus> hrm. where does this launchpadlib store the OAuth details I'm abotu to put in?
[14:08] <Morbus> the script will be running as a different (non-Unix) user than my current Unix user, so I don't want it to overwrite my own data.
[14:09] <Morbus> wrong chan.
[14:14] <Riddell> ug, I keep using the broken "s" for submit option on feed-pqm
[14:14] <Riddell> lifeless: is it true you have a good reason for keeping that around?
[14:17] <vila> Riddell: hehe, was just reading such emails :)
[14:21] <Riddell> poolie: if you add me to ~hydrazine-core I'll set up daily builds so the packaging is no longer a year out of date
[14:21] <Riddell> I might also get rid of the broken "s" option on feed-pqm while nobody is looking :)
[14:27] <vila> Riddell: Propose a branch for merge, I run from sources ;)
[15:27] <lifeless> Riddell: nope
[15:27]  * lifeless disappears
[15:28] <Riddell> oh good
[15:57] <vila> spiv: wake up ! wake up ! I have good news !
[16:03] <vila> spiv: what ? Not even 1AM and you're not there... Sheesh
[16:04] <vila> For the rest of the crowd: one source of selftest hanging on babune shut got a head-shot, thanks to spiv ;)
[16:04] <vila> For the rest of the crowd: one source of selftest hanging on babune just got a head-shot, thanks to spiv ;)
[16:04] <vila> just not shut... tyops are back
[16:05] <vila> I blame fullermd
[16:05] <mgz> it's generally his fault.
[16:07] <mgz> vila: can you run a branch of mine on one of your forking babune slaves?
[16:07] <mgz> I think I fixed the remaining pain, just want to double check before proposing
[16:07] <vila> mgz: sure
[16:08] <vila> which branch and which subset ?
[16:08] <mgz> lp:~gz/bzr/cleanup_testcases_by_collection_613247 as always hang fix before r
[16:08] <mgz> ...interesting edit
[16:08] <mgz> that branch, but merge in whatever you need to make a full run work too.
[16:08] <vila> say that again ?
[16:09] <mgz> so, the import tariff hang fix if that was an issue on the slae
[16:09] <mgz> *slave
[16:09] <vila> I'd prefer a significant subset, not *all* hangs are fixed, I have a couple of pretty good silver bullets now tough
[16:09]  * mgz blames vila's infectious typos
[16:09] <vila> hehe
[16:10] <vila> justasec, a couple of zombies to kill first
[16:10] <mgz> `-s bb. -s bt.test_` isn't bad, but I want a full run to compare resource usage really
[16:11] <mgz> I got it through a complete selftest on the laptop (after stopping X, had som OOMs trying to fork otherwise), so it should run inside 240MB or so
[16:11] <vila> hmm, a full run will be more complex *right now*, let's try with the subset and ping me again if I forget the full one
[16:11] <mgz> okay
[16:12] <vila> but how will you check resources usage on babune ?
[16:12] <mgz> but parallel=fork please, and optionally -Euncollected_cases
[16:12] <mgz> ^...it doesn't give metrics? er... speed I guess then.
[16:12] <vila> hmm, you know what ? File a bug on lp against babune so I can better track that
[16:13] <vila> yeah, speed could be a good indirect indicator
[16:14] <vila> hmm, bt.test_ will include tariff, no good, can *you* merge lp:~vila/bzr/import-tariff-test-subprocess-deadlock  instead ?
[16:15] <vila> can we start with -s bb instead ?
[16:15] <mgz> okay, -s bb. then
[16:15] <vila> or is it not good enough ?
[16:15] <mgz> that should be clean though.
[16:16] <vila> mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/109/aggregatedTestReport/
[16:19] <vila> crap typo in the branch name ;)
[16:21] <mgz> ehhee
[16:21] <mgz> add -s bt.test_selftest to the subset if you've not restarted yet
[16:21] <mgz> that should give some output
[16:22] <vila> I did, but it' soon enough to cancel
[16:24] <vila> hmm, 3 slaves running concurrently, if bad things happen, don't take the blame...
[16:24] <vila> ...or not too fast ;)
[16:25] <vila> http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/111/aggregatedTestReport/
[16:26] <vila> mgz: gentoo failures already available, shallow ?
[16:26] <mgz> hm, that's the hard test case.
[16:27] <vila> mgz: same number on freebsd, karmic, osx (macadam is osx)
[16:27] <vila> Oh, I didn't specify -Exxx
[16:27] <vila> if that helps...
[16:27] <mgz> should work anyway, but those failures are from trying to exercise the parallel=fork code
[16:28] <mgz> which is... tricky
[16:28] <vila> unexplored territory.. unfortunately
[16:29] <vila> mgz: which makes me believe you're not splitting your proposal enough :-D
[16:29] <mgz> the code needs to work...
[16:30] <mgz> I can continue landing things that don't actually fix the issue for ever
[16:30] <mgz> but maybe I'll split fixing parallel=fork from the rest.
[16:31] <vila> mgz: well, -Euncollected_cases as a first step would be good to start with no ?
[16:31] <vila> mgz:  if it requires *not* using --parallel, I'll still buy it
[16:31] <mgz> not if it prints every single test case when you run selftest with --parallel=fork :)
[16:32] <vila> mgz: I can live with such a limitation as long as it doesn't break --parallel=fork when I *don't* use it !
[16:33] <vila> mgz: if we reach the point where the test suite can fully run without OOMing that would make me extremely happy
[16:34] <mgz> what's the subunit version on those slaves?
[16:34] <vila> hmm, close to trunk I think, except for the osx one maybe
[16:35] <vila> oh no, even the osx one mounts my source dir
[16:36] <mgz> and testtools?
[16:36] <vila> so, trunk for subunit
[16:36] <vila> hey, let me type :)
[16:36] <vila> trunk too
[16:37] <mgz> hum hum.
[16:37] <vila> but that's not true for the chroots (but you don't care at that point (OMG this is becoming complex again :-/)))
[16:37] <mgz> I'll have to boot the laptop again, darn 2.6 requirement
[16:38] <vila> ha
[16:38] <vila> I updated this week after months of using very old versions...
[16:41] <mgz> hm, passes here. wonder if it's something about being a real multicore machine.
[16:44] <vila> not passing here
[16:44] <vila> just a note:
[16:45] <vila> have a look at my last --exclude ORed proposal for a trick to use short names for tests, you will then be able to use assertEquals instead of assertContains
[16:45] <vila> no big deal but I feel better not using regexps when I can avoid them
[16:46] <mgz> yeah, saw that.
[16:46] <mgz> still need contains, because it looks at the whole output
[16:46] <mgz> which is good here, because it tells me no tests are being run under fork
[16:46] <mgz> ...not sure why though
[16:47] <mgz> anyway, problem with the test not the case cleanup code
[16:47] <vila> http://paste.ubuntu.com/613816/
[16:47] <vila> after running ./bzr selftest -s bt.test_selftest
[16:48] <vila> I'll ignore the two errors blaming some weird merge
[16:48] <mgz> ...and there it's the reverse problem
[16:49] <mgz> all the cases are leaking
[16:49] <mgz> but the test works.
[16:49] <vila> ha crap, forgot =-site
[16:50] <vila> ok single error, s/<above>/&/ :)
[16:50] <mgz> ...does that help? if not, I'd check bzrlib.tests.fork_for_tests and make sure the two list emptying statements survived the merge
[16:50] <vila> what ? You pushed ?
[16:51] <mgz> nope.
[16:51] <mgz> I'm just trying to understand your results
[16:52] <mgz> ...I'm not sure I have ssh to any machines with python 2.6
[16:52] <vila> oooh, I love "notify = "uncollected_cases" in selftest_debug_flags" :D
[16:56] <vila> mgz: lol, reading your patch, tu quoque mi fili ! using test_suite_factory :)
[16:57] <vila> mgz: but you don't support the arguments, a bit more risky but good enough here
[16:58] <vila> mgz: come to think of it, the conditional code in sefltest for test_suite_factory may be better *outside* of tests.selftest
[16:58] <mgz> there are quite a lot of oddities with how code is arranged for selftest
[16:58] <vila> or rather, always called in the same way
[16:58] <vila> yeah, history
[16:58] <mgz> even having taken an axe to decorators, they're still a pain in the bum
[16:59] <mgz> I can't get a simple param from run_suite down to the code that does the forking
[16:59] <mgz> so have to monkey patch subunit
[17:01] <mgz> I'm still none the wiser about why the slaves didn't manage to run the forking test correctly
[17:01] <vila> only 3 failures on windows
[17:02] <vila> can't you just override the forking code ?
[17:02] <mgz> no fork! ... and they look very familiar failures I thought we'd fixed in the past.
[17:03] <mgz> basically about trying to read a locked pack file.
[17:04] <vila> huh ? Those are new to me... may be I didn't notice them earlier ? Worth investigating
[17:04] <vila> but right, not now, indeed, different failures
[17:04] <mgz> ^I want to test the actual code that selftest uses to do the test splitting and forking, because it has issues now
[17:04] <mgz> I don't like fixing problems if I'm not testing that they won't regress
[17:05] <vila> I was suggesting wrapping them to address your params passing issue
[17:06] <mgz> the problem is there are already too many wrappers :)
[17:07] <vila> nah... the functions you're after are not *yet* wrapped ;D
[17:09] <mgz> can you re-run the subset with the flag on?
[17:09] <mgz> ...I don't think it'll help me understand why the fork tests aren't happy on babune, but I'm out of ideas
[17:11] <vila> fired
[17:13] <vila> mgz: I wonder if your overrides survives the fork...
[17:14] <mgz> ooh, interesting
[17:14] <vila> ...or something
[17:14] <vila> may be silly but since you ran out of ideas, I'm trying to help :D
[17:14] <mgz> of course I've not been running the whole suite under --parallel=fork here
[17:15] <mgz> I'll see if I can get the failure by forcing that
[17:15] <mgz> yeay!
[17:15] <mgz> I can repo.
[17:15] <mgz> okay, will fix.
[17:16] <mgz> ...also, annoying, you don't get a full test count with --parallel=fork just a running total of completed tests
[17:16] <mgz> thanks vila!
[17:18] <vila> me ? Thank my daemon, he send me stupid ideas all day !
[17:24] <vila> mgz: seriously, I have no idea why you're thanking me... any hint ?
[17:25] <mgz> your suggestion was enough to tell me how to reproduce the failures babune got locally
[17:26] <mgz> if I can reproduce, I can fix.
[17:26] <vila> haa, great !
[17:26] <mgz> so, the why might be wrong, but the wondering was useful
[17:52] <smoser> vila, or maxb, could someone handle bug 788736 for me ? if its not a terribly painful thing.
[17:53] <__monty__> u
[17:55] <vila> smoser: justasec, just found it the mail in my backlog (and this has been a busy day...)
[17:55] <__monty__> vila are you online
[17:56] <vila> __monty__: yes, but expect lag, I should have stopped working already ;)
[17:58] <__monty__> vila: About the error for which I'm trying to add a test, do you have any idea why the result differs for you and me?
[17:59] <vila> __monty__: I don't know *what* result you get, but search for socket.error in the code base, there are plenty of cases where the same pattern occurs (EPIPE among others)
[17:59] <vila> smoser: on it
[18:00] <vila> smoser: branches overwritten, deleting tags
[18:00] <vila> smoser: expectedly getting No such tag errors :)
[18:01] <vila> maxb rocks...
[18:04] <Daviey> vila: Whilst looking at that one, fancy actioning maxb's suggestion for sysvinit :) ?
[18:04] <__monty__> vila: Could you glance at the results I get for selftest? https://code.launchpad.net/~toonn/bzr/socket.error-traceback-393713/+merge/62585
[18:04] <vila> smoser: requeued
[18:05] <vila> smoser: running
[18:05] <vila> Daviey: meh, which one ? I think I requeue that recently
[18:06] <Daviey> vila: https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2011-May/000807.html :)
[18:09] <vila> Daviey: :-/ I don't know enough there to act without maxb
[18:09]  * maxb waves
[18:09] <vila> rejoice !
[18:10] <vila> maxb: sudo what ? :D
[18:10] <maxb> I guess the first thing we need to do is decide which of my proposed options w.r.t. sysvinit we are going to go with
[18:10] <maxb> Daviey: How anxious are you to get this sorted?
[18:11] <Daviey> maxb: today doesn't matter
[18:12] <maxb> I would quite like to get james_w's opinion on my email
[18:12] <vila> smoser: comment on the bug when you get some results. Thanks in advance
[18:12] <Daviey> maxb: Throwing away the trivial merge doesn't seem to matter, but it's not a really a good generic fix IMO.  As it's not ideal for other situations
[18:13] <vila> __monty__: just a sec
[18:13] <Daviey> vila: thanks for looking into it
[18:13] <maxb> Daviey: Agreed. Though, the situation that sysvinit is in on Launchpad, with some Ubuntu branches existing but no Debian branches existing, should never occur naturally anyway
[18:13] <vila> Daviey: np, thank maxb ;)
[18:14] <Daviey> maxb: I blame smoser.
[18:14] <maxb> So I'm guessing that someone has been doing some manual fiddling there anyway
[18:14] <maxb> eh?
[18:14] <maxb> Have we crossed sysvinit and python-boto?
[18:14] <Daviey> no, i just enjoy blaming smoser for generic things.
[18:14] <smoser> i probably did it.  i am constantly fighting with bzr. it sees things differently than i do.
[18:14] <vila> __monty__: ok, so what OS are you on ?
[18:14] <vila> Oh, oSX
[18:14] <__monty__> vila: os X.6
[18:15] <smoser> and since i don't have a 'smoser' to blame like Daviey does, i usually just blame bzr.
[18:15] <__monty__> vila: no os X.5.8 (sry)
[18:16] <vila> __monty__: ha ha, an OSX 10.5 user using python2.6...
[18:16] <vila> __monty__: you know what ? We may have more interesting bugs for you :) But let's focus on that one first
[18:17] <__monty__> vila: Sure.
[18:18] <vila> sockets can raise different kind of execptions depending on the platform so you need to be ready for that
[18:19] <__monty__> vila: Anywhere I can find what exception they raise on what platform? Or how do I handle this?
[18:20] <vila> __monty__: we care more about catching all the relevant ones that tracking which platform track which kind, so try grepping the sources for socket.error
[18:23] <vila> __monty__: more concretely, what you should check is not the *message* but rather the class of the exception and then the associated args
[18:23] <vila> you should find plenty of examples in the code
[18:23] <__monty__> Indeed, they are plentiful.
[18:32] <vila> __monty__: so, if you start working again, it's better to put your mp into the 'Work In Progress' state
[18:33] <vila> __monty__: because it will pop up in the list again once you put it back to 'NeedsReview'
[18:33] <__monty__> Ah yes, hadn't thought of that.
[18:34] <maxb> Argh, what?! The python-boto reimport has somehow retained the revisions that were not supposed to be there?!
[19:03] <__monty__> vila: Care to give me another clue? I don't really understand what to learn from the examples in the code.
[19:40] <vila> __monty__: sorry, was afk
[19:40] <vila> so, what are you trying to test exactly ?
[19:54] <__monty__> vila: I'm working on the test for the socket.error which apparently behaves different on linux(?) and on os X.
[19:55] <vila> right, I got that, but why are you doing that ? What is your final goal ?
[19:57] <__monty__> Proving that the socket.error is allready caught? Because it's a subclass of IOError.
[19:57] <smoser> maxb, so any ideas?
[19:58] <smoser> it looks like the score is still :  smoser's stupidity: 1, bzr: 0
[19:59] <poolie> hi all
[19:59] <vila> __monty__: then you want a test that succeeds at catching IOError but fails at catching socket.error ?
[20:00] <vila> poolie: wow, hey !
[20:00] <vila> poolie: is it late for me, early for you or both ?
[20:00] <poolie> :) early for me
[20:01] <vila> rats, I thought I could stop and enjoy my week-end ;-D
[20:04] <poolie> :) well, you can
[20:04] <poolie> isn't it something like 9pm there anyhow?
[20:04] <poolie> i just thought i'd poke at some discretionary lp patches since i'm up so early
[20:04] <vila> one last bug !
[20:04] <vila> :)
[20:04] <__monty__> vila: No I don't think so. Because IOError is allready handled by test_trace.py and socket.error is a subclass thereof (since python 2.6) the cause of bug 393713 no longer produces a traceback. I am now trying to add a test that proves this. So the bug can be closed.
[20:06] <vila> __monty__: if you raise a socket.error and have two exception handlers, one for IOError and one socket.error, if socket.error is a subclass, the IOError handler will trigger, if not, the socket.error handler will trigger, which one triggers tells you if your proof is correct
[20:07] <__monty__> Ah, like so. So I try catching IOError first?
[20:08] <vila> __monty__: just try ! That's what tests are for ! Experimenting with your understanding of the code !
[20:09] <__monty__> Still, I don't really understand how the tests work. Is there someplace I can read up on them? My main difficulty with them is that the except blocks are just 'pass'ed and then the error string is checked.
[20:11] <vila> __monty__: try adding a self.debug() at the first line of your test and execute it step-by-step under pdb, that should help you understand how it works
[20:20] <__monty__> vila: How do I run it in pdb? import pdb; import bzrlib.tests.test_trace; pdb.run('test_format_sockets_error()')    ?
[20:20] <vila> __monty__: try adding a self.debug() at the first line of your test
[20:20] <vila> __monty__: and just re-run ./bzr selfest
[20:23] <__monty__> vila: Can I go on step by step? Because now it just stops, then I type continue and the results for selftest are shown.
[20:24] <poolie> vila, tests using threading seem highly likely to be flakey
[20:24] <poolie>  except KeyboardInterrupt, e:
[20:24] <poolie>             out, err = e.args
[20:24] <poolie> wow that's quite creative
[20:25] <vila> __monty__: you don't know how to use pdb ?
[20:25] <poolie> well, good luck to you
[20:25] <poolie> __monty__: to step, use 's' or 'n'
[20:25] <poolie> the latter steps over function calls
[20:25] <__monty__> vila: No, but 'step' seems to do the trick.
[20:26] <vila> doh, I'm tired, that was a silly question :(
[20:26] <vila> __monty__: http://docs.python.org/library/pdb.html?highlight=pdb#module-pdb
[20:27] <vila> poolie: I disagree
[20:27] <__monty__> vila: I allready have that open, it's just I don't really see what's the point in using pdb. I can go over the code just reading it no? It doesn't seem to give me extra information.
[20:28] <vila> poolie: they are flaky only when they are buggy, at least that's my experience based on debugging the thread leaks
[20:28] <vila> poolie: most of the bugs where bad synchronization
[20:29] <vila> __monty__: you said you didn't understand how the tests worked, the best way to understand them is to see them run, just reading them reading doesn't have the same taste ;)
[20:29] <vila> poolie: s/where/were/
[20:30] <vila> poolie: and unsurprisingly here, that's still a race, involving processes instead of threads but still a race
[20:30] <__monty__> vila: What I meant was, why is(are) there except blocks if they don't do anything?
[20:31] <vila> __monty__: try removing them and you'll soon realize they *do* something
[20:31] <poolie> monty, where?
[20:31] <vila> __monty__: probably swallowing an execption
[20:32] <__monty__> Ah, didn't realise that a trp
[20:32] <__monty__> *Ah, didn't realise that a try block still raises the error if it's not handled.
[20:37] <poolie> it's not so much it still raises it, it just doesn't stop it propagating
[20:39] <__monty__> vila: I'm still not sure about what you said earlier, 'the handler that's triggered will proof socket.error is a subclass'. Why should I proof that, it is true(since python 2.6). I think what I need to proof is that the socket.error is allready handled in test_trace.py, no?
[20:39] <__monty__> poolie: Thank you for correcting.
[20:40] <vila> __monty__: I don't know, does test_trace catch IOError ?
[20:40] <__monty__> Yes.
[20:41] <vila> that's not what your test is showing
[20:41] <__monty__> vila: That's true but how do I show that?
[20:42] <vila> we're running into cycles, where did you start ? What was failing ?
[20:44] <vila> __monty__: the bug report says: "I think that on python2.6 (which is required for bzr2.4) this bug will be implicitly fixed because socket.error has become a subclass of IOError, which does not generate a traceback. We should test that though."
[20:44] <__monty__> nvm what I was typing. In short that's the reason for the test ^.
[20:47] <vila> __monty__: that's what I described above: proof that IOError is a subclass of socket.error, this can be as simple as assertIsInstance(socket.error(), IOError) or assertTrue(issubclass(socket.error, IOError)) or a bit more detailed as I explained above
[20:49] <vila> if you want to go further then you need to find a case which indeed raise a socket.error, explore the call stack, remove the now useless socket.error handlers and check (with tests) that the behavior is still the same
[20:49] <__monty__> vila: What socket.error handlers are you talking about?
[20:50] <pl0sh> hey guys, how can I publish my branches on my own server?
[20:50] <vila> any try block with a except socket.error clause
[20:51] <vila> pl0sh: by allowing people to connect to your server with any protocol supported by bzr: ftp/http/ssh/bzr
[20:52] <vila> pl0sh: the setup ranges from none to quite sophisticated depending on the protocol
[20:55] <pl0sh> let's say http, because my dev's uses winsucks, but my server is a freebsd box
[20:56] <poolie> pl0sh: do they need read write or readonly access?
[20:56] <poolie> if they're developers i guess rw?
[20:56] <poolie> the easiest thing then is to let them ssh in and run bzr over ssh
[20:56] <poolie> the bzr windows client includes ssh support
[20:57] <__monty__> vila: I think I don't really understand the problem then. I thought what I was trying to solve was the fact that people got a traceback when a socket.error occured. Bug 364462 is what I started on but poolie(I think) pointed out it's a dupe of 393713.
[20:57] <pl0sh> poolie well, they have to be able to commit and merge the changes
[20:57] <poolie> monty, where are you with it now?
[20:57] <poolie> ok, so bzr+ssh is the way to go
[20:58] <pl0sh> Ok, where can I find some info?
[20:58] <__monty__> poolie: Still nowhere pretty much.
[20:58] <pl0sh> I have installed bzr on my freebsd and on my windows boxes
[20:59] <poolie> pl0sh: there's an admin guide
[20:59] <poolie> but, basically, start an ssh server on the bsd box
[20:59] <poolie> then just from a windows box run eg
[20:59] <poolie> 'bzr init bzr+ssh://bsd/~/test'
[21:00] <pl0sh> great
[21:01] <pl0sh> and bzr push bzr+ssh://bsd/~/test right?
[21:01] <pl0sh> to push changes to the repo
[21:01] <flacoste> is there an easy API in bzrlib available to get the LP API branch URL from a working tree?
[21:01] <flacoste> i have a working tree of a branch on lp and want to make API call on its LP representation
[21:08] <poolie> hi flacoste
[21:08] <flacoste> hi poolie
[21:08] <flacoste> i was about to try
[21:08] <poolie> pl0sh: correct
[21:08] <poolie> i think there is one in plugins/launchpad
[21:08] <flacoste> from bzrlib.plugins.launchpad import lp_api
[21:08] <flacoste> lp_api.from_bzr(lp, branch)
[21:21] <__monty__> poolie: I'm trying to write a test for 393713 but I'm not sure what to write in it. (Doing this because you say in comment #4: 'We should test that though.')
[21:22] <poolie> flacoste: so is that ok
[21:22] <flacoste> poolie: still writing the script :-)
[21:23] <flacoste> from the look of it, it seems like it's exactly what i need
[21:23] <poolie> flacoste: separately i was wondering if you could nudge lp reviewers to land more approved 3rd party patches
[21:23] <poolie> not me, other peolpe
[21:23] <poolie> if you want to add a tip to the api guide docs or wiki page that would be welcome
[21:23] <poolie> what are you writing, just for curiouisyt?
[21:24] <vila> g'night all, have fun !
[21:24] <__monty__> vila: gn, thanks for helping.
[21:24] <flacoste> poolie: a script to make a principia package branch official
[21:25] <poolie> monty, have you pushed your current code?
[21:25] <flacoste> poolie: inspired by set_official.py in udd but less coupled to the package-importer implementation
[21:25] <poolie> i'll have a look at the review
[21:25] <poolie> cool
[21:25]  * __monty__ nudges poolie to stop ignoring his question? :)
[21:26] <flacoste> poolie: people approving a third party branch are supposed to take care of landing it, isn't that happening?
[21:26] <poolie> apparently not
[21:26] <flacoste> poolie: remember that it's not visiale if they have submitted it to ec2test and it will take some time to update
[21:26] <poolie> just sliping through the cracks i think
[21:26] <flacoste> well, i'm seeing 3rd party branches merged
[21:26] <flacoste> nigelb and chris' one
[21:27] <flacoste> which one haven't landed?
[21:27] <poolie> like https://code.launchpad.net/~james-w/launchpad/more-matchers/+merge/32057
[21:27] <flacoste> it's lifeless here that needs nudging
[21:27] <poolie> 3 from chrisjohnson
[21:27] <flacoste> he might not be aware of it
[21:27] <poolie> oh to rereview it?
[21:27] <flacoste> he approved it
[21:27] <poolie> i've just put one of chris's up for ec2
[21:27] <pl0sh> poolie thanks
[21:28] <poolie> i'm not saying it never happens, just it apparently doesn't always happen
[21:28] <poolie> i am very happy chris & others got prompt reviews
[21:29] <flacoste> i can send a reminder
[21:29] <poolie> vila, you just need a couple of tweaks to the utextwrap thing
[21:29] <poolie> __monty__: sorry, not trying to ignore you
[21:30] <poolie> show me the test you have currently?
[21:30] <poolie> if any
[21:30] <__monty__> poolie: It's worthless currently.
[21:30] <poolie> i thought yesterday we got up to having a test based on the other error-reporting tests
[21:31] <poolie> that raised a socket error and then checked it was printed in a reasonable way
[21:31] <poolie> did that break?
[21:31] <__monty__> Well, turns out the error message is different on different platforms.
[21:32] <poolie> oh, that's too be expected, yeah
[21:32] <ironcamel> has anyone got bzr bisect to work http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html ?
[21:32] <poolie> the main thing we want to assert in the test is just that it does not give a stack trace
[21:32] <poolie> ironcamel: what specifically is going wrong?
[21:33] <ironcamel> poolie: i installed it, but bzr bisect doen't do anything
[21:33] <ironcamel> bzr: ERROR: unknown command "bisect"
[21:33] <__monty__> poolie: Agreed, so just test the string for not containing 'traceback' ?
[21:33] <poolie> how about 'bzr plugins -v'
[21:33] <poolie> __monty__: i think it's "Traceback" but yes
[21:34] <ironcamel> poolie: it's not listed
[21:34] <poolie> how did you install it?
[21:34] <ironcamel> poolie: python setup.py install
[21:34] <ironcamel> got the source from https://launchpad.net/bzr-bisect
[21:36] <poolie> hm, i wonder where that installed it to?
[21:36] <poolie> perhaps something that's not on your bzr plugin path
[21:36] <ironcamel> not sure
[21:36] <poolie> typically you'd install from source with just eg
[21:36] <poolie> bzr branch lp:bzr-bisect ~/.bazaar/plugins/bisect
[21:37] <ironcamel> oh really
[21:37] <ironcamel> it comes with a setup.py, so that's why i did that
[21:38] <ironcamel> poolie: i think that did it :)
[21:39] <ironcamel> a little documentation would have made this easier
[21:39] <poolie> please file a bug against it about the setup.py not doing the right thing
[21:40] <ironcamel> sure
[21:42] <ironcamel> done
[21:51] <__monty__> poolie: This is what the test should look like right? https://code.launchpad.net/~toonn/bzr/socket.error-traceback-393713/+merge/62585
[22:00] <poolie> looks pretty good
[22:02] <__monty__> Ok, then I'm off, thanks for the help. Hope I can work on a different bug tomorrow. :)
[22:12] <smoser> hm... lp:ubuntu/nagios-plugins seems to be screwed up the same way python-boto is.
[22:14] <smoser> opened bug 789342 to address that.
[22:15] <poolie> thanks smoser
[23:26] <mgz> poolie, did you get a chance to look at my additions to your stale locks branch?
[23:26] <mgz> I... was slightly losing track last night but I think the code makes sense
[23:28] <poolie> mgz i did merge it in
[23:28] <poolie> thanks for that
[23:28] <poolie> i have some more items from spiv still to fix
[23:28] <poolie> at the moment i'm just finishing off some pending lp work
[23:32] <mgz> in unrelated bookkeeping, do I need to bug someone for an expenses form for last week?
[23:33] <poolie> yes, marianna
[23:33] <mgz> will email.


[09:04] <Laney> guten morgen!
[09:04] <larsu> morning Laney
[09:05] <seb128> good morning desktopers!
[09:05] <seb128> Laney, hey, how are you? had a good w.e?
[09:06] <Laney> hallo, yeah it was good - saturday was sunny so I roamed around outside doing various things but sunday it rained all day
[09:06] <Laney> = playing games and making sloe gin
[09:07] <Laney> you?
[09:08] <seb128> saturday was raining, sunday sunny for us
[09:08] <seb128> I did some errands/shopping on saturday, some "house-cleaning as well, and played tennis in between
[09:09] <seb128> yesterday mostly enjoyed the weather and spent some time with my cousin who is here for the holidays
[09:09] <seb128> today it's raining again :/
[09:10] <seb128> but they forecast 16°C and sunny for next w.e
[09:10] <seb128> crazy weather!
[09:10] <Laney> seems we get the opposite weather to you
[09:10] <Laney> blue sky outside now!
[09:10] <seb128> bah, give it back!
[09:11] <seb128> ;-)
[09:11] <seb128> oh, seems like the "download fixes" landing from friday was buggy :/ (it made clicks unhappy)
[09:11] <Laney> yeah I saw
[09:11] <Laney> apparently nobody did the full test plan
[09:12] <Laney> I guess everyone checked the system update bit
[09:12] <Laney> whoops
[09:12] <seb128> I didn't even realize that was doing clicks
[09:12] <seb128> yeah
[11:40] <Trevinho> mlankhorst: hey, I was checking https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1055166
[11:40] <ubot2`> Launchpad bug 1055166 in unity (Ubuntu) "compiz crashed with SIGSEGV in memmove() from drisw_update_tex_buffer() from dri_set_tex_buffer2() from operator() from compiz::opengl::bindTexImageGLX() from ... from unity::UnityWindow::DrawWindowDecoration" [High,Triaged]
[11:40] <Trevinho> mlankhorst: and it seems that the problem happens when a texture is 0x0...
[11:41] <Trevinho> mlankhorst: in that case I'm getting at some point on the bt: http://pastebin.ubuntu.com/7026994/
[11:41] <Trevinho> where w/h seems to have random values
[11:42] <Trevinho> mlankhorst: fyi the problem is solved by not creating textures of null size, but it would still be something that should not crash btw
[11:46] <mlankhorst> Trevinho: but if I add a flush I don't get a crash
[11:46] <Trevinho> mlankhorst: I don't know how that might fix it... mhmh
[11:46] <Trevinho> mlankhorst: flushing after building the pixmap?
[11:47] <mlankhorst> flushing before the failing XGetGeometry call
[11:48] <Trevinho> mlankhorst: ah, yeah so basically between the pixmap creation and the binding of the pixmap to texture...
[11:48] <Trevinho> in the same way, btw, if I don't create a texture if the size is 0x0, it works... mhmh
[11:54] <Trevinho> mlankhorst: at unity level flushing after creating the pixmap doesn't seem enough tohg
[11:54] <Trevinho> tough*
[12:03] <mlankhorst> Trevinho: yeah I did a flush at the crashing call, so I have no idea what it is, but I'm not really sure that it's a bug in libdri
[12:03] <mlankhorst> is any error suppressing libx11 handler installed btw?
[12:03] <mlankhorst> might be good to find out the first real error
[12:04] <Trevinho> mlankhorst: mhmh, herrors should be catched by gdk I think here... let me check
[12:06] <Trevinho> mlankhorst: oh, yeah... we have in compiz let me get the info
[12:09] <Trevinho> mlankhorst: I'm only getting a couple of BadWindow error on X_GetProperty calls
[12:09] <Trevinho> ah, no wait I've the fixes installed :)
[12:09] <mlankhorst> does anything happen around the time of crash?
[12:12] <Trevinho> mlankhorst: no, even with crashing unity, still no x errors
[12:13] <mlankhorst> the XGetGeometry call fails, and afaict the only failure allowed is BadDrawable
[12:13] <mlankhorst> surely that error ends up *somewhere* ?
[12:14] <Trevinho> mlankhorst: mh, we have an error handler in compiz, that does nothing by default (unless enabling debug), then nothing else
[12:14] <Trevinho> I think there's not a gdk error handler set, but it shouldn't interfere
[12:15] <mlankhorst> :\
[12:16] <mlankhorst> well XGetGeometry is failing before the real crash, that should at least generate *some* kind of error.. :/
[12:44] <seb128> bregma, hey, what's the plan for the unity hi-dpi fixes landing? ;-)
[12:52] <mhr3_> Trevinho, i noticed that with latest compiz window placement doesn't seem to take the titlebar into account, known?
[12:54] <Trevinho> mhr3_: known and fixed
[12:54] <mhr3_> Trevinho, in distro?
[12:54] <Trevinho> but not in distro yet
[12:54] <mhr3_> i see
[12:55] <mhr3_> Trevinho, what about my shadow issue? :)
[12:55] <Trevinho> mhr3_: it's on my list... but I've to finish other things before... :)
[12:56] <mhr3_> Trevinho, is there a workaround possible?
[12:56] <Trevinho> mhr3_: for synapse you mean?
[12:56] <Trevinho> mhr3_: set it as argb window
[12:56] <mhr3_> how would i do that?
[12:58] <mhr3_> Trevinho, is that a window hint, ccsm setting or...?
[12:58] <Trevinho> mhr3_: let me check the higher level call :)
[13:00] <Trevinho> mhr3_: ah, no the argb thing won't work... as it already is :)
[13:00] <Trevinho> so.... mhmh, try to mark it as a dock type window for now
[13:00] <Trevinho> is the easiest workardound
[13:06] <mhr3_> Trevinho, hm, looks like it was using SPLASHSCREEN as a special case for compiz
[13:06] <mhr3_> breaking existing workarounds! evil Trevinho!
[13:06] <Trevinho> ahah :D
[13:14] <Trevinho> mhr3_: anyway to get the proper fix I think you should instead use a cairo mask to shape the window to match the style,,, so you'd get events only in that area and unity won't draw any shadow :)
[13:17] <mhr3_> Trevinho, hm, seems like we're doing that for kwin already
[13:18] <mhr3_> Trevinho, i guess there were other issues so we had to use non-NORMAL window type with compiz
[13:21] <mhr3_> Trevinho, oh maybe it was just to get rid of the stupid appear animations :)
[13:23] <desrt> Laney: good morning
[13:24] <desrt> Laney: looked into that one remaining tests failure over the weekend.  it's a hardware bug :)
[13:29] <mitya57> charles: Hi, can you please re-review https://code.launchpad.net/~mitya57/indicator-applet/unparent-label/+merge/208174 ?
[13:32] <RAOF> Trevinho: Oh, are you the reason gnome-do has recently picked up some shadows on its hidden results window? :)
[14:07] <dpm> Hi happyaron, around?
[14:11] <desrt> Laney: but seriously... some more info about which machine that test failed on would be helpful because it looks like it's impossible for it to fail unless the machine has some very strange floating point implementation (non-standard rounding rules, non-deterministic behaviour, etc.)
[14:11] <desrt> if it's a softfloat machine then maybe we found some problems there...
[14:16] <smb> tseliot, Sarvatt who should be bugged about bug 1285205 / bug 1152656? Not sure this is known and tracked as something else or not on the radar yet. Looks to be present after todays updates, still for me.
[14:16] <ubot2`> Launchpad bug 1152656 in compiz (Ubuntu) "compiz crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/1152656
[14:17] <seb128> smb, Trevinho has a fix for it
[14:17] <tseliot> smb: not me, no proprietary drivers there ;)
[14:18] <seb128> smb, https://code.launchpad.net/~3v1n0/compiz/ignore-invalid-sized-textures/+merge/209061
[14:18] <smb> seb128, Ah ok. Thanks
[14:19] <seb128> smb, yw
[14:25] <Laney> desrt: they were either jenkins slaves (VMs?) or archive builders
[14:25] <Laney> sadly the old logs have gone away
[14:26] <desrt> tsk.
[14:26] <Laney> I could turn the tests back on ...
[14:26] <desrt> Laney: so i'm kinda convinced the tests aren't buggy
[14:26] <desrt> like the one failure of assert (a == b) where it showed that the two were equal...
[14:27] <desrt> this test consists of performing the same calculation twice and making sure it comes out the same both times
[14:27] <desrt> ...which apparently it doesn't
[14:27] <desrt> pretty dodgy...
[14:28] <desrt> the other failure is .. possible to imagine, at least.  it consists of someone rounding improperly.
[14:29] <smb> seb128, Hm, ok. Looks to me like something there causes ci to fail (or something else)
[14:30] <seb128> smb, right
[14:30] <seb128> bregma, btw, whenever you do an unity landing, could you try to include https://code.launchpad.net/~3v1n0/compiz/ignore-invalid-sized-textures/+merge/209061 ? it's currently creating issues for qa tests (segfault in vm/using software rendering)
[14:31] <ChrisTownsend> smb: seb128: We are working on straightening out the CI failure and then once that's done, we'll review and get it on the train.
[14:31] <seb128> ChrisTownsend, thanks
[14:31] <seb128> \o/ seeing Trevinho's hi-dpi branch on the train!
[14:31] <ChrisTownsend> seb128: np
[14:32] <Laney> desrt: I'll turn them back on in the next release
[14:32] <smb> ChrisTownsend, Ok, thanks.
[14:32] <Laney> expecting a tarball today :-)
[14:33] <desrt> Laney: yup.  will be releasing it.
[14:33] <desrt> have a few fixups to push first, though.
[14:33] <Trevinho> Trevinho: :)
[14:47] <mpt> seb128, I see the “Prompt when not connected” feature isn’t implemented yet. <https://wiki.ubuntu.com/Networking#phone-wifi> What package would it belong to?
[14:48] <seb128> mpt, indicator-network and ubuntu-system-settings I would say
[14:49] <seb128> tedg, Wellark: ^ right?
[14:50] <tedg> seb128, Yes, indicator-network mostly. The code exists, it just needs to be integrated.
[14:50] <tedg> Right now it's in indicator-network-prompt, but it'll be moved into indicator-network. So the bug should go there.
[14:51] <seb128> tedg, thanks
[14:57] <xnox> Laney: how come gstreamer0.10 still on the cd?
[14:58] <xnox> is it just seeded or actually needed for something?
[14:59] <Laney> check for rdepends on the image
[14:59] <Laney> of the library
[15:04] <xnox> Laney: found one, bluez-gstreamer.
[15:04] <xnox> all others appeared to be circular back to ubuntu-desktop.
[15:05] <seb128> xnox, Laney: ubuntuone stuff use python-qt4 which depends on libqtwebkit4 which depends on libgstreamer-plugins-base0.10-0
[15:05] <seb128> ubuntu-sso-client-qt
[15:05] <seb128> ubuntuone-control-panel-qt
[15:06] <xnox> seb128: oh, i see. about that, do we have anybody to port that stuff to qt5?
[15:06] <seb128> xnox, not that I know...
[15:06] <seb128> to python3 as well would be nice
[15:06] <xnox> seb128: ack.
[15:08] <mterry> mpt, JohnLea: hey you two!  I sent out an email about sharing the volume with the greeter last week.  If you get a chance, I'd like feedback on what ya'll think about the use cases.  I believe I'm going to go ahead and work on a patch to share it, but would appreciate guidance
[15:09]  * xnox tries to remember Mathieu Trudel-Lapierre real irc name.....
[15:09] <seb128> lol
[15:09] <seb128> cyphermox
[15:09] <cyphermox> yup
[15:09] <xnox> cyphermox: hey! any plans to switch to bluez 5.x ? =)))
[15:09] <cyphermox> xnox: nope
[15:09] <cyphermox> xnox: why? do you need something from it?
[15:09] <xnox> cyphermox: how about disabling gstreamer compile option?
[15:09] <cyphermox> sure.
[15:10] <cyphermox> IIRC we don't install that stuff usually, though
[15:10] <xnox> cyphermox: 5.x doesn't have gstreamer =)
[15:10] <cyphermox> I know
[15:10] <cyphermox> what uses bluez-gstreamer currently though? :)
[15:10] <xnox> $ seeded-in-ubuntu -b bluez-gstreamer
[15:10] <xnox> bluez-gstreamer is seeded in:
[15:10] <xnox>   edubuntu: dvd
[15:10] <xnox>   ubuntu-gnome: daily-live
[15:10] <xnox>   ubuntu: daily-live
[15:10] <xnox>   ubuntukylin: daily-live
[15:11] <xnox> cyphermox: for one reason or another it's seeded into all of above....
[15:11] <cyphermox> right
[15:11] <seb128> xnox, cyphermox: what feature does that provide?
[15:11] <cyphermox> I'm not sure it's actually used by anything, but we'll have to look into it
[15:11] <seb128> xnox, what's the point to drop it we can't drop gst0.10 anyway due to u1?
[15:11] <cyphermox> some kind of gstreamer library ;)
[15:12] <xnox> seb128: i have a stronger bargaining chip =)
[15:12] <xnox> (with security team) =))))
[15:12] <seb128> xnox, I doubt we are going to drop u1, that's a bargain you are going to loose
[15:12] <cyphermox> xnox: I'll look into it, since I'm messing in bluez anyway
[15:13] <xnox> seb128: or win development time to port it.
[15:13] <seb128> good luck
[15:13] <xnox> cyphermox: seeds just says "Bluetooth: recommend gnome-bluetooth, and bluez-gstreamer"
[15:14] <xnox> cyphermox: added in 2010 by pitti, "explicitly add bluez-gstr4eamer, desktop-common dropped it"
[15:29] <mpt> mterry, sorry I was out a chunk of last week. I’ll have a look at it tomorrow morning.
[15:30] <mterry> mpt, no crazy rush.  I think the technical work is pretty similar regardless
[15:30] <seb128> mpt, still having those unity-control-center strings suggestions on your todolist as well? ;-)
[15:30] <mpt> yessss
[15:31] <seb128> great, sorry for piling on all those requests you already have
[15:32] <ChrisTownsend> attente: Hey, when you have a sec, let's discuss https://code.launchpad.net/~attente/compiz/1284532/+merge/208908
[15:33] <attente> ChrisTownsend, sure
[15:34] <ChrisTownsend> attente: So I made a comment, but then thought maybe my comment is not so valid:)
[15:34] <attente> ChrisTownsend, no, it's a concern, definitely
[15:35] <ChrisTownsend> attente: Do you know if other downstreams (such as Gnome Flashback) might still use this plugin?
[15:35] <seb128> Trevinho, oh, that ^ change interests you
[15:35] <attente> ChrisTownsend, no idea unfortunately...
[15:36] <attente> i guess alternatively we can just change the defaults for those settings to null them out
[15:36] <attente> but that's also a distro-patch
[15:36] <ChrisTownsend> attente: Ok, well, maybe it's best to just distro patch disabling the plugin when using Unity.
[15:37] <ChrisTownsend> attente: Leave the other code intact.
[15:37] <attente> ChrisTownsend, i think there are two other settings there that are still used by unity
[15:37] <ChrisTownsend> attente: Just in case somebody wants to use it.
[15:37] <attente> "show main menu (alt+f1)" and "run dialog (alt+f2)"
[15:37] <ChrisTownsend> attente: Oh, right, I mistyped.
[15:38] <ChrisTownsend> attente: I meant disable the settings as you said.
[15:38] <attente> ChrisTownsend, ok, thanks, sounds reasonable
[15:38] <ChrisTownsend> attente: Cool.  Let me know when your MP is ready and I'll review it.
[15:40] <seb128> Laney, I think you should put a landing for https://code.launchpad.net/~laney/ubuntu-system-settings/as-ringtone/+merge/200862
[15:40] <Laney> but I'm scared
[15:40] <Laney> ;-)
[15:43] <seb128> haha
[15:43] <Laney> I will do, let me do this reset api fix and then do that
[15:44] <seb128> Laney, that v2 thing is the plugin api confuses me
[15:44] <seb128> what is needed for a plugin to declare it's on v2?
[15:45] <Laney> change the interface it implements
[15:45] <seb128> can we warn when a plugin is not on v2 to avoid confusion?
[15:45] <Laney> and the Q_SOMETHING lines
[15:45] <Laney> umm, don't think so
[15:46] <seb128> what change is needed to -online? can we just do a synced landing of both?
[15:46] <seb128> it feels like we are arguing about a theoritical issue since we have 1 external plugin known and we control it
[15:46] <Laney> I already proposed a branch for it
[15:46] <seb128> so we can jdi
[15:46] <Laney> but mardy still asked for this
[15:46] <Laney> and you backed him up, so I'm doing it now
[15:47] <seb128> well, I don't really understand what are the issue, it just seemed that the check was low cost and safer
[15:47] <seb128> but I didn't think it could create issues and create confusion
[15:48] <Laney> It's just that you can't reset if you aren't 2
[15:48] <Laney> We can probably remember that
[15:48] <seb128> well, that's fine I think
[15:48] <seb128> honestly I don't see any issue either way
[15:49] <Laney> I just wanted to let people reset from javascript whenever
[15:49] <Laney> but it doesn't really matter that much
[15:49] <seb128> right
[15:50] <seb128> Laney, not sure why mardy insist on that, he seems like he's ok to drop those lines later
[15:50] <seb128> we can as well do a synced landing, pinged him about that on #ubuntu-devel
[15:50] <Laney> I don't know why he said that
[15:50] <Laney> Either it's a good idea in which case keep it or it isn't in which case don't do it at all
[15:52] <seb128> right
[15:52] <seb128> well, I would go for a synced landing
[15:53] <Laney> shrug, I've done it now
[15:53] <seb128> but I want to hear back from mardy before deciding
[15:53] <seb128> sorry about that, really I don't care much, they are all equal options :-)
[15:53] <Laney> :P
[15:53] <seb128> just pick one
[15:53] <Laney> actually the test broke
[15:53] <Laney> noooooooooooooooooo
[15:53] <seb128> :/
[15:54] <Laney> oh it was this exact issue
[15:54] <Laney> haha
[16:44] <seb128> bregma, can I press "build" for the unity7 silo or do you hold on for a reason? doing a build now doesn't block you from redoing one later but it would give debs to those of us who want to test the update
[16:45] <bregma> seb128, oops, go ahead, I got buried by other stuff and forgot to do it myself
[16:46] <seb128> bregma, done
[16:46] <bregma> thanks
[16:46] <seb128> bregma, I commented on the unity8 session mp with a "you might to fix that"
[16:47] <bregma> seb128, yes, it's in my to-do queue
[16:48] <seb128> cool
[17:53] <seb128> bregma, ChrisTownsend, Trevinho: the unity update from ppa-004 works nicely for me, good work ;-) (just giving feedback since it's up for testing)
[18:08]  * didrocks waves good evening and good night
[18:53] <seb128> cyphermox, hey, do you know if ofono provides what we need for https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1287267 ?
[18:53] <ubot2`> Launchpad bug 1287267 in ubuntu-system-settings (Ubuntu) ""Data usage statistics" not shown" [Low,Triaged]
[18:53] <seb128> cyphermox, e.g stats on datas sent/received
[18:59] <ChrisTownsend> seb128: Cool, thanks for the feedback:)
[19:40] <seb128> mdeslaur, gnote?!
[19:44] <mdeslaur> seb128: yes! no?
[19:44] <mdeslaur> am I the only gnote user? :)
[19:44] <seb128> mdeslaur, well, patches are welcome, but we don't intend to maintain patches for !default_install
[19:44] <mdeslaur> I see
[19:44] <seb128> the only one that cares about menus I guess
[19:44] <seb128> ;-)
[19:45]  * seb128 uses tomboy, but can see the interest in not having mono installed
[19:45] <mdeslaur> it's in universe, I assumed some community member would maintain it :)
[19:45] <seb128> yeah, if somebody comes with a patch, fine, we are just not going to write
[19:45] <seb128> +it
[19:45] <mdeslaur> I took a quick look, but it's C++, so I got a nosebleed
[19:46] <mdeslaur> seb128: oh, I wasn't expecting you to
[19:46] <seb128> I'm already happy we managed to get nautilus evince file-roller and some others
[19:46] <mdeslaur> yes!
[19:46] <seb128> larsu is our hero there ;-)
[19:46]  * mdeslaur hugs larsu
[19:46]  * seb128 hugs larsu as well
[19:48]  * larsu feels hugged
[19:50] <seb128> ;-)


[07:38] <Kano> hi, 64 bit missing from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.7-quantal/
[07:40] <Kano> also missing from 3.4.14
[08:30] <marijnsch> Just installed 12.04.1 yesterday on hp elitebook 8470p. Unfortunately wireless doesn't work. Something wrong with the firmware it seems. I've tried upgrading to kernels from the kernel ppa, but it hasn't helped so far. Maybe because it is instead linux-firmware that needs to be updated. The issue is reportedly fixed in quantal. How do I go about making it work in precise?
[08:53] <apw> marijnsch, if it is missing firmware it may well show up in dmesg output as it tries to load
[08:54] <marijnsch> apw: not missing, but some problem with the combination firmware and kernel driver (iwlwifi).
[08:56] <ohsix> weren't some iwlwifi models or something gone unmaintained about a year ago?
[09:12] <apw> ohsix, some were lesss loved indeed.  but if it works in quantal its probabally not one of those
[09:12] <apw> marijnsch, it would be good to confirm it does work in Q, and if you have seen a bug fixing it in Q all the better
[09:14] <marijnsch> apw: can I try the Q kernel alone without upgradiing too much else? if yes, how do I do that?
[09:14] <apw> marijnsch, the easiest might be to try a live cd
[09:15] <marijnsch> apw: I'd rather try to upgrade kernel and/or firmware directly
[09:16] <apw> you should be able to directly install the kernel for testing, i'd not take the firmware at the same time
[09:20] <marijnsch> apw: I already tried a few kernels for precise such as kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc6-precise/ and it didn't help...
[09:21] <apw> marijnsch, well you could try a 3.5.6 or so, that is basically quantal
[09:23] <marijnsch> apw: they don't have amd64 kernels though... I don't think it would work with my amd64 userland
[09:23] <apw> marijnsch, ahhh i am working on that right now, build tools issue
[09:27] <marijnsch> apw: think there is any use in trying the pre-proposed kernel?
[09:38] <apw> i should have these fixes and build within the hour
[09:43] <marijnsch> apw: alright, no hurry
[10:33] <apw> marijnsch, ok 3.5.6/7 have amd64 now
[10:47] <apw> marijnsch, ok 3.5.6/7 have amd64 now
[11:18] <marijnsch> apw: alright, let me give it a try
[11:25] <marijnsch> apw: this 3.5.7 kernel doesn't seem to have iwlwifi driver...
[11:26] <apw> odd
[11:39] <apw> marijnsch, i see it in the binary packages, did you install linux-image-extra
[11:39] <apw> -rw-r--r-- root/root<PHONE_NUMBER>-10-13 10:03 ./lib/modules/3.5.7-030507-generic/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko
[11:41] <marijnsch> apw: indeed I did not
[11:42] <marijnsch> so, I've been testing an old module with new kernels the whole time and now the mismatch got too big for it to even load...
[11:58] <marijnsch> apw: it still won't work
[11:59] <apw> so then it might be worth trying an update to linux-firmware
[11:59] <apw> you get that from the librarian
[12:00] <marijnsch> the librarian? :)
[12:23] <marijnsch> apw: ?
[12:23] <apw> launchpad librarian
[12:24] <apw> https://launchpad.net/ubuntu/+source/linux
[12:43] <marijnsch> apw: not sure what to do with that. I don't see linux-firmware there.
[13:17] <apw> marijnsch, https://launchpad.net/ubuntu/+source/linux-firmware
[13:37] <marijnsch> apw: 1.95 also doesn't seem to have amd64 builds
[13:39] <apw> marijnsch, linux-firmware isn't arch specific, _all is useable on any arch
[14:17] <marijnsch> apw: linux-firmware-1.95 seems to contain the same version of wireless firmware: [   10.448112] iwlwifi 0000:24:00.0: loaded firmware version <IP_ADDRESS>
[14:17] <marijnsch> also I see no change in behavior
[14:17] <apw> marijnsch, then i'd say the chances your issue is fixed in quantal is near 0
[14:18] <marijnsch> apw: yes, that is starting to seem unlikely :(
[14:18] <apw> marijnsch, so you need to file a bug against 'linux' (ubuntu-bug linux) and describe the symptoms


[06:46] <webchat23> Hi team
[06:48] <arrayboltXE> webchat23: o/
[06:49] <webchat23> We have a Ubuntu 18.04 server running on cloud. Now, We are trying to upgrade the server to Ubuntu release 20.04 using
[06:49] <webchat23> # sudo apt-get update
[06:49] <webchat23> # sudo apt-get upgrade -y
[06:49] <webchat23> # sudo apt-get dist-upgrade -y
[06:49] <webchat23> # sudo apt-get autoremove
[06:49] <webchat23> # sudo reboot
[06:50] <arrayboltXE> webchat23: Uh... usually we use a website like bpa.st to share large snippets like that.
[06:50] <arrayboltXE> Sadly, an anti-flooding bot has muted you for 60 seconds. Sorry for the inconvenience.
[06:51] <arrayboltXE> Alright, should be fixed now.
[07:42] <guiverc> webchat23, Lubuntu 18.04 LTS was the end of the road for Lubuntu, being the last LXDE release.  As noted in https://lubuntu.me/focal-2-released/ you'll read "Note, due to the extensive changes required for the shift in desktop environments, the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh
[07:42] <guiverc> install."   ie. the release-upgrade will work for your base system, but desktop maybe broken if you were using Lubuntu/LXDE
[07:43] <arrayboltXE> guiverc: They're using 18.04 *server*, not Lubuntu. I think their question probably should have gone in #ubuntu, where I see they also posted.
[07:44] <guiverc> ack; I'd not looked, but asking in this room would mean Lubuntu/LXDE is implied
[07:46] <guiverc> (loads of server users, esp. those more familar with windows - often added LXDE/Lubuntu to a server install;  wasn't a great move given it was end of the road for Lubuntu/LXDE... we had some documentation on it long ago, since gone)
[07:46] <arrayboltXE> Oh, didn't know that.


[01:45] <ScottL> TheMuso, could you help me on a few points?
[01:45] <ScottL> 1. can you help make sure some updates get pushed to the repos
[01:45] <ScottL> 2. possibly explain what is involved in pushing to the repos
[01:46] <ScottL> 3. suggest a method that i can acquire the ability to push to the repos?
[01:46] <ScottL> any help would be appreciate :)
[01:46] <ScottL> oh, on any of those points
[03:49] <micahg> ScottL: for #3: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package_Uploaders
[03:49] <micahg> the same rules apply for a packageset which ubuntustudio has
[04:01] <micahg> ScottL: I'd suggest throwing any updates in the sponsorship queue
[04:01] <micahg> !sponsoring | ScottL
[04:01] <micahg> ScottL: https://wiki.ubuntu.com/SponsorshipProcess
[08:34] <astraljava> ScottL: Sorry, I've been really swamped with 'real-life' issues lately. I'm gonna get things updated today, and bug the necessary people. Thanks for asking, and sorry I've been out of reach.
[11:55] <ScottL> thanks micahg!  i will certainly read those today :)
[11:56] <ScottL> astraljava, don't worry friend, these things happen, i just want to make sure we have redundancy for such things
[12:21] <ScottL> perhaps it is my reading comprehension that is deficient, but i do not explicitly see how i request sponsorship for a fix
[12:23] <ScottL> i see notes to updating the code, filing bugs, attaching your work, making debdiffs, et al
[12:24] <ScottL> but between two different pages i did not see it say, "in order for sponsors to know your package needs sponsorship you need to do $ACTION
[12:34] <astraljava> ScottL: Yes, redundancy is good. :)
[12:36] <astraljava> ScottL: Are you talking about a  FFe, or just needing an upload of something that doesn't require it? In the former case, a bug needs to be filed, and ubuntu-sponsors team needs to be subscribed on it, but in the latter, only asking for uploading on #ubuntu-devel or #ubuntu-release should be sufficient.
[15:51] <micahg> ScottL: usually, unless it's urgent, it's better to subscribe ubuntu-sponsors than poke someone in ubuntu-devel for upload (unless there's a patch pilot in the /topic, they're made to be poked)
[15:57] <scott-work> astraljava and micahg: my internet at work was dodgy for a bit, checking logs
[15:58] <scott-work> astraljava: i'm surprised that #ubuntu-motu wouldn't be the place to ask for uploading/sponsorship, doesn't make me right/others wrong, just presenting my own personal biased thinking :P
[15:59] <scott-work> but i shall remember -release and -devel for uploading/sponsorship
[16:00] <scott-work> micahg: but i see you are saying to just subscribe ubuntu-sponsors unless it's urgent, i shall do that then
[16:00] <scott-work> thank you two :)
[16:01] <micahg> scott-work: well, right before beta 2 freeze could be considered urgent, I hope to be piloting a little later
[20:23] <astraljava> scott-work: I suppose -motu is as good a place as the aforementioned, but on the two former there's bound to be a higher percentage of people privileged enough to do the job requested.
[20:23] <astraljava> scott-work: I made the modifications, and asked for the upload, but didn't find any traces of the nautilus-image-whatwasthat.
[20:24] <astraljava> Will have to check again when new images have been spinned.
[20:26] <astraljava> Oh, and ubuntustudio-menu is of version 0.15, with falktx's changes. I haven't tested the new images yet, but I will do that soon. Forgive me, but I forget, did we have the lightdm-greeter theme existing? (I will of course comb the backlog for it)
[20:27] <falktx> astraljava: I haven't seen the package report for it, so I assume no
[20:32] <astraljava> falktx: Just found the link to the tarball. Is the 0.1 the latest version of it?
[20:33] <falktx> should be
[20:34] <falktx> astraljava: link?
[20:34] <astraljava> http://kxstudio.sourceforge.net/tmp/ubuntustudio-lightdm-theme_0.1.tar.gz
[20:36] <micahg> anything need to go in for beta 2?
[20:37] <falktx> astraljava: beh, that's not on launchpad...
[20:37] <falktx> micahg: ubuntustudio-lightdm-theme
[20:37] <falktx> oh, and ubuntustudio-icons
[20:38] <micahg> those are both new packages and need FFes
[20:40] <micahg> and I don't know if 20 minutes is enough for a new source audit
[20:40] <falktx> micahg: *-icons is not new
[20:41] <falktx> micahg: it's already packaged, and the code is already updated in the branch
[20:41] <falktx> it just needs an update
[20:41] <falktx> micahg: https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio
[20:42] <micahg> ah, it's called ubuntustudio-icon-theme
[20:43] <falktx> micahg: can you update it?
[20:44] <falktx> micahg: I already made a bug report for it - https://bugs.launchpad.net/ubuntu/+source/ubuntustudio-icon-theme/+bug/846483
[20:44] <micahg> yes, but I believe you need a UIFe for it at this point
[20:45] <micahg> oh, totally broke?
[20:45] <falktx> micahg: this is a fix
[20:46]  * falktx wonders how to get ubuntustudio-lightdm-theme into the repos...
[20:46] <micahg> falktx: you forgot to close the bug in the changelog
[20:47] <falktx> micahg: ah, yes, I created the bug after the package :)
[20:47] <falktx> micahg: do I really need to close it?
[20:47] <micahg> falktx: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages
[20:47] <falktx> ok, I'll update the branch
[20:48] <astraljava> falktx: It is now.
[20:48] <astraljava> https://code.launchpad.net/~ubuntustudio-dev/+junk/ubuntustudio-lightdm-theme
[20:49] <micahg> falktx: can you jump into #ubuntu-release to discuss the icon update?
[20:49] <astraljava> Oh crap, how did the +junk get in there?
[20:49] <falktx> astraljava: thanks!
[20:49] <astraljava> I didn't notice it.
[20:49] <falktx> hehe, junk...
[20:49] <falktx> what a cute name ubuntu gives for these things...
[20:50] <astraljava> It's embarrassing, for so many reasons. :D
[20:50] <falktx> astraljava: scott-work: do you have screenshots of *before* any icon changes? (ie, the normal behaviour?)
[20:51] <astraljava> falktx: Is this what you're looking for? http://astraljava.kapsi.fi/(X)ubuntu_studio_cropped.png
[20:52] <falktx> astraljava: no, that doesn't show the missing icons
[20:53]  * falktx is trying to get the new icons into beta-2
[20:56] <astraljava> falktx: You got 3 minutes. :D
[20:56] <astraljava> Not really, that's just the freeze.
[20:56] <falktx> I'm trying
[20:56] <astraljava> Ok, which icons are we looking at?
[20:57] <falktx> astraljava: they didn't even know US was going to change to XFCE!
[20:57] <knome> lol
[20:59] <knome> i need to see how photoshop will create asymmetric circular gradients
[20:59] <knome> yay!
[20:59] <astraljava> falktx: Who didn't?
[21:00] <astraljava> knome: I'm sorry, I don't do hebrew.
[21:00] <falktx> astraljava: the ubuntu dev guys
[21:00] <knome> ;)
[21:00] <astraljava> falktx: Well, they're too busy with the vanilla, they have no time to think about the derivates.
[21:00] <micahg> falktx: I hope you've tested this :)
[21:00] <astraljava> And quite frankly, it's just as well, as we're still heavily leaning on their power for the foundation etc.
[21:01] <falktx> micahg: yes, I did
[21:01] <astraljava> https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio/ubuntustudio-lightdm-theme
[21:01] <astraljava> micahg: I suppose this needs an FFe as well, right?
[21:01] <falktx> micahg: what else can we do to make this happen?
[21:02] <micahg> falktx: which one, I'm test building then uploading the icon package
[21:02] <knome> ah great! the inner glow -effect does exactly what i want
[21:02] <knome> WOOOOOHOOO
[21:02] <falktx> micahg: the icon
[21:02] <falktx> micahg: lightdm theme I think it's too late, right?
[21:02] <micahg> well, you can file for the FFe
[21:03] <falktx> micahg: but the lightdm thing is not 100% working right now, it's missing some postinst rules
[21:03] <falktx> but now at least the code is up, thanks astraljava
[21:04] <micahg> falktx: icons uploaded
[21:05] <falktx> ah, nice!
[21:05] <astraljava> falktx: Okay, then we have a problem. I included that in desktop already. I need to get that off quick, because I already asked for an upload of ubuntustudio-meta.
[21:05] <falktx> astraljava: it's safe to use
[21:05] <falktx> astraljava: but it will not "just work"
[21:05] <micahg> I can't do meta, I don't have enough time ATM
[21:06] <astraljava> Ahh... okay then, it can stay then.
[21:06] <falktx> the package will install
[21:06] <astraljava> micahg: No worries, I asked on -release.
[21:06] <falktx> micahg: thanks for the icon upload! where can I find you if I need more help?
[21:06] <micahg> I can do it later tonight though
[21:06] <astraljava> micahg: Thanks a bunch for your efforts!
[21:06] <micahg> falktx: I idle in here
[21:06] <falktx> nice
[21:07] <falktx> wow, this was fast... :)
[21:08] <falktx> micahg: I'll mark the bug as fixed then
[21:08] <micahg> falktx: LP should do that
[21:08] <falktx> ah, yeah
[21:08] <falktx> I'm new to all these stuff
[21:09] <micahg> falktx: that's why I had you close it in the changelog (also since if anyone had a question why the upload was done this late, there's a reference)
[21:09] <falktx> yep, got it
[21:11] <astraljava> I like this sort of thing, at the office we're utilizing git+redmine for it, very similar to bzr+LP (the bug management side of it)
[22:02] <scott-work> ach, sorry, been really busy at work today
[22:02] <scott-work> it looks like we dont' need a screenshot for the icons now
[22:03] <scott-work> micahg: do you think it is possible to get the lightdm package in before final release at all?  not just before B2?
[22:04] <scott-work> going home, micahg i'll catch your response as ScottL
[22:07] <astraljava> ScottL: I would think we'll get it in. After all, it's only affecting our distribution, nothing else depends on it.
[23:08] <ScottL> and it is only a lightdem theme as well, shouldn't be too hard to check it
[23:13] <falktx> hey
[23:13] <falktx> ScottL: fixed menu and icons will be in beta!
[23:18] <ScottL> yeah, thank you falktx !


[11:33] <jhutchins> DRK-AAM: That ought to keep the channel busy.
[11:33] <DRK-AAM> lol
[11:34] <wwcross> lol
[11:34] <jhutchins> DRK-AAM: Seeing as it still doesn't work for most users.
[11:34] <DRK-AAM> Hmmm... True...
[11:34] <wwcross> fusion needs better GFX
[11:36] <DRK-AAM> And as proud representative of the n00bz, it'll also need to be packaged for easier installation...
[11:37] <DRK-AAM> let me tell ya, the hours I spent on installing just beryl!
[11:37] <wwcross> yeah
[11:39] <wwcross> Firepaint. cool but donno what use it is
[11:39] <mintsoup> is there any way to make window redraw when dragging a window over top of another a little faster?
[11:40] <Angelus> where is kde and qt installed?
[11:48] <gdiebel> mintsoup: that is mostly dependent on your graphics hardware. are you using nvidia or ati binary drivers, or the ones included with xorg? also, you can configure kde to only show window outlines when dragging a window around
[11:53] <mintsoup> i don't remember exactly my drivers, but i am using an ati card with xgl drivers or something like that..
[11:54] <Dexter_F> does kubuntu use apple style hinting?
[11:55] <_wintermute_> Dexter_F: how do you mean
[11:55] <gdiebel> Dexter_F: not quite. freetype hinting is similar to apple if using autohinter. more close to microsoft style hinting if using the bytecode interpreter. also depends on which fonts. some look great with freetype bytecode, some not. autohinter is more consistent
[11:56] <Dexter_F> gdiebel: ok, lemme sum up: 3 options, apple, FT auto, none.
[11:56] <Dexter_F> apple=illegal, FT=ok for most
[11:57] <Dexter_F> or is FT hinting and FT+autohinting yet another thing?
[11:59] <der_fox> any germans in here ?
[11:59] <gdiebel> Dexter_F: not exactly. the autohinter does not infringe on patents. the bytecode interpreter may. it is enabled by default in debian/ubuntu. so, technically speaking, default ubuntu may be infringing.
[11:59] <trekdanne> !de
[11:59] <ubotu> Deutschsprachige Hilfe fuer Probleme mit Ubuntu, Kubuntu und Edubuntu finden Sie in den Kanaelen #ubuntu-de, #kubuntu-de, #xubuntu-de und #edubuntu-de
[12:00] <trekdanne> der_fox: even if there are they are not allowed to speak german :P
[12:01] <Eeyore-Jr> is there a way to check a system for defaults, against an attack in kubuntu?
[12:01] <carbonfreeze> anyone having issues passing vga= options to kernel on boot? tribe4+. I get a blank screen instead of normal verbose output
[12:01] <trekdanne> carbonfreeze: what value are you passing
[12:02] <Dexter_F> gdiebel: *that's* what I wanted to hear. I'm installing debian Etch on an other box and wondered why font's are so f?!*ing ugly there.
[12:02] <carbonfreeze> trekdanne: wait 1.
[12:02] <trekdanne> carbonfreeze: i'm using vga=791 for a nice 1024x786
[12:02] <trekdanne> carbonfreeze: hmm i think it should be a resolution or "ask"
[12:03] <carbonfreeze> trekdanne: I tried that and vga=0x318 etc and all i get is blank screen.
[12:03] <Eeyore-Jr> a way to check the integrity of a system?
[12:03] <carbonfreeze> trekdanne: this is with verbose option
[12:03] <gdiebel> Dexter_F: so if you prefer closer to apple style, just pick slight hinting in your control panel, that forces autohinter. or you can "sudo dpkg-reconfigure fontconfig-config" and pick autohinting. uh debian and ubuntu fonts are both using the same hinting by default.
[12:03] <trekdanne> carbonfreeze: hmm i dunno really never had any problems with that switch
[12:04] <carbonfreeze> trekdanne: I didn't either, until doing a dist-upgrade from 7.04 to 7.10 tribe4 about 2 weeks ago
[12:05] <carbonfreeze> trekdanne: tried forcing fb device in options (radeonfb and a couple others) to no effect.
[12:07] <trekdanne> carbonfreeze: what kernel are you using
[12:07] <Eeyore-Jr> !mp3
[12:07] <ubotu> For multimedia issues, this page has useful information: https://help.ubuntu.com/community/RestrictedFormats - See also http://help.ubuntu.com/ubuntu/desktopguide/C/common-tasks-chap.html - But please use free formats if you can: https://help.ubuntu.com/community/FreeFormats
[12:08] <carbonfreeze> trekdanne: 2.6.22-9
[12:09] <carbonfreeze> trekdanne: it has been a problem since the first 7.10 kernel that was used with tribe4; and each kernel since.
[12:10] <trekdanne> hmm strange indeed
[12:14] <familia> hola a todos
[12:14] <trekdanne> carbonfreeze: hmm maybe ask in #kubuntu-devel ?
[12:15] <der_fox> #kubuntu-de
[12:15] <der_fox> jaaaaaaaaaaaa
[12:15] <der_fox> mein compiz luft :D
[12:16] <voidmage> was anyone here when I was asking about my reinstall troubles?
[12:16] <voidmage> turns out the hard drive died.
[12:18] <NickPresta> voidmage, heh. I'm glad you found a solution.
[12:21] <trekdanne> does the *ubuntu alternative installation disc use ncurses (like slackware and debian)?
[12:22] <Dexter_F> gdiebel: well, that's odd then, for the character spacing as well as the chars themselves are wider than on this feisty box
[12:26] <Biovore> trekdanne: yes.. it all text based.. just like debian's installer
[12:27] <trekdanne> Biovore: ok nice
[12:32] <gdiebel> Dexter_F: that could be due to many other factors than hinting, font size or face, screen dpi. There are many things involved in getting nice fonts. search ubuntuforums for subpixel hinting for feisty. that gives you a new method of filtering the subpixel fringing that occurs in freetype (similar to ms cleartype) it makes for fairly accurate glyphs with sharpness and contrast as good as or better than windows.
[12:35] <Dexter_F> gdiebel: CRT, so subpixels are no concern. forcing both servers to 96dpi via kcontrol.
[12:35] <Dexter_F> guess ill clone the according .kde files and see what I can get


[00:21] <MK`> Did anyone see my question earlier? :
[00:21] <MK`> :)
[00:38] <MK`> hello jkbys
[02:26] <Emmanuel_Chanel> hi
[02:49] <MK`> hi Emmanuel_Chanel
[03:08] <Emmanuel_Chanel> MK`: I don't know the answer of your question.
[03:09] <MK`> ok