=== Aww is now known as Gingersnap
=== Gingersnap is now known as Aww
=== thumper-afk is now known as thumper
NEWTOUBUNTUINEEDi 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 LIVE00:54
NEWTOUBUNTUINEEDdo i choose the UBUNTU 12.04 LIVE00:56
NEWTOUBUNTUINEEDi trying to boot and install it from THE USB STICK and not a DVD CD00:58
NEWTOUBUNTUINEEDcan somone hep me please00:59
=== 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
pittigood morning04:37
didrockswith the latest MIR acked, I think it's time to get unity 7 and touch to saucy!04:48
didrocksurgh, who relaunched the indicators /o\04:49
didrockssomeone redeployed it :/04:50
didrockssession restart05:06
* didrocks grumbles about the commit and rebuild from adding upstart session to unity05:12
didrocks"no best time than 12 hour before releasing and asking for a rebuild"05:12
didrocksok, there is for an hour of test running, better to do my exercice meanwhile :)05:27
m4n1shdidrocks: can saucy be updated to latest zeitgeist version 0.9.14?06:03
m4n1shsorry, I meant 0.9.1306:11
didrocksm4n1sh: not today, but you can ask for sponsoring :)06:27
didrocksjibel: I can't have the tests running anymore, not sure if it's a real regression or something else06:28
* didrocks recreates a container due to the kernel upgrade, just in case with dkms…06:38
didrocksit seems to be latest ted's change06:39
m4n1shdidrocks: 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 side06:39
didrocksm4n1sh: if you can propose a package for sponsoring, that would be awesome :)06:40
maxiaojunWhat's the future plan of Ubuntu's CJKV inputting stack?06:41
m4n1shdidrocks: it isn't in debian as I can see. will propose for sponsorship06:42
didrocksm4n1sh: thanks06:42
didrocksmaxiaojun: more a question for #ubuntu-unity I guess06:43
maxiaojundidrocks: thanks06:43
jibelhey didrocks , which tests ?06:47
didrocksjibel: 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 build06:48
didrocksjibel: I just reverted it and relaunched an unity bulid06:48
jibeldidrocks, unity died during the tests?06:49
didrocksjibel: I think it's the panel service06:49
didrocksand then, it's making unity dying06:49
didrocksjibel: 4 runs, reproduceable reliably06:50
didrocksjibel: tedg migrated the panel service to upstart06:50
didrocksand removed the .service file06:50
didrocksI'm sure there is something with the service not responding and unity goes to a bad trip :p06:50
jibeldidrocks, i'll restart the machine to make sure the env is clean, and restart indicators06:51
didrocksjibel: I did that06:51
didrocksjibel: and even reprovisionned after that06:51
didrocksjibel: so, let's see with the new unity06:51
didrocksjibel: I'm stopping the current check06:52
didrocksas soon as i386 is published06:52
didrocksI'll rerun the indicators06:52
didrockswith whole ppa06:52
didrocks(as the tests are quicker than unity)06:52
jibeldidrocks, we can increase the memory allocation, this box has 8G but that'd just push the wall further06:52
didrocksjibel: doesn't seem to be linked to memory though06:52
didrocksjibel: when it was stuck, we only had 400MB taken06:53
didrocksand no swap06:53
jibeldidrocks, right, after dropping the caches there's only 109MB used :/06:54
didrocksjibel: let's see and cross fingers that the upstart change is the guilty one06:54
jibeldidrocks, did you watch on the KVM the state of the screen?06:55
didrocksjibel: no, I just relyied on logs, I need to setup KVM here I guess06:56
Laneyhey there07:59
Laneyf r i d a y !07:59
* hyperair feels fairly caffeine-deprived08:00
pittimerci dieu c'est vendredi08:00
pittiZum Glück ist Freitag!08:00
pittiso what will we flame about today?08:00
czajkowskipitti: pick a default and change your mind and discuss :)08:01
didrockspitti: don't tempt me :)08:12
* czajkowski tempts didrocks with some cake 08:12
didrocksahah ;)08:12
Laneywe can't flame without seb128 anyway :P08:13
czajkowskiwe've done the default language should be french and people didn't see the joke there08:14
didrocksthey really took it seriously08:14
jibelah, was it a joke?08:14
didrocksthat was hilarious :)08:14
czajkowskididrocks: oh yes indeed so many threads were started with OMG...08:15
czajkowskiamusing really08:15
seb128hey didrocks Laney pitti czajkowski, happy friday!08:15
pittiseb128: bonjour seb128, bon vendredi !08:15
czajkowskiwhooo Friday \o/08:15
* Laney gets down08:15
didrockshey seb12808:15
pittiseb128: tbird sucks! let's get evo back in08:15
* czajkowski hands pitti some soap to wash his mouth out :)08:16
pittiI'm really missing my appointments in the indicator08:16
czajkowskipretty thunderbird is pretty08:16
pittiyeah, well, I guess it's still too early, I'm not really in flamebait mood yet08:16
* pitti pats his mutt08:16
czajkowskipine ftw!08:17
seb128pitti, appointements in the indicator work ... did you try to install evo to see if that makes it work for you?08:17
pittiwohoo, getting serious now :)08:18
* pitti installs evo08:18
Mirvdidrocks: 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:18
didrocksMirv: can we handle that on Monday? TBH, completely spawn with saucy ;)08:19
didrocksMirv: but yeah, if you have cases with only empty changelog, would be interesting to have the test case exactly08:19
pittiseb128: so I installed evolution (killed ~/.config/evolution, .cache, .local etc. before); I see my gcal stuff there08:20
pitti$ killall indicator-datetime-service08:20
LaneyMy manually added calendar still works but the UOA one is busted of course08:20
Mirvdidrocks: yes, let's continue then, to check eg. if those were already fixed or could still happen08:20
pittinow I indeed see the appointments in the indicator08:20
didrocksMirv: right :)08:20
pittiseb128: I killed evo and evo-alarm-notify, appointments in indicator still work08:21
pittiso indeed, installing evolution does some magic to make that work08:21
seb128pitti, well, to me the issue was that calendar needs credentials08:25
seb128but the indicator doesn't have an UI to ask for your password08:25
seb128so auth would just fail08:25
pittihm, but UOA already knows the account08:25
seb128but that was before the online account integration time08:26
pittiempathy and gnome-documents just work then08:26
seb128seems like buggy still08:26
=== vrruiz_ is now known as rvr
czajkowskichrisccoulson: I have your rain and cloud, please come and collect and bring it back up north!10:37
chrisccoulsonczajkowski, it's beautiful sunshine here10:38
czajkowskichrisccoulson: https://twitter.com/Crustyfur/status/34293538429822566410:38
czajkowskiI'm right under that flippin' cloud!10:38
chrisccoulsonhah :)10:38
chrisccoulsonczajkowski, is it thundering? i'm only interested in collecting your weather system if it has thunder in it10:39
czajkowskiyes we've had thunder10:39
czajkowskiit scared the hens10:39
czajkowskithey were very much unimpressed10:39
chrisccoulsonfeel free to send that up to the midlands ;)10:39
czajkowskithe hens or the weather :)10:40
chrisccoulsonczajkowski, just the bits of the weather that are thundering :)10:40
mhr3seb128, 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
seb128mhr3, that seems like a recipe for troubles10:56
mhr3orly? :)10:56
seb128mhr3, you are likely up for symbol clash10:56
seb128mhr3, don't do that :p10:57
mhr3it's being done as we speak10:57
seb128mhr3, where did you find gee-1.0?10:58
ricotzmhr3, hi, yeah, that won't work10:58
ricotzseb128, hi10:58
seb128ricotz, hey10:59
mhr3seb128, libgee2 vs libgee0.810:59
seb128mhr3, ah, 0.6 and 0.8 then10:59
mhr3seb128, yea, 0.6 has gee-1.0 as pc name10:59
ricotzmhr3, the whole runtime stack needs to use the same gee10:59
mhr3:/ let's prepare for some weird gee crashes then11:00
seb128mhr3, what is having the issue? empathy?11:00
mhr3seb128, anything that will use folks + libunity on S11:01
mhr3so yes, empathy comes to mind first11:01
mhr3unless they dropped libunity stuff11:01
seb128mhr3, any plan to port libunity to gee 0.8 or 0.10? ,-)11:02
mhr3if it becomes a real problem for us...11:02
mhr3the two gees are largely compatible so it might be a simple thing of s/gee-1.0/gee-0.8/11:03
seb128we should maybe directly go for 0.1011:03
mhr3or we could remove any gee stuff from libunity and just use glib containers11:04
mhr3you can do everything with list array and hashtable, no? :)11:04
ricotzseb128, 0.10 doesnt change api and is 0.811:04
seb128ricotz, ok11:04
maxiaojunCan someone review the patch attached to this bug? https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/92083411:11
ubot2`Ubuntu bug 920834 in ibus (Ubuntu) "ibus cannot show icon in panel without appindicator" [Low,Confirmed]11:11
maxiaojunCan someone review the patch attached to this bug? https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/92083411:19
ubot2`Ubuntu bug 920834 in ibus (Ubuntu) "ibus cannot show icon in panel without appindicator" [Low,Confirmed]11:19
=== 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
jbichaseb128: could you rebuild gtk3 for the wayland transition?12:31
=== MacSlow|lunch is now known as MacSlow
seb128jbicha, yes, I've an upload planned anyway12:32
seb128does it rebuild without change?12:32
jbichaI haven't tried yet but it's breaking my attempts to build against -proposed12:34
seb128can you try?12:42
davmor2hey 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:58
seb128davmor2, hey, what sort of errors?12:59
davmor2seb128: 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 basically13:00
seb128well, if you find error in .desktop shipped by packages sure open bugs13:01
davmor2seb128: 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:02
davmor2seb128: that's great then thanks for your time :)13:08
jbichaseb128: yes, the GTK3 desktop branch builds ok13:15
seb128jbicha, great, thanks for confirming13:15
=== hggdh_ is now known as hggdh
=== davidcalle_ is now known as davidcalle
xnoxseb128: Laney: are you two implementing system settings designs for touch as per mpt's designs?13:51
Laneyxnox: that's the idea13:52
seb128xnox, not only us but yes13:53
seb128xnox, see https://blueprints.launchpad.net/ubuntu/+spec/client-s-system-settings-panels13:53
xnoxLaney: 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:53
xnoxwhich all well, call into system settings to implement those.13:54
xnoxI also wonder if any design can be shared between the two, or at least the backend logic.13:54
seb128xnox, system settings doesn't provide APIs in the current design13:54
seb128we should yes13:54
seb128those seems like dbus calls13:54
seb128we should do a qt plugin to share13:54
xnoxseb128: hmmm.... ok.13:54
seb128or maybe a settings-backend13:54
xnoxseb128: 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:55
Laneythe idea of the settings stuff is to make reusable widgets as much as possible13:56
desrtpitti: hey.  tedg and i wanted to talk to you yesterday13:56
desrtpitti: we want to make apport collect a stacktrace and file a bug whenever a program hits a g_critical()13:57
pittihey desrt13:57
tedgseb128, 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
desrtpitti: we have a few ideas for ways to do this but your input is very appreciated13:57
desrtpitti: one of the most obvious ways is to do «if (fork()==0)abort();» on each critical13:58
desrtso apport will see the spawned child crashing and record its stacktrace13:58
desrt(which will be the same as the parent that reached the critical)13:58
pittiah, that should actually work13:58
pittieasier than calling apport in glib13:58
seb128tedg, 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 packages13:58
desrtpitti: so the one problem with this is that we lose the other threads13:58
pittidesrt: however, please don't just call abort()13:58
pittidesrt: it would be good if we could salvage the actual message, otherwise the reports will be mostly useless13:59
desrtpitti: which i guess isn't _too_ important13:59
pittidesrt: 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 signature13:59
desrtsounds good13:59
desrtpitti: so another question: you know we have these cases where you start a program and get like 2000 criticals all at once14:00
desrthow is apport/lp going to like that?14:00
pittiapport has a rate limit14:00
desrtdoes it do deduping before filing bugs?14:00
pittiyou can only have one unseen report per user and program14:00
desrtoh.  neat.14:00
tedgpitti, Actually ev is looking at fixing that.14:01
pittiand after you saw the report (i. e. in the apport popup), you can only have three reports per program and user and day14:01
pittitedg: fixing what?14:01
desrtpitti: perfect14:01
tedgpitti, Making it per signature14:01
pittiurgh, no!14:01
desrtpitti: what is the absolute best way for me to crash the program in the fork?  abort() after setting that variable?14:02
pittidesrt: so at least for now we'd get them trickle in, instead of one huge blast14:02
pittiwhich is probably good, since often one has followup criticals14:02
desrtindeed -- and you always want the first one14:03
desrtalthough that is an interesting point....14:03
pittidesrt: abort() sounds nice, SIGABRT is more appropriate to this than a SIGSEGV or so14:03
Guest52607you guys do know that some of our programs spew a lot of criticals, right?14:03
desrtthere is a possible race here if you fork() off a bunch of things all at once in response to a set of criticals14:03
=== Guest52607 is now known as larsu
desrtthe second fork() may get to the abort() first14:03
pittidesrt: 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 fatal14:04
* desrt wonders if abort() is signal-handler-safe14:04
pittidesrt: fork() and wait() ?14:04
desrtpitti: interesting.14:04
pittidesrt: I don't think you want to write a massive number of core files in parallel anyway, so serialization sounds safer to me14:04
desrtpitti: we already have an established convention that if (fork()) { wait() } else { exit() } is non-blocking14:05
pittidesrt: at least we should start small14:05
desrtsince g_spawn_async_with_pipes() does exactly this14:05
danwestBug 1173818: "Unable to set solid colors and gradients as desktop background" - anyone know a workaround or status on this bug?14:05
ubot2`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/117381814:05
desrt(it creates an intermediate helper process and waits for it to quit in order to know if the exec() was successful)14:05
desrtalso so it can preemtively reap...14:06
desrtpitti: another option is that we only fork/abort the first time14:06
desrti like your wait idea, though14:06
pittidesrt: just thinking aloud, could the child set the fatal flag, and just call g_critical() again, with the same message?14:06
desrtpitti: definitely not14:06
pittidesrt: that would avoid copying the assert msg logic14:06
pittiah, it woudl duplicate teh screen output14:07
desrtpitti: after fork() in a threaded program you are in a dangerous spot14:07
desrtwhen you fork() only the thread that made the syscall is brought into the new process image14:07
desrtand the other threads may have been holding locks14:07
desrtso you can't do anything that may try to acquire a lock14:07
* ogra reads didrocks mail and wonders who cares about unity7 .... we want unity8 !14:07
desrtie: you should limit yourself to syscalls and libc "signal-handler-safe" functions14:07
didrocksogra: don't tell that I spent all those crazy hours for nothing :p14:08
didrocksogra: but but, you have touch as well!14:08
ograyou mean unity8 ?14:08
pittidesrt: right; so poke the message into __glib_assert_msg and abort(), and the parent wait()s, that sounds feasible to me14:08
desrtpitti: great14:08
desrttedg: 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
desrti'm happy to do it as well, though14:09
pittidesrt: NB that each critical will incur a significant delay, though14:09
pittias writing and compressing the core dump takes a while14:09
desrtpitti: and the parent doesn't get SIGCHLD until that is done?14:09
pittidesrt: apport fortunately already has this new class "RecoverableError" which we can use for this (as it's not really a crash)14:10
desrtpitti: ya... this is what ted was originally using14:10
pittidesrt: no, the child needs to hang in limbo until the kernel finished coredumping it14:10
desrtand spawning apport directly to report it14:10
desrtbut it lacked a proper trace14:10
desrtso we're trying to figure out how to get that14:10
desrtpitti: hmmmmmm14:11
pittiwe are going to get looots of those, though :)14:11
tedgSo in my original patch I turned it on with an env var.14:11
tedgBasically so that we could ramp up slowly14:11
desrti think that's a fairly reasonable idea14:11
pittiso maybe at first we should limit it to some packages, or never send these to LP, but only to errors14:11
desrtG_DEBUG=fork-criticals or so14:11
pitti^ indeed14:12
pittiit's bad to decide it in apport, as at this point the overhead has already happened14:12
tedgdesrt, 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
desrtso another interesting idea may be to do an async wait for the child14:12
desrtby scheduling a task for it on the glib worker thread14:12
desrtand don't emit another one until the child has finished for the first14:12
desrtthis would probably also implicitly rate-limit the case of 2000-criticals-on-start14:12
desrtit 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 trace14:13
pittidesrt: err, but you are going to get the child's core, not the uncontaminated parent's14:14
desrti think we have a misunderstanding14:15
desrti'm doing the comtaminating work in the parent14:15
desrtin order to keep track of when it's 'safe' to launch another child14:15
pittioh, right, sorry14:15
desrtokay.  sounds good14:16
desrtthanks for the infos14:16
* desrt will probably have a patch for this today14:16
desrtit's actually pretty easy14:16
tedgdesrt, You took out all the hard stuff by making apport do the stack trace ;-)14:16
desrttedg: that was my plan all along14:17
desrtapport will be able to get a better stacktrace than we could ever get by introspecting ourselves14:17
desrtand it'll be able to retrace it as well14:17
pittidesrt: can we prefix the assertion message in some way?14:20
Laneytjaalton: Looks like your wayland sync isn't quite right14:21
pittidesrt: 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 crash14:21
Laneyfile conflict :-)14:21
* Laney fixes14:21
pittidesrt: 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 signal14:21
tjaaltonLaney: oh?14:21
Laneytjaalton: Check the version on the Conflicts/Replaces and what we had in Ubuntu before14:22
Laneypitti: Did packagekit get rolled back alright? (i.e. can I remove that block?)14:23
pittiLaney: yes, it was14:23
pittiLaney: it was rather easy in the end, three removals and one rebuild14:23
Laneydidn't think it would be too hard14:24
Laneyproposed makes doing that kind of thing more feasible14:24
pittiI'm so happy we have this thing14:24
pitti(in a multitude of ways)14:24
pittiputting something in between dput, "ohsh**", and "why did that FTBFS not happen in my sbuild" :)14:25
desrtpitti: so you're going to have g_messages_fork_critical() in the backtrace14:25
pittidesrt: ah, good 'nuff14:25
pittiprovided that the machine has glib debug symbols14:26
pittiso maybe not14:26
desrtpitti: explain this other variable to me14:26
pittidesrt: that is _the_ variable, what's the other one?14:26
desrtwhat is that and how do you get access to it if there are no debug symbols?14:26
pittidesrt: oh, see commit 3658727c; perhaps you saw __abort_msg14:27
desrtright.  interesting.14:27
desrtbut it's not marked as exported14:27
desrtso... how does that work?14:27
pittidesrt: well, you can only set it from inside glib14:28
desrtpitti: i mean, how does apport find it?14:28
pitticall gdb with 'print __glib_assert_msg'14:28
desrtand that works with no debug symbols?14:28
desrtthis confuses me because it's not on the dlsym table either14:28
desrtso i don't know how it would find it...14:28
pittihm, good question; the retracer will of course figure it out, but maybe not the initial apport run on the client side, indeed14:29
pittiah, I wasn't actually aware of that -- apport's autopkgtest has a dependency on glib-dbg14:29
desrtright.. so good enough for the retracer14:29
pittiI guess for that very reason14:29
desrtso that means that you can't tell the difference at bug-filing time14:30
pittithat makes it kinda impossible for client-side duplicate detection, but at least we can do it on the server side14:30
pittii. e. all that we see on the client is a SIGABRT and a core14:30
desrtwe could also distropatch glib to export this symbol on the .so in ubuntu14:30
desrtor maybe even discuss doing that upstream14:30
pittior install glib's -dbg by default (but not sure how well taht would go)14:30
desrtpitti: did you see this minidebug stuff?14:31
=== m_conley_away is now known as m_conley
pittidesrt: minidump? yes, a few years ago at least14:31
desrtno.  minidebuginfo14:31
desrtit's this neat idea that alex had14:31
pittino, I haven't seen that14:31
desrtturns out that you can include some basic debug info (symbols only) in the default install for a very very small size cost14:31
desrtlike +0.5%14:32
desrti think we should seriously consider doing this14:33
pittiat least for libc and glib that sounds interesting indeed14:34
pittias these will appear pretty much everywhere14:34
pittiand qt14:34
desrtfor those, i'd include even more data14:34
desrti think maybe this doesn't impact us as much as it does fedora because we have a good retracer14:34
desrtbut it would definitely improve our ability to do client-side matching14:34
pittidesrt: ^ perhaps not even that14:35
pittiwe still have the address signature14:35
pittiwhich usually works well enough for the client-side14:35
desrtpitti: well... for __glib_assert_msg, for example :)14:35
pittieven though it's a "magic" abort, it's still an abort on a specific place in the code14:35
pittiso client-side dupling on SAS should still work14:35
pittiyeah, we cannot figure out the contents of the message on the client side, but we can tell that we know about it in errors/LP14:36
pittiand the retracers figure out the rest14:36
desrtfair enough14:36
desrtbut 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:36
pittiSAS 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 analysis14:37
pittiand it turned out that the vast majority of crashes only have 3 to 5 SASes, with the topmost having 20 or so14:37
pittidesrt: right, that would be good, to know what to show to the user14:37
desrtSaS = stacktrace as-a service? :)14:37
desrtpitti: i guess you have some magic in there to derandomise the addresses based on the base address of the library14:38
pittidesrt: yes14:38
desrtlike you match on libglib-2.0.so+0x234214:38
desrtpitti: anyway... how would you like to find out about the nature of the crash?14:39
desrti could SIGTRAP instead of SIGABRT14:39
pittia different symbol would definitively help14:40
desrtafaik, sigtrap is still fatal and core-producing by default14:40
pittior something in /proc14:40
desrtpitti: but we're back to the same problem about symbol visibility...14:40
pitti$ sh -c 'kill -TRAP $$'14:41
pittiyep, apport coming up14:41
pittidesrt: hm, if you set an environment variable that doesn't reflect in /proc/self/environ AFAIR, right?14:41
desrti don't think so14:41
desrtand i don't want to manipulate the environment14:41
desrtthis is _definitely_ not signal-handler-safe14:42
desrti could open a file and that would show in /proc/self/fds/14:42
desrtbut this is getting gross14:42
* pitti looks in /proc/self whether there's something else fungible14:43
desrt#if (defined (__i386__) || defined (__x86_64__)) && defined (__GNUC__) && __GNUC__ >= 214:44
desrt#  define G_BREAKPOINT()        G_STMT_START{ __asm__ __volatile__ ("int $03"); }G_STMT_END14:44
desrti like this.14:44
desrt#else   /* !__i386__ && !__alpha__ */14:44
desrt#  define G_BREAKPOINT()        G_STMT_START{ raise (SIGTRAP); }G_STMT_END14:44
desrti consider that this is going to be ?@#$ annoying if you try to run under a debugger....14:45
pittiwow, we actually have exactly one crash report with TRAP14:46
pittino, two14:46
desrtthe compiz ones?14:46
pittiand bug 17895914:46
ubot2`Launchpad bug 178959 in GtkHTML "evolution crashed with SIGTRAP (assertion failed)" [Critical,Confirmed] https://launchpad.net/bugs/17895914:46
pitti (aaancient)14:46
desrtwhy would there be sigtrap in g_logv?14:47
pittioh, that's not an apport report14:47
pittilet's consider this a human typo in the description14:48
desrtsignal 5 (SIGTRAP)14:48
desrtthat's one hell of a typo :)14:48
pittiand the compiz one is signal 514:48
desrt5 is trap14:48
pittidesrt: no, I mean the gtkhtml crash14:48
desrt6 is abrt14:48
desrtmy question stands14:48
desrthow the heck do we get signal 5 here?14:48
pittiright; no idea14:48
desrtso the code has14:49
desrtif (!(test_level & G_LOG_FLAG_RECURSION)) G_BREAKPOINT ();14:49
desrtie: compiz probably installs a custom log message handler that, itself, is causing criticals to be emitted14:49
desrtno wait.  that's backwaqrds.14:50
Laneytjaalton: ok, uploaded that wayland fix. It's probably something we need to carry for a while unfortunately.14:50
pittidesrt: so, one in a million sounds like an acceptable false positive rate for determining that's a "recoverable error", but of course it's still a hack14:50
desrtpitti: anything we do is a hack short of defining some new symbol that the debugger will definitely see14:51
pittihm, I guess we shouldn't set errno, that might be interesting in some cases14:51
tjaaltonLaney: yeah.. thanks14:51
pittidesrt: yeah, I agree; if we want to see it without debug symbols we need to export it properly, right? or add a public function to return __glib_assert_msg14:51
pittiin which case we can just as well have a __glib_critical_msg and a function for that14:52
pittito avoid the string/stack trace heuristics14:52
desrti'd prefer variables to functions14:52
desrtand export them, but not put them in any header14:52
pittivariables are writable outside, though14:52
pittior that, yes14:53
pittiso gdb can see them, but not C code14:53
desrtif someone wants to do something very evil from C, of course they could14:53
desrtbut... srsly?14:53
pittiwell, there is very little that you can't do from C :)14:53
desrt(although i shouldn't speak... glib was doing the same evil thing to lib until your patch)14:53
desrt*to libc14:54
pittiso, a new exported variable sounds like a clean solution to me; opening fds, defining a new signal number (424242) or messing in /proc/ all seem like gross hacks to me14:55
desrtokay.  i'll do that, then14:55
desrti also need to figure out how we will handle being run under gdb in the future when we want this feature on-by-default14:56
pittidesrt: how would that be a probleM?14:56
desrtsince fork()ing on a critical under gdb is .... not helpful14:56
pittioh, right14:56
desrtmaybe we can detect gdb somehow14:56
desrtwe already have code to detect valgrind14:56
pittiI was going to say, gdb intercepts the signals, but I forgot about the fork14:56
pittidesrt: can you tell whether you are being ptraced?14:57
desrti suppose we could try ptracing ourselves and see if that fails =)14:57
desrtalthough this is going to work very badly on ubuntu14:57
desrtsince upstart does its cgroups-in-userspace by using ptrace to watch the fork() calls that the processes that it spawns are doing14:58
desrtso we may mistakenly conclude that we are under a debugger when we're not14:58
pittihm, I wonder whether a process under gdb has prctl(PR_GET_DUMPABLE) == false, but I guess not15:01
pitti(as it's already being traced)15:01
desrtgdb can just intercept the signal at the ptrace level15:01
desrtand the process never gets a chance to dump15:01
desrti wonder if upstart has any plans to move to using cgroups...15:01
desrtbecause checking if you're under ptrace is really the best way...15:02
desrtand what upstart is currently doing is a pretty bad hack15:02
pitti(gdb) call prctl(3,0,0,0,0)15:02
pitti$1 = 115:02
pittiyep, so we can't use PR_GET_DUMPABLE15:02
desrtsome discussion on the topic from scott: https://lists.ubuntu.com/archives/upstart-devel/2012-May/001877.html15:03
desrtdoesn't look like it went anywhere, though15:03
desrtalso a blueprint https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations15:03
bcurtiswxhmm, why is my saucy box trying to install wayland ?15:04
bcurtiswxwell actually, it fails to install those15:05
LaneyI bet it's trying to upgrade it15:05
Laneyand don't run with -proposed15:05
Laney(gtk already depended on libwayland in raring)15:06
bcurtiswxLaney, is using -proposed broken right now?15:07
LaneyYou shouldn't ever be using -proposed in the development release15:07
Laneyit's for computers not people15:07
bcurtiswxLaney, interesting that i never knew that. thanks15:08
pitti bcurtiswx: yeah; almost by definition, stuff in -proposed is guaranteed to be broken15:08
Laney(not that anything automatic would have caught that upgrade failure)15:08
pittibecause as soon as it stops being broken, it moves to saucy15:09
Laney(luckily I /am/ running proposed in an lxc container so noticed it)15:09
bcurtiswxwell, hopefully I keep that as my only oops moment for today :P15:11
bcurtiswxi see the changes in unity. but when i left click an icon after clicking my ubuntu icon on top it opens up the info instead of just loading the app15:17
tedgAnyone getting crashes in unity-panel-service?15:18
Laneybcurtiswx: same15:18
Laneyplease report it!15:18
tedgLooking at it now, but I had to rename the binary to make my machine usable.15:18
bcurtiswxok will do15:18
bcurtiswxunity package right?15:18
Laneysounds like a good place to start15:20
sil2100tedg: crashes?15:20
tedgsil2100, Yes15:20
sil2100tedg: we noticed a crash in unity-panel-service when indicator-network was installed15:20
sil2100tedg: but it was a type of crash that 'was breaking the panel infinitely'15:21
tedgHmm, I do have it installed.  perhaps removing it would make it usable for a bit.15:22
bcurtiswxLaney is that called the dash?15:22
bcurtiswxim not up on my official terms (i should be)15:23
tedgsil2100, Cool, that fixed it.  And shows where the error is :-)15:23
Laneybcurtiswx: yeah15:23
sil2100tedg: ;)15:23
sil2100tedg: could you take a look at that?15:23
tedglarsu, What's blocking the new .indicator loading?  I'm not sure fixing the old indicator-ng is worth it with updates in the pipe.15:24
larsutedg: nothing. Didn't it get merged yet?15:25
* larsu checks15:25
larsujenkins complained, and you set it to approve but it didn't autoland15:25
larsuis libindicator not set up for that?15:26
larsuanyway, I'll merge it manually15:26
bcurtiswxLaney, bug #118865615:26
ubot2`Launchpad bug 1188656 in unity (Ubuntu) "Left clicking on Unity dash icons acts the same as right clicking" [Undecided,New] https://launchpad.net/bugs/118865615:26
larsutedg: thanks for the reminder15:26
tedglarsu, Hmm, I thought it was...15:26
tedglarsu, Grab the ido branch as well :-)15:26
larsutedg: that one was merged, no?15:29
tedglarsu, I was meaning call-ido-init in libindicator.15:29
larsutedg: ah, right. Will do!15:29
sil2100cyphermox: ping15:33
Laneybcurtiswx: ty15:34
Laneykeyboard works well btw15:34
bcurtiswxLaney, yw15:34
cyphermoxsil2100: sup15:34
Laneyooh, my git svn clone of glib is getting close to finishing15:34
Laneyonly 2 days later15:34
sil2100cyphermox: hello! I have a question ;)15:34
sil2100cyphermox: siiince, hm, I checked the FAQ and I wanted to re-deploy a stack15:34
cyphermoxsil2100: can you please get to the point?15:35
sil2100cyphermox: but besides using the cu2d-update-stack it is said there to ping some archive admin15:35
cyphermoxoh right15:35
sil2100cyphermox: is that still required?15:35
cyphermoxyeah, if you add a package, you need to ask someone to update some rsync file on lillypilly as far as I know15:35
cyphermoxdidrocks should have been well aware of the details :)15:36
sil2100Yes, he's gone now - since I think I need to redeploy the platform stack, as I need dbus-cpp-dev to get a merge in15:36
sil2100But that stack adds new packages right now15:36
larsutedg: done15:37
sil2100cyphermox: so, should I wait for didrocks for the stack redeployment, or maybe you would be able to help in some way?15:38
cyphermoxI'm not an archive admin ... I can't do it15:38
cyphermoxseb128: ?15:38
tedglarsu, Great, hopefully that'll fix this indicator-network issue.15:39
sil2100On second thought15:39
larsutedg: oops, test suite doesn't pass. I'll have a fix before the daily merge ;)15:39
seb128cyphermox, what do you need?15:39
sil2100I think I'll try getting it in somehow else, since once it's redeployed, it will automatically get auto-released daily15:39
sil2100cyphermox, seb128: so maybe for now let's leave things as they are15:40
cyphermoxseb128: ... sil2100 needs some cu2d stuff fixed up15:40
seb128cyphermox, why do you need and archive admin for that?15:40
cyphermoxsil2100: you shouldn't have to need any of this unless you add a project15:40
cyphermoxseb128: ask didrocks, there is some file that needs to be updated apparently15:40
sil2100cyphermox: there are some projects added, since I see dbus-cpp added and location-service15:40
sil2100seb128: yes, at least the FAQ says so!15:41
sil2100But for now I think I'll stay clear of that15:41
pittibonsoir tout le monde, profiter du week-end !16:06
tedgattente, So I've now got unity-gtk2-module from the repos and xchat-gnome isn't exporting its menus anymore.16:09
tedgattente, Is that known?16:09
attentetedg, not known, looking into it16:11
attentetedg, are you getting the double menu bar problem?16:12
Laneyit's the same gtk2 problem isn't it?16:12
attenteLaney, appears so16:12
Laneyseb just uploaded for that16:12
attenteok, cool, thanks Laney16:13
tedgAh, yes, I didn't check up top when it was in the app.16:15
attentetedg, yeah, sorry about that, that was a known problem after all16:16
Bubblesany way to get medibuntu to work on a fresh reload of lucid?16:23
ograwould probably be clever to ask this in a medibuntu channel somewhere :)16:30
desrtpitti, tedg: https://bugzilla.gnome.org/show_bug.cgi?id=70180016:47
ubot2`Gnome bug 701800 in general "a new approach to reporting critical errors" [Normal,New]16:47
tedgdesrt, Probably should do it on LOG_LEVEL_ERROR as well.16:49
desrttedg: error will always abort16:49
desrtso we don't need to16:49
tedgdesrt, Ah, okay.16:50
bschaeferSarvatt, hey, thanks for pushing new versions up of unity up to that ppa :)16:53
bcurtiswxmhr3, re: bug #1188656, why would people have to one-click the left bar icons to open them but double-click dash icons to open them? What was the rationale for making it double-click now?16:59
ubot2`Launchpad bug 1188656 in unity (Ubuntu) "Left clicking on Unity dash icons acts the same as right clicking" [Undecided,Confirmed] https://launchpad.net/bugs/118865616:59
mhr3bcurtiswx, you're targetting your questions at wrong person17:00
mhr3bcurtiswx, design wanted, so we made it so17:00
bcurtiswxmhr3, interesting. thanks :)17:01
mhr3bcurtiswx, feel free to mail to unity-design :)17:01
bcurtiswxmhr3, would that be better than commenting in the bug?17:02
bschaeferbcurtiswx, hmm left clicking a launcher icon opens it if its not opened, or focuses the last focused window...17:02
bschaefermhr3, o it was a design change?17:03
bcurtiswxim in slight shock, actually, thats a pretty big change IMO17:04
mhr3bschaefer, yep17:05
mhr3anyway, /me out17:05
bschaefermhr3, have a good weekend :)17:05
bcurtiswxgood weekend mhr317:05
bschaeferalso yay for smart scopes :)17:05
=== m_conley is now known as m_conley_away
=== broder_ is now known as broder

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!