[00:19] <RAOF> Whoops, just missed mterry.
[01:57] <jbicha> wow, my terminal crashed in the middle of my build :(
[02:00] <robert_ancell> jbicha, gtk3?
[02:02] <jbicha> robert_ancell: no I was just building gnome-shell
[04:37] <desrt> RAOF: hey!
[04:50] <RAOF> desrt: Yo!
[04:51] <RAOF> Oh, wow.  That router really wanted a reboot.
[04:51] <desrt> RAOF: i just discovered something cool from wikipedia
[04:51] <desrt> RAOF: you're one of the few non-canadians who is likely to understand me when i say "i didn't pay my bill, so they cut off my hydro."
[04:52] <RAOF> :)
[04:52] <RAOF> It's no longer called the hydro in Tassie, though; it got the three-part split a decade ago or so.
[04:53] <desrt> they still use the name here
[04:53] <desrt> even though it's 75% untrue these days
[04:54] <RAOF> What was called the HEC is now Transend, Aurora, and... some other company, which actually owns the dams.
[04:55] <desrt> ah.  like that.
[04:56] <RAOF> Yeah.
[04:56] <desrt> i thought you meant three sources
[04:56] <RAOF> Oh, no.
[04:56] <desrt> like hydro/nuclear/coal
[04:56] <desrt> which is sort of how the situation is in ontario
[04:57] <RAOF> As far as I know, it's still almost all hydro, with a peaking gas plant at Bell Bay, and a connection to the national grid via a submarine cable to Victoria.
[04:57] <RAOF> Which means that there's coal/wind/solar in there, too, but in aggregate :)
[04:57] <desrt> most of canada is hydro
[04:57] <desrt> but ontario has a lot of nuclear
[04:57] <desrt> we're just about done with the coal, fortunately
[04:58] <desrt> but ya... gas as well
[05:02] <pitti> Good morning
[05:02] <desrt> pitti: good morning
[05:07] <RAOF> Hey pitti
[05:24] <didrocks> good morning
[05:25] <pitti> hey didrocks
[05:25] <didrocks> guten morgen pitti, how are you?
[05:25] <pitti> quite fine, thanks! yourself?
[05:26] <didrocks> I'm fine as well ;) grey weather outside, still rainy and it seems it will become worse in the follow hours. All good reasons to stay home :)
[05:33] <BigWhale> Good Morning.
[07:24] <chrisccoulson> good morning everyone
[07:24] <pitti> hey chrisccoulson
[07:25] <chrisccoulson> hi pitti, how are you?
[07:25] <pitti> quite fine, thanks! how are you?
[07:27] <chrisccoulson> pitti - yeah, good thanks
[07:30] <didrocks> hey chrisccoulson!
[07:31] <Sweetshark> moin!
[07:32] <pitti> Sweetshark: oh hai!
[07:34] <didrocks> hi Sweetshark
[07:36] <Sweetshark> pitti, didrocks, seb128: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-precisetest-20120327/+sourcepub/2385065/+listing-archive-extra <- this should fix one bug you nagged me about (didrocks: quicklists, pitti: -kde/-gnome suggests, seb128: visio mime for LibreOffice Draw)
[07:38] <dpm> hey pitti, good morning. You've probably seen it, but the full langpack export finished this morning \o/ have you had a look whether the ubuntu-docs xml translations are there?
[07:38] <dpm> Otherwise I can have a look at it myself
[07:40] <Sweetshark> dpm: oh, you were interested in that too: l10n for quicklists is "fix commited"
[07:40] <pitti> dpm: yes, I saw; I started the build some 15 minutes ago
[07:41] <pitti> dpm: ubutu-docs xml trnaslations are not in teh LP export, langapck-o-matic downloads them directly from LP (see my mail replies to mdke)
[07:41] <pitti> (argh typing!)
[07:42] <dpm> ah, gotcha, good to know, thanks pitti!
[07:42] <pitti> Sweetshark: great, thanks! this should probably become an SRU at this point, given the build times, but as this is going to -proposed anyway, we could still consider moving it into final
[07:42]  * dpm hugs Sweetshark
[07:42] <dpm> that's awesome, thanks for getting this in, that will make non-English users happy!
[07:47] <pitti> micahg: o/
[07:48] <micahg> pitti: so, there's a sendto feature for blueman that we decided to disable as it's breaking nautilus-sendto, the problem is that the flag isn't recognized when passed through DEB_CONFIGURE_EXTRA_FLAGS, it looks like the feature is written improperly in .ac, but I'm not sure offhand how to regenerate configure with CDBS without dh-autoreconf which just seems to do everything twice
[07:49] <micahg> AC_ARG_ENABLE(sendto,
[07:49] <micahg> [  --enable-sendto=[yes/no] Enable nautilus-sendto plugin build],,have_nst=no)
[07:49] <micahg> oops, was originally yes at the end
[07:49] <Sweetshark> pitti: right. I will make that an 3.5.2-2ubuntu2 for proposed.
[07:49] <pitti> micahg: a mere DEB_CONFIGURE_EXTRA_FLAGS = --disable-sendto doesn't work then?
[07:50] <micahg> nope
[07:50] <pitti> micahg: err, --enable-sendto=no
[07:50] <pitti> that's odd
[07:50] <micahg> well, in theory from what I read, both should work, but neither does
[07:51] <pitti> micahg: so, if you patch the configure.ac, including /usr/share/cdbs/1/rules/autoreconf.mk ought to be sufficient
[07:51] <micahg> if I read the docs correctly (which is a big if at this hour), the last option to AC_ARG_ENABLE is the ELSE clause (i.e. no feature)
[07:51] <pitti> and adding dh-autoreconf build dep
[07:51] <micahg> pitti: it includes gnome.mk
[07:51] <pitti> sure, but gnome.mk doesn't include autoreconf
[07:51] <micahg> I tried with dh-autoreconf but not with that and fixing the ELSE clause to no
[07:51]  * micahg tries now
[07:52]  * pitti has a closer look at the autoconf bit
[07:54] <micahg> Nautilus sendto plugin enabled: yes
[07:55] <pitti> argh
[07:55] <pitti> micahg:
[07:55] <pitti> have_nst=yes
[07:55] <pitti> AC_ARG_ENABLE(sendto,
[07:55] <pitti> [  --enable-sendto=[yes/no] Enable nautilus-sendto plugin build],,have_nst=yes)
[07:55] <pitti> micahg: there is nothing that ever sets this to "no" :)
[07:55] <micahg> right, so I changed the final bit to no instead of yes, but I think I just wanted to no in the middle there
[07:56] <pitti> so your patch seems correct
[07:56] <micahg> pitti: it generates as this: http://paste.ubuntu.com/935105/
[07:56] <Sweetshark> hmmmm, "wc -l debian/patches/series == 38" -- some upstreaming checking for q is in order.
[07:56] <micahg> which seems to tell me I did it backwards
[07:58] <micahg> Nautilus sendto plugin enabled: no \o/
[07:58] <micahg> I did do it backwards :)
[08:00] <pitti> ok, I tried something shorter, but that didn't quite work; /me tests teh proper approach
[08:01] <micahg> pitti: I've got the patch now, I just hope it doesn't break something for Xubuntu or Lubuntu now :)
[08:01] <micahg> pitti: thanks
[08:02] <pitti> micahg: http://paste.ubuntu.com/935110/ confirmed to work in all three cases here
[08:02] <pitti> I tried [  --enable-sendto=[yes/no] Enable nautilus-sendto plugin build],have_nst=$enable_val,have_nst=yes)
[08:02] <pitti> but that's not quite correct
[08:02] <pitti> as enable_val is "" for --disable-sendto
[08:03] <micahg> pitti: I did this: http://paste.ubuntu.com/935105/
[08:03] <micahg> oops, that's the old one
[08:03] <micahg> http://paste.ubuntu.com/935111/
[08:03] <seb128> hey
[08:03] <pitti> micahg: does that really work with --enable-sendto ?
[08:03] <pitti> hey seb128
[08:03] <didrocks> salut seb128 :)
[08:03] <didrocks> seb128: happy thursdsay \o/
[08:03] <pitti> seb128: do you happen to have another bug to fix?
[08:03] <seb128> hey pitti didrocks, how are you?
[08:03] <micahg> yes, I have--enable-sendto=no set right now
[08:04] <didrocks> seb128: I'm fine, it's thursday ;)
[08:04] <didrocks> you?
[08:04] <pitti> micahg: I think that would break with --enable-sendto (i. e. not enable it)
[08:04] <seb128> pitti, no bug no, why?
[08:04] <pitti> didrocks: did you move to Australia recently?
[08:04] <pitti> seb128: I have one I'd like to fix, but can't ruin the stats
[08:04] <seb128> didrocks, did you swap friday this week?
[08:04] <seb128> pitti, use proposed? ;-)
[08:05] <pitti> I guess I could do that, yes
[08:05] <didrocks> pitti: just kidding with seb128, as I shifted my easter monday holiday with this friday and when I was the only one here working on friday, he was gladly telling "it's friday for me on thursday" :)
[08:05] <didrocks> so, revenge ;)
[08:05] <didrocks> seb128: yeah!
[08:05] <micahg> pitti: you are correct
[08:05]  * micahg looks at how other flags work
[08:06] <pitti> micahg: http://paste.ubuntu.com/935110/ is the standard approach
[08:06] <pitti> the "else" part is right, it's meant to default to "yes"
[08:06] <pitti> but it fails to consider the value when disabling it
[08:06] <didrocks> ok, in fact, only sudo was dropping all the env for pbuilder, no black magic here :)
[08:07] <seb128> didrocks, ;-)
[08:07] <seb128> pitti, don't bother about the stats anyway, just upload where it's right, we can say that in spirit we tied ;-)
[08:07]  * seb128 hugs pitti
[08:08] <pitti> seb128: nah, I'll use -proposed
[08:08] <pitti> then we can even build apport already, and publication will be faster
[08:10] <Sweetshark> seb128: bug 926940 is fix commited
[08:10] <ubot2> Launchpad bug 926940 in mime-support "Visio files not associated with LibreOffice Draw" [Undecided,Confirmed] https://launchpad.net/bugs/926940
[08:10] <seb128> Sweetshark, hey, thanks!
[08:11] <micahg> pitti: I'm just tempted to default to no and be done with it ;)
[08:11] <pitti> micahg: that's not upstreamable, though; above fix is
[08:11] <pitti> but if you aren't concerned about that, pretty much any hack will do
[08:11] <pitti> micahg: you could even choose to simply not install the extension, i. e. change debian/*.install ?
[08:12] <pitti> that should avoid the autoreconfiscation, too
[08:12] <micahg> there is no .install, but I can rm the files I guess
[08:12] <pitti> ah, single-binary
[08:32]  * micahg files  a bug against blueman for the flag issue
[08:38] <lifeless> micahg: speaking of bluetooth
[08:38] <lifeless> micahg: and I'm being totally opportunistic
[08:38] <lifeless> micahg: why do I have two bluetooth indicators, with different content?
[08:39] <micahg> lifeless: no idea, I don't even use it, I'd suggest speaking to cyphermox
[08:46] <pitti> did you guys see that we have shiny new i386 and amd64 buildds?
[08:46] <pitti> https://launchpad.net/builders
[08:47] <pitti> they are now super-fast
[08:49] <seb128> \o/
[08:50] <pitti> now powerpc sucks even more, relatively speaking :)
[08:50] <pitti> Sweetshark will be happy with his next LibO upload
[08:52] <Sweetshark> hrhr, if i386/amd64 and powerpc/arm grow even further apart, we will run into the uploading while building scenario even more often (not that it didnt happen before).
[08:54] <micahg> well, ~4.5 hrs for i386/amd64
[08:55] <micahg> well, powerpc is still faster than arm*, but the queue for it will be further behind
[09:27] <pitti> didrocks, seb128: do you happen to know about these lightdm-set-defaults additions? http://launchpadlibrarian.net/102448032/lightdm_1.2.0-0ubuntu2_1.2.1-0ubuntu1.diff.gz
[09:27] <pitti> they formally need a FFE
[09:27] <pitti> if not, I'll mail robert
[09:28] <seb128> pitti, it's an utility that can be used to change the config
[09:29] <seb128> pitti, https://code.launchpad.net/~mfisch/lightdm/set-defaults-work/+merge/102196 is the work that landed
[09:29] <didrocks> pitti: they are called by helper in postinst normally
[09:31] <pitti> seb128: yes, I know
[09:31] <pitti> so that wasn't tied to a bug
[09:32] <seb128> pitti, yeah, robert_ancell is usually overlooking processes and paperwork ;-)
[09:34] <pitti> seb128: look at https://launchpad.net/builders :)
[09:40] <seb128> pitti, nice ;-)
[10:30] <seb128> pitti, 04/17/12 11:56:52: retracing #983892 failed with status: -11
[10:30] <seb128> pitti, do you know what status: -11 means?
[10:30] <pitti> argh, that again?
[10:30] <pitti> segfault
[10:30] <pitti> I guess you have a core file now
[10:30] <seb128> hum
[10:30] <pitti> I usually just remove and restart
[10:30] <seb128> there is a "core" in the userdir yes
[10:30] <seb128> pitti, ok
[10:30] <seb128> should I rm the core file as well?
[10:30] <pitti> as you wish
[10:31] <pitti> we'll get a new one soon enough :)
[10:31] <seb128> ok, too late if you wanted it
[10:31] <pitti> oh, and I was _so_ keen on debugging python on lucid now!!!
[10:31] <seb128> ;-)
[10:31] <seb128> 04/18/12 10:31:33: retracing #984064 (left in pool: 216)
[10:31] <seb128> *shrug*
[10:31] <seb128> 216 bugs in the backlog
[10:32] <pitti> in 24 hours, wowo
[10:32] <pitti> s/o$//
[10:33] <seb128> pitti, well I already rmmed a lock file yesterday for a -11 error so maybe it's > a day
[10:33] <seb128> i.e it was maybe not an empty pool when it stopped
[11:04] <seb128> pitti, are the retracers supposed to close the bugs when retracing fail or only if retracing fail && some_other_condition?
[11:04] <pitti> seb128: retrace fail && useless stack trace
[11:04] <pitti> err
[11:04] <pitti> I mean retrace fail (== useless stack trace) and outdated packages
[11:04]  * pitti -> lunch, bbl
[11:04] <seb128> pitti, enjoy
[11:05] <seb128> I tend to be annoyed by "useless stacktrace && !outdated packages" I guess
[11:05] <seb128> i.e corrupted dumps
[11:05] <seb128> they are useless still be kept open
[11:31] <Sweetshark> ricotz: you are on http://planet.documentfoundation.org btw
[11:33] <ricotz> Sweetshark, hey, nice ;)
[11:35] <Sweetshark> ricotz: and on http://voices.canonical.com/ for completeness sake ;)
[11:36] <ricotz> hehe
[11:46] <seb128> Sweetshark, how is the debian,ubuntu relationship going for libreoffice nowadays? is rene still an Ubuntu hater? ;-)
[11:47] <Sweetshark> 13:08  * _rene_ thinks committing unity files upstream is the "something wrong" here
[11:47] <Sweetshark> 13:08 <@_rene_> *hides*
[11:48] <Sweetshark> ^- thats a few minutes ago on libreoffice-dev. Still, I personally can work with _rene_ quite well, although he might still have a lot of reservations against ubuntu.
[11:50] <seb128> that's something at least ;-)
[12:18] <jbicha> good morning
[12:18] <didrocks> hey jbicha
[12:18] <didrocks> how are you?
[12:19] <seb128> jbicha, hey
[12:19] <seb128> jbicha, good job getting the ubuntu-docs update in ;-)
[12:21] <jbicha> seb128: does it work for you in French?
[12:21] <seb128> jbicha, local build worked, I can't tell for the archive until we get new langpacks
[12:49]  * pitti sighs at more crashes in the retracer, restarting
[12:49] <seb128> pitti, thanks
[12:55] <kelemengabor> Sweetshark: hi, thanks for your work on reenabling the LO quicklists, however there is a tiny one liner bug left. could you please take a look at bug #774020?
[12:55] <ubot2> Launchpad bug 774020 in libreoffice "Menu of Draw in zh_TW translation is not included in Natty" [Undecided,New] https://launchpad.net/bugs/774020
[12:56] <kelemengabor> I still see it here: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=patches/ubuntu-quicklists.diff;h=a0fba1d9243b03fe0833341f06348e78de56b1c1;hb=06d44513521f9db4417cd317e8266d8e1069aa2e#l210
[13:07] <Sweetshark> kelemengabor: i see a tranlation for zh_TW in line 265 for draw. What do I misunderstand? *confused*
[13:07] <kklimonda> hmm, is overrides the only way to configure unity-greeter? can't we use /etc/dconf/db ?
[13:09] <kelemengabor> Sweetshark: I have linked line 210 for zn_CN, which should be zh_CN
[13:09] <seb128> kklimonda, nothing block you do use a db, that's a sysadmin stuff usually though
[13:09]  * desrt yawns
[13:09] <seb128> desrt, hey
[13:09] <desrt> hi
[13:09] <seb128> desrt, how are you?
[13:09] <seb128> desrt, not to cold?
[13:09] <desrt> pre-coffee :)
[13:09] <desrt> yourself?
[13:10] <seb128> I'm good thanks
[13:10] <desrt> cold?
[13:10] <seb128> desrt, we are pretty hard frozen by now
[13:10] <seb128> it's cold around :p
[13:10] <desrt> oh :)
[13:10] <desrt> i'm enjoying the cold
[13:10] <desrt> it's a nice lul
[13:10] <seb128> ;-)
[13:10] <desrt> i noticed you assigned more examples of that weird error-case gsettings (possibly threading) issue
[13:10] <kklimonda> seb128: aren't overrides are distro stuff though, being in /usr/share and requiring a call to glib-compie-schemas afair?
[13:11] <kelemengabor> Sweetshark: oh, sorry, I think this is another bug :\
[13:11] <seb128> desrt, yeah, I was unsure if you want to know about them as well, or if you receive emails about bugs you are just subscribed to, or if you want them just opened on bugzilla
[13:11] <seb128> desrt, I decided I would assign them to you just to get your comments, feel free to unassign ;-)
[13:11] <desrt> seb128: i'm really not sure what the issue is in this case
[13:11] <desrt> seb128: nah.  i don't mind having it assigned.  i'm really curious about what the issue is
[13:12] <desrt> just don't expect a fast fix :)
[13:12] <seb128> kklimonda, they are, what are you trying to do?
[13:12] <desrt> do you figure that there's any chance that this is another one of those weird logout issues?
[13:13] <seb128> desrt, oh, they are stoppers in no way, they just seemed to be maybe real bugs so I wanted you to see them in case they are just another yet stupid distro upgrade race issue or something
[13:13] <seb128> desrt, could be yes
[13:13] <desrt> seb128: after poking at it a bit, it's the only explanation i could come up with
[13:14] <kklimonda> seb128: well, I just got a bug email from lightdm about disabling start-up sound (I'm subscribed to a bunch of "new" packages like lightdm/unity-greeter so I can see what's going on with them ;))
[13:14] <seb128> desrt, I hate logout issues, I really want to get a way to see what bugs happen on logout ;-)
[13:14] <kklimonda> seb128: and someone has suggested creating an .override file to do that
[13:14] <desrt> seb128: that would probably not be too difficult
[13:15] <desrt> seb128: i suggest talking to pitti about it :)
[13:16] <desrt> (actually, maybe it is difficult -- it is rather unlikely that logout-time crashes are handled right away so, by the time apport is doing its thing, it's probably no longer logout time)
[13:16] <seb128> kklimonda, just edit the etc config?
[13:16] <seb128> desrt, well then "not current session"
[13:17] <seb128> like compare the report time with the login time or something
[13:17] <desrt> ya.  that would probably work fairly well
[13:17] <desrt> although i guess it could also give some false positives
[13:18] <seb128> we should maybe wipe the reports on login
[13:18] <desrt> well
[13:18] <desrt> this is a bug
[13:18] <desrt> so i'm happy we know about it :)
[13:18] <kklimonda> seb128: ok, I'm a bit confused - why does unity-greeter has etc config and ships with the gsettings schema?
[13:19] <seb128> kklimonda, that option seems to be in gsettings
[13:19] <desrt> kklimonda: the file in /etc is old
[13:19] <desrt> it's no longer used
[13:19] <seb128> kklimonda, what are you trying to do? just a local change for your user? just set the key for in the etc db or for the lightdm user?
[13:19] <desrt> kklimonda: this confused me quite a lot at one point as well
[13:19] <desrt> kklimonda: the settings are actually stored in a normal dconf db in the lightdm homedir
[13:21] <seb128> jbicha, you should probably open a ffe bug where we can have that discussion for the record in any case
[13:22] <kklimonda> seb128: well, the current example is disabling start-up sound that unity-greeter is apparently playing, but I'm trying to wrap my mind around an entire concept :)
[13:23] <Sweetshark> kelemengabor: do you have a bug# for zn_CN
[13:23] <Sweetshark> ?
[13:24] <kelemengabor> Sweetshark: no, I have looked for it, but nothing
[13:24] <kelemengabor> should I file one?
[13:24] <kklimonda> seb128: it doesn't help that a lot of lightdm settings (like disabling user list or enabling "others" login) are not in gsettings, but in the old good .conf file
[13:26] <seb128> kklimonda, lightdm != unity-greeter
[13:28] <alf_> Hi! How is gtk-window-decorator started by unity? With the arm gles2 compiz/unity packages, I need to run it manually to get any decorations and I am trying to figure out what is wrong.
[13:28] <kklimonda> seb128: I know, but they use vastly different configuration mechanisms and I can imagine that at some point in the future sssd will gain an ability to sync dconf/gsettings with LDAP to ease deployments (or someone creates a different solution to this problem), but  we'll be stuck with old good puppet to configure lightdm ;)
[13:28] <alf_> ogra_: ^^
[13:28] <alf_> ogra_: (two lines up)
[13:29] <seb128> alf_, try #ubuntu-unity
[13:29] <Sweetshark> kelemengabor: that would be great
[13:29] <Sweetshark> kelemengabor: bug 774020 can be assumed fixed than?
[13:29] <ubot2> Launchpad bug 774020 in libreoffice "Menu of Draw in zh_TW translation is not included in Natty" [Undecided,New] https://launchpad.net/bugs/774020
[13:30] <ogra_> alf_, i think its related to /x-window-manager
[13:30] <seb128> kklimonda, I would be reluctant to make lightdm use gsettings
[13:30] <kelemengabor> Sweetshark: yes, the Draw file has no zn_TW entry anymore
[13:30] <kklimonda> seb128: it's already linking against the entire glib stack, isn't it?
[13:30] <alf_> seb128: thanks
[13:31] <kklimonda> I guess the argument against it is to make lightdm more desktop-agnostic
[13:31] <seb128> kklimonda, yeah, it's stupid, ignore that, I still hate how non-robust gsettings is against i.e schemas install issues
[13:31] <seb128> like the last thing I want is the login manager to fail starting because it doesn't find a schemas telling if it should play the login sound
[13:32] <kklimonda> *nods* that's a good argument, but isn't it the case already now that unity-greeter is using gsettings?
[13:32] <kklimonda> unless lightdm can work in a fallback mode without unity-greeter?
[13:33] <seb128> which is why I say "it's stupid, ignore that" ;-)
[13:33] <kklimonda> ah, right :)
[13:33] <seb128> well without unity-greeter lightdm would send you in failsafe mode to fix your config
[13:33] <seb128> or should
[13:34] <ogra_> which is funny given that we dont actually *have* a config anymore and xorg should sutodetect the world :)
[13:34] <ogra_> *auto...
[13:34] <kelemengabor> Sweetshark: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/984893
[13:34] <ubot2> Launchpad bug 984893 in libreoffice "Typo in LO Base desktop file: zn_Cn" [Undecided,New]
[13:36] <seb128> ogra_, well you can have a broken config
[13:36] <seb128> ogra_, which means fixing it is basically removing the broken config ;-)
[13:36]  * cyphermox <3 readu
[13:36] <cyphermox> gah
[13:36] <ogra_> seb128, sure, but that usually doesnt refer to xorg itself
[13:36] <seb128> cyphermox, hey, how are you?
[13:36] <cyphermox> hey
[13:36] <cyphermox> not too bad
[13:37] <ogra_> seb128, i.e. if my lightdm config is broken the failsafe doesnt offer me to fix that but it wants to fix xorg
[13:38] <seb128> ogra_, it should offer you that, that was the plan
[13:38] <seb128> ogra_, I guess some workitems didn't get done this cycle
[13:38] <ogra_> yeah, i definitely didnt see such an option in my broken setups
[13:55] <Sweetshark> kelemengabor: fix committed
[13:55] <pitti> seb128: logout crashes> do we still get that many? I was hoping the fix that we put into apport would get rid of many of those
[13:56] <seb128> pitti, the issue is that it's hard to do which ones are logout issues and not
[13:56] <kelemengabor> Sweetshark: thanks!
[13:57] <seb128> pitti, I got one for sure yesterday from an oneiric to precise update, evince exited on missing gschemas key because it was running during the update and schemas changed under it, the user got apport to trigger after the first login into precise after reboot
[13:58] <seb128> pitti, it took some pingpong and look at timestamp to figure the issue happened during the upgrade before reboot, he got the prompt after reboot and login in the updated system
[13:59] <seb128> pitti, what was the hack done in apport again? maybe it doesn't work as it should?
[13:59] <pitti> seb128: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/hookutils.py#L814
[14:00] <pitti> oh, wait
[14:00] <pitti> we only use that to determine whether or not to attach ~/.xsession-errors
[14:01] <pitti> we don't actually prevent them from being sent
[14:01] <pitti> mostly because service processes (plumbing, gvfs, and the like) are not directly attached to the session
[14:03] <seb128> pitti, ok, that makes sense
[14:04] <seb128> pitti, I wish reports would have the "current login time" as well as report['Date']
[14:04] <pitti> I don't think we have found a real solution for "is this happening at logout" yet
[14:04] <seb128> pitti, report['Date'] is the date where the issue happened or when ubuntu-bug was run?
[14:04] <Darxus> I think you folks are likely to be interested in this, apparently the Ubuntu specific modifications to GTK+ are incompatible with Wayland:  https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/984914
[14:04] <ubot2> Launchpad bug 984914 in gtk+3.0 "Ubuntu modifications to GTK+ incompatabile with Wayland" [Undecided,New]
[14:04] <pitti> seb128: the latter
[14:04] <pitti> seb128: we can find out about the former, though, maybe that makes more sense
[14:04] <seb128> Darxus, not for precise
[14:04] <seb128> Darxus, maybe next cycle
[14:05] <pitti> seb128: wait, hang on, I tell rubbish
[14:05] <pitti> seb128: yes, Date is the time the crash  happened, sorry
[14:05] <seb128> pitti, from the evince report I was talking about I had the impression Date was the issue time
[14:05] <seb128> pitti, ok, that matches that specific case I looked at today
[14:05] <seb128> so I would just need the "current login" time
[14:06] <Darxus> seb128: Yeah I know it's not getting enabled in Precise, just seemed like something somebody would want to fix eventually.
[14:06] <seb128> like when running ubuntu-bug, look at ck current login and compare to the report date
[14:06] <pitti> seb128: you mean the time when apport-bug runs?
[14:06] <pitti> seb128: that's precisely what in_session_of_problem() gives you
[14:06] <seb128> pitti, is that somewhere in the report? or is that just used for the .xsession-errors logic?
[14:07] <pitti> seb128: so for desktop apps, you indirectly know by "does this bug have a xsession-errors attachment"
[14:07] <seb128> pitti, I don't see that actual info being printed
[14:07] <pitti> seb128: no, it's not a separate field
[14:07] <seb128> pitti, well, "doesn't have a xsession-errors" can also mean "the xsession-error log had nothing matching the filter regexp"
[14:07] <pitti> seb128: if a bug has an .xsession-errors, then it's not a "crash at logout", barring weird bugs
[14:08] <pitti> seb128: right, that too
[14:08] <seb128> so you are back to be unsure
[14:08] <seb128> pitti, could we just append session_start_time to the infos?
[14:09] <pitti> seb128: would it be enough to have a boolean flag? InSessionOfProblem: Yes
[14:09] <pitti> or so?
[14:09] <pitti> I guess that's what you are actually looking out for, and improves both privacy and also the legibility of reports?
[14:09] <seb128> pitti, concrete example: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/983697
[14:10] <ubot2> Launchpad bug 983697 in evince "evince crashed with signal 5 in g_settings_get_value()" [Low,Invalid]
[14:10] <seb128> pitti, yes, a boolean would work for me
[14:11] <seb128> pitti, and yes, either to have apport to do the timestamp checks and the logic than having to do it manually, even if that's easy maths ;-)
[14:11] <seb128> either->easier
[14:13] <pitti> seb128: so that, or an extra tag, or so
[14:13] <pitti> seb128: how woudl that help in that particular case?
[14:13] <seb128> pitti, I just need the info, I'm not picking about how it's exposed
[14:14] <pitti> seb128: it wasn't the session that was closing?
[14:14] <pitti> seb128: but I actually thought we reject crashes if the binary changes between the crash and the reporting time
[14:14] <pitti> ah, I guess here it crashed when the new binary already was in place, darn
[14:14] <seb128> no we don't
[14:14] <seb128> right
[14:14] <pitti> so we'd need to find out at crash time if the binary is the same as it was when the program started
[14:15] <pitti> i. e. program start time >= mtime(ExecutablePath)
[14:15] <seb128> pitti, good point, that wouldn't give me the exact info I need, but at least I could see "none of the dup happened in the current session"
[14:15] <seb128> pitti, which is a good clue it might be a logout issue
[14:15] <pitti> program start time shoudl be somewhere in /proc, hang on
[14:16] <pitti> ah, I could use the time of the /proc/pid/exe symlink
[14:16] <pitti> and compare that to the mtime of the executable path
[14:16] <seb128> pitti, that's another issue but a frequent one, in fact it's a more interesting one
[14:16] <pitti> i. e. crash right after upgrade
[14:17] <seb128> pitti, we often have the case with g-s-d or unity where new report come from the fixed version
[14:17] <Darxus> Can anybody give me a summary of what I'm getting into by disabling the patches in the precise gtk package?  The ubuntu specific stuff?  What depends on that, Unity?
[14:17] <seb128> pitti, because people didn't restart for 3 days
[14:17] <seb128> so they still have the old buggy version loaded
[14:17] <seb128> which is often giving us some wth, does the fix doesn't work?
[14:17]  * pitti files that as a bug; then we have something to report to when asking for an SRU
[14:17] <seb128> pitti, thanks
[14:18] <seb128> Darxus, lot of trouble
[14:18] <seb128> Darxus, do you disable all the patches?
[14:18] <seb128> Darxus, you will basically break unity, appmenu, overlayscrollbar
[14:18] <Darxus> seb128: I did in the last one I built, with the 3.4.1 packaging and gtk master.
[14:18] <Darxus> seb128: Thanks, that's exactly what I was looking for.  Anything else?
[14:19] <seb128> Darxus, the sound indicator
[14:19] <seb128> Darxus, software-center
[14:19] <seb128> Darxus, scrolling in gwibber
[14:19] <seb128> Darxus, like some other stuff as well
[14:19] <seb128> Darxus, i.e "don't do that"'
[14:19] <Darxus> Thanks.
[14:20] <Darxus> Eh, do you have any better suggestions for creating a package that allows gtk apps to work through wayland?
[14:21] <seb128> Darxus, what ubuntu patch breaks wayland support exactly?
[14:21] <Darxus> I'm not sure.
[14:21] <jbicha> Darxus: you really ought to start with the current Ubuntu packaging instead of starting from fresh, it'll make your life a lot easier
[14:21] <seb128> start by figuring that?
[14:21] <pitti> seb128: bug 984944, I subbed you
[14:21] <ubot2> Launchpad bug 984944 in apport "Reject crashes that happen right after upgrade" [Medium,Triaged] https://launchpad.net/bugs/984944
[14:21] <seb128> pitti, danke!
[14:21] <Darxus> jbicha: I'm planning to - the problem is that segfaults due to bug 983697.  Which is why I'm asking about disabling the ubuntu patches.
[14:22] <ubot2> Launchpad bug 983697 in evince "evince crashed with signal 5 in g_settings_get_value()" [Low,Invalid] https://launchpad.net/bugs/983697
[14:22] <seb128> Darxus, try export LIBOVERLAY_SCROLLBAR=0
[14:22] <Darxus> seb128: Cool, thanks.
[14:22] <seb128> Darxus, that disable the overlay scrollbars
[14:22] <seb128> Darxus, no need to drop any patch for that
[14:23] <seb128> Darxus, the patch checks for the variable
[14:23] <Darxus> I'll give that a try tonight, thanks.
[14:23] <seb128> it should be a no-op if it's set to 0
[14:23] <pitti> shoudln't it be enough to sudo dpkg -P liboverlay-scrollbar3-0.2-0 ?
[14:23] <pitti> ah, right, that variable should work, too
[14:26] <seb128> grrr, some days launchpad is a piece of crap, especially when trying to reassing bugs
[14:27] <seb128> like I tried to put "ayatana-scrollbar" upstream comment, failed, I added "liboverlay-scrollbar" ubuntu package and it reassigned to "ubuntu" no package
[14:28] <ogra_> lovely
[14:29] <mhr3> seb128, you're the stacktrace man :) can i somehow get the fully symbolic trace from addresses returned by the standard backtrace() call?
[14:30] <seb128> pitti, ^
[14:30] <seb128> mhr3, I doubt the addresses are enough to give you those infos
[14:30] <seb128> but pitti knows better about that
[14:30] <seb128> he looked to signatures stuff for the client side dup detection
[14:31] <mhr3> ok
[14:31]  * mhr3 waits for pitti's response
[14:33] <mhr3> i think something could be skipped in such trace (if compiler inlines stuff) but otherwise it should be possible to get a nice trace imo
[14:35] <seb128> mhr3, why just not use the standard tools,workflow?
[14:35] <pitti> mhr3: in theory yes, but in practice there is no tool to do it
[14:35] <pitti> mhr3: so you are much better off with a core dump
[14:36] <mhr3> seb128, it's an issue i'm unable to reproduce in gdb... i guess timing matters
[14:36] <seb128> mhr3, just ulimit -c and gdb the dump?
[14:36] <pitti> right, what seb128 says
[14:36] <pitti> no need to actually run the process under gdb
[14:36] <pitti> "ulimit -c unlimited"
[14:36] <pitti> gdb /path/to/process core
[14:36] <mhr3> but it doesn't crash
[14:37] <seb128> make it to so? :p
[14:37] <seb128> or you want the stacktrace every time you use some function?
[14:37] <mhr3> i want it when g_log logs the ref problem
[14:38] <seb128> mhr3, do a code check and abort() when that happens?
[14:38] <pitti> so if the first time is enough, change it g_error and it will SIGABRT
[14:38] <pitti> or call abort() yourself
[14:38] <mhr3> unfortunately there are many errors before that
[14:38] <mhr3> ones i dont particularly care about
[14:39] <seb128> mhr3, can't you regexp match the error in the code and abort() on the specific match?
[14:39] <seb128> like parse the error string
[14:39] <Darxus> seb128: My packages that are just the Ubuntu package plus the two necessary patch sets works with export LIBOVERLAY_SCROLLBAR=0 :)  Thanks.
[14:39] <mhr3> hmm, maybe
[14:39] <mhr3> thx seb128, pitti
[14:39] <seb128> Darxus, yw
[14:39] <seb128> mhr3, yw
[14:40] <pitti> mhr3: I haven't played with backtrace_symbols(), but that might help you?
[14:41] <mhr3> pitti, that's actually what i was using, but it's not overly useful
[14:42] <mhr3> like:
[14:42] <mhr3> 9: /lib/x86_64-linux-gnu/libdbus-1.so.3(+0xb47a) [0x7ffff1b6047a]
[14:42] <mhr3> 10: /lib/x86_64-linux-gnu/libdbus-1.so.3(dbus_connection_dispatch+0x9a) [0x7ffff1b6370a]
[14:42] <mhr3> 11: /usr/lib/x86_64-linux-gnu/libatspi.so.0(+0xa955) [0x7fffd5aed955]
[14:42] <mhr3> 12: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x16a) [0x7ffff5a2bc9a]
[14:42] <pitti> you only know the function names, not the precise location in the fuction, yes
[14:45] <pitti> mhr3: another hack: you could call gdb to create a core dump of yourself repeatedly, and name it with the timestamp or so
[14:45] <pitti> there's even a /usr/bin/gcore convenience wrapper
[14:45] <mhr3> now that sounds interesting
[14:48] <mhr3> i wonder if i could just synchronously call gcore by the process i want to core dump :)
[14:49] <mhr3> ah, requires root :/
[14:50] <pitti> or PR_SET_DUMPABLE
[14:50] <pitti> err, no, not that one
[14:51] <mhr3> SET_PTRACER?
[14:51] <pitti> mhr3: you can temporarily disable it globally in /etc/sysctl.d/10-ptrace.conf
[14:51] <mhr3> right
[14:51] <pitti> then any gdb can attach to any of your processes
[15:18] <seb128> desrt, could you look at bug #858390? it's getting some duplicates
[15:18] <ubot2> Launchpad bug 858390 in d-conf "nautilus crashed on startup in dconf_engine_refresh_user()" [Medium,Triaged] https://launchpad.net/bugs/858390
[15:24] <desrt> seb128: hm
[15:24] <desrt> seb128: the duplicates started to increase just after i did some refactoring in that area
[15:24] <desrt> suspicious!
[15:26] <seb128> desrt, I've asked for an updated stacktrace next time we get a duplicate
[15:26] <desrt> crashing with SIGBUS.  fascinating.
[15:26] <desrt> that's almost certainly due to hitting the shm area
[15:28] <desrt> is it always nautilus?
[15:28] <desrt> ie: do we see this same SIGBUS-in-dconf code situation in anything other than nautilus?
[15:29] <desrt> also: can we tell if maybe these users are on NFS?  this is more or less exactly the situation i'd expect to see because of XDG_RUNTIME_DIR not being set
[15:31] <seb128> desrt, one of the dups is gsd, so "no"
[15:31] <desrt> seb128: that was the other issue, no?
[15:31] <seb128> desrt, we can ask them...
[15:32] <seb128> desrt, https://bugs.launchpad.net/ubuntu/+source/d-conf/+bug/870800
[15:32] <ubot2> Launchpad bug 870800 in d-conf "gnome-settings-daemon crashed on system start indconf_engine_refresh_user() (dup-of: 858390)" [Medium,New]
[15:32] <ubot2> Launchpad bug 858390 in d-conf "nautilus crashed on startup in dconf_engine_refresh_user()" [Medium,Triaged]
[15:32] <desrt> ah.  go figure.
[15:34] <desrt> seb128: any way i could get my hands on some core?
[15:35] <seb128> desrt, not easily, maybe ask those users if one get the issue in a realiable way and could add one?
[15:36] <seb128> desrt, the other option that could work would be to put the bug "fix released", I think apport would "freak out" on the next duplicate, saying it's a regression and keeping it in state
[15:36] <seb128> pitti, ^ is that correct?
[15:36] <desrt> seb128: seems a rather indirect way of doing that...
[15:39] <seb128> desrt, yeah, I don't have a good reply though, out of asking the users
[15:48] <pitti> we don't usually expose the core dumps, indeed
[15:48] <pitti> we keep them in crashes which failed retracing
[15:48] <desrt> is it a case of not exposing them or them actually being deleted entirely?
[15:49] <pitti> the latter
[15:49] <desrt> privacy concerns, i guess
[15:49] <pitti> if you know the URL, you can still get them, but there's no way except DB hackery to find out
[15:49] <pitti> yes, we don't know what stuff might hide in them
[15:49] <desrt> hmm
[15:49] <desrt> seems like the worst of both worlds
[15:50] <desrt> private data is kept around forever
[15:50] <desrt> ....but you can't make productive use of it
[15:50] <pitti> oh, they will get cleaned up after a few days
[15:50] <desrt> ah
[15:50] <pitti> LP's garbage collector
[15:50] <pitti> but not immediately
[15:50] <desrt> gotcha
[15:53] <mterry> bryceh, heyo.  Do you know much about xkb maps and me getting a "key types not defined" error when trying to have xkbfile X extension use the "fr oss" layout?
[15:53] <bryceh> mterry, hyea
[15:54] <bryceh> mterry, yeah yeah I tinker with such bugs from time to time.  tell me more
[15:55] <pitti> good night everyone!
[15:56] <seb128> pitti, 'night
[15:56]  * bryceh pulls up fr oss
[15:57] <mterry> bryceh, let me get the bug
[15:57] <didrocks> see you pitti
[15:57] <mterry> bryceh, bug 960096 (look at my last few comments -- much of the bug deals with some other flaws)
[15:57] <ubot2> Launchpad bug 960096 in libxklavier "Live session started with wrong layout" [Medium,Confirmed] https://launchpad.net/bugs/960096
[15:57] <mterry> pitti, bye!
[16:01] <bryceh> mterry, ok so sounds like just a missing keyboard symbol in that key map?  should be a straightforward error if we know what the missing symbol(s) are
[16:03] <bryceh> mterry, /usr/share/X11/xkb/symbols/fr is the symbol map (search on xkb_symbols "oss")
[16:03] <mterry> bryceh, how do I get a smaller test case than "running X with fr/oss as default"?  Like, I tried running xkbcomp  /usr/share/X11/xkb/symbols/fr but it didn't error out
[16:05] <bryceh> right, that just compiles them
[16:10] <mterry> bryceh, OK.  So what's my next step?
[16:10]  * mterry is lost at the X barrier
[16:10] <rickspencer3> hey all, what's the word on the street for Precise? ready to ship?
[16:12] <bryceh> mterry, I've found  an upstream patch to the fr oss layout that we may be missing.  Reviewing...
[16:12] <ogra_> rickspencer3, "all, broken, we'll delay for 6 months"
[16:12] <ogra_> :)
[16:13] <bryceh> mterry, something with the space character
[16:13] <rickspencer3> ogra_, so we'll have 2 12.10's?
[16:13] <ogra_> indeed 12.10LTS and 12.10 :)
[16:16] <kenvandine> :)
[16:16] <bryceh> mterry, ok so next steps... are you able to reproduce this bug yourself?  If so let me paste you the current mainline version of fr to test.  if that works, could short circuit some debugging work.
[16:16] <mterry> bryceh, yes, I can reproduce
[16:17] <bryceh> mterry, ok, here's the fr file - http://paste.ubuntu.com/935651/ - copy to /usr/share/X11/xkb/symbols/fr
[16:17] <bryceh> you'll need to regen your xkb cache; easiest way is just restart X
[16:18] <mterry> bryceh, OK.  Will be back after trying
[16:20] <mterry> bryceh, no good
[16:21] <bryceh> ok, too bad, that would have been an easy fix :-)
[16:21] <mterry> agreed  :)
[16:23] <bryceh> mterry, ok so can you describe to me the steps to reproduce?
[16:23] <bryceh> does it happen immediately after setting the layout in the keyboard preferences capplet to fr oss?
[16:24] <mterry> bryceh, um, I haven't tried, I've had my layout like that for a little while for testing
[16:24] <mterry> bryceh, but if you have fr/oss as your first layout
[16:25] <mterry> bryceh, and start a session, you'll end up with 'us'
[16:25] <bryceh> ok, I can give that a try
[16:26] <bryceh> also, there are a set of standard log files we need for xkb bugs, but this bug report is missing them; perhaps easiest solution is to file a new bug against xorg, but if you'd rather stick with this bug report, would you mind manually collecting them?
[16:26] <bryceh> setxkbmap -print
[16:27] <bryceh> xkbcomp :0 -w0 -
[16:27] <bryceh> locale
[16:29] <mterry> bryceh, I can file a new bug.  would prefer to keep this new flaw separate from that previous bug
[16:29]  * mterry runs ubuntu-bug
[16:29] <bryceh> mterry, sounds good
[16:30] <bryceh> 'ubuntu-bug xorg' should do it
[16:32] <bryceh> mterry, there's a bug, or I guess class of bugs, which has been around as long as I can remember, where gnome tries to set the layout, and X barfs, and the user gets a quite unhelpful error message.  bug #524406 is an example.  If you see "Error activating XKB configuration." that's one of the symptoms.
[16:32] <ubot2> Launchpad bug 524406 in libxklavier "Frequent "Error activating XKB configuration"" [Low,New] https://launchpad.net/bugs/524406
[16:32] <seb128> mterry, if you need a xkb master you can try to ping svu on #gnome-hackers when he's online (he's the libgnomekbd, libxklavier upstream)
[16:32] <mterry> bryceh, I don't get a user-visible error
[16:34] <mterry> bryceh, bug 985065
[16:34] <ubot2> Launchpad bug 985065 in xorg "Can't use fr/oss keyboard layout by default" [Undecided,New] https://launchpad.net/bugs/985065
[16:35] <bryceh> seb128, I'll get in contact with svu about this once we have it characterized
[16:35] <seb128> bryceh, ok, good
[16:42] <bryceh> mterry, ok I'm reproducing here.  let me dick around with it a bit this morning and get back to you.
[16:42] <mterry> bryceh, ok, thanks!
[17:03]  * didrocks waves good evening
[17:06] <Sweetshark> pitti: ping?
[18:06] <Darxus> Is there a way to get notified any time a new gtk package is released?
[18:07] <desrt> Darxus: there are release announcements posted to various lists
[18:08] <desrt> including an automated announcement posted to the ftp-release-list@gnome.org
[18:08] <desrt> that's probably the most reliable one to follow
[18:09] <desrt> seb128: so we get some comfirmation that ecryptfs may be to blame here
[18:09] <desrt> for the dconf issue
[18:09] <Darxus> desrt: Sorry, I meant Ubuntu packages.
[18:10] <desrt> Darxus: apt-get upgrade? :)
[18:11] <Darxus> Heh.  So there's no way to just get an email any time the "latest upload" field on https://launchpad.net/ubuntu/+source/gtk+3.0 changes?
[18:12] <kklimonda> Darxus: you could filter through the precise-changes ML
[18:12] <Darxus> kklimonda: Thanks.
[18:12] <jbicha> Darxus: you can for Debian packages but I don't know if there's an automated way for Ubuntu packages
[18:12] <Darxus> I don't suppose there's an lp bzr repo containing the latest gtk source package I could set up a build recipe against?
[18:13] <jbicha> there is, & you could subscribe to email notifications of that
[18:13] <Darxus> Ooh.
[18:14] <Darxus> Where?
[18:14] <jbicha> you can just click the code tab at https://launchpad.net/ubuntu/+source/gtk+3.0
[18:15] <jbicha> but for Desktop packages, see the ~ubuntu-desktop branches, ie https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3
[18:15] <jbicha> just click Subscribe yourself in the top right
[18:15] <Darxus> Ah, that's what I was looking for, thanks.
[18:16] <jbicha> the ubuntu-desktop branches are usually packaging only which makes bzr pull faster
[18:16] <jbicha> there's some docs for it at https://wiki.ubuntu.com/DesktopTeam/Bzr
[18:17] <Darxus> Thanks.
[18:18] <Darxus> It'll be nice to automate my builds with the wayland backend enabled.
[18:21] <jbicha> if it works well, I'd imagine we'd build with wayland support for 12.10
[18:24] <Darxus> jbicha: Thanks, I hope so.  By that time, 3.6.0 will be released, so the patches I'm using will be included.  Just need to add --enable-wayland-backend --enable-x11-backend and the libxkb and libwayland dependencies.
[18:25] <Darxus> I'm hoping coordinating mutually compatible versions of wayland, gtk, and qt won't be too exiciting :/
[18:41] <Darxus> Seems like a build recipe using that doesn't grab the upstream tarball.  How would I make it do that?
[18:45] <micahg> Darxus: use the lp:ubuntu/gtk+3.0 branch instead
[18:45] <Darxus> micahg: But that one hasn't been updated since 2011-07-20?
[18:46] <micahg> meh, http://package-import.ubuntu.com/status/gtk+3.0.html#2011-07-25%2009:43:52.029711
[18:47] <Darxus> Imports broke?
[18:48] <micahg> yeah
[18:50] <Darxus> Should I file a bug?
[18:50] <micahg> sure, against the udd project if there isn't one already for that type
[18:51] <Darxus> Right, thanks.
[18:51] <Darxus> micahg: How did you find that page?  I don't see it linked from https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/gtk+3.0/precise
[18:51] <micahg> http://package-import.ubuntu.com/status/ + CTRL+F :)
[18:52] <Darxus> Ah, thanks.
[19:30] <kklimonda> micahg: don't those get stalled from time to time?
[19:30] <micahg> kklimonda: well, when they're stalled, they're usually restarted
[19:58] <seb128> lol
[19:58] <seb128> the kernel team now has a "bot-stop-nagging" tag
[19:59] <seb128> or how to stack hacks on hacks
[19:59] <seb128> "If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging."
[19:59] <seb128> can they made that the default? :p
[19:59] <seb128> make
[19:59] <seb128> then maybe just drop the stupid nag bot and be back to sanity ;-)
[20:02] <micahg> seb128: that was created at the last UDS
[20:02] <bryceh> seb128, I've been using a similar tag on the xorg bugbot, but treat it's use as an indicator of bugginess in the bot, and try to minimize its presence...
[20:02] <seb128> micahg, the stupid bot or the tag to prevent the bot?
[20:03] <micahg> seb128: tag to prevent the bot :)
[20:03] <jbicha> Sweetshark: is there a LibreOffice backports PPA?
[20:03] <seb128> micahg, bryceh: their bot just made me not want to ever report a kernel bug again
[20:04] <cyphermox> seb128: you're not alone
[20:04] <seb128> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/978622 is a good example of why
[20:04] <ubot2> Launchpad bug 978622 in linux "every app becomes unresponsive when nautilus is copying files" [Medium,Confirmed]
[20:04] <micahg> well, they've gone from 10k+ bugs to < 6k
[20:05] <seb128> "nice reporter" follow by 2 different bug similar "can you test with new kernel" comments, followed by a reply, followed by another same automatic bot reply, followed by a "it seems an upstream issue report it to them yourself"
[20:05] <seb128> micahg, I suprised they didn't went to 0
[20:05] <bryceh> yeah I  hate the "report it upstream yourself" responses
[20:06]  * micahg doesn't like those comments in general unless it's untestable by a triager, which unfortunately is the case for most kernel bugs
[20:06] <seb128> micahg, it's easy enough to write a bot just closing bugs if you don't want to deal with them
[20:06] <bryceh> seb128, indeed it's an 8 line script. easy
[20:06] <seb128> ;-)
[20:07] <bryceh> I think it's sort of a failing in launchpad that it doesn't allow for better tracking of what was tested
[20:09] <seb128> well, it's not a question of what was tested
[20:09] <seb128> it's that they upload a kernel every 2 weeks and never look at your bugs
[20:09] <seb128> but add a bot comment with every upload
[20:10] <seb128> so on a cycle you get to fight with a bot which sets your bug to incomplete 10 times at least
[20:10] <seb128> no wonder that at the end it wins
[20:11] <seb128> when you reopened the bug 5 times saying "yes it's an issue" you still nobody else than the bot setting to incomplete communicated with you, you go wth and give up on trying to ever report a kernel bug again
[20:11] <seb128> you still-> with still
[20:13] <bryceh> seb128, well what I mean is that launchpad ought to distinguish that the bug is against an out of date version, rather than using a bot to post comments
[20:13] <bryceh> so, the idea would  be if you look at a bug you filed a month ago, it should indicate that the bug's against an out of date version
[20:13] <seb128> bryceh, well that wouldn't help there
[20:13] <bryceh> seb128, sure it would
[20:14] <seb128> it's easy to figure that the bug was reported against an outdated version
[20:14] <seb128> the issue is that they send a bug putting the bug incomplete on you to get ride of your bug rather than trying to read it
[20:14] <bryceh> seb128, ah but that's not clear to the reporter that it's blocked because of that (else why bother with the bot comments?)
[20:15] <bryceh> anyway, not like we'll get launchpad to implement new features any time soon.
[20:15] <seb128> right
[20:15] <seb128> at the end it's a manpower,number of bugs issue
[20:15] <bryceh> seb128, and also anyway, I completely agree it's quite annoying as implemented.  I grit my teeth whenever I get that after filing a bug
[20:16] <bryceh> but with the kernel they get so many bug reports that your bug report is going in a black hole, bot or no
[20:16] <seb128> I would just prefer to have my bug ignored until read than having to fight with a bot
[20:16] <seb128> like once every cycle would be fine
[20:16] <bryceh> usually have to catch a kernel engineer's attention too
[20:16] <seb128> I'm fine revisit my open bugs every 6 months
[20:16]  * bryceh nods
[20:17] <bryceh> yeah that's sort of the level I try with my bugbot; try to have no more than one bugbot question per bug, per year
[20:17] <seb128> one comment a cycle is a good goal I think
[20:17] <seb128> it's fair enough to ask when a new Ubuntu version is out to retest
[20:18] <seb128> I should try reporting a firefox bug to see how that goes ;-)
[20:19] <seb128> firefox doesn't bug enough, I didn't get to do that for a while!
[20:19] <bryceh> I try to couple it to a significant change, like after we've uploaded a new X stack, or if a fix went in that we expect to solve a *lot* of bug reports.  Seems like with the kernel they re-ask a bit too aggressively
[20:19] <seb128> right
[20:20] <Amaranth> bryceh: Sadly with the kernel hibernate and suspend bugs can be "fixed" with something as simple as a recompile sometimes so it makes sense to try to get constant testing as new versions are put out
[20:20] <Amaranth> Just as an example of a class of kernel bugs
[20:21] <bryceh> true, and we have some like that in X, like proprietary drivers especially
[20:23] <bryceh> but in such cases I try to target the bot to just that specific class of bug, and give some targeted message relevant to the type of bug.  I think that goes over better with the reporters than a generic "new version.  please retest"
[20:33] <bryceh> mterry, btw if you're still abouts think I got a handle on the keyboard bug
[20:33] <mterry> bryceh, oooh!
[20:33] <bryceh> looks like 'udevadm  trigger --subsystem-match=input --action=change' does the trick
[20:33] <bryceh> try that
[20:34] <bryceh> +sudo
[20:34] <mterry> bryceh, I see your comment.  I got debug comments by changing the code  :-/
[20:34] <mterry> bryceh, this is after I login?
[20:34] <bryceh> mterry, aha! no wonder I couldn't figure out how to turn that on :-)
[20:34] <bryceh> mterry, yep, from just a gnome-terminal window or whatever
[20:35]  * bryceh retests too
[20:35] <mterry> bryceh, hmm.   i didn't logout and in again, but was my layout supposed to instantly change?
[20:35] <bryceh> mterry, it did for me.
[20:36] <bryceh> although I'd run a few other things prior to that, so it could be a combination.  retesting
[20:36] <bryceh> nope, that's all that it takes for em
[20:36] <mterry> hm
[20:37] <bryceh> mterry, well let me backup
[20:37] <mterry> can't log out, becasue I'm in the middle of an upload
[20:37] <bryceh> I found that running sudo dpkg-reconfigure keyboard-config made my keyboard work right.  Someone had suggested it on the previous bug.  But it only persists one session.
[20:38] <bryceh> mterry, so looking at the keyboard-configuration scripts and readmes, I saw
[20:38] <bryceh> blah blah the
[20:38] <bryceh> changes will become visible to X only if
[20:38] <bryceh> udevadm trigger --subsystem-match=input --action=change
[20:39] <mterry> I've still got upstream's fr symbols file if that matters...
[20:39] <bryceh> mterry, shouldn't.
[20:43] <bryceh> mterry, anyway, I *think* maybe what's needed is to add the above udev call to the gnome keyboard tool.  once your upload's done if you could test it, that'd help.  I'll poke further in a little bit.
[20:44] <mterry> bryceh, which keyboard tool?
[20:52] <bryceh> mterry, in the hud type "keyboard layout"
[20:53] <bryceh> don't think it has a separate executable anymore
[20:53] <bryceh> guessing the backend code is in gnome-settings-daemon or somesuch
[20:58] <mterry> bryceh, but this happens if you just change the gsettings key and reboot
[20:58] <mterry> bryceh, and the trigger stuff would happen each boot right?   Or are you saying when lightdm changes the layout via libxklavier, it should also issue a trigger?
[21:01] <bryceh> mterry, I need to dig a bit more but yes, I suspect that we need this call added to the startup code "somewhere" to kick it into action
[21:02] <bryceh> mterry, we might want to run  this by cjwatson for sanity check before we change anything
[21:02] <mterry> yar
[21:06] <seb128> mterry, hey
[21:06] <seb128> mterry, (now is time to run for you ;-)
[21:07] <seb128> dammit! ;-)
[21:07] <mterry> seb128, :)
[21:07] <seb128> hehe
[21:07] <seb128> mterry, you working on indicator-datetime in the past, do you know how it's computing the timezone for a location you add?
[21:07] <seb128> mterry, i.e http://geoname-lookup.ubuntu.com/?query=new%20york&release=precises&lang=fr_FR.UTF-8 returns geolocation infos
[21:08] <seb128> name, coordinates
[21:08] <mterry> seb128, should get that from the server
[21:08] <seb128> but not times
[21:08] <seb128> mterry, do you know if I can query that from the website?
[21:08] <mterry> seb128, oh right.  it looks it up on a map it has
[21:08] <mterry> seb128, maps the coords to the same map you click on
[21:08] <seb128> mterry, it's placing "new york" in africa for some users
[21:08] <mterry> seb128, seems bad
[21:08] <seb128> right
[21:08] <seb128> we are trying to figure why
[21:09] <seb128> and why it happens only to some users (locales?)
[21:09] <mterry> oh really?  locale...  shouldn't affect it
[21:09] <mterry> might affect response from server?
[21:10] <seb128> mterry, right, that's why we are trying to figure, thanks
[21:10] <kenvandine> mterry, so if seb128 disconnects network it works
[21:10] <kenvandine> just getting it from the local cache
[21:10] <seb128> mterry, like the cached value give me the right time
[21:10] <kenvandine> when online it sets his timezone to africa
[21:10] <seb128> 'Africa/Abidjan New York'
[21:11] <seb128> in the gsettings key
[21:11] <kenvandine> not just for new york either, someone else reported it for barcelona
[21:11] <seb128> kenvandine, barcelona is in africa seen from the U.S it's an understable mistake :p
[21:11]  * seb128 hides
[21:12] <kenvandine> mterry, for users that can reproduce the bug, it is consistent
[21:12] <kenvandine> but others can't :/
[21:12] <kenvandine> hehe
[21:14] <mterry> hmm
[21:14] <mterry> Have to reboot to test bryceh's thing.  Hold on
[21:17] <seb128> mterry, unping, ted figured it out, it's you U.S guys hating use europeans
[21:17] <mterry> seb128, oh nice!  what was the deal?
[21:17] <seb128> mterry, aka atof not liking being giving a "." instead or a ","
[21:17] <mterry> seb128, hah!
[21:17] <seb128> the decimal separator
[21:18] <mterry> seb128, everyone needs to just speak swahili and we'd all be happier
[21:18] <micahg> is that a locale specific thing?
[21:19] <mterry> bryceh, your udevadm line didn't change anything for me after a fresh reboot
[21:19] <seb128> micahg, not one locale, but yes, some locales use "," as a decimal separator
[21:19] <seb128> like in most european country you write 45,3 not 45.3
[21:21] <mterry> So adorable!  /me tousles seb128's hair
[21:22] <seb128> heh
[21:23] <seb128> mterry, you realized that it's the second french hater bug we are discussing in 2 days? I wonder what is going on there!
[21:23] <seb128> mterry, btw having to run that udev command seems weird, like why would it be needed for some variants of keyboard only?
[21:23] <jbicha> seb128: does your ubuntu-docs work?
[21:24] <mterry> seb128, you're barely french, why do you care?
[21:24] <seb128> jbicha, oh, good question, I need to upgrade, I will tell you that in a bit
[21:24] <mterry> seb128, agreed...
[21:31] <seb128> jbicha, yes, the updated langpacks works ;-)
[21:31] <Laney> can we get apport to attach sources.list to upgrade failure bugs or to indicate if any third-party repositories are in use?
[21:31] <seb128> mterry, https://code.launchpad.net/~ted/indicator-datetime/lp773987/+merge/102591 is the datetime fix in case you were curious about the details
[21:32] <seb128> Laney, that's to discuss with pitti but I guess we can easily do it if we decide it's not a privacy issue
[21:32] <seb128> Laney, but users might have private ppas in there
[21:32] <seb128> Laney, so maybe a "ppa in use" flag or something would be better
[21:33] <Laney> it could have a heuristic to filter out common private repo patterns, but that could never catch all private repos I guess
[21:33] <mterry> seb128, awesome.  nice catch tedg!
[21:33] <seb128> Laney, what issue do you try to solve?
[21:33] <seb128> Laney, we should rather signal if local installed packages were non official versions
[21:34] <Laney> yeah
[21:34] <seb128> Laney, isn't the dist-upgrade disabling ppas for upgrades anyway?
[21:34] <Laney> there's a bad mono upgrade failure that seems to still exist in some PPA/unofficial package
[21:34] <Laney> maybe it's not dist-upgrade
[21:34] <Laney> well, u-m upgrade
[21:34] <jbicha> seb128: cool! so there's help for the French after all
[21:35] <jbicha> perhaps the upgrader should ppa-purge instead of just disabling ppa's
[21:35] <Laney> I thought apport did indicate unofficial packages but perhaps it doesn't know that in upgrade scenarios
[21:38] <seb128> Laney, well it does prevent you to report against an unofficial version and it will indicator changed content from the binary (i.e files which don't match the md5sum)
[21:38] <seb128> Laney, it will probably not warn after upgrade since the new version which failed to install is the official one though
[21:39] <Laney> right, it reports that the old version failed to upgrade
[21:40] <Laney> but it doesn't catch that this is due to a bug that exists in the unofficial new version
[22:49] <Sweetshark> jbicha: https://launchpad.net/~libreoffice/+archive/ppa description needs some updating.
[22:50] <Sweetshark> jbicha: it was needed for the f**^&*ed up 3.4 release ...
[22:53] <jbicha> Sweetshark: is that going to have stable releases, like for 12.04 users can they add that and they'll get LO 3.5 when it's ready?
[22:55] <jbicha> the idea I had in mind was kinda like the firefox-stable PPA before everyone got the latest Firefox releases
[23:06] <Sweetshark> jbicha: ? ubuntu 12.04 will have LibreOffice 3.5
[23:07] <jbicha> I meant LO 3.6
[23:07] <Sweetshark> jbicha: there will be a libreoffice-3-5 ppa, which will get 3.5.X updates before they are SRUed. http://sweetshark.livejournal.com/10977.html
[23:09] <Sweetshark> jbicha: i will primarily care about 3.6 on ubuntu p+1, but if ricotz continues to backport as fast as he does now, there shouldnt be an issue.
[23:13] <micahg> Sweetshark: might I suggest a stable and oldstable vs versioned PPAs so they can be reused