[04:57] <pitti> Good morning
[05:30] <didrocks> good morning
[05:35] <pitti> bonjour didrocks ! as-tu eu un bon week-end?
[05:38] <larsu> bonjour!
[05:40] <didrocks> pitti: très bon week-end, "week-end du patrimoine", donc pas mal de visistes
[05:40] <didrocks> et toi ?
[05:40] <didrocks> bonjour larsu !
[05:40] <didrocks> toujours content de ton appartement ?
[05:45] <larsu> didrocks: bien sûr!
[05:45] <larsu> how are you? Did you ave a nice weekend?
[05:46] <pitti> didrocks: nous sommes allè à Dresden, pour le 60eme anniversaire de père d'Annett
[05:46] <larsu> guten morgen pitti!
[05:47] <pitti> didrocks: "allé"
[05:48] <didrocks> super ! :)
[06:44] <seb128> good morning desktopers
[07:22] <pitti> bonjour seb128 !
[07:22] <seb128> pitti, salut, comment ça va ?
[07:22] <pitti> seb128: ça va bien, et toi ? on est allè à Dresden le week-end pour le 60eme anniversaire de père d'Annett
[07:23] <seb128> pitti, super, vous avez passé un bon w.e ?
[07:23] <pitti> seb128: oui -- beaucoup de voyage bien sûr, mais recontrer la famille est toujours bien
[07:24] <seb128> c'est long le trajet d'Augsburg à Dresden ?
[07:24] <pitti> seb128: presque 7 heures
[07:25] <pitti> seb128: vendredi je peux travailler dans le train -- mon "bureau rollant" :)
[07:25] <seb128> :-)
[07:26] <seb128> c'est vrai que ça fait long, c'est bien que tu puisses travailler en route
[07:55] <willcooke> Good day citizens
[07:55] <larsu> morning willcooke. Had a nice weekend?
[07:57] <seb128> hey willcooke
[08:01] <willcooke> larsu, good thanks, did gardening.  Today I feel like I've been run over
[08:01] <willcooke> larsu, how about you?
[08:03] <Laney> hey hey HEY
[08:03] <larsu> willcooke: uh oh, get better! I had a relaxing weekend well. Mostly unpacked boxes and rearranged stuff in the appartment :)
[08:03] <larsu> Laney: hey! sup?
[08:04] <didrocks> hey willcooke, larsu
[08:04] <didrocks> Laney*
[08:04] <didrocks> still rehey larsu ;)
[08:04]  * larsu reheys didrocks 
[08:05] <didrocks> \o/
[08:05] <Laney> #fail!
[08:06] <pitti> hey Laney
[08:06] <seb128> hey Laney, how are you?
[08:07] <Laney> HEY larsu & didrocks & pitti & seb128
[08:08]  * Laney is doing good
[08:08] <Laney> went on a foraging course at the weekend
[08:08] <Laney> I remember one thing from it, which is that you can eat fuschia berries
[08:09] <davmor2> Laney: yeah just not the red one, fuschia fine :)
[08:09]  * larsu has no indicator-power
[08:10] <seb128> Laney, "foraging"?
[08:10] <seb128> is that hunting? ;-)
[08:11] <seb128> larsu, is the service active? anything in the logs?
[08:12] <larsu> seb128: restarting helped - nothing in the logs :/
[08:12] <larsu> why is this stuff not in the journal yet?
[08:12] <Laney> this is weird
[08:13] <seb128> "stuff"?
[08:13] <Laney> can't find the translation
[08:13] <larsu> seb128: logs from indicators
[08:13] <Laney> but it is hunting for plants...
[08:13] <didrocks> larsu: started by the session?
[08:13] <larsu> didrocks: I have lots of session things in the journal
[08:13] <seb128> larsu, they are upstart session jobs, log should be in .cache/upstart
[08:13] <didrocks> larsu: the dbus-activated ones, yeah, but not the ones started by upstart
[08:13] <larsu> ah
[08:13] <larsu> we should redirect that
[08:13] <Laney> go teach upstart about the journal
[08:14] <Laney> that'll be a cool patch
[08:14] <seb128> Laney, k, google results were not very descriptive so I was unsure ;-)
[08:14] <larsu> can't we make it syslog?
[08:14] <Laney> I was looking in dictionaries
[08:14] <Laney> it's weird
[08:14] <larsu> having logs all over the place will make it harder for people to find problems
[08:14] <Laney> but yeah looking for what you can find to eat growing out and about
[08:14] <seb128> k
[08:14] <seb128> be careful with mushrooms!
[08:15] <Laney> the guy seemed to have made wine out of almost everything he showed us
[08:15] <Laney> was funny
[08:15] <seb128> larsu, I personally like the .cache/upstart/*.log better still, journalctl is a bit of a mess and it requires sudo
[08:16] <Laney> nettle wine anyone?
[08:16] <seb128> lol
[08:16] <hikiko> hi
[08:16] <larsu> seb128: no it doesn't
[08:16] <Laney> hey hikiko
[08:16] <larsu> and it's much faster
[08:16] <Laney> how's it going?
[08:16] <larsu> and has cmdline completion
[08:17] <larsu> morning hikiko :)
[08:17] <seb128> larsu, and it's a mess where you can't find anything because everything is mixed
[08:17] <davmor2> Laney: nettle tea is quite nice but a little bitter so I could see wine being a nice way to sweeten it
[08:17] <hikiko> hello larsu Laney and everyone
[08:18] <larsu> seb128: you can filter it :)
[08:18] <Laney> davmor2: you try it and let us know how it is :P
[08:18] <seb128> larsu, yeah, grep and sed are my friends ;-)
[08:19] <Laney> 1970sLinuxUser
[08:19] <Laney> :D
[08:19] <davmor2> Laney: for the tea then normally add peppermint to take out the bitter edge and that is yummy
[08:19] <seb128> $ journalctl --unit=nautilus
[08:19] <seb128> -- No entries --
[08:19] <seb128> thanks journalctl, that's useful :p
[08:19] <seb128> I guess because nautilus is not an unit
[08:20] <seb128> but I don't see a more appropriate option in -h to filter out nautilus logs
[08:20] <seb128> -t does the same
[08:22] <larsu> seb128: right, we don't have units for session things yet. journalctrl _COMM=nautilus
[08:22] <seb128> _COMM?
[08:22] <larsu> it even completes "_COMM" and "nautilus" if you have log entries with that
[08:23] <larsu> that's the executable name
[08:23] <larsu> like /proc/self/comm
[08:23] <larsu> _CMDLINE works as well
[08:23] <larsu> man systemd.journal-fields
[08:23] <seb128> that's not documented in "journalctl -h"
[08:23] <larsu> the one I mentioned above is linked
[08:24] <seb128> also doesn't work
[08:24] <seb128> also doesn't work
[08:24] <seb128> $ journalctl _COMM=nautilus
[08:24] <seb128> -- Logs begin at lun. 2015-03-02 16:17:32 CET, end at lun. 2015-09-21 10:24:02 C
[08:24] <seb128> avril 30 09:52:05 seb-e6410 audit[15063]: <audit-1400> apparmor="DENIED" operati
[08:24] <seb128> $
[08:24] <larsu> didrocks: is that still not fixe? ^
[08:24] <seb128> "journalctl | grep nautilus" gives lines
[08:25] <didrocks> larsu: it's fixed, not sure why seb128 doesn't have access
[08:25] <larsu> right, probably from gnome-session
[08:25] <larsu> didrocks: yeah it works for me too (I just thought maybe I added myself to the group manually)
[08:25] <didrocks> but sems that it's some other issues he's having
[08:25] <didrocks> as "journalctl | grep nautilus" works for him without sudo
[08:26] <larsu> right
[08:26] <larsu> seb128: nautilus logs in gnome-session for me
[08:26] <didrocks> larsu: but yeah, of course, _COMM=nautilus won't work, as they all come from gnome-session for now
[08:26] <seb128> larsu, anyway, not wanting to start a debate. journalctl is power and fine if you are an elite user, standalone logs were easier for normal users :-/
[08:26] <larsu> seb128: "normal" users don't exist
[08:26] <seb128> me
[08:27] <seb128> if you prefer :p
[08:27] <larsu> people who want logs without knowing tools should use gnome-logs
[08:27] <larsu> seb128: you know sed, grep, etc
[08:27] <didrocks> +1
[08:27] <seb128> like I would never have guessed that _COMM=
[08:27] <larsu> this is the command line, it needs learning
[08:27] <seb128> that's not even documented in -h
[08:27] <larsu> yes, it is
[08:27] <seb128> not here
[08:27] <seb128> $ journalctl -h | grep COM
[08:27] <seb128> seb128@seb-e6410:~$
[08:27] <seb128> $
[08:28] <larsu> the manual clearly states that you can match on fields, and fields are described in systemd.journal-fields
[08:28] <larsu> journalctl itself only has a few switches for often-used matching
[08:28] <larsu> but is mainly a viewer tool
[08:28] <seb128> filtering one app isn't "often-used"?
[08:28] <larsu> grep doesn't tell you how to grep for logs in .cache/upstart either
[08:28] <larsu> seb128: no
[08:29] <seb128> shrug
[08:29] <larsu> filtering by unit, yes
[08:29] <seb128> yeah, with standalone logs you could just browse the dir in nautilus and double click on a log and get gedit to read it
[08:29] <larsu> which we will have if we get it into the session
[08:29] <larsu> seb128: I need to know the dir, though
[08:29] <larsu> and it's all over the place!
[08:29] <larsu> /var/log/messages for system things
[08:29] <larsu> and *some* session things
[08:30] <larsu> ~/.cache/upstart/* for other session things
[08:30] <larsu> it's just that we're used to that
[08:30] <seb128> at one point we had pretty much everything from the session in there
[08:30] <larsu> "pretty much"
[08:30] <seb128> well, I would say everything
[08:30] <seb128> but maybe there is one thing I don't know about which was missing :p
[08:31] <seb128> the reverse is true today
[08:31] <larsu> let's make upstart log to syslog (or the journal directly) and we have everything in one place
[08:31] <seb128> indicator logs are not in the journal
[08:31] <willcooke> hikiko, meeting time
[08:31] <willcooke> seb128, do you want in?  No obligation
[08:31] <didrocks> well, we still had some "weird" things, like some info being in gnome-session logs and other directly in its own file
[08:31] <larsu> seb128: because they're upstart jobs
[08:31] <didrocks> (and that's as long as gnome-session will spawn some parts of the desktop…)
[08:31] <seb128> willcooke, I might just listen in and maybe do a comment or two
[08:31] <willcooke> seb128, cool
[08:32] <seb128> larsu, anyway, sorry I didn't want to enter in an argument, journalctl is probably the way to go, it's just that today using it is mostly frustration
[08:32] <seb128> if we want to resolve that we have some work to do
[08:32] <hikiko> willcooke, which channel?
[08:33] <seb128> like we should maybe install gnome-logs
[08:33] <seb128> and work on making things all use it
[08:33] <seb128> atm we have no graphical tool preinstalled
[08:34] <larsu> I know
[08:34] <seb128> and logs are not all in it
[08:34] <larsu> I suggested that some time ago already
[08:34] <seb128> so from an user perspective it's really suboptimal
[08:34] <seb128> which is all I was saying
[08:34] <larsu> seb128: and you were totally right of course :)
[08:34] <larsu> sorry, didn't want to start a big debate either
[08:34] <seb128> previous cycle you said to wait a bit for gnome-logs I think?
[08:34] <seb128> we should maybe switch gnome-system-log for gnome-logs
[08:34] <larsu> ya
[08:35] <larsu> I agree
[08:35] <seb128> unsure if we should do a ffe or wait next cycle?
[08:35] <Laney> wait
[08:35] <larsu> wait
[08:35] <Laney> HAMMER TIME
[08:35] <Laney> (not quite)
[08:35] <Laney> (but close enough)
[08:35] <larsu> :)
[08:36] <Laney> man
[08:36] <Laney> eog's fullscreen is bad
[08:36] <Laney> at least some of that is our fault
[08:36] <larsu> hm? I thought I fixed that with the latest theme changes
[08:36]  * larsu wonders if they landed
[08:36] <seb128> did we land the theming fixes for the previous/next buttons?
[08:36] <Laney> you didn't fix the headerbar not hiding
[08:37] <seb128> they are still not looking right here
[08:37] <Laney> and there is a weird transparent toolbar which appears on mouse activity
[08:37] <Laney> and has huge buttons on hidpi :(
[08:37] <larsu> :/
[08:37]  * larsu has another look
[08:37] <seb128> https://code.launchpad.net/~larsu/ubuntu-themes/eog-overlay-buttons/+merge/269482
[08:37] <seb128> needs to land
[08:38] <larsu> I hate that I have to keep track of landing
[08:38] <larsu> I think I've mentioned this before... :)
[08:38] <seb128> yeah
[08:38] <Laney> yeah...
[08:38] <seb128> well you don't really, not more than before
[08:38] <seb128> we always had somebody who needed to make a landing in the distro
[08:38] <seb128> even when fixes were autocommited to the vcs
[08:40] <Laney> didn't daily landing upload automatically?
[08:40] <Laney> larsu: http://people.canonical.com/~laney/weird-things/eog.png for reference
[08:40] <Laney> ignore the image inside eog ;-)
[08:41] <seb128> I don't remember now, but I like better having the maintainer saying "now is a good time for landing"
[08:41] <seb128> it's just annoying that this is just not a click away
[08:41] <didrocks> daily landing were uploading automatically, if the packages had enough tests and its tests was passing (and the stacks he was depending on still had their tests passing)
[08:41] <Laney> it has good features
[08:42] <Laney> I probably miss an overview and an easy way to make an upload with all approved things
[08:42] <Laney> being pinged with "erm, that approved branch has been there for a week, did you miss it?" would be nice
[08:42] <Laney> but would be nice is not the same as doing the work
[08:42] <Laney> so /me shuts up
[08:42] <larsu> yes all the indicators landed automatically
[08:43] <larsu> I kind of see seb128's point, though
[08:43] <didrocks> larsu: TBH, I was still looking daily at the status, when things got blocked and so on
[08:43] <larsu> but where upstream==downstream this was a harder disitnction
[08:43] <didrocks> larsu: so it was automatic to you, I was still looking after :p
[08:43] <seb128> at the end of the day you need a maintainer/somebody looking at logs, migrations, bugs, etc
[08:43] <larsu> hehe
[08:43] <Laney> what you're saying is that you want to start looking at all outstanding MPs?
[08:43] <larsu> fair enough
[08:43] <Laney> pick this work up again
[08:43] <seb128> the issue atm with ubuntu-themes is that nobody maintains it
[08:43] <Laney> thanks didrocks!
[08:44] <didrocks> Laney: I meant, that's what I did in a large enough feature set to me :p
[08:44] <larsu> seb128: Trevinho touched it last!
[08:44] <didrocks> Laney: and no, no more! :)
[08:44] <seb128> :-)
[08:46] <larsu> Laney: wow, that is ugly
[08:46] <larsu> and my branch doesn't fix it
[08:46] <larsu> I think this is not only theming :/
[08:46] <larsu> also need to hide the headerbar in full screen
[08:46] <Laney> yeah
[08:46] <Laney> I can look at that part
[08:47] <Laney> if you have ideas about that toolbar
[08:48] <larsu> is that upstream?
[08:48] <Laney> which?
[08:49] <larsu> that weird toolbar
[08:49] <Laney> yeah we only have patches for titlebars and stuff
[08:52] <larsu> weird, it's really not very gnome3y
[08:53] <larsu> ah, changed slightly in 3.18 (symbolic icons now)
[08:58] <hikiko> willcooke, I think that for compiz we can automatically close the bugs that are for "mate" "gnome" "kde" "metacity"
[08:59] <willcooke> hikiko, I wonder if we could reassign them to the general project
[08:59] <hikiko> if they have these keywords on title, description, tags and not the word "unity"
[08:59] <hikiko> willcooke, maybe we should use this list:
[08:59] <didrocks> I don't think it will be nice to close mate bugs, but rather involve the mate community to triage those?
[09:00] <hikiko> https://bugs.launchpad.net/ubuntu/+source/compiz
[09:00] <hikiko> compiz ubuntu
[09:00] <hikiko> and remove the bugs from here
[09:00] <hikiko> while we leave them in the Compiz project
[09:00] <willcooke> ah, right
[09:00] <Trevinho> willcooke: looking at http://reqorts.qa.ubuntu.com/qapkgstatus/unity it only shows stats for a month or so, so if we want longer infos we should download from time to time the source XML.... However unfortunately the link is dead
[09:01] <hikiko> so the mate etc communities can still fix them
[09:01] <didrocks> hikiko: people will still reopen bugs against the compiz (ubuntu) project. If you only want one list, you should either tear down the upstream project, either use something like unify to keep the status in sync
[09:02] <willcooke> hey jibel, can you advise us?  This page: http://reqorts.qa.ubuntu.com/qapkgstatus/unity has a link to download an XML file:   http://qa.ubuntu.com/reports/pkg-stats/unity.xml
[09:02] <willcooke> jibel, but that xml file link redirects here:  http://community.ubuntu.com/contribute/quality/
[09:09] <hikiko> didrocks, what is unify? you are right
[09:10] <didrocks> hikiko: some script that generates reports and sync upstream/downstream bug status (that was written for unity & associated components)
[09:10] <didrocks> hikiko: it's not a straight up sync as there is a difference if you "fix released" upstream and not downstream
[09:10] <didrocks> (as the package isn't uploaded yet)
[09:11] <didrocks> hikiko: this is the link I gave to willcooke: https://launchpad.net/unify
[09:11] <hikiko> oh that script :)
[09:12] <didrocks> yep
[09:12] <didrocks> well, there are 2 scripts: one giving some webpages for the design team in particular
[09:12] <hikiko> the only problem is that I don't know python :)
[09:12] <didrocks> and the rest being the "sync bugs"
[09:12] <didrocks> well, I offered many times to willcooke to help here :p
[09:12] <didrocks> seems like there is no interest so…
[09:13] <hikiko> so how it works? I modify the compiz ubuntu  bug list let's say manually at first
[09:13] <hikiko> because I mark a bug that no longer affects ubuntu
[09:13] <didrocks> hikiko: it's taking the "most advanced" status
[09:13] <hikiko> and then?
[09:13] <didrocks> and then, ensuring that the compiz ubuntu/compiz upstream reflects the same status
[09:14] <didrocks> some difference is that "fix released" upstream would be translated to "fix committed" in the ubuntu stack
[09:14] <didrocks> (as we don't know if the fix hit the distro yet)
[09:14] <didrocks> there is some mode to force the real sync
[09:14] <didrocks> and also, you can add a third project "distro priority" to track a priority list
[09:15] <didrocks> that then is reflected to a (minimal) website
[09:15] <didrocks> component per component
[09:15] <didrocks> (but we can remove that part if that's of no interest for your case)
[09:17] <hikiko> didrocks, that's very good but I don't know if it would help me to reduce the number of bugs, ideally, I'd like to have a list of bugs that concern us (unity desktop related) and leave the mate, gnome etc bugs in the compiz list
[09:18] <hikiko> willcooke, suggested I write a wiki post
[09:18] <hikiko> and explain which type of bugs we ll support
[09:18] <didrocks> the only thing is that doing that manually is going to be long though
[09:19] <hikiko> well, willcooke will use his script
[09:19] <hikiko> I'll just make a 2nd pass
[09:19] <didrocks> as lon as you don't close the mate bugs (I don't think gnome ever cared about compiz), I think think we'll be fine
[09:19] <hikiko> you mean don't close them even in compiz(ubuntu)? or don't close them in Compiz
[09:20] <didrocks> don't close them even in compiz(ubuntu)
[09:21] <hikiko> ok! I won't :)
[09:21] <didrocks> because they are valid, they are bugs for mate in ubuntu in compiz
[09:21] <didrocks> (and they will reopen more)
[09:21] <hikiko> I see
[09:23] <hikiko> yep, mate uses the C++ compiz and I think that mate bugs are easier because they are "surely compiz" bugs :) (sometime people report bugs in compiz but the problem is on unity, at least with mate we know for sure that the bug is in compiz :p)
[09:24] <hikiko> I just thought that compiz (ubuntu) was for the default ubuntu desktop (unity)
[09:24] <didrocks> no, it's the compiz package in ubuntu
[09:25] <didrocks> but yeah, you should have also a lot of even non compiz/unity bugs reflected there, I remember when everyone was blaming unity for whatsoever :)
[09:25] <didrocks> like "nautilus don't have new panes dialog -> unity" :p
[09:25] <hikiko> yep hahaha
[09:26] <hikiko> my favorite bug was one for vlc that couldn't run fullscreen on unity desktop because the panel was always seen on top
[09:26] <hikiko> the person who reported it had maximized the vlc (didn't run it fullscreen)
[09:26] <didrocks> ahah
[10:22] <darkxst> hey desktopers
[10:26] <didrocks> hey darkxst, how are things?
[10:27] <darkxst> didrocks, good, spent the weekend down in melbourne, house warming party and mountain biking :)
[10:27] <didrocks> nice! :)
[10:29] <darkxst> warming up as well, nice spring weather
[10:30] <seb128> hey darkxst
[10:30] <darkxst> hey seb128
[10:32] <darkxst> I fixed (reverted schemas on ppa) the gedit crash last week, just forgot to update bug status
[10:33] <seb128> great
[10:43] <larsu> Laney: I'll look into the eog thing after lunch. Do you want to do the toolbar thing?
[10:43] <Laney> ya
[10:43] <Laney> I'll just push it to bzr & wait for your stuff before uploading
[10:43] <larsu> ok cool
[10:44] <larsu> I don't think it will be much
[10:44] <larsu> probably just set the bg
[10:45] <Laney> what about the big icons on hidpi?
[10:45] <larsu> right :/
[10:46] <Laney> icon theme?
[10:46] <larsu> ye
[10:46] <larsu> yes
[10:46] <Laney> :|
[12:23] <Laney> xnox: want to check https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/1497177?
[12:23] <Laney> willcooke: did you ask for the user interface freeze exception?
[12:25] <willcooke> Laney, ah, yes. I asked on IRC but got no response and gunnar hasn't been around to ask directly.
[12:25] <willcooke> Any suggestions?
[12:26] <xnox> Laney: willcooke: i'm gonna send a ruler and origami to Blue fin.
[12:26] <willcooke> xnox, I know!  I spoke to them about it and they said...
[12:26] <Laney> https://lists.ubuntu.com/mailman/listinfo/ubuntu-doc <- that list
[12:26] <willcooke> oh, it's in an email somewhere, but basically it couldn't be fixed
[12:27] <xnox> willcooke: "...do you like me? do you think I'm pretty?" OhAh I think I found a cheerleader.
[12:27] <willcooke> maybe digitalalex can try again. I will keep an eye out
[12:27] <xnox> willcooke: they fixed it last time, as all of these blends are calculated, and they can simply move the viewport.
[12:27] <xnox> mpt: it would seem to me, that origami centre fold, is not in the centre again =(
[12:28] <xnox> willcooke: it's better than before, only a few pixels, rather than tens of pixels like last time around.
[12:28] <willcooke> xnox, yeah, but still jarring
[12:29] <willcooke> bah, no johnlea either
[12:32] <willcooke> hey digitalalex
[12:33] <digitalalex> hello
[12:33] <willcooke> digitalalex, regarding the alignment of the wallpaper and the "dots".  Last time you were able to adjust the image view port so that the folds etc were lined up just right.  Can you try that same process again with the new 15.10 wallpaper?
[12:34] <digitalalex> I have already
[12:34] <digitalalex> the files I have sent do match the view point
[12:34] <digitalalex> I will double check just in case
[12:35] <willcooke> digitalalex, thanks.  I don't know if that photo I sent you is clear enough, but it looks like we're off by a few pixels
[12:35] <digitalalex> ok no problem will look into in
[12:36] <willcooke> digitalalex, thanks.  I am in the process of filing a UI freeze exception.  So I will hold on that until you've had a chance to check.  But I want to get the OK to upload asap, so please let me  know your findings as soon as you can
[12:40] <xnox> digitalalex: there could be a lightdm regression, where the dots themself are not centred property. I will double check everything on wily, once i'm back at wily machine in the evening.
[12:40] <xnox> was testing on vivid at the moment.
[12:41] <willcooke> xnox, I have tested on W.  I'll try and get a better picture...
[12:42] <xnox> willcooke: dual screen lightdm, with no focus on the other screen?
[12:42] <xnox> willcooke: there will be ubuntu circle of friends in the centre / not in the centre of the background.
[12:44] <willcooke> xnox, this is just a single screen
[12:46] <xnox> hm, i should ask rick to buy you and/or designers a dual screen setup.
[12:48] <digitalalex> this was my email to willcooke in regards to the dots No sure if is even possible to line up the dots with the lines. Since screens have different dimensions and resolutions.
[12:48] <digitalalex> The background is independent from the dots. Also they will go out of any alignment depending on what system settings you have i.e. fill, zoom, center, scale, etc.
[12:49] <digitalalex> I have checked and the viewpoint alignment is correct
[13:23] <seb128> Laney, that eog/menu issue, the user seems to have a point. there should be an appmenu, atm there is no way to open e.g the preferences
[13:23] <seb128> disable-appmenu-when-not-needed.patch seems like it shouldn' tbe there if we don't have a menubar anymore
[13:23] <seb128> "Description: Disables the application menu on platforms that show an app menu
[13:23] <seb128>   and a menubar (such as unity). The menubar already contains all the actions of
[13:23] <seb128>   the appmenu. Having both is redundant."
[13:24] <Laney> he came back with a different point
[13:24] <Laney> feel free to drop it
[13:24] <Laney> then we get a weird double thing but better than nothing
[13:24] <seb128> double thing?
[13:25] <Laney> Image Viewer Image Viewer
[13:25] <seb128> ah
[13:25] <seb128> hum
[13:25] <seb128> what are the other options?
[13:25] <Laney> bring back a menu bar
[13:25] <Laney> put the missing options in the app menu
[13:25] <Laney> burger menu
[13:25] <Laney> whatever that thing is called
[13:26] <seb128> right
[13:26] <seb128> if it was just a matter of deciding I would say the menubar is best
[13:26] <seb128> unsure how much work that is though
[13:26] <seb128> larsu, ^ do you know?
[13:28] <seb128> we have a few things doing the "Title Title"
[13:29] <seb128> e.g gnome-disks d-feet baobab dconf-editor
[13:29] <Laney> I wonder if Unity could handle the appmenu
[13:29] <seb128> the gnome games
[13:29] <seb128> handle it how?
[13:30] <Laney> just show one name
[13:30] <Laney> with a triangle if there's a menu
[13:30] <Laney> or something
[13:30] <seb128> willcooke, Trevinho, ^ do you think that's something we should look at for the LTS?
[13:31] <Laney> I suppose we still prefer to have real menus
[13:31] <Laney> but in the absence of this
[13:31] <Laney> be good to look better if possible
[13:31] <Trevinho> Mh could be...
[13:31] <seb128> right, but as I said, we already have a stack of apps doing that
[13:31]  * willcooke reads
[13:31] <Trevinho> But triangle where?
[13:32] <seb128> willcooke, the gnome apps which have an appmenu only lead to unity panel showing "Title Title" where the first one is the app name and the second the menu
[13:32] <seb128> willcooke, try "disks" as an example
[13:32] <seb128> willcooke, that looks a bit lame
[13:33] <Trevinho> Ah.... I see
[13:33] <willcooke> ahh
[13:33] <Trevinho> So... Mh, well decorations are pretty editable nowadays so I guess we can do that
[13:33] <willcooke> I see what Laney means with the Triangle now
[13:34] <Laney> it's weird though
[13:34] <Laney> when maximised the title moves when you put your mouse up there
[13:35] <Laney> and when not then it changes font weight
[13:35] <seb128> yeah, I think we discussed that in the past and we didn't really an elegant solution
[13:35] <Laney> (with LIM)
[13:35] <Laney> so I don't know how to design it properly in short
[13:36] <willcooke> seb128, can you add the topic to: https://blueprints.launchpad.net/ubuntu/+spec/desktop-1604-planning-sprint
[13:36] <Laney> Maybe for eog we can add the menubar back
[13:36] <Laney> it seems to have GActions for stuff in the code
[13:36] <Laney> larsu has done similar before
[13:37] <seb128> willcooke, done
[13:37] <seb128> Laney, that would be good
[13:37] <seb128> also we need to resolve the issue that the popdown menus are not pushed to the hud
[13:37] <seb128> well, for the LTS we should fix that
[13:38] <mhall119> willcooke: ping
[13:38] <seb128> willcooke, give him a contentless ping warning!
[13:38] <seb128> :-)
[13:38] <mhall119> :-P
[13:38] <willcooke> mhall119, otp
[13:38] <mhall119> if I gave context to my pings, nobody would ever reply
[13:38] <seb128> lol
[13:39] <willcooke> mhall119, can type, but expect delays
[13:40] <willcooke> seb128, re: blueprint - thanls
[13:40] <willcooke> thanks
[13:40] <mhall119> willcooke: if you can jump into #ubuntu-app-devel when you can, it seems the ubuntu-ui-toolkit is broken on wily due to the gcc upgrade, and bzoltan's team needs help figuring out how to fix it
[13:44] <Laney> This seems inefficient (going via the manager), you probably want to just ask one of us first
[13:44] <willcooke> what laney said
[13:44] <willcooke> :)
[13:47] <seb128> especially that several of us are on this channel
[13:48] <seb128> mhall119, installing "ubuntu-sdk" works fine on my wily system
[14:03] <Trevinho> wow I didn't think that flying direct from florence to london was soo expensive (i generally use ryanair, but that's not in my city, I've to go to Pisa... And there's 1hr bus) :o
[14:03] <seb128> Trevinho, how much is it?
[14:04] <Trevinho> well, on those days it reaches 400€
[14:05] <Laney> O_O
[14:05] <Trevinho> 393 to LCY (that would be actually very convinient)... or 400 with vueling
[14:05] <Trevinho> that's not how it generally is, but those days seems to be very expensive
[14:06] <Trevinho> flying in weekdays it would be 200€ less...
[14:07] <Trevinho> with one connection it would be 300€, but > 4hrs
[14:09] <seb128> is gvfs spamming syslog for others as well on wily?
[14:10] <Laney> nope
[14:11] <seb128> Laney, what if you plug a phone to your computer?
[14:11] <seb128> Sep 21 10:39:02 localhost org.gtk.vfs.Daemon[1817]: dc05: Association Type UINT16 data type ANY 16BIT VALUE form READ ONLY
[14:11] <seb128> Sep 21 10:39:02 localhost org.gtk.vfs.Daemon[1817]: dc06: Association Desc UINT32 data type ANY 32BIT VALUE form READ ONLY
[14:11] <seb128> Sep 21 10:39:02 localhost org.gtk.vfs.Daemon[1817]: dc03: Protection Status UINT16 data type ANY 16BIT VALUE form READ ONLY
[14:11] <seb128> Sep 21 10:39:02 localhost org.gtk.vfs.Daemon[1817]: Storage Devices:
[14:11] <seb128> Sep 21 10:39:02 localhost org.gtk.vfs.Daemon[1817]: StorageID: 0x00000003
[14:11] <larsu> Laney, seb128: sorry, lunch was longer than expected. Can you summarize? (seems like a lot of discussion was going on...)
[14:12] <seb128> larsu, currently on wily there is no way to access the eog appmenu, so no way to open preferences and toggle some of the options
[14:12] <seb128> larsu, we were discussing how to fix that, one way is to add a menubar back
[14:12] <seb128> not sure how much work that would be though
[14:12] <larsu> seb128: oh indeed
[14:12] <larsu> seb128: not a lot if it already uses GAction
[14:13] <larsu> just drop in another .xml file
[14:13] <seb128> larsu, is that something you can look at?
[14:13] <larsu> sure
[14:13] <seb128> danke
[14:13] <Laney> eogday
[14:13] <Laney> the best kind of day
[14:13] <seb128> hehe
[14:13] <larsu> Laney: :)
[14:13] <seb128> so I wonder why gvfs is only spammy for me
[14:15] <seb128> Laney, can you try to connect a phone or camera and see if that makes any difference?
[14:16] <Laney> ok, need to charge it though
[14:16] <seb128> thanks
[14:16] <Laney> my normal phone has a partially broken usb port
[14:16] <Laney> so it connects/disconnects constnatly
[14:16] <Laney> annoying
[14:17] <seb128> that should be enough to see if syslog get noise when the system first see the phone
[14:18] <Laney> nothing like that
[14:18] <seb128> k, thanks, I'm going to investigate more then
[14:32] <larsu> Trevinho: did anything change in unity-panel-service recently? It shows smaller fonts than the rest of the desktop for me as of a week ago or so
[14:32] <Trevinho> larsu: no
[14:32] <larsu> weird
[14:32]  * larsu wonders what's going on
[14:32] <Trevinho> larsu: nothing in the past weeks I think
[14:33] <larsu> desrt: got some time to have a look at the geonames stuff?
[14:33] <desrt> sure
[14:34] <larsu> desrt: cool. An api review is what I care about most right now: https://git.launchpad.net/geonames
[14:34] <larsu> no index yet (it's fast enough - let's see how it handles on a phone)
[14:35] <desrt> cute flags field
[14:35] <desrt> what do you have in mind?
[14:35] <larsu> online
[14:35] <desrt> ah
[14:36] <desrt> return the pointer from _finish
[14:36] <desrt> make it gint, and -1 terminate it
[14:36] <desrt> ie: always non-NULL
[14:36] <larsu> hm...
[14:36] <larsu> I was actually thinking of returning the objects directly
[14:36] <larsu> I forgot why you suggested the index-thing in the first place...
[14:37] <desrt> because of the whole nasty "free the array of objects" thing
[14:37] <desrt> also because of how easy it would be to use the index to build a model
[14:37] <larsu> yeah, true
[14:37] <larsu> -1 terminating it is a good idea, thanks
[14:37] <larsu> but keep the *length, no?
[14:37] <desrt> yes.  of course.
[14:38] <desrt> are the results guaranteed to be sorted?
[14:38] <desrt> (read: "i don't see any docs")
[14:38] <larsu> I sort them by quality of match and population of the city right now
[14:38] <desrt> interesting
[14:38] <larsu> docs are of course coming as well
[14:38] <desrt> that's fair
[14:39] <larsu> there's lots of San Franciscos, for example
[14:39] <desrt> i'd call the function _async and/or add a _sync variant
[14:39] <larsu> most with <10k people
[14:39] <larsu> why?
[14:39] <desrt> is population in the DB?
[14:39] <larsu> yes
[14:39] <desrt> _sync could be useful for tools
[14:39] <desrt> or for people who have their own worker threads
[14:39] <larsu> fair enough
[14:39] <desrt> and it looks like you basically have the sync version inside anyway
[14:39] <larsu> I do
[14:40] <larsu> and I could then also use the lib directly from tests
[14:40] <desrt> ensure_geonames_data () <- bad C99
[14:40] <larsu> hm? you mean (void)?
[14:40] <desrt> yes.  of course.
[14:41] <larsu> indeed
[14:41] <desrt> if you're going to allow a call to geonames_get_city() without first calling query() then you should also have a getter for the number of cities
[14:41] <desrt> or you should allow _get_cities() to return NULL if index > N
[14:42] <desrt> i base this on the ensure() call at the top of _get_cities() causing me to think that you expect this to happen without a call to query() first
[14:42] <larsu> indeed
[14:42] <larsu> I don't, really
[14:42] <larsu> but why not
[14:42] <czajkowski> if you're filing a bug against trusty - date/time drop down, what's the application I should chose ?
[14:42] <desrt>   g_variant_get_child (city, 1, "&s", &state); <- this is technically evil
[14:42] <larsu> I know that I have a ref to the surrounding variant...
[14:42] <desrt> i'm surprised it doesn't complain at you about this, in fact
[14:43] <seb128> czajkowski, which one? installer? unity settings?
[14:43] <czajkowski> seb128: on the desktop so unity.
[14:43] <desrt> larsu: you also need to know that it's serialised
[14:43] <czajkowski> cannot change my time and I'm -8 hrs from my local setting so it's confusing ,me :)
[14:43] <seb128> czajkowski, unity -control-center likely
[14:43] <czajkowski> seb128: thanks
[14:43] <seb128> czajkowski, what happens when you try to change it?
[14:43] <larsu> desrt: it is when I load it from data, no?
[14:44] <larsu> or shall I make sure? (can I even?)
[14:44] <czajkowski> seb128: nothing I click on the date/time and it doesn't pop out like it should to change
[14:44] <desrt> there is a bug in g_variant_get_child()
[14:44] <seb128> czajkowski, can you click on the map?
[14:44] <desrt> i should fix that
[14:45] <seb128> czajkowski, now I'm confused, are you speaking about the settings app? you can't open the panel?
[14:45] <czajkowski> seb128: the map doesnt even pop out. I click on the word date/time from the drop down and nothing happens.
[14:45] <seb128> czajkowski, what dropdown?
[14:45] <seb128> czajkowski, can you make a screenshot?
[14:46] <larsu> desrt: hm, there's no way to know from the outside if a gvariant is serializeD?
[14:46] <czajkowski> seb128: if you click on the time /date  up on the right of my screen where all the settings are, not sure it has a special name then click on the date/time words it used to pop out the big map to change
[14:46] <desrt> larsu: i don't think so
[14:46] <seb128> czajkowski, are you speaking about the indicator?
[14:47] <seb128> czajkowski, that never has a map, the map was in old gnome2/gnome-panel time
[14:47] <desrt> larsu: the correct fix is in gvariant.  we do the same thing for other getters
[14:47] <larsu> desrt: so I technically have to make a copy even though I'm sure I can get a pointer to a const gchar * ?
[14:47] <desrt> i just missed get_child() its eems
[14:47] <larsu> hm?
[14:47] <seb128> czajkowski, you mean http://i.stack.imgur.com/mswzC.png
[14:47] <czajkowski> seb128: yes
[14:47] <czajkowski> sorry forthe confusion :(
[14:47] <desrt> larsu: the trouble is if you have a tree-form gvariant (ssss) and get a pointer to one of the strings, and then later call something on the tuple that causes it to be serialised, the string will be freed
[14:48] <seb128> czajkowski, that would be indicator-datetime then, can you pasebin ~/.cache/upstart/indicator-datetime.log ?
[14:48] <desrt> whereas the normal rule with the gvariant API is that internal pointers remain valid as long as the instance that you used to fetch them from still exists
[14:48] <seb128> czajkowski, is "indicator-datetime-service" running?
[14:48] <larsu> desrt: why would this variant ever be in tree form?
[14:48] <czajkowski> seb128: I'll check and come back tanks
[14:48] <czajkowski> stand up and running to meeting
[14:48] <desrt> larsu: in your case, it would never be
[14:48] <seb128> czajkowski, k
[14:48] <czajkowski> appreciate the help
[14:48] <larsu> desrt: if I make copies, I might as well make the whole GeonamesCity thing a proper gobject
[14:49] <desrt> larsu: i'm not telling you to make copies
[14:49] <desrt> i'm just saying that there is a theoretical problem here that doesn't impact your usecase and i'm the one that needs to make a change to gvariant
[14:49] <desrt> ie: if i find a '&' in the format string i need to force-flatten the variant before proceeding
[14:50] <desrt> it's funny because this will already happen in any case, but it will happen to the child, which is useless
[14:50] <desrt> it needs to happen to the parent
[14:50] <larsu> oh, interesting
[14:51] <seb128> those of you on hidpi screen, is your appearance panel having its previews too small like on https://launchpadlibrarian.net/213196769/ChangeDesktopBackgroundHiDPI.png ?
[14:52] <larsu> seb128: correct for me when running with GDK_SCALE=2
[14:52] <seb128> larsu, yeah, I tried that way as well, see my comment on https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1480128
[14:53] <seb128> sorry didn't give the bug number before
[14:53] <larsu> ah ok
[14:53] <seb128> unsure what is different in his case
[14:53] <larsu> desrt: btw, geonames has alternate names with language info ... thinking about generating .po files from that...
[14:53] <seb128> larsu, thanks for testing
[14:54] <larsu> seb128: weird. let me try with setting the unity scale factor as well
[14:54] <seb128> larsu, he's on 14.04 so maybe it's fixed since, I asked on the bug
[14:55] <larsu> seb128: ya, works as well. probably has been fixed
[14:55] <seb128> larsu, danke
[14:55] <larsu> man, we need to make our theme draw everything manually instead of using .pngs
[14:55] <desrt> larsu: interesting idea
[14:55] <larsu> it's a bit blurry on hidpi
[14:55] <desrt> larsu: i guess the .po files will not be compressed, though
[14:56] <desrt> also, even if they were, the act of splitting them out would be very bad from the redundancy standpoint
[14:56] <desrt> since the source language string would appear over and over and over again
[14:56] <larsu> why?
[14:56] <larsu> but you'd only install the languages you're interested in...
[14:57] <desrt> sure... if you langpack it, that might be interesting
[14:57] <larsu> how else?
[14:57] <desrt> i dunno.  i thought you'd just install all the .po files :)
[14:57] <larsu> I don't know how all of this machinery is working, but this is a good excuse to find out
[14:57] <larsu> and seb128 will be able to type "Londres"
[14:57] <desrt> you could also skip gettext and use a homebrew
[14:57] <larsu> but then I'd always install all the languages, no?
[14:58] <desrt> not necessarily.  nothing stops you from langpacking your homebrew
[14:58] <desrt> the trouble with gettext is that you're going to need to find some weird way to do context
[14:58] <desrt> and it's more or less going to come down to encoding the index in the gettext string
[14:58] <larsu> context?
[14:58] <desrt> ie: to deal with the 100 "San Francisco"s
[14:58] <desrt> maybe this city name is not always translated in the same way
[14:58] <desrt> depending on which one...
[14:59] <larsu> ah, just put the country into the comment
[14:59] <desrt> the context, you mean
[14:59] <larsu> yes
[14:59] <desrt> but why bother when you could just store the langpack file as a separate GVariant
[14:59] <desrt> an array, using exactly the same index numbers as the original
[15:00] <larsu> hm, indeed
[15:00] <desrt> this is more efficient, less redundant, and avoids the context/ambiguity issue
[15:00] <larsu> if I can install langpacks that are not gettext just as easily, why not
[15:01] <larsu> where is this stuff documented?
[15:01] <desrt> no idea
[15:01] <larsu> Laney or seb128 probably know
[15:01] <desrt> but one nice hack: use the empty string for "same as C"
[15:01] <desrt> this will save you a _lot_ of space
[15:01] <larsu> it's compressed anyway ;)
[15:01] <larsu> (but yeah, even in memory)
[15:02] <desrt> well, even with compression
[15:02] <larsu> I assume most cities will have the same name
[15:02] <desrt> better to reduce the amount of data to compress
[15:02] <seb128> larsu, langpacks do po and help atm, but you can add depends on other binaries like we do for dictionnaries and such
[15:02] <desrt> the cool thing about the language splitout is that you can now do locale-specific transliterations for the search tokens
[15:02] <larsu> seb128: interesting. Can you point me to some docs on how I add this to my package?
[15:03] <larsu> desrt: turkish!
[15:03] <desrt> fucking turkish
[15:03] <desrt> >:|
[15:03] <desrt> İ hate ıt so much
[15:03] <seb128> larsu, "this"? what are you trying to split?
[15:03] <larsu> desrt: you meant >:İ, right?
[15:04] <larsu> seb128: just langpacks in general
[15:04] <larsu> seb128: never did anything in that area
[15:04] <desrt> seb128: he wants to produce a series of binary files with names like /usr/share/geonames/locale/{fr,de,zh_CN,...} and have those put in langpacks, accordingly
[15:04] <seb128> larsu, I'm not sure to understand the question
[15:04] <seb128> desrt, oh, ok
[15:04] <desrt> seb128: so what does he have to do to get the langpack packages to pick that up from his package?
[15:04] <seb128> larsu, desrt, I don't think there is an automatic way
[15:05] <larsu> seb128: is it a lot of extra work?
[15:05] <seb128> you basically need to build <yourpackage>-<locale> binaries by listing every binary in debian/control and having corresponding .install
[15:05] <seb128> and then you need to patch langpacks to add the depends
[15:05] <desrt> a one-file package?
[15:05] <seb128> like make -fr recommends yourlib-tz-fr
[15:05] <seb128> yes
[15:05] <desrt> times 100+?
[15:05] <desrt> :(
[15:05] <seb128> right
[15:06] <larsu> uh oh
[15:06] <seb128> or talk to pitti about adding support to langpack-o-matic for a new format
[15:06] <desrt> this can't be that hard....
[15:06] <desrt> larsu: btw.. if you're gonna go down this path, you're gonna love g_get_language_names() :)
[15:08] <larsu> desrt: oh neat!
[15:08] <seb128> how bigs are those files?
[15:08] <larsu> desrt: in any case, thanks for the review!
[15:08] <seb128> why not using gettext/normal po/mo?
[15:08] <larsu> this was my first idea
[15:08] <desrt> seb128: gettext will be inefficient and problematic here
[15:08] <larsu> but generating them manually is a bit weird
[15:08] <desrt> since there are many cities around the world with the same names
[15:08] <desrt> and they might not get translated the same way
[15:09] <larsu> well, we could use context for that
[15:09] <desrt> so you end up having to stick context on everything
[15:09] <desrt> and the most obvious thing to use is the index in the DB as the context
[15:09] <desrt> and then since you have a unique ID then you may as well just use the index as the source string rather than as the context
[15:10] <desrt> but now you're using the hash of a stringified-int to do a lookup in something that could just as well be an array
[15:10] <desrt> ...and compressed
[15:10] <desrt> also: once the tokenised search terms are added to the DB, it will get even more awkward to have it in gettext
[15:10] <desrt> and all those hash lookups are going to get expensive during searches
[15:11] <larsu> the other option is to always install all languages
[15:11] <desrt> (since you will have to do _all_ of them, _every_ time since you cannot possibly know what the string is until you fetch it)
[15:11] <desrt> yes.  and put them in the same big file.
[15:11] <desrt> which will help compression due to similarities between the languages
[15:11] <desrt> and will generally simplify things
[15:11] <desrt> but it's probably a lot of data....
[15:11] <desrt> i think you need to get numbers, basically
[15:12] <desrt> but imho gettext is kinda unviable
[15:12] <larsu> uh oh, alternateNames.zip is 104mb
[15:13] <desrt> so there's your numbers :)
[15:13] <larsu> let's see - I think there might be too much stuff inthere
[15:13]  * larsu remembers not to open a 400mb text file with gedit
[15:14]  * desrt is going to eat soylent for lunch
[15:15] <larsu> how is that?
[15:15] <desrt> may god have mercy on my soul
[15:15] <desrt> i have no idea.  someone gave me a pack, semi-randomly
[15:30] <desrt> that wasn't good, but it also wasn't bad
[15:33] <larsu> haha
[15:34] <desrt> i think i'm gonna mix in a bit of cinnamon next time :)
[15:36] <desrt> oh.  great.
[15:36] <desrt> WARNING: This product contains chemicals known to the State of California to cause cancer and birth defects or other reproductive harm.
[15:38] <Laney> larsu: I bet you can have some dh_something put these into the langpacks
[15:39] <Laney> that would be a pitti topic
[15:39] <larsu> desrt: wow...
[15:40] <larsu> Laney: ah thanks. I think he's gone for the day, will pester him tomorrow
[15:40] <larsu> that would clearly be the best solution
[15:50] <Laney> still laughing at #hameron
[15:50] <Laney> oops wrong channel
[15:50] <larsu> hameron?
[15:50] <larsu> now I want to know!
[15:50] <Laney> well...
[15:51] <larsu> is this some british thing?
[15:51] <Laney> someone published a "revenge" biography of David Cameron
[15:51] <Laney> it contains a story about a pig...
[15:53] <larsu> TELL IT!
[16:19] <ogra_> larsu, you dont want to hear it
[16:19] <Laney> I gave him a link in private
[16:19] <Laney> !coc
[16:19] <Laney> :)
[16:20] <ogra_> hahaha, right
[16:21] <larsu> lol
[16:26] <davmor2> Laney: the diyers are going to hater you that is just too close to #hammeron
[16:26] <davmor2> s/hater/hate
[16:35] <czajkowski> seb128: http://pastebin.ubuntu.com/12515250/
[16:36] <seb128> czajkowski, dpkg -l | grep indicator-datetime
[16:38] <czajkowski> seb128: http://pastebin.ubuntu.com/12515275/
[16:39] <seb128> czajkowski, ps aux | grep indicator-datetime?
[16:40] <czajkowski> seb128: http://pastebin.ubuntu.com/12515283/
[16:40] <seb128> czajkowski, and when you click on the indicator you don't get the menu with the calendar?
[16:41] <czajkowski> seb128: no it's really weird
[16:41] <czajkowski> let me sscreen and show you
[16:43] <czajkowski> seb128: https://goo.gl/photos/45Ls1sYj9nzcZ6KL8
[16:43] <seb128> czajkowski, oh, but the menu is displayed
[16:43] <seb128> you have the indicator, calendar, tzs etc
[16:43] <seb128> so what's the issue?
[16:44] <seb128> oh, is that if you select the item at the bottom that it doesn't open settings?
[16:44] <czajkowski> seb128: exactly
[16:44] <czajkowski> clicking on date/time doesnt bring up any dialoge
[16:44] <seb128> czajkowski, dpkg -l | grep control-center
[16:44] <seb128> right
[16:45] <seb128> your indicator log indicates it tries to open gnome-control-center but that's missing
[16:45] <seb128> which suggests you don't have settings installed for some reason
[16:45] <czajkowski> seb128: well they were installed up to the lastest updates last week
[16:45] <czajkowski> http://pastebin.ubuntu.com/12515322/
[16:46] <czajkowski> with the amount of travelling I do it's the first thing I change when I arrive
[16:46] <czajkowski> it's not a bigg and I do appreciate the help
[16:46] <czajkowski> it's just baffling
[16:47] <seb128> czajkowski, rc  unity-control-center                                 15.04.0+15.04.20150410-0ubuntu1            amd64        utilities to configure the GNOME desktop
[16:47] <seb128> that's your issue
[16:47] <seb128> sudo apt-get install unity-control-center
[16:47] <seb128> czajkowski, then you can grep control-center /var/log/dpkg.log to see when they got removed and what else was uninstalled
[16:48] <seb128> Trevinho, open https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1498089 for you, I think it's a side effect of you wily build fix (though I'm unsure what's wrong)
[16:48] <czajkowski> seb128: awww you rock
[16:48] <czajkowski> thank you
[16:48] <seb128> czajkowski, yw!
[16:56] <Trevinho> Laney, seb128: do you know why compiz ddebs for vivid are missing (see https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1470097 )
[16:57] <seb128> Trevinho, no, likely because the ddeb infrastructure is not robust and they didn't get imported for some reason and they get cleaned from the buildds since
[16:58] <seb128> we need a no change rebuild SRU to fix that :-/
[16:58] <seb128> there are plans to get ddebs in launchpad, in fact it's mostly done I think, unsure what's missing
[16:58] <Laney> I think it's more robust now
[16:58] <Laney> but maybe that was after vivid
[16:58] <Trevinho> ouch, annoying...
[16:58] <seb128> weird that nobody noticed until now
[16:58] <seb128> retraces and e.u.c are probably not very useful due to that
[16:58] <Laney> bdmurray used to do uploads to get them back
[16:59] <Laney> don't know how he found missing ones
[16:59] <seb128> through investigating e.u.c failed retraces I think
[17:06] <sethj> so, did the bug scrubbing pick up while I was busy over the weekend?
[17:09] <Laney> bye!
[17:12] <Trevinho> Laney: do you have a bug for that unity branch?
[18:35] <Laney> Trevinho: I looked for one but didn't find
[18:35] <Laney> doesn't mean there isn't
[19:15] <willcooke> g'night
[21:36] <Trevinho> Laney: no worries I opened one
[21:56] <sethj> andyrock, were you able to reproduce this bug? https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1286910 I see you marked it has confirmed. I cannot reproduce it on Wily and was going to mark it invalid but then I saw you touched it recently.