[00:16] <TheMuso`> robert_ancell_: Thats difficult, because its difficult to transition users from using one shortcut to another. The installer still offers both, although the desktop uses the newer shortcut, super + alt + s. Probably worth changing to be consistant.
[00:16] <robert_ancell_> TheMuso`, so should we make u-g do both in trusty?
[00:16] <robert_ancell_> seb128 was concerned about changing the existing key combo
[00:17] <TheMuso`> robert_ancell_: Is that hard to do? Afaik we offer the shortcut via the menu shortcut stuff atm.
[00:18] <TheMuso`> robert_ancell_: Particularly since the menu shows the shortcut as well.
[00:18] <robert_ancell_> TheMuso`, harder than backporting the fix but shouldn't be too hard to change the default to alt+ctrl+s and also support ctrl+s
[00:18] <TheMuso`> Alt + super + S, and yeah sounds good.
[00:18] <TheMuso`> as well as control + s.
[00:19] <robert_ancell_> yeah, that one :)
[04:56] <pitti> Good morning
[04:58] <desrt> hello pitti
[05:00] <pitti> hey desrt, how are you?
[05:00] <desrt> okay
[05:00] <desrt> just writing some NEWS
[06:04] <didrocks> good morning
[06:08] <pitti> bonjour didrocks, ça va ?
[06:15] <larsu> good morning!
[06:16] <didrocks> pitti: ça va bien, et toi ?
[06:16] <didrocks> good morning larsu !
[06:20] <didrocks> hum, keybindings don't work, restarting session
[06:20] <didrocks> and while I'm at it, rebooting under upstart for a test
[06:24] <larsu> good luck ;)
[06:24] <didrocks> interesting, pressing escape on plymouth even on upstart just shows a blank screen, we don't display /dev/console here, maybe only failing jobs…
[06:24] <didrocks> at least, I have my keybindings back now :)
[06:26] <didrocks> larsu: if you try to scroll the volume on the sound menu, don't you see weird behavior
[06:26] <didrocks> when dragging the slider?
[06:26] <larsu> didrocks: yep, it's broken (and on my list)
[06:26] <larsu> there's a bug about it iirc
[06:27] <didrocks> ok, I'm not dreaming then! :)
[06:27] <didrocks> I guess it's due to the 120% patch
[06:27] <larsu> sure?
[06:27] <larsu> I think it worked in U
[06:27]  * larsu wrote that patch and probably tried the slider
[06:28] <didrocks> I'm unsure, the offset seems to match a 20% missing :)
[06:28] <didrocks> like if a callback would reset from the % the slider is completed
[06:28] <larsu> hm, this might be a different issue
[06:28] <didrocks> I don't really know in utopic, most of the time, I'm using the multimedia keys for this
[06:29] <larsu> for me, it simply jumps back to 0
[06:29] <didrocks> … until they broke at login time :)
[06:29] <didrocks> ah
[06:29] <didrocks> try to drag until 80%
[06:29] <larsu> like some event translation problem (sometimes I can make it go to 1/3)
[06:29] <didrocks> right
[06:29] <didrocks> and if you go over 80%, it's setting at 100%
[06:29]  * larsu moves that up in his todo list. didrocks important.
[06:30] <didrocks> larsu: ahah, don't! I just noticed it this morning due to the multimedia keys :)
[06:30] <larsu> didrocks: interesting. I can't try that right now because I can't move it beyond 30%
[06:30] <didrocks> well, still to fix for vivid
[06:30] <larsu> right
[06:30] <didrocks> larsu: I think I will be a good candidate to test your patch then!
[06:31] <larsu> :)
[06:31] <pitti> didrocks: je vais bien, merci !
[06:31] <pitti> nous avons regardé un bon concert hier soir -- "Scrap Arts Music"
[06:32] <pitti> ah, http://scrapartsmusic.com/
[06:32]  * didrocks looks
[06:32] <pitti> they do drums and sounds on metal scrap, plastic pipes, isolation material and what not
[06:33] <didrocks> pitti: sounds interestering! Were they giving a show in your city?
[06:33] <pitti> didrocks: yeah, right in the "Parktheater" which is a 15 mins walk from here
[06:34] <pitti> I love that place -- it's a beautiful theater in "Jugendstil" and they have a lot of nice shows
[06:35] <didrocks> oh, nice! :)
[06:36] <didrocks> I guess that style goes very well with this arts music show :)
[06:36] <pitti> didrocks: well, let's say it's a nice contrast :)
[06:37] <pitti> didrocks: we've seen magic shows and Jazz concerts there, and of course more classical theater plays
[06:38] <pitti> https://de.wikipedia.org/wiki/Kurhaus_G%C3%B6ggingen
[06:39] <pitti> didrocks: would you have some minutes this morning for catching up on some systemd stuff?
[06:42] <seb128> good morning desktopers
[06:42] <seb128> hey pitti
[06:42] <pitti> bonjour seb128, ça va ?
[06:42] <desrt> word up seb
[06:42] <seb128> pitti, is using /lib/systemld
[06:42] <seb128> pitti, is using /lib/systemd/system a debian/ubuntu-ism?
[06:42] <seb128> rather than /usr/lib/systemd
[06:43] <seb128> pitti, oui, et toi ?
[06:43] <pitti> seb128: well, it's an -ism of distros which haven't merged /usr into / yet
[06:43] <pitti> s/yet//
[06:43] <seb128> desrt, good middle-of-the-night
[06:43] <desrt> :)
[06:43] <pitti> seb128: but upstream software isn't supposed to hardcode that path anyway
[06:43] <seb128> pitti, ok, I was reading a bit the systemd documentation to get more familiar with it and upstream documents /usr/lib/systemd so I was wondering
[06:44] <pitti> seb128: yeah, that's for Fedora which installs the entire OS into /usr/ now
[06:44] <seb128> k
[06:44]  * desrt wonders when the debian world will realise the wisdom of os-in-/usr
[06:45] <seb128> pitti, btw I noticed that you added some systemd job without having a Documentation=man:..., should we add that to the recommendations/template we use/...?
[06:45] <didrocks> pitti: 30 minutes? having family here
[06:45] <pitti> seb128: it's in the examples on https://wiki.ubuntu.com/SystemdForUpstartUsers and documented there
[06:46] <pitti> seb128: I added it to most stuff, but indeed I left it out where there are no manpages; did I forget one?
[06:46] <pitti> we might also add some URLs or README files
[06:46] <pitti> didrocks: sure, sounds fine!
[06:47] <didrocks> hey seb128, desrt!
[06:47] <desrt> didrocks: good morning
[06:48] <seb128> pitti, well, e.g ufw doesn't have one and has a manpage, but you did that earlier in the cycle
[06:48] <pitti> seb128: ah, I guess I was young and needed the ... education
[06:48] <seb128> :-)
[06:49] <pitti> seb128: yeah, that one certainly has manpages or other documents
[06:49] <seb128> pitti, I'm trying to educate myself as well
[06:49] <pitti> - debian/rulles: Call dh_systemd_{enable,start}.
[06:49] <pitti> go, pitti, go! spelling R us!
[06:49] <seb128> didrocks, pitti, btw do you have your sysgtemd catchup/discussion in public channels, or just over hangouts?
[06:49] <pitti> seb128: I don't know yet
[06:50] <pitti> seb128: the one I have in mind probably works better over IRC, but I'm fine with HO too
[06:50] <pitti> (i. e. the writing-to-thinking ratio is quite low)
[06:50] <seb128> if you do IRC I'm probably going to keep an eye on it
[06:50] <pitti> seb128: that said, I always enjoy hangouts to actually see my friends :)
[06:50] <seb128> trying to get a bit more involved with that side of things
[06:50]  * pitti hugs seb128
[06:51] <seb128> hehe
[06:51]  * seb128 hugs pitti
[06:52] <pitti> seb128: we got through most stuff, but especially on the phone there's still some bits to port if you are interested
[06:53] <seb128> pitti, yeah, I might have a look at helping there
[06:53] <seb128> and if not I'm going to try to help at least on bugs and maybe on the user session stuff next cycle
[07:12] <didrocks> pitti: as you prefer, we can go on IRC
[07:12] <didrocks> my family will live in a bit, but we can start chatting now
[07:12] <didrocks> leave*
[07:13] <pitti> didrocks: so, I was working on providing a counterpart for static-network-up
[07:13] <pitti> i. e. I want to make network-online.target wait until all "auto" interfaces in /e/network/interfaces are up
[07:13] <pitti> that's similar to NetworkManager-wait-online.service or systemd-networkd-wait-online.service which hook themselves there
[07:14] <didrocks> this is not the default of network-online.target?
[07:14] <didrocks> or is it when the first is up?
[07:14]  * didrocks remembers a wiki page about it, but quite rotten in my mind
[07:14] <pitti> n-o.t by itself does nothing, it just comes up when requested
[07:14] <pitti> you have to "implement" it by adding dependencies to it, such as NetworkManager-wait-online.service
[07:14] <didrocks> gotcha
[07:14] <pitti> but so far we don't have an implementation for ifupdown
[07:15] <didrocks> indeed
[07:15] <pitti> so, you know about our udev rule to activate ifup@.service?
[07:15] <pitti> grep net /lib/udev/rules.d/99-systemd.rules
[07:16] <pitti> that one will call ifup@iface.service which will call "ifup iface" once these interfaces appear
[07:16] <pitti> that is for catching interfaces which are hotplugged/slow to initialize and thus aren't covered by the /etc/init.d/networking run during boot
[07:16] <didrocks> with $name, corresponding to the newly detected device
[07:17] <pitti> so, my initial approach was to write a generator which adds Requires/After=ifup@XXX.service to network-online.target, for XXX in all "auto" /e/n/i
[07:17] <pitti> that was http://paste.ubuntu.com/9792001/
[07:18] <didrocks> but this starts the services, due to Requires?
[07:18] <pitti> didrocks: but at that point I think the "dependencies" approach and the "hotplugged udev event" don't go well together
[07:18] <didrocks> even before they are ready
[07:18] <pitti> didrocks: right
[07:18] <didrocks> yeah, so dependency vs event :)
[07:19] <pitti> didrocks: so if you e. g. make whoopsie Requires/After=network-online.target (the standard way to say "start this service only after we have networking up")
[07:19] <didrocks> it will start network-online.target
[07:19] <pitti> didrocks: then whoopsie and network-online.target will fail with "dependency failure"
[07:19] <didrocks> which will starts all if@
[07:19] <didrocks> ifup@
[07:19] <didrocks> yep
[07:19] <didrocks> because the unit doesn't exist
[07:19] <pitti> if any of the /e/n/i interfaces aren't ready yet
[07:19] <didrocks> well, it exists, but not ready
[07:20] <pitti> didrocks: well, it works if /e/init.d/networking brings them all up
[07:20] <pitti> didrocks: in my experiment I added an "eth42" to /e/n/i which doesn't exist
[07:20] <pitti> but I can make it exist later with 'sudo ip link add name eth42 type veth peer name veth42'
[07:20] <didrocks> oh right, that's how "new ones" come up
[07:21] <pitti> didrocks: so that was my Q on the upstream mailing list -- can I somehow re-trigger the startup of network-oline.target and reverse deps
[07:21] <pitti> didrocks: yeah, that just simulates a hotplug event, or an interface being detected very late during boot
[07:21] <pitti> i. e. that ip link command will create an eth42 device, trigger the udev rule, trigger ifup eth42 through ifup@.service
[07:22] <pitti> didrocks: so that's where in http://paste.ubuntu.com/9792001/ the last paragraph comes into play
[07:22] <didrocks> hum
[07:22] <pitti> didrocks: whenever an ifup@.service starts, it re-triggers network-online.target with the Wants=network-online.target
[07:22] <pitti> didrocks: so while that bit works fine, this doesn't propagate "upwards", i. e. everything *depending on* n-o.target won't start
[07:23] <pitti> i. e. it's the same problem one level up
[07:23] <didrocks> sure, as it's not an event
[07:23] <didrocks> it's just "that destination is reached"
[07:23] <pitti> because fundamentally, when you start a unit, it starts all of its deps, and if anything fails it fails itself too
[07:23] <didrocks> yep
[07:24] <pitti> so I was wondering if you have a clever idea about "try to re-start everything which depends on n-o.target" in n-o.target
[07:24] <pitti> which is arguably turning the design upside down, but I wondered if it's possible
[07:24] <pitti> as that's basically what you need to trigger units on hardware
[07:24] <didrocks> I guess from the dbus API, we can list all failed units and redo the logic…
[07:24] <didrocks> but then, you have the rdepends on the rdepends…
[07:24] <didrocks> and so on
[07:25] <didrocks> sounds hackish
[07:25] <didrocks> so, that would mean:
[07:25] <didrocks> - listing failed units, check the reason and that they Requires/Wants n-o.target
[07:25] <didrocks> - restarts them
[07:25] <pitti> didrocks: well, instead of re-triggering, it would be enough to not fail into dep-wait, but instead just wait (with a timeout) until your requirements become ready
[07:25] <didrocks> - check if there was no rdepends on those units
[07:25] <pitti> didrocks: yeah, doing all that is crazy, and a "you don't want to do that", I think
[07:25] <didrocks> so n-o.target waiting forever?
[07:25] <didrocks> yeah ;)
[07:26] <didrocks> the waiting would be better
[07:26] <pitti> didrocks: so, yesterday I finally gave up and opted for a very simple "waiting" solution
[07:26] <didrocks> as it's really what you want to express
[07:26] <pitti> didrocks: http://paste.ubuntu.com/9787017/
[07:26] <didrocks> the target isn't really ready until all interfaces are up
[07:26]  * didrocks looks
[07:26] <pitti> didrocks: it's basically what {NetworkManager,systemd-networkd}-wait-online.service do -- these services wait until the network is up, then exit, and then the unit is started
[07:27] <didrocks> +TimeoutStartSec=2min -> the issue of course, is that you have to quantify…
[07:27] <pitti> didrocks: ^ the 2 mins is to copy the  behaviour of /etc/init/networking
[07:27] <pitti> ... .conf
[07:28] <pitti> (default is 1.5min, which would certainly work too, but that's just a detail..)
[07:28] <didrocks> well, better to express it explicitely
[07:28] <didrocks> TBH, the wait solution is the less hackish to me
[07:29] <didrocks> as it's really what you want to express
[07:29] <pitti> didrocks: so, I don't find that very elegant, with the polling loop
[07:29] <pitti> but in essence, I think it fits the design best, and mirrors what the other "implementations" of n-o.t do
[07:29] <didrocks> pitti: can't we have a simple daemon receiving some udev events?
[07:29] <didrocks> instead of polling
[07:29] <pitti> didrocks: that's not enough
[07:29] <pitti> ifup'ing an interface doesn't send out uevents
[07:29] <pitti> ifup is ... special
[07:30] <didrocks> ah… :)
[07:30] <pitti> you actually have to ask ifquery whether an interface is up
[07:30] <pitti> that's the only guaranteed way
[07:30] <didrocks> ok, hence being bound to polling
[07:30] <pitti> you can't even rely on ifup's exit status (debian bug 773539), but that wouldn't help that much either
[07:32] <pitti> didrocks: so, I think it's an ok way to get the correct behaviour (I tested it in a VM pretty extensively), it's just not terribly elegant
[07:33] <didrocks> yeah, and we can't really get that in a dependency fashion to reevaluate it
[07:34] <pitti> now the only question is whether we want n-o.target to fail after two mins (by instsalling it into network-online.target.requires/) or to succeed after two mins (by installing it into network-online.target.wants/)
[07:34] <pitti> so far under upstart we have a "fallback mode" which boots the system anyway after 2 mins, so I went with wants/ for now
[07:35] <pitti> which means, whoopsie whould start after 2 mins if an interface fails
[07:35] <pitti> which for most applications is probably what we want -- the standard case is to wait for all ifaces so that you can bind on all network addresses
[07:35] <pitti> i. e. for old-skool servers which don't react to hotplugged interfaces
[07:36] <pitti> didrocks: so, if you don't have a better idea either, I guess I'll go with that ifupdown patch?
[07:36] <didrocks> I'm trying to think about it
[07:37] <didrocks> give me 15 minutes, I'm experimenting something
[07:38] <pitti> cat <<EOF | sudo tee /etc/network/interfaces.d/eth42.cfg
[07:38] <pitti> auto eth42
[07:38] <pitti> iface eth42 inet static
[07:38] <pitti>         address 192.168.2.42
[07:38] <pitti> EOF
[07:38] <pitti> didrocks: ^ that's what I did to add a non-existing interface at boot
[07:38] <pitti> sudo ip link add name eth42 type veth peer name veth42
[07:38] <pitti> and that's how you bring it up after boot
[07:38] <didrocks> thanks! trying with this
[07:39] <pitti> (another day of yaying for super-quick throw-away VMs, thank you QEMU!)
[07:39] <didrocks> heh, indeed!
[07:42] <didrocks> pitti: yeah, forget about it, this isn't going to work…
[07:43] <didrocks> however, thinking about it, why wouldn't we create another target?
[07:43] <didrocks> like network-online.target -> at least, one interface is up
[07:43] <didrocks> network-online-all.target (or whatever)
[07:43] <pitti> didrocks: I had a version of the generator with creating ifup-all-auto.target and adding deps there, but that makes the problem worse
[07:43] <didrocks> that way, we don't delay the whoopsie startup
[07:43] <pitti> well, the problem isn't delaying the woopsie startup -- it's not starting it up at all if not all ifaces are ready at boot
[07:43] <didrocks> as most of services only need "some connexion"
[07:44] <pitti> of course whoopsie is just my usual test guinea pig -- whoopsie doesn't actually need a n-o.target dep
[07:44] <pitti> (i. e. you have to hack its .service to add this)
[07:44] <didrocks> hum, why would we want to start it without network connection?
[07:45] <pitti> didrocks: as for "why do services want to delay their startup until all interfaces are up", that's a different discussion
[07:45] <pitti> servers usually bind to all available interfaces during startup
[07:45] <pitti> and if you bring up an interface later, they won't automatically bind to that
[07:45] <pitti> unless they listen to udev and re-bind, etc.
[07:45] <didrocks> you think it's the majority? I would say it's the minority actually
[07:46] <pitti> didrocks: so whether to have different targets for both cases is of course also something which we can discuss
[07:46] <pitti> but it still has the same problem
[07:46] <didrocks> and if we explicitely divide that in 2 targets, we can have one succeeding, and the other one failing
[07:46] <pitti> a direct "hardware comes up" -> "start a unit" link is easy
[07:46] <pitti> add a SYSTEMD_WANTS=foo.service in an udev rule
[07:46] <pitti> but putting any indirection in between seems hard
[07:47] <pitti> like, make that uevent activate a service which implements a target
[07:47] <pitti> well, I guess I'll re-send that to the upstream ML
[07:47] <didrocks> I'm a little uneasy if we are making it failing if any interface doesn't come up to basically say "there is no network at all"
[07:48] <didrocks> but I can see you want to know it…
[07:48] <pitti> didrocks: well, that's how stuff has worked for years in Ubuntu with the upstart jobs
[07:48] <pitti> and they do time out after 2 mins and start anyway after that
[07:48] <pitti> stgraber wrote that as at early boot, when /etc/init/networking.conf (or /etc/init.d/networking) runs, often some interfaces aren't ready yet on big servers
[07:49] <didrocks> so, even on upstart, we didn't retrigger an event to say "there is more interfaces, please reevaluate"
[07:49] <didrocks> are*
[07:49] <pitti> didrocks: and this only applies to services which explicitly depend on network-online.target (which isn't actually a lot; but they did come up during porting)
[07:49] <pitti> didrocks: we did
[07:50] <pitti> net-device-up <NAME>
[07:50] <didrocks> ah, so, we restarted let's say apache… as a consequence (or reload)
[07:50] <pitti> but we already have that -- the uevent, plus the systemd .device unit
[07:50] <pitti> didrocks: correct; look at e. g. /etc/network/if-up.d/openssh-server
[07:51] <pitti> didrocks: that restarts openssh on new interfaces
[07:51] <pitti> and that's the correct way to do it
[07:51] <didrocks> ah, but we are getting that in a non systemd way
[07:51] <didrocks> but with those specific rules
[07:51] <didrocks> in /etc/network/if-up.d/
[07:51] <didrocks> yeah, kind of making sense
[07:51] <pitti> but we need the "static-networking-up" (upstart), respectively network-online.target for "old-skool" servers which aren't designed for hotplugging, but just for a server world of static interfaces
[07:52] <didrocks> yeah, I think your approach is good enough for most of the case anyway
[07:52] <pitti> i. e. where you just want to extend the notion of "boot" a bit
[07:52] <didrocks> right
[07:52] <pitti> it's not a clearly defined semantics anyway, I mostly wanted to mirror what we do on upstart
[07:53] <pitti> it gets you a little closer to the old "static" world where you define stuff in /e/n/i and assume it's there
[07:53] <pitti> for a desktop it's entirely a no-op
[07:53] <didrocks> I think that would be an interesting case, where "boot" isn't an answer for those, for the systemd hackfest
[07:53] <didrocks> we do have your solution which is mostly working (as you told, no-op on desktop, mirroring what we did on server)
[07:54] <didrocks> but maybe we can really look how to pull that further and be more dynamic
[07:54] <pitti> yeah
[07:54] <didrocks> did you discuss about it with Lennart already?
[07:54] <pitti> didrocks: only very quickly, but I think I explained it wrongly; I'll re-explain it on the ML
[07:55] <didrocks> yeah ;)
[07:55] <didrocks> tricky!
[07:55] <pitti> "how to make hardware activated targets" basically
[07:55] <didrocks> I think the "force reevaluating" is maybe an answer
[07:56] <pitti> didrocks: right, and that works fine for re-evaluating network-online.target itself, through the extra "Wants" in the ifup@.service
[07:56] <pitti> but not for its rdepends
[07:56] <didrocks> yeah, I more "reevaluating all failed-units"
[07:56] <didrocks> meant*
[07:57] <didrocks> like, it can be a keyword as part of the transaction
[07:57] <didrocks> pitti: ok, I'll update you on plymouth/fsck, back in 5 if you don't mind?
[07:57] <pitti> didrocks: sure!
[07:57] <pitti> didrocks: I need to leave for a doctor appt. in ~ 20 mins FYI
[07:57] <pitti> takes about 30 mins
[07:58] <pitti> 1 min to get the allergy shot, and 30 mins sitting there reading the news, in case something goes wrong
[07:58] <pitti> (never happened, but oh well, they insist)
[07:59]  * pitti goes back to testing ubuntu CD insertion with update-notifier, to fix its upstart job
[07:59] <pitti> ugh CDs, who has them still?
[07:59]  * pitti plays with QEMU hot-adding virtual drives
[08:00] <darkxst> how does one plug a CD into qemu ;)
[08:00] <pitti> by squeezing really hard!
[08:01] <pitti> you can add an empty drive with -drive if=ide,index=1,media=cdrom
[08:01] <pitti> and send a monitor command to insert a "medium" (from an image), which I'm currently RTFMing about
[08:02] <darkxst> pitti, or just melt the CD and plug it into the USB port ;)
[08:02]  * didrocks back
[08:02] <pitti> actually, -drive media=cdrom is enough
[08:02] <didrocks> pitti: I really think that if systemd internals can reevaluate (not restart), but retry failing jobs and only try restarting one path that makes sense with the new state of the world…
[08:03] <didrocks> let's see what upstream thinks about it
[08:03] <didrocks> pitti: ok, so on fsck/plymouth
[08:03] <pitti> yeah, something for the hackfest
[08:03] <didrocks> I have multiple systemd-fsck process talking to one central systemd-fsckd
[08:03] <didrocks> and systemd-fsckd talking to plymouth
[08:04] <didrocks> I hacked our ubuntu logo theme to get those info
[08:04] <didrocks> which means:
[08:04] <didrocks> - systemd grows a dep on plymouth
[08:04] <didrocks> - I factorized plymouth communication in the shared static lib
[08:04] <didrocks> I have to update the text theme + xubuntu and such to this new protocol
[08:05] <didrocks> also, there are some fixes for some corner cases, like reconnecting if plymouth respawn
[08:05] <didrocks> I'm stuck on i18n though
[08:05] <pitti> didrocks: you mean libplymouth, right? or plymouth the daemon?
[08:05] <didrocks> libplymouth
[08:05] <mlankhorst> morning :P
[08:05] <pitti> didrocks: oh, plymouthd crashing in the middle of fsck'ing, and you can survive that?
[08:05] <pitti> hey mlankhorst, how are you?
[08:05] <didrocks> hey mlankhorst
[08:06] <mlankhorst> hey I'm good :-)
[08:06] <didrocks> pitti: yeah, right now, I survive, but I don't reconnect to the new one
[08:06] <pitti> ambitious!
[08:06] <didrocks> well, shouldn't be too hard, like a 20 minutes job testing included :)
[08:06] <didrocks> so yeah, then adding the .services, writing manpages…
[08:06] <didrocks> I'm just worried about this i18n
[08:07] <pitti> darkxst: ah, awesome! FTR: change ide0-cd0 /home/martin/Downloads/ubuntu/vivid-desktop-amd64.iso
[08:07] <didrocks> - the first version of plymouth theme (the code is still there, just not in use) did create the string shown to the user
[08:07] <darkxst> pitti, given I don't have a functioning cd drive, melting might work better ;)
[08:07] <didrocks> - then, mountall sent the translation as part of the message and that's what is used with upstart nowdays
[08:08] <pitti> darkxst: it's all virtual :) (I don't have a physical CD drive either)
[08:08] <didrocks> - systemd doesn't have any i18n facility…
[08:08] <pitti> didrocks: oh, you mean s-fsckd will already generate the strings, not the theme
[08:08] <didrocks> it seems it makes sense to do that on systemd-side, but maybe different themes wants different message to display and we just send the metadata?
[08:08] <pitti> didrocks: systemd does have i18n
[08:08] <didrocks> the theme doesn't support i18n either
[08:08] <didrocks> hum, really?
[08:09] <pitti> didrocks: yeah, mostly for the .policy files (polkit)
[08:09] <pitti> didrocks: but also for the CLI tools
[08:09] <darkxst> pitti, CD's are a physical media that can't be virtualised ;) iso's on the other can ;)
[08:09] <didrocks> pitti: I did only see the policy files, which is different, not the CLI tools
[08:09]  * didrocks looks
[08:09] <pitti> didrocks: oh right
[08:10] <didrocks> yeah, regrepped and nothing
[08:10] <pitti> didrocks: I guess there's something to be said to leave the representation to the theme
[08:10] <pitti> some themes might want this entirely graphical, or on really small screens or whatever
[08:10] <didrocks> pitti: I agree, that's the current implmentation
[08:10] <didrocks> but!
[08:11] <didrocks> .script doesn't seem to support i18n
[08:13] <didrocks> not an issue for the C themes of course, but our main one is a script…
[08:13] <pitti> didrocks: hmm, if themes don't suppor that, how do we i18n this today?
[08:13] <didrocks> pitti: as told, that was put into mountall which send the strings to the theme
[08:13] <pitti> eww, yes
[08:13] <didrocks> as part of the message
[08:14] <pitti> didrocks: and "script" can't call shell tools like "gettext", I suppose?
[08:14] <didrocks> which sounds wrong to me
[08:14] <pitti> yes, it is
[08:14] <didrocks> I didn't try, didn't see that in practice
[08:14]  * didrocks looks for example, but theme documentation is really thin
[08:17] <didrocks> yeah, nothing obvious at least
[08:18]  * pitti looks at themes/ubuntu-logo/ubuntu-logo.script
[08:19] <didrocks> pitti: btw, as told, I tried to be minimal in my patch in the theme, meaning, I don't touch most of the rest of the logic
[08:19] <didrocks> but there is a lot of already dead code due to design changes
[08:19] <didrocks> (like the progress bars)
[08:20] <didrocks> and all the fsck logic was there
[08:20] <pitti> didrocks: hm, I can't imagine why plymouth themes wouldn't have their own text/i18n, but maybe they did design it like that, that clients have to create the strings
[08:20] <pitti> didrocks: adding i18n to fsckd doesn't seem much of a problem really; add it to po/POTFILES.in and use glibc's gettext
[08:20] <pitti> but I wonder if that's the right design
[08:20] <pitti> well, obviously it's the current design
[08:21] <didrocks> pitti: I don't think it is as it means, we are forcing upon each themes our strings
[08:21] <didrocks> well, forcing/proposing :)
[08:21] <didrocks> (as we can keep, as of today, the metadata as well)
[08:24] <pitti> didrocks: need to run for appointment, back in 30; but I guess for now let's put the strings into fsckd then?
[08:24] <didrocks> pitti: yeah :/
[08:24] <didrocks> pitti: just to be complete on the fsck question: we won't implement the question about "your partition is broken, do you want to fix it?" as systemd-fsck force repair by default
[08:24] <didrocks> I need to implement the escape feedback though
[08:24] <pitti> at least with that themes don't have to copy&paste the fsck messages
[08:24] <didrocks> like you press escape -> cancel all fsck jobs
[08:24] <pitti> right
[08:24] <pitti> we mostly just need the "checking, NN%  done" and maybe the cancel
[08:24] <didrocks> right
[08:25] <didrocks> so, doing the escape first
[08:25] <didrocks> and text theme, should be easy
[08:25] <didrocks> i18n -> I'm quite "sad" :/
[08:32] <didrocks> hum, ubuntu-text never supported fsck messages
[08:32]  * didrocks wonders if it worths it to add that now (it's in C)
[09:02] <willcooke> good morning all
[09:03] <pitti> hey willcooke
[09:03] <pitti> didrocks: hm, we install that on servers, right?
[09:03] <pitti> didrocks: but if fsckd sends the messages, wouldn't -text get that automatically?
[09:04] <Laney> hallo
[09:04] <didrocks> pitti: we install that on the client as well, it's shown when you have nvidia cards
[09:04] <didrocks> pitti: and no, there is no room for "update" message into that theme
[09:05] <didrocks> (like no sprite placement)
[09:05] <pitti> oh, ok
[09:05] <willcooke> Laney, bad news...
[09:05] <willcooke> Laney, no tenner found.
[09:05] <didrocks> pitti: the one on the right: http://i.stack.imgur.com/EPKXz.png
[09:06] <Laney> willcooke: oh well, I'll take that raise then
[09:06] <willcooke> I might be in the office this week, I'll be sure to check down the back of the sofa in reception for your "raise"
[09:06] <Laney> :-)
[09:10] <didrocks> hum, can't get the disconnect signal from plymouth :/
[09:30] <didrocks> pitti: I'm unsure that we tested disconnection from plymouth in a long time
[09:30] <didrocks> the issue is that the even loop is stuck, and so is the daemon…
[09:31] <didrocks> I'm checking what we are doing in casper or mountall, and it seems to be the same though
[09:32] <seb128> Laney, hey, btw it seems the upower transition was a redherring on that sleep issue on the device
[09:32] <pitti> didrocks: I'm unsure that we tested anythign in plymouth recently :/
[09:32] <pitti> it's quite a bit of a bitrot case
[09:33] <pitti> didrocks: i. e. our current approach is to hope that plymouth won't crash? :/
[09:33] <didrocks> pitti: seems so, if it does, I'm pretty sure mountall or md5check is stuck
[09:33] <didrocks> pitti: we have a disconnect handler, bound
[09:33] <didrocks> but it's only trigger from plymouth code on ply_event_loop_process_pending_events()
[09:33] <didrocks> triggered*
[09:34] <Laney> seb128: oh yeah?
[09:34] <didrocks> which we already use of course to send the update to plymouth
[09:34] <didrocks> but if plymouth quits, ply_event_loop_process_pending_events() is stuck
[09:34] <didrocks> I guess I have to printf in plymouth to see where it's stuck…
[09:34] <seb128> Laney, yeah, apparently the issue is not easy to trigger and the testing is a bit flacky/make difficult to confirm what image is good or not
[09:34] <seb128> Laney, seems all images get the issue in some random ways
[09:35] <Laney> so we're not sure if it even got worse?
[09:35] <pitti> didrocks: erk, that's awful; i. e. whenever plymouth would crash (and it does that a lot), essentially the whole boot is stuck
[09:35] <seb128> Laney, seems not
[09:36] <didrocks> pitti: I'm still unsure, can be me not doing something right, but I can't see the immediate issue and the difference I would have with mountall or md5check
[09:36] <didrocks> so printf time!
[09:37] <pitti> didrocks: yuck! I hope it gets captured in the journal :)
[09:38] <didrocks> pitti: let's see… I feel it's going to be a "fun" day
[10:07] <pitti> didrocks: uploading ifupdown now; it's all static files, so we can always improve this stuff
[10:10]  * pitti documents that on https://wiki.ubuntu.com/SystemdForUpstartUsers
[10:18] <Laney> seb128: btw, you went offline when I tried to reply to you yesterday then I forgot - yes, taking care of poppler
[10:18] <seb128> Laney, great, thanks
[10:19] <seb128> yeah, I did some unity8 playing with which got me out of IRC for a while
[13:35] <didrocks> ah, I think I got the plymouth hangups
[13:35]  * didrocks tries something
[13:36] <didrocks> \o/
[13:36] <seb128> got to the bottom of it?
[13:37] <didrocks> yeah
[13:37] <didrocks> basically, you need to attach the event listener after you are connected to plymouth
[13:37] <didrocks> which may creates a race, and that's why I did the other way around
[13:37] <didrocks> but in that case, it doesn't reregister the disconnection handler
[13:37] <didrocks> and then, next listen on the queue just hangs
[13:38] <didrocks> it's tricky, because if you attach the listener before you connect to plymouth, all events are passed well
[13:38] <didrocks> apart from the disconnection…
[13:39] <didrocks> I see that casper-md5check does the same than I did btw
[13:39] <didrocks> so I guess the process would hang if plymouth crashes
[13:39]  * didrocks adds a TODO
[13:41] <didrocks> pitti: FYI ^
[13:43] <didrocks> seb128: the issue is that the plymouth code is copying the reference at attach time, instead of refering directly to the object
[13:44] <seb128> didrocks, is that still in context of the fsck integration to plymouth?
[13:45] <didrocks> yeah
[13:45] <didrocks> why?
[13:46] <seb128> just curious, I didn't follow closely the issue, trying to make sense of what you describe
[13:58] <pitti> didrocks: "other way round"? you can attach to a listener before connecting? anyway, I'm afraid I know next to nothing about it, so great that you found it!
[14:01] <didrocks> pitti: yep! Cleaning up the code base and then trying multiple plymouth reconnect
[14:03] <Sweet5hark> jcastro: I heard you do lobbying in europe now: https://cdt.org/staff/jorge-castro/
[14:03] <jcastro> hah, good to know
[14:16] <didrocks> ok, now, can reconnect to any new plymouth connexion and resend last update \o/
[14:16]  * pitti ^5s didrocks
[14:16]  * didrocks ^5s back
[14:17] <didrocks> ok, so control+C now
[14:17] <didrocks> then, will remain i18n and the "what to do with the text theme?"
[15:12] <Laney> seb128: poppler in NEW if you have a few minutes to look
[15:13] <willcooke> seb128, all - might be 5 mins late for the meeting again, school run.  Should be back in time though...
[15:23] <seb128> Laney, sure
[15:23] <seb128> wk
[15:23] <seb128> willcooke, k
[15:24] <Laney> ty
[15:31] <willcooke> back
[15:31] <desrt> mmmmmmm
[15:31] <desrt> mmmmmmmmmmmm
[15:31] <willcooke> #startmeeting Desktop Weekly Team Meeting 2015-01-20
[15:31] <meetingology> Meeting started Tue Jan 20 15:31:25 2015 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:31] <meetingology> Available commands: action commands idea info link nick
[15:31] <desrt> meeting!
[15:31] <willcooke> Roll call coming up....


[15:33] <qengho> DIALING...
[15:33] <willcooke> attente_, desrt, dgadomski_ didrocks, FJKong , happyaron , Laney larsu mlankhorst qengho seb128 Sweet5hark
[15:33] <dgadomski_> hello everyone o/
[15:34] <desrt> here :)
[15:34] <didrocks> hey!
[15:34] <FJKong> hey
[15:34] <seb128> _o/
[15:34] <Sweet5hark> o/
[15:34] <larsu> yep
[15:35] <willcooke> lets do this thing
[15:35] <willcooke> #topic attente_
[15:35] <attente_> hi
[15:35] <attente_> not much to report, did some more testing for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1408593 and https://bugs.launchpad.net/mir/+bug/1409133
[15:35] <attente_> tried switching over to using the new mir menu api, but blocked on lack of support in the demo shell, looked into adding it
[15:36] <desrt> attente_: did you see that popovers in gtk are using wayland subsurfaces now?
[15:36] <desrt> probably worth seeing if they can be done the same way on mir
[15:36] <desrt> would be nice to have a feature that works better in mir than it does in x11 ;)
[15:37] <attente_> you mean implementing subsurfaces in mir?
[15:37] <desrt> i was thinking that the menu positioning stuff is really just the same as subsurfaces, no?
[15:38] <desrt> ie: a new surface that is related to and has a relative position to another existing surface but is not necessarily clipped by it
[15:38] <attente_> the api adds some extra stuff to determine where to position the surface if it overflows outside of the screen though
[15:38] <larsu> attente_: I've started looking into gtk mir too. I'll help out starting very soon
[15:39] <larsu> attente_: let me know if you need something specific (if not, let's talk at the sprint)
[15:39] <desrt> attente_: ya... i'm sure it won't be 1:1 easy... but probably worth looking into it to see how it can be done... maybe it needs some more changes in mir, maybe not
[15:39] <desrt> would be good to know that ahead of the sprint week
[15:40] <larsu> mir has a "menu" api?
[15:40] <desrt> just an api for positioning menu-like windows
[15:40] <attente_> yeah
[15:40] <desrt> not gmenumodel or anything, if that's what you're thinking :)
[15:40] <attente_> but tbh i don't think gtk needs it
[15:40] <seb128> larsu, https://code.launchpad.net/~albaguirre/mir/add-menu-api/+merge/244632
[15:40] <attente_> because gtk seems to adjust the position inside the screen itself
[15:41] <larsu> desrt: no I wasn't thinking that. Just sounded a bit too specific for a window manager
[15:41] <larsu> seb128: thanks!
[15:41] <seb128> yw :-)
[15:41] <desrt> rule 1) window managers must not handle menus
[15:41] <desrt> rule 2) feel free to violate rule 1, as long as you write it in javascript
[15:42] <larsu> desrt: seems like gerry was against this (in addition to other people)
[15:42] <attente_> should we ask them to revert that api?
[15:42] <desrt> er wait what?
[15:43] <larsu> attente_: no, looks like there was quite a bit of discussion around it
[15:43]  * larsu trusts that they came to some kind of consensus
[15:43] <attente_> because gtk is already fixing the position of the menus itself
[15:43] <seb128> seems like the sort of topic better to discuss in Brussels
[15:43] <desrt> ya...
[15:43] <larsu> ya
[15:43]  * desrt is a bit surprised to be hearing this now
[15:43] <willcooke> ok cool
[15:44] <seb128> desrt, it landed less than a week ago
[15:44] <willcooke> I will add this topic to my list of Brussels things
[15:44] <desrt> seb128: ya.  i know.  i was kinda assuming that it didn't suck.
[15:44] <seb128> willcooke, good idea
[15:45] <willcooke> one sec while I add it....
[15:45] <willcooke> (otherwise I will forget)
[15:45]  * Sweet5hark is available as an adjutant for duels in bruessels
[15:46] <willcooke> #topic desrt
[15:46] <desrt> hi
[15:46] <desrt> not lots to say.  still working on file monitors
[15:46] <desrt> this turned into quite a large job
[15:47] <desrt> plus the usual bugs/reviewing/etc. stuff has been keeping me from it a bit
[15:47] <desrt> the good news is that they work.  the bad news is that the branch is in an ugly state and needs to be cleaned up and there are surely some bugs left to fix
[15:47] <desrt> that's all
[15:48] <willcooke> thanks desrt
[15:48] <willcooke> #topic dgadomski_
[15:48] <dgadomski_> This week in the widely understood around-desktop area it was:
[15:48] <dgadomski_> * established a working setup for testing bug #1104230, solved 2 problems, continuing debugging, new kernel build available in ppa:dgadomski/linux-mst
[15:48] <dgadomski_> * got positive feedback on fix to bug #1020210, got it sponsored, waiting for it being reviewed and land in -proposed
[15:48] <dgadomski_> * still working on implementation to fix bug #1337873
[15:48] <dgadomski_> * thanks to cyphermox I was able to move forward with bug #1410779, waiting for more feedback from the user
[15:48] <dgadomski_> * following upstream decisions regarding the future of bug #445333
[15:48] <dgadomski_> EOF
[15:49] <willcooke> thanks dgadomski_ - do you need anything from us right now?
[15:49] <dgadomski_> no, thanks, I'm ok currently :)
[15:50] <willcooke> cool
[15:50] <willcooke> #topic didrocks
[15:50] <didrocks> Ubuntu Make:
[15:50] <didrocks> * Reviewing IDEA (non community) edition integration into Ubuntu Make
[15:50] <didrocks> * Get jayatana installed by default (pulled by appmenu package)
[15:50] <didrocks> Systemd:
[15:50] <didrocks> * systemd sprint, continues converting a bunch of packages: powernap, lxc-android-config, conmux, bluetooth-touch, mosquitto, edubuntu-server
[15:50] <didrocks> * pair with Martin to get a crude version of Ubuntu Touch to be started under systemd. We can even ssh to it now and get Unity8 running \o/ Still some work needed for a lot of jobs to run.
[15:50] <didrocks> * discussed about the android property bridge and did some testing/debugging on it.
[15:50] <didrocks> * finish fsck daemons all connecting to fsckd, and get fsckd talking to plymouth + change plymouth (ubuntu logo) theme. Still some opened questions before integrating that to systemd upstream like where to put i18n… Need as well Ctrl+C integration.
[15:50] <didrocks> Misc:
[15:50] <didrocks> * Helped FJKong debugging some segfaults using qt.
[15:50] <didrocks> .
[15:51] <didrocks> (loosing right now some hairs on getting a nice systemd/plymouth integration)
[15:52] <willcooke> thx didrocks
[15:53] <desrt> didrocks: excellent job!
[15:53] <willcooke> #topic FJKong
[15:53] <FJKong> * bug tracking: change font size does't works in setting, can't reproduce on my computer
[15:53] <FJKong> * bug fixing: crash after clicking apply then clicking menu to change skin, fixed it this week
[15:53] <FJKong> * bug tracking: memory leak when using ImageProvider, processing it
[15:53] <FJKong> * streghthen skin structure
[15:54] <FJKong> mainly focusing on fix bugs about sogou
[15:54] <FJKong> that's all
[15:55] <willcooke> thanks FJKong
[15:55] <willcooke> #topic happyaron
[15:56] <willcooke> happyaron, might not be around - timeout set at 2 mins.  We can always come back around.
[15:56] <larsu> timeout. so much pressure.
[15:57] <qengho> His packets DO have to travel pretty far.
[15:57] <larsu> haha indeed
[15:58]  * Sweet5hark gets the pressure feels too.
[15:58] <willcooke> #topic Laney
[15:58] <Laney> • Split a-i-t. Need to move reverse-deps of gnome-icon-theme over
[15:58] <Laney> • Fix oslo-config upgrade SNAFU
[15:58] <Laney> • yelp crash fix
[15:58] <Laney> • evolution point release, SRU this to utopic too
[15:58] <Laney> • new vala, contains binding security fix so rebuild affected rdeps
[15:58] <Laney> • new webkitgtk, build problem, propose a fix upstream
[15:58] <Laney> • new gtk+3.0, also some chat about a security fix in trusty
[15:58] <Laney> • Get dose-distcheck deployed to the transition tracker to fix parsing error there
[15:59] <Laney> • poppler 0.30.0, will be a transition. also SRU a fix for some ligatures not displaying correctly to utopic and trusty
[15:59] <Laney> • Start DMB election nomination period
[15:59] <Laney> • Some poking flavours about alpha 2 which is meant to be this week, might cancel it due to lack of help
[15:59] <Laney> • Get sponsor queue to display ubuntu-desktop branches
[15:59] <Laney> ⚒
[15:59] <willcooke> thx Laney
[15:59] <desrt> Laney: new glib too
[15:59] <Laney> oh yes
[15:59] <desrt> with your NM Stuff...
[15:59] <Laney> https://packages.qa.debian.org/g/glib2.0/news/20150120T153405Z.html
[16:02] <willcooke> #topic larsu
[16:02] <larsu> hey!
[16:02] <larsu> * theme finally doesn't depend on unico anymore
[16:02] <didrocks> \o/
[16:02] <desrt> larsu just won the meeting
[16:03] <seb128> larsu, I've been running your branch, didn't notice any issue/difference
[16:03] <desrt> next he's going to tell us overlay scrollbars are dead or something
[16:03] <larsu> * more theme fixes for spinners, some backgrounds, etc
[16:03] <larsu> * also lots of cleanup (removed unused rules and files)
[16:03] <larsu> seb128: nice! There's another one as well. Would be cool if we could merge them soon
[16:03] <larsu> seb128: thanks
[16:03] <larsu> desrt: not yet, though I've played around backporting the upstream ones
[16:03] <seb128> great, we should probably put those in a silo when you feel like they are ready for landing
[16:04] <desrt> larsu: "we need to talk...."
[16:04] <larsu> desrt: I think we should just wait though. Just one cycle is not worth the hassle
[16:04] <larsu> seb128: can you please do that? You have the power ;)
[16:04] <larsu> desrt: _we_ do?
[16:04] <desrt> larsu: yes.  protocol violation here
[16:04] <seb128> larsu, if you are happy with your current work and want to land it, sure
[16:04] <desrt> don't waste time backporting when you're gonna see laney in a couple of weeks
[16:05] <desrt> just make sure you have enough money in your beer fund
[16:05] <larsu> seb128: yes please - thanks
[16:05] <Laney> correct
[16:05] <larsu> haha
[16:05] <larsu> slippy-finger time!
[16:05] <larsu> anyhow:
[16:06] <larsu> * started looking into gtk/mir to be able to jump into it at the hackfest
[16:06] <seb128> I'm happy to drink beers with you guys while Laney fixes the issue with the new GTK he just slipped in :p
[16:06] <desrt> sounds like we're gonna need a bigger beer fund...
[16:06] <willcooke> :)
[16:06] <larsu> * oh and looked into the volume slider event issue (thanks didrocks). Got a fix but don't know why it works
[16:06] <willcooke> I'll look down the back of the Canonical sofa
[16:06] <Laney> plenty of issues to go around guys
[16:06] <Laney> we can have a lucky dip
[16:06] <didrocks> larsu: that's the best fixes :)
[16:06] <willcooke> once Laney has his pay rise there should still be plenty to go around
[16:06] <seb128> haha
[16:07] <desrt> we're all going to need a pay raise to cover our keeping seb in a tranquil state
[16:07] <larsu> for some reason event coordinates don't need to be mapped to the slider's allocation anymore
[16:07] <Laney> he means because the numbers will start to overflow the bank's integers
[16:07] <seb128> didrocks, is the issue that the cursor is shifted from the actual position activated when you click?
[16:07] <larsu> I can't find a relevant commit in gtk
[16:07] <didrocks> seb128: right!
[16:07] <didrocks> when you drag as well…
[16:07] <seb128> didrocks, k, I noticed that as well
[16:07] <larsu> not sure if bisecting is needed or if we can just use the fix I have and dtop thinking about it
[16:08] <didrocks> which is even more puzzling to my brain ;
[16:08] <Laney> that's been on the pad for weeks already
[16:08] <didrocks> :)
[16:08] <Laney> why is random pinging necessary?
[16:08] <qengho> Laney: you hope they're unsigned types.
[16:08] <Laney> just as long as the cheques are signed
[16:09] <willcooke> larsu, ok to move on?
[16:09] <larsu> willcooke: yep, that's it
[16:09] <willcooke> thanks larsu
[16:09] <willcooke> #topic mlankhorst
[16:09] <mlankhorst> harassing people in #ubuntu-release without much success
[16:09] <mlankhorst> updating the vmware and intel packages in the x-staging ppa for 1.17 (waiting on fglrx)
[16:09] <mlankhorst> adding rotation and 2x option to xmir-standalone
[16:09] <mlankhorst> resend glamor patches to xorg-devel ml
[16:09] <mlankhorst> regression test and upload mesa 10.4.2 to vivid
[16:09] <mlankhorst> upload and verify xserver-xorg-video-intel sru's with rotation fixes
[16:09] <mlankhorst> upload new xserver-xorg-video-vmware to archive after testing
[16:10] <willcooke> great stuff, thanks mlankhorst.
[16:10] <willcooke> Any luck today with #ubuntu-release?
[16:10] <mlankhorst> nope :P
[16:10] <didrocks> mlankhorst: did you try direct ping as suggested?
[16:10] <mlankhorst> just a silent echo
[16:11] <mlankhorst> I 'll try that next, but usually that channel is more active
[16:11] <mlankhorst> raof accepted some packages, but I had some discussion about the ones not in yet though i havent had a reply rom him since
[16:12] <willcooke> he's on the other side of the world isn't he?
[16:14] <willcooke> mlankhorst, if you dont have any luck by EOD tomorrow, let's revisit
[16:14] <willcooke> #topic qengho
[16:16] <qengho> - In Cr, fixed bugs like search-suggestions and DRI3/sandbox backport.
[16:16] <qengho> - Worked on connecting Cr to mir. I may need help with today's problem. I'll ask here once I try some more.
[16:16] <qengho> And that's mostly it. Some debugging of a crash in unity8, but that got nowhere.
[16:16] <willcooke> thanks qengho
[16:17] <seb128> qengho, is chromium updated soon?
[16:17] <seb128> qengho, you said the next update would be around now and would adress that bug that tops e.u.c
[16:17] <qengho> seb128: I said in about two weeks, which is still a week away.
[16:18] <seb128> oh ok, I though it was 2 meetings ago
[16:18] <seb128> all good then ;-)
[16:19] <willcooke> #topic seb128
[16:19] <seb128> * had some vac days
[16:19] <seb128> * helped moving some SRUs forward (updated patches, triaged bugs, verified some fixes)
[16:19] <seb128> * a bit of sponsoring
[16:19] <seb128> * backported a fix to rtm to make the "reply" hint in indicator-message translated
[16:19] <seb128> * spent some time reading documentation and playing with unity8, current desktop-next session, systemd
[16:19] <seb128> * usual share of desktop related bugs triage and discussions

[16:20] <willcooke> thanks seb128
[16:20] <willcooke> #topic Sweet5hark
[16:20] <Sweet5hark> - checked prerequs. and submitted MIRs for libabw, libe-book, libeot, libetoneyek, libfreehand, libmwaw, libodfgen to ubuntu-mir team for approval -- bug 1410866 and bug 1410883
[16:20] <Sweet5hark> - blogged about the (small) writer performance improvements: https://skyfromme.wordpress.com/2015/01/15/swnodeindex-ludicious-speed/
[16:20] <Sweet5hark> - various trackers/issues grinding
[16:20] <Sweet5hark> - remerging from Debian (ongoing)
[16:20] <Sweet5hark> - new upstream LibreOffice 4.4.0~rc3 due this week (tag expected ~today)
[16:20] <Sweet5hark> - some upstream patch review
[16:20] <Sweet5hark> - upstream admistration tasks (meh)
[16:20] <Sweet5hark> EOF
[16:22] <willcooke> thx Sweet5hark
[16:22] <willcooke> #topic themuso
[16:22] <willcooke> * Exclusively been working on bug #1066157, and have determined that unity is using deprecated methods/signals in atk, so am now going through unity a11y code checking all methods/signals, and checking whether they are still valid. There may be more things to fix to resolve this bug, but I think this will go a long way to getting us there.
[16:22] <willcooke> #topic any other business
[16:22] <willcooke> Dont think there is much else
[16:23] <seb128> seems not
[16:23] <willcooke> #endmeeting
[16:23] <meetingology> Meeting ended Tue Jan 20 16:23:17 2015 UTC.
[16:23] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2015/ubuntu-desktop.2015-01-20-15.31.moin.txt
[16:23] <willcooke> thanks all
[16:23] <seb128> qengho, found back the IRC log btw, http://irclogs.ubuntu.com/2015/01/08/%23ubuntu-desktop.html#t16:37
[16:23] <seb128> qengho, that was not previous week but the week before ;-)
[16:24] <Sweet5hark> looking for forward to see you guys soon in cafe delirium ...
[16:25] <larsu> Sweet5hark: !
[16:25] <Laney> Was a bit busy for me last time ...
[16:25] <desrt> ya
[16:25] <desrt> i'm starting to get tired of going to this place :)
[16:25] <seb128> Sweet5hark, btw I lost track, but is there any libreoffice work I'm supposed to upload for you and that I didn't do?
[16:26] <didrocks> desrt: come on, it's your second venue to FOSDEM only IIRC :)
[16:26] <desrt> might be better to buy a case of beer from elsewhere and bring it to the alleyway :)
[16:26] <larsu> 3rd
[16:26] <larsu> desrt: wegbier!
[16:26] <desrt> 3rd?  seems more like 4th or 5th
[16:26] <larsu> desrt: at least 3rd (I was there the last two years and you were there)
[16:26] <Sweet5hark> seb128: rechecking ...
[16:26] <seb128> Sweet5hark, danke
[16:27] <desrt> codethink had some hackfests in brussels around fosdem time
[16:28] <qengho> seb128: I expect a upstream release in the next few days, but after patching/building/testing, it will be next week before it's ready to upload.
[16:28] <seb128> qengho, ok, fair enough, looking forward the update still ;-)
[16:28] <qengho> :)
[16:28] <qengho> Me too!
[16:29] <Sweet5hark> seb128: hmm, I dont see LibreOffice 4.2.8 in trusty-proposed nor in the trusty queue: http://people.canonical.com/~bjoern/trusty/4.2.8/
[16:30] <Sweet5hark> seb128: ... and I will throw some 4.4.0 rc at you in the next days, I guess.
[16:30] <seb128> Sweet5hark, ok, I think that's the one which was missing SRU info, you added those and I didn't have another look
[16:30] <seb128> k, sounds good
[16:31] <seb128> I'm going to have another look to the SRU one
[16:32] <Sweet5hark> seb128: great thanks so much! as for vivid -- no other upload. Precise: yeah, Id guess we need to do something there at some point -- lets talk in brussels on that if possible.
[16:32] <seb128> ok
[16:32] <Sweet5hark> seb128: yes, 4.2.8 now has a bug ID in the changes ...
[16:54] <didrocks> oh my! /me found a way easier way (and remove last hour of work :/)
[16:55] <desrt> didrocks: on the scale of replace-oneself-with-a-script experiences, an hour of wasted effort is actually pretty low :)
[16:57] <didrocks> desrt: indeed, especially counting that I remove many lines, a hashmap I was handling manually and so force in the process :)
[16:58] <didrocks> it's one of those things when you are writing code, thinking "it sucks", and suddenly, when you gave up on thinking on another solution, it just comes to your mind…
[17:34] <pitti> argh, Sweetshark is already gone ;/ wanted to say happy bday
[17:48]  * didrocks waves good evening
[18:56]  * willcooke EOD
[21:27] <tedg> robert_ancell, Am I correct to assume that you'll land the indicator-bluetooth bz5 MR when you've got the whole transition ready?
[21:28] <robert_ancell> tedg, yes
[21:29] <tedg> robert_ancell, Cool, any idea of time? Guessing it has to be relatively soon for FF coming up.
[21:30] <robert_ancell> tedg, I'm not sure what the plan is. didrocks was managing the transition. I'm just doing the grunt work for the indicator
[21:30] <tedg> Ah, okay.
[21:31] <tedg> Grunt away! ;-)
[23:18] <Sweet5hark> mterry: as a trusty main inclusion request man: do you see any obvious troubles with bug 1410883 or bug 1410966?
[23:19] <mterry> Sweet5hark, ah, I haven't looked at those yet.  It's near eod for me, mind if I look at them tomorrow?
[23:19] <Sweet5hark> mterry: no worries, not too urgent...