=== Aww is now known as Gingersnap === Gingersnap is now known as Aww [00:51] HI ALL === thumper-afk is now known as thumper [00:54] i was trying to use UNETBOOTING software and i have a problem with it it dont have the verison that i downloaded on the list it just goes up to UBUNTU 12.04 LIVE and not what i have UBUNTU 13.04 higest it is the UNBUNTU 12.04 LIVE [00:56] do i choose the UBUNTU 12.04 LIVE [00:56] IM TRYING TO BOOT IT FROM A [00:56] opps caps [00:56] USB drive [00:58] i trying to boot and install it from THE USB STICK and not a DVD CD [00:59] can somone hep me please === fginther|afk is now known as fginther === amithkk_ is now known as amithkk === Aww is now known as [Cupcakes] === [Cupcakes] is now known as Aww === m_conley is now known as m_conley_away [04:37] good morning [04:48] with the latest MIR acked, I think it's time to get unity 7 and touch to saucy! [04:49] urgh, who relaunched the indicators /o\ [04:50] someone redeployed it :/ [05:06] session restart [05:12] * didrocks grumbles about the commit and rebuild from adding upstart session to unity [05:12] "no best time than 12 hour before releasing and asking for a rebuild" [05:27] ok, there is for an hour of test running, better to do my exercice meanwhile :) [06:03] didrocks: can saucy be updated to latest zeitgeist version 0.9.14? [06:11] sorry, I meant 0.9.13 [06:27] m4n1sh: not today, but you can ask for sponsoring :) [06:28] jibel: I can't have the tests running anymore, not sure if it's a real regression or something else [06:38] * didrocks recreates a container due to the kernel upgrade, just in case with dkms… [06:39] it seems to be latest ted's change [06:39] didrocks: oh yeah. I wasn't asking you to do right away. Just wanted to know if anything else needs to be done from my side before it is fit to be accepted. Just wanted to make sure nothing is missing form my side [06:40] m4n1sh: if you can propose a package for sponsoring, that would be awesome :) [06:41] What's the future plan of Ubuntu's CJKV inputting stack? [06:42] didrocks: it isn't in debian as I can see. will propose for sponsorship [06:42] m4n1sh: thanks [06:43] maxiaojun: more a question for #ubuntu-unity I guess [06:43] didrocks: thanks [06:47] hey didrocks , which tests ? [06:48] jibel: indicators and unity. I thought it could be a dmks issue when upgrading the kernel, but not. I think it's one of the very late ted's commit that was taken with latest build [06:48] jibel: I just reverted it and relaunched an unity bulid [06:49] didrocks, unity died during the tests? [06:49] jibel: I think it's the panel service [06:49] and then, it's making unity dying [06:50] jibel: 4 runs, reproduceable reliably [06:50] jibel: tedg migrated the panel service to upstart [06:50] and removed the .service file [06:50] I'm sure there is something with the service not responding and unity goes to a bad trip :p [06:51] didrocks, i'll restart the machine to make sure the env is clean, and restart indicators [06:51] jibel: I did that [06:51] ah [06:51] jibel: and even reprovisionned after that [06:51] jibel: so, let's see with the new unity [06:52] jibel: I'm stopping the current check [06:52] as soon as i386 is published [06:52] I'll rerun the indicators [06:52] with whole ppa [06:52] (as the tests are quicker than unity) [06:52] didrocks, we can increase the memory allocation, this box has 8G but that'd just push the wall further [06:52] jibel: doesn't seem to be linked to memory though [06:53] jibel: when it was stuck, we only had 400MB taken [06:53] and no swap [06:54] didrocks, right, after dropping the caches there's only 109MB used :/ [06:54] jibel: let's see and cross fingers that the upstart change is the guilty one [06:55] didrocks, did you watch on the KVM the state of the screen? [06:56] jibel: no, I just relyied on logs, I need to setup KVM here I guess [07:59] hey there [07:59] f r i d a y ! [07:59] tgif [08:00] * hyperair feels fairly caffeine-deprived [08:00] merci dieu c'est vendredi [08:00] Zum Glück ist Freitag! [08:00] so what will we flame about today? [08:01] pitti: pick a default and change your mind and discuss :) [08:12] pitti: don't tempt me :) [08:12] * czajkowski tempts didrocks with some cake [08:12] ahah ;) [08:13] we can't flame without seb128 anyway :P [08:14] we've done the default language should be french and people didn't see the joke there [08:14] they really took it seriously [08:14] ah, was it a joke? [08:14] that was hilarious :) [08:15] didrocks: oh yes indeed so many threads were started with OMG... [08:15] amusing really [08:15] hey didrocks Laney pitti czajkowski, happy friday! [08:15] seb128: bonjour seb128, bon vendredi ! [08:15] whooo Friday \o/ [08:15] * Laney gets down [08:15] hey seb128 [08:15] seb128: tbird sucks! let's get evo back in [08:16] * czajkowski hands pitti some soap to wash his mouth out :) [08:16] I'm really missing my appointments in the indicator [08:16] pretty thunderbird is pretty [08:16] yeah, well, I guess it's still too early, I'm not really in flamebait mood yet [08:16] * pitti pats his mutt [08:17] pine ftw! [08:17] pitti, appointements in the indicator work ... did you try to install evo to see if that makes it work for you? [08:18] wohoo, getting serious now :) [08:18] * pitti installs evo [08:18] didrocks: some feedback from the raring SRU btw.. ugly changelogs like some entries with only the automatic messages. should we start to clean those for SRUs if they still happen? as another note, the fixes are not yet in saucy ;) [08:19] Mirv: can we handle that on Monday? TBH, completely spawn with saucy ;) [08:19] Mirv: but yeah, if you have cases with only empty changelog, would be interesting to have the test case exactly [08:20] seb128: so I installed evolution (killed ~/.config/evolution, .cache, .local etc. before); I see my gcal stuff there [08:20] $ killall indicator-datetime-service [08:20] My manually added calendar still works but the UOA one is busted of course [08:20] didrocks: yes, let's continue then, to check eg. if those were already fixed or could still happen [08:20] now I indeed see the appointments in the indicator [08:20] Mirv: right :) [08:21] seb128: I killed evo and evo-alarm-notify, appointments in indicator still work [08:21] so indeed, installing evolution does some magic to make that work [08:25] pitti, well, to me the issue was that calendar needs credentials [08:25] but the indicator doesn't have an UI to ask for your password [08:25] so auth would just fail [08:25] hm, but UOA already knows the account [08:26] but that was before the online account integration time [08:26] right [08:26] empathy and gnome-documents just work then [08:26] seems like buggy still === vrruiz_ is now known as rvr [10:37] chrisccoulson: I have your rain and cloud, please come and collect and bring it back up north! [10:38] lol [10:38] czajkowski, it's beautiful sunshine here [10:38] chrisccoulson: https://twitter.com/Crustyfur/status/342935384298225664 [10:38] I'm right under that flippin' cloud! [10:38] hah :) [10:39] czajkowski, is it thundering? i'm only interested in collecting your weather system if it has thunder in it [10:39] yes we've had thunder [10:39] it scared the hens [10:39] ooh [10:39] they were very much unimpressed [10:39] feel free to send that up to the midlands ;) [10:40] the hens or the weather :) [10:40] czajkowski, just the bits of the weather that are thundering :) [10:40] bah [10:56] seb128, if gee-0.8 and gee-1.0 exports the same symbols and libunity links with 1.0 and some other app that also uses libunity links with 0.8, will the dl be able to resolve all that? [10:56] mhr3, that seems like a recipe for troubles [10:56] orly? :) [10:56] mhr3, you are likely up for symbol clash [10:57] mhr3, don't do that :p [10:57] it's being done as we speak [10:57] :-( [10:58] mhr3, where did you find gee-1.0? [10:58] mhr3, hi, yeah, that won't work [10:58] seb128, hi [10:59] ricotz, hey [10:59] seb128, libgee2 vs libgee0.8 [10:59] mhr3, ah, 0.6 and 0.8 then [10:59] seb128, yea, 0.6 has gee-1.0 as pc name [10:59] mhr3, the whole runtime stack needs to use the same gee [11:00] :/ let's prepare for some weird gee crashes then [11:00] mhr3, what is having the issue? empathy? [11:01] seb128, anything that will use folks + libunity on S [11:01] so yes, empathy comes to mind first [11:01] unless they dropped libunity stuff [11:01] shrug [11:02] mhr3, any plan to port libunity to gee 0.8 or 0.10? ,-) [11:02] if it becomes a real problem for us... [11:03] the two gees are largely compatible so it might be a simple thing of s/gee-1.0/gee-0.8/ [11:03] we should maybe directly go for 0.10 [11:04] or we could remove any gee stuff from libunity and just use glib containers [11:04] you can do everything with list array and hashtable, no? :) [11:04] seb128, 0.10 doesnt change api and is 0.8 [11:04] ricotz, ok [11:11] Can someone review the patch attached to this bug? https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/920834 [11:11] Ubuntu bug 920834 in ibus (Ubuntu) "ibus cannot show icon in panel without appindicator" [Low,Confirmed] [11:19] Can someone review the patch attached to this bug? https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/920834 [11:19] Ubuntu bug 920834 in ibus (Ubuntu) "ibus cannot show icon in panel without appindicator" [Low,Confirmed] === dednick is now known as dednick|lunch === MacSlow is now known as MacSlow|lunch === dednick|lunch is now known as dednick === cking_ is now known as cking === olli_ is now known as olli [12:31] seb128: could you rebuild gtk3 for the wayland transition? === MacSlow|lunch is now known as MacSlow [12:32] jbicha, yes, I've an upload planned anyway [12:32] does it rebuild without change? [12:34] I haven't tried yet but it's breaking my attempts to build against -proposed [12:42] can you try? [12:48] trying [12:58] hey seb128 you might be able to help me with a quick question. For apps.ubuntu.com/cat with have a basic apt script that is run each day, it's been breaking recently due to faulty .desktop files noodles has filed a bug against the app and fixed the script so it no longer breaks. if we got a log of the .desktop issues though would be useful to you guys? [12:59] davmor2, hey, what sort of errors? [13:00] seb128: it would pick up on any error that apt throws up for an app basically, I think the issue was with a universe app where the .desktop file was laid out incorrectly off the top of my head, but we need to pull in every app from all the standard repos basically [13:01] well, if you find error in .desktop shipped by packages sure open bugs [13:02] seb128: okay that's great, so if we store a log of the issues and can file a bug for each one that is the way to go then yes? [13:03] correct [13:08] seb128: that's great then thanks for your time :) [13:08] yw [13:15] seb128: yes, the GTK3 desktop branch builds ok [13:15] jbicha, great, thanks for confirming === hggdh_ is now known as hggdh === davidcalle_ is now known as davidcalle [13:51] seb128: Laney: are you two implementing system settings designs for touch as per mpt's designs? [13:52] xnox: that's the idea [13:52] why? [13:53] xnox, not only us but yes [13:53] xnox, see https://blueprints.launchpad.net/ubuntu/+spec/client-s-system-settings-panels [13:53] Laney: i think I am on the hook for OOBE (out of the box experience) the wizard portion of it, which helps the user setup the phone: name, U1, timezone, language, etc. [13:54] which all well, call into system settings to implement those. [13:54] I also wonder if any design can be shared between the two, or at least the backend logic. [13:54] xnox, system settings doesn't provide APIs in the current design [13:54] we should yes [13:54] those seems like dbus calls [13:54] we should do a qt plugin to share [13:54] seb128: hmmm.... ok. [13:54] or maybe a settings-backend [13:55] seb128: it's just, unlike the desktop. OOBE will stay installed, in case user resets the phone. I even ponder if we should just be a single app/source package doing it all. [13:56] the idea of the settings stuff is to make reusable widgets as much as possible [13:56] pitti: hey. tedg and i wanted to talk to you yesterday [13:57] pitti: we want to make apport collect a stacktrace and file a bug whenever a program hits a g_critical() [13:57] hey desrt [13:57] seb128, Do you know why the debian introspection policy wants the dev package to depend on the gir package? It seems a bit odd to me. [13:57] pitti: we have a few ideas for ways to do this but your input is very appreciated [13:58] pitti: one of the most obvious ways is to do «if (fork()==0)abort();» on each critical [13:58] so apport will see the spawned child crashing and record its stacktrace [13:58] (which will be the same as the parent that reached the critical) [13:58] ah, that should actually work [13:58] easier than calling apport in glib [13:58] tedg, they are part of doing dev with the lib? not really sure, but before that we had to duplicate lib/gir in build-depends for most packages [13:58] pitti: so the one problem with this is that we lose the other threads [13:58] desrt: however, please don't just call abort() [13:59] desrt: it would be good if we could salvage the actual message, otherwise the reports will be mostly useless [13:59] pitti: which i guess isn't _too_ important [13:59] desrt: i. e. set teh __glib_abortmsg or whatever the name was, so that we can pry it out of the core dump and use as the title and dupe signature [13:59] sounds good [14:00] pitti: so another question: you know we have these cases where you start a program and get like 2000 criticals all at once [14:00] how is apport/lp going to like that? [14:00] apport has a rate limit [14:00] does it do deduping before filing bugs? [14:00] you can only have one unseen report per user and program [14:00] oh. neat. [14:01] pitti, Actually ev is looking at fixing that. [14:01] and after you saw the report (i. e. in the apport popup), you can only have three reports per program and user and day [14:01] tedg: fixing what? [14:01] pitti: perfect [14:01] pitti, Making it per signature [14:01] urgh, no! [14:02] pitti: what is the absolute best way for me to crash the program in the fork? abort() after setting that variable? [14:02] desrt: so at least for now we'd get them trickle in, instead of one huge blast [14:02] which is probably good, since often one has followup criticals [14:03] indeed -- and you always want the first one [14:03] although that is an interesting point.... [14:03] desrt: abort() sounds nice, SIGABRT is more appropriate to this than a SIGSEGV or so [14:03] you guys do know that some of our programs spew a lot of criticals, right? [14:03] there is a possible race here if you fork() off a bunch of things all at once in response to a set of criticals === Guest52607 is now known as larsu [14:03] the second fork() may get to the abort() first [14:04] desrt: you could either re-use the g_assert() code of setting that variable and then fork and do the action that it would do as if it was fatal [14:04] * desrt wonders if abort() is signal-handler-safe [14:04] desrt: fork() and wait() ? [14:04] pitti: interesting. [14:04] desrt: I don't think you want to write a massive number of core files in parallel anyway, so serialization sounds safer to me [14:05] pitti: we already have an established convention that if (fork()) { wait() } else { exit() } is non-blocking [14:05] desrt: at least we should start small [14:05] since g_spawn_async_with_pipes() does exactly this [14:05] Bug 1173818: "Unable to set solid colors and gradients as desktop background" - anyone know a workaround or status on this bug? [14:05] Launchpad bug 1173818 in gnome-control-center-unity (Ubuntu) "Unable to set solid colors and gradients as desktop background in gnome-control-center" [Undecided,Confirmed] https://launchpad.net/bugs/1173818 [14:05] (it creates an intermediate helper process and waits for it to quit in order to know if the exec() was successful) [14:06] also so it can preemtively reap... [14:06] pitti: another option is that we only fork/abort the first time [14:06] i like your wait idea, though [14:06] desrt: just thinking aloud, could the child set the fatal flag, and just call g_critical() again, with the same message? [14:06] pitti: definitely not [14:06] desrt: that would avoid copying the assert msg logic [14:07] ah, it woudl duplicate teh screen output [14:07] pitti: after fork() in a threaded program you are in a dangerous spot [14:07] when you fork() only the thread that made the syscall is brought into the new process image [14:07] and the other threads may have been holding locks [14:07] so you can't do anything that may try to acquire a lock [14:07] * ogra reads didrocks mail and wonders who cares about unity7 .... we want unity8 ! [14:07] ie: you should limit yourself to syscalls and libc "signal-handler-safe" functions [14:08] ogra: don't tell that I spent all those crazy hours for nothing :p [14:08] ogra: but but, you have touch as well! [14:08] you mean unity8 ? [14:08] desrt: right; so poke the message into __glib_assert_msg and abort(), and the parent wait()s, that sounds feasible to me [14:08] pitti: great [14:09] tedg: since you brought this topic, do you want to write the patch? this sounds like something we'd be happy to have upstream now... [14:09] i'm happy to do it as well, though [14:09] desrt: NB that each critical will incur a significant delay, though [14:09] as writing and compressing the core dump takes a while [14:09] pitti: and the parent doesn't get SIGCHLD until that is done? [14:10] desrt: apport fortunately already has this new class "RecoverableError" which we can use for this (as it's not really a crash) [14:10] pitti: ya... this is what ted was originally using [14:10] desrt: no, the child needs to hang in limbo until the kernel finished coredumping it [14:10] and spawning apport directly to report it [14:10] but it lacked a proper trace [14:10] so we're trying to figure out how to get that [14:11] pitti: hmmmmmm [14:11] we are going to get looots of those, though :) [14:11] So in my original patch I turned it on with an env var. [14:11] Basically so that we could ramp up slowly [14:11] i think that's a fairly reasonable idea [14:11] so maybe at first we should limit it to some packages, or never send these to LP, but only to errors [14:11] G_DEBUG=fork-criticals or so [14:12] ^ indeed [14:12] it's bad to decide it in apport, as at this point the overhead has already happened [14:12] desrt, In the short term I need to finish off some HUD stuff... so if you've got time now, go ahead. Otherwise I'll get to it. [14:12] so another interesting idea may be to do an async wait for the child [14:12] by scheduling a task for it on the glib worker thread [14:12] and don't emit another one until the child has finished for the first [14:12] this would probably also implicitly rate-limit the case of 2000-criticals-on-start [14:13] it makes me a bit nervous to do all of this work from the critical handler (since something is probably wrong if we're at that point) but as long as we fork() off the crashing image _before_ we do this fancy stuff, we won't risk contaminating the trace [14:14] desrt: err, but you are going to get the child's core, not the uncontaminated parent's [14:14] correct. [14:15] i think we have a misunderstanding [14:15] i'm doing the comtaminating work in the parent [14:15] in order to keep track of when it's 'safe' to launch another child [14:15] oh, right, sorry [14:15] yes [14:16] okay. sounds good [14:16] thanks for the infos [14:16] * desrt will probably have a patch for this today [14:16] it's actually pretty easy [14:16] desrt, You took out all the hard stuff by making apport do the stack trace ;-) [14:17] tedg: that was my plan all along [14:17] apport will be able to get a better stacktrace than we could ever get by introspecting ourselves [14:17] and it'll be able to retrace it as well [14:20] desrt: can we prefix the assertion message in some way? [14:21] tjaalton: Looks like your wayland sync isn't quite right [14:21] desrt: I'm thinking, with a glib assert msg and SIGABRT apport will usually treat it as a normal assertion violation and file it as a crash [14:21] file conflict :-) [14:21] * Laney fixes [14:21] desrt: so we need some way to tell these apart, perhaps with a string prefix (or does it already start with *-CRITICAL?) or perhaps we use a different signal [14:21] Laney: oh? [14:22] tjaalton: Check the version on the Conflicts/Replaces and what we had in Ubuntu before [14:22] ahh.. [14:23] pitti: Did packagekit get rolled back alright? (i.e. can I remove that block?) [14:23] Laney: yes, it was [14:23] Laney: it was rather easy in the end, three removals and one rebuild [14:24] excellent [14:24] didn't think it would be too hard [14:24] proposed makes doing that kind of thing more feasible [14:24] OMGyes [14:24] I'm so happy we have this thing [14:24] (in a multitude of ways) [14:25] putting something in between dput, "ohsh**", and "why did that FTBFS not happen in my sbuild" :) [14:25] pitti: so you're going to have g_messages_fork_critical() in the backtrace [14:25] desrt: ah, good 'nuff [14:26] well [14:26] provided that the machine has glib debug symbols [14:26] so maybe not [14:26] pitti: explain this other variable to me [14:26] __glib_assert_msg [14:26] desrt: that is _the_ variable, what's the other one? [14:26] what is that and how do you get access to it if there are no debug symbols? [14:27] desrt: oh, see commit 3658727c; perhaps you saw __abort_msg [14:27] right. interesting. [14:27] but it's not marked as exported [14:27] so... how does that work? [14:28] desrt: well, you can only set it from inside glib [14:28] pitti: i mean, how does apport find it? [14:28] call gdb with 'print __glib_assert_msg' [14:28] and that works with no debug symbols? [14:28] this confuses me because it's not on the dlsym table either [14:28] so i don't know how it would find it... [14:29] hm, good question; the retracer will of course figure it out, but maybe not the initial apport run on the client side, indeed [14:29] ahhh [14:29] ah, I wasn't actually aware of that -- apport's autopkgtest has a dependency on glib-dbg [14:29] right.. so good enough for the retracer [14:29] I guess for that very reason [14:30] so that means that you can't tell the difference at bug-filing time [14:30] that makes it kinda impossible for client-side duplicate detection, but at least we can do it on the server side [14:30] i. e. all that we see on the client is a SIGABRT and a core [14:30] we could also distropatch glib to export this symbol on the .so in ubuntu [14:30] or maybe even discuss doing that upstream [14:30] or install glib's -dbg by default (but not sure how well taht would go) [14:31] pitti: did you see this minidebug stuff? === m_conley_away is now known as m_conley [14:31] desrt: minidump? yes, a few years ago at least [14:31] no. minidebuginfo [14:31] http://fedoraproject.org/wiki/Features/MiniDebugInfo [14:31] it's this neat idea that alex had [14:31] no, I haven't seen that [14:31] turns out that you can include some basic debug info (symbols only) in the default install for a very very small size cost [14:32] like +0.5% [14:33] i think we should seriously consider doing this [14:34] at least for libc and glib that sounds interesting indeed [14:34] as these will appear pretty much everywhere [14:34] and qt [14:34] for those, i'd include even more data [14:34] i think maybe this doesn't impact us as much as it does fedora because we have a good retracer [14:34] but it would definitely improve our ability to do client-side matching [14:35] desrt: ^ perhaps not even that [14:35] we still have the address signature [14:35] which usually works well enough for the client-side [14:35] pitti: well... for __glib_assert_msg, for example :) [14:35] even though it's a "magic" abort, it's still an abort on a specific place in the code [14:35] so client-side dupling on SAS should still work [14:36] yeah, we cannot figure out the contents of the message on the client side, but we can tell that we know about it in errors/LP [14:36] and the retracers figure out the rest [14:36] fair enough [14:36] but you still have the problem that you want to know the difference between a real crash and a critical on the client side, right? [14:37] SAS is not an one-to-one mapping of course, as the addresses are different between architectures and builds, but the other day I did an analysis [14:37] and it turned out that the vast majority of crashes only have 3 to 5 SASes, with the topmost having 20 or so [14:37] desrt: right, that would be good, to know what to show to the user [14:37] SaS = stacktrace as-a service? :) [14:37] StacktraceAddressSignature [14:38] pitti: i guess you have some magic in there to derandomise the addresses based on the base address of the library [14:38] desrt: yes [14:38] like you match on libglib-2.0.so+0x2342 [14:39] pitti: anyway... how would you like to find out about the nature of the crash? [14:39] i could SIGTRAP instead of SIGABRT [14:40] a different symbol would definitively help [14:40] afaik, sigtrap is still fatal and core-producing by default [14:40] or something in /proc [14:40] pitti: but we're back to the same problem about symbol visibility... [14:41] $ sh -c 'kill -TRAP $$' [14:41] yep, apport coming up [14:41] desrt: hm, if you set an environment variable that doesn't reflect in /proc/self/environ AFAIR, right? [14:41] i don't think so [14:41] and i don't want to manipulate the environment [14:42] this is _definitely_ not signal-handler-safe [14:42] i could open a file and that would show in /proc/self/fds/ [14:42] but this is getting gross [14:42] hah [14:42] creat("/tmp/not-a-real-crash-kthx"); [14:43] * pitti looks in /proc/self whether there's something else fungible [14:44] #if (defined (__i386__) || defined (__x86_64__)) && defined (__GNUC__) && __GNUC__ >= 2 [14:44] # define G_BREAKPOINT() G_STMT_START{ __asm__ __volatile__ ("int $03"); }G_STMT_END [14:44] i like this. [14:44] #else /* !__i386__ && !__alpha__ */ [14:44] # define G_BREAKPOINT() G_STMT_START{ raise (SIGTRAP); }G_STMT_END [14:45] i consider that this is going to be ?@#$ annoying if you try to run under a debugger.... [14:45] https://bugs.launchpad.net/bugs/+bugs?field.searchtext=SIGTRAP [14:46] wow, we actually have exactly one crash report with TRAP [14:46] no, two [14:46] the compiz ones? [14:46] and bug 178959 [14:46] Launchpad bug 178959 in GtkHTML "evolution crashed with SIGTRAP (assertion failed)" [Critical,Confirmed] https://launchpad.net/bugs/178959 [14:46] (aaancient) [14:47] wtf [14:47] why would there be sigtrap in g_logv? [14:47] oh, that's not an apport report [14:48] let's consider this a human typo in the description [14:48]