[06:40] <pitti> Good morning
[07:58] <willcooke> Good morning all
[08:13] <tsdgeos> guys my indicator-time does randomly not start every say 10 or 20 times
[08:13] <tsdgeos> when i log in
[08:13] <tsdgeos> shitty bug report i know :/
[08:13]  * willcooke has seen this randomly as well
[08:14] <seb128> tsdgeos, maybe check .cache/upstart log for errors?
[08:14] <seb128> what is the status of the upstart job when that happens? is the binary running?
[08:14] <larsu> journalctl!
[08:14] <tsdgeos> binary is not running
[08:16] <tsdgeos> status of the job not sure since i just started it manually ^_^
[08:16] <tsdgeos> will try next time
[08:16] <seb128> k
[08:16] <seb128> nothing in the log?
[08:17] <tsdgeos> there's
[08:17] <tsdgeos> Indicator-Datetime-Message: indicator-datetime exiting; failed/lost bus ownership
[08:17] <tsdgeos> g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
[08:17] <tsdgeos> but is not from today but yesterda
[08:17] <tsdgeos> -rw-r----- 1 tsdgeos_work tsdgeos_work 197 feb  2 18:52 indicator-datetime.log.1.gz
[08:20] <larsu> tsdgeos: woah, dbus is stopped before the indicator
[08:20] <larsu> the indicators don't handle that case at all
[08:20]  * larsu wonders if we should assert
[08:21] <pitti> bonjour mes amis, comment avez-vous et le sprint ?
[08:21] <larsu> oh cool, GDBusConnection supports killing your process when the connection disappears
[08:21] <larsu> pitti: bonjour!
[08:22] <didrocks> bonjour pitti
[08:23] <larsu> didrocks: kopf hoch!
[08:24]  * didrocks does a fake smiling then
[08:24] <desrt> didrocks: i repeat my original suggestion :)
[08:24] <desrt> (ie: put the code in plymouth)
[08:25] <desrt> didrocks: stand up
[08:25] <didrocks> well, the goal was to have something that would work on the long term
[08:30] <pitti> "the code"> listening to fsckd?
[08:31] <pitti> 'cause, fsckd itself makes more sense in systemd itself, and it was already agreed that we want this
[08:32] <didrocks> pitti: yeah, that was this that we discussed (and what I explained yesterday)
[08:33] <seb128> pitti, salut! ça va bien, et toi ?
[08:33] <pitti> seb128: je vais bien, merci ! debugging people's boot problems :)
[08:34] <seb128> pitti, my reboot/shutdown hangs until I sit on the power button, I saw you mentioned some cases where that can happen on the upstream list
[08:34] <seb128> pitti, how can I tell if I hit one of those?
[08:34] <pitti> seb128: /usr/share/doc/systemd/README.Debian describes how to enable the debug shell
[08:34] <seb128> pitti, danke
[08:34] <pitti> seb128: i. e. boot without "splash quiet", systemctl start debug-shell.service
[08:35] <pitti> seb128: then shut down, and when it hangs, Alt+F9 to get to the debug shell
[08:35] <seb128> pitti, exellent, thanks
[08:35] <pitti> seb128: then systemctl list-jobs shows you what it's waiting on
[08:35] <pitti> seb128: then you can poke further with systemctl status -l <unit>, etc.
[08:35] <pitti> seb128: thanks for doing that; please file a bug once you know what it's hanging on, I really want to track these issues
[08:36] <seb128> pitti, yw
[08:36] <seb128> pitti, that README doesn't say to boot without splash quiet
[08:36] <seb128> just to systemctl start debug-shell
[08:36] <pitti> seb128: well, it's not strictly necessary, but generally nicer to see what's going on without manual prodding
[08:38] <seb128> brb
[08:49] <seb128> pitti, ok, of course it doesn't happen when I try to reproduce, booted with the option anyway maybe later I hit it again
[08:50] <pitti> seb128: at least the issue I was discussing on the ML is a race condition; might require a few reboots indeed :/
[08:50] <pitti> seb128: you can just start the debug shell, so that you have it available once it happens
[08:50] <seb128> pitti, yeah, the README has a warning about doing that :p
[08:51] <pitti> seb128: you could also "systemctl enable debug-shell" if you always want it; but be aware that anyone with access to your computer then has a root shell :)
[08:51] <seb128> yeah
[08:53] <willcooke> mlankhorst, you ded?
[08:53] <willcooke> mlankhorst, feeling any better today?
[08:55] <darkxst> pitti, seb128 its a security hole either way, unless you have encypted partitions
[08:55] <pitti> darkxst: these don't help -- they are usually unlocked while running :)
[08:56] <pitti> the only thing that actually helps is per-user ecryptfs for users which are not currently logged in
[08:56] <pitti> but meh -- it's a debugging tool, exactly what it says on the tin :)
[08:56] <darkxst> it does make it a little too easy to get root access to a machine though
[08:57] <darkxst> not that its that hard to do it other ways also
[08:57] <darkxst> if you have physical access
[08:57] <pitti> sure; just reboot in rescue mode
[09:06] <pitti> seb128: FYI, jibel just reminded me that it might be modemmanager
[09:06] <pitti> that occasionally hits me too, under upstart as well
[09:06] <seb128> Trevinho, larsu, there is an issue with your bamf changes, it displays a low res gedit icon for me, quite visible in alt-tab
[09:06] <seb128> pitti, how do I tell if that's it?
[09:07] <darkxst> pitti, sure, many easy  ways to get root access when you have physical access to a machine
[09:07] <pitti> seb128: list-jobs would have a job for modem-manager
[09:07] <seb128> pitti, k
[09:07] <pitti> seb128: under upstart, I'm not sure; back then I dropped splash/quiet and just saw it hang there
[09:07] <seb128> pitti, I'm under systemd, so debugging that is good enough for me
[09:10] <larsu> seb128: clearly Trevinho's fault :P
[09:17] <tsdgeos> charles: you there?
[09:18] <seb128> tsdgeos, he's likely sleeping at this hour
[09:19] <tsdgeos> oki, i'll comment on the MR then
[09:19] <seb128> Laney, https://code.launchpad.net/~renatofilho/ubuntu/vivid/syncevolution/default-syncInterval/+merge/247768 was the mr for the syncevolution change
[09:20] <seb128> it's still unapproved and not even closed or commented on...
[10:06] <mlankhorst> willcooke: slightly, still sick-ish
[10:06] <willcooke> mlankhorst, bad luck :/
[10:06] <willcooke> hope you are feeling better soon
[10:06] <mlankhorst> yep
[10:06] <mlankhorst> thanks
[10:07] <mlankhorst> btw Xmir can't leave the ppa until 1.17 is in vivid
[10:07] <willcooke> ah
[10:07] <willcooke> interesting
[10:07] <willcooke> Can the source not be made available via that project either?
[10:08] <mlankhorst> I would prefer to use a git tree for Xmir
[10:09] <willcooke> mlankhorst, can we still pull Xmir in to our projects/silos etc for inclusion in, let's say, a phone image?
[10:09] <mlankhorst> I think so
[10:10] <willcooke> mlankhorst, ok - didrocks does something similar for Make
[10:10] <willcooke> LP can point to Git as an upstream project and pull it in automagically
[10:10] <willcooke> let's do that :)

