/srv/irclogs.ubuntu.com/2021/07/02/#ubuntu-devel.txt

=== Guest9658 is now known as blue_penquin[m]
iceylooking 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!07:10
laneyicey: 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
iceythanks laney!08:09
laneyfor example the oldest one says:08:10
laneyskipped: 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-dev08:10
laneyso you'd look into why librust-grcov-dev isn't installable on riscv64 and try to fix that if posisble08:10
iceyah, cool! thanks for more new links to follow :)08:12
laneyhave fun :-)08:14
iceyok - 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 depend08:23
iceyon libgweather (or gnome-weather) are currently blocking it?08:23
iceysuch as: gnome migrating from 3.38 to 40.208:23
laneyicey: 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 transition08:28
laneyeventually you can work out it's because gnome-shell is missing, and that's being worked on by Trevinh_o currently08:28
laneysorry for the "weird 'quoting'" there08:29
iceyheh no worries08:29
iceylooking 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 list08:31
slyonsil2100: 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/460208:41
laneyyeah the rest of it is stuff that depends on gnome-shell08:54
laneywell, didn't check it all08:54
laneyat least most of the rest08:54
sil2100slyon: 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 queue09:11
sil2100Which might either mean some credentials being busted09:11
slyonok, thanks!09:11
sil2100But I can't debug this myself as only IS has access to Bileto09:11
sil2100I'll continue poking them about it!09:11
=== Guest2892 is now known as blue_penquin[m]
slyonrbasak: 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:50
slyonI'm currently trying to formalize the definition of "network-online" in a spec.11:51
=== apteryx_ is now known as apteryx
=== georgiag__ is now known as georgiag
rbasakslyon: I did not - I got trumped by a thread on ubuntu-devel@ instead12:55
rbasakslyon: 12 May12:56
slyonrbasak: ok. I'm aware of that ubuntu-devel@ thread12:56
slyonI was just wondering if there is anything to add from your side, so that I can have the full picture before writing it down12:57
rbasakslyon: from my research, it is effectively defined well in the specific cases of networkd and NetworkManager if you follow the systemd breadcrumbs.12:57
rbasakHowever that definition isn't perfect for our needs, I don't think12:57
slyonACK. there is "systemd-networkd-wait-online" and "nm-online" and I will consider their man-pages accordingly.12:59
slyonThanks!12:59
rbasakslyon: also note the arguments they're called with on a default Ubuntu12:59
rbasakIIRC, there are some12:59
slyonYeah, 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:01
slyonwhich makes sense in a desktop scenario where we do not want NM to wait for a wifi connection setup.13:04
rbasakOne 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:06
rbasakTherefore 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:07
rbasakSeparately, 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:08
rbasakAnother 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
rbasakStuff 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.13:09
slyonYes, 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:40
slyonI will consider your examples and possibly add them to the spec as well!14:41
=== genii-core is now known as genii

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!