[04:54] <desrt> smspilla1: hey
[04:54] <desrt> smspilla1: mfisch is trying to track down a bug whereby on ubuntu, gdk_beep() doesn't do anything
[04:54] <mfisch> g'day smspilla1
[04:54] <desrt> 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] <desrt> http://git.gnome.org/browse/mutter/tree/src/core/bell.c
[04:55] <desrt> smspilla1: does compiz have a plugin to try to do something similar?
[04:55] <mfisch> smspilla1: under ubuntu, the beep only works if a) pcspkr module is loaded and b) xset b on was run
[04:55] <desrt> he may not quite be awake yet.  he's on the west coast :)
[04:56] <desrt> or he may be at lunch.  i guess it's noon there.
[04:57] <mfisch> desrt: timezone website says 1pm
[04:57] <mfisch> desrt: that's about beer-o-clock in .au on a friday ;)
[04:58] <desrt> mfisch: it's actually 7:30 in that case
[04:58] <desrt> they hang their clocks upside down in australia
[04:58] <desrt> mfisch: could also be that he actually decided to go to school today :)
[05:01] <pitti> Good morning
[05:04] <RAOF> desrt: There's a longstanding bug on compiz for that.
[05:04] <smspilla1> desrt: yes
[05:04] <smspilla1> desrt: its not on by default
[05:04] <smspilla1> desrt: I also need to ask you something
[05:05] <smspilla1> 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] <smspilla1> (I'm using glibmm if there are any known issues there)
[05:06] <smspilla1> desrt: school is also finished :p
[05:06] <desrt> smspilla1: hold on a second.  it's taking me a little while to parse that sentence :)
[05:06] <smspilla1> mfisch: but yeah, you're looking for ..
[05:06] <desrt> smspilla1: so if you execvp() then you no longer get to write to your O_CLOEXEC pipe...
[05:06] <desrt> that's sort of the point
[05:07] <desrt> so i think i'm misunderstanding the question
[05:07] <smspilla1> desrt: right, well, I call pipe () as soon as I set up my main loop
[05:07] <smspilla1> so it  gets set up again no problem
[05:07] <desrt> the mainloop no longer exists after the exec...
[05:08] <desrt> the entire old process image gets blown away
[05:08] <smspilla1> oh, sorry I forgot to add
[05:08] <smspilla1> we are execvp()'ing ourselves
[05:08] <smspilla1> (apparantly you're supposed to do it on SIGHUP)
[05:08] <smspilla1> (minor detail ;-))
[05:08] <smspilla1> 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] <desrt> so if all your fds are O_CLOEXEC and you're exec()ing, it doesn't matter
[05:08] <desrt> it's as if you started fresh
[05:08] <smspilla1> but glib never calls the prepare function after execvp
[05:09] <desrt> smspilla1: can i see some code?
[05:09] <smspilla1> desrt: yeah, maybe I included too much irrelevant information
[05:09] <smspilla1> desrt: sure
[05:09] <desrt> 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] <smspilla1> mfisch: https://github.com/hypodermia/compiz-bell-plugin
[05:10] <smspilla1> desrt: ok, hang on
[05:11] <smspilla1> desrt: I think the SIGHUP probably comes from the X Server in this case
[05:11] <smspilla1> compiz was written before dbus really existed
[05:11] <desrt> smspilla1: you should get that plugin in the distro...
[05:11] <smspilla1> desrt: yeah I should, it keeps dropping off my stack
[05:11] <desrt> smspilla1: waiting for dbus activation isn't really appropriate for a window manager, either :)
[05:11] <desrt> mfisch: problem solved, then.... (as soon as smspillaz finds time)
[05:11] <smspilla1> desrt: and weirdly enough david was opposed to it because it was "putting too much stuff in the compiz process"
[05:11] <smspilla1> mfisch: oh on that
[05:12] <smspilla1> mfisch: you're probably going to have to remind me every day
[05:12] <smspilla1> :)
[05:12] <smspilla1> this thing has a tendency to drop off my stack
[05:12] <desrt> smspilla1: hey
[05:12] <desrt> smspilla1: did you remember about the compiz bell plugin?
[05:12] <smspilla1> desrt: what's a bell ?
[05:12] <smspilla1> successful troll is successful
[05:13] <desrt> +1 counter-troll
[05:14] <desrt> smspillaz: you have until i'm done brushing my teeth and flossing
[05:14] <desrt> then i'm going to bed :p
[05:14] <smspillaz> kk
[05:15] <smspillaz> the awkward moment where you can't find your own code
[05:17] <smspillaz> ah here we go
[05:18] <smspillaz> desrt: https://code.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_894639-test
[05:18] <smspillaz> (its still pushing to it sadly)
[05:19] <smspillaz> desrt: http://bazaar.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_894639-test/view/head:/src/screen.cpp#L166
[05:19] <smspillaz> so if I do poll on signalPipeFds[0] it returns and says there's stuff that's ready
[05:20] <smspillaz> but the relevant source for it which is
[05:20] <smspillaz> http://bazaar.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_894639-test/view/head:/src/screen.cpp#L288
[05:20] <smspillaz> never actually gets called
[05:20] <smspillaz> but *only* after an execvp
[05:21] <smspillaz> so execvp -> set up pipe -> set up source -> signal -> closeDown -> write -> (prepare not called)
[05:21] <smspillaz> as opposed to the normal startup case where prepare is called
[05:21]  * mfisch is catching up...
[05:22] <smspillaz> (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] <smspillaz> (while the main loop is still polling for events)
[05:22] <smspillaz> (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] <desrt> closeDown() is in the signal handler?
[05:23] <smspillaz> yeah
[05:23] <desrt> asprintf supposedly because it's signal-safe?
[05:23] <smspillaz> for debugging
[05:23] <mfisch> RAOF & smspillaz: do you have a bug number for the beep issue?
[05:24] <smspillaz> mfisch: not one off the top of my head
[05:24] <mfisch> smspillaz: would it be against compiz?  I'll go look around
[05:24] <desrt> smspillaz: okay... let me get this straight
[05:24] <desrt> smspillaz: you have a pipe pair marked as O_CLOEXEC
[05:24] <smspillaz> yes
[05:24] <desrt> and you write to the write end
[05:25] <desrt> then immediately call execvp()
[05:25] <smspillaz> uh, no
[05:25] <desrt> okay.  good.
[05:25] <smspillaz> its more like
[05:26] <smspillaz> 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] <RAOF> mfisch: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/301174
[05:26] <ubot2> Launchpad bug 301174 in pulseaudio "Use proper sound event instead of system beep" [Wishlist,Fix released]
[05:27] <smspillaz> (I have another question about g_main_loop_quit but I'll save that for later)
[05:27] <mfisch> RAOF: thanks.
[05:27]  * mfisch goes to bed satisfied
[05:27] <desrt> mfisch: nite
[05:28] <smspillaz> 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] <smspillaz> I'm guessing its probably a problem with my code
[05:29] <smspillaz> in some very weird way
[05:29] <desrt> i just don't understand what could possibly be the difference between a normal exec and the re-exec
[05:29] <desrt> unless you foul up the argv or the environment
[05:29] <desrt> exec is pretty much a clean-start
[05:30] <smspillaz> yeah, that's whats confusing me too
[05:30] <desrt> argv, the environment or leaked file descriptors should be the only thing that goes across
[05:30] <smspillaz> ok, single stepping it is then
[05:30] <smspillaz> desrt: also meant to ask
[05:31] <smspillaz> 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] <smspillaz> is it normal that B and C remain stuck in poll and the mainloop doesn't actually quit ?
[05:31] <desrt> smspillaz: you may be interested to know that glib has unix signal watches these days
[05:31] <desrt> smspillaz: see g_unix_signal_add()
[05:31] <smspillaz> desrt: cool, I'll look into that
[05:32] <smspillaz> (the documentation says "if there are sources still waiting to be dispatched, g_main_loop waits on them)
[05:32] <smspillaz> (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] <desrt> smspillaz: it doesn't really work like that...
[05:33] <desrt> assuming you have no threads, poll() is only ever running when nothing else is running
[05:33] <smspillaz> s/stuck in poll/returns to poll/
[05:33] <desrt> so if you're calling g_main_loop_quit() then, by definition, nothing is stuck in poll
[05:33] <desrt> nah..
[05:33] <smspillaz> hm ok
[05:33] <desrt> the loop won't poll again after g_main_loop_quit()
[05:34] <smspillaz> thats at least what I've obvserved
[05:34] <desrt> there was a race about that before
[05:34] <desrt> but only when threads were involved
[05:34] <desrt> and i think the race is fixed now
[05:34] <smspillaz> hmm
[05:34] <smspillaz> ok, I'll have another look
[05:34] <smspillaz> desrt: It could be that glibmm's Glib::MainLoop::quit () is broken
[05:35] <mfisch> desrt & smspillaz: thx for the assistance
[05:35] <desrt> mfisch: no prob
[05:35] <desrt> smspillaz: imho, glibmm is not worth the trouble
[05:35] <desrt> i'd just use glib's C API directly from C++
[05:35] <smspillaz> desrt: yeah I've noticed some ... weird stuff about it
[05:35] <smspillaz> desrt: though the C API is awkward to use directly
[05:35] <smspillaz> or at least, it doesn't fit our object model that well
[05:35] <desrt> smspillaz: the C API is awkward to use from C too :)
[05:36] <smspillaz> desrt: I think glib is just awkward really
[05:36] <smspillaz> or maybe I'm awkward
[05:36] <smspillaz> and glib is really cool
[05:36] <desrt> glib is pretty good for what it is
[05:36] <smspillaz> :p
[05:36] <desrt> it's pretty hard to make C look like an object-oriented language though
[05:36] <desrt> so some awkwardness is necessarily implied :)
[05:38] <smspillaz> desrt: http://images.cheezburger.com/completestore/2011/12/1/d5fb6962-c9c0-4095-8bcb-9a9140340b66.jpg
[05:38] <smspillaz> :3
[05:39] <smspillaz> 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] <smspillaz> desrt: anyways, g'night :)
[05:40] <smspillaz> I read through the documentation for gmmproc this morning and
[05:40] <smspillaz> yeah
[05:40] <smspillaz> my brain hurt
[05:41] <broder> ugh, but gmmproc is doing so much more work than it needs to these days
[05:41] <broder> i really, really wish somebody had a tool that generated C++ bindings using GI
[05:41] <smspillaz> oh there isn't one ?
[05:41] <smspillaz> hmmmmmmmmmmm
[05:41]  * smspillaz plots
[05:41] <broder> well, there's smoke-gobject/gobject-consume/whatever it's called
[05:41] <broder> but that's not really functional
[05:42] <broder> and gmmproc requires pre-writing .hg and .ccg input files that are basically pre-processor food
[05:42] <smspillaz> yeah  Isaw
[05:42] <broder> (so with gmmproc you're basically binding everything by hand)
[05:42] <smspillaz> when I was reading the gmmproc documentation I was kind of like
[05:42] <smspillaz> oh taht
[05:42] <smspillaz> *that
[05:42] <smspillaz> "haha"
[05:44] <broder> 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] <broder> and i'd be happy to try and help
[05:44] <smspillaz> I can see desrt sitting somewhere in Canada screaming "use a real language!" :p
[05:45] <broder> C++ is a real language!
[05:46] <broder> C++11 even more so!
[05:50] <pitti> broder: even more so, it's like the union of ten languages
[05:50] <pitti> if only it had a sensible way of handling ABI stability
[05:53] <smspillaz> _ZICanHaveAGoodABITooC8bp9_R3w
[05:57] <pitti> smspillaz: or the really nasty habit of putting constructors in .h files, it's insane
[05:57] <pitti> *cough* apt *cough*
[05:58] <RAOF> Well, where else are you going to put them? :)
[05:58] <pitti> RAOF: that's an obvious answer
[05:58] <pitti> "in your face" of course, everytime it blows up
[05:58] <RAOF> It's always fun when the .h file has a mixture of class declarations and inline functions.  Hello, nux!
[05:59] <pitti> 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] <pitti> with that, changing private members effectively breaks ABI
[06:00] <RAOF> Well, yes.
[06:02] <smspillaz> pitti: yeah, I usually try to keep code out of headers in compiz too
[06:02] <smspillaz> though there are still some places where it is there (left by other people that are not yours truly of course)
[06:03] <smspillaz> pitti: code out of headers and PIMPL is how I roll
[06:04] <smspillaz> pitti: I think C++11 brings a standard ABI though doesn't it ?
[06:04] <smspillaz> although, it still really easy break the ABI
[06:06] <smspillaz> pitti: C++ would also be nice if template error messages were not hundreds of lines long
[06:07] <RAOF> Heh.
[06:08] <RAOF> It would be nice if templates were runtime generated code, too :)
[06:08] <smspillaz> nah
[06:08] <pitti> err, what?
[06:09] <smspillaz> pitti: nope, apparantly it doesn't, must have misread something
[06:51] <didrocks> good morning
[07:05] <pitti> hey didrocks
[07:05] <didrocks> bonjour pitti, how are you?
[07:10] <pitti> didrocks: quite fine, thanks! had some fun this morning unbreaking the archive
[07:11] <didrocks> oh? the archive broke after alpha1 unfreeze?
[07:11] <pitti> software-center was uninstallable, causing all CD builds to fail, plus nautilus-python breaking edubuntu
[07:11] <pitti> yes
[07:11] <pitti> well, that's why we have a stable+1 team :)
[07:13] <didrocks> heh, from day 2, pitti for rescussing the archive! :)
[07:13]  * didrocks hugs pitti
[07:16]  * pitti hugs back didrocks
[07:46] <tkamppeter> pitti, hi
[08:18] <pitti> hey tkamppeter
[08:19] <tkamppeter> pitti, hi
[08:20] <tkamppeter> pitti, it is about CUPS 1.5.x. The IPP backend has a lot of regressions.
[08:21] <tkamppeter> pitti, bug 881843, bug 877958, bug 879625, bug 883585
[08:21] <ubot2> 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] <ubot2> 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] <ubot2> 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] <ubot2> 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] <tkamppeter> pitti, a volunteer, Robert Bradley, tried to fix these and worked with the reporters to get more info.
[08:23] <tkamppeter> 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] <tkamppeter> pitti, now I am thinking about doing this in our CUPS package, especially also as an SRU for Oneiric.
[08:24] <tkamppeter> pitti, on Precise I would then return to the current backend when the bugs are fixed upstream.
[08:25] <tkamppeter> pitti WDYT?
[08:25] <pitti> tkamppeter: hm, I thought the new one implied some change in the names/URIs of the printer
[08:25] <pitti> tkamppeter: if we would go back, wouldn't we change them back and break them again?
[08:27] <tkamppeter> 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] <tkamppeter> pitti, from where do you know that.
[08:28] <pitti> tkamppeter: oh, I'm mixing that up with the USB backend
[08:28] <pitti> that was libusb vs. /dev/lpUSBnn
[08:28] <tkamppeter> pitti, the USB backend is fine now after 2 SRUs.
[08:29] <tkamppeter> pitti, I could quickly prepare a new CUPS SRU package and we could replace the current not-yet-approved one.
[08:30] <pitti> 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] <tkamppeter> pitti, you mean s/USB/IPP/
[08:31] <chrisccoulson> niiiiiiiiiiiiiiice http://www.youtube.com/watch?v=RuIQskGD3u0
[08:31] <chrisccoulson> good morning everyone
[08:32] <pitti> tkamppeter: yes, I have it all backwards this morning :(
[08:32] <pitti> hey chrisccoulson
[08:33] <chrisccoulson> hi pitti, how are you?
[08:33] <tkamppeter> pitti, diff is attached to bug 881843, comment #6.
[08:33] <ubot2> Launchpad bug 881843 in cups "CUPS IPP print to Novell servers error since 11.10 upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/881843
[08:41] <pitti> tkamppeter: uh, this looks like a whole rewrite indeed
[08:41] <pitti> 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] <pitti> i. e. if they are using new features of the 1.5 backend
[08:43] <tkamppeter> 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] <tkamppeter> pitti, so I will apply it and tell you when the SRU package is ready for approving.
[08:44] <tkamppeter> pitti, can you already approve the HPLIP SRU? Thanks.
[08:45] <pitti> tkamppeter: will do an SRU run later today (have some urgent stuff to fix right now)
[08:45] <pitti> tkamppeter: so you want me to ignore or reject the current cups SRU upload?
[08:46] <tkamppeter> pitti, please reject the current CUPS SRU upload, I will re-upload it with the IPP backend patch.
[08:53] <pitti> tkamppeter: roger, done
[08:58] <chrisccoulson> hmmm, this is depressing - https://bugs.launchpad.net/ubuntu/+source/firefox/+bugs?field.tag=test-suite
[09:01] <pitti> chrisccoulson: are these filed by a bot of your's?
[09:02] <chrisccoulson> pitti - no, i filed them manually
[09:02] <chrisccoulson> i should probably figure out a way to do that automatically though
[09:13] <rodrigo_> hello
[09:20] <pitti> hey rodrigo_, how are you?
[09:20] <didrocks> good morning rodrigo_
[09:26] <Sweetshark> moin desktop world!
[09:27] <rodrigo_> hi pitti, didrocks
[09:27] <rodrigo_> and Sweetshark :)
[09:27] <didrocks> good morning Sweetshark!
[09:30] <pitti> hey Sweetshark
[09:30] <pitti> Sweetshark: I have a bug to report
[09:30] <pitti> openoffice.org 1:3.3.0-7
[09:31] <pitti> Sweetshark: that is correctly spelled "3:1.3.3-7"!
[09:32] <tkamppeter> 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] <ubot2> Launchpad bug 897309 in ghostscript "Package «gs-esp» is still needed in Oneric and higher" [Undecided,New] https://launchpad.net/bugs/897309
[09:33] <pitti> tkamppeter: depends; do they have a versioned dependency? if it's just "gs-esp", a Provides: will work fine
[09:33] <pitti> (meh, gs-esp was many, many years ago)
[09:44] <seb128> hey
[09:45] <Sweetshark> pitti: huh?
[09:50] <pitti> Sweetshark: just kidding
[09:50] <pitti> hey seb128
[09:51] <seb128> hey pitti, how are you?
[09:52] <pitti> seb128: quite fine :)
[09:52] <pitti> cleaned up after mvo and myself breaking the archive and daily builds yesterday
[09:53] <pitti> and now working on bug 897680 (ugh)
[09:53] <ubot2> 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] <pitti> stable team FTW :)
[09:55] <seb128> pitti, ;-)
[09:55] <tkamppeter> 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] <pitti> tkamppeter: I'd start with a Provides:
[09:56] <pitti> tkamppeter: I don't like reintroducing 5 year old clutter for that :/
[09:56] <pitti> seb128: indicator-me looks obsolete, right?
[09:56] <seb128> pitti, it is, I though we dropped it in Oneiric?
[09:56] <seb128> pitti, it got merged in indicator-session
[09:56] <pitti> seb128: that was replaced with the new session plugin
[09:57] <pitti> seb128: yes, but apparently re-synced to precise; I'll remove again and blacklist
[09:57] <seb128> pitti, right, did it come back by some way?
[09:57] <seb128> oh ok
[09:57] <seb128> yes, seems about right ;-)
[09:58] <mvo> pitti: *eeeh* what did I do ?
[09:58] <pitti> mvo: software-center depended on the new plugins which were in binNEW and universe
[09:58] <mvo> aha, ok
[10:00] <tkamppeter> pitti, CUPS SRU re-uploaded.
[10:01] <tkamppeter> pitti, patch also pushed to BZR.
[10:05] <pitti> tkamppeter: current version is in testing, so I guess I better upload this
[10:05] <pitti> tkamppeter: thanks!
[10:06] <Sweetshark> pitti: /me is in deer-in-headlight-mode. Monday is release branch off.
[10:06] <Sweetshark> ;)
[10:06] <pitti> Sweetshark: oh, that's kind of "release time crunch" for LibO then?
[10:08] <Sweetshark> pitti: yes, the scheduling of LO and Ubuntu never leaves me without a 'release time crunch' ;)
[10:12] <chrisccoulson> hah, i wish i could say the same for firefox
[10:12] <chrisccoulson> 24th April - Firefox 12, 26th April - Precise ;)
[10:15] <seb128> chrisccoulson, it's like the anti-perfect schedule, end of year holidays, hard freeze...
[10:19] <rodrigo_> brb
[10:56] <seb128> pitti, help :p
[10:56] <seb128> bug #898973
[10:56] <ubot2> 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] <seb128> seems like lool broke precise as well :p
[10:56] <seb128> that got 2 bug reports today so I guess it's a real bug somewhere
[10:58] <pitti> oh dear, that sounds like bug     871083
[10:58] <ubot2> 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] <pitti> seb128: only known workaround for that right now is to upload a package with dh_compress -XNEWS, I'm afraid
[11:01] <seb128> :-(
[11:02] <pitti> 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] <seb128> pitti, I can do it
[11:03]  * pitti hugs seb128, thanks
[11:03]  * seb128 hugs pitti back, you're welcome
[11:03] <seb128> 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] <pitti> seb128: as you prefer
[11:04] <seb128> ok
[11:04] <seb128> I'm on it ;-)
[11:04] <pitti> I'd dupe it so that we collect all the tasks on the master bug
[11:04] <pitti> and know what to revert once the real bug is fixed
[11:04] <pitti> but we can add a task without duping, too
[11:05] <seb128> pitti, ok, makes sense,  I can do that
[11:05] <htorque> pitti: hello! about above mentioned bug: i reported it too and it got duped - shouldn't apport have told me that?
[11:06] <pitti> htorque: I'm afraid we can't do that yet for package install failures
[11:06] <pitti> the log parsing isn't reliable enough yet to do that
[11:06] <htorque> ah ok, so just for crashers.
[11:06] <pitti> as many errors are followups, some are noise, etc.
[11:06] <pitti> it's not easy even as a human to spot the real root cause
[11:09] <pitti> tkamppeter: nice, Robert is already sending patches for the regressions to upstream
[11:17] <lool> seb128: you want me to upload with -XNEWS?
[11:18] <seb128> 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] <htorque> will -XNEWS also take care of README.gz and changelog.Debian.gz? because they seem to cause trouble too.
[11:20] <seb128> no, they should probably be added to the -X list
[11:20] <seb128> lool, ^
[11:20] <pitti> htorque: is that confirmed?
[11:20] <pitti> htorque: in libtasn, only NEWS was affected
[11:21] <lool> the bug and the dup only have NEWS listed
[11:22] <lool> oh it's in gtk+2.0
[11:22] <pitti> you can download both .debs, dpkg-deb -x them, and compare md5sums
[11:23] <htorque> 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] <lool> seb128: So why does it relate to me?  :-)
[11:24] <lool> hmm E: gtk2-engines-udeb udeb: udeb-contains-documentation-file usr/share/doc/gtk2-engines-udeb/
[11:24] <lool> grabing gtk+2.0
[11:24] <seb128> lool, I overlooked the -pixbuf part of the name, or rather confused it with your gtk2-engines upload from yesterday :p
[11:24] <seb128> lool, sorry :-(
[11:25] <lool> seb128: see how you blame me for everything!!1!
[11:25] <seb128> lool, (or in fact it's my secret plan to make you do desktop work ;-)
[11:25] <seb128> lool, (but sussssh)
[11:26] <lool> pitti: It's a bit ugly to add these -Xs if it also affects changelog and README  :-/
[11:28] <lool> Ah cjwatson was looking after it
[11:28] <pitti> lool: but at least we exactly know what to revert once it's fixed
[11:29] <lool> pitti: You mean we can grep Contents to find packages to revert?
[11:29] <pitti> lool: no, I think we should add tasks to that master bug
[11:30] <lool> oh wow, we moved from gzip 1.3.12 from *2007* to 1.4.0 from 2010
[11:30] <pitti> lool: but that wasn't it
[11:30] <lool> pitti: Ok; I hope it's not going to affect too many packages
[11:30] <pitti> lool: we just never noticed beefore multiarch
[11:30] <pitti> otherwise I had reverted it already
[11:30] <lool> pitti: Ok
[11:30] <pitti> i. e. it's not a regression
[11:31] <lool> pitti: It's just certain contents?
[11:31] <pitti> yes
[11:31] <pitti> and I never managed to reproduce it locally
[11:31] <pitti> must be something spethial on the buildds
[11:31] <pitti> different kernel, different file system, I don't know
[11:31] <pitti> PPAs are fine, local builds are fine with both lucid and precise kernel,e tc.
[11:31] <lool> oh wow
[11:31] <pitti> some buildds allegedly run the hardy kernel, I didn't try that locally
[11:32] <pitti> 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] <lool> we don't seem to log kernel version with build logs
[11:37] <pitti> right, so I could only guess
[11:38] <lool> proposed https://code.launchpad.net/~lool/launchpad-buildd/log-kernel-version/+merge/84247
[11:40] <pitti> lool: merci
[11:42] <pitti> seb128: retracer assertion failure> will have a look on monday, -ENOTIME any more today
[11:42] <seb128> pitti, ok
[11:42] <pitti> probably a weird bug which needs to be duped, etc., but need to figure out the logic
[11:45] <tkamppeter> pitti, SRU for bug 897309 uploaded, precise package will come soon.
[11:45] <ubot2> Launchpad bug 897309 in ghostscript "Package «gs-esp» is still needed in Oneric and higher" [Undecided,New] https://launchpad.net/bugs/897309
[11:49] <pitti> seb128: ok, worked around for now, they _should_ be back up until the next gksu crash comes in
[11:49] <seb128> pitti, danke
[11:49] <seb128> pitti, what is wrong with gksu?
[11:49] <seb128> (just curious)
[11:50] <pitti> bug 898874
[11:50] <ubot2> Launchpad bug 898874 in gksu "gksu crashed with SIGSEGV in __strlen_ia32()" [Medium,Confirmed] https://launchpad.net/bugs/898874
[11:50] <pitti> the traces all look slightly differently
[11:50] <pitti> I don't yet have a firm idea where the duplication logic fails
[11:50] <pitti> it's rather conservative right now with lots of asserts
[11:50] <pitti> so I'd rather just let it crash again when it happens
[11:50] <seb128> ok
[11:56] <pitti> I need to run now, cu later on the train (maybe, I'll mostly work offline)
[11:56] <pitti> have a nice weekend!
[11:57] <lool> pitti: Good WE!
[12:22] <tkamppeter> pitti, all SRUs for this week are uploaded now and ready for approval: CUPS, HPLIP, Ghostscript (10 bugs).
[12:39] <seb128> ricotz, hey
[12:39] <seb128> lool, so will you handle gtk or should I have a look? it seems you started on it?
[12:40] <seb128> pedro_, ola, thanks for the sru verification ;-)
[12:42] <pedro_> seb128, hello! np, i'm reviewing the ones that need verification today
[12:43] <seb128> great
[12:45] <ricotz> seb128, hey
[12:45] <seb128> ricotz, how are you?
[12:46] <ricotz> seb128, a bit busy, but fine
[12:46] <ricotz> seb128, hoping you are fine too
[12:46] <seb128> 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] <seb128> ricotz, I'm fine thanks ;-)
[12:47] <ricotz> seb128, i see, i think you can grab the ppa package, i dont remember making packaging changes though
[12:47] <seb128> ricotz, ok, are you fine if I sponsor that to precise then?
[12:48] <seb128> ricotz, is that version working fine for you? ;-)
[12:48] <ricotz> seb128, i am using it all day, i think the crashes i am getting arent related to rhythmbox, so feel free to sponsor it
[12:49] <seb128> ricotz, great, thank you
[12:50] <ricotz> seb128, as usual the tarball contains some patches to have a working "make dist"
[12:50] <seb128> ricotz, that's fine, did you send those in bugzilla or something?
[12:51] <seb128> ricotz, btw you should use "snapshot" rather than "release" in your changelog for git snapshots ;-)
[12:51] <ricotz> seb128, if i recall it correctly fta had an plugin issue, but nothing serious
[12:52] <seb128> ok
[12:53] <ricotz> seb128, havent sent them upstream since it is only some uncommented stuff in makefiles and a vala sample plugin problem
[12:54] <ricotz> seb128, yeah, the version string doesnt contain git so my script puts release in there
[12:58]  * ricotz needs to strip the "git" to keep the update path with the repo version ;)
[12:58] <lool> seb128: I had started it, but had started researching the gzip issue instead; doing it now
[12:59] <seb128> lool, thanks ;-)
[13:01] <ricotz> seb128, btw, how is it going with glib 2.31.x since you mentioned updating clutter/cogl which would need this newer glib
[13:02] <seb128> ricotz, today is friday so not the best day for a new glib serie, I think I will upload it early next week
[13:02] <seb128> ricotz, is the current version working fine for you?
[13:02] <seb128> i.e no surprise?
[13:03] <seb128> out of the eog patch we will ned
[13:03] <seb128> need
[13:03] <ricotz> mhh, can't think of anything currently
[13:03] <seb128> ok, that's a good sign ;-)
[13:03] <ricotz> there were mostly cairo/gtk issues
[13:04] <ricotz> seb128, did you see problems with the newer tp-mission-control version?
[13:04] <seb128> no, but I didn't watch closely, kenvandine is probably a better person to ask when he will be online
[13:05] <ricotz> ah, gnome-system-monitor has a similiar issue like eog
[13:05] <ricotz> ok
[13:05] <ricotz> if there arent any reports this tp problem might be caused by glib
[13:06] <seb128> not that I noticed but I'm not sure many people run precise yet
[13:06] <seb128> but anyway some bugs is not the end of the world for precise, I just wanted to make sure there is no known stoppers
[13:06] <seb128> we will figure what to do with issues when we hit them ;-)
[13:06] <ricotz> seb128, right
[13:07] <ricotz> better to find them early in the cycle rather than waiting with the upload
[13:33]  * rodrigo_ lunch
[13:33] <chrisccoulson> seb128, you should upload glib today. precise is boring right now ;)
[13:33] <chrisccoulson> i like living life on the edge!
[13:33] <seb128> chrisccoulson, be my guest and do it!
[13:34] <chrisccoulson> lol
[13:34] <chrisccoulson> i can't ;)
[13:34] <chrisccoulson> probably a good job!
[13:34] <seb128> you still didn't apply for upload rights?!
[13:34] <chrisccoulson> not yet. i haven't really needed to recently
[13:34] <seb128> you need them today see! ;-)
[13:34] <chrisccoulson> lol
[13:48]  * desrt yawns
[13:48] <desrt> smspillaz: get your situation sorted?
[14:16] <ockham_> hi, anyone feel like reviewing http://revu.ubuntuwire.com/p/unity-lens-bliss ?
[14:18] <mdeslaur> Thought of the day(tm): instead of deciding the default desktop applications based on toolkits and programming languages, we should have a valgrind faceoff
[14:19] <HOHOHaney> L
[14:19] <HOHOHaney> oops
[14:22] <seb128> didrocks, can you explain r211 in the nautilus vcs?
[14:22]  * didrocks looks
[14:23] <seb128> didrocks, it's used to get the strings translated?
[14:23] <seb128> or I'm overlooking something?
[14:23] <didrocks> seb128: hum, I would have thought that, let me check again, but I think we don't preprocess it at all
[14:24] <seb128> didrocks, we have a patch that add it to the POTFILES.in
[14:24] <seb128> debian/patches/13_translate_unity_launcher.patch:+debian/nautilus-home.desktop.in
[14:24] <seb128> didrocks, ^
[14:24] <didrocks> seb128: oh, ok, my bad then, please revert it
[14:24] <didrocks> seb128: I tried to look at debian/rules mainly
[14:24] <desrt> good morning, didrocks, seb128
[14:24] <didrocks> hey desrt :)
[14:24] <seb128> didrocks, ok, good, I prefered to check if the .desktop got deprecated and I was overlooking something
[14:24] <seb128> didrocks, thanks ;-)
[14:24] <seb128> desrt, hey, good friday to you!
[14:25] <didrocks> seb128: no no, just didn't see where it was used and thinking that we got the translation from another desktop file. Thanks for looking!
[14:25] <desrt> happy friday!
[14:31] <pitti> desrt: TGIF!
[14:31]  * desrt was quite enjoying this week, actually
[14:35] <dobey> pitti: hey
[14:35] <dobey> pitti: you wouldn't happen to have any idea why quilt would just randomly exit in the middle of applying a patch, would you?
[14:36] <pitti> dobey: urgh
[14:36] <pitti> dobey: reproducible?
[14:36] <dobey> and exit cleanly, that is
[14:36] <pitti> I see how dpatch could, but not quilt
[14:36] <dobey> pitti: sort of; it happens in the recipe build i'm trying to set up for rhythmbox daily builds
[14:36] <pitti> dobey: that's with "quilt push", or "quilt push -a", or package build?
[14:37] <pitti> ah, so during dpkg-source -x ?
[14:37] <pitti> either way, perhaps stracing reveals an error?
[14:37] <lool> seb128: Fighting local gtk+ build issue; the first one is fixed (docbook), I'm now getting another one, the first error in the log is from the testsuite, but it seems ignored; anyway, I'd rather fix it, are the new ubuntu_* functions supposed to be in the ABI or not?  they aren't in headers
[14:37] <dobey> it's quilt push -a -v i tihnk
[14:37] <dobey> think
[14:37] <lool> ubuntu_gtk_get_use_overlay_scrollbar, ubuntu_gtk_menu_shell_activate_first etc.
[14:37] <seb128> kenvandine, ^
[14:37] <dobey> hrmm, actually, maybe it is being applied, but then is failing to unapply for some reason
[14:38] <lool> kenvandine: Hey Ken, search for "FAIL: abicheck.sh" in https://launchpadlibrarian.net/86349189/buildlog_ubuntu-precise-amd64.gtk%2B2.0_2.24.8-0ubuntu1_BUILDING.txt.gz
[14:38] <seb128> lool, they are used only by overlay-scrollbar I think so I'm not sure how public we want them
[14:38] <lool> kenvandine: the lines with +es are new public symbols; either we want these to be public, then we should have them in a .h and update gtk/gtk.symbols, or we want them to be private, naming them _something should be enough to hide them
[14:39] <lool> seb128: Ok; will leave it to Ken
[14:39] <dobey> pitti: unfortunately, i can't strace, as it's on the LP server; i can't reproduce the problem locally :(
[14:39] <seb128> lool, I would not bother with cleaning for gtk2, those are probably fine to let as it
[14:40] <seb128> lool, but I'm less perfectionist than you ;-)
[14:40]  * kenvandine looks
[14:40] <dobey> pitti: https://launchpadlibrarian.net/86377740/buildlog.txt.gz
[14:42] <lool> seb128: I'll be uploading now, but I didn't manage to complete a build; I get an error and didn't verify the binaries: dpkg-buildpackage: erreur: fakeroot debian/rules binary a produit une erreur de sortie de type 2
[14:42] <lool> I think it wont happen on the buildds
[14:43] <seb128> lool, yeah, if you just changed the rules to add the -X there is no reason runtime should break, just upload ;-)
[14:43] <pitti> dobey: but I supose 04_pause_button.patch actually does apply cleanly locally?
[14:43] <pitti> dobey: did you try with bzr-builder?
[14:44] <dobey> pitti: bzr dailydeb recipe isn't working for me locally, because for some reason it seems to want the rhythmbox branch to be a source package branch with the upstream-foo tags in it :(
[14:45] <pitti> dobey: uh? well, any of the branch needs to provide a debian/ dir
[14:45] <pitti> dobey: what does your recipe look like?
[14:45] <pitti> dobey: it should work locally, otherwise there's little chance of working in LP
[14:45] <dobey> https://code.launchpad.net/~ubuntuone-hackers/+recipe/rhythmbox-dailies
[14:45] <pitti> dobey: are you trying to merge against ubuntu:rhythmbox?
[14:45] <dobey> no
[14:45] <dobey> lp:rhythmbox
[14:46] <dobey> which is the import of upstream git master
[14:46] <kenvandine> lool, those have bounced around a bit between being in headers and not... agateau cleaned that stuff up quite a bit last cycle and there was some reasoning for this...
[14:46] <kenvandine> agateau, do you remember?
[14:46] <lool> kenvandine: It's inconsistent with other patches where gtk.symbols is correctly patches
[14:46] <lool> *patched
[14:46] <dobey> pitti: building manually locally works fine; i can dpkg -S -sa and then pbuilder-oneiric the .dsc and it builds
[14:46] <lool> seb128: uploaded
[14:46] <james_w> Patch 04_pause_button.patch does not remove cleanly (refresh it or enforce with -f)
[14:46] <james_w> make: *** [reverse-patches] Error 1
[14:46] <kenvandine> lool, yeah... maybe we just need to add them there
[14:47] <seb128> lool, thanks!
[14:47] <didrocks> ok, all unity test cases in checkbox now :) Will have to debug checkbox now though :/
[14:47] <lool> kenvandine: I had a quick look, and given these aren't in headers, I'd rather have them renamed from ubuntu_foo to _ubuntu_foo
[14:47] <pitti> dobey: can you try with: nest-part packaging lp:~ubuntuone-control-tower/rhythmbox/packaging-dailies debian debian
[14:47] <pitti> dobey: otherwise you put the *whole* branch into debian/
[14:47] <lool> kenvandine: If you look at gtk.symbols, it maps to header files
[14:47] <pitti> dobey: i. e. you'll have a debian/debian/
[14:47] <james_w> dobey, that doesn't sound like it randomly exiting cleanly in the middle of applying a patch?
[14:48] <dobey> pitti: the whole branch is only the stuff that's inside debian/
[14:48] <pitti> dobey: oh, I see
[14:48] <pitti> (that's unusual)
[14:48] <pitti> dobey: so, I'm in a train, so I can't try that recipe right now (too little bandwidth)
[14:48] <pitti> dobey: do you have the error message that it produces locally?
[14:48] <dobey> pitti: sure
[14:48] <kenvandine> lool, yeah... i want agateau to weigh in on that, i think there was a reason they need to be public
[14:48] <dobey> bzr: ERROR: No such tag: upstream-2.90.1+r7750dding file 20/25
[14:49] <dobey> that last bit is where it screwed up writing to the terminal and bzr branch output got overwritten in the shell
[14:49] <dobey> the dding.* bit
[14:49] <james_w> dobey, are you running with --allow-fallback-to-native?
[14:50] <pitti> dobey: I'm out of my wisdom then :/ but look, james_w to the rescue!
[14:50] <dobey> james_w: ah no
[14:51] <james_w> RUN ['bzr', 'dailydeb', '--safe', '--no-build', '/home/buildd/build-47ee96de33267c60c108b9c3ed958637e9ffc494/chroot-autobuild/home/buildd/work/recipe', '/home/buildd/build-47ee96de33267c60c108b9c3ed958637e9ffc494/chroot-autobuild/home/buildd/work/tree', '--manifest', '/home/buildd/build-47ee96de33267c60c108b9c3ed958637e9ffc494/chroot-autobuild/home/buildd/work/tree/manifest', '--allow-fallback-to-native', '--append-version', '~precise1']
[14:51] <dobey> trying that now
[14:52] <dobey> but just running the quilt push -a -v then quilt pop -a -R in the tree works fine for me; which is why i'm confused
[15:04] <james_w> dobey, what about with "fakeroot debian/rules clean" in between?
[15:05] <dobey> i'll try that in a minute; i've commented out all the patches in series except for one now
[15:06] <dobey> and it still fails on that one patch; which is a one-line change :(
[15:08] <dobey> james_w: debian/rules clean rmoves the patches
[15:09] <dobey> james_w: so i suppose if i run quilt pop now it will fail
[15:10] <dobey> it seems to be what is runs quilt pop anyway
[15:10] <james_w> I guess that could be the cause of quilt failing
[15:11] <dobey> well, it's failing *inside* the "fakeroot debian/rules clean" in the recipe build
[15:17] <pitti> have a nice weekend everyone!
[15:18] <dobey> cheers pitti
[15:23] <mterry> pitti, can you set https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-unity-greeter to be a precise goal?  it doesn't show up in work item tracker right now
[15:23] <seb128> haha
[15:23] <seb128> mterry, welcome to the club of the people who tried to get .symbols for cpp and gave up on it using -V ;-)
[15:24] <mterry> seb128, heh.  :)
[15:24] <didrocks> we should create a launchpad team :)
[15:24] <charles> seb128, my inbox says you are a bug triaging *machine* :)
[15:24] <mterry> seb128, I thought I had it.  I used pkg-kde to write a symbols file that had some tags in it, but not enough.  still failed on amd64
[15:24] <seb128> charles, lol
[15:24] <seb128> charles, I wish others who do a bit extra triage so I would have less to do :p
[15:25] <seb128> mterry, btw while you are here, do you want me to take over the gedit 3.2.3 sru?
[15:25]  * mterry bugs didrocks about reviewing his quickly-gtk3 branch
[15:25] <seb128> mterry, i've time today for it
[15:25] <mterry> seb128, did I sign up for that?  I didn't write it down...  sorry  :-/
[15:26] <didrocks> mterry: s/bugs/hugs rather? :)
[15:26] <mterry> didrocks, ah yes... typo...  :)
[15:26] <seb128> mterry, I'm slightly disappointed that you didn't do the compiz sru sponsoring yesterday btw :p maybe pitti will get to it on monday during his turn ;-)
[15:26] <didrocks> mterry: as you suffer from marshmalling the C++ symbols file as well, I guess it can take some time for looking at your branch!
[15:26] <mterry> seb128, oh no I do have the gedit sru in my queue
[15:27] <mterry> seb128, I'll get to it in a bit
[15:27] <seb128> mterry, no, I signed you up for it in a but comment you probably didn't read :p in fact they worked around the pygobject,snippet segfault
[15:27] <seb128> mterry, you had that pygobject bug assigned to you
[15:27] <seb128> mterry, ok, thanks
[15:27] <mterry> yup, bug
[15:27] <mterry> 863773
[15:28] <seb128> mterry, if you have other things to do that's fine, I'm not too busy today so I can do it as well, just tell me
[15:28] <mterry> seb128, no problem, you keep triaging  :)
[15:28] <seb128> lol
[15:33] <asac> heyho
[15:33] <asac> at some point there was the system -> preferences -> preferred applications thing
[15:34] <asac> nowadays that doesnt exist anymore :(
[15:34] <asac> at least i cannot find it
[15:34] <asac> where can i now switch mailto: and http: mime handler?
[15:36] <asac> me opens gnome-control-center again in hope to find it
[15:36] <didrocks> asac: it is in gnome-control-center
[15:36] <didrocks> asac: the system info
[15:36] <didrocks> then, there is preferred apps
[15:37] <asac> didrocks: guys that make absolutely no sense :)
[15:37] <didrocks> asac: I didn't say it did make sense :)
[15:37] <asac> i tried _every_ other button in control center
[15:37] <asac> this one i left out
[15:37] <didrocks> no every, see, don't lie! :)
[15:37]  * didrocks hugs asac
[15:37] <asac> oh no
[15:37] <asac> i cannot set a custom command there anymore
[15:37] <asac> i want to make desktop-webmail package work again
[15:37] <asac> guess it needs a .desktop file
[15:37] <didrocks> hum, not sure about that one apart from editing the mimeapps file :/
[15:38] <asac> hmm
[15:38] <didrocks> or yeah, creating a desktop, should be better
[15:38] <asac> it has a .desktop file
[15:38] <asac> ah
[15:38] <didrocks> hum, and the mimetype is matched?
[15:38] <asac> MimeType=x-scheme-handler/mailto
[15:39] <asac> is missing
[15:39] <asac> odd
[15:39] <asac> do i need to run something to pick this up if i try it manually?
[15:40] <didrocks> good question, I would say just put in the standard XDG directory and maybe rerun g-c-c, never tried TBH
[15:40] <didrocks> mterry: so, gesttings pick the new schemas in XDG_DATA_DIR ?
[15:41] <asac> let me see
[15:43] <dobey> for a .desktop file?
[15:44] <mterry> didrocks, yeah
[15:44] <dobey> just put the .desktop in /usr/share/applications, and i think there is a trigger that runs the desktop file cache thing
[15:44] <mterry> (at least that's my memory, it's been a while since I wrote that branch)
[15:44] <didrocks> mterry: waow, great, I was thinking it was compulsory to add the filename in /etc/dconf/profile/
[15:45] <dobey> to change the default, just put an override in the gsettings overrides dir i guess
[15:47] <asac> didrocks: just restarting it didnt help
[15:47] <asac> didrocks: i changed the .desktop file in applications
[15:48] <asac> cat /usr/share/applications/desktop-webmail.desktop  | pastebinit
[15:48] <asac> http://paste.ubuntu.com/757192/
[15:48] <dobey> asac: you need to run update-mime-database
[15:48] <didrocks> dobey: this is not about override, this is about trunk testing
[15:48] <asac> kk
[15:48] <asac> thanks dobey
[15:49] <asac> dobey: hmm. wasnte there a more convenient scrip that we call in postinst?
[15:49] <asac> this one tells me:
[15:49] <asac> sudo update-mime-database
[15:49] <asac> [sudo] password for asac:
[15:49] <asac> Usage: update-mime-database.real [-hvV] MIME-DIR
[15:49] <dobey> asac: i think there's a trigger that runs if your package has .desktop file in /usr/share/applications, so you don't have to do anything in postinst actually
[15:49]  * asac tries to think hard
[15:49] <dobey> asac: update-mime-database /usr/share/applications
[15:50] <dobey> sudo of course :)
[15:50] <asac> hmm. i am sure in the past we had a convenient script hat didnt need the dir
[15:50] <asac> but ok
[15:50] <asac> i am old anyway
[15:50]  * ogra_ agrees
[15:50] <ogra_> :P
[15:50] <asac> hehe
[15:50] <asac> sudo update-mime-database /usr/share/applications
[15:50] <asac> Directory '/usr/share/applications/packages' does not exist!
[15:50] <asac> so see
[15:50] <asac> i tell you ... we dont use that :)
[15:50] <dobey> oh
[15:50] <dobey> update-dsektop-database
[15:51] <dobey> sorry
[15:51] <dobey> got confused with fdo mixing mime and .desktop stuff :)
[15:51] <asac> yay
[15:51] <asac> and that is not in PATH
[15:51] <asac> that sounds more like what i remember
[15:51] <dobey> [dobey@lunatari:~]: which update-desktop-database
[15:51] <dobey> /usr/bin/update-desktop-database
[15:51] <asac> hmm
[15:52] <asac> well its in path
[15:52] <asac> strange
[15:52] <asac> ok thanks
[15:52] <asac> lets see
[15:52] <asac> cool
[15:53] <asac> thanks dobey
[15:53] <dobey> sure :)
[15:55] <seb128> hey asac
[15:55] <seb128> asac, did you get it working?
[15:58] <asac> seb128: yes. though send link from browser doesnt work (guess a bug)
[15:58] <asac> but thats on desktop-webmail side ... so thanks
[15:58] <asac> ok off
[15:58]  * asac sick
[15:58] <seb128> asac, take care!
[15:59] <asac> will do. thanks!
[16:00] <asac> seb128: oh ... can you tell me what wrapper/api is used when i right click on gnome-terminal and use send mail ?
[16:00] <asac> xdg-open i guess
[16:01] <seb128> chrisccoulson, ^ do you know?
[16:01] <seb128> asac, but I would guess it's gio
[16:01] <seb128> like it probably triggers the default handler for those urls
[16:01] <seb128> same story than for the browser
[16:01] <chrisccoulson> yeah, i'd imagine it's just using gio
[16:01] <chrisccoulson> nothing sane uses xdg-open
[16:02] <chrisccoulson> only chrome uses that ;)
[16:02] <seb128> chrisccoulson, not even firefox? ;-)
[16:02] <chrisccoulson> seb128, nope :)
[16:02] <seb128> good ;)
[16:02] <asac> is there a command line wrapper or just api?
[16:02] <asac> in any case xdg-open shows the same problem
[16:03] <asac> as firefox send mail
[16:03] <asac> and gnome-terminal send mail
[16:03] <asac> anyway ... will dig a bit deeper
[16:03] <chrisccoulson> asac, what's the issue?
[16:04] <asac> chrisccoulson: i am sick ... will ping you over weekend if i feel better :/
[16:04] <asac> thanks for your helP!
[16:04] <chrisccoulson> asac, ok, no worries. hope you feel better soon :)
[16:04] <asac> it is about desktop-webmail
[16:04] <asac> so most likely nothing important fo ryou :)
[16:04] <asac> bye
[17:49] <seb128> lool, it seems your DB2HTML=non-existent broke the i386 gtk2 build
[17:50] <seb128> well I assume it's that, I don't see what else would have done it
[18:23] <seb128> chrisccoulson, congrats, you won bug #865490
[18:23] <ubot2> Launchpad bug 865490 in nautilus-sendto "nautilus-sendto crashed with SIGSEGV in _start()" [Medium,Confirmed] https://launchpad.net/bugs/865490
[18:23] <seb128> ;-)
[18:24] <chrisccoulson> yay \o/
[18:25] <chrisccoulson> right, i've got to disappear. travelling round to jo's parents house this evening
[18:25] <chrisccoulson> sigh :/
[18:25]  * didrocks waves good night and good week-end!
[18:25] <didrocks> see you on Monday everyone!
[18:26] <Sweetshark> chrisccoulson: I was tought it that way: action items always go to the guy who is not in the meeting ;)
[18:26] <Sweetshark> ... too late
[18:26]  * Sweetshark is gone for the weekend too.