didrocks | good morning | 05:54 |
---|---|---|
duflu | Hi didrocks | 05:56 |
didrocks | hey duflu | 06:05 |
oSoMoN | good morning desktoppers | 06:32 |
didrocks | salut oSoMoN | 06:33 |
oSoMoN | salut didrocks | 06:33 |
duflu | Morning oSoMoN | 06:39 |
oSoMoN | good afternoon duflu | 06:41 |
=== pstolowski|afk is now known as pstolowski | ||
duflu | Just picked my first self-grown lemon | 07:50 |
duflu | Very happy with that | 07:50 |
Laney | yo | 08:03 |
duflu | Morning Laney | 08:03 |
Laney | nice one duflu | 08:03 |
Laney | do you have to move it inside? | 08:04 |
Laney | in the winter | 08:04 |
duflu | It is winter, so no :) | 08:04 |
duflu | Besides, it's a few metres tall and wide | 08:05 |
duflu | Today winter means 21 degrees apparently | 08:06 |
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:07 |
Laney | didrocks: URGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH | 08:08 |
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:09 |
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:10 |
Laney | didrocks: dh_systemd_enable / dh_systemd_start | 08:11 |
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:13 |
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:14 |
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:15 |
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:16 |
Trevinho | morning! | 08:17 |
didrocks | hey Trevinho | 08:17 |
Laney | hi Trevinho | 08:18 |
Laney | didrocks: where's that enabled on your system? | 08:18 |
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:20 |
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:21 |
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:22 |
oSoMoN | good morning Trevinho | 08:23 |
Laney | maybe systemd.special manpage gives you a target that does what you want? | 08:23 |
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:24 |
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:25 |
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:26 |
didrocks | but I wonder what the [Install] section would look like, it's it's normally the contrary (WantedBy…) | 08:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
didrocks | let me ask Balint, he did the last uploads on systemd | 08:39 |
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:42 |
didrocks | ah, it seems that After= + Conflicts= on emergency.target would help | 08:47 |
rbalint | didrocks, yes | 08:49 |
didrocks | rbalint: ok, doing this and giving it some trials then. Thanks for confirming | 08:49 |
rbalint | didrocks, but would not WantedBy= be enough instead of Conflicts=? | 08:52 |
* rbalint reading backlog | 08:54 | |
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) | 08:57 |
rbalint | ah, ok, btw why don't you want it in emergency.target? | 09:13 |
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:14 |
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:37 |
didrocks | if you start the system explicitely with emergency | 09:38 |
rbalint | didrocks, no, emergency.target is special and will not run services | 09:39 |
didrocks | rbalint: ok, worth a try then, thanks for the feedback :) | 09:40 |
Laney | what about rescue.target? | 09:40 |
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:42 |
rbalint | Laney, the zsys service would not be run by default in rescue.target because it is a generic service | 09:45 |
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:49 |
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:50 |
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:51 |
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:52 |
Laney | looks like we always pull graphical.target | 09:55 |
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:56 |
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 | 09:57 |
ogra | oSoMoN, do you have nscd or unscd installed on the machine you are testing the chromium snap ? | 14:17 |
robert_ancell | kenvandine, do you know who would be able to respond to https://github.com/ubuntu/yaru/issues/1433 ? | 15:21 |
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:23 |
oSoMoN | I wonder what differs between our setups | 15:24 |
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:25 |
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 | 15:33 |
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:22 |
ogra | (or are accidentually running in --devmode or some such ....) | 16:24 |
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:26 |
oSoMoN | too many VMs running at once… | 16:27 |
ogra | heh | 16:27 |
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:28 |
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:29 |
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 | 16:30 |
=== pstolowski is now known as pstolowski|afk | ||
robert_ancell | willcooke, can you open a new team update thread? | 17:44 |
willcooke | robert_ancell, on it | 17:45 |
willcooke | robert_ancell, https://discourse.ubuntu.com/t/desktop-team-update-monday-5th-august-2019/12059 | 17:47 |
robert_ancell | willcooke, argh, now I've forgotten the thing I had done I was going to note... | 18:03 |
willcooke | :)) | 18:04 |
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) | 18:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!