[07:43] mwhudson, did you see your changes there failed to build https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.8.8 ? [10:27] seb128: oh whoops no i did not see that [10:28] oh lala i removed alsa-utils from build-depends not depends === didrocks999 is now known as didrocks [14:03] LP: #1922735 [14:03] Launchpad bug 1922735 in grub2 (Ubuntu) "Incorrect grub menu appears in live session" [Undecided,Confirmed] https://launchpad.net/bugs/1922735 [14:04] xnox: ^^ that was a deliberate change removing syslinux/gfxboot theme was it not [14:04] ? [14:32] still looking for sponsorship for bug 1916250 [14:32] bug 1916250 in libsignon-glib (Ubuntu) "gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute)" [Low,New] https://launchpad.net/bugs/1916250 [14:50] xnox: thanks for the bug comment. I guessed a won't fix would be the result [15:15] waveform: sil2100 raises a good question in bug 1920837 re non-Rasperry Pi hardware. Is there a way we could check to see if the hardware is really raspberry? [15:15] bug 1920837 in apport (Ubuntu Groovy) "apport bugs from official raspi or riscv images are not identified" [Undecided,In progress] https://launchpad.net/bugs/1920837 [15:29] didrocks: hey, do you know the best person to ask about a zfs-linux issue? we looked into https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1922293/comments/14 and it seems to be either a zfs-linux issue or a systemd bug [15:29] Launchpad bug 1922293 in snapd (Ubuntu) "Snaps appear broken on 21.04 Beta with ZFS" [High,Confirmed] [15:35] mvo: hey! There are 2 things here: [15:35] - the zfs generator is currently broken in the default setup due to OpenZFS 2.0 default layout. ubiquity in unapproved since this morning is fixing this [15:35] (people using our default setup will not be impacted by the bug then) [15:35] - then, for people using ZFS themselves (no ZSys/not our default setup with a generator), indeed, all the .mount units needs to specify After=zfs-mount.service as [15:35] Pawel suggested [15:36] (as the mount points are only available once zfs-mount.service has run) [15:36] bdmurray, thanks for the heads-up - will post an update on that bug [15:36] mvo: I guess cking (who is our ZFS maintainer) can have a second eye on this, but the truth shouldn’t be far from that :) [16:04] didrocks: cool, thanks. so your recommendation is that we implement the workaround? [16:05] didrocks: for those who use non-defaults? [16:06] mvo: correct, for everyone using non default having a dataset as a parent directory where you mount the snaps (for the .mount files) [16:52] tjaalton: can you try https://launchpad.net/~rikmills/+archive/ubuntu/mesa to see if you get the crash? [16:52] just commented on the bug [16:54] that build of 20.3.4 against recent toolchain does fixes crashes for me [16:58] tjaalton: that is exactly this, but with a bumped version to make installing to test easier: https://launchpad.net/ubuntu/+source/mesa/20.3.4-1 [16:59] rbalint: cjwatson: "Convert all packages using -Zlzma to use -Zxz instead: TODO" => i think we never bothered to actually rebuild things with xz and add Pre-Depends. Instead we waited an lts cycles and then started to use xz by default without any predepends. [17:01] xnox: Yeah, I think that's likely correct outside of a few special cases [17:02] xnox: Note that only a few packages had -Zlzma in the first place [17:02] check was added in maverick cycle; then precise got released; and then launchpad dropped the pre-depends check. Such that things in precise already were ok to build and upload without pre-depends. [17:02] by same logic, we have enough lts cycles to do zstd without predepends. [17:02] and without launchpad upload predepends check. === ijohnson is now known as ijohnson|lunch [17:03] There were at least some Pre-Depends [17:03] cloop-utils is the first one I see in precise's main/binary-amd64/Packages [17:04] That has Pre-Depends: dpkg (>= 1.15.6~) and data.tar.xz [17:04] And the Pre-Depends was added manually there [17:04] https://launchpad.net/ubuntu/+source/cloop/2.6.39.2-1ubuntu1 [17:05] i think if we add zstd support to xenial, things are nice. cause then any up to date release can jump to zstd using debs. [17:05] issue there was that lucid didn't, and we had to support lucid -> precise upgrade. [17:07] hm [17:07] to be explicit with debian; kind of makes sense to make our dpkg have Provides: dpkg-zstd => and then have Pre-Depends: dpkg-zstd everywhere. [17:07] such that it is not satisfied on debian. [17:08] (or any other distro that didn't take zstd support into dpkg yet) [17:08] rbalint: thoughts? ^ [17:09] RikMills: that one works [17:09] which is weird [17:09] but means I don't know how to bisect this easily [17:11] tjaalton: I tried to bisect and the odd branching mesa have done made me give up as I was not sure I was getting a true intermediate state [17:13] xnox, Provides: and Pre-Depends: would definitely work, but installation will also fail if someone tries installing the .deb [17:14] xnox, and those are not exactly nice :-) [17:14] xnox, let me sleep on that [17:14] RikMills: there shouldn't be anything odd, there's a tag for the branchpoint where 20.3.0~ started and master moved on to become 21.0 [17:15] rbalint: we should publish dpkg as a snap, to allow people snap install dpkg and then set apt config option to use /snap/bin/dpkg ? [17:15] rbalint: or we should at least ensure that debootstrap has zstd support, or keep our debootstrap set compressed with xz => to allow debootstrapping ubuntu from debian? [17:15] xnox, i meant a nice sleep, not a nightmare :D [17:17] xnox: the inability to debootstrap Ubuntu from Debian is going to *suck* [17:17] xnox: unless that can be worked around in debootstrap somehow ... [17:17] tjaalton: was the bisect build you did with all the patches and config from our packaging, or something more vanilla? [17:17] xnox, cjwatson it can be worked around by recompressing the packages ... [17:18] cjwatson: i thought debootstrap in the past had support for "unpack things by hand without dpkg support for compression $foo" [17:18] That's not a serious workaround, surely [17:18] if like xz-utils is available, etc. [17:18] Oh, if you mean automatically [17:18] I don't quite remember [17:18] RikMills: I built 20.3.4 too, disabled some drivers that aren't useful for swrast build, used LIBGL_DRIVERS_PATH and pointed it to the build dir [17:19] It's only needed for the initial extraction [17:19] I do think the use case of "create sbuild chroot on Debian box" is at least handy if not essential [17:19] cjwatson: rbalint: i think we must add zst support to debootstrap. [17:19] i see code for it to do extract ar_deb_data using like zcat bzcat xzcat cat etc. [17:20] OK, so that's hopefully not too difficult [17:20] Just another line in that case [17:20] RikMills: I'll bisect with packages next, meh.. [17:20] but it defaults to dpkg-deb extractor *har har har* [17:20] instead of an ar one. [17:20] xnox, i've added debootstrap to the checklist [17:21] rbalint: tah. [17:21] tjaalton: yeah, I started to do that and realised it would be extra long and tedious! [17:21] i think EXTRACTOR_OVERRIDE=ar debootstrap => should be easy enough to make work. [17:22] tjaalton: thanks you for the help and effort. it is appreciated :) [17:22] or at least make deb_data one from dpkg-deb fallback to ar one. [17:22] rbalint: we are doing both control.zst & data.zst or data only? [17:22] EXTRACTOR_OVERRIDE is meant as an implementation detail of --extractor=ar I think [17:22] control.tar.zst surely isn't worth the effort [17:23] i see that it is asymetrical as to what is supported for control & data. [17:23] xnox, i planned going for data for now [17:23] RikMills: I don't have a choice :) [17:23] ok. [17:23] tjaalton: that doesn't make me less appreciative [17:24] xnox, cjwatson in a few lts cycles we could also switch control.zst for a bit of extra speed [17:25] RikMills: I'm on a temp git branch and have a copied debian/ dir on it, so it doesn't conflict with the moving head too much, not the first time [17:32] tjaalton: the only change that strikes me in packaging is going from confflags_OSMESA = -Dosmesa=gallium to confflags_OSMESA = -Dosmesa=true [17:33] was that a fix that would have been valid for 20.3.4? or a change required by 21.0.x changes? [17:34] plus the relate bug change of this makes me suspicious: https://gitlab.freedesktop.org/mesa/mesa/-/commit/ee802372180a2b4460cc7abb53438e45c6b6f1e4 [17:35] bug change? I man big change [17:35] *mean [17:36] god, my typing is horrid sometimes [17:41] that osmesa thing was because before there were two versions, classic and gallium. now it's just gallium so the option got changed [17:43] got it [17:45] ddstreet, xnox systemd 248 has been released too late for Hirsute but i've collected a round of fixes on top of 247.3-3ubuntu2 in git [17:46] ddstreet, xnox if you would like to add something i plan a new upload at night tommorrow (~6PM CET) [17:57] RikMills: run 'glxinfo -B', what do you have as the device when it crashes? [18:02] tjaalton: in a VM https://i.imgur.com/yHqRbue.png [18:03] hmm ok [18:46] RikMills: try disabling d3d12 from debian/rules [18:57] because I had to disable it when starting the bisect, and it was off until getting close to 21.0.0 and things still worked [18:57] so I guess that broke it somehow [18:59] huh, no [19:13] RikMills: I need to EOD, will continue tomorrow === ijohnson|lunch is now known as ijohnson [22:16] something very strange is going on here https://launchpad.net/~mwhudson/+livefs/ubuntu/hirsute/test/+build/269397 [22:16] why is needrestart doing things after each package? [22:17] oh wait, this is my code i think [22:17] yes