[00:00] cjwatson: mitya57: we don't even use debconf's perlqt frontend in kubuntu, we use debconf-kde which is a c++ library so I expect it can be dropped === _salem is now known as salem_ === salem_ is now known as _salem [00:22] Hm. Who's familiar with the seeds/germinate process? I need to know why mir-client-platform-mesa is being pulled in to the vivid touch image, and how to stop it. [00:39] ROAF: because it's a reverse-depends of libmirclient8 perhaps? [00:44] mdeslaur: It's an alternative rdepends of libmirclient8, yes. [00:45] But mir-client-platform-android is explicitly seeded, and satisfies that alternative. [01:05] RAOF: hrm, not sure then. perhaps infinity would know [01:26] RAOF: It's almost certainly because of the alternate dep, and could just need a blacklist. [01:27] RAOF: Germinate's not always bright in the face of alternate deps. [01:27] Ah. [01:28] Let me see if I can work out how to do that... [01:28] RAOF: To be fair, situations that call for blacklists usually mean your deps are wrong, but I can see how this is a curious special case, since you want two different defaults. [01:28] An alternative would be to *not* depend on a driver module at all for libmirclient8. [01:29] Which is possibly also correct. [01:29] That would probably be reasonable. [01:29] Unless it needs it to load. [01:29] Well... it's not *linked* to the driver module, but it'll fail as soon as you try to do anything with it. [01:30] But that's a solution that doesn't require me to try and work out how germinate works again, so... :) [01:30] RAOF: Decoupling it is probably the right thing anyway. [01:31] RAOF: Since the android/gnu thing really needs to *stop* being how we define "touch" and "not". [01:31] Heh, yes. [01:32] RAOF: That all needs to be defined in hardware support packs that just drop the right bits in place, and userspace should opprtunistically use the right bits as it discovers them. [01:32] RAOF: Otherwise, any hope for convergence is a bit of a joke, IMO. [01:32] RAOF: Or any hope for touch devices with free driver stacks. :P [01:37] We've *very nearly* landed the necessary bits in Mir to do that, yes. [01:37] (This has been apparent for a while ☺) [03:00] Unpacking python-oslo-config (1:1.6.0-0ubuntu1) ... [03:00] dpkg: error processing archive /var/cache/apt/archives/python-oslo-config_1%3a1.6.0-0ubuntu1_all.deb (--unpack): [03:01] trying to overwrite '/usr/lib/python2.7/dist-packages/oslo/config/cfg.py', which is also in package python-oslo.config 1:1.5.0-0ubuntu1 [03:01] I wonder if that is already known [03:26] lamont: Sounds like some missing Breaks/Replaces. Report and/or pester jamespage and/or fix it yourself cause you're still a core-dev? :) [03:27] lamont: Oh, already reported as LP: #1410727 [03:27] Launchpad bug 1410727 in oslo-config (Ubuntu) "package python-oslo-config (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/python2.7/dist-packages/oslo/config/cfg.py', which is also in package python-oslo.config 1:1.5.0-0ubuntu1" [High,Confirmed] https://launchpad.net/bugs/1410727 [03:29] jamespage: ^ [04:54] Good morning [05:48] mitya57: I don't know. [06:35] slangasek: any preference for today's EU/US sprint handover hangout? [06:36] pitti: preference - do you mean for time? [06:36] slangasek: oh, nevermind, I just saw the cal entry [06:36] my /preference/ is to have it quite a bit later than I actually scheduled it ;) [06:36] (I didn't get a mail notification for it, weird) [06:37] slangasek: I have a meeting 17:00 to 18:00 UTC, anything before and the hour after would WFM [06:40] pitti: would an hour later work, maybe? [06:40] that's more realistic considering I'm still awake [06:40] slangasek: yes, even two hours [06:41] pitti: two hours later runs into other conflicts [06:41] slangasek: not three hours (as that overlaps with my other meeting), but four works again [06:43] hangover hangout? === doko_ is now known as doko [06:43] did I actually write.. [06:43] no :) [06:44] doko: today is the handover; tomorrow (at Friday evening) is the hangover :) [06:45] slangasek: time added to the pad [06:46] * pitti invites jamespage [07:11] cjwatson, slangasek, xnox: who maintains ubiquity these days? If we work review based, I'd appreciate a look at https://code.launchpad.net/~pitti/ubiquity/systemd/+merge/246535 [07:11] I believe I tested it sufficiently, but more eyes can't hurt [07:16] slangasek: do you want to tackle bug 1312976 for the sprint? you said you wanted to rearrange the init.d scripts as well, do that in Debian, etc. [07:16] bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312976 [07:49] slangasek: apparently upstream also has native systemd jobs (I've seen some patches fly by via CC: systemd-devel@), so maybe we can just use those [08:05] didrocks: ah, having a look at some touch ones? [08:05] I got some easy ones without android deps this week; for the others we should probably wait for xnox to wake up? [08:06] well, some of those might still be simple [08:06] pitti: I'm currently on the edubuntu one, but I think we should start with the android config one first and try to understand how that exactly works [08:07] pitti: it contains a lot of upstart jobs, maybe we should do Touch once all the others are done? [08:07] and do a real iterative work on it [08:07] didrocks: I don't have a good feeling about how much work it is TBH [08:08] I'm not very familiar with the phone booting [08:08] pitti: I think it would be better to directly Do The Right Thing and revisit(Tm) [08:08] pitti: but TBH, seeing how close rtm is on rebasing on vivid from what I heard, I doubt they will move to systemd this cycle, still doesn't stop us of doing the work [08:09] but my gut feeling is it would be less work to really understand the dependencies and directly optimize it [08:09] wdyt? [08:09] not sure what you mean with DTRT? you mean stop listening to android events? [08:09] I don't think we can do that anytime soon [08:10] maybe for special cases like MTP (as I hinted in my reply to xnox), but I haven't investigated that really [08:10] pitti: it seems to me that there are a lot of jobs that are just events in the middle or specific for one device [08:10] pitti: I'm pretty sure some cruft piled up over time [08:12] oh, for sure [08:22] good morning [08:31] seb128: hi! Does the session-migration stuff work on Ubuntu touch? [08:33] doko: hi, are we going to switch to gcc 5.0 in 15.04? [08:33] mardy: it does run, yeah [08:33] didrocks: please remove from the pad when the package moves to vivid; please keep it as long as it's in -proposed still [08:33] didrocks: we've had several packages getting stuck [08:33] didrocks: cool, thanks! [08:33] pitti: ok, got it [08:33] mardy: yw ;) [08:34] mardy: if you have never used it, some hints: http://blog.didrocks.fr/post/Announcing-session-migration-now-in-ubuntu [08:35] mardy: or ask me for the dh_migration usage if needed [08:35] didrocks: IIRC I've used it once, long time ago; but I'll certainly ask, if in doubt :-) thanks :-) [08:35] no worry ;) [08:38] mardy, hey, what didrocks said [08:38] o/ [08:38] seb128, didrocks: LOL, sorry, I just realized that I mixed you guys up -- must be because of your Frenchness ;-) [08:40] mardy: sure sure, "all the same" :p [08:40] ;-) [08:56] hi developerz! [09:34] pitti, what locale gets used during package build tests? and is it the same on debian? [09:34] darkxst: C.UTF-8 usually [09:35] darkxst: and yes, it should be the same everywhere [09:35] pitti, tracker tests fail on debian, but not ubuntu [09:36] martyn thinks its sorting issue due to locale's [09:36] darkxst: oh, wait, during *package build* [09:36] darkxst: I thought autopkgtest, sorry [09:36] darkxst: so, should be C for both D and U [09:36] pitti, actually I meant autopkgtest [09:36] darkxst: ah; Debian runs in a simple schroot, Ubuntu in qemu; that might explain it [09:38] pitti, I can reproduce the debian failures just running adt tests locally in a debian vm === greyback__ is now known as greyback [09:51] Riddell, I think I will keep it as it will be less delta than dropping it :) [09:57] Oooh, I just realized that libqtgui4-perl is used not only when generating .pm file, but when actually drawing the interface, too. [09:59] infinity: blacklists are not only normally a sign of wrong dependencies, but normally flat-out don't work for what people try to use them for :-) [10:02] pitti: I see xnox is reviewing, so I'll leave it to him. I don't immediately see anything wrong ... [10:03] cjwatson: thanks [10:05] morning =) [10:08] hey xnox, wie gehts? [10:10] pitti: sehr gut, danke schon ;-) [10:21] xnox: ah, while I do see the oem-config debconf page, I can't actually do anything there [10:21] doesn't react to any keypresses [10:21] xnox: that might be because its running in an upstart job which get their own PTY as stdin/out/err? [10:26] pitti: yes. [10:27] "console output" in upstart speak, in systemd there are Stdin= Stdout= stanzas or some such, no? [10:28] xnox: there are TTY* options; usually units don't have any tty/pty at all, their stdout/err goes to the journal [10:28] xnox: I updated the MP [10:28] (comments, not code yet) [10:29] xnox: or perhaps under upstart it collides with getty1 somehow? [10:29] xnox: anyway, I won't put a lot of effort into debugging this under upstart now :) [10:31] pitti: well, console output means that "/dev/console" is being opened with O_RDWR | O_NOCTTY [10:31] in upstart. [10:34] pitti: StandardIntput=tty, StandardOutput=tty for oem-config job? for both oem-config & oem-config-debconf jobs. [10:34] .... sorry "units". jobs in systemd are state transitions [10:38] xnox: yep, I'm testing that ATM [10:39] xnox: sorry, doing three things at once [10:39] TTYVHangup=yes too, I think [10:39] and TTYReset=yes also couldn't hurt [10:40] OK, I have a clean test VM again; my previous try purged oem-config, so using -snapshot now :) [10:40] pitti: yes, it likes to purge itself. [10:42] jamespage: do you know if someone is looking at manila? [10:42] pitti, noone yet === _salem is now known as salem_ [10:42] pitti, I was going to take a look after my meeting finishes [10:42] pitti, kickinz1 is looking at maas [10:49] xnox: hah, now I have a systemd unit which behaves in the exact same way -- I see debconf, but dead keyboard :) [10:50] pitti: ship it, it's no regression parity =) [10:50] xnox: I wonder if that's a qemu quirk or so [10:52] xnox: Bazinga! [11:02] xnox: ok, all hunky-dory now; I updated the MP [11:05] * pitti goes back to isc-dhcp and its umpteen jobs [11:05] tseliot, no === kickinz1 is now known as kickinz1|afk [11:41] hi, are there any plans for updating boost in the v cycle? currently in archive are 1.54 and 1.55, but upstream released 1.57 in november 2014 [11:42] doko: ok, thanks [12:03] xnox: do you want to re-review the ubiquity MP, or are you happy with it? [12:04] pitti: i have not looked at your recent commits. [12:04] pitti: in general i'm happy with it. [12:04] * pitti is very sure to not have broken upstart mode, so we might just upload it now to ease testing tremendously [12:04] pitti: do you know how to merge & release ubiquity the right way, or shall I do it? [12:05] jamespage: yay you [12:05] pitti, that was a package in need of some love [12:05] xnox: well, for merging I'd just push my commits to trunk (looks cleaner than merge IMHO) [12:06] xnox: as for releasing, is it more than just bzr bd -S? that already does a lot of magic like downloading packages etc. [12:06] pitti: yes, bzr bd -S should do the right thing. [12:06] xnox: at least it's now I built my local test debs [12:06] xnox: that doesn't do the "Automatic update of source packages..." thing, though [12:06] I suppose there's a script for that? [12:06] pitti: ./debian/rules update; debcommit; bzr bd -S [12:07] pitti: bzr bd -S -> does update-local which will bail the build if out of date. [12:07] xnox: ok, I'll do that [12:08] xnox: ah, nothing new apparently; well, last update was just a week ago [12:08] cool. [12:08] xnox: ack, then I'll upload, and ask some cdimage folks in the afternoon to get us a new live image [12:08] xnox: thanks [12:09] xnox: argh, can't push, EPERM -- can you pull from my branch and push, please? [12:09] (or merge if you prefer) [12:09] I generally use debuild -S rather than bzr bd -S [12:09] which is not to say the latter won't work === MacSlow is now known as MacSlow|lunch [12:09] it's become a habit of mine [12:09] pitti: i think i can grant you permissions. [12:09] but it saves effectively re-running the d-i update bits [12:10] cjwatson: i added bzr bd -S magic, because you called me out on having unclean stuff in the ubiquity upload debdiffs =)))))) [12:10] pitti: you have permisssions now. [12:11] pitti: also spam =) [12:11] I was afraid of that :) [12:13] ev: i have successfully passed the batton to pitti. [12:13] \o/ [12:13] pitti: congrats on being the new maintainer of ubiquity =) [12:13] * pitti runs away screaming -- err, to have some lunch [12:14] xnox: well. mostly I called you out for not reading the debdiffs before upload :) [12:15] but ok [12:16] pitti, re the zentyal packages; i've pinged the upstream developers who are mean't to maintain those packages; basically if they don't want to update, I suggest we remove zentyal from the archive [12:17] its not been touched for over two years now so is vastly out-of-date [12:17] jamespage: ah right, and not in Debian either; no objection to cleaning them up if they don't reply or don't want to indeed [12:19] jamespage: pitti: zentyal would be broken / dangerous if we switch to systemd by default. [12:19] for pid 1. [12:19] xnox, indeed [12:20] also would be nice to remove system-config-* bits. [12:21] oh, that's the "new" name for ebox [12:21] xnox: dangerous because they are very upstart specific and the web frontend etc. only configures that? [12:22] pitti: yes. [12:22] pitti: not sure where the upstream stand at, but they did claim way back when that they will maintain it in ubuntu. [12:28] xnox, that's not happened so much [12:28] xnox, they have ppu rights for zentyal === kickinz1|afk is now known as kickinz1 === MacSlow|lunch is now known as MacSlow [13:25] tseliot: do you have some minutes to help me understand the nvidia-prime upstart job? for bug 1312255 [13:25] bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312255 [13:25] tseliot: I'm fine with porting it if you don't have time, but the upstart job looks a bit weird [13:40] is anyone looking for a really easy upstart → systemd porting to learn about it? ltsp-cluster-{accountmanager,lbagent} are simple [13:41] apw: hey, I see you are conmux's upstream, does this package makes sense under systemd or should it be replaced with manually instanced serial-getty? [13:42] didrocks, it does something other that that which getty does, i can add system startups if that is needed [13:43] systemd [13:43] apw: I have some spare cycles to do it now, seems quite a nice one with instantiated services. Just wanted to know if you feel it worthed it [13:43] jamespage, xnox: https://github.com/Zentyal/zentyal seems to be quite active though; it just seems they stopped uploading to Ubuntu; maybe people are supposed to use their own archive now [13:43] apw: so, it seems that indeed, it does make sense, so doing it [13:43] pitti: FYI ^ [13:44] didrocks, ahh, do indeed, but who knows how much use it gets these days [13:44] apw, didrocks: also see Debian bug 775185 [13:44] Debian bug 775185 in conmux "conmux: has only upstart job, no upstart dependency" [Normal,Open] http://bugs.debian.org/775185 [13:44] apw: mind answering on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775185? [13:44] would make sense to upload it there too [13:44] pitti: I'll attach a debdiff to it [13:44] apw: including a systemd unit upstream would be nice indeed [13:44] pitti: we just had a conversation in #ubuntu-server about Zentyal. Conclusion is to remove it from Vivid. [13:45] hey rbasak [13:45] pitti: in favour of their own repository, yes. [13:45] pitti: o/ [13:45] rbasak: ack, sounds good; I'll clean them up then [13:45] Thanks! [13:46] pitti: ah, you referenced the bug in the pad, funny, I was looking at conmux's bug to see if a patch was already attached were I saw we were in sync :) [13:46] didrocks: yeah, that's a curious case -- must be the only upstart-only package in Debian :) [13:46] (and undeclared on top of that) [13:47] pitti: yeah, we found it! :) the package was in ubuntu first and just uploaded in debian as-is [13:48] pitti: that means though, they will have the same postrm and so on issue once switch to systemd on that package as they don't have our patch [13:48] (in invoke-rc.d) [13:50] jamespage, rbasak: zentyal> *flush* [13:53] ok, I'll grab the ltsp-cluster-* ones now; might just as well get it over with [13:55] pitti, rbasak: yes indeed [13:55] pitti, I'd flush all of them [13:55] jamespage: yes, that's what I did (not just those on the pad) [13:55] $ remove-package -m 'unmaintained in Ubuntu for 2 years, upstream has their own repository' zentyal-ca zentyal-dhcp zentyal-dns zentyal-firewall zentyal-network zentyal-ntp zentyal-objects zentyal-openvpn zentyal-printers zentyal-services zentyal-users zbuildtools zentyal-common zentyal-samba zentyal-squid [13:55] pitti, thanks [13:55] I checked reverse-depends [14:00] pitti: do you know if it's possible to start some instances of a template service from another one (rather than running systemctl start fooservice@barinstance)? [14:03] didrocks: Requires=otherinstance@%I.service ? [14:04] pitti: well, the instance name is dynamically generate, though more from a script [14:05] pitti: maybe a generator would be the best solution, but I feel that being a little bit overkill for conmux [14:05] didrocks: uh, a template template? [14:06] didrocks: how dynamic? you can also create .d dirs in /run/systemd/system/ with the extra Requires, but I suppose that needs some daemon-reload === seb128_ is now known as seb128 [14:07] pitti: basically, there is 'for filename in dir -> start conmux-daemon@filename' [14:07] didrocks: ah -- well, that does sound like a generator [14:07] until now, it was conmux.upstart doing that (after starting the main server) [14:07] yeah, ok, let's go for a simple generator then [14:07] pitti: what is it that's not clear about nvidia-prime.upstart? [14:08] didrocks: /bin/dash FTW :) [14:08] pitti: not a bin fan in term of perf as it impacts boot time, but well :) [14:08] didrocks: well, *shrug*, the upstart job was also a script, so not really a regression? [14:09] pitti: true :) and so, creating some conmux.d/ -> Requires [14:09] on all those instance [14:09] sounds sane? [14:09] tseliot: it seems it only starts start-nvidia-persistenced if prime is *not* supported [14:09] didrocks: yes [14:10] didrocks: and TBH, as long as a script uses only builtins and doesn't call grep and other external programs a lot, it should be fine [14:10] pitti: yeah, it's really rudimentary [14:10] one can do a lot with POSIX sh already, and bash is even more powerful :) [14:11] ok, [ "${haystack%needle*}" != "$haystack" ] isn't exactly easy to read, but much cheaper than a grep [14:16] pitti: we can probably get rid of that, as we start and stop nvidia-persistenced with a udev rule /lib/udev/rules.d/71-nvidia.rules in the nvidia packages [14:17] apw: btw, in https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration you have a WI to merge initramfs-tools; infinity once said he'd also want to do a two-way merge with Debian (but that was already a long time ago) [14:17] apw: just saying for coordination [14:17] tseliot: ah, that's much more elegant indeed [14:18] pitti: I think I need to take care of this myself, as I need to test it with my systems with hybrid graphics. Sorry it's taking so long, but I've focussed on the drivers (speaking of which, nvidia-graphics-drivers-346 and nvidia-graphics-drivers-346-updates are still in Vivid NEW) [14:18] tseliot: but I figure that wouldn't provide the same "do that before lightdm" synchronization? [14:18] tseliot: ok [14:19] tseliot: actually I wonder if that upstart job is doing what you expect -- it basically doesn't do anything if prime-supported is true [14:19] pitti: the do before lightdm is a requirement only for switching between graphics drivers (as X will be off) [14:19] s/is true/shows something/ [14:19] tseliot: that's what's confuzing me [14:21] pitti: yes, maybe I made the upstart job redundant as I now handle a lot of stuff directly in the gpu-manager [14:21] this is also why I need to check [14:21] (mostly because I don't remember, it's been a while) [14:23] rbasak, jamespage: do you know what "CPC cloud images" are? https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration mentions that they have some dynamic upstart jobs === roadmr is now known as roadmr_afk [14:27] pitti: thanks for your help with the versioning - do you mind also sponsoring http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.1.9-2+deb7u1.dsc ? [14:28] hallyn: will do in a few mins [14:32] ?quit [14:45] pitti: that's utlemming and Odd_Bloke's department. Cloud images, basically. [14:45] rbasak: ah, so the CPC doesn't mean anything special? [14:47] hallyn: is debian bug 726127 fixed in testing/unstable? if so, the bug should be closed with an appropriate Version: [14:47] Debian bug 726127 in libnetcf1 "libnetcf1: The function ipcalc_netmask in netcf had a bug for any netmask > 24" [Important,Open] http://bugs.debian.org/726127 [14:47] rbasak: pitti: Also rcj. [14:48] utlemming, Odd_Bloke, rcj: does "CPC" cloud image mean anything special? https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration mentions that they create some dynamic upstart jobs [14:48] pitti: We're the Certified Public Cloud team, so it just means the cloud images that we produce. [14:49] Odd_Bloke: ah, so just http://cloud-images.ubuntu.com/ ? [14:49] i. e. this affects all cloud images, it's not an upstart job only in some "special" fork of them? [14:50] pitti: I'm not 100% sure; utlemming would be able to answer that question better. [14:50] pitti: But we do build images from the ci.u.c images specifically for some clouds, so we do have forks/derivatives of the images there. [14:51] halfie: uploaded [14:51] hallyn: uploaded [14:51] halfie: sorry, tab error [14:58] awe_: hey Tony, how are you? [14:59] awe_: do you want to review https://code.launchpad.net/~pitti/ofono/systemd/+merge/246103 or should I just push/upload this? no-op for upstart, tested with systemd on a desktop [15:00] didrocks, slangasek, xnox: hangout now, right? [15:01] jamespage: ^ if you want to join, too [15:01] pitti, [15:01] ok [15:01] pitti, just started a mtg ( that I'm leading ), will ping you when I'm done [15:01] pitti: url? [15:01] * xnox saw no emails. [15:01] xnox: in the pad [15:02] xnox: you didn't get an invite? [15:04] pitti: yeah, that bug was fixed long ago in unstable. [15:07] lol, i joined and the hangout froze =) === roadmr_afk is now known as roadmr [15:29] pitti: did you get the ubiquity review you were looking for? === kickinz1 is now known as kickinz1|afk [15:30] pitti: without the property bridge, touch should boot but without mtp support and the like. [15:30] lxc-android-boot & lxc-android-config are needed though. === kickinz1|afk is now known as kickinz1 [15:37] slangasek: yes, ubiquity is in vivid now [15:37] slangasek: and xnox also told me the secret how to test it in text mode [15:37] slangasek: so now, while it's broken in text mode under upstart, it actually works under systemd :) [15:38] heh [15:38] hallyn: ah, can you close the bug then? send to XXX-done with "Version: 1.2.3-4" (first fixed version) in the first line, and then some quick explanation [15:39] pitti: ok - i was actualy going to do that first this morning, then realized wheezy might be a problem still :) [15:40] pitti: thanks [15:40] slangasek: so if you could build a new ubuntu desktop live, I'd appreaciate -- I'd like to do the full end to end testing without the crazy casper hacking to install local .debs [15:40] hallyn: ack, thanks [15:42] pitti: I kicked off the build, it should be running now [15:43] pitti, looks good to me. One question though...what's the meaning of --nodetach on the ExecStart line? [15:43] also does "multi-user.target" == desktop? [15:43] awe_: multi-user.target ~= standard runlevel. [15:43] awe_: --nodetach is to keep it running in the foreground instead of demonizing [15:44] (default boot state for server, desktop, phone, cloud) [15:44] awe_: that's generally preferable under systemd and upstart, as it (1) avoids the unnecessary fork, and more importantly (2) you get the output logged properly, instead of it going to /dev/null [15:44] awe_: multi-user.target is roughly "runlevel 2" [15:44] awe_: i. e. it would be started on graphical and text boots after rcS/single user mode (in SysV terms) [15:45] pitti, ofonod actually does the double fork [15:45] awe_: unless it's decidedly graphical (like lightdm) or early-boot, it's the most common default target to hook it in [15:45] which is why the upstart job has "expect fork" [15:45] ( unless I'm mistaken ) [15:45] awe_: right, I know; but not with --nodetach [15:46] is there documentation for "--nodetach"? [15:46] awe_: I think I just did ofonod --help or so [15:46] hmmm [15:46] awe_: it was fairly easy to find, so I guess I got it from --help or the manpage [15:47] sorry, for some reason I thought that was being passed to ExecStart [15:47] lemme check the ofono src [15:47] awe_: so, there's two types: Type=simple (the default) just stays in the foreground, and "Type=forking" (equivalent to upstart's "expect fork") for daemonizing ones [15:47] awe_: yes, it is passed to the program you specify in ExecStart [15:48] awe_: but with it staying in the foreground it's a lot easier to debug problems (sudo systemctl status ofono will show the recent output -- journal magic) [15:48] yea... sorry, just never used --nodetach before [15:48] so... aren't there security implications for not forking into the background? [15:48] awe_: so, it works just fine by itself and with phonesim (that's already systemd-ified, I uploaded yesterday) [15:49] awe_: no; forking is really just an old way of starting daemons when we only had SysV init [15:49] awe_: it's completely obsolete with upstart or systemd [15:49] awe_: these already do that forking/isolation for you [15:50] OK, not something I was aware of... I'll take your word for it, for now. ;)- [15:51] awe_: it was the same in upstart -- daemonizing and "expect fork" worked, but you never got a log in /var/log/upstart [15:51] pitti, reviewed/approved [15:51] awe_: with --stay-in-the-foreground (for whatever daemon) and without "expect fork", we had /var/log/upstart/.log [15:51] awe_: ack, thanks [15:51] pitti, that cause the log output when to syslog, where I expected it to! [15:51] ;) [15:52] it's very useful to see ofono's log messages intertwined with NM's messages [15:52] awe_: you can still do that :) [15:52] ok [15:52] awe_: so, I don't mind much if you want to switch to Type=forking and drop the --nodetach [15:52] this is just how most other stuff behaves these days [15:53] awe_: so you get the per-unit output separately, or everything in one log, or any filtering of the complete log [15:53] let's leave it as for now. We can discuss more when we go to move the phone image to systemd [15:53] awe_: ack; either way, it's simple enough to flip [15:53] if possible, I'd like to get rid of the need for the override [15:53] if possible... [15:54] awe_: sorry, which override? [15:54] hey, one other thing.. if you get a chance, we're seeing an issue with phonesim-autostart on vivid: https://bugs.launchpad.net/ubuntu/+source/ofono-phonesim/+bug/1401143 [15:54] Launchpad bug 1401143 in ofono-phonesim (Ubuntu) "Installing ofono-phonesim-autostart makes the phone unusable" [High,Confirmed] [15:54] pitti: where is the ofono job? [15:54] So I just ran pull-lp-source and it stomped on an existing directory; is there a backup of the directory it stomped on anywhere? [15:54] any chance you could take a look [15:54] pitti, there's an ofono.override installed in touch images [15:54] pitti: did you add that it should claim the BusName=org.ofono? [15:54] awe_: don't worry about the touch, i'm working on the ofono override for touch. [15:54] awe_: ah! yeah, I guess we'll get to that when we review the touch upstart jobs tomorrow [15:55] pitti: awe_: please please =) i have a patch to the event bridge to make ofono job work on the touch properly. [15:55] xnox, please keep me in the loop... as mentioned, if possible it'd be great to get rid of the need for an override [15:55] xnox: no, I didn't; so far it doesn't do socket activation and notification anyway, but I guess it wouldn't hurt [15:56] awe_: there is an email on ubuntu-devel with rough plan, tomorrow i'll post working debs for testing. But I don't have phone to test it on, so will ask for remote hands. [15:56] xnox, ack [15:56] I"m off this afternoon, but will be around tomorrow to review/test/... [15:56] awe_: ugh, only happens on krillin, not on mako? explains why I've never seen it :/ [15:57] awe_: I keep this open and have a closer look, and check if there's anything fishy wrt. stopping it [15:57] yea... if you don't have a krillin, I can do some more debug on my end, but might have to wait till Mon [15:57] pitti, the one pain in the ass is the upstart watchdog that we added... if the respawn limit gets hit, the phone goes into a hard reboot loop [15:58] ( which I've suggested we get rid of and put a limit on number of reboots that happen ) [15:58] awe_: ah, was that added only on krillin? [15:58] no [15:58] but only vivid, not rtm [15:58] awe_: but ofonod is running, it's just not through its upstart job [15:58] ah [15:58] yea, but somehow upstart gets confused and tries to restart the ofono job [15:59] and fails repeatedly hitting the respawn limit [15:59] which then triggers the watchdog to reboot the phone [15:59] ad infinitum [15:59] pitti: ofono on the phone should not do dbus activation, this is one of the things i have fixed.... [15:59] pitti: otherwise watchdog has no idea. [16:00] xnox: ah right, so BusName= is just to determine a more precise "did that service finish starting up" [16:00] xnox, yea...that was fixed awhile back [16:00] awe_: in systemd watchdog is builtin, thus you can specify which units to activate on failure, etc. [16:00] xnox, watchdog is a new thing... to detect system processes that are in a bad state [16:00] xnox, cool [16:00] pitti: yeap, if it's on the bus, it's ready to accept connections. Previously we needed fork as the notification when it's ready. [16:00] anyways, I have to jump on to our stand-up [16:00] be around tomorrow to discuss more [16:00] thanks! [16:07] xnox: works fine, pushed to https://code.launchpad.net/~pitti/ofono/systemd/+merge/246103 [16:09] slangasek: pmcgowan: https://bugs.launchpad.net/juju-core/+bug/1409639/comments/5 *shrug* [16:09] Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] [16:14]