[08:52] <zetheroo> I would like to benchmark the CPU performance on a server running Ubuntu 16.04. I have installed the phoronix-test-suite but I am not sure which of the many processor benchmark tests are "best".
[11:19] <otisolsen70> On my Ubuntu servers, I seem to have an endless stream of these type of audit messages in auth.log: https://paste.yt/p24403.html
[11:19] <otisolsen70> Does Ubuntu Server by default log every program executed on a system?
[11:19] <otisolsen70> Is there a way to disable this?
[12:06] <konstruktoid> it's configured via auditd
[13:53] <ahasenack> kanashiro[m]: what does this statement mean:
[13:53] <ahasenack> "The latest docker.io version in Lunar requires Golang 1.18 to be backported to Focal."
[13:54] <ahasenack> in #1977860
[13:54] <ahasenack> is that preparing focal for the next future containerstack backport?
[14:23] <ahasenack> kanashiro[m]: around? I have some more questions
[14:24] <kanashiro[m]> ahasenack: to backport current docker.io in lunar we need go 1.18
[14:25] <kanashiro[m]> And we do not have it in focal and bionic, that's the SRU
[14:28] <ahasenack> kanashiro[m]: question about the dh-golang breaks
[14:29] <ahasenack> kanashiro[m]: it's my understanding the new version of golang needs GOCACHE set to a writable directory
[14:29] <ahasenack> that's what dh-golang >= 1.40 does
[14:29] <ahasenack> we won't backport that
[14:29] <ahasenack> so, will the version of dh-golang in bionic break? It sets GOCACHE to "off"
[14:29] <kanashiro[m]> ahasenack: yes, that's one thing. Also correctly set GO111MODULE
[14:30] <ahasenack> or in other words, packages that use dh-golang, *and* golang 1.18, will have to set that var manually? Or just break?
[14:30] <kanashiro[m]> We need to set it manually in d/rules
[14:31] <kanashiro[m]> Otherwise the package will not build
[14:31] <ahasenack> so when you backport the containerstack, or adsys, or whatever that needs golang 1.18, it will also likely need that adjustment, which is done automatically by newer dh-golang
[14:31] <kanashiro[m]> exactly 
[14:31] <ahasenack> ok
[14:32] <ahasenack> kanashiro[m]: don't you also need to remove it from d/control.in? The breaks?
[14:34] <kanashiro[m]> ahasenack: I could do that, yes. It was not an issue because we do not regenerate d/control pre or during build time automatically 
[14:34] <ahasenack> it was done so in the golang-1.16 case
[14:34] <ahasenack> I think it would be consistent
[14:34] <kanashiro[m]> I can fix that if you want
[14:34] <ahasenack> yes please
[14:34] <kanashiro[m]> ack
[14:34] <ahasenack> I'll reject the one that is there now then
[14:35] <ahasenack> use the same version
[14:38] <kanashiro[m]> ok
[14:48] <kanashiro[m]> ahasenack: uploaded the fixed version
[14:49] <ahasenack> thanks
[17:13] <mdeslaur> cpaelzer: any objection to me merging exim4?
[17:17] <mdeslaur> oh, maybe bryceh is doing it
[17:17] <mdeslaur> bryceh: are you still working on merging exim4? want me to do it?
[17:51] <mdeslaur> whoops too late :)
[18:00] <bryceh> mdeslaur, that's fine by me if you do it.  We sometimes use it for new hires to practice with, but not sure if we're doing that this time
[18:00] <bryceh> in any case, there are frequent updates so someone needing merge experience will likely have other opportunties :-)
[18:00] <mdeslaur> thanks bryceh, I just uploaded it, it fixes a security issue
[18:00] <mdeslaur> I figured you two wouldn't mind
[18:05] <ahasenack> kanashiro[m]: does the jammy task still make sense for this bug? https://bugs.launchpad.net/ubuntu/+source/golang-1.18/+bug/1977860
[18:05] -ubottu:#ubuntu-server- Launchpad bug 1977860 in golang-1.18 (Ubuntu Jammy) "Backport 1.18.1 to 18.04, 20.04 and 22.04 LTS" [Undecided, Incomplete]
[18:05] <ahasenack> jammy has 1.18.1, which the other releases are getting via the SRU
[18:05] <ahasenack> I think if someone wants 1.18.3 in jammy, for other reasons, that needs to be a different bug
[18:30] <kanashiro[m]> ahasenack: I hijacked that bug, initially the goal was jammy :)
[18:30] <ahasenack> that's where the 1.18.3 upload came from, right?
[18:31] <ahasenack> but it was removed now, and the reason is that 1.18 *is* the default golang in jammy, so updating it there isn't so trivial
[18:31] <ahasenack> concerns about rebuild failures and such, and I would also want to know if all apps already built with 1.18.1 would need to be rebuilt with 1.18.3 to benefit from the 1.18.3 updates
[18:54] <kanashiro[m]> Likely a bunch of them
[22:02] <Woet> is there a way to install google chrome or chromium on ubuntu 20 arm64 *without* snap?
[22:07] <Odd_Bloke> Woet: Your best bet is probably to see if the Debian package works (i.e. https://askubuntu.com/questions/1179273/how-to-remove-snap-completely-without-losing-the-chromium-browser/1206502#1206502)
[22:08] <Woet> hm, I saw that, it didn't seem ideal
[22:08] <Woet> but I guess it's the only option left
[22:09] <sarnold> you could probably stuff the debian packaging into a ppa or opensuse build service
[22:09] <Odd_Bloke> Regrettably, yes, as Canonical have decided against providing supported debs.
[22:14] <Woet> Odd_Bloke:  chromium : Depends: libwebpmux3 (>= 0.6.1-2.1) but 0.6.1-2ubuntu0.20.04.1 is to be installed
[22:14] <Woet> looks like it no longer works on the current versions
[22:15] <Woet> i guess i can backport it 
[22:15] <Woet> to be fair, that answer was january 2020. by now, debian stable is bullseye, not buster
[22:16] <Woet> i wonder if i change the apt repos to buster it will work
[22:17] <Woet> yup, that works
[22:17]  * Odd_Bloke takes notes
[22:46] <JanC> that seems like a bad idea
[22:47] <JanC> better build it in a PPA
[22:47] <JanC> (or maybe there already is one?)
[22:50] <Woet> JanC: I wasn't able to find a PPA that works on arm64 20.04
[22:54] <JanC> Woet: https://launchpad.net/~phd/+archive/ubuntu/chromium-browser seems to have them?
[22:54] <Woet> hmm
[22:54] <JanC> (not my PPA or by someone I know, so use with care as always)
[23:23] <JanC> seems like he's an active FLOSS community member, so it's _probably_ okay  :)