[09:55] <xypron> I am looking for a sponsor for LP #1968174
[10:15] <seb128> xypron, uploaded
[12:04] <ahasenack> morning
[12:05] <lxsameer> hey folks, what tool do you use to build the official ubuntu live images?
[12:05] <lxsameer> live-build?
[12:12] <ahasenack> can anybody spot the error here? I can't: https://pastebin.ubuntu.com/p/3VfXVG7zH5/
[12:12] <ahasenack> golang is so fast that even the error messages don't have time to appear?
[12:13] <ogra> lxsameer, try https://git.launchpad.net/livecd-rootfs/tree/ ...
[12:13] <ogra> (that wraps combination of live-build and ubuntu-image to build the images)
[12:14] <ogra> +a
[12:14] <lxsameer> thank you
[12:41] <ahasenack> sarnold: I heard you have the whole archive locally, would it be easy for you to do a grep in debian/tests/* for all packages? ;)
[12:41] <ahasenack> I guess you have the debs, not the extracted sources
[12:43] <ahasenack> oh, this worked: https://codesearch.debian.net/search?q=ldap%5Ba-z%5D%2B+.*-h+path%3Adebian%2Ftests&literal=0
[12:48] <rbasak> u-d-a@ moderation please
[12:49] <cjwatson> rbasak: .
[12:50] <rbasak> Thanks!
[13:11] <xypron> I am looking for a sponsor for LP #1907878
[13:14] <seb128> xypron, are you sure the change is right? what users wrote indicate that the return also needs to be changed to an exit? also I'm not familiar with the package but if those lines are there it's probably for a reason, did we figure out what they were meant to do to decide they are safe to remove?
[13:15] <seb128> schopin, hey, can I bother you with an openssl problem?
[13:26] <enr0n> ahasenack: I have seen that issue with that golang package before on ppc64el. It appeared to be a memory-constraint issue, and we resolved it by adding the package to big_packages on ppc64el. Where are you seeing it?
[13:26] <ahasenack> enr0n: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libzstd on s390x
[13:28] <enr0n> ahasenack: Yeah, maybe it needs to be added to big_packages for s390x as well then.
[13:39] <xypron> seb128: the deleted lines contain variable names. These were never exectued. But unless you use 'set -e' the lines were simply ignored.
[13:41] <xypron> seb128: on a system using ifupdown and NetworkManager I have tested with eth1, eth1.90, eth1:1 and found no issues.
[13:41] <xypron> seb128: the change only removes the lines that were not executed and does not change the logic of the scripts.
[13:44] <seb128> xypron, k
[14:06] <seb128> xypron, sponsored
[14:07] <xypron> seb128: thanks
[14:20] <bdmurray> enr0n, ahasenack: I'll add golang-github-valyala-gozstd to big_packages for s390x and rerun the test
[14:25] <ahasenack> thanks bdmurray
[14:26] <enr0n> bdmurray: thanks!
[14:39] <lxsameer> have you folks, ever created an ubuntu image only via live-build?
[14:44] <ahasenack> schopin: hi, what do you know about RC4 being disabled in openssl3?
[14:44] <ahasenack> I'm troubleshooting a crash in cyrus-sasl, and so far it looks like it's trying to use RC4 via openssl
[14:45] <ahasenack> in jammy and kinetic, this command shows an error trying to use rc4: echo -ne "test" | openssl rc4 -k test
[14:45] <ahasenack> in impish (openssl 1) it issues just the warning, but seems to work otherwise
[14:48] <jawn-smith> lxsameer: some of our images are created using only live-build commands, such as the unmatched images
[14:49] <lxsameer> jawn-smith: good one, but since live-build is in the ubuntu's repo i thought you support it
[14:52] <ahasenack> ok, found three upstream issues, lots of changes ://
[14:53] <jawn-smith> lxsameer: our different images are built with many different tools, which is actually something we're actively working to unify. In the future ubuntu-image will be the tool to build all images, but for now there are many different tools
[14:54] <jawn-smith> The HiFive Unmatched images are currently built with live-build, and there may be some others.
[14:58] <lxsameer> jawn-smith: is it part of the official ubuntu repo?
[14:58] <jawn-smith> live-build? Yes live-build is in main
[15:00] <lxsameer>  jawn-smith sorry i meant the live-build config, where can i find the live-build config for the unmatched image?
[15:19] <seb128> slyon, hey, systemd sort of question for you, https://launchpadlibrarian.net/601716367/buildlog_ubuntu-kinetic-amd64.network-manager_1.38.0-1ubuntu1_BUILDING.txt.gz is failing to build on kinetic
[15:20] <seb128> compared to the 1.36 previous build we had in J, systemd isn't getting installed, probably because it's part of the base image?
[15:20] <seb128> I didn't debug the test issue yet but it seems that is probably due to a missing /etc/machine-id
[15:21] <seb128> also the old log which installed systemd had
[15:21] <seb128> > Initializing machine ID from random generator.
[15:22] <seb128> which I guess might be missing in the case of the systemd as part of the preinstall env?
[15:22] <jawn-smith> lxsameer: ah I see. The Unmatched images are built with the config/build scripts here: https://git.launchpad.net/livecd-rootfs/tree/live-build/auto
[15:22] <seb128> cjwatson, ^ or is that a launchpad build issue?
[15:22] <jawn-smith> It keys off of the SUBARCH environment variable with a value of "sifive_hifive_unmatched_fu740"
[15:22] <slyon> seb128: interesting. I'm sure why systemd shouldn't be installed..
[15:22] <slyon> *not sure
[15:23] <jawn-smith> This is a really outdated/ugly build system that we're working to replace, just FYI lxsameer
[15:23] <seb128> slyon, it's in the build-depends so my guess is that it is preinstall on whatever image the builders are loading
[15:23] <seb128> preinstalled
[15:24] <cjwatson> seb128: if there's a discrepancy in the base chroot, then that would be something for CPC - we just pull in what they build
[15:24] <cjwatson> (albeit irregularly)
[15:24] <seb128> cjwatson, are the buildds starting a container? like would that be a normal system start which should generate a machine-id ?
[15:24] <cjwatson> seb128: chroot, not container
[15:25] <cjwatson> we might switch to a container at some point, but that would be quite a big change and there hasn't been a pressing need for it
[15:25] <seb128> cjwatson, is there anywhere I can see the CPC provided chroot content?
[15:25] <slyon> oh ok. it's pre-installed. But we didn't change anything wrt. machine-id recently, so I wonder how this might have changed now. might be related to the pre-installed image
[15:25] <cjwatson> seb128: https://api.launchpad.net/devel/ubuntu/kinetic/amd64 has a link to it
[15:25] <seb128> cjwatson, thanks
[15:26] <seb128> slyon, well, the 22.04 build log shows systemd installed as part of the build-depends install, and the machine-id is generated at this time
[15:26] <seb128> so at least that part changed
[15:26] <seb128> having it preinstall it seems nothing in the chroot setup is creating a machine-id
[15:26] <cjwatson> I don't believe it's intentional for systemd to be in the chroot; there may have been a dependency change that caused that
[15:27] <seb128> ack, I will check with cpc
[15:27] <cjwatson> it's the buildd subproject in livecd-rootfs
[15:27] <slyon> ack
[15:27] <seb128> cjwatson, side bug, that url has a chroot_url in http instead of https which firefox refuses to open, I will report a launchpad bug about it ;)
[15:27] <cjwatson> hm we do install "init" for historical reasons, maybe I'm misremembering
[15:27] <cjwatson> seb128: not a bug, api isn't typically expected to be used by browsers
[15:28] <seb128> ah, ok
[15:28] <cjwatson> we might change it for general politeness reasons
[15:29] <cjwatson> you can also use manage-chroot in ubuntu-archive-tools to grab it
[15:29] <seb128> thx
[15:29] <seb128> slyon, so that chroot archive has a 0 byte /etc/machine-id
[15:32] <seb128> which was the case in older series also, and systemd was also installed in the chroot
[15:32] <cjwatson> It might just be that buildd had to upgrade systemd from what the older chroot had
[15:32] <seb128> right, that's what I was just thinking
[15:33] <seb128> so maybe it is a regression in n-m tests not handling fine the 0 byte /etc/machine-id
[15:33] <cjwatson> I suppose we could have buildd generate a machine-id and poke it in for chroot-based builds, though that doesn't answer why this wasn't needed before
[15:33] <slyon> so just coincidence that we had to upgrade systemd in JJ chroots? and something might have changed/broken that a while back?
[15:34] <seb128> which is boggus but doesn't seem a new issue
[15:35] <slyon> according to man machine-id(5): "If /etc/machine-id exists and is empty, a boot is not considered the first boot.  systemd will still bind-mount a file containing the actual machine-id over it and later try to commit it to disk (if /etc/is writable)."
[15:35] <slyon> that bind-mount doesn't seem to happen here neither. Do you know if /etc/ is writable inside the chroot?
[15:39] <cjwatson> I would be astonished if /etc weren't writable, but systemd won't be running in the chroot
[15:40] <cjwatson> Because it's a chroot, not a container
[15:40] <seb128> well, I guess it's not a new condition but just confuse n-m now
[15:40] <seb128> cjwatson, slyon, thanks for the replies!
[15:41] <seb128> I will dig a bit more into n-m changes after diner if gitlab is responding again
[16:08] <enr0n_> I am looking for someone to review/sponsor LP #1973377
[16:34] <teward> !no dmb-ping is <reply>rbasak, sil2100, teward, bdmurray, kanashiro, seb128: DMB ping
[16:34] <teward> sorry for the ping everyone
[17:12] <xypron> I am looking for a sponsor for LP #1973788
[17:55] <sarnold> ahasenack: I've got some scripts that can unpack either the sources or binaries and run things over the results; I've also got the sources unpacked, but funny enough, searching through *all* of those is way slower than the scripts because those unpack only what's reachable via the lists, but I don't yet have a way to clean up no-longer-needed sources
[17:56] <ahasenack> ok
[19:18] <GunnarHj> Hi bdmurray, gnome-settings-daemon 42.1-1ubuntu2.1 was moved to jammy-updates about 10 hours ago, but I still don't see it available in jammy via "apt update". (I'm using the main server, so I assume it's not about propagation.) Known issue, or "just me"?
[19:21] <jbicha> I noticed that https://people.canonical.com/~ubuntu-archive/phased-updates.html was empty for jammy today but several things were promoted to jammy-updates early today
[19:26] <GunnarHj> jbicha: Yeah, I too got *some* updates, but not the one I mentioned.
[20:03] <bdmurray> GunnarHj, jbicha: You can see the phased-update-percentage by looking up one of the binaries in LP. It's currently at 20%.
[20:03] <bdmurray> https://launchpad.net/ubuntu/jammy/amd64/gnome-settings-daemon/42.1-1ubuntu2.1
[20:06] <jbicha> the phased updates page is working for me now
[20:06] <bdmurray> Or you can just look at the Packages file http://archive.ubuntu.com/ubuntu/dists/jammy-updates/main/binary-amd64/Packages.gz
[20:08] <GunnarHj> Thanks, bdmurray, I take it that you say that this delay is normal. All is well then.