[03:14] <tjaalton> robert_ancell: btw, packages can build-depend on stuff from universe now, so the x11proto that uses fop could've been synced, aiui
[03:14] <robert_ancell> tjaalton, ah, of course
[03:44] <happyaron> ls
[03:44] <happyaron> sorry...
[03:55] <robert_ancell> happyaron, :)
[05:00] <hikiko> Hi
[05:49] <pitti> Trevinho: I downloaded the current and PPA sources and debdiffed that, it's ok; I accepted it last night
[05:49] <pitti> Good morning
[06:07] <seb128> good morning desktopers!
[06:11] <seb128> pitti, thanks for the pkgnostrip flag, but by default universe packages don't have their translations stripped ... is that the X-Ubuntu-Use-Langpack which does that?
[06:11] <pitti> seb128: correct
[06:11] <pitti> seb128: I reviewed/accepted the evo SRU last night
[06:11] <seb128> I saw
[06:12] <seb128> but seems like that didn't work :-/
[06:12] <pitti> err, wut
[06:12] <seb128> the .mo are not included in any deb
[06:13] <seb128> does the parser just look for X-Ubuntu-Use-Langpack and would consider a commented one as being defined?
[06:13] <seb128> I should perhaps have deleted the line...
[06:17] <pitti> pkgstriptranslations:if grep -q 'X[[:alpha:]]*-Ubuntu-Use-Langpack: yes' debian/control; then
[06:17] <pitti> seb128: erk, my bad :/
[06:17] <pitti> should have a ^
[06:18] <seb128> well I guess commented is not that common
[06:18] <pitti> seb128: I'll fix it in pkgbinarymangler now, but I suppose it's easier for this case if you reupload evo
[06:18] <pitti> I can review/accept it right away
[06:19] <seb128> pitti, thanks for poking the security team on libimobiledevice, I was unsure what to do, I added the security patch in yakkety because I looked at git and it seemed a nice one to backport and I decided to try to get in the SRU as well
[06:19] <pitti> seb128: yeah, I don't particularly mind, but I'd at least give them a chance to weigh in
[06:25] <seb128> pitti, evo reuploaded
[06:25] <seb128> on that note I'm done with email backlog, time for coffee ;-)
[06:25] <pitti> seb128: just waiting for diff, will press the button then
[06:25] <seb128> thanks!
[06:26] <pitti> seb128: pkgbinarymangler fix uploaded
[06:26] <pitti> ... for the future
[07:01] <seb128> pitti, nice
[07:03] <seb128> wth :/
[07:03] <seb128> pitti, the .mo are still stripped out :-/
[07:05] <seb128> pitti, also any way you could accept the nm-applet sru? oem team is waiting on one of the fixes, 2 of the 3 bugs are fixed in yakkety and the 3rd one is commit in upstream git/going to be in the point update happyaron is working on
[07:05] <seb128> or I guess I could do a yakkety upload with the 3rd fix if you prefer
[07:05] <seb128> while Aron gets the rebase done
[07:12] <pitti> seb128: WTF
[07:13] <seb128> yeah...
[07:16] <seb128> pitti, sorry, my fault
[07:16] <pitti> seb128: nm-applet> I targetted the yakkety bug to 16.06 now and assigned
[07:16] <seb128> pitti, thanks
[07:16] <pitti> but we don't have a way to enforce that they really get fixed
[07:17] <pitti> if devs forget about it, we have zero pressure on that
[07:17] <seb128> yeah, as said I can do an upload now if you prefer
[07:17] <seb128> it's just that Aron is working on updating to 1.2.2 and including that change
[07:17] <seb128> rebasing the patches just take some time
[07:18] <pitti> it's not that important whether it happens now or in a few days, but it's crucial that it's not being dropped
[07:18] <pitti> so if that's in the pipeline, ok
[07:18] <seb128> right
[07:18] <seb128> I'm going to make sure of that
[07:18] <pitti> thanks
[07:18] <seb128> it's landing this week one way or another
[07:18] <pitti> (accepted)
[07:18] <seb128> thanks!
[07:18] <seb128> pitti, evolution is good, ignore my recent comment
[07:19] <pitti> seb128: oh, you only looked at s390, and that doesn't build a -common package?
[07:19] <seb128> I looked at one of the archs that built first (powerpc) but the translations are in common
[07:19] <seb128> amd64 is still building
[07:19] <pitti> *phew*
[07:19] <seb128> sorry :-)
[07:19] <pitti> so, not "good" yet, but at least not "definitively bad" :)
[07:19] <seb128> ah, build done
[07:20] <seb128> -rw-r--r-- root/root    166711 2016-05-25 07:11 ./usr/share/locale/af/LC_MESSAGES/evolution-3.18.mo
[07:20] <seb128> pitti, good :-)
[07:20]  * pitti ^5s seb128
[07:20]  * seb128 ^5s pitti back
[07:23] <seb128> pitti, can "idVendor" or "idProduct" udev attributes being missing/null for plugged devices?
[07:24] <seb128> the libopenobex segfault which I SRUed the fix for, the command is called by that udev rules
[07:24] <seb128> ACTION=="add", SUBSYSTEM=="usb", PROGRAM="/usr/sbin/obex-check-device $attr{idVendor} $attr{idProduct}", MODE="660", GROUP="plugdev"
[07:24] <seb128> I wonder if it's normal that one of the arguments might go missing
[07:24] <seb128> or if that's another issue to look at
[07:24] <pitti> yes,  for sure
[07:25] <pitti> it should at least be robust against that
[07:25] <pitti> s/for sure/possibly/; sorry, that was about "every usb device in /sys", but the rule is "every usb device in /dev"
[07:26] <pitti> seb128: but that whole rule should go, plugdev is a thing of the past
[07:26] <pitti> or at least use the uaccess tag
[07:26] <seb128> I don't even know what obex-check-device does
[07:27]  * seb128 looks a bit
[07:27] <seb128> just that e.u.c gets quite some report because it segfaulted when called with 1 arg only
[07:27] <pitti> seb128: but I would expect that if the attribute is missing in /sys, it woudl be called with "" ""
[07:27] <pitti> i. e. I thought udev would split args by spaces
[07:27] <pitti> this is not funnelled through a shell
[07:28] <willcooke> o/
[07:28] <pitti> seb128: but having idVendor but not idProduct is indeed odd
[07:28] <pitti> I'd expect both or none
[07:28] <seb128> hey willcooke
[07:28] <pitti> ça va willcooke
[07:28] <seb128> pitti,
[07:28] <seb128> " ProcCmdline: /usr/sbin/obex-check-device 0bda"
[07:29] <seb128> from one of the apport reports
[07:32] <pitti> seb128: interesting, I haven't seen devices which only have a vendor
[07:47] <willcooke> bleh - it's like winter here today.  < 10 degrees
[07:47] <willcooke> raining
[08:03]  * Laney brrrrrrrrrrrrrrr
[08:03] <Laney> cold today
[08:03] <Laney> hello!
[08:03] <pitti> hey Laney
[08:03] <happyaron> hey
[08:03] <seb128> hey Laney happyaron!
[08:06] <Laney> hey seb128 and pitti and happyaron!
[08:06]  * Laney greets you from west to east
[08:06] <Laney> how's it going?
[08:07] <seb128> coldly
[08:07]  * seb128 is pondering putting a sweater on top of the tshirt
[08:10] <Laney> do some star jumps
[08:10] <pitti> I did that ten minutes after sitting down today
[08:10] <Laney> https://launchpadlibrarian.net/261491743/buildlog_ubuntu_yakkety_armhf_ubuntu-touch_BUILDING.txt.gz
[08:10] <Laney> WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! init systemd-sysv (due to init) 0 upgraded, 946 newly installed, 2 to remove and 0 not upgraded. E: Essential packages were removed and -y was used without --allow-remove-essential.
[08:10]  * Laney blinks
[08:11] <pitti> Laney: I dropped upstart-sysv as a supported init in yakkety
[08:11] <pitti> (after discussing with Steve)
[08:11] <pitti> as we won't release any touch products from y
[08:12] <pitti> maybe it's time to switch the touch seeds to systemd-sysv then?
[08:16] <Laney> pitti: That or stop it from building
[08:16] <pitti> at least a year ago or so the phone actually did boot with systemd, and calls/text/3G etc. were all working
[08:16] <seb128> pitti, oh, not sure if you saw on the upower/usd segfault bug, https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/include/linux/usb.h?id=feb26ac31a2a5cb88d86680d9a94916a6343e9e6 seems like the real fix
[08:17] <pitti> just not the upstart jobs in the touch-whatsitsname-i-ship-fifteen-upstart-overrides package
[08:17] <pitti> seb128: I did see that, yes
[08:17] <pitti> seb128: I'd still like to get some feedback from any of the reporters about the patched upower in my PPA, but nothing so far :/
[08:17] <pitti> slightly false info in power indicator >> crashing the whole u-s-d
[08:18] <sarnold> pitti: oh hey that reminds me, what's the deal with the /etc/systemd/system/sshd.service, syslog.service, iscsi.service, etc. symlinks? I thought /etc/systemd/system/ was playground for local admin but .. I've got a lot more things in that directory than I touched
[08:18] <seb128> yeah, nothing new, the u-s-d stack of plugins design :-/
[08:19] <seb128> same, input device being unplugged while configured and your u-s-d is down
[08:19] <pitti> sarnold: /etc/systemd/system/sshd.service is because of Alias=sshd.service in /lib/systemd/system/ssh.service
[08:19] <sarnold> pitti: ah! that seems like a big convenience. :)
[08:20] <pitti> sarnold: i. e. most of that is Aliases
[08:20] <pitti> sarnold: indeed I'd like this directory a bit more empty, like dropping all the *.wants dirs; xnox was working on that a while ago, but it got stuck in the middle
[08:21] <sarnold> pitti: indeed I neve rnoticed the symlinks all have different names. alright :)
[08:34] <Laney> sil2100: Thoughts on yakkety touch failures ↑?
[09:54] <pitti> Laney, Trevinho: do you see any advantage of managing bamfdaemon via upstart? it needs carefully crafted start conditions, this dbus activation wrapper script, etc. -- it seems to me that just using d-bus activation would be muuuch simpler
[09:55] <pitti> I have a conversion ready for systemd units, but this just adds a whole lot of  complexity for no visible gain IMHO
[09:55] <Laney> I don't know why it was done in that way
[09:56] <Laney> maybe it takes a while to start and they wanted to get in before the activation?
[09:56] <pitti> Laney: it actually locks up quite a bit, as the upstart job waits until unity7 is started
[09:57] <pitti> http://bazaar.launchpad.net/~unity-team/bamf/trunk/revision/621
[09:57] <pitti> not that long ago, actually
[09:57] <seb128> yeah, Trevinho wanted it for the lts
[09:58]  * pitti looks where teh corresponding MP is
[09:58] <seb128> I just did that
[09:58] <Laney> probably for 'respawn'
[09:58] <seb128> no rational in there
[09:59] <seb128> https://code.launchpad.net/~3v1n0/bamf/upstart-support/+merge/276865
[09:59] <pitti> https://code.launchpad.net/~3v1n0/bamf/upstart-support/+merge/276865
[09:59] <pitti> ah
[09:59] <pitti> Laney: but dbus activation alreayd gives you that
[09:59] <pitti> yeah, that's not very helpful
[10:00] <pitti> start on (starting hud or starting unity-panel-service or starting unity7)
[10:00] <Laney> with this you get it pre-emptively
[10:00] <pitti> it now requires this to be correct and covering all use cases
[10:00] <Laney> just trying to think what it might be
[10:00] <Laney> not defending it
[10:00] <pitti> yeah, I guess I'll wait for Trevinho to comment
[10:03] <willcooke> flocculant, around line 57 of your gtk-widgets.css file you have a .entry.progressbar entry, which is then duplicated in gtk-widgets.css line 1337
[10:03] <willcooke> sorry, I mean flexiondotorg ^
[10:03] <flexiondotorg> willcooke, OK
[10:03] <willcooke> I don't know if it will cause any issues or not, probably not
[10:03] <pitti> i followed up on https://code.launchpad.net/~3v1n0/bamf/upstart-support/+merge/276865, to keep a public record of that
[10:03] <seb128> Laney, pitti, IRC log says
[10:03] <seb128> Ubuntu Server-#ubuntu-desktop.log:févr. 24 15:01:17 <Trevinho>	Laney: well, having upstart to manage it would have ensured that the service would have ran only when needed, and that could have been controlled by initctl... With actual respawn and such.
[10:04] <willcooke> but I just noticed it as I was trying to fix Ambiance
[10:04] <flexiondotorg> willcooke, Thanks for pointing it out, I'll look into it :-)
[10:04] <pitti> seb128: hm, but activation does both, and more precisely
[10:05] <willcooke> flexiondotorg, lemme finish fixing up Ambiance and finding out if it causes any harm or not.  I can fling a patch your way if it's an improvemetn
[10:05] <flexiondotorg> willcooke, Thanks :)
[10:05] <Laney> seb128: fevr 24?
[10:05] <Laney> that's about something else surely
[10:05] <Laney> those MPs are from november
[10:06] <seb128> Laney, I think his rational was the same/consistent for using upstart in different unity jobs
[10:06] <seb128> but maybe you are right and he was not
[10:06] <seb128> anyway let's wait for him
[10:06] <Laney> I think that was about the zeitgeist thing
[10:06] <Laney> it might have used a similar trick
[10:08] <seb128> pitti, some things upstart gives you over dbus activation is respawn limit, "proper" log in .cache/upstart which apport picks up and a stop/start command which is handy for debugging ... but I'm note that's enough to justify the cost
[10:09] <pitti> seb128: not sure if the respawn limit actually helps here -- as soon as I try to stop bamf it immediately comes back via activation, as apparently unity is talking to it all the time
[10:09] <pitti> so we'd replace those with 25s timeouts
[10:10] <pitti> but I do see the point in logging, that's harder to see  from .xsession-errors
[10:10] <Laney> pitti: are you using the systemd bus activation support in your replacement?
[10:10] <Laney> does that work for --user?
[10:10] <pitti> Laney: unfortunately SystemdService= isn't implemented in dbus for user units, that just works for system units
[10:10] <pitti> Laney: i. e. I tried, but this is a no-op
[10:11] <Laney> shame
[10:11] <pitti> well, I tested 1.10.6, haven't checked latest upstream yet
[10:14] <Laney> pitti: wait, dbus?
[10:14] <Laney> I thought this was a generator
[10:14] <pitti> Laney: SystemdService= in dbus *.service files is implemented in dbus
[10:15] <pitti> i. e. dbus activation needs to redirect to systemd if that field is present
[10:15] <Laney> I suppose dbus needs to know how to activate stuff
[10:16] <Laney> I was looking at this dbus1-generator
[10:16] <pitti> maybe I missed something, and that's not the field that we want
[10:16] <Laney> what's that for?
[10:16] <Laney> kdbus?
[10:16] <pitti> i. e. I think there's another mechanism that creates "proxy" connections for the bus names
[10:18] <pitti> Laney: not sure, need to look at that
[10:19] <Laney> oh right
[10:20] <Laney> it makes Type=dbus units from SystemdService= .service files
[10:21] <pitti> ah, so that I could use
[10:21] <pitti> except that I need two additional properties
[10:21] <pitti> and presumably some After=, and I need to install the unit
[10:24] <willcooke> seb128, anyone - can you confirm this missing icon?  http://imgur.com/xQCxQTP
[10:24] <willcooke> could be because I'm dicking around with themes
[10:24] <willcooke> also: progressbars are filled in :)
[10:26] <Laney> pitti: why?
[10:26] <Laney> if it's just bus activation then the defaults should be okay?
[10:27] <pitti> Laney: for "proper" visible apps that don't work via dbus activation (like g-settings-daemon) I need Slice=graphical.slice, to restrict the life cycle on the current grpahical session
[10:27] <pitti> to shut them down cleanly when the session goes down
[10:28] <pitti> I suppose bamfdaemon will just crash on "OMG my $DISPLAY went away" with plain dbus activation
[10:28] <pitti> so it's not that bad eitehr
[10:28] <pitti> Laney: I mostly just picked bamfdaemon as the first thing to convert, I guess I should have picked something else :)
[10:28] <pitti> Laney: so, the generated defaults should work, yes
[10:29] <pitti> maybe not 100% cleanly
[10:29] <Laney> The generator doesn't actually do anything for me
[10:29] <pitti> Laney: did you add SystemdService= to anything?
[10:30] <pitti> nevermind, gnome-terminal, gvfs etc. have those
[10:30] <Laney> I have it on loads of stuff already
[10:31] <Laney> https://paste.debian.net/702369/
[10:31] <seb128> willcooke, icon is fine here
[10:32] <Laney> open("/sys/fs/kdbus/control", O_RDWR|O_NOCTTY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[10:32] <Laney> exit_group(0)                           = ?
[10:32] <Laney> oh yeah I see this in the code now
[10:32] <pitti> so that won't help anytime soon :)
[10:33] <Laney> but...
[10:33] <Laney> why does it rely on kdbus?
[10:33] <Laney> if dbus-daemon can do systemd activation too
[10:33] <pitti> but for this to be truly useful, dbus-daemon would need to learn systemd activation for user services
[10:33] <pitti> maybe because of that?
[10:35] <Laney> hmm
[10:35] <Laney> is it really that?
[10:35] <pitti> I have a manually created unit (so not depending on that  generator)
[10:35] <pitti> I added SystemdService=
[10:36] <pitti> and yet dbus activaiton doesn't start it
[10:37] <seb128> willcooke, do you have aptdaemon-data installed?
[10:38] <seb128> aptdaemon-update-cache.png seems to be the icon it loads
[10:43] <willcooke> $ apt-cache policy aptdaemon-data
[10:43] <willcooke> aptdaemon-data:
[10:43] <willcooke>   Installed: 1.1.1+bzr982-0ubuntu14
[10:43] <willcooke>   Candidate: 1.1.1+bzr982-0ubuntu14
[10:43] <willcooke>   Version table:
[10:43] <willcooke>  *** 1.1.1+bzr982-0ubuntu14 500
[10:43] <willcooke>         500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
[10:43] <willcooke>         500 http://gb.archive.ubuntu.com/ubuntu xenial/main i386 Packages
[10:43] <willcooke>         100 /var/lib/dpkg/status
[10:44] <Laney> pitti: laney@nightingale> systemctl --user start org.gnome.Cheese                                                                                                                     ~/.config/systemd/user
[10:44] <Laney> Failed to start org.gnome.Cheese.service: Unit dbus.socket not found.
[10:44] <pitti> Laney: missing dbus-user-session ?
[10:44] <pitti> I have it here
[10:45] <willcooke> seb128, it's probably something to do with me messing with the theme.  Don't worry about it, I'll confirm it goes away again when I'm done playing
[10:45] <Laney> ah right, that provides this?
[10:45] <Laney> don't think I have that
[10:45] <seb128> willcooke, k
[10:45] <pitti> Laney: yes
[10:46] <Laney> indeed
[10:46]  * Laney whines about having to close session
[10:46]  * pitti mutters "VM"
[10:46] <pitti> Laney: wait
[10:46] <Laney> haha
[10:46] <pitti> Laney: for this to really work, you need https://launchpad.net/ubuntu/+source/dbus/1.10.6-1ubuntu4
[10:47] <pitti> or disble upstart session
[10:49] <Laney> got it
[10:49] <Laney> brb
[10:52] <Laney> my that's a nice wallpaper
[10:53] <Laney> good job I like it because that's all I can see
[10:53] <pitti> lol
[10:54] <Laney> HAHA
[10:54] <pitti> Laney: do you have any dbus-daemon running now?
[10:54] <Laney> this is actually amusing
[10:54] <pitti> there's always the one for at-spi2
[10:54] <Laney> laney@nightingale> cat unity7.override                                                                                                                                                                                       ~/.config/upstart
[10:54] <pitti> but aside from that there should now only be the --address=systemd: one
[10:54] <Laney> manual
[10:54]  * Laney coughs
[10:55] <pitti> Laney: wow, did you add that half an hour ago, or do you never restart your session? :)
[10:55] <Laney> that's better :)
[10:55] <Laney> I did it a couple of days ago
[10:55] <Laney> when you were asking about .override files
[10:55] <pitti> Laney: ah -- right, that got sorted out, I updated the bug
[10:56] <Laney> indeed
[10:56] <pitti> that was due to that hacky bamfdaemon d-bus activation wrapper
[10:56] <Laney> I just forgot to remove it
[10:56] <Laney> unity7 might not have been the best example to use
[10:56] <pitti> nice trap :)
[10:56] <Laney> ooh no terminal menus
[10:57] <Laney> global menu*
[10:57] <pitti> Laney: bug 1532226 ?
[10:59] <Laney>   Installed: 0.5.3~bzr0+16.10.20160516-0ubuntu1
[11:00] <pitti> I actually do get the menu in terminals after booting in my yakkety VM
[11:01] <andyrock> hey guys
[11:02] <Laney> pitti: anyways, https://paste.debian.net/702431/ <- session bus service got activated by systemd
[11:03] <Laney> hey andyrock
[11:03] <pitti> Laney: I didn't create a .service symlink by the bus name, maybe that's necessary?
[11:03] <willcooke> hey andyrock
[11:03] <pitti> Laney: I had thought if I specify SystemdService=bamfdaemon.service that'd be enough
[11:04] <Laney> pitti: ah, I don't know, let me try renaming it
[11:04] <Laney> pitti: this still works
[11:04] <Laney>    Loaded: loaded (/home/laney/.config/systemd/user/hellopitti.service; static; vendor preset: enabled)
[11:04] <Laney>    Active: active (running) since Wed 2016-05-25 12:04:41 BST; 1s ago
[11:05] <pitti> Laney: http://bazaar.launchpad.net/~pitti/bamf/systemd-unit/revision/637 is my current bamfdaemon stuff; if we can simplify that, that'd be great
[11:05] <Laney> pitti: that's just http://paste.debian.net/702433/
[11:05] <Laney> and SystemdService=hellopitti.service
[11:06] <pitti> Laney: but no /usr/share/dbus-1/services/org.gnome.Cheese.service ? I wonder if that gets in the way for bamf then
[11:06] <Laney> that's the file I edited, yes
[11:06] <pitti> Laney: oh, wait -- that silly redirectory again
[11:07] <pitti> Laney: maybe systemd did try to activate it, then called the wrapper script, which again tried to call it via systemd/upstart, loop, bang
[11:07] <Laney> if you had Exec=/that/wrapper then that seems likely
[11:07] <Laney> urgh
[11:08] <Laney> I vote for dropping all this crazy stuff and using dbus activation then
[11:08] <pitti> +1
[11:09] <pitti> nevetheless, the general approach should work for other services, so it wasn't in vain
[11:09] <Laney> so I wonder about dropping this kdbus check then
[11:20] <pitti> Laney: indeed, this works absolutely fine
[11:20] <pitti> so this was just this redirection wrapper that fooled me
[11:24]  * pitti wants bzr commit --amend
[11:26] <pitti> http://bazaar.launchpad.net/~pitti/bamf/systemd-unit/revision/637 fixed
[11:27] <Laney> \o/
[11:27] <pitti> Laney: so, dropping the kdbus check and automatically wrapping every service into a unit would be great
[11:27] <Laney> building systemd without the check now
[11:27] <pitti> that would give us the per-service logging and restart limit for free
[11:27] <Laney> to see what happens
[11:31] <pitti> Laney: ok, autopkgtest runners seem throughly unhappy; need to grab some lunch and then tend to my minions
[11:31] <pitti> Laney: thanks for looking into the dbus generator!
[11:32] <Laney> np!
[11:33] <pitti> actually, !s390x is running at full steam, just the logtails are broken
[11:33] <pitti> ok, post-lunch problem :)
[11:33] <Laney> queues look big
[11:33] <Laney> damn you qt!
[11:33] <pitti> yeah, we got like 10 Qt uploads in the last few days
[11:34] <pitti> Mirv, the test infra killer :)
[11:35] <pitti> 2016-05-25 11:35:08,160 INFO:worker adt-run exited with code 1
[11:35] <pitti> 2016-05-25 11:35:08,172 ERROR:worker AMQP queue interrupted, reconnecting in 5s: [Errno 2] No such file or directory: '/tmp/adt-work.8yGtP7/out/exitcode'
[11:35] <pitti> that doesn't look healthy
[11:40]  * Laney screams at multiarch
[11:40] <Mirv> uh oh :(
[11:41] <Mirv> s/killer/stress tester/
[11:43] <Mirv> the new KDE release brings its own problems, everything is intertwined.
[12:13] <larsu> Laney: join the chorus!
[12:14] <larsu> I did the same yesterday when I realized that `apt-get update` tries to load i386 package listings from our repository
[12:14] <larsu> which is configured to only contain amd64 and source
[12:14] <larsu> the "fix" is to either create an empty i386 in the repo, or have people put [arch=amd64] in the source.list line
[12:16] <Laney> larsu: there's something fishy there
[12:17] <larsu> the internet says it's supposed to be like this
[12:17] <larsu> even though I'd say it's a bug in apt
[12:18] <Laney> I think you're supposed to configure your repository to produce i386 Packages
[12:18] <Laney> if clients are going to be requesting them
[12:19] <larsu> we don't build them, though
[12:19] <larsu> and don't advertise them
[12:20] <larsu> by that logic, we'd always need to build all archs, no?
[12:23] <pitti> Laney: ok, I put an end to the minion strike :)
[12:23] <pitti> Laney: any luck with dropping the patch?
[12:23] <pitti> err, check
[12:24] <Trevinho> pitti:  as for bamf... I wanted auto-respawn and at the same time be able to get the process handled by upstart even when dbus-activated
[12:26] <pitti> Trevinho: hey!
[12:26] <Trevinho> pitti: the start conditions are just "optional", so we ensure that bamf is already ran whe something is just about to start that might use it (without having dbus activation to come into play); so it's like an "optimization", but nothing that prevents it to run
[12:26] <pitti> Trevinho: bus activation does auto-respawm already
[12:26] <Laney> pitti: Got distracted by talking DMB
[12:26] <Laney> i386 seems to have finished now
[12:26] <Trevinho> pitti: mh I didn't get that in the past, was there a missing option?
[12:27] <pitti> Trevinho: not really, no; when you try to connect to a non-running service, it'll be activated
[12:27] <Trevinho> pitti: also, at the time, the upstart environment vars were not matching the dbus ones (now it's fixed), thus this was potentially causing some issues
[12:27] <pitti> and auto-respawn doesn't help either way for existing connections
[12:27] <Trevinho> pitti: well for the way libbamf is done (which does quite some caching), this wouldn't cause to be called enough
[12:27] <Trevinho> or... It would cause to restart bamf on user actions (like alt+tabbing or clicking in the launcher)
[12:28] <pitti> Trevinho: I mean, if your current daemon crashes, your connection will become invalid, no matter whether the daemon gets autorestarted or restarted the next time on bus activation
[12:29] <Trevinho> pitti: yes, but we've gdbus doing things internally, so.... At the end our proxy just stays the same
[12:29] <pitti> right
[12:30] <pitti> Trevinho: so, I have a systemd-ification ready, but adding all that complexity and that ugly hack with the activation wrapper script doesn't seem worth the effort to me TBH
[12:30] <Trevinho> I mean we had this condition that on bamf crashes (we don't have them, actually, as the code is perfect 😃), we were loosing some controls
[12:30] <seb128> hey Trevinho!
[12:30] <Trevinho> hi seb128
[12:30] <seb128> Trevinho, thanks for the reviews, you did a night shift? 4am comments :-)
[12:30] <Trevinho> seb128: eh, you know... nights are things I like
[12:31] <seb128> hehe
[12:31] <seb128> Trevinho, I think we have a good stack of usd changes now, we should do a landing
[12:32] <Trevinho> seb128: yeah, all yours.
[12:32] <Trevinho> seb128: it would be nice to SRU them all probably too
[12:32] <Trevinho> so we have both fixes and the x/y delta to the lowest level
[12:33] <Laney> larsu: I guess maybe you could argue that apt should deal with it being missing if it's a foreign architecture
[12:33] <Laney> might be worth asking juliank about that
[12:35] <larsu> I agree
[12:35] <seb128> Trevinho, yeah, need a y landing, then SRU in 2 or 3 rounds
[12:35] <seb128> smalls fixes + keyboard ones
[12:35] <pitti> Trevinho: so in summary, I was wondering how attached you were to this stuff
[12:35] <Trevinho> seb128: even screensaver one could be nice, since it seems that chrome use that API
[12:36] <Trevinho> at least... maybe not latest versions, but it used to use only fdo api
[12:36] <Trevinho> pitti: well... if things work differently when using systemd at user level, I don't mid removing it
[12:36] <pitti> Trevinho: it shouldn't really work differently with upstart either
[12:36] <Trevinho> pitti: in upstart world, it's something that seems to work better than just using dbus activation
[12:36] <pitti> Trevinho: i. e. I'm still trying to understand the rationale for usptartizing this in the first place
[12:37] <pitti> Trevinho: right, so how does it work better exactly?
[12:37] <Trevinho> pitti: environment vars were not matching with unity
[12:37] <Trevinho> pitti: and we had not a proper and immediate respanw
[12:37] <pitti> that was fixed in bug 1433013, no?
[12:37] <Trevinho> which meant, empty launcher for a while until "something" happened
[12:37] <Trevinho> pitti: yes
[12:38] <Trevinho> I'm speaking using the past verb for that thing in fact
[12:38] <pitti> Trevinho: ah, so bamfdaemon does "something" while clients are not talking to it?
[12:38] <pitti> (that would be a good reason)
[12:39] <Trevinho> it's presence causes unity to show launcher icons. Once it gets removed, launcher becomes empty. This is because internally icons need to be seen as active. Which is a condition that is not true anymore when the daemon isn't there (as we can't assume it)
[12:41] <pitti> Trevinho: hm, I didn't see that under y at least; killing bamf keeps a functional launcher, you just get new icons pulsating while they try to match their window and bamf isn't running
[12:41] <pitti> (i. e. I disabled the activatino file)
[12:41] <Trevinho> So its presence around is a condition for having the desktop fully working. Not only for the launcehr, but also panel titles and many other elements rely on it. And since some changes are only emitted by signals or property changes, we could avoid to cal methods
[12:41] <pitti> Trevinho: anyway, if it does active things instead of just reacting, that makes sense
[12:42] <pitti> I didn't see evidence of it and there was no justification in the MP, so I wondered
[12:42] <Trevinho> yeah, I've not been much clear indeed
[12:42] <pitti> Trevinho: so I guess we'll have to carry http://bazaar.launchpad.net/~pitti/bamf/systemd-unit/revision/637 around for a bit until the migration is complete and we can drop the upstart bit
[12:43] <pitti> but I figure the touch branches are usually also landed for v/x, so we'll have to keep this for a while
[12:43] <Trevinho> pitti: yeah, I was looking at it... I know it's overcomplicating things a little
[12:43] <Trevinho> but, nothing we should really touch for years probably
[12:46] <muktupavels> Trevinho: if you have time can you review compiz merge proposals?
[12:46] <Trevinho> muktupavels: I see lots of them :)
[12:46] <pitti> Trevinho: thanks for the heads-up!
[12:47] <Trevinho> pitti: np
[12:47] <pitti> Trevinho: It'll still be a while until I send an MP, I'll first stage this in a PPA
[12:51] <Trevinho> pitti: ok no worries... I'll be happy to test that then
[12:53] <Laney> pitti: I don't think it's working for --user
[12:53] <Laney> open("/usr/share/dbus-1/system-services", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[12:53] <Laney>         r = cg_pid_get_owner_uid(0, NULL);
[12:53] <Laney>         if (r >= 0) {
[12:53] <Laney>                 path = "/usr/share/dbus-1/services";
[12:54] <pitti> yay for being on the forefront of systemd-ification for a change :)
[12:54] <Laney> do you know about this cgroup stuff?
[12:56] <pitti> Laney: this parses out the UID from /proc/self/cgroup name=systemd:
[12:56] <pitti> 1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
[12:56] <pitti> so it should be "1000" for this
[12:56] <Laney> 1:name=systemd:/user/laney/0/dbus.service
[12:57] <pitti> oh, what's that
[12:57] <pitti> Laney: ah! libpam-cgm?
[12:57] <Laney> haha
[12:57] <Laney> is that the lxd thing?
[12:57] <pitti> although, why is that touching the systemd group
[12:57] <pitti> Laney: no, it's obsolete
[12:58] <pitti> you only need it for unpriv lxc containers, not necessary for lxd
[12:58] <pitti> but that looks like a bug
[12:58] <Laney> no I don't have this installed
[12:58] <pitti> it's not supposed to mess with systemd's own cgroups, just create additional ones
[12:58] <Laney> I have libpam-cgfs though
[12:58] <pitti> ah, that
[12:58] <pitti> it changed name
[12:59] <willcooke> any clues what applicaiton was used in this screenshot snippet?  https://launchpadlibrarian.net/255943248/Auswahl_027.png
[12:59] <pitti> Laney: but wait, dbus.service?
[12:59] <Trevinho> willcooke: update manager I think
[12:59] <willcooke> thanks Trevinho
[12:59] <Laney> gnome-system-monitor
[12:59] <Trevinho> willcooke: I've seen the same in synaptic and... mh
[12:59] <Trevinho> willcooke: another app was excyly
[12:59] <Trevinho> yeah
[12:59] <Trevinho> the disk usag
[13:00]  * Trevinho yells at his keyboard
[13:00] <Laney> pitti: I'm in uncharted territory for me here :)
[13:00] <pitti> Laney: so my user dbus process has /user.slice/user-1000.slice/user@1000.service/dbus.service
[13:01] <pitti> Laney: can you try uninstalling libpam-cfgs and see if that helps?
[13:01] <pitti> Laney: it's the main/only thing that I'm aware of, otherwise we'll have to deep-dive
[13:01] <Laney> okay
[13:09] <Trevinho> hikiko: hey
[13:09] <Trevinho> hikiko: could you review this plase https://code.launchpad.net/~smspillaz/compiz/compiz.animationaddon-returns/+merge/295497 ?
[13:10] <Laney> aaaaaahhhh
[13:10] <hikiko> Trevinho, sure
[13:11] <hikiko> oh
[13:12] <hikiko> he changed the opengl calls to be compatible with gles2
[13:12] <hikiko> :s
[13:16] <Trevinho> hikiko: it's a plugin we don't use by default in unity, so it's not our main target, but still it has not to break any experience of course :)
[13:18] <hikiko> he changed the opengl plugin to be compatible with gles2
[13:18] <hikiko> and he fixed the animationaddon
[13:20] <hikiko> but yeah probably this doesn't affect anything on the desktop
[13:20] <Laney> pitti: this breaks eeeeeverything! :)
[13:21] <hikiko> well no, he removed the lighting
[13:21] <pitti> Laney: "this" ==?
[13:21] <hikiko> lighting in gles2 is done in shaders
[13:21] <hikiko> :s
[13:21] <Laney> pitti: the generator
[13:21] <Laney> it masks dbus.service
[13:24] <desrt> word up, peeps
[13:26] <Laney> I guess that turning this off for dbus-daemon is the thing that is good to do
[13:26] <Laney> greetings desrt
[13:26] <desrt> Hello, Laney!
[13:27] <pitti> Laney: you mean it generates a unit for dbus.service itself? and it's not stuffing them into generator-late/ ?
[13:27] <seb128> hey desrt!
[13:27] <desrt> hello seb128, pitti, hikiko, Trevinho  :)
[13:27] <pitti> hey Allison, how is it going?
[13:27] <desrt> another lovely day
[13:27] <Laney> pitti: /run/systemd/generator/dbus.service -> /dev/null
[13:27] <Trevinho> hi desrt
[13:27] <pitti> Laney: WTH
[13:28] <Laney> And some dbus.socket -> systemd-bus-proxy
[13:28] <desrt> pitti: oddly sleepy this morning!  trying to overcompensate using exclamation marks!
[13:28] <Laney> .socket thing appears
[13:28] <Laney> Is this like "use kdbus now please"?
[13:28] <pitti> Laney: ah, yes, the bus proxy is kdbus
[13:28] <pitti> that explains masking dbus
[13:28] <hikiko> hello desrt and all
[13:28] <Laney> so I'll try to turn this off for the non kdbus case
[13:28] <Laney> but after lunch, o/
[13:28] <desrt> did i wake up in some weird alternate universe in which kdbus has been merged?
[13:29] <Laney> we're abusing systemd in wicked ways
[14:12] <Trevinho> hikiko: as the change from handsome_feng landed I guess this is not needed anymore, right: https://code.launchpad.net/~hikiko/unity/unity.scale-launcher-at-the-bottom/+merge/293124
[14:12] <Trevinho> ?
[14:15] <Trevinho> muktupavels: mostly approved them.. there are a couple of comments also from Sam I'd like to clear out  before a final approval
[14:15] <Trevinho> muktupavels: are you fine with a partial landing in the mean time (https://requests.ci-train.ubuntu.com/#/ticket/1465) ?
[14:16] <muktupavels> Trevinho: why did not you aprove gwd-theme-implement-draw-window-decoration?
[14:17] <muktupavels> seems that you included it in landing
[14:17] <muktupavels> Trevinho: yes, I am fine with partial landing.
[14:18] <Trevinho> muktupavels: ah, thanks for pointing out... I misssed it :)
[14:18] <Trevinho> muktupavels: nice cleanup, btw
[14:19] <muktupavels> Trevinho: I think you are right in gwd-change-theme-loading - signal must be disconected.
[14:20] <Trevinho> muktupavels: a disconnect_by data could do things even for future stuff
[14:21] <muktupavels> Trevinho: I will use signal id.
[14:24] <Trevinho> muktupavels: fine anyway
[15:16] <Laney> build systemd buildddddddddddddddddDDDdddDDDdddDDDddDDDDDddd
[15:16] <Sweet5hark> Laney: faster, systemd, kill, kill?
[15:17] <Laney> die, systemd, die
[15:17] <Laney> </sideshow bob>
[15:18] <davmor2> Laney: you can never end sideshow bob Muhahahahahahahahahaha
[15:20]  * Sweet5hark now see a Russ Meyer movie featuring Sideshow Bob in his head.
[15:20] <Sweet5hark> It aint pretty.
[15:20] <ogra_> eek
[15:20] <Laney> I just googled the scene
[15:20] <Laney> https://youtu.be/Ipf3an9RGDs
[15:26] <seb128> can anyone see if in rhythmbox -> preferences -> music
[15:27] <seb128> if you select ogg vorbis as format
[15:27] <seb128> does it tell you extra softwares are needed (button at the bottom of the dialog)
[15:27] <seb128> ?
[15:27]  * desrt finds a new interesting task
[15:29] <Trevinho> pitti: hey.... Soooo... We introduced a regression in upower :/
[15:29] <Trevinho> pitti: (lt-upowerd:12806): UPower-WARNING **: failed to convert brightness: 0
[15:30] <Trevinho> pitti: this is because *end != '\0' isn't true... Because end returns the position of the last read elements, not the last+1
[15:32] <flocculant> seb128: I don't see that
[15:32] <seb128> flocculant, so it works for you?
[15:33] <flocculant> seb128: I can select ogg vorbis without it saying anything, can set bit rate
[15:34] <seb128> flocculant, thanks, in fact it works in a guest session, so probably something with my gstreamer cache/profile :-/
[15:34] <flocculant> seb128: ok
[15:35] <seb128> flocculant, thanks for testing!
[15:35] <flocculant> seb128: welcome as always when I see something I *can* test :)
[15:35] <seb128> other easy to test bug :p
[15:35] <flocculant> :)
[15:36] <seb128> starting gedit, ctrl-O, select "recent" is the fileselector
[15:36] <seb128> do you get files from yesterday not displayed with a "yesterday" label in the accessed column?
[15:36] <flocculant> seb128: aaah - not so easy to test - I'd have to install gedit (xubuntu uses mousepad)
[15:37] <seb128> any gtk3 app would do
[15:37] <flocculant> and I assume I'd need zeitgeist for it to know yesterday?
[15:37] <seb128> no, it's gtk-recent
[15:37] <seb128> but depends if you opened files yesterday
[15:37] <seb128> I've the feeling that it's files opened for less than 24 hours
[15:37] <seb128> I wonder if it's a bug or by design
[15:38] <seb128> like it's 17:38 here
[15:38] <seb128> I see files noted as
[15:38] <seb128> 19:07
[15:38] <seb128> yesterday 16:18
[15:38] <flocculant> mousepad doesn't list them with labels
[15:38] <seb128> well "labels"
[15:38] <seb128> it's the most right column
[15:38] <seb128> in the "recent" section from the fileselector
[15:39] <flocculant> seb128: Ctrl+O shows /home/ but it does have dates - and yesterday is yesterday
[15:40] <seb128> flocculant, did you select "recent" in the left sidebar
[15:40] <flocculant> aah - never seen that
[15:42] <flocculant> seb128: that doesn't look right at all
[15:43] <seb128> which part?
[15:43] <flocculant> nothing between Sunday and this morning
[15:44] <flocculant> and apparently something at 17:34 even though it's only 16:43 > and that's an audio file that I'm unlikely to be listening to in 45 minutes
[15:44] <flocculant> as far as 'yesterday' I'm as likely to use nano as mousepad
[15:47] <seb128> do you think you opened that audio file yesterday at 17:34?
[15:48]  * Sweet5hark got a libreoffice 5.2 alpha1 to run from a snap (in --devmode, with tweaks and ugly tricks, but still).
[15:48] <Sweet5hark> https://www.youtube.com/watch?v=Y6ljFaKRTrI
[15:48] <seb128> Sweet5hark, well done!
[15:48] <qengho> Sweet5hark: Yay!
[15:48] <seb128> qengho, hey, did you see my comment about fontconfig yesterday?
[15:48] <Sweet5hark> now to get this in a shape that can be shown to the world ...
[15:49] <seb128> Sweet5hark, well, if it starts it can be shown
[15:49] <seb128> bugs can be fixed in iterations ;-)
[15:50] <qengho> seb128: No!  /me scrolls
[15:50] <seb128> qengho, it was on #snappy during the meeting, didn't want to derail it
[15:50] <seb128> qengho,
[15:50] <seb128> https://bugs.launchpad.net/snapcraft/+bug/1576303
[15:50] <seb128> do you have the variables described there?
[15:52] <Sweet5hark> (like not having "sudo dot -c" in the build, which of course prompts for a password)
[15:53] <Sweet5hark> seb128, qengho: speaking of fonts, for now the "right" way is to just bundle them in the snap?
[15:53] <qengho> seb128: No, I don't have those defined.
[15:53] <qengho> Sweet5hark: Yes, include them. (I think.)
[15:53] <seb128> qengho, try that then, it might fix the issue you mentioned during the meeting
[15:53] <qengho> seb128: Thanks!
[15:54] <seb128> Sweet5hark, qengho, bundle for now yes, but they are working on an interface that is going to bindmount the fonts dir
[15:54] <flocculant> seb128: I'm sure I didn't access that file yesterday at that time
[15:55] <qengho> seb128: Are we moving dependencies and dependency-checking into app-space?
[15:55] <flocculant> I've cleared recent files and will look again tomorrow - I know what I've been looking at today
[15:55] <Laney> shady stuff
[15:55] <seb128> flocculant, check into /home/seb128/.config/gtk-3.0/bookmarks
[15:56] <seb128> k
[15:56] <seb128> qengho, you mean? there is no depends in snaps, out of the core systemd
[15:57] <qengho> seb128: Yes, I know. But if we're bind-mounting, that asserts something about the host system. It looks like apps will have to check whether fonts exist (e.g.) on their own, then.
[15:58] <qengho> I'm complaining to the wrong person, I know.
[15:59] <qengho> The interface provides ability to use host resources, but no way to assert host resources.
[16:00] <flocculant> seb128: so just quickly, cleared bookmarks, opened a file and .config/gtk-3.0/bookmarks, if I now go to gedit or mousepad - I have access times of 16:58 and 20:30 respectively
[16:00] <flocculant> but will look tomorrow as well to see what it says about 'yesterday'
[16:02] <seb128> flocculant, thanks
[16:03] <seb128> qengho, well, the snap providing the interface can provide content/code I guess? if no we need a desktop core image which includes fonts, mimetypes, etc...
[16:04] <qengho> I suppose a "fonts" interface can map to a snapd-enforced "dependency" to require some selection (!) of fonts and tools. ick.
[16:48] <Laney> ruh roh
[16:48] <Laney> pitti made me break my laptop!
[17:06]  * Laney waves
[17:06] <Laney> cd sy
[19:49] <qengho> Chromium 51? Ugh.
[21:15] <robert_ancell> mterry, hey, just letting you know I am working on the in-session greeter LightDM work. It's just turned out to be a complicated headache :(
[21:15] <mterry> robert_ancell, heyo
[21:15] <mterry> robert_ancell, no rush on my side
[21:16] <robert_ancell> mterry, ok, cool. If that's OK I might shelve it for a bit and then come back to it next week.
[21:16] <mterry> robert_ancell, yeah I'm still dealing with making the greeter look nice and fingerprint support
[21:16] <mterry> not blocked on you at all
[21:16] <robert_ancell> mterry, cool fingerprint - what stack are you using for that?
[21:17] <mterry> robert_ancell, I don't know the details exactly underneath, but some custom stack by tvoss
[21:18] <mterry> robert_ancell, not integrated with pam
[21:18] <robert_ancell> yeah, was about to ask
[21:18] <mterry> robert_ancell, only supposed to be used in lockscreen, not to log in first time, is my understanding
[21:19] <robert_ancell> until that requirement comes :)
[21:20] <robert_ancell> The only stack I know of is fprintd
[21:30] <robert_ancell> mterry, do you happen to know if Josh Arenson is around?
[21:36] <mterry> robert_ancell, no sorry
[21:36] <mterry> robert_ancell, he's in #ubuntu-unity...
[21:36] <mterry> robert_ancell, "josharenson"
[21:36] <robert_ancell> aha, I checked everywhere else :)