[04:54] smspilla1: hey [04:54] smspilla1: mfisch is trying to track down a bug whereby on ubuntu, gdk_beep() doesn't do anything [04:54] g'day smspilla1 [04:54] smspilla1: mutter has code that intercepts the beep and either displays it as a visual flash and/or causes libcanberra to play a beep sound [04:54] http://git.gnome.org/browse/mutter/tree/src/core/bell.c [04:55] smspilla1: does compiz have a plugin to try to do something similar? [04:55] smspilla1: under ubuntu, the beep only works if a) pcspkr module is loaded and b) xset b on was run [04:55] he may not quite be awake yet. he's on the west coast :) [04:56] or he may be at lunch. i guess it's noon there. [04:57] desrt: timezone website says 1pm [04:57] desrt: that's about beer-o-clock in .au on a friday ;) [04:58] mfisch: it's actually 7:30 in that case [04:58] they hang their clocks upside down in australia [04:58] mfisch: could also be that he actually decided to go to school today :) [05:01] Good morning [05:04] desrt: There's a longstanding bug on compiz for that. [05:04] desrt: yes [05:04] desrt: its not on by default [05:04] desrt: I also need to ask you something [05:05] desrt: is there any reason why, after an execvp (), writing to a pipe that is O_CLOEXEC (that I set up at the start of my main loop) on a signal causes the relevant gmain source not to have its prepare () function called ? [05:05] (I'm using glibmm if there are any known issues there) [05:06] desrt: school is also finished :p [05:06] smspilla1: hold on a second. it's taking me a little while to parse that sentence :) [05:06] mfisch: but yeah, you're looking for .. [05:06] smspilla1: so if you execvp() then you no longer get to write to your O_CLOEXEC pipe... [05:06] that's sort of the point [05:07] so i think i'm misunderstanding the question [05:07] desrt: right, well, I call pipe () as soon as I set up my main loop [05:07] so it gets set up again no problem [05:07] the mainloop no longer exists after the exec... [05:08] the entire old process image gets blown away [05:08] oh, sorry I forgot to add [05:08] we are execvp()'ing ourselves [05:08] (apparantly you're supposed to do it on SIGHUP) [05:08] (minor detail ;-)) [05:08] and if I test it with something like write (myPipeWriteEnd, "h", 1); and then do poll (myPipeWriteEnd) poll () returns and I can read data from the pipe [05:08] so if all your fds are O_CLOEXEC and you're exec()ing, it doesn't matter [05:08] it's as if you started fresh [05:08] but glib never calls the prepare function after execvp [05:09] smspilla1: can i see some code? [05:09] desrt: yeah, maybe I included too much irrelevant information [05:09] desrt: sure [05:09] smaller is better, as always :) [05:09] * smspilla1 snickers [05:10] * desrt prefers the exit-on-SIGHUP approach (and wait until dbus reactivates you) [05:10] mfisch: https://github.com/hypodermia/compiz-bell-plugin [05:10] desrt: ok, hang on [05:11] desrt: I think the SIGHUP probably comes from the X Server in this case [05:11] compiz was written before dbus really existed [05:11] smspilla1: you should get that plugin in the distro... [05:11] desrt: yeah I should, it keeps dropping off my stack [05:11] smspilla1: waiting for dbus activation isn't really appropriate for a window manager, either :) [05:11] mfisch: problem solved, then.... (as soon as smspillaz finds time) [05:11] desrt: and weirdly enough david was opposed to it because it was "putting too much stuff in the compiz process" [05:11] mfisch: oh on that [05:12] mfisch: you're probably going to have to remind me every day [05:12] :) [05:12] this thing has a tendency to drop off my stack [05:12] smspilla1: hey [05:12] smspilla1: did you remember about the compiz bell plugin? [05:12] desrt: what's a bell ? [05:12] successful troll is successful [05:13] +1 counter-troll === smspilla1 is now known as smspillaz [05:14] smspillaz: you have until i'm done brushing my teeth and flossing [05:14] then i'm going to bed :p [05:14] kk [05:15] the awkward moment where you can't find your own code [05:17] ah here we go [05:18] desrt: https://code.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_894639-test [05:18] (its still pushing to it sadly) [05:19] desrt: http://bazaar.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_894639-test/view/head:/src/screen.cpp#L166 [05:19] so if I do poll on signalPipeFds[0] it returns and says there's stuff that's ready [05:20] but the relevant source for it which is [05:20] http://bazaar.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_894639-test/view/head:/src/screen.cpp#L288 [05:20] never actually gets called [05:20] but *only* after an execvp [05:21] so execvp -> set up pipe -> set up source -> signal -> closeDown -> write -> (prepare not called) [05:21] as opposed to the normal startup case where prepare is called [05:21] * mfisch is catching up... [05:22] (I am writing to it from the signal handler btw, since that's the only safe way I think think of delivering the fact that the signal happened to the main loop) [05:22] (while the main loop is still polling for events) [05:22] (whihc never actually wakes up in the case I'm testing it in because we're using a fake X server to do compiz testing) [05:23] closeDown() is in the signal handler? [05:23] yeah [05:23] asprintf supposedly because it's signal-safe? [05:23] for debugging [05:23] RAOF & smspillaz: do you have a bug number for the beep issue? [05:24] mfisch: not one off the top of my head [05:24] smspillaz: would it be against compiz? I'll go look around [05:24] smspillaz: okay... let me get this straight [05:24] smspillaz: you have a pipe pair marked as O_CLOEXEC [05:24] yes [05:24] and you write to the write end [05:25] then immediately call execvp() [05:25] uh, no [05:25] okay. good. [05:25] its more like [05:26] pipe -> mainloop -> SIGHUP -> closeDown -> write -> mainloop -> (signal pipe wakes up) -> g_main_loop_quit () -> execvp (ourselves) -> repeat -> SIGTERM -> write -> mainloop (source never gets prepare called) [05:26] mfisch: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/301174 [05:26] Launchpad bug 301174 in pulseaudio "Use proper sound event instead of system beep" [Wishlist,Fix released] [05:27] (I have another question about g_main_loop_quit but I'll save that for later) [05:27] RAOF: thanks. [05:27] * mfisch goes to bed satisfied [05:27] mfisch: nite [05:28] desrt: I guess if there's no obvious "no you can't do that" I should probably single step gmain.c to see what the problem is [05:29] I'm guessing its probably a problem with my code [05:29] in some very weird way [05:29] i just don't understand what could possibly be the difference between a normal exec and the re-exec [05:29] unless you foul up the argv or the environment [05:29] exec is pretty much a clean-start [05:30] yeah, that's whats confusing me too [05:30] argv, the environment or leaked file descriptors should be the only thing that goes across [05:30] ok, single stepping it is then [05:30] desrt: also meant to ask [05:31] desrt: If you have sources A, B and C, and B and C are stuck in poll () and have never been dispatched before and then A gets an event and calls g_main_loop_quit () [05:31] is it normal that B and C remain stuck in poll and the mainloop doesn't actually quit ? [05:31] smspillaz: you may be interested to know that glib has unix signal watches these days [05:31] smspillaz: see g_unix_signal_add() [05:31] desrt: cool, I'll look into that [05:32] (the documentation says "if there are sources still waiting to be dispatched, g_main_loop waits on them) [05:32] (so right now I have this awkward workaround which immediately dispatches and force fails all sources as soon as a g_main_loop_quit happens) [05:33] smspillaz: it doesn't really work like that... [05:33] assuming you have no threads, poll() is only ever running when nothing else is running [05:33] s/stuck in poll/returns to poll/ [05:33] so if you're calling g_main_loop_quit() then, by definition, nothing is stuck in poll [05:33] nah.. [05:33] hm ok [05:33] the loop won't poll again after g_main_loop_quit() [05:34] thats at least what I've obvserved [05:34] there was a race about that before [05:34] but only when threads were involved [05:34] and i think the race is fixed now [05:34] hmm [05:34] ok, I'll have another look [05:34] desrt: It could be that glibmm's Glib::MainLoop::quit () is broken [05:35] desrt & smspillaz: thx for the assistance [05:35] mfisch: no prob [05:35] smspillaz: imho, glibmm is not worth the trouble [05:35] i'd just use glib's C API directly from C++ [05:35] desrt: yeah I've noticed some ... weird stuff about it [05:35] desrt: though the C API is awkward to use directly [05:35] or at least, it doesn't fit our object model that well [05:35] smspillaz: the C API is awkward to use from C too :) [05:36] desrt: I think glib is just awkward really [05:36] or maybe I'm awkward [05:36] and glib is really cool [05:36] glib is pretty good for what it is [05:36] :p [05:36] it's pretty hard to make C look like an object-oriented language though [05:36] so some awkwardness is necessarily implied :) [05:38] desrt: http://images.cheezburger.com/completestore/2011/12/1/d5fb6962-c9c0-4095-8bcb-9a9140340b66.jpg [05:38] :3 [05:39] desrt: I dunno, I'd like to think that we can get nice C++ bindings to G*, but being able to do that is really hard [05:39] desrt: anyways, g'night :) [05:40] I read through the documentation for gmmproc this morning and [05:40] yeah [05:40] my brain hurt [05:41] ugh, but gmmproc is doing so much more work than it needs to these days [05:41] i really, really wish somebody had a tool that generated C++ bindings using GI [05:41] oh there isn't one ? [05:41] hmmmmmmmmmmm [05:41] * smspillaz plots [05:41] well, there's smoke-gobject/gobject-consume/whatever it's called [05:41] but that's not really functional [05:42] and gmmproc requires pre-writing .hg and .ccg input files that are basically pre-processor food [05:42] yeah Isaw [05:42] (so with gmmproc you're basically binding everything by hand) [05:42] when I was reading the gmmproc documentation I was kind of like [05:42] oh taht [05:42] *that [05:42] "haha" [05:44] smspillaz: anyway, have to run, but if you were to write a tool that built gobjectmm-based bindings using just GI information, that would be *so* *cool* [05:44] and i'd be happy to try and help [05:44] I can see desrt sitting somewhere in Canada screaming "use a real language!" :p [05:45] C++ is a real language! [05:46] C++11 even more so! [05:50] broder: even more so, it's like the union of ten languages [05:50] if only it had a sensible way of handling ABI stability [05:53] _ZICanHaveAGoodABITooC8bp9_R3w [05:57] smspillaz: or the really nasty habit of putting constructors in .h files, it's insane [05:57] *cough* apt *cough* [05:58] Well, where else are you going to put them? :) [05:58] RAOF: that's an obvious answer [05:58] "in your face" of course, everytime it blows up [05:58] It's always fun when the .h file has a mixture of class declarations and inline functions. Hello, nux! [05:59] having a ctor like "MyClass(): member1(0), member2(NULL)" might look nice and convenient, but it's utter insanity whenever you have to add a new private member to a class [06:00] with that, changing private members effectively breaks ABI [06:00] Well, yes. [06:02] pitti: yeah, I usually try to keep code out of headers in compiz too [06:02] though there are still some places where it is there (left by other people that are not yours truly of course) [06:03] pitti: code out of headers and PIMPL is how I roll [06:04] pitti: I think C++11 brings a standard ABI though doesn't it ? [06:04] although, it still really easy break the ABI [06:06] pitti: C++ would also be nice if template error messages were not hundreds of lines long [06:07] Heh. [06:08] It would be nice if templates were runtime generated code, too :) [06:08] nah [06:08] err, what? [06:09] pitti: nope, apparantly it doesn't, must have misread something [06:51] good morning [07:05] hey didrocks [07:05] bonjour pitti, how are you? [07:10] didrocks: quite fine, thanks! had some fun this morning unbreaking the archive [07:11] oh? the archive broke after alpha1 unfreeze? [07:11] software-center was uninstallable, causing all CD builds to fail, plus nautilus-python breaking edubuntu [07:11] yes [07:11] well, that's why we have a stable+1 team :) [07:13] heh, from day 2, pitti for rescussing the archive! :) [07:13] * didrocks hugs pitti [07:16] * pitti hugs back didrocks === tkamppeter_ is now known as tkamppeter [07:46] pitti, hi [08:18] hey tkamppeter [08:19] pitti, hi [08:20] pitti, it is about CUPS 1.5.x. The IPP backend has a lot of regressions. [08:21] pitti, bug 881843, bug 877958, bug 879625, bug 883585 [08:21] Launchpad bug 881843 in cups "CUPS IPP print to Novell servers error since 11.10 upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/881843 [08:21] Launchpad bug 877958 in cups "After every single page on ipp: Unable to get print job status" [Undecided,Confirmed] https://launchpad.net/bugs/877958 [08:21] Launchpad bug 879625 in cups "CUPS fails to request authentication when printing over IPP w/ TLS" [Undecided,Incomplete] https://launchpad.net/bugs/879625 [08:21] Launchpad bug 883585 in cups "Kubuntu 11.10 -- Network/Local Printers found but cannot print - Unable to get printer status" [Undecided,Confirmed] https://launchpad.net/bugs/883585 [08:22] pitti, a volunteer, Robert Bradley, tried to fix these and worked with the reporters to get more info. [08:23] pitti, he also suggested to downgrade the IPP backend to the one of CUPS 1.4.x and tells that this solves the problems. [08:24] pitti, now I am thinking about doing this in our CUPS package, especially also as an SRU for Oneiric. [08:24] pitti, on Precise I would then return to the current backend when the bugs are fixed upstream. [08:25] pitti WDYT? [08:25] tkamppeter: hm, I thought the new one implied some change in the names/URIs of the printer [08:25] tkamppeter: if we would go back, wouldn't we change them back and break them again? === jibel_ is now known as jibel [08:27] pitti, I did not know about that. The release notes http://www.cups.org/documentation.php/doc-1.5/whatsnew.html do not tell about that. [08:27] pitti, from where do you know that. [08:28] tkamppeter: oh, I'm mixing that up with the USB backend [08:28] that was libusb vs. /dev/lpUSBnn [08:28] pitti, the USB backend is fine now after 2 SRUs. [08:29] pitti, I could quickly prepare a new CUPS SRU package and we could replace the current not-yet-approved one. [08:30] tkamppeter: would be interesting to see a diff of the USB backend between 1.4.6 and 1.5.0 to see the scope of teh changes [08:31] pitti, you mean s/USB/IPP/ [08:31] niiiiiiiiiiiiiiice http://www.youtube.com/watch?v=RuIQskGD3u0 [08:31] good morning everyone [08:32] tkamppeter: yes, I have it all backwards this morning :( [08:32] hey chrisccoulson [08:33] hi pitti, how are you? [08:33] pitti, diff is attached to bug 881843, comment #6. [08:33] Launchpad bug 881843 in cups "CUPS IPP print to Novell servers error since 11.10 upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/881843 === gema_afk is now known as gema [08:41] tkamppeter: uh, this looks like a whole rewrite indeed [08:41] tkamppeter: so, if you think that's best, fine for me; I don't know whether downgrading would potentially break anyone's configuration or setup [08:42] i. e. if they are using new features of the 1.5 backend [08:43] pitti, as the release notes do not mention anything, it seems that this is merely only stuff to improve on Mac OS X. [08:44] pitti, so I will apply it and tell you when the SRU package is ready for approving. [08:44] pitti, can you already approve the HPLIP SRU? Thanks. [08:45] tkamppeter: will do an SRU run later today (have some urgent stuff to fix right now) [08:45] tkamppeter: so you want me to ignore or reject the current cups SRU upload? [08:46] pitti, please reject the current CUPS SRU upload, I will re-upload it with the IPP backend patch. === jodh is now known as jodh_ [08:53] tkamppeter: roger, done [08:58] hmmm, this is depressing - https://bugs.launchpad.net/ubuntu/+source/firefox/+bugs?field.tag=test-suite [09:01] chrisccoulson: are these filed by a bot of your's? [09:02] pitti - no, i filed them manually [09:02] i should probably figure out a way to do that automatically though [09:13] hello [09:20] hey rodrigo_, how are you? [09:20] good morning rodrigo_ [09:26] moin desktop world! [09:27] hi pitti, didrocks [09:27] and Sweetshark :) [09:27] good morning Sweetshark! [09:30] hey Sweetshark [09:30] Sweetshark: I have a bug to report [09:30] openoffice.org 1:3.3.0-7 [09:31] Sweetshark: that is correctly spelled "3:1.3.3-7"! [09:32] pitti, about bug 897309, some proprietary printer driver packages need gs-esp. Should I simply add a "Provides: gs-es" to the "ghostscript" binary package? [09:32] Launchpad bug 897309 in ghostscript "Package «gs-esp» is still needed in Oneric and higher" [Undecided,New] https://launchpad.net/bugs/897309 [09:33] tkamppeter: depends; do they have a versioned dependency? if it's just "gs-esp", a Provides: will work fine [09:33] (meh, gs-esp was many, many years ago) [09:44] hey [09:45] pitti: huh? [09:50] Sweetshark: just kidding [09:50] hey seb128 [09:51] hey pitti, how are you? [09:52] seb128: quite fine :) [09:52] cleaned up after mvo and myself breaking the archive and daily builds yesterday [09:53] and now working on bug 897680 (ugh) [09:53] Launchpad bug 897680 in ubiquity "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected" [High,In progress] https://launchpad.net/bugs/897680 [09:53] stable team FTW :) [09:55] pitti, ;-) [09:55] pitti, the bug does not say anything about versioned or not, so seems to be better to introduce a dummy package to assure that it works with all drivers. [09:55] tkamppeter: I'd start with a Provides: [09:56] tkamppeter: I don't like reintroducing 5 year old clutter for that :/ [09:56] seb128: indicator-me looks obsolete, right? [09:56] pitti, it is, I though we dropped it in Oneiric? [09:56] pitti, it got merged in indicator-session [09:56] seb128: that was replaced with the new session plugin [09:57] seb128: yes, but apparently re-synced to precise; I'll remove again and blacklist [09:57] pitti, right, did it come back by some way? [09:57] oh ok [09:57] yes, seems about right ;-) [09:58] pitti: *eeeh* what did I do ? [09:58] mvo: software-center depended on the new plugins which were in binNEW and universe [09:58] aha, ok [10:00] pitti, CUPS SRU re-uploaded. [10:01] pitti, patch also pushed to BZR. [10:05] tkamppeter: current version is in testing, so I guess I better upload this [10:05] tkamppeter: thanks! [10:06] pitti: /me is in deer-in-headlight-mode. Monday is release branch off. [10:06] ;) [10:06] Sweetshark: oh, that's kind of "release time crunch" for LibO then? [10:08] pitti: yes, the scheduling of LO and Ubuntu never leaves me without a 'release time crunch' ;) [10:12] hah, i wish i could say the same for firefox [10:12] 24th April - Firefox 12, 26th April - Precise ;) [10:15] chrisccoulson, it's like the anti-perfect schedule, end of year holidays, hard freeze... [10:19] brb [10:56] pitti, help :p [10:56] bug #898973 [10:56] Launchpad bug 898973 in gtk+2.0 "package gtk2-engines-pixbuf 2.24.6-0ubuntu6 failed to install/upgrade: './usr/share/doc/gtk2-engines-pixbuf/NEWS.gz' is different from the same file on the system" [Undecided,Confirmed] https://launchpad.net/bugs/898973 [10:56] seems like lool broke precise as well :p [10:56] that got 2 bug reports today so I guess it's a real bug somewhere [10:58] oh dear, that sounds like bug 871083 [10:58] Launchpad bug 871083 in gzip "gzip -9n sometimes generates a different output file on different architectures" [High,Triaged] https://launchpad.net/bugs/871083 [11:01] seb128: only known workaround for that right now is to upload a package with dh_compress -XNEWS, I'm afraid [11:01] :-( [11:02] seb128: do you have time to dupe and upload the workaround, or shall I? (I'm a bit tight on time today, need to catch a train later on and finishing up something) [11:03] pitti, I can do it [11:03] * pitti hugs seb128, thanks [11:03] * seb128 hugs pitti back, you're welcome [11:03] pitti, "dupe" the bug you mean? I will rather just close it with the workaround with a note the real issue is the gzip one [11:04] seb128: as you prefer [11:04] ok [11:04] I'm on it ;-) [11:04] I'd dupe it so that we collect all the tasks on the master bug [11:04] and know what to revert once the real bug is fixed [11:04] but we can add a task without duping, too [11:05] pitti, ok, makes sense, I can do that [11:05] pitti: hello! about above mentioned bug: i reported it too and it got duped - shouldn't apport have told me that? [11:06] htorque: I'm afraid we can't do that yet for package install failures [11:06] the log parsing isn't reliable enough yet to do that [11:06] ah ok, so just for crashers. [11:06] as many errors are followups, some are noise, etc. [11:06] it's not easy even as a human to spot the real root cause [11:09] tkamppeter: nice, Robert is already sending patches for the regressions to upstream [11:17] seb128: you want me to upload with -XNEWS? [11:18] lool, if you want to feel free, I'm finishing something and was going to do that next but if you want to do it that's welcome ;-) [11:19] will -XNEWS also take care of README.gz and changelog.Debian.gz? because they seem to cause trouble too. [11:20] no, they should probably be added to the -X list [11:20] lool, ^ [11:20] htorque: is that confirmed? [11:20] htorque: in libtasn, only NEWS was affected [11:21] the bug and the dup only have NEWS listed [11:22] oh it's in gtk+2.0 [11:22] you can download both .debs, dpkg-deb -x them, and compare md5sums [11:23] pitti: i removed NEWS.gz and did 'install -f' and it complained about changelog.Debian.gz. removed that too, then it showed the same for README.gz. removed that one and the update worked. [11:23] seb128: So why does it relate to me? :-) [11:24] hmm E: gtk2-engines-udeb udeb: udeb-contains-documentation-file usr/share/doc/gtk2-engines-udeb/ [11:24] grabing gtk+2.0 [11:24] lool, I overlooked the -pixbuf part of the name, or rather confused it with your gtk2-engines upload from yesterday :p [11:24] lool, sorry :-( [11:25] seb128: see how you blame me for everything!!1! [11:25] lool, (or in fact it's my secret plan to make you do desktop work ;-) [11:25] lool, (but sussssh) [11:26] pitti: It's a bit ugly to add these -Xs if it also affects changelog and README :-/ [11:28] Ah cjwatson was looking after it [11:28] lool: but at least we exactly know what to revert once it's fixed [11:29] pitti: You mean we can grep Contents to find packages to revert? [11:29] lool: no, I think we should add tasks to that master bug [11:30] oh wow, we moved from gzip 1.3.12 from *2007* to 1.4.0 from 2010 [11:30] lool: but that wasn't it [11:30] pitti: Ok; I hope it's not going to affect too many packages [11:30] lool: we just never noticed beefore multiarch [11:30] otherwise I had reverted it already [11:30] pitti: Ok [11:30] i. e. it's not a regression [11:31] pitti: It's just certain contents? [11:31] yes [11:31] and I never managed to reproduce it locally [11:31] must be something spethial on the buildds [11:31] different kernel, different file system, I don't know [11:31] PPAs are fine, local builds are fine with both lucid and precise kernel,e tc. [11:31] oh wow [11:31] some buildds allegedly run the hardy kernel, I didn't try that locally [11:32] lool: I suppose it's something like "truncate() doesn't zero blocks under some circumstances" or "some memory pages remain uninitialized when you write the tail" or whatnot [11:37] we don't seem to log kernel version with build logs [11:37] right, so I could only guess [11:38] proposed https://code.launchpad.net/~lool/launchpad-buildd/log-kernel-version/+merge/84247 [11:40] lool: merci [11:42] seb128: retracer assertion failure> will have a look on monday, -ENOTIME any more today [11:42] pitti, ok [11:42] probably a weird bug which needs to be duped, etc., but need to figure out the logic [11:45] pitti, SRU for bug 897309 uploaded, precise package will come soon. [11:45] Launchpad bug 897309 in ghostscript "Package «gs-esp» is still needed in Oneric and higher" [Undecided,New] https://launchpad.net/bugs/897309 [11:49] seb128: ok, worked around for now, they _should_ be back up until the next gksu crash comes in [11:49] pitti, danke [11:49] pitti, what is wrong with gksu? [11:49] (just curious) [11:50] bug 898874 [11:50] Launchpad bug 898874 in gksu "gksu crashed with SIGSEGV in __strlen_ia32()" [Medium,Confirmed] https://launchpad.net/bugs/898874 [11:50] the traces all look slightly differently [11:50] I don't yet have a firm idea where the duplication logic fails [11:50] it's rather conservative right now with lots of asserts [11:50] so I'd rather just let it crash again when it happens [11:50] ok [11:56] I need to run now, cu later on the train (maybe, I'll mostly work offline) [11:56] have a nice weekend! [11:57] pitti: Good WE! === MacSlow is now known as MacSlow|lunch [12:22] pitti, all SRUs for this week are uploaded now and ready for approval: CUPS, HPLIP, Ghostscript (10 bugs). [12:39] ricotz, hey [12:39] lool, so will you handle gtk or should I have a look? it seems you started on it? [12:40] pedro_, ola, thanks for the sru verification ;-) [12:42] seb128, hello! np, i'm reviewing the ones that need verification today [12:43] great [12:45] seb128, hey [12:45] ricotz, how are you? [12:46] seb128, a bit busy, but fine [12:46] seb128, hoping you are fine too [12:46] ricotz, it would be nice to get rhythmbox updated in precise, do you want to do it? I can do the sponsoring for you [12:46]