[13:46] <sofeafaef> Hi all
[13:46] <sofeafaef> Hi to all
[15:56] <ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYdwzZ1kXc6oi121rGs9L9ex5ZAZ7_MJRoCt3gGWBiIM--djug?authuser=0&hl=en
[15:56] <ogasawara> smagoun, jibel, xnox ^^
[15:56]  * ogasawara looks for others
[15:57] <mdeslaur> \o
[15:57] <ogasawara> mdeslaur: https://plus.google.com/hangouts/_/hoaevent/AP36tYdwzZ1kXc6oi121rGs9L9ex5ZAZ7_MJRoCt3gGWBiIM--djug?authuser=0&hl=en
[15:57] <ogasawara> mdeslaur: hiya
[16:00] <ara> hello!
[16:01] <xnox> o/
[16:01] <roadmr> hi
[16:04] <ara> shouldn't https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule be updated to show that date? Aug 7th 12.04.5?
[16:05] <smagoun> ara: yes
[16:05] <smagoun> :)
[16:08] <rbasak> What Adam says makes sense. But the flip side is that users would ideally always be able to install from the latest image, and never get a message immediately.
[16:09] <xnox> as long as precise+trusty-hwe upgrade to trusty
[16:17] <bdmurray> what about landscape?
[16:21] <jamespage-uds> rbasak: dhenrich on the landscape team
[16:21] <jamespage-uds> ogasawara: ^^
[16:21] <ogasawara> jamespage-uds: awesome, thanks
[16:24] <rbasak> apw: that one also needs to be able to answer people's question "will this be happening to me?" in advance of an actual notification.
[16:28] <smagoun> ogasawara: I need to drop for another commitment - thank you for facilitating this
[16:29] <ogasawara> smagoun: thanks
[17:50] <ogasawara> jodh: https://plus.google.com/hangouts/_/hoaevent/AP36tYeuCFlc0lIjfDjhzuNFhXzVCok55HB8kUFPhezu3jicPS7A4Q?authuser=0&hl=en
[17:50] <ogasawara> jodh: no hurry, you've got 10min
[17:51] <ogasawara> jodh: let me know if you need help pinging participants
[17:54] <jodh> ogasawara: thanks
[17:58]  * pitti waves hello
[17:59]  * slangasek waves
[17:59] <slangasek> pitti: https://plus.google.com/hangouts/_/hoaevent/AP36tYeuCFlc0lIjfDjhzuNFhXzVCok55HB8kUFPhezu3jicPS7A4Q?authuser=0&hl=en
[18:05] <ogra_> what about services that systemd needs, how do we transition things like rsyslog ?
[18:08] <cjwatson> $ dpkg -L rsyslog | grep 'systemd.*service'
[18:08] <cjwatson> /lib/systemd/system/rsyslog.service
[18:08] <cjwatson> ogra_: ^-
[18:08] <ogra_> oh ?
[18:09] <ogra_> i thought that wasnt possible anymore
[18:09] <ogra_> cool then
[18:09] <cjwatson> yep, you can absolutely have both upstart and systemd configs in the same package
[18:09] <gQuigs> anyone played with this?  https://launchpad.net/~ondrej/+archive/systemd
[18:09]  * gQuigs couldn't get it to work
[18:09] <ogra_> cjwatson, no, i mean using rsyslog on systemd ...
[18:10] <ogra_> i thought systemd needs journald
[18:10] <ogra_> as an essential bit
[18:10] <cjwatson> the systemd journal writes through to rsyslog
[18:10] <tedg> It seems like using Upstart/Systemd together means that we have more flexibility on the session side.
[18:10] <cjwatson> that's the default config in Debian already
[18:10] <tedg> If the session systemd can't run without a system systemd
[18:10] <ogra_> sweet
[18:10] <sergiusens> property watcher for android is system
[18:10] <cjwatson> you get both information in the journal, and traditional logs
[18:11] <cjwatson> the journal isn't nearly so evil a thing with that as it's been painted
[18:11] <ogra_> well, i cant use less on the logs :)
[18:11] <ogra_> reluctancy to change and all :)
[18:12] <cjwatson> you can absolutely use less on the rsyslog-generated logs bridged through from the systemd journal
[18:12] <ogra_> right, but i cant use it with plain journald logs
[18:12] <cjwatson> I would encourage setting up a quick Debian VM, configure it to boot with systemd, and play with that
[18:12] <ogra_> i'll surely do that (not right now indeed)
[18:13] <cjwatson> ogra_: you can use journalctl/systemctl or whatever, or you can use less on the trad logs; while I can see that you want to look at the raw journal files if you're debugging systemd, I don't understand why that would be justified by a reluctance to change
[18:13] <ogra_> sergiusens, well, before we even think about how to make the upstart bridges work with systemd we need to see if the android kernels can even run with systemd without to much patchwork :)
[18:13] <cjwatson> if you're reluctant to change, you read the traditional logs and you ignore the journal
[18:14] <ogra_> cjwatson, i know many people that run silly screen scraping shellscripts on logfiles etc
[18:14] <sergiusens> ogra_, true
[18:14] <ogra_> cjwatson, such setups kind of assume you have plain text logs
[18:14] <cjwatson> ogra_: those will still work
[18:15] <cjwatson> /var/log/syslog is *still there* and *still contains useful content*
[18:15] <ogra_> right, in our setup
[18:15] <ogra_> (or debians)
[18:15] <sergiusens> ogra_, we will need to rewrite our overrides ourselves as well
[18:15] <ogra_> "raw" systemd wouldnt though
[18:15] <ogra_> sergiusens, yeah :(
[18:15] <cjwatson> ogra_: why would I care about something that isn't our setup? :)
[18:15] <cjwatson> or why should we care
[18:15] <ogra_> heh
[18:15] <ogra_> well, i dont know the debian setup yet ...
[18:16]  * sergiusens stops commenting for ogra to single thread :-)
[18:16] <cjwatson> anyway, my point is that the logs thing is a non-issue
[18:16]  * ogra_ was always very happy with upstart ... i never felt the need to try other inits
[18:16] <ogra_> right, i didnt know that debian had a solution already
[18:18] <gQuigs> that seems painful to debug ....
[18:20] <gQuigs> ... https://bugs.launchpad.net/upstart/+bug/160150  is this relevant?  nit: cannot be run as a PID other than 1
[18:20] <udsbotu> Launchpad bug 160150 in upstart "init: cannot be run as a PID other than 1" [Wishlist,Triaged]
[18:21] <ogra_> hmm, that used to work
[18:21] <ogra_> (you were able to boot with init=/bin/sh and run /sbin/init manually for debugging)
[18:23] <ogra_> sergiusens, the android property watcher just writes to a socket, isnt it ?
[18:24] <ogra_> i think systemd should be capable to read from that
[18:33] <rsalveti> probably
[18:37] <apw> slangasek, can we not just move the system jobs to like /etc/init/system/* and only run those if pid==1 and not pid==2
[18:38] <slangasek> apw: could be done, but that's a lot of glue code to add to upstart that doesn't currently exist
[18:38] <apw> slangasek, by which i mean when we add a new systemd unit to the job move the upstart job to the systemd directory, so we know it is only needed when not using systemd
[18:38] <apw> "a lot" is it really
[18:42] <slangasek> ah, you mean moving them out of the standard upstart path so that they're not seen when booted as a helper, ok - seems the discussion on the hangout has caught up a bit :)
[18:43] <gQuigs> which version of systemd are we aiming for?
[18:43] <apw> slangasek, right if when you convert a job to system as well, you move those into a second place, upstart uses both dirs, upstart helper does not use the "converted" directory on its path
[18:50] <xnox> apw: don't use subdirectory in /etc/init as upstart reads all subdirectories and it's all valid jobs.
[18:50] <slangasek> right
[18:51] <xnox> gQuigs: that bug is not relevant, upstart can run as both session or system init as not pid1. Most of our unit test rely on that. We have some safety checks in place, which will need to be tweaked, but nothing major.
[18:54] <xnox> slangasek: apw: at the moment, we disable running system upstart with multiple config dirs, but that can be updated/re-enabled.
[18:56] <ogra_> do you guys plan to cover the android related bits too ?
[18:56]  * ogra_ doesnt see any recent notes about it, we need to make sure the helpers we use inside the android container still work or are portable ... and indeed there is that android kernel question ... can systemd work on 3.0 kernels etc 
[18:57] <rsalveti> at least on >= 3.4
[18:58] <sergiusens> rsalveti, that's min req I guess, but will it work?
[18:58] <rsalveti> not without patching the kernel I believe
[18:58] <xnox> pitti: but our 204 is with or without stable-branch patches?
[18:58] <rsalveti> someone needs to get an action to check that for the next cycle
[18:59] <pitti> xnox: not a lot of backported patches, mostly just for hwdb
[18:59] <pitti> xnox: nothing stops us from pulling some in, of course
[18:59] <xnox> pitti: ok.
[18:59]  * ogra_ guesses the guys in the session dont read IRC 
[18:59] <ogra_> :P
[19:00] <xnox> cjwatson: but touch is next session =)
[19:00] <ogra_> xnox, well, touch has also system jobs :P
[19:00]  * tedg has jobs that use the apparmor stanza :-)
[19:00] <ogra_> next session is about session
[19:00] <pitti> heh
[19:01] <tedg> the session session
[19:01] <xnox> pitti: slangasek: yeah, how are we going to support android-bridge on systemd?
[19:01] <slangasek> xnox: in the first iteration, is there any reason not to run that under upstart compatibility?
[19:01] <ogra_> xnox, ++
[19:01] <ogasawara> https://plus.google.com/hangouts/_/hoaevent/AP36tYda5hjUl0qHK6-TMT6DkfUsU8iSeC_i8DATvp-9NyIO21R-WQ?authuser=0&hl=en
[19:01] <ogra_> slangasek, well, long term we need to switch
[19:02] <xnox> slangasek: sounds good to me. I just thought phone could switch to systemd without any compatibility layer, as it doesn't need one at all.
[19:02] <ogra_> and we start to rely more and more on system properties from android
[19:02] <cjwatson> xnox: good to be accurate anyway :)
[19:02] <ogra_> xnox, well, only if the bridge helpers work on systemd
[19:02] <slangasek> xnox: well, it needs one for the android bridge, initially :)
[19:02] <ogra_> and for session stuff we rely 100% on upstart today
[19:02] <xnox> slangasek: cjwatson: e.g. do systemd unit files support arbitrary new stanzas and/or generic events thingies?
[19:03] <ogra_> (way more than desktop for example)
[19:03] <cjwatson> apw: I think we should avoid doing this in a way that requires us to do extra per-job work just to make upstart jobs work when they haven't been converted to systemd yet
[19:03] <cjwatson> that way round means that we probably won't meet any sensible compatibility goals
[19:04] <cjwatson> and in many cases if we're going to touch a package anyway it's just as easy to write a systemd unit for it
[19:04] <cjwatson> e.g. I wrote systemd units for click which I'm pretty sure will work even though I've never run them
[19:04] <slangasek> ogra_: do you want to join the hangout?
[19:05] <ogra_> slangasek, i'm fine with IRC if someone pays attention to it :)
[19:05]  * ogra_ would need to find a place where he can speak 
[19:05] <ogra_> (not easy atm)
[19:05] <slangasek> ogra_: well, /I'm/ not fine with IRC, the hangouts are used for a reason :)
[19:05]  * tedg likes a silent ogra_ ;-)
[19:05] <ogra_> :P
[19:06]  * ogra_ reloactes
[19:06] <slangasek> ogra_: (best case, there's significant lag between us talking and you seeing it on the feed)
[19:06] <tedg> So an initial topic, it seems like we can't do any session migration until systemd is PID 1, right?
[19:06] <xnox> tedg: correct, but once it is, we need a plan for conversion.
[19:07] <tedg> But that's for trust + 1, right?
[19:07] <tedg> We can't even think about it until then.
[19:07] <ogra_> slangasek, gimme the HO url
[19:07] <cjwatson> Some time between trusty+1 and trusty+4
[19:07] <cjwatson> We can absolutely think about it
[19:07] <cjwatson> And should
[19:07] <slangasek> ogra_: https://plus.google.com/hangouts/_/hoaevent/AP36tYda5hjUl0qHK6-TMT6DkfUsU8iSeC_i8DATvp-9NyIO21R-WQ?authuser=0&hl=en
[19:08] <tedg> I guess I think the session is going to be much easier to migrate than the system.
[19:08] <tedg> We're not as complexly invested there, we simply haven't used it as long.
[19:08] <slangasek> tedg: I don't agree that it's going to be *much* easier
[19:08] <tedg> I'd love to avoid getting to tied into Upstart, but I do want to use "modern init features" more and more.
[19:09] <cjwatson> There are things like associations with :sys: events
[19:09] <tedg> slangasek, Well, I'm scared of servers, so it might be a perspective thing :-)
[19:09] <slangasek> the uses of upstart in the session are largely orthogonal to how we're using it in the system init
[19:09] <xnox> tedg: modern features would be using dbus-activation =)
[19:09] <xnox> tedg: as that's managed under systemd ;-)
[19:11] <tedg> That makes dbus-activation not suck. But it still doesn't align with purpose of session length jobs :-)
[19:13] <tedg> +1, I think flag day.
[19:14] <xnox> jdstrand: are you about?
[19:14] <jdstrand> I am here
[19:14] <xnox> jdstrand: join the hangout.
[19:14] <xnox> jdstrand: https://plus.google.com/hangouts/_/hoaevent/AP36tYda5hjUl0qHK6-TMT6DkfUsU8iSeC_i8DATvp-9NyIO21R-WQ?authuser=0&hl=en
[19:15] <tedg> ogra_, Unity shouldn't see much change, we've already abstracted it with libupstart-app-launch
[19:15] <tedg> We just need to port UAL.
[19:15] <xnox> tedg: and what would that involve?
[19:15] <tedg> xnox, I mean I think it's more just "doing it" I'm guessing it's a week or two of work. Just need to schedule it.
[19:15] <ogra_> tedg, well, doesnt ubity-mir do some lifecycle stuff that also might want to talk to upstart ?
[19:16] <tedg> xnox, I don't think it's worth doing until we think we can have a systemd as PID 1 though.
[19:16] <tedg> ogra_, AFAIK it does all of that through libual.
[19:16] <xnox> tedg: well, we'll be able to start testing it as soon as we have ppa up with systemd as pid1
[19:16] <ogra_> tedg, ok, so if you think we can easily transition that one to systemd we should be good
[19:16] <tedg> xnox, Sure, but my manager doesn't take "I want to play with a PPA" as a good reason to schedule my time :-)
[19:16] <xnox> tedg: which is in a matter of weeks, early 14.10. not something "in the very long future"
[19:17] <xnox> tedg: ask slangasek to convince your manager ;-)
[19:17]  * ogra_ would really prefer if we could stay on upstart with the phone until at least 15.04
[19:17] <ogra_> (for sessions)
[19:17] <cjwatson> Could you elaborate on reasons?  Is this just risk-aversion?
[19:17] <ogra_> the system is far from being readily designed
[19:18] <tedg> I'd rather design it more on systemd. Get it early, get it right.
[19:21] <jodh> ogra_: FYI, I've started on a wiki page (it covers overrides btw): https://wiki.ubuntu.com/SystemdForUpstartUsers. More input welcome! :)
[19:22] <serue> jodh: oh, nice, thanks for that
[19:22] <slangasek> separately, the extensive use of overrides on the phone is really rather problematic
[19:22] <pitti> jodh: hah, nice cheat sheet!
[19:22] <sergiusens> tedg, so the u in libual will s/upstart/ubuntu/?
[19:23] <tedg> sergiusens, Heh, that'd be a great idea!
[19:23] <jodh> pitti, serue: :) I was hoping that that page would form part of the release notes once we've switched (or made that an option atleast)
[19:23]  * tedg wants to name it bob
[19:25] <sergiusens> ogra_, that's a problem from the prior session ;-)
[19:26] <pitti> stgraber, ogra_: child reaper support is linux >= 3.4
[19:26] <ogra_> sergiusens, yeah it was not dealt with in the former session, so i thought i should bring it up
[19:27] <tedg> I don't think UAL is a "pain point," but it's a work item that we need to schedule.
[19:27] <tedg> It's a significant thing that needs to be ported.
[19:28] <tedg> I'd like to avoid supporting both at the same time, but if we have to, that's probably possible.
[19:28] <cjwatson> I think we have to have some degree of dual running, both at the system and session levels
[19:29] <cjwatson> I suppose worst case we could fork a systemd-app-launch if you really don't want both in UAL ...
[19:29] <ogra_> hopoefully only during development
[19:29] <cjwatson> (it'd want to be renamed anyway, right?)
[19:29] <tedg> Eventually I think it should be.
[19:29] <tedg> I like sergiusens' idea of "Ubuntu App Launch" though :-)
[19:29] <ogra_> why does it have the session manager in its name ?
[19:29] <tedg> We wouldn't have to support two APIs in Unity for sure.
[19:30] <ogra_> it is used for launching click apps ...
[19:30]  * ogra_ would call it click-app-launch :)
[19:30] <tedg> Eh, I don't know. It was originally supposed to be a couple of Upstart jobs. It got feature creep :-)
[19:30] <sergiusens> tedg, you forget the surfaceflinger/mir transition (still on going)
[19:30] <sergiusens> :-)
[19:30] <xnox> tedg: right it would be one or the other. you will not need to launch one app with systemd and another with upstart within the same session.
[19:30] <tedg> sergiusens, I'm trying to forget ;-)
[19:31] <cjwatson> ogra_: it's used for launching apps, not exclusively click apps
[19:32] <tedg> It's also used for managing them. Finding PIDs, etc.
[19:32] <ogra_> well, currently it only launches click apps ... due to circumstance :)
[19:32] <xnox> ogra_: it launches click and legacy.
[19:32] <sergiusens> ogra_, no, it launches legacy apps too
[19:32] <tedg> Webbrowser isn't a click app :-)
[19:32] <cjwatson> ogra_: perhaps, but consider the long tail of apps with unity8 on the desktop
[19:32] <ogra_> oh
[19:32] <ogra_> i stand corrected :)
[19:33] <ogra_> cjwatson, well, they will hopefully all become click too ;)
[19:33] <cjwatson> "long tail"
[19:33] <ogra_> :)
[19:33]  * sergiusens doesn't wnt to convert any more apps; too hard with the tight train schedule
[19:33] <cjwatson> as the click author it is not my goal to stop people launching apps when they aren't in click format
[19:34] <ogra_> sergiusens, just wait for libreoffice ;)
[19:35] <cjwatson> I do not expect many apps to *ever* be converted, particularly people's local apps that they haven't rebuilt since 1995
[19:35] <cjwatson> but this is for another session I suppose :)
[19:35]  * ogra_ does ... but thats because i can read asacs mind :)
[19:36] <cjwatson> asac is wrong :P
[19:36] <ogra_> heh
[19:36] <xnox> ogra_: one _never_ recompiles go-apps!
[19:37] <xnox> =))))
[19:37] <ogra_> xnox, who cares about go :) i want firefox and libreoffice click packages :)
[19:37] <xnox> ogra_: nobody else wants those at all =)
[19:38] <ogra_> convergence !
[19:38] <xnox> ogra_: webbrowser-app https://drive.google.com
[19:38] <ogra_> pfft
[19:38] <ogra_> :)
[19:43] <gQuigs> how can community contributers best help?
[19:43] <slangasek> gQuigs: by taking workitems from the blueprint? :)
[19:44] <gQuigs> err.. I mean from the perspective of changing jobs over.. when it's time to start, etc
[19:44] <ogra_> gQuigs, and if you dont want to do that, we should have something to test at some point and someone will blog about how to use it and we'll need people to test the hell out of it
[19:44] <gQuigs> ogra_: right
[19:45] <ogra_> for changing jobs over we will first need the basics in place ...
[19:45] <ogra_> once thats there you should be able to go wild on it :)
[19:45] <gQuigs> ogra_: cool
[19:45] <cjwatson> right, probably simplest to wait until we have a PPA you can work with and then start converting jobs where dependencies allow
[19:46] <rsalveti> the android one is also system level
[19:47] <ogra_> does it pick up anything there yet ?
[19:48] <rsalveti> no, not picking at system level, I mean, it's part of system, not session
[19:48] <ogra_> right
[19:48] <ogra_> stgraber just translated your brazilian for me :P
[19:49] <sergiusens> ogra_, that last comment came from the future
[19:49] <sergiusens> :-)
[19:49] <rsalveti> yeah, this delay is quite interesting
[19:49] <ogra_> heh
[19:52] <tedg> Thanks!