[05:54] <didrocks> good morning
[05:56] <duflu> Hi didrocks
[06:05] <didrocks> hey duflu
[06:32] <oSoMoN> good morning desktoppers
[06:33] <didrocks> salut oSoMoN
[06:33] <oSoMoN> salut didrocks
[06:39] <duflu> Morning oSoMoN
[06:41] <oSoMoN> good afternoon duflu
=== pstolowski|afk is now known as pstolowski
[07:50] <duflu> Just picked my first self-grown lemon
[07:50] <duflu> Very happy with that
[08:03] <Laney> yo
[08:03] <duflu> Morning Laney
[08:03] <Laney> nice one duflu
[08:04] <Laney> do you have to move it inside?
[08:04] <Laney> in the winter
[08:04] <duflu> It is winter, so no :)
[08:05] <duflu> Besides, it's a few metres tall and wide
[08:06] <duflu> Today winter means 21 degrees apparently
[08:07] <Wimpress> Morning o/
[08:07] <duflu> Morning Wimpress
[08:07] <didrocks> hey Laney, hope you got some sleep after all :)
[08:07] <didrocks> morning Wimpress
[08:08] <Laney> didrocks: URGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
[08:09] <oSoMoN> yo Laney, good morning Wimpress
[08:09] <didrocks> hum, dh_installsystemd doesn't start units by default? /me looks at the man pages
[08:10] <didrocks> --no-enable isn't set though, weird
[08:10] <oSoMoN> duflu, I planted a lemon tree and an orange tree in the spring, and there's a couple of tiny lemons growing already, I'm eagerly waiting for the winter now
[08:10] <Laney> hey oSoMoN Wimpress
[08:11] <Laney> didrocks: dh_systemd_enable / dh_systemd_start
[08:13] <didrocks> Laney: looking at the code, it's also done now by dh_installsystemd
[08:13] <didrocks> but yeah, no Install section, which isn't used in the "successful boot" systemd example, I wonder how that work then…
[08:14] <didrocks> Laney: as you can see /lib/systemd/system/systemd-bless-boot.service doesn't have an install section, I wonder how it can work then
[08:15] <Laney> I think those two I mentioned are the ones used by default (see /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm)
[08:15] <didrocks> yep, but the sequence is deprecated since compat 11
[08:16] <Laney> ah yeh, it depends which compat you have
[08:16]  * didrocks wrote some code on dh_systemd_{enable,start}, but I didn't follow that those were deprecated then
[08:16] <didrocks> but anyway, dh_installsystemd doesn't enable it because of no Install section, which is fine
[08:16] <didrocks> but I wonder how /lib/systemd/system/systemd-bless-boot.service is working then
[08:16] <didrocks> (as I'm doing something similar with zsys)
[08:17] <Trevinho> morning!
[08:17] <didrocks> hey Trevinho
[08:18] <Laney> hi Trevinho
[08:18] <Laney> didrocks: where's that enabled on your system?
[08:20] <didrocks> Laney: it's not (well, it's vendor preset: enabled for a static unit). But the unit is described in the systemd manpage as an example of a daemon to run on succesful boot
[08:20] <duflu> Morning Trevinho
[08:21] <didrocks> ah, maybe it's the generator pulling it in
[08:21] <didrocks> yeah, that's it
[08:21] <Laney> this stuff https://sources.debian.org/src/systemd/242-2/docs/AUTOMATIC_BOOT_ASSESSMENT.md
[08:22] <didrocks> right, systemd-boot starts, then the generator saw it was using systemd boot and pull this unit in the transaction
[08:22] <Laney> yah
[08:22] <Laney> like dynamic enable
[08:22] <didrocks> quite unhelpful it's named as a "good example for running a service on successful boot" by the system doc then, it's a special case :p
[08:23] <oSoMoN> good morning Trevinho
[08:23] <Laney> maybe systemd.special manpage gives you a target that does what you want?
[08:24] <Laney> although those boot ones are systemd-boot only I think and that's not explicitly mentioned
[08:24] <didrocks> Laney: well, this is where I saw the "boot-complete.target" and this is where I saw "See systemd-bless-boot.service(8) for a service that propagates boot success information to the boot loader, and orders itself after boot-complete.target."
[08:24] <didrocks> yeah, I wonder if it's systemd-boot only or not
[08:24] <Laney> that target isn't started here anyway
[08:25] <didrocks> right, hence the dynamically pulling in
[08:25] <didrocks> but the description is puzzling "This target is intended as generic synchronization point for services that shall determine or act on whether the boot process completed successfully"
[08:26] <Laney> I guess it should probably mention 'if you are using systemd-boot'
[08:26] <didrocks> agreed
[08:26] <Laney> 'man 7 bootup' has another diagram
[08:26] <didrocks> I guess anyway I want to start After=default.target
[08:27] <didrocks> but I wonder what the [Install] section would look like, it's it's normally the contrary (WantedBy…)
[08:28] <Laney> that sounds right
[08:28] <Laney> then it'll get symlinked in default.target.wants/
[08:28] <didrocks> Laney: right, but it can't be WantedBy=default.target and After=default.target, or can it?
[08:29] <didrocks> ah no, Wants doesn't impact ordering, just "inclusion"
[08:29] <didrocks> I always found it puzzling :p
[08:29] <Laney> yeah sure it can
[08:30] <Laney> WantedBy on a target gets you an After= by default btw
[08:30] <didrocks> this is weird, no? If B is wanted by A, I would expect the normal case to be "A is done once B is done"
[08:31] <didrocks> done as "started" here
[08:31] <didrocks> but yeah, that's the contrary
[08:31] <didrocks> after all those years of systemd, can still be tricked :)
[08:32] <Laney> job security :p
[08:32] <didrocks> heh
[08:32] <Laney> you might want to get a review from someone like Colin about default.target though - afaik that'll mean that it is ~always started
[08:33] <Laney> and there might be a better one to pick that expresses what you want
[08:33] <didrocks> Laney: yeah, the goal is to have it started on server and desktop, but I'll ask him when NEWing it
[08:34] <Laney> like even if you do systemd.unit=emergency.target on the commandline
[08:34] <didrocks> hum, and a combination of After=multi-users.target graphical.target default.target then?
[08:34] <didrocks> I wonder how that works when emergecy.target is targetted and the others aren't the transaction
[08:35] <didrocks> needs experimentations :)
[08:35] <Laney> the unit you boot to is aliased to default.target
[08:35] <didrocks> right, I know taht, hence the additional constratints
[08:35] <didrocks> constraints*
[08:35] <Laney> ya
[08:35] <didrocks> I'll give it some tries
[08:36] <Laney> I mean probably ideally you want that boot-complete.target for grub2 too
[08:36] <Laney> but ...
[08:36] <didrocks> sounds like impactful
[08:36]  * Laney wouldn't want to propose that :-)
[08:36] <didrocks> yep ;)
[08:39] <didrocks> let me ask Balint, he did the last uploads on systemd
[08:42] <didrocks> rbalint: hey, do you have some opinions on a good syntax to have an unit running once a system is considered as booted successful (basically after default.target when it's either multi-user.target or graphical.target, but not emergency.target for instance)? It seems that boot-complete.target is only enabled dynamically if systemd-boot is used (by the systemd-bless-boot-generator)
[08:47] <didrocks> ah, it seems that After= + Conflicts= on emergency.target would help
[08:49] <rbalint> didrocks, yes
[08:49] <didrocks> rbalint: ok, doing this and giving it some trials then. Thanks for confirming
[08:52] <rbalint> didrocks, but would not WantedBy= be enough instead of Conflicts=?
[08:54]  * rbalint reading backlog
[08:57] <didrocks> rbalint: I need to point to default.target for being able to run on servers (where it's multi-users.target) and desktop (graphical.target). However, default.target points to emergency.target if you enter this mode, and I don't want this unit to be run in that case (as the boot isn't "sucessful" for zsys)
[09:13] <rbalint> ah, ok, btw why don't you want it in emergency.target?
[09:14] <didrocks> because the unit/service purpose is to signal to zfs that the boot was successful, meaning "we can boot all a working server/desktop env" (which isn't what emergency.target conveys)
[09:37] <rbalint> didrocks, i don't think you need to special-case emergency.target in your services file, emergency.target won't start other services by default (while you can start them manually)
[09:37] <didrocks> rbalint: wouldn't WantedBy=default.target be equivalent to emergency.target?
[09:38] <didrocks> if you start the system explicitely with emergency
[09:39] <rbalint> didrocks, no, emergency.target is special and will not run services
[09:40] <didrocks> rbalint: ok, worth a try then, thanks for the feedback :)
[09:40] <Laney> what about rescue.target?
[09:42] <rbalint> Laney, special targets don't need special handling in 'normal' services to minimize the configuration to be written, so it should not be handled in zsys either imo
[09:42] <Laney> if the point of the service is to record a successful boot
[09:45] <rbalint> Laney, the zsys service would not be run by default in rescue.target because it is a generic service
[09:49] <Laney> rbalint: ok, I'll take your word for it, thx
[09:49] <rbalint> didrocks, Laney a good way of looking at the connections between targets services is runnuning systemd-analyze dot | grep rescue
[09:49] <Laney> perhaps default.target is statically defined and not per-boot like I thought it was
[09:49] <Laney> if so, then this wouldn't be a particular problem
[09:50] <didrocks> rbalint: ok, however, we don't have the link with "default.target", but I'll take your work on it too :) (better to not hardcode anything)
[09:51] <didrocks> Laney: seems like default.targe requires multi-user.target
[09:51] <didrocks> target*
[09:51] <Laney> it's a symlink
[09:51] <didrocks> ah right
[09:52] <Laney> to graphical.target, but I thought systemd set that up in /run or something when you give systemd.unit
[09:52] <Laney> maybe not
[09:52] <didrocks> so yeah, maybe not dynamic
[09:52] <didrocks> same
[09:52] <didrocks> it means that desktop/server package have some Replaces?
[09:52] <didrocks> weird
[09:52] <Laney> not sure who manages that
[09:55] <Laney> looks like we always pull graphical.target
[09:56] <Laney> TIL I guess :>
[09:56] <didrocks> wondering what happens on server, so graphical.target but not real interesting units installed on it
[09:56] <didrocks> yep :p
[09:56] <Laney> means you can't just install something for graphical.target and assume it won't be run on a server
[09:57] <didrocks> or you can say "if you install gdm on server, it will start it", which is the positive side :p
[09:57] <didrocks> but yeah, I wasn't expecting that either
[14:17] <ogra> oSoMoN, do you have nscd or unscd installed on the machine you are testing the chromium snap ?
[15:21] <robert_ancell> kenvandine, do you know who would be able to respond to https://github.com/ubuntu/yaru/issues/1433 ?
[15:23] <oSoMoN> ogra, neither, so I guess the fact that I'm seeing this working is because the test service is on the same machine
[15:23] <oSoMoN> oh, just seeing your followup comment now…
[15:24] <oSoMoN> I wonder what differs between our setups
[15:25] <oSoMoN> would anyone be willing to test bug #1838038 and comment on whether the test in comment #1 is working for them?
[15:25] <ubot5> bug 1838038 in chromium-browser (Ubuntu) "[snap] Chromium does not work with .local mdns/avahi name resolution" [Undecided,New] https://launchpad.net/bugs/1838038
[15:33] <kenvandine> robert_ancell: there's work close to landing that will help improve support for using themed icons
[15:33] <kenvandine> so if that icon was in the yaru theme
[15:33] <kenvandine> we can install our current  icon as a fallback for when the theme doesn't provide it
[16:22] <ogra> oSoMoN, well, it is very funny that it works for you because thats technically impossible (no mdns support in core means you simply can not access that protocol) ... are you 100% sure you are using the snap binary ? :)
[16:24] <ogra> (or are accidentually running in --devmode or some such ....)
[16:26] <oSoMoN> ogra, "impossible n’est pas français" :) yes, I'm positive I'm running the actual chromium snap, strictly confined
[16:26] <ogra> so weird
[16:26] <oSoMoN> will try in a VM in a moment
[16:27] <oSoMoN> too many VMs running at once…
[16:27] <ogra> heh
[16:28] <ogra> well, it starts woring fine for all my snaps when installing nscd but thats a universe package we cn indeed not require .... it also makes spotify discovery for other devices work ...l which also depends on mdns ...
[16:28] <ogra> as soon as i install nscd my snap starts seeing the chromecase i my living room and my phone
[16:29] <ogra> if i remove it again chromium and spotify reliable refuse to open mdns stuff again
[16:29] <oSoMoN> ogra, including that very simple test with the python http server?
[16:29] <ogra> s/chromecase/chromecast/
[16:29] <ogra> yes
[16:30] <oSoMoN> I probably have additional stuff on my laptop that somehow make this work
[16:30] <ogra> well, nscd or unscd would be a candidate, thats whyy i asked .... i wouldnt know any other thing that could make it work though
=== pstolowski is now known as pstolowski|afk
[17:44] <robert_ancell> willcooke, can you open a new team update thread?
[17:45] <willcooke> robert_ancell, on it
[17:47] <willcooke> robert_ancell, https://discourse.ubuntu.com/t/desktop-team-update-monday-5th-august-2019/12059
[18:03] <robert_ancell> willcooke, argh, now I've forgotten the thing I had done I was going to note...
[18:04] <willcooke> :))
[18:45] <robert_ancell> popey, did you intentionally add the whitespace in the description text of Word Salad snap but expect it to be in bold, i.e. "** Word Salad **"? (See https://github.com/canonical-web-and-design/snapcraft.io/issues/2127)
[18:45] <robert_ancell> (If it is supposed to be bold please leave as is until the bug is checked)