[00:00] pitti: should gssd.service just have a ConditionVirtualization=!container added? [00:05] maybe we should just allow the rpc mounts... [00:07] but adding that to run-rpc_pipefs.service does work === shoutme is now known as hallyn [00:33] slangasek: apologies for the delay, i think i've got the split main/universe build for php7.0 working with just a one-variable chagne between the two src packages ... build & testing now, will let you know [00:35] jgrimm: checksecurity merge request sent [00:35] smoser: thanks for your help! === dasjoe_ is now known as dasjoe === psivaa_ is now known as psivaa === balkamos_ is now known as balkamos === daxcat is now known as dax [01:46] nacc: cool, thanks! === juliank is now known as Guest26968 === juliank_ is now known as juliank === pepee- is now known as pepee [03:27] Pici: found the issue with the jenkins image importer, fixed now, it's processing its backlog which should take quite a few hours (about 200 images to download, unpack, update, repack, sign, ...) [03:27] pitti: ^ [03:27] Pici: sorry, bad tab completion :) === tsimonq2alt is now known as tsimonq2- === tsimonq2- is now known as tsimonq2 [04:05] stgraber: yay, thanks for fixing the image builds [04:05] Good morning [04:33] can someone nuke this from the sponsorship queue https://code.launchpad.net/~maozhou/ubuntu/utopic/tomboy/bug-12345/+merge/283581 [04:34] it was just someone playing around with merges by the looks of it [04:52] darkxst: set to "rejected", that should do [04:52] pitti, thanks! === marcusto_ is now known as marcustomlinson === kitterma is now known as ScottK [05:38] @pilot in === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst === wilhelm.freenode.net changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [05:51] yofel, debfx: both our telepathy-qt and telepathy-qt5 packages are wildly out of date, use gstreamer 0.10 etc., and it seems the reason for the split is long gone: Debian's telepathy-qt builds both qt 4 and qt5 packages [05:51] can we just sync/merge this? [05:53] yofel, debfx: see bug 1538772, keeping notes there [05:53] bug 1538772 in telepathy-qt5 (Ubuntu) "Stop build-depending on libfarstream-0.1-dev" [Undecided,Confirmed] https://launchpad.net/bugs/1538772 === tjaalton_ is now known as tjaalton [06:16] yofel, debfx: I put a merged test package into my PPA, some testing would be great === mfisch is now known as Guest38484 [06:28] good morning [07:07] anyone able to add gitg to desktop-extra packageset (I am sure it was meant to be done already, but apparently not) [07:29] how come https://launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu shows the package is in universe when apt-cache policy shows the binary is in main? [07:37] xserver-xorg-video-amdgpu | 1.0.1-1build2 | xenial | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x [07:37] xserver-xorg-video-amdgpu | 1.0.1-1build2 | xenial/universe | source [07:37] xserver-xorg-video-amdgpu-dbg | 1.0.1-1build2 | xenial/universe | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x [07:37] tjaalton: wrong overrides; where is this supposed to be? [07:38] main [07:38] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1543659 [07:38] Launchpad bug 1543659 in xserver-xorg-video-amdgpu (Ubuntu) "MIR: xserver-xorg-video-amdgpu" [High,Fix released] [07:38] tjaalton: ok, fixed [07:38] thanks! [07:40] tjaalton: been fielding support questions about fglrx recently. checking i'm reading right: no more fglrx in xenial onwards, right? [07:40] dax: right [07:40] amd finally confirmed it in public [07:40] thanks (and thanks for getting rid of it, though it'll make #ubuntu fun for a cycle or two i'm glad it's gone) [07:41] there's going to be a userspace blob at some point, but it's only for the amdgpu stack [07:41] *nod* [07:41] good morning [07:41] i've been using radeon for ages and have been reading about amdgpu. just wasn't sure if it was yet another temporary delay in xorg compat or if it was permanent [07:41] http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/857070-ubuntu-is-deprecating-fglrx-catalyst-in-16-04-lts/page6?_=1457549209785 [07:42] comments by bridgman and twriter [07:42] I emailed tim yesterday and begged that they'd make it public :) [07:43] there's probably going to be a more formal announcement too [07:46] now if only it'd be ok to build a fully featured mesa and then just put some binaries in universe that'd be cool (vaapi, opencl..), but main/universe split makes it impossible [07:48] wgrant: hey William, how are you? [07:49] wgrant: I did a boo-boo with process-removals (had some 'y's in the input buffer) [07:49] wgrant: can I un-remove a package from xenial, or do I need to reupload/rebuild? [07:52] pitti: Morning. [07:52] pitti: You can use copy-package to revive it. [07:52] wgrant: copy from where then? [07:53] pitti: copy-package --from-suite=xenial --to-suite=xenial -e 1.2.3-4 -b --auto-approve --force-same-destination somepackage [07:53] wgrant: hah, lol; thanks [07:53] The -e picks a version other than the current one. [07:54] So it doesn't matter if it's published or not. [08:03] yofel, debfx: qtmobility got removed in Debian, only rdepends in Ubuntu is artikulate; is this still something we want to keep? [08:04] (it also uses the obsolete gstreamer0.10) [08:10] pitti: qtmobility-dev likely just needs to be dropped from build-deps [08:10] ^ [08:12] where does it use gstreamer0.10? I only see a dep on libqt5gstreamer-1.0-0 [08:13] Comment: (From Debian) ROM; will not get ported to GST 1.0, superseded by Qt5; Debian bug #802642 [08:13] Debian bug 802642 in ftp.debian.org "RM: qtmobility -- ROM; will not get ported to GST 1.0, superseded by Qt5" [Normal,Open] http://bugs.debian.org/802642 [08:13] that's what the Debian removal bug says [08:13] and it also seems generally obsolete [08:14] debfx: libqtmultimediakit1 depends on libgstreamer0.10-0 [08:16] right, so applying http://anonscm.debian.org/cgit/pkg-kde/applications/artikulate.git/commit/?id=609f5b1 and killing qtmobility is the solution [08:18] debfx: ah, thanks; so good to remove? [08:25] qtmobility? sure. would be nice if someone could fix artikulate before. [08:30] @pilot out [08:36] debfx: uploaded/removed [08:38] xnox: hey! do you have some time to look at the s390x test failures of upstart? [08:41] please could an archive admin promote python-pika-pool to main? MIR bug 1552827 approved - the old version oslo.messaging in the release pocket is causing test failures right now for openstack testing [08:41] bug 1552827 in python-pika-pool (Ubuntu) "[MIR][FFE] Please sync python-pika-pool (0.1.3-1) from Debian (unstable)" [Undecided,Fix committed] https://launchpad.net/bugs/1552827 [08:46] jamespage: it's not on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- you need to make something in main depend on it [08:46] otherwise the next AA will demote it back [08:47] pitti, python-oslo.messaging is depwaiting on it [08:47] letme check again [08:48] jamespage: ah sorry, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt [08:48] pitti, yup [08:48] promoted [08:49] pitti, I'll also need a binary only of python3-pika please [08:49] source already in main [08:50] jamespage: I did all the ones on the above list, including that [08:52] pitti, thankyou [09:31] nacc: php5.6 got removed in Debian, do we want to follow suit? I assume yes as you're heading for 7.0, but want to confirm [09:33] nacc: well, I remove it for now, our only change was an FTBFS fix; I can bring it back if necessary [09:33] nacc won't be up for a while. I know the plan is to remove 5.6. I didn't know what stage nacc was at for that though. [09:33] Presumably all the reverse deps are gone now? [09:34] * php-redis (for php5.6-dev) [09:34] * php5.6-json (for php5.6-dev) [09:34] rbasak: php5.6-json was also removed (I just did that in Ubuntu) [09:34] rbasak: and php-redis needs a rebuild against php7, I just synced the new Debian package [09:34] rbasak: i. e. yes, all gone [09:34] Not sure about php-redis. php5.6-json is 5.6-specific. 7.0 has a replacement json that doesn't need a separate source package IIRC. [09:35] I also removed a whole bunch of obsolete php-* stuff (via debian removals), should help a bit [09:37] (I also synced dh-php and php-igbinary, as php-redis needs those) [09:49] Unit193: do you still care about dvdstyler? it's the only thing which still holds the obsolete wxsvg in Ubuntu (got removed in Debian bug 813151) [09:49] Debian bug 813151 in ftp.debian.org "RM: wxsvg -- RoM; unmaintained, library without rev deps" [Normal,Open] http://bugs.debian.org/813151 [09:55] I did the last upload because it didn't function at all, afact there's no new version that ports from wxsvg. [10:20] Unit193: right, my question was in the direction of "is dvdstyler obsolete and should be removed?" or is there still some upstream for it [10:21] pitti: Ah! Well they did just release a new version in Jan, but I don't actually know much more than that, never used it myself. Sorry. [10:23] * pitti tries to find some ubuntustudio folks [10:24] zequence: ^ hey, how are you? do you know about dvddstyler? ^ [10:33] juliank: apparently some amd64-ism crept into apt's test suite? tests now fail on anything except amd64 [10:33] dpkg: error processing archive /tmp/tmp.tKhfFn1igl/aptarchive/pool/pkgb_1_amd64.deb (--unpack): [10:33] package architecture (amd64) does not match system (i386) [10:33] pitti: Yes, I'm aware of that and forwarded it yesterday to DonKult [10:33] juliank: ah, danke [10:34] pitti: In the meantime, ignoring them is the way to go. (Problem being that while we set APT's architecture, we do not configure dpkg's architecture, but install packages, which fails) [10:46] pitti: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=e457c94 [10:47] juliank: yay you, danke [10:47] bb [10:47] oops [10:48] i386 also failed the (flaky) download progress test again [10:55] pitti, upstart is not used on s390x at all =) [10:55] it's only used in desktop sessions, and there are no desktops on s390x. [10:55] xnox: oh, so it's not even installed by default? [10:56] xnox: indeed, only rdepends on my system is unity-greeter (ugh, there should be some more for sure..) [10:56] xnox: you mean we could/should remove the s390x binaries? [10:57] pitti, i don't think we will like an arch skew, nor the build depends skew (there are things that depend on libupstart et.al.) [10:57] but it's definitely not supported =) [10:57] well, it's ftbfs on s390x; we could also disable the tests on s390x [10:57] i can look at the test failures out of interest. [10:57] xnox: oh, I don't have libupstart1 installed [10:57] however, upstart is a good kernel tester. [10:58] only libupstart-dev depends on it [10:59] horum. there should have been deps in app-launchers and things, unless they have switched to dbus direct. [11:05] pitti, around? i've got some systemd networking questions. [11:05] https://public.etherpad-mozilla.org/p/cloud-init-networking has some background. [11:05] see description around line 39 there. [11:06] pitti: Seems my assistance was not needed :) [11:07] zequence: why? there was no other answer about this so far (nor an upload) [11:07] smoser: (be with you in a sec) [11:07] k. thanks. [11:07] zequence: i. e. it's still "do we want to keep and update dvdstyler or remove it" [11:07] pitti: Oh, I thought someone was on it [11:08] Ah, right. Yes, I'll check with Len Ovens, who is the one in our team who is most informed on that package [11:10] smb, ogasawara, seb128 Hello Pilots - If you could take a look at my sponsoring requests during your pilot sessions today I'd really appreciate it :-) [11:11] smoser: these steps seem fine to me; let me see where cloud-init-local hooks in right now, i. e. that it's a proper place for this [11:12] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/systemd/cloud-init-local.service [11:12] pitti: I'll get back to you about the package within a day or so. Just double checking with Len first. [11:12] smoser: ah, was just doing "systemctl cat" on a cloud instance [11:12] flexiondotorg, did you test compiz? why did not you update your branch for review? [11:12] zequence: great, thanks a lot for your efforts [11:13] muktupavels, Because I work on this stuff in my spare time and my time is limited :-( [11:14] muktupavels, It is 2nd on my list though. [11:14] pitti, thanks for systemctl cat. did not know. [11:14] smoser: so, cloud-init is after=local-fs.target, but at first sight I don't see a strict enough Before= that would cause networking stuff to wait? [11:14] yeah. at the moment networking is not blocked at all. [11:15] smoser: "systemctl show -p After cloud-init-local" is also quite useful [11:15] smoser: as that shows you the properties "all combined" [11:15] cloud-init-local needs filesystems (and yes, /usr) [11:15] i. e. if some other unit bar.foo does Before=foo", then showing foo.service will show After=bar [11:16] smoser: can/should we just redefine cloud-init-local to block bringup of network, or is there stuff happening there that already needs network? [11:16] smoser: (if so, it would be wrong as it doesn't depend on networking, but still asking) [11:16] no. it should not need network [11:16] it looks at local sources of information such as attached disks or stuff in the filesystem [11:17] or as described there to add 'ip=' flag [11:17] muktupavels, I see you've got a merge proposal in. [11:17] smoser: btw, this might not run as early as you think, as it doesn't have DefaultDependencies=no [11:17] muktupavels, What help do you require from me to progress this? [11:17] smoser: in old SysV terms, this runs in rc2, not in rcS (which you'd get with DefaultDeps=no) [11:17] flexiondotorg, what merge proposal? [11:18] https://code.launchpad.net/~albertsmuktupavels/compiz/gwd-marco-gsettings/+merge/287820 [11:19] flexiondotorg, just merge it in your branch and test it. I pushed that only as example. [11:20] yeah, goal is "as early as i can pallet". i think i'm probably ok. . i need /var/lib/cloud, /usr/bin/cloud-init really want /run . [11:20] smoser: /run is always there, that's no problem [11:20] smoser: do you support craziness like /var on NFS for cloud-init? [11:20] (as that would be a circular dependency then) [11:21] for c-i-local.service [11:21] at this point i dont think so. [11:21] i think if someone really wanted such a thing, then we might try to get there, but it wouldnt work right now. [11:22] smoser: so, I left some notes in the pad [11:24] pitti, thanks. wrt seriallized boot, you may be interested in the generator i added, which means you can completely disable cloud-init (well,. other than the generator running) [11:24] smoser: line 70 → is that a systemd generator? or some other kind? (as these run even earlier) [11:25] yeah, the generator is what allows you to disable cloud-init entirely [11:25] i'd also like at some point it to be able to change cloud-init to only run in a way that is guaranteed to not foobar your ENI [11:26] * pitti yays lots of shell in early boot :) [11:26] smoser: any chance to at least drop the shell parsing of /proc/cmdline? [11:26] you can add ConditionKernelCommandLine= to any unit to run (or not run) it for certain kernel command line options [11:28] smoser: is =enabled and =disabled already released API? (most other kernel options use =1 or =0, or no value at all) [11:32] pitti, i'm not opposed to changing =enabled or =disabled. to =1 or =0, but one seems less magic. [11:32] the kernel command line parsing also supports reading the environment variable which could be set in lxd (right now lxc does not mask /proc/cmdline) [11:34] i dont think performance is likely an issue in reading proc cmdline. the logging in that script probably is much more a performance issue [11:36] actually, the one fork i make (systemd-detect-virt) is probably 90% of the time for that functionality [11:37] smoser: ConditionKernelCommandLine= actually does just that [11:38] smoser: if it's booting on a real kernel, it parses /proc/cmdline, otherwise it takes the argv of pid1 [11:38] i. e. lxc's flavor of a "kernel"(ish) command line [11:38] and there's ConditionVirtualization= which also avoids the fork [11:38] (but I think you don't actually need that [11:39] muktupavels, OK, will do. [11:40] smoser: anyway, that's quibbling over less code/optimizing etc; I guess the important bit here is the Before=network-pre.target (and moving earlier into the boot) of c-i-local? [11:40] yeah. [11:40] smoser: where does this $KERNEL_CMDLINE thing come from? [11:41] it would allow you to set that in lxc's pid1 [11:41] i dont know that the argv of pid1 would be sufficient or not [11:41] can i run '/sbin/init cloudinit=1' and systemd not be bothered by that ? [11:43] KERNEL_CMDLINE is not standardized in any way. i picked an environment variable name. if there is a more appropriate one, good with that. [11:43] smoser: well, "bothered", that's how every init is called; it will of course pick out stuff like systemd.log-level or so, but it ignores unknown arguments, yes [11:44] (or quiet/debug/emergency) [11:44] so you can e. g. do sudo lxc-start -n adt-wily /sbin/init rescue -F [11:44] starting a container or a kernel isn't much different wrt. kernel command line parsing really [11:45] for clarity, the -F belongs to lxc-start, so like: sudo lxc-start -F -n adt-wily /sbin/init debug cloudinit=1 [11:45] systemd will recognize the "debug" as somethign it knows, and just ignore the cloudinit= [11:45] ok. i'll consider that, adn the systemd conditions in the generator too [11:46] 2 things i'd like generally... [11:46] smoser: generators don't have conditions (as they are not units), they always run [11:46] i'd like to be able to read "is this a container" (systemd-detect-virt) without a fork [11:46] well, you can programatically check for stuff of course [11:46] i. e. my point is, I believe you don't need the generator at all [11:47] i'd like to be able to read the cmdline without a fork too (reading /proc/1/cmdline and /proc/1/environ are null terminated. easy for anything but shell) [11:47] I think this boils down to ConditionKernelCommandLine=!cloud-init=disabled [11:47] maybe, yeah. [11:48] and you don't really need the dynamic enaling then, as the condition will already make cloud-init*.service a no-op if disabled [11:49] and the detect-virt goes away as ConditionKernelCommandLine= DTRT for both "real" kernels and container pid 1's [11:49] and ConditionPathExists! [11:49] pitti, oh. the other thing i thouht i got from the generator. [11:49] was that i have no bottlnecks in boot [11:50] ie, one thing runs and then if disabled, the others do not run [11:50] rather than having the bottleneck come down to cloud-init-local and then checking for that file [11:51] well, they don't actually fork/run anything [11:51] "they" -> Condition* [11:51] no. but they force a bottleneck [11:51] ie, if cloud-init-local blocks networkign coming up, then there is a bottleneck at boot down to that one job [11:52] and then another at the point where i want cloud-init to run [11:52] ah, you'd make network-pre.target run after local-fs.target, yes [11:52] where with the generator i thought i incur the single cost of the generator and if disabled, then cloud-init has *no* affect on boot [11:52] which is not really a biggie as everything that actually touches network config also needs After=local-fs.target [11:54] well, then i'm free to do what ever silly things i want to do to boot. [11:54] smoser: well, cloud-init-local.service really doesn't do much serialization (other than network-pre.target after local-fs.target); I guess the stating and symlinking and parsing that you do there is probably a dozen times heavier :) [11:54] but i think its probably really a very small optimization. [11:55] also cloud-init.service forces some bottlenecks. [11:55] for sshd.service etc. [11:55] its fine. i think this is mostly in the terms of "small" then. i was more concerned that cloud-init's presense on disk had negative affects on boot when it wasn't utilized. [11:55] i'd like for peple to not think 'cloud-init sucks, purge it' [11:55] but rather cloud-init could be useful, i'll just disable it. [11:56] you've convinced me its a small thing, and i'm not opposed to looking into your path for sure. [11:56] smoser: so cloud-init.service serializing ssh.service after network-online.target is the main serialization that I see [11:56] (and i have another email to you about ssh.service and pollinate) [11:56] smoser: for that a generator might make sense [11:58] i do want cloud-init.service to generally block everything it can [11:58] for just about all of boot to serialize on it (and cloud-confnig.service) so that they can affect as much of boot as possible. === _salem is now known as salem_ [12:04] pitti, that make sense? generally speaking i *want* to serialize boot. so that users can provide user-data that will run "as soon as networking is up" and affect other parts of boot. [12:04] unfortunately, it seems that systemd is not as dynamic as upstart was in that regard [12:05] they can't just drop new units in and have them consumed via inotify [12:05] smoser: sure; you can hook into network-online.target to block that (and everything that waits on it) [12:05] how can i hook into it ? [12:05] right, you need to enable new units [12:05] smoser: Before=network-online.target [12:06] (or whichever other target you want to "block") [12:06] and that will run when networking is up [12:06] but block anything else that would need it ? [12:06] of course you can't then simultaneously have After=network-online.target as it does rigth now [12:07] you could add an After=networking.service (for ifupdown), if you don't care about other methods [12:07] so cloud-init.service will need to use the configured networking to go looking for a datasource [12:07] then you'd have networking.service -> cloud-init -> network-online.target -> everything that depends on that [12:07] so yeah, thats what i want. but that is only accomplishable on ubuntu ? [12:08] but of course not all services depend on that, so if you really want to affect *all* services you can only run a generator [12:08] (but then have literally no assumptions) [12:08] .... and dhcp request sent with "wrong" hostname.... [12:08] xnox, well, you'll be happy to know that on azure, they bounce the dhcp interface so that it does it with the right one [12:08] smoser: network-online (and pretty much all other targets) are cross-distro; *.service are often distro specific, e. g. networking.service is "ifupdown" [12:09] smoser, excellent. I guess i just need s390x on azure then =) [12:09] smoser: so indeed if you run on a distro that doesn't have ifupdown, you can't use this (but they your network config bit wouldn't work in teh first place -- you probably want to ship a networkd config or somethign such) [12:09] pitti, yeah. well, a cross distro blocking "network is up" event is what i'm after. [12:09] smoser: that's network-online.target, pretty much [12:10] yeah. other than the blockign part :) [12:10] smoser: but I meant, a lot of services don't wait for that, but already start before [12:10] pitti, you've been so very helpful, thank you. [12:10] there is a generic event for "network is available" network-online.target, but things that provide network block that, and don't create an alias... [12:10] say, postgres or ssh [12:10] smoser: the blocking is your decision (adding a Before=n-o.t) [12:11] it could be networkd, networkmanager, ifupdown, what not. So I don't think there is a generic way to block /those/ things that configure the network. [12:11] unless you opportunistically encode all of their names. [12:11] xnox: yeah, that'd be network.target [12:11] (sorry, I thought you meant "use the network") [12:12] pitti, i thought that e.g. "before=network.target" unit, may still run in between say networkd and network.target. [12:12] as e.g. networkd is simply before network.target.... no? [12:12] well, yeah. i want to be able to run code when the network is up that basically blocks all other code that would expect the network to be up. [12:12] but i want to not know what brought that networking up [12:12] i want to be special! [12:12] ah. [12:12] xnox: right, sorry, network-pre [12:12] you are talking about two different things [12:12] pitti, oh, that one, ok. [12:12] right. [12:13] smoser talks about "using the network" (but after configuring it) -> network-online.target [12:13] xnox talks about "things that bring up interfaces" (network-pre.target) [12:13] yes. i need both. [12:13] cloud-init-local before network-pre.target [12:13] and [12:14] cloud-init after network-online.target [12:14] but what i want is [12:14] cloud-init=network-online.target [12:14] smoser: right, the -local bit should run very early (as said in the pad, that shows how to put it earlier) [12:14] you can make cloud-init to be required by network-online.target, and just wait for network to be up. [12:14] because that target is a blocking one already. [12:15] hm.. [12:15] well, depends [12:15] * xnox with his upstartish ways of doing things [12:15] stuff like postgres or haveged or whatnot isn't caring about network [12:15] right. somet hings i can't affect. thats fine. [12:15] so those things need to be configured in -local then [12:16] or local should install a firewall rule =) har har [12:16] smoser | cloud-init=network-online.target [12:16] smoser: ^ what does that mean? [12:16] Before and After [12:16] :) [12:16] well, a target is a synchronization point, it doesn't "do" anything [12:17] i.e. you can run before or after, but not "in" it [12:17] right. but i need to run after it is there and want to stop evyerthing else that would run 'After' it [12:17] and by default that target is empty, and a thing that brings up network has a helper to say "network is online". [12:17] that's similar to upstart, yuou can either do "on starting" or "on started" (before or after) [12:17] so on ubuntu [12:17] right. [12:18] smoser: that concept of "I want to be the only one" doesn't exist in any init system any more [12:18] network-online.target.wants -> [networking.service, NetworkManager-wait-online.service] [12:18] (not even sysv with inssersv) [12:18] because, what happens if there's another package which wants to be the only one? :-) [12:18] thus on ubuntu you want to be (a) wantedby -online.target (b) after = [networking.service, NetworkManager-wait-online.service] [12:18] pitti, you're completely missing the point. *I* want to be special [12:18] i dont care about other people! [12:18] :) [12:19] oh, right :) [12:19] you can add wanted by everywhere, and to work everywhere you should add After = networkd [12:19] and that's it. [12:19] reminds me of those bug reports that say "this must be the last thing on boot" [12:19] (and of course I've seen at least three *different* people/packages claiming that) [12:20] smoser: so yes, if you want to block a target, do Before=network-online.target, and wait on the specific thing you just configured, like networking.service [12:20] there shoudl be a target "basically-last-thing-in-boot" [12:20] smoser: and if/once cloud-init learns how to setup networkd, you can add After=systemd-networkd.service too [12:20] rc.local (what it used to provide) is such a very useful thing for normal humans. [12:20] we call that "multiuser.target" =) [12:20] but, lets not go there :) [12:20] well, that conceptually isn't possible :) [12:20] and 147 things run at 'multiuser.target' [12:20] (and that's completely independent of insserv/upstart/systemd) [12:20] not systemd-networkd.service, but after systemd-networkd-wait-online.service. [12:21] hey. [12:21] i really do have to run now. [12:21] ok, time for lunch then [12:21] xnox and pitti have been very, very helpful [12:21] thank you [12:21] pitti at your leisure, yuou have an email about pollinate from me too. [12:21] thanks again. [12:22] best irc chat ever. [12:22] smoser, but given our on/off thing, your cloud init generator will need to install "cloud-init" wanted by "network-online", the After= lines can be encoded for all the world wide known network-online.target wanted'bys.... [12:22] really, thank you! [12:22] or even better the generator can sniff those off disk. [12:23] cause you want to create network-online.target.wants/cloud-init.service & create cloud-init.service.d/after.conf -> and that conf will list [Unit]\n After=`ls /etc/systemd/system/network-online.target.wants` [12:27] xnox: urgh, that sounds way too hackish [12:27] =) [12:27] xnox: cloud-init can only configure ifupdown anyway, so there's little point waiting for the others [12:29] pitti, it's not about configuring network however. ifupdown can only be done by cloud-init-local. I think what smoser here is after "network is configured by whatever" now block all services and wait for cloud-init to finsih installing/upgrading packages; configure users etc..... do everything. And then unblock network services to spawn everything else. [12:29] e.g. sshd server. [12:29] xnox: correct, which is just Before=network-online.target in cloud-init.service [12:30] pitti, can one be wantedby & before network-online.target? [12:31] it can't be before network-online.target, as then it will before network is actually configured.... [12:31] xnox: yes, that's by far the most common behaviour (it's unusual for something to want a dependency, but that dependency should run *after* oneseelf) [12:31] e.g. before network-online.target, will be before networking.service/NetworkManager-wait-online.service [12:31] no? [12:32] xnox: right, hence cloud-init.service being After=networking.service Before=network-online.target [12:32] that's racy. [12:32] as we don't (currently) care a bout anything else in cloud-init than ifupdown [12:32] ok. so it's racy in network configs that support -wait-online stuff properly (e.g. networkmanager, networkd) [12:33] if you want to block on those too, then add them to After=, yes [12:33] right, gotcha. [12:35] muktupavels, I've built Compiz with you changes stacked on mine here - https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+build/9327928 [12:36] muktupavels, And tested it. Works great. Thanks for your help on this, it is much appreciated :-) === yofel_ is now known as yofel [12:38] muktupavels, Changes merged in the proposal - https://code.launchpad.net/~ubuntu-mate-dev/compiz/marco-gsettings/+merge/282882 [12:40] Trevinho, I've merged and tested the changes muktupavels suggested for the improve Marco integration in Compiz. Please review https://code.launchpad.net/~ubuntu-mate-dev/compiz/marco-gsettings/+merge/282882 === francisco is now known as Guest63468 [13:15] could somebody look at bug 1555046 and help us get it uploaded? the shimmer-themes package is snatched from xubuntu by some dependencies to the kubuntu packageset so we're unable to do that ourself [13:15] bug 1555046 in shimmer-themes (Ubuntu) "Please upload shimmer-themes-2.1.1-0ubuntu1 to xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1555046 [13:15] cheers! [14:22] pitti, "conflicts/before=shutdown.target" ? [14:29] smoser: that's to ensure that it gets stopped on shutdown (shouldn't be relevant, it's just standard practice; see man systemd.service DefaultDependencies) [14:29] ah. ok. [14:30] is there a way that i can get systemd to print a log with microsecond timestampos of services and targets ? [14:30] that were started thus far. [14:54] pitti, ^ is that just an ignorant question ? [14:54] smoser: (in meeting, bbl) [14:54] perfectly acceptable. thanks. === Pici- is now known as Pici [15:00] smoser: jounralctl -o short-precise? [15:00] smoser: journal always stores microseconds, it's just output formatting/presentation [15:02] but that is just stuff that got written to journal [15:03] (had journal output or somethingt) [15:03] suytemd ran a bunch of servivces and decided that some targets were reached. [15:03] it did that at certain points in the boot [15:04] i'd like to get timestamps of every one of those. [15:04] systemd-analyze critical-chain is useful [15:20] smoser: yes, these are recorded in the journal too [15:21] smoser: Mär 10 05:01:27.102984 donald systemd[1]: Starting Load Kernel Modules... [15:21] smoser: something like this "Starting/Started", coming from systemd itself) [15:22] smoser: yeah, systemd-analyze can massage these nicely too; "plot" for the visually inclined :) [15:23] infinity: regarding the mstflint adujstment of yesterday I have a few final questions [15:24] infinity: trusty's version is 1.4-OFED-1.4.2-1ubuntu1 and wily's version is 3.7.0+1.18.gcdb9f80-3.1ubuntu2. I supposed that the versionned Breaks should be << 3.7.0+1.18.gcdb9f80-3.1ubuntu2 (wily's) ? [15:24] pitti, ok. i was just not seeing what i was looking for becausae systemd shows the 'Description' there [15:24] which then you have to map back to the unit [15:25] ie, if i want to know about 'pollinate' [15:25] # journalctl -o short-precise | grep Seed [15:25] that works [15:25]