=== Serge is now known as hallyn [01:54] doko: I think python3.10 has an issue since the last upload to lunar-proposed [01:54] File "/usr/lib/python3.10/_sysconfigdata__x86_64-linux-gnu.py", line 45 [01:55] https://launchpadlibrarian.net/653067200/buildlog_ubuntu-lunar-amd64.python-swiftclient_1%3A4.2.0-0ubuntu1_BUILDING.txt.gz [08:01] Hi, a general question about triggers. deb-triggers man says that 'activate' declared in "package".triggers will fire the trigger at the start of the operation, e.g. configure. Is there any way to activate trigger after operation finishes without resorting to dpkg-trigger ? [09:52] coreycb: why do you need 3.10? anyway, I'll fix that [12:50] doko: thanks. I'm not really sure why but it looks like there are some hard reverse-depends on python 3.10. maybe they just need rebuilds. [13:35] coreycb: yes, a lot of Python packages need to be rebuilt: https://people.canonical.com/~ubuntu-archive/transitions/html/python3.11-only.html [13:42] jbicha: ok thanks [15:35] arraybolt3: :wave: saw your post on the mailing list, I think you'll like what I've been working on. I have some stuff to do first this morning but I'll do an email response, and we can also chat more if you like. [16:51] bdrung: I wonder why naming it tzdata-right instead of tzdata-legacy-do-not-install ;) [16:56] vorlon, because it's the right name to use. ;) Yokes aside, it reflects the name of the directory. Hopefully "You do not need this package if you are unsure." in the description is enough. [16:57] vorlon, I noticed that there are one or two packages that uses the UTC file from there to determine the amount of leap seconds === Eickmeyer is now known as NoLongerEickmeye === NoLongerEickmeye is now known as NotEickmeyer [18:12] bdrung: yeah but as a namespace thing, "right" implies "proper", like the thing you want to use [18:45] vorlon, do you have a better name? [18:48] bdrung: tzdata-legacy? [18:48] then, if there's more stuff that becomes legacy later, you can shunt that over to the same binary package too [19:11] vorlon: Hi! Now that livecd-rootfs has migrated, is there anything more that needs to be done for edubuntu? [19:12] Eickmeyer: well I suppose I should kick off another test build! [19:13] vorlon: hehe alright :) [19:14] oh, not sure I actually *did* a test build of edubuntu yet - I had only done xubuntu-minimal [19:14] Yeah, I was a little unsure of your use of "another" there, but I wasn't going to look a gift horse in the mouth. :) [19:14] so, kicking off builds for both [19:17] Eickmeyer: well that failed quickly [19:17] oof [19:18] https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/lunar/edubuntu/+build/417345 [19:19] that seems to be giving decidedly little information [19:19] Yeah, I'm not sure how to fix that. [19:19] um reproduce it locally and add print debugging statements :P [19:21] Ok, not sure how to *do* that. :P [19:26] Eickmeyer: the logic showing how the livefs builds are dispatches is in lp:launchpad-buildd. There's a lot of indirections but at the end of the day it's invoking /usr/share/livecd-rootfs/live-build/auto/config, /usr/share/livecd-rootfs/live-build/auto/build via lpbuildd/target/build_livefs.py [19:26] so! the xubuntu-minimal image ftbfs the same way [19:26] looks like livecd-rootfs breakage [19:26] Ok, so we're not alone here. [19:31] although, lubuntu successfully built 3 hours ago [19:32] *confusion intensifies* [19:32] There's another livecd-rootfs in proposed too. [19:34] I bet edubuntu-live isn't in the Tasks: field in the archive [19:34] correct it is not [19:35] Let me see what I can do about that. [19:35] it's an AA problem [19:36] Oh, ok. [19:36] Thought it was a seed problem. [19:39] this would all go away if I took mwhudson's branch, wouldn't it [19:39] bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-publishing/trunk/.bzr/branch-format [19:41] which means in fact that ubuntu-unity is not getting task fields either, is it [19:42] Yiiiiiikes [19:42] cjwatson: ^^ halp [19:43] hmm this is probably a proxy error or something [19:46] yeah I was able to work around it by unsetting http_proxy from the env :/ [19:46] not sure if this branch is supposed to be auto-pulled tho; if so it was 5 months out of date [19:47] anyway, code deployed now so the next publisher run should have the Task fields and we can try again Eickmeyer [19:47] vorlon: Ok, sounds good. [19:52] juliank: uh does this mean that we're getting wrong unsatisfied Recommends: of core packages because of debootstrap misbehavior? Calculating upgrade... ignore old unsatisfied important dependency on libgpg-error-l10n:amd64 [19:53] perhaps that gets fixed up later in the build [20:00] vorlon: only new recommends are installed if foo is installed and has recommends bar but bar is not installed, upgrading foo does not install bar [20:01] I don't know what debootstrap does [20:01] switch image building to mmdebstrap and rejoice in full apt solver [20:01] :D [20:01] juliank: well, debootstrap evidently is not following recommends, judging by the livefs build logs [20:02] One could apt install --fix-policy later [20:02] juliank: but also they're probably all pulled in later via the tasks anyway [20:03] Yes germinate follows recommends and makes the choices for you [20:03] dbungert: Thanks! sil2100 gave me a sneak preview. I'll look at it later today hopefully. I might not have a lot of time today, but Sunday and Monday I'll probably have more. [20:03] juliank: oho, except I just checked lubuntu daily-live and libgpg-error0-l10n is indeed missing [20:04] juliank: so apt-get install --fix-policy? (since we're not supposed to use apt in scripts ;) [20:05] jawn-smith: ^^ does ubuntu-image have this bug? [20:08] vorlon: should be fine after debootstrap to fix this [20:09] But maybe fixing debootstrap is the better choice? [20:12] fair point [20:35] I: Retrieving libgpg-error-l10n 1.46-1 [20:35] looking good [20:41] ginggs, doko: python3.10-dev is broken on armhf: https://paste.ubuntu.com/p/dXTg8KnXvH/ [20:48] vorlon: sorry just saw this [20:48] reading [20:50] I don't think so. IIUC juliank is saying that germinate doesn't have this bug because it follows recommends. Since we're calling germinate directly to get a list of packages this shouldn't be an issue [20:52] You U C [20:52] thanks julian [21:52] jawn-smith: so you don't invoke debootstrap at all for the initial unpack but have your own implementation? [21:56] vorlon: we invoke debootstrap and then use germinate to get a list of packages to add to the chroot [21:57] jawn-smith: ah. if you are passing a list of packages from germinate to apt, do you then do some kind of handling afterwards to make sure the appropriate packages are marked auto-installed? [21:57] nothing that i'm aware of [21:57] (so that if they are dropped as depends of the metapackage later they get autoremoved) [21:57] ok that's not ideal either then [22:07] juliank: well this is fascinating, a naive implementation of Recommends support in debootstrap fails with python3-minimal not being installed before python3 [22:08] rather, python3.11-minimal not being installed before python3-minimal [22:08] ah perhaps I bunged the pre-depends handling in the process, let's see [22:09] ah only indirectly [22:10] also for a package implemented in perl, debootstrap has really awful regexps everywhere [22:16] juliank: yeah so debootstrap has fundamentally broken pre-depends handling (i.e. it does not handle it at all at the unpack stage) so including recommends is sufficient to change unpack ordering and break debootstrap completely lololol [22:18] *otoh* python3-minimal pre-depends on python3.11-minimal is wrong, because python3-minimal contains no preinst so why is this even here! [22:19] ahahahaha https://bugs.debian.org/901001 who filed that [22:19] -ubottu:#ubuntu-devel- Debian bug 901001 in python3-minimal "python3-minimal should Pre-Depend on python3.N-minimal" [Serious, Open] [22:19] ok so the rationale there is unfortunately sane [22:33] juliank: well I don't want to touch this code anymore, so it may be an apt-get install --fix-policy postprocess in livecd-rootfs after all :P [22:42] sort [23:46] FWIW: Chrome has a corruption bug with Intel graphics we have seen on lots of devices. The fix is to use chome:flags and turn on vulkan. This appears across many kernel flavors and desktops (Unity and KDE confirmed). [23:55] mmikowski: chrome, not chromium?