=== Guest9658 is now known as blue_penquin[m]
[07:10] <icey> looking at update_excuses, I notice that there are a lot with "Will attempt migration (Any information below is purely informational) " - and some of those are 3+ weeks old. There doesn't really seem to be any action to take but I'd appreciate learning more!
[08:09] <laney> icey: see https://wiki.ubuntu.com/ProposedMigration#I_still_don.27t_understand.21__The_proposed-migration_scripts_say_that_this_package_is_a_valid_candidate.2C_but_it_still_hasn.27t_gone_into_the_release_pocket.
[08:09] <icey> thanks laney!
[08:10] <laney> for example the oldest one says:
[08:10] <laney> skipped: rust-grcov (0, 0, 11) got: 30+0: a-0:a-0:a-0:i-1:p-0:r-29:s-0 * riscv64: librust-grcov-dev
[08:10] <laney> so you'd look into why librust-grcov-dev isn't installable on riscv64 and try to fix that if posisble
[08:12] <icey> ah, cool! thanks for more new links to follow :)
[08:14] <laney> have fun :-)
[08:23] <icey> ok - since I'm probably misunderstanding something: gnome-weather (depends on libgweather) has something like "skipped: gnome-weather (0, 90, 41) got: 31+0: a-2:a-0:a-0:i-1:p-0:r-28:s-0", but it and libgweather seem to build fine on amd64 (https://launchpad.net/ubuntu/+source/gnome-weather/40.0-1) and I've just installed them in an AMD64 impish container (from proposed) just fine - I'm guessing that the failure to migrate is that other things that depend
[08:23] <icey> on libgweather (or gnome-weather) are currently blocking it?
[08:23] <icey> such as: gnome migrating from 3.38 to 40.2
[08:28] <laney> icey: further on down in update-output.txt there's an attempt where gnome-weather is tried with lots of other packages ("search for 'gnome-weather/'") that must go together with it because of a library transition
[08:28] <laney> eventually you can work out it's because gnome-shell is missing, and that's being worked on by Trevinh_o currently
[08:29] <laney> sorry for the "weird 'quoting'" there
[08:29] <icey> heh no worries
[08:31] <icey> looking at the 2 (?) sections with 'gnome-weather/' in them, I do see gnome-shell, but it seems like it's just another thing in a list
[08:41] <slyon> sil2100: have you already been able to have a look at the missing bileto test results? I see the same issue here: https://bileto.ubuntu.com/#/ticket/4602
[08:54] <laney> yeah the rest of it is stuff that depends on gnome-shell
[08:54] <laney> well, didn't check it all
[08:54] <laney> at least most of the rest
[09:11] <sil2100> slyon: hey! Yes, I have filled in an RT in the morning to investigate that with IS - looks like there are some issues with connecting to the AMQP queue
[09:11] <sil2100> Which might either mean some credentials being busted
[09:11] <slyon> ok, thanks!
[09:11] <sil2100> But I can't debug this myself as only IS has access to Bileto
[09:11] <sil2100> I'll continue poking them about it!
=== Guest2892 is now known as blue_penquin[m]
[11:50] <slyon> rbasak: Hey! In May you mentioned a draft regarding "network-online.target" which you prepared to send to debian-devel@ ... Did that email/draft already go out? I cannot find it... Could you share the email (or draft) with me?
[11:51] <slyon> I'm currently trying to formalize the definition of "network-online" in a spec.
=== apteryx_ is now known as apteryx
=== georgiag__ is now known as georgiag
[12:55] <rbasak> slyon: I did not - I got trumped by a thread on ubuntu-devel@ instead
[12:56] <rbasak> slyon: 12 May
[12:56] <slyon> rbasak: ok. I'm aware of that ubuntu-devel@ thread
[12:57] <slyon> I was just wondering if there is anything to add from your side, so that I can have the full picture before writing it down
[12:57] <rbasak> slyon: from my research, it is effectively defined well in the specific cases of networkd and NetworkManager if you follow the systemd breadcrumbs.
[12:57] <rbasak> However that definition isn't perfect for our needs, I don't think
[12:59] <slyon> ACK. there is "systemd-networkd-wait-online" and "nm-online" and I will consider their man-pages accordingly.
[12:59] <slyon> Thanks!
[12:59] <rbasak> slyon: also note the arguments they're called with on a default Ubuntu
[12:59] <rbasak> IIRC, there are some
[13:01] <slyon> Yeah, we're using the defaults for "systemd-networkd-wait-online" (at least on my running system). But we do "nm-online -s", which means: do not wait on any connection, but only for the NetworkManager daemon to be started.
[13:04] <slyon> which makes sense in a desktop scenario where we do not want NM to wait for a wifi connection setup.
[13:06] <rbasak> One issue arises when some packages might be configured to provide some network functionality. For example named serving DNS authoritatively bound to particular interfaces might need to wait until the "network is up". But for named configured as a local recursive resolver, it's the opposite.
[13:07] <rbasak> Therefore I don't like bug reports telling us that they configured their daemon in a particular way, it didn't work, and therefore our packaged systemd dependency tree is wrong and should be changed. Because I feel that only considers a narrow use case.
[13:08] <rbasak> Separately, I expect that there will always be cases where if you configure one thing in one place, you're expected/required to configure another thing in another to match (in this case the systemd service unit's dependencies).
[13:09] <rbasak> Another example of this general principle is if a user configures a daemon to use a path outside its default confined AppArmor profile. Then in addition to the configuration change to the daemon, the AppArmor profile also needs adjusting.
[13:09] <rbasak> Stuff like "I configured sshd to bind on an interface but it fails to start because you're not waiting on network-online.target". But there's another user who expects "ssh localhost" to work early.
[14:40] <slyon> Yes, I expect that there will be edge cases as well. But as discussed at ubuntu-devel@ I think those should probably be rejected as non-default and the admin is asked to manually adopt the configuration (in all relevant places).
[14:41] <slyon> I will consider your examples and possibly add them to the spec as well!
=== genii-core is now known as genii