[10:11] <mlankhorst> for an upstream project is a /debian directory needed?
[10:11] <willcooke> erm, didrocks ^ can you advise?
[10:13] <happyaron> seems not important, it'll be ignored by dpkg-source eventually
[10:13] <Laney> you can have this in another branch
[10:15] <Laney> I guess pkg-xorg does something like that already
[10:15] <Laney> separate upstream and upstream+packaging branches
[10:25] <mlankhorst> yeah it's what happens right now
[10:25] <mlankhorst> on every release we'll merge the new upstream back to the branch with packaging
[10:27] <Laney> what's wrong with that then?
[10:33] <didrocks> mlankhorst: no debian directory needed
[10:33] <didrocks> its all magic :)
[10:33] <didrocks> mlankhorst: I can do it for you if you create the project and gives me the creds
[10:34] <didrocks> and point to the git upstream repo :)
[10:37] <Laney> oh for the import?
[10:56] <mlankhorst> ok, I don't have a git repo currently, lets see..
[11:02] <mlankhorst> git://people.freedesktop.org/~mlankhorst/xserver.git
[11:02] <mlankhorst> when it gets up in a bit
[11:11] <didrocks> mlankhorst: tell us when you registered the launchpad project
[11:13] <mlankhorst> https://launchpad.net/xmir already exists?
[11:14] <mlankhorst> could we use that?
[11:16] <didrocks> mlankhorst: yeah, ask duflu to fix the ownership though
[11:16] <didrocks> mlankhorst: or kgunn
[11:22] <mlankhorst> who do you want to have ownership?
[11:23] <mlankhorst> I can adjust it to anything it seems
[11:24] <duflu> didrocks, mlankhorst: Might be better to add Maarten to mir-team or create an xmir team
[11:24] <mlankhorst> duflu: https://launchpad.net/~mir-team/+members ;-)
[11:25] <didrocks> mlankhorst: ok, so, if you create a new branch, there is an option to tell "hosted in a git repo"
[11:25] <didrocks> and then, just point to your git ^
[11:25] <duflu> OK, I need to fix nothing.
[11:25] <duflu> Lunch
[11:25] <didrocks> thanks duflu
[11:26] <mlankhorst> added
[11:28] <didrocks> mlankhorst: should appear in ~15min
[11:28] <didrocks> keep me posted
[11:53] <mlankhorst> oke
[13:48] <seb128> shrug
[13:48] <seb128> kenvandine, u-s-s tests seems unreliable again?
[13:48] <seb128> got a few different ones hitting CI errors :-/
[13:59] <kenvandine> seb128, :-(
[14:03] <tedg> seb128, kenvandine, do you guys know of a package overriding ctest? I was trying to do it and I can't seem to get the directory right. Looking for something to crib off of.
[14:03] <kenvandine> tedg, i haven't seen one
[14:12] <seb128> tedg, no, I don't
[14:13] <didrocks> larsu: http://paste.ubuntu.com/10054163/
[14:14] <tedg> :-(
[14:14] <tedg> Someone had to have wanted verbose test logs, somewhere! :-)
[14:18] <tedg> So I think I need to be in the object directory.
[14:18] <tedg> How do I find that?
[14:19] <tedg> In my case it's: /home/ted/Development/indicator-sound/build-area/indicator-sound-12.10.2+15.04.20150129.1/obj-x86_64-linux-gnu
[14:25] <xnox> tedg: dh_auto_make -> will put you in the cmake's build directory as far as I can tell.
[14:27] <xnox> tedg: one can derive it from DEB_HOST_GNU_TYPE it's
[14:27] <xnox> "obj-" . dpkg_architecture_value("DEB_HOST_GNU_TYPE");
[14:27] <xnox> include /usr/share/dpkg/default.mk
[14:27] <xnox> "obj-"$(DEB_HOST_GNU_TYPE)
[14:27] <xnox> "
[14:28] <tedg> Cool, let me try that. I think I found an environment variable that might pass things to CTest as well.
[14:29] <tedg> Yes, so this works to pass an arg to CTest:
[14:29] <tedg> +override_dh_auto_test:
[14:29] <tedg> +	ARGS=-V dh_auto_test
[14:29] <tedg> We can talk about horrible variable naming later :-)
[14:29] <tedg> (wasn't me)
[14:34] <tedg> Thanks xnox
[14:34] <xnox> tedg: ewh
[14:34] <xnox> tedg: dh_auto_test -- -V=1
[14:34] <xnox> override_dh_auto_test:
[14:35] <xnox>      dh_auto_test -- -V=1
[14:35] <xnox> is aught to work
[14:35] <ogra_> but it doesnt use the beautiful "ARGS"
[14:35] <ogra_> :P
[14:35] <tedg> xnox, I think that passes the -V to make, which doesn't work.
[14:35] <tedg> xnox, It has to pierce through the makefile and into ctest.
[14:36]  * tedg heard you liked wrappers do he wrapped your make script in a dh_ helper so that it can wrap the test tool which wraps your tests
[14:37] <xnox> tedg: i would have thought:
[14:37] <xnox> dh_auto_configure -- -DCTEST_OUTPUT_ON_FAILURE=TRUE
[14:37] <xnox> would work
[14:37] <xnox> or
[14:37] <tedg> I don't want the output on failure, I want it on progress.
[14:37] <xnox> CTEST_OUTPUT_ON_FAILURE=TRUE dh_auto_test
[14:37] <xnox> oh, horum.
[14:37]  * xnox hates that cmake is non-free
[14:37] <tedg> The problem is the test is hanging on Jenkins.
[14:37] <xnox> documentation that is.
[14:37] <xnox> hehe =) Jenkins, got to love ya.
[14:38] <tedg> Yeah :-/
[14:38] <ochosi> xnox: hey there! i know it's very low priority and all, but also extremely low hanging fruit, mind to take a 1min peek at my 3-line ubiquity MR? https://code.launchpad.net/~ochosi/ubiquity/xubuntu-panel-bg/+merge/247001
[14:38] <tedg> And since Jenkins just kills the whole thing instead of killing the leaf processes and letting make clean up, I don't get any logs.
[14:39] <xnox> ochosi: you want cyphermox
[14:39] <cyphermox> ah?
[14:39] <xnox> cyphermox: ^^^ from ochosi
[14:39] <cyphermox> yes yes
[14:40] <ochosi> ah
[14:40] <xnox> ah ah
[14:40]  * xnox joins the ah game
[14:40] <ochosi> xnox: sorry, i was under the impression you were *the* ubiquity guy :)
[14:40] <ochosi> otherwise i wouldn't have done the ad hominem ping
[14:40] <ochosi> thanks for fwding me
[14:40] <xnox> ochosi: i am just a minion.
[14:40] <ochosi> and hi cyphermox :)
[14:40] <cyphermox> howdy :)
[14:40] <xnox> ochosi: cyphermox is a more responsive minion =)
[14:40] <ochosi> xnox: you mean one of those little yellow ones? :]
[14:41] <ogra_> ubiquity makes you crazy if you work in it to long ... so we try to rotate the devs before we need to send them to asylum
[14:41] <ochosi> haha
[14:41] <xnox> ochosi: BA-NA-NA
[14:41] <cyphermox> I see myself more like an umpa-lumpa, but minion works ;)
[14:41] <ochosi> heh, well given that its codebase drives you crazy, ubiquity works well enough :)
[14:55] <davmor2> cyphermox: I don't believe it there is no oompaloompa vs minion videos :D
[14:55] <cyphermox> omg.
[14:58] <andyrock> seb128, you here?
[14:58] <seb128> andyrock, hey
[14:58] <andyrock> so i'm working on the large text bug again (was busy in the last few days)
[14:58] <seb128> cyphermox, hey, how is the segfault issue going?
[14:59] <andyrock> know unity correctly updates the value of text-scaling-factor (the gnome setting)
[14:59] <andyrock> but the applications need to be refocused
[14:59] <seb128> andyrock, that's a bug in GTK I think
[15:00] <andyrock> to get the large text
[15:00] <seb128> Laney, larsu ^
[15:00] <andyrock> also the gtk widgets in 14.10 scales nicely
[15:00] <andyrock> *scale
[15:01] <andyrock> in 15.04 they fail to scale and text does not fit
[15:01] <andyrock> another no-unity bug
[15:06] <seb128> larsu, Laney ^
[15:06] <seb128> andyrock, what widgets?
[15:16] <larsu> Laney: ^
[15:17] <Laney> WHAT
[15:17] <desrt> seb128: ping
[15:17] <seb128> desrt, PONG
[15:17] <didrocks> those guys…
[15:17] <desrt> seb128: so we're playing tennis now, or what?
[15:17] <didrocks> seb128: Laney: larsu: desrt: those guys!
[15:17] <seb128> oh yeah
[15:17] <seb128> double with a refereee = 5
[15:18] <desrt> size of a shift in hockey, excluding the goalie
[15:18] <desrt> also five!
[15:18] <desrt> and omg
[15:18] <desrt> seb128 + didrocks + Laney + larsu + desrt ...
[15:18] <desrt> also five
[15:19] <larsu> + willcooke is also 5
[15:19] <desrt> willcooke can be the goalie
[15:19] <larsu> ballboy
[15:20] <desrt> it would suck to have a nick that didn't have 5 letters in it
[15:20] <desrt> sure glad i don't have to live that life
[15:20] <andyrock> seb128, http://imagebin.ca/v/1qVP9Bni8IMD
[15:21] <andyrock> after a while they get the correct dimensions
[15:21] <andyrock> the text just need a refocus
[15:21] <andyrock> the widgets (in the pictures) need some time more
[15:22] <andyrock> seb128, and it happens on nautilus, u-c-c and others
[15:23] <seb128> andyrock, yeah, looks like a gtk issue, please fix the unity side still
[15:24] <andyrock> ok, i can look inside the gtk side as well but I need some help to start
[15:24] <seb128> Laney, larsu ^
[15:25] <larsu> Laney: ^
[15:26] <Laney> WHAT
[15:26] <larsu> WAT
[15:26] <Laney> thanks it's in our brain space and will look soon
[15:26] <cyphermox> seb128: still in my PPA, with the other fix too
[15:27] <andyrock> Laney, regarding the issue with "large text"
[15:27] <andyrock> Laney, https://bugs.launchpad.net/unity/+bug/1408212
[15:28] <andyrock> Laney, a fix for Unity is in progress
[15:28] <andyrock> but likely there is some issue on gtk as well
[15:32] <andyrock> seb128, I proposed a fix right now
[15:32] <andyrock> seb128, I'm working on an utility class to avoid this issue in the feature but for the moment is better to fix it asap
[15:32] <didrocks> willcooke: bregma: https://bugs.launchpad.net/unity/+bug/1364070
[15:33] <andyrock> didrocks, last time it was working fine
[15:33] <seb128> attente_,  gsettings set org.gnome.desktop.interface text-scaling-factor
[15:34] <andyrock> didrocks, likely you where using new gsettings
[15:34] <andyrock> *were
[15:35] <didrocks> andyrock: did you look at the bug report?
[15:35] <didrocks> andyrock: it was reporting way before the gsettings change
[15:35] <didrocks> reported*
[15:35] <didrocks> andyrock: and it's 80% of the time
[15:35] <andyrock> didrocks, yep i know
[15:35] <didrocks> (see description)
[15:35] <andyrock> but I can't reproduce 100%
[15:35] <didrocks> andyrock: so, it's not due to the new gsettings
[15:35] <didrocks> yeah, 80%
[15:35] <didrocks> getting bug reports everyday
[15:35] <didrocks> seb128: you got it as well, isn't it?
[15:36] <seb128> I saw it yeah
[15:41] <andyrock> didrocks, how do you create the desktop file?
[15:41] <didrocks> andyrock: in ~/.local/share/applications
[15:41] <didrocks> just writing to it through python
[15:42] <didrocks> andyrock: want an example?
[15:42] <didrocks> (it shows up in the dash, and I can add it afterward)
[15:42] <didrocks> andyrock: again, it's working like 20% of time
[15:43] <didrocks> so, maybe a timestamp issue?
[15:43] <didrocks> (gsettings has the right values with gsettings get)
[15:45] <andyrock> didrocks, k I'll try to reproduce it again
[15:45] <didrocks> thanks!
[15:46] <andyrock> didrocks, maybe bamf's fault as well
[15:48] <bregma> willcooke, another thing we need to have a strategy for is applications that make explicit X11 calls despite using a toolkit
[15:49] <willcooke> bregma, is that not convered by Xmir?
[15:49] <bregma> only if it's using XMir
[15:49] <willcooke> Ahh, so, e.g. Gtk apps which also call X11
[15:50] <bregma> yeah, like gksudo
[15:50] <willcooke> erk
[15:50] <didrocks> andyrock: oh, good one
[15:50] <bregma> or QtCreator
[15:50] <didrocks> andyrock: when it happens, a logout/login "fixes" it, so can be bamf,yeah
[15:50] <willcooke> Sounds like another "exceptions list" thing
[15:50] <Trevinho> andyrock: I think it's not bamf, but mostly related to the icons priority
[15:51] <Trevinho> I had a change that was resetting it after a reorder, so maybe that's enough but it had other downsides
[15:51] <bregma> willcooke, we're thinking a small fake Xlib might solve some problems (setting WM atoms is a common reason to call X11 directly)
[15:51] <andyrock> Trevinho, unity asks bamf is a desktop file is a good one right?
[15:51] <andyrock> *if
[15:51] <Trevinho> no
[15:52] <willcooke> bregma, oh - much nicer :)
[15:52] <andyrock> mmm so it's not the problem
[16:38] <larsu> someone hug desrt
[16:41] <desrt> larsu: ?
[16:41] <larsu> desrt: you looked like you needed one when you were fighting with wp
[16:41] <desrt> ah.  ya.
[16:42] <desrt> evil wp.
[16:44] <andyrock> didrocks, ok i can reproduce the issue
[16:47] <Laney> wee
[16:47] <Laney> 46,000th launchpad email
[16:47] <Laney> since Date: Wed, 04 Aug 2010 19:29:21 -0000
[16:50] <desrt> Laney: good job.  have a cookie.
[16:51] <Laney> I'll take one at 50,000 instead
[16:51] <desrt> :)
[16:51] <desrt> larsu seems happy
[16:51] <didrocks> andyrock: sweet!
[16:52] <larsu> desrt: he is!
[20:04] <cyphermox> ochosi: your ubiquity change looks fine, but you should know that ubiquity-panel-bg.png doesn't currently seem to be installed from shimmer-themes.
[23:16] <ochosi> cyphermox: hm, weird, it's in git and i thought there was a release+upload already. i'll check again. good thing is, even if it fails, i.e. that file isn't there, ubiquity won't fail/break
[23:16] <ochosi> cyphermox: thanks for reviewing/approving and letting me know!
[23:42] <andyrock> desrt, ping