[03:14] 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] tjaalton, ah, of course [03:44] ls [03:44] sorry... [03:55] happyaron, :) [05:00] Hi [05:49] Trevinho: I downloaded the current and PPA sources and debdiffed that, it's ok; I accepted it last night [05:49] Good morning [06:07] good morning desktopers! [06:11] 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] seb128: correct [06:11] seb128: I reviewed/accepted the evo SRU last night [06:11] I saw [06:12] but seems like that didn't work :-/ [06:12] err, wut [06:12] the .mo are not included in any deb [06:13] does the parser just look for X-Ubuntu-Use-Langpack and would consider a commented one as being defined? [06:13] I should perhaps have deleted the line... [06:17] pkgstriptranslations:if grep -q 'X[[:alpha:]]*-Ubuntu-Use-Langpack: yes' debian/control; then [06:17] seb128: erk, my bad :/ [06:17] should have a ^ [06:18] well I guess commented is not that common [06:18] seb128: I'll fix it in pkgbinarymangler now, but I suppose it's easier for this case if you reupload evo [06:18] I can review/accept it right away [06:19] 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] seb128: yeah, I don't particularly mind, but I'd at least give them a chance to weigh in [06:25] pitti, evo reuploaded [06:25] on that note I'm done with email backlog, time for coffee ;-) [06:25] seb128: just waiting for diff, will press the button then [06:25] thanks! [06:26] seb128: pkgbinarymangler fix uploaded [06:26] ... for the future [07:01] pitti, nice [07:03] wth :/ [07:03] pitti, the .mo are still stripped out :-/ [07:05] 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] or I guess I could do a yakkety upload with the 3rd fix if you prefer [07:05] while Aron gets the rebase done [07:12] seb128: WTF [07:13] yeah... [07:16] pitti, sorry, my fault [07:16] seb128: nm-applet> I targetted the yakkety bug to 16.06 now and assigned [07:16] pitti, thanks [07:16] but we don't have a way to enforce that they really get fixed [07:17] if devs forget about it, we have zero pressure on that [07:17] yeah, as said I can do an upload now if you prefer [07:17] it's just that Aron is working on updating to 1.2.2 and including that change [07:17] rebasing the patches just take some time [07:18] 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] so if that's in the pipeline, ok [07:18] right [07:18] I'm going to make sure of that [07:18] thanks [07:18] it's landing this week one way or another [07:18] (accepted) [07:18] thanks! [07:18] pitti, evolution is good, ignore my recent comment [07:19] seb128: oh, you only looked at s390, and that doesn't build a -common package? [07:19] I looked at one of the archs that built first (powerpc) but the translations are in common [07:19] amd64 is still building [07:19] *phew* [07:19] sorry :-) [07:19] so, not "good" yet, but at least not "definitively bad" :) [07:19] ah, build done [07:20] -rw-r--r-- root/root 166711 2016-05-25 07:11 ./usr/share/locale/af/LC_MESSAGES/evolution-3.18.mo [07:20] pitti, good :-) [07:20] * pitti ^5s seb128 [07:20] * seb128 ^5s pitti back [07:23] pitti, can "idVendor" or "idProduct" udev attributes being missing/null for plugged devices? [07:24] the libopenobex segfault which I SRUed the fix for, the command is called by that udev rules [07:24] ACTION=="add", SUBSYSTEM=="usb", PROGRAM="/usr/sbin/obex-check-device $attr{idVendor} $attr{idProduct}", MODE="660", GROUP="plugdev" [07:24] I wonder if it's normal that one of the arguments might go missing [07:24] or if that's another issue to look at [07:24] yes, for sure [07:25] it should at least be robust against that [07:25] s/for sure/possibly/; sorry, that was about "every usb device in /sys", but the rule is "every usb device in /dev" [07:26] seb128: but that whole rule should go, plugdev is a thing of the past [07:26] or at least use the uaccess tag [07:26] I don't even know what obex-check-device does [07:27] * seb128 looks a bit [07:27] just that e.u.c gets quite some report because it segfaulted when called with 1 arg only [07:27] seb128: but I would expect that if the attribute is missing in /sys, it woudl be called with "" "" [07:27] i. e. I thought udev would split args by spaces [07:27] this is not funnelled through a shell [07:28] o/ [07:28] seb128: but having idVendor but not idProduct is indeed odd [07:28] I'd expect both or none [07:28] hey willcooke [07:28] ça va willcooke [07:28] pitti, [07:28] " ProcCmdline: /usr/sbin/obex-check-device 0bda" [07:29] from one of the apport reports [07:32] seb128: interesting, I haven't seen devices which only have a vendor [07:47] bleh - it's like winter here today. < 10 degrees [07:47] raining [08:03] * Laney brrrrrrrrrrrrrrr [08:03] cold today [08:03] hello! [08:03] hey Laney [08:03] hey [08:03] hey Laney happyaron! === Guest30529 is now known as fredp === fredp is now known as Guest22212 [08:06] hey seb128 and pitti and happyaron! [08:06] * Laney greets you from west to east [08:06] how's it going? [08:07] coldly [08:07] * seb128 is pondering putting a sweater on top of the tshirt [08:10] do some star jumps [08:10] I did that ten minutes after sitting down today [08:10] https://launchpadlibrarian.net/261491743/buildlog_ubuntu_yakkety_armhf_ubuntu-touch_BUILDING.txt.gz [08:10] 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] Laney: I dropped upstart-sysv as a supported init in yakkety [08:11] (after discussing with Steve) [08:11] as we won't release any touch products from y [08:12] maybe it's time to switch the touch seeds to systemd-sysv then? [08:16] pitti: That or stop it from building [08:16] at least a year ago or so the phone actually did boot with systemd, and calls/text/3G etc. were all working [08:16] 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] just not the upstart jobs in the touch-whatsitsname-i-ship-fifteen-upstart-overrides package [08:17] seb128: I did see that, yes [08:17] 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] slightly false info in power indicator >> crashing the whole u-s-d [08:18] 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] yeah, nothing new, the u-s-d stack of plugins design :-/ [08:19] same, input device being unplugged while configured and your u-s-d is down [08:19] sarnold: /etc/systemd/system/sshd.service is because of Alias=sshd.service in /lib/systemd/system/ssh.service [08:19] pitti: ah! that seems like a big convenience. :) [08:20] sarnold: i. e. most of that is Aliases [08:20] 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] pitti: indeed I neve rnoticed the symlinks all have different names. alright :) [08:34] sil2100: Thoughts on yakkety touch failures ↑? [09:54] 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] I have a conversion ready for systemd units, but this just adds a whole lot of complexity for no visible gain IMHO [09:55] I don't know why it was done in that way [09:56] maybe it takes a while to start and they wanted to get in before the activation? [09:56] Laney: it actually locks up quite a bit, as the upstart job waits until unity7 is started [09:57] http://bazaar.launchpad.net/~unity-team/bamf/trunk/revision/621 [09:57] not that long ago, actually [09:57] yeah, Trevinho wanted it for the lts [09:58] * pitti looks where teh corresponding MP is [09:58] I just did that [09:58] probably for 'respawn' [09:58] no rational in there [09:59] https://code.launchpad.net/~3v1n0/bamf/upstart-support/+merge/276865 [09:59] https://code.launchpad.net/~3v1n0/bamf/upstart-support/+merge/276865 [09:59] ah [09:59] Laney: but dbus activation alreayd gives you that [09:59] yeah, that's not very helpful [10:00] start on (starting hud or starting unity-panel-service or starting unity7) [10:00] with this you get it pre-emptively [10:00] it now requires this to be correct and covering all use cases [10:00] just trying to think what it might be [10:00] not defending it [10:00] yeah, I guess I'll wait for Trevinho to comment [10:03] 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] sorry, I mean flexiondotorg ^ [10:03] willcooke, OK [10:03] I don't know if it will cause any issues or not, probably not [10:03] i followed up on https://code.launchpad.net/~3v1n0/bamf/upstart-support/+merge/276865, to keep a public record of that [10:03] Laney, pitti, IRC log says [10:03] Ubuntu Server-#ubuntu-desktop.log:févr. 24 15:01:17 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] but I just noticed it as I was trying to fix Ambiance [10:04] willcooke, Thanks for pointing it out, I'll look into it :-) [10:04] seb128: hm, but activation does both, and more precisely [10:05] 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] willcooke, Thanks :) [10:05] seb128: fevr 24? [10:05] that's about something else surely [10:05] those MPs are from november [10:06] Laney, I think his rational was the same/consistent for using upstart in different unity jobs [10:06] but maybe you are right and he was not [10:06] anyway let's wait for him [10:06] I think that was about the zeitgeist thing [10:06] it might have used a similar trick [10:08] 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] 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] so we'd replace those with 25s timeouts [10:10] but I do see the point in logging, that's harder to see from .xsession-errors [10:10] pitti: are you using the systemd bus activation support in your replacement? [10:10] does that work for --user? [10:10] Laney: unfortunately SystemdService= isn't implemented in dbus for user units, that just works for system units [10:10] Laney: i. e. I tried, but this is a no-op [10:11] shame [10:11] well, I tested 1.10.6, haven't checked latest upstream yet [10:14] pitti: wait, dbus? [10:14] I thought this was a generator [10:14] Laney: SystemdService= in dbus *.service files is implemented in dbus [10:15] i. e. dbus activation needs to redirect to systemd if that field is present [10:15] I suppose dbus needs to know how to activate stuff [10:16] I was looking at this dbus1-generator [10:16] maybe I missed something, and that's not the field that we want [10:16] what's that for? [10:16] kdbus? [10:16] i. e. I think there's another mechanism that creates "proxy" connections for the bus names [10:18] Laney: not sure, need to look at that [10:19] oh right [10:20] it makes Type=dbus units from SystemdService= .service files [10:21] ah, so that I could use [10:21] except that I need two additional properties [10:21] and presumably some After=, and I need to install the unit [10:24] seb128, anyone - can you confirm this missing icon? http://imgur.com/xQCxQTP [10:24] could be because I'm dicking around with themes [10:24] also: progressbars are filled in :) [10:26] pitti: why? [10:26] if it's just bus activation then the defaults should be okay? [10:27] 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] to shut them down cleanly when the session goes down [10:28] I suppose bamfdaemon will just crash on "OMG my $DISPLAY went away" with plain dbus activation [10:28] so it's not that bad eitehr [10:28] Laney: I mostly just picked bamfdaemon as the first thing to convert, I guess I should have picked something else :) [10:28] Laney: so, the generated defaults should work, yes [10:29] maybe not 100% cleanly [10:29] The generator doesn't actually do anything for me [10:29] Laney: did you add SystemdService= to anything? [10:30] nevermind, gnome-terminal, gvfs etc. have those [10:30] I have it on loads of stuff already [10:31] https://paste.debian.net/702369/ [10:31] willcooke, icon is fine here [10:32] open("/sys/fs/kdbus/control", O_RDWR|O_NOCTTY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory) [10:32] exit_group(0) = ? [10:32] oh yeah I see this in the code now [10:32] so that won't help anytime soon :) [10:33] but... [10:33] why does it rely on kdbus? [10:33] if dbus-daemon can do systemd activation too [10:33] but for this to be truly useful, dbus-daemon would need to learn systemd activation for user services [10:33] maybe because of that? [10:35] hmm [10:35] is it really that? [10:35] I have a manually created unit (so not depending on that generator) [10:35] I added SystemdService= [10:36] and yet dbus activaiton doesn't start it [10:37] willcooke, do you have aptdaemon-data installed? [10:38] aptdaemon-update-cache.png seems to be the icon it loads [10:43] $ apt-cache policy aptdaemon-data [10:43] aptdaemon-data: [10:43] Installed: 1.1.1+bzr982-0ubuntu14 [10:43] Candidate: 1.1.1+bzr982-0ubuntu14 [10:43] Version table: [10:43] *** 1.1.1+bzr982-0ubuntu14 500 [10:43] 500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages [10:43] 500 http://gb.archive.ubuntu.com/ubuntu xenial/main i386 Packages [10:43] 100 /var/lib/dpkg/status [10:44] pitti: laney@nightingale> systemctl --user start org.gnome.Cheese ~/.config/systemd/user [10:44] Failed to start org.gnome.Cheese.service: Unit dbus.socket not found. [10:44] Laney: missing dbus-user-session ? [10:44] I have it here [10:45] 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] ah right, that provides this? [10:45] don't think I have that [10:45] willcooke, k [10:45] Laney: yes [10:46] indeed [10:46] * Laney whines about having to close session [10:46] * pitti mutters "VM" [10:46] Laney: wait [10:46] haha [10:46] Laney: for this to really work, you need https://launchpad.net/ubuntu/+source/dbus/1.10.6-1ubuntu4 [10:47] or disble upstart session [10:49] got it [10:49] brb [10:52] my that's a nice wallpaper [10:53] good job I like it because that's all I can see [10:53] lol [10:54] HAHA [10:54] Laney: do you have any dbus-daemon running now? [10:54] this is actually amusing [10:54] there's always the one for at-spi2 [10:54] laney@nightingale> cat unity7.override ~/.config/upstart [10:54] but aside from that there should now only be the --address=systemd: one [10:54] manual [10:54] * Laney coughs [10:55] Laney: wow, did you add that half an hour ago, or do you never restart your session? :) [10:55] that's better :) [10:55] I did it a couple of days ago [10:55] when you were asking about .override files [10:55] Laney: ah -- right, that got sorted out, I updated the bug [10:56] indeed [10:56] that was due to that hacky bamfdaemon d-bus activation wrapper [10:56] I just forgot to remove it [10:56] unity7 might not have been the best example to use [10:56] nice trap :) [10:56] ooh no terminal menus [10:57] global menu* [10:57] Laney: bug 1532226 ? [10:57] bug 1532226 in bamf (Ubuntu Xenial) "No menu bar in gtk apps on fresh boot" [Undecided,Fix committed] https://launchpad.net/bugs/1532226 [10:59] Installed: 0.5.3~bzr0+16.10.20160516-0ubuntu1 [11:00] I actually do get the menu in terminals after booting in my yakkety VM [11:01] hey guys [11:02] pitti: anyways, https://paste.debian.net/702431/ <- session bus service got activated by systemd [11:03] hey andyrock [11:03] Laney: I didn't create a .service symlink by the bus name, maybe that's necessary? [11:03] hey andyrock [11:03] Laney: I had thought if I specify SystemdService=bamfdaemon.service that'd be enough [11:04] pitti: ah, I don't know, let me try renaming it [11:04] pitti: this still works [11:04] Loaded: loaded (/home/laney/.config/systemd/user/hellopitti.service; static; vendor preset: enabled) [11:04] Active: active (running) since Wed 2016-05-25 12:04:41 BST; 1s ago [11:05] 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] pitti: that's just http://paste.debian.net/702433/ [11:05] and SystemdService=hellopitti.service [11:06] 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] that's the file I edited, yes [11:06] Laney: oh, wait -- that silly redirectory again [11:07] 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] if you had Exec=/that/wrapper then that seems likely [11:07] urgh [11:08] I vote for dropping all this crazy stuff and using dbus activation then [11:08] +1 [11:09] nevetheless, the general approach should work for other services, so it wasn't in vain [11:09] so I wonder about dropping this kdbus check then [11:20] Laney: indeed, this works absolutely fine [11:20] so this was just this redirection wrapper that fooled me [11:24] * pitti wants bzr commit --amend [11:26] http://bazaar.launchpad.net/~pitti/bamf/systemd-unit/revision/637 fixed [11:27] \o/ [11:27] Laney: so, dropping the kdbus check and automatically wrapping every service into a unit would be great [11:27] building systemd without the check now [11:27] that would give us the per-service logging and restart limit for free [11:27] to see what happens [11:31] Laney: ok, autopkgtest runners seem throughly unhappy; need to grab some lunch and then tend to my minions [11:31] Laney: thanks for looking into the dbus generator! [11:32] np! [11:33] actually, !s390x is running at full steam, just the logtails are broken [11:33] ok, post-lunch problem :) [11:33] queues look big [11:33] damn you qt! [11:33] yeah, we got like 10 Qt uploads in the last few days === hikiko is now known as hikiko|ln [11:34] Mirv, the test infra killer :) [11:35] 2016-05-25 11:35:08,160 INFO:worker adt-run exited with code 1 [11:35] 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] that doesn't look healthy [11:40] * Laney screams at multiarch [11:40] uh oh :( [11:41] s/killer/stress tester/ [11:43] the new KDE release brings its own problems, everything is intertwined. [12:13] Laney: join the chorus! [12:14] I did the same yesterday when I realized that `apt-get update` tries to load i386 package listings from our repository [12:14] which is configured to only contain amd64 and source === JanC is now known as Guest85398 === JanC_ is now known as JanC [12:14] 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] larsu: there's something fishy there [12:17] the internet says it's supposed to be like this [12:17] even though I'd say it's a bug in apt [12:18] I think you're supposed to configure your repository to produce i386 Packages [12:18] if clients are going to be requesting them [12:19] we don't build them, though [12:19] and don't advertise them [12:20] by that logic, we'd always need to build all archs, no? [12:23] Laney: ok, I put an end to the minion strike :) [12:23] Laney: any luck with dropping the patch? [12:23] err, check [12:24] 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 === hikiko|ln is now known as hikiko [12:26] Trevinho: hey! [12:26] 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] Trevinho: bus activation does auto-respawm already [12:26] pitti: Got distracted by talking DMB [12:26] i386 seems to have finished now [12:26] pitti: mh I didn't get that in the past, was there a missing option? [12:27] Trevinho: not really, no; when you try to connect to a non-running service, it'll be activated [12:27] 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] and auto-respawn doesn't help either way for existing connections [12:27] pitti: well for the way libbamf is done (which does quite some caching), this wouldn't cause to be called enough [12:27] or... It would cause to restart bamf on user actions (like alt+tabbing or clicking in the launcher) [12:28] 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] pitti: yes, but we've gdbus doing things internally, so.... At the end our proxy just stays the same [12:29] right [12:30] 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] 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] hey Trevinho! [12:30] hi seb128 [12:30] Trevinho, thanks for the reviews, you did a night shift? 4am comments :-) [12:30] seb128: eh, you know... nights are things I like [12:31] hehe [12:31] Trevinho, I think we have a good stack of usd changes now, we should do a landing [12:32] seb128: yeah, all yours. [12:32] seb128: it would be nice to SRU them all probably too [12:32] so we have both fixes and the x/y delta to the lowest level [12:33] larsu: I guess maybe you could argue that apt should deal with it being missing if it's a foreign architecture [12:33] might be worth asking juliank about that [12:35] I agree [12:35] Trevinho, yeah, need a y landing, then SRU in 2 or 3 rounds [12:35] smalls fixes + keyboard ones [12:35] Trevinho: so in summary, I was wondering how attached you were to this stuff [12:35] seb128: even screensaver one could be nice, since it seems that chrome use that API [12:36] at least... maybe not latest versions, but it used to use only fdo api [12:36] pitti: well... if things work differently when using systemd at user level, I don't mid removing it [12:36] Trevinho: it shouldn't really work differently with upstart either [12:36] pitti: in upstart world, it's something that seems to work better than just using dbus activation [12:36] Trevinho: i. e. I'm still trying to understand the rationale for usptartizing this in the first place [12:37] Trevinho: right, so how does it work better exactly? [12:37] pitti: environment vars were not matching with unity [12:37] pitti: and we had not a proper and immediate respanw [12:37] that was fixed in bug 1433013, no? [12:37] bug 1433013 in upstart (Ubuntu Trusty) "Super -> exec vs Alt-F2 -> exec have different environment" [Medium,Confirmed] https://launchpad.net/bugs/1433013 [12:37] which meant, empty launcher for a while until "something" happened [12:37] pitti: yes [12:38] I'm speaking using the past verb for that thing in fact [12:38] Trevinho: ah, so bamfdaemon does "something" while clients are not talking to it? [12:38] (that would be a good reason) [12:39] 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] 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] (i. e. I disabled the activatino file) [12:41] 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] Trevinho: anyway, if it does active things instead of just reacting, that makes sense [12:42] I didn't see evidence of it and there was no justification in the MP, so I wondered [12:42] yeah, I've not been much clear indeed [12:42] 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] 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] pitti: yeah, I was looking at it... I know it's overcomplicating things a little [12:43] but, nothing we should really touch for years probably [12:46] Trevinho: if you have time can you review compiz merge proposals? [12:46] muktupavels: I see lots of them :) [12:46]