[04:20] <vpa1977> Hi, would it be possible to review rlottie FTBS: https://code.launchpad.net/~vpa1977/ubuntu/+source/rlottie/+git/rlottie/+merge/438432 - I've tried to do minimal change and just removed offending code since it was not used.
[06:37] <zhsj> a new/fixed version of arno-iptables-firewall has migrated. could someone retry all regressions by arno-iptables-firewall? notably I want https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=arno-iptables-firewall&trigger=kmod%2F30%2B20221128-1ubuntu1
[07:15] <liushuyu> Hi there, can someone help me retry some autopkgtests? Thank you! The links follow after this message:
[07:15] <liushuyu> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=i386&package=libzstd&trigger=libzstd/1.5.4%2Bdfsg2-3
[07:15] <liushuyu> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=victoriametrics&trigger=libzstd/1.5.4%2Bdfsg2-3
[07:16] <liushuyu> -- End of links. Thank you!
[08:48] <soundmodel> anyone know good hosts for having continuous IRC with FOSS projects?
[09:01] <schopin> coreycb: The only thing I can tell you about rustc backports is that as long as we have Firefox in an LTS release archive we'll have to regularly backport rustc to all subsequent releases. We should move to versioned package names at some point to minimize potential breakages though.
[09:06] <schopin> coreycb: I'm a bit surprised by wanting to backport python-cryptography though. Wouldn't that be fairly risky given the number of rdeps?
[09:15] <Unit193> soundmodel: IRCCloud, or perhaps a ZNC host.
[09:18] <soundmodel> but I also read: https://libera.chat/contributing/sponsor/
[09:21] <soundmodel> it's surprising that I get this feature free with Discord, but then these channels decide to use IRC while I cannot find a host that gives me free service
[10:04] <ginggs> zhsj: arno-iptables-firewall retried
[10:04] <zhsj> ginggs: thx
[10:05] <ginggs> liushuyu[m]: libzstd and victoriametrics retried
[12:19] <coreycb> schopin: Thanks for the info. yes there are a lot of rdeps. I don't know that I have much of a choice unfortunately since new versions of keystone for openstack require it.
[12:27]  * ahasenack wonders why ubuntu's vim still doesn't default to set bg=dark, given the default terminal is dark
[13:18] <ahasenack> so a dep8 test starts at 18:54:16
[13:18] <ahasenack> env is being prepared
[13:18] <ahasenack> that's a bunch of apt upgrades/installs
[13:18] <ahasenack> it gets killed mid-apt-install at 20:05:07
[13:18] <ahasenack> timeout: kind: install
[13:19] <ahasenack> default "install" timeout in autopkgtest is 3000s
[13:19] <ahasenack> so the vm didn't even finish apt-get install in time?
[13:19] <ahasenack> are the dep8 vms so slow? disk? network?
[13:19] <ahasenack> https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/arm64/a/auto-multiple-choice/20230306_200519_8770d@/log.gz
[13:19] <ahasenack> @paride: any idea? does that depend on which dc it was launched? Are there known issues?
[13:20] <ahasenack> autopkgtest-lrg-root4@bos02-arm64-18.secgroup <-- "boston 02"?
[13:21] <ahasenack> cpaelzer: you mentioned something about "good" and "bad" DCs for dep8 runners the other day iirc?
[13:22] <paride> ahasenack, I have no clear idea, I'm trying to manually bring up a VM which shows clear slowness to then point IS to it
[13:22] <ahasenack> paride: so you have seen this slowness already?
[13:41] <cpaelzer> ahasenack: yeah bos01 is the one with newer chips
[13:41] <cpaelzer> but this log seems slower than anything I referred to would cause
[15:44] <ahasenack> xnox: hm, I'm not able to reproduce #1826294 in a lunar vm, with rsyslog's apparmor profile in enforce mode. I tried both running "os-prober" and the shell script from the bug. What am I missing?
[15:46] <xnox> ahasenack:  i can reproduce it, but i am on a weird kernel. Question 1) do you run it as root Question 2) do you windows drive attached to make os-prober do things and log stuff?
[15:47] <ahasenack> xnox: 1) I ran the test script (and os-prober) as root, yes
[15:47] <xnox> ahasenack:  question 3) did you upgrade to 6.1 kernel?
[15:47] <ahasenack> 2) nope, nothing of the sort, no drive attached, just plain lunar vm started up
[15:47] <xnox> cause we also have apparmor regression in 6.1 kernel
[15:47] <ahasenack> 3) nope, am on 5.19, let me upgrade and reboot
[15:47] <xnox> i think plain lunar vm will quickly find nothing, and thus will not attempt to do anything.
[15:47] <xnox> please try 6.1 kernel, from lunar-release.
[15:47] <ahasenack> will do
[15:48] <xnox> hopefully that will be enough to trigger the regression. cause maybe it is our apparmor regression.
[15:48] <ahasenack> what is the apparmor regression?
[15:50] <xnox> ahasenack:  we dropped patches for ipc mitigation, as we didn't have updated pull request.
[15:50] <xnox> ahasenack:  also i upload os-prober work around for --socket-error=off => so when running os-prober, ideally there should be no denials in dmesg, and no error messages on stderr w.r.t. unable to open /dev/log.
[15:51] <xnox> but that's only in lunar-proposed right now
[15:51] <xnox> also need a bug report for apparmor
[15:51] <ahasenack> yeah, I saw your fix, I still have the old os-prober package
[15:51] <ahasenack> hm, on 6.1.0 now
[15:52] <ahasenack> I changed the test script slightly to produce a unique log message everytime, to avoid rsyslog's throttling
[15:52] <ahasenack> I do see two logger calls, and they don't fail, and no apparmor denials
[15:52] <ahasenack> xnox: did you reproduce the DENIED with the test script from the bug?
[15:52] <ahasenack> or just with an os-prober call
[15:53] <ahasenack> I don't doubt the fix, there are many apparmor profiles out there with that extra flag
[16:18] <xnox> ahasenack:  i'm seeing this on the linux-laptop 6.1 kernel which is a ppa kernel.
[16:18] <xnox> ahasenack:  i guess the onus is on me to reproduce this with stock lunar
[16:18] <ahasenack> xnox: is there one in lunar-proposed I could try?
[16:30] <xnox> no
[16:30] <xnox> it will never be in ubuntu archive, and it's arm64 only kernel
[16:30] <xnox> ahasenack:  https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1826294/comments/4 => can you try that ?
[16:30] -ubottu:#ubuntu-devel- Launchpad bug 1826294 in rsyslog (Ubuntu) "os-prober exits prematurely with 'logger: socket /dev/log: Protocol wrong type for socket'" [Critical, New]
[16:30] <xnox> as that's minimal end-to-end reproducer for me, on arm64
[16:31] <xnox> This is Ubuntu desktop install. rsyslog.service is active and running, systemd-journald-dev-log.socket is running.
[16:31] <xnox> if it matters
[16:43] <liushuyu> ginggs: Thank you!
[20:02] <kanashiro[m]> enr0n: done
=== fo0bar_ is now known as fo0bar
[20:11] <fo0bar> Looks like ubuntu-ports currently has a Packages mismatch for systemd: https://gist.github.com/rfinnie/1bbd5d01cb250b4991004ba698d77ae5
[20:17] <sarnold> hey fo0bar :) this should be fixed soon
[20:18] <fo0bar> haha, I returned to IRC for a bug report :) (actually no, I first mentioned it on an alumni Signal channel, THEN came here).  thanks for the confirmation
[20:19] <sarnold> :D
[20:43] <sarnold> fo0bar: try again?
[20:46] <fo0bar> sarnold: confirmed, thanks!
[20:46] <sarnold> fo0bar: woot! thanks :)