[03:34] <foo> A simple cp -Rv command on 20 files is taking longer than it should. What might this imply? We're talking < less than 10MB of files. 
[03:44] <arraybolt3> foo: How fast are the disks involved, and is one of the directories on a remote server and attached over the network?
[03:44] <arraybolt3> I've had copies between my local system and an SFTP directory to be painfully slow.
[03:45] <arraybolt3> Though I'm using a connection with a rather slow upload speed and uploading to a remote server over the Internet.
[04:31] <foo> arraybolt3: this is on a digital ocean droplet on a production server. All files are local to the VM. 
[04:31] <foo> arraybolt3: what's odd is everything else seems ok, just the copying of files that causes an issue
[04:31] <foo> I don't see any network delays during this time but am paying attention to that too
[04:36] <JanC> how many files is also important; "less than 10 MiB" could in theory be a million or more tiny/empty files/directories  :)
[04:39] <JanC> also, the -v could be causing the slowness too
[04:39] <JanC> especially if there are many files
[13:33] <rbasak> bryyce: have you looked at the autopkgtest failure in bug 1986521?
[13:33] -ubottu:#ubuntu-server- Bug 1986521 in openssh (Ubuntu Jammy) "ssh client spins if output fd closed" [Medium, Fix Committed] https://launchpad.net/bugs/1986521
[13:50] <bryyce> no
[13:52] <bryyce> hg-git and xen-tools.  hmm
[13:58] <bryyce> @rbasak xen-tools might just be flaky.  retriggered it.  Not sure on hg-git but for now retriggered those too.  I'll check back later.
[14:22] <rbasak> Thanks!
[14:38] <elflng> hiya. there seems to be an issue with the image create by xen-create-image --dist=bullseye. when loading the created domu with xl create /etc/xen/<image>.cfg, it bootloops. if i use the console to get on, i can see that it gets to pygrub, but if i try to edit the kernel options, it errors with an 'unable to find partition containing kernel' (i can paste the whole traceback on pastebin if youd like), 
[14:38] <elflng> and if i hit enter or wait for the timeout, it crashes silently.
[14:38] <elflng> the same xen-create-image line differing only by --dist=buster works fine upon load.
[14:38] <elflng> (as a sidenote, the /usr/share/xen-tools/debian.d/20-setup-apt file is missing instructions for bullseye, but even adding them does not fix the issue.)
[14:38] <elflng> i have full straces for the creation and load of both buster and bullseye images, if that would be helpful.
[15:06] <ravage> elflng: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1956166 maybe this is related?
[15:06] -ubottu:#ubuntu-server- Launchpad bug 1956166 in xen (Ubuntu Kinetic) "Ubuntu 22.04 doesn't boot with xen" [Medium, Fix Released]
[15:08] <ravage> i dont think Ubuntu spends a lot of time on Xen anymore. I moved on to lxf a long time ago too :)
[15:10] <ogra> lxf ? did i miss two iterations ? 😄
[15:11] <ravage> :D
[16:23] <radix0> Let me know if I need to RTFM harder or use a search engine better. Can't find an obvious answer. Removing a CA cert is easy enough - plop in /usr/local/share/ca-certificates/ and update-ca-certificates. But how do I *remove* a CA certificate? Is it as simple as removing the two symlinks in /etc/ssl/certs ?
[16:25] <oerheks> a help https://ubuntu.com/server/docs/security-trust-store
[16:25] <radix0> Correction to third sentence should have read "Adding a CA cert is easy enough"
[16:26] <oerheks> https://ubuntu.com/server/docs/security-certificates
[16:26] <radix0> oerheks, neither of those describe how to remove the trust of a CA
[16:28] <sdeziel> radix0: I think you need to edit `/etc/ca-certificates.conf` and prefix those you do not trust with a `!`
[16:29] <sdeziel> radix0: then run `sudo update-ca-certificates`
[16:58] <radix0> sdeziel, I looked at that file but mine did not show up there. I just removed the two links and rebooted and it *seems* to have had the desired effect. It's just weird this isn't obvious/documented.
[16:59] <radix0> chatgpt also gave me a hint of grepping the /etc/ssl/cert/ca-certificates.crt file which is how I confirmed that the CA was no longer trusted.
[17:02] <sdeziel> radix0: removing the links risks having them recreated by the next run of `update-ca-certificates`, no?
[17:10] <chromebittin> Starting working at the commune with Ubuntu stuff on Friday this week :) 
[18:28] <radix0> sdeziel, I neglected to mention that I removed the cert from the /usr/local/share directory
[18:38] <JanC> radix0: I think dpkg-reconfigure on the ca-certificates package does what you want
[18:39] <JanC> if you wnat an easy way to check/uncheck certificates
[18:39] <radix0> I'm not familiar with dpkg operations. I'll have to check that out later. Does it bring up a TUI or something?
[18:41] <JanC> yeah, a curses TUI that allows you to select if new certificates should be added automatically (yes/no/ask) and allows you to check/uncheck individual certs from the package
[18:42] <radix0> intriguing. thanks.
[18:42] <JanC> I assume it basically does what sdeziel says (edit that .conf & then run the update script)
[18:43] <sdeziel> radix0: ah, I assumed you wanted to remove one of the packaged-shipped CA. If you want to remove a custom one (in /usr/local/share/...), removing the file in question and running `sudo update-ca-certificates` should do
[18:44] <sdeziel> radix0: but if you removed the file and the symlink, you've probably essentially did what `update-ca-certificates` would have done for you
[18:47] <JanC> ah, right, when it's a custom cert; not sure if dpkg-reconfigure would handle that  :)
[19:46] <radix0> sdeziel, see I thought removing the cert first from /usr/local/share + update-ca-certificates would do it, but in terms of CRUD that's only a CRU operation me thinks. Not that I know what I'm talking about lol
[23:16] <athos> hey bryyce, I forgot to mention: pg-snakeoil tests just needed to be re-triggered for clamav (after pg-15 migrated)
[23:16] <athos> they are green now
[23:17] <athos> clamav should migrate soon
[23:17] <athos> also, thanks for the php7.4 review ;)
[23:25] <athos> sergiodj: The new postgis build should unblock the remaining issues with pg-common now. Thanks for the review
[23:40] <bryyce> athos, ok great, thanks for looking at it!
[23:46] <sergiodj> athos: +1