[07:43] <seb128> mwhudson, did you see your changes there failed to build https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.8.8 ?
[10:27] <mwhudson> seb128: oh whoops no i did not see that
[10:28] <mwhudson> oh lala i removed alsa-utils from build-depends not depends
[14:03] <RikMills> LP: #1922735
[14:04] <RikMills> xnox: ^^ that was a deliberate change removing syslinux/gfxboot theme was it not
[14:04] <RikMills> ?
[14:32] <Laibsch> still looking for sponsorship for bug 1916250
[14:50] <RikMills> xnox: thanks for the bug comment. I guessed a won't fix would be the result
[15:15] <bdmurray> 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:29] <mvo> 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:35] <didrocks> mvo: hey! There are 2 things here:
[15:35] <didrocks> - 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] <didrocks> (people using our default setup will not be impacted by the bug then)
[15:35] <didrocks> - 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] <didrocks> Pawel suggested
[15:36] <didrocks> (as the mount points are only available once zfs-mount.service has run)
[15:36] <waveform> bdmurray, thanks for the heads-up - will post an update on that bug
[15:36] <didrocks> 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] <mvo> didrocks: cool, thanks. so your recommendation is that we implement the workaround?
[16:05] <mvo> didrocks: for those who use non-defaults?
[16:06] <didrocks> 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] <RikMills> tjaalton: can you try https://launchpad.net/~rikmills/+archive/ubuntu/mesa to see if you get the crash?
[16:52] <RikMills> just commented on the bug
[16:54] <RikMills> that build of 20.3.4 against recent toolchain does fixes crashes for me
[16:58] <RikMills> 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] <xnox> 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] <cjwatson> xnox: Yeah, I think that's likely correct outside of a few special cases
[17:02] <cjwatson> xnox: Note that only a few packages had -Zlzma in the first place
[17:02] <xnox> 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] <xnox> by same logic, we have enough lts cycles to do zstd without predepends.
[17:02] <xnox> and without launchpad upload predepends check.
[17:03] <cjwatson> There were at least some Pre-Depends
[17:03] <cjwatson> cloop-utils is the first one I see in precise's main/binary-amd64/Packages
[17:04] <cjwatson> That has Pre-Depends: dpkg (>= 1.15.6~) and data.tar.xz
[17:04] <cjwatson> And the Pre-Depends was added manually there
[17:04] <cjwatson> https://launchpad.net/ubuntu/+source/cloop/2.6.39.2-1ubuntu1
[17:05] <xnox> 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] <xnox> issue there was that lucid didn't, and we had to support lucid -> precise upgrade.
[17:07] <xnox> hm
[17:07] <xnox> 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] <xnox> such that it is not satisfied on debian.
[17:08] <xnox> (or any other distro that didn't take zstd support into dpkg yet)
[17:08] <xnox> rbalint:  thoughts? ^
[17:09] <tjaalton> RikMills: that one works
[17:09] <tjaalton> which is weird
[17:09] <tjaalton> but means I don't know how to bisect this easily
[17:11] <RikMills> 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] <rbalint> xnox, Provides: and Pre-Depends: would definitely work, but installation will also fail if someone tries installing the .deb
[17:14] <rbalint> xnox, and those are not exactly nice :-)
[17:14] <rbalint> xnox, let me sleep on that
[17:14] <tjaalton> 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] <xnox> 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] <xnox> 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] <rbalint> xnox, i meant a nice sleep, not a nightmare :D
[17:17] <cjwatson> xnox: the inability to debootstrap Ubuntu from Debian is going to *suck*
[17:17] <cjwatson> xnox: unless that can be worked around in debootstrap somehow ...
[17:17] <RikMills> tjaalton: was the bisect build you did with all the patches and config from our packaging, or something more vanilla?
[17:17] <rbalint> xnox, cjwatson it can be worked around by recompressing the packages ...
[17:18] <xnox> cjwatson:  i thought debootstrap in the past had support for "unpack things by hand without dpkg support for compression $foo"
[17:18] <cjwatson> That's not a serious workaround, surely
[17:18] <xnox> if like xz-utils is available, etc.
[17:18] <cjwatson> Oh, if you mean automatically
[17:18] <cjwatson> I don't quite remember
[17:18] <tjaalton> 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] <cjwatson> It's only needed for the initial extraction
[17:19] <cjwatson> I do think the use case of "create sbuild chroot on Debian box" is at least handy if not essential
[17:19] <xnox> cjwatson:  rbalint: i think we must add zst support to debootstrap.
[17:19] <xnox> i see code for it to do extract ar_deb_data using like zcat bzcat xzcat cat etc.
[17:20] <cjwatson> OK, so that's hopefully not too difficult
[17:20] <cjwatson> Just another line in that case
[17:20] <tjaalton> RikMills: I'll bisect with packages next, meh..
[17:20] <xnox> but it defaults to dpkg-deb extractor *har har har*
[17:20] <xnox> instead of an ar one.
[17:20] <rbalint> xnox, i've added debootstrap to the checklist
[17:21] <xnox> rbalint:  tah.
[17:21] <RikMills> tjaalton: yeah, I started to do that and realised it would be extra long and tedious!
[17:21] <xnox> i think EXTRACTOR_OVERRIDE=ar debootstrap => should be easy enough to make work.
[17:22] <RikMills> tjaalton: thanks you for the help and effort. it is appreciated :)
[17:22] <xnox> or at least make deb_data one from dpkg-deb fallback to ar one.
[17:22] <xnox> rbalint:  we are doing both control.zst & data.zst or data only?
[17:22] <cjwatson> EXTRACTOR_OVERRIDE is meant as an implementation detail of --extractor=ar I think
[17:22] <cjwatson> control.tar.zst surely isn't worth the effort
[17:23] <xnox> i see that it is asymetrical as to what is supported for control & data.
[17:23] <rbalint> xnox, i planned going for data for now
[17:23] <tjaalton> RikMills: I don't have a choice :)
[17:23] <xnox> ok.
[17:23] <RikMills> tjaalton: that doesn't make me less appreciative
[17:24] <rbalint> xnox, cjwatson in a few lts cycles we could also switch control.zst for a bit of extra speed
[17:25] <tjaalton> 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] <RikMills> tjaalton: the only change that strikes me in packaging is going from confflags_OSMESA =  -Dosmesa=gallium to confflags_OSMESA =  -Dosmesa=true
[17:33] <RikMills> was that a fix that would have been valid for 20.3.4? or a change required by 21.0.x changes?
[17:34] <RikMills> plus the relate bug change of this makes me suspicious: https://gitlab.freedesktop.org/mesa/mesa/-/commit/ee802372180a2b4460cc7abb53438e45c6b6f1e4
[17:35] <RikMills> bug change? I man big change
[17:35] <RikMills> *mean
[17:36] <RikMills> god, my typing is horrid sometimes
[17:41] <tjaalton> 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] <RikMills> got it
[17:45] <rbalint> 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] <rbalint> ddstreet, xnox if you would like to add something i plan a new upload at night tommorrow (~6PM CET)
[17:57] <tjaalton> RikMills: run 'glxinfo -B', what do you have as the device when it crashes?
[18:02] <RikMills> tjaalton: in a VM https://i.imgur.com/yHqRbue.png
[18:03] <tjaalton> hmm ok
[18:46] <tjaalton> RikMills: try disabling d3d12 from debian/rules
[18:57] <tjaalton> 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] <tjaalton> so I guess that broke it somehow
[18:59] <tjaalton> huh, no
[19:13] <tjaalton> RikMills: I need to EOD, will continue tomorrow
[22:16] <mwhudson> something very strange is going on here https://launchpad.net/~mwhudson/+livefs/ubuntu/hirsute/test/+build/269397
[22:16] <mwhudson> why is needrestart doing things after each package?
[22:17] <mwhudson> oh wait, this is my code i think
[22:17] <mwhudson> yes