[00:25] <mwhudson> mwhudson@anduril:~/ubuntu/logs$ apt-cache show libstdc++6 | grep -E '^Package|Description-en'
[00:25] <mwhudson> Package: libstdc++6
[00:25] <mwhudson> Description-en: GNU Standard C++ Library v3
[09:36] <eoli3n> Hi mardy
[09:36] <eoli3n> i'm back to work, i really need to find a way to fix firefox
[09:36] <eoli3n> https://forum.snapcraft.io/t/cannot-open-path-of-the-current-working-directory-permission-denied-bis/28704/41
[09:37] <eoli3n> can we take some time on this, if you have some I will answer as quickly as I can
[09:37] <eoli3n> I need to fix this before the end of the week, to be able to start migrating ~800 desktop next week
=== Fallen is now known as Fallen[m]
=== Fallen[m] is now known as Fallen
[12:18] <ahasenack> Unit193: are you planning on updating wireguard in debian before ubuntu's feature freeze?
=== luis220413_ is now known as luis220413
[12:37] <eoli3n> mardy should I set no_root_squash option client or server side ?
[12:38] <eoli3n> when i add this client side in autofs config and restart autofs/umount user home, then remount, the option seems ignore
[12:38] <eoli3n> d
[13:54] <enr0n> I am looking for a sponsor for bug 1860568, which is a left over from my +1 shift a couple weeks ago
[13:54] <ubottu> Bug 1860568 in dtfabric (Ubuntu) "fails autopkgtest on s390x" [Undecided, Confirmed] https://launchpad.net/bugs/1860568
[14:45] <jawn-smith> Did an AA remove my busybox upload from kinetic-proposed? It was there yesterday and now it's gone
[14:47] <ginggs> jawn-smith: it's migrating...
[14:48] <jawn-smith> oh, that's surprising cause there was still a failed autopkgtest
[14:48] <jawn-smith> oh yeah there it is, "will attempt migration due to a hint"
[14:48] <ginggs> zfs-linux?
[14:48] <jawn-smith> Thanks ginggs! Yeah, zfs-linux
[14:48] <jawn-smith> I missed that there was a hint for that
[14:54] <enr0n> bdmurray: The systemd amd64 autopkgtest passed on staging. Would you prefer to try the remaining arches there before re-triggering in the production autopkgtest environment?
[15:16] <nibbon_> o/
[15:17] <nibbon_> is there a way to change the compression of a .deb generated by dkms mkbmdeb?
[15:19] <athos> amurray: hi! I am wondering if it would be OK to sync redis 7.x from debian or if there is some special reason to keep it in 6.x for kinetic
[15:27] <xnox> nibbon_:  because you need different one?
[15:27] <xnox> nibbon_:  normally one would produce those inside schroot created by mk-sbuild such that they are compatible with a target release.
[15:32] <bdmurray> enr0n: Is the PPA upload something that'll eventually go to release? I mean could you get what you are looking for by using staging? It'd be faster than waiting for the production queues to be consumed.
[15:38] <enr0n> Yes, these are pre-upload checks for merging 251.4 from debian. slyon went ahead and triggered the tests though, except for armhf.
[15:41] <ginggs> athos: i'd say redis looks good for a sync, it's in universe and CVE-2022-0543 is fixed in the debian changelog
[15:41] <ubottu> It was discovered, that redis, a persistent key-value database, due to a packaging issue, is prone to a (Debian-specific) Lua sandbox escape, which could result in remote code execution. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0543>
[15:42] <enr0n> bdmurray: so if we could trigger the armhf test on staging that would be good
[15:44] <bdmurray> enr0n: that is done
[15:44] <enr0n> bdmurray: thanks!
[16:57] <athos> ginggs: thanks! That's what I have been thinking! Just wondered it would be nice to ask before sync'ing to ensure there's no other reason it wasn't sync'd yet apart from that CVE
[17:05] <nibbon_> xnox: yeah, I have a repository that doesn't support the default tar compression. Right now I'm using an ugly hack - unpacking and repacking passing -Zxz - but I wanted to know whether there an option or a env variable I can pass to dkms
[17:09] <xnox> nibbon_:  best option to open a feature request to https://github.com/dell/dkms/issues
[17:13] <nibbon_> oic, I hope there was a special spell to cast 🙄 ... alrighty then, I'll open a feature request with them. Thx
[17:44] <Unit193> ahasenack: I think that's unlikely.
[18:36] <ahasenack> ok
[18:59] <luis220413> How can I get the build status of multiple packages in the development release at once?
[18:59] <luis220413> Specifically, I want to know which Haskell packages are failing to build.
[19:00] <Unit193> ahasenack: Why do you ask?
[19:00] <ahasenack> because the version we have is from september 2021
[19:01] <ahasenack> almost a year old, assuming there is a new one out there
[19:02] <Unit193> If there was a new one, I'd have picked it up.  It's just the tests pending right now.
[19:02] <ahasenack> yeah, just checked, looks like the latest tag: https://github.com/WireGuard/wireguard-tools/tags
[19:02] <ahasenack> so n/m
[19:03] <Unit193> 1. The "This package is out of date, email the maintainer!" would have notified me.  2. I have uscan --report run over all of my packages every three days, I'd know. :3
[19:03] <jbicha> luis220413: click the good checkbox at https://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html
[19:04] <sarnold> that's cool
[19:46] <luis220413> This build is blocking several packages: https://launchpad.net/ubuntu/+source/haskell-lua/2.1.0+ds1-2/+build/24233985
[19:46] <luis220413> Actually, all builds for this source package
[19:46] <vorlon> luis220413: https://people.canonical.com/~ubuntu-archive/transitions/html/html/ghc.html is the best overview; I am working through the necessary rebuilds
[19:47] <luis220413> Thanks!
=== justache is now known as justache_
=== justache_ is now known as justache
[19:49] <luis220413> However, this build was retried before that of haskell-tasty, causing dependency failures.
[19:49] <luis220413> vorlon: However, these builds (of haskell-lua) was retried before those of haskell-tasty, causing dependency errors.
[19:49] <luis220413> *were
[19:51] <vorlon> luis220413: someone retried all the failed package builds; there's no logs to say who did this.  I am building the packages in order.
[19:51] <luis220413> Thanks!