[05:23] <cpaelzer> good morning
[05:24] <cpaelzer> thanks ahasenack for continuing on those PG-14 fixes I've found
[05:26] <cpaelzer> bryceh: ahasenack: yeah that (lp-test-ppa + ppa-dev-tools + wishes + some work => a great useful thing) is exactly what I have hoped for as well
[05:26] <cpaelzer> let us see how the lightning talks resonate
[05:30] <bryceh> :-D
[11:10] <athos> good morning!
[12:25] <ahasenack> cpaelzer: bryceh: btw, juliank asked to no longer trigger autopkgtests from ppas, the clusters are swamped
[12:26] <ahasenack> (not directly asked us, but mentioned it in general)
[12:29] <cpaelzer> ahasenack: ok, I have none running or queued atm
[12:30] <cpaelzer> ahasenack: does this also imply stopping ppa builds, or only autopkgtests?
[12:30] <ahasenack> I only heard about dep8
[12:31] <kanashiro> do we have any FTBFS left to be investigated? Or everything is sorted out in some way?
[12:31] <cpaelzer> kanashiro: I think we have them all by now
[12:31] <cpaelzer> some still in -proposed, but we have them
[12:33] <kanashiro> cpaelzer, is any of them unassigned?
[12:33] <ahasenack> samba takes 5h30min to build on riscv64 :/
[12:33] <ahasenack> kanashiro: I'll have one for review shortly
[12:33] <ahasenack> but it's a bit awkward
[12:33] <ahasenack> python-tempita
[12:33] <ahasenack> it's still python2 :/
[12:33] <cpaelzer> ahasenack: I have an unsubscription request up for that btw
[12:33] <ahasenack> and finally stopped building with python 3.10
[12:33] <cpaelzer> it is openstack
[12:33] <ahasenack> yeah
[12:33] <ahasenack> it's abandoned upstream
[12:34] <ahasenack> same version out there for years
[12:34] <ahasenack> and did I mention it's py2 only? :)
[12:34] <cpaelzer> so you do not "have to" fix it, but I'm not stopping you if you have an idea how to handle it
[12:34] <ahasenack> it survived this long because it was using a setuptools trick to run 2to3 on-the-fly during build
[12:34] <ahasenack> cpaelzer: my "idea" (quite the compliment) was to build it with py3.9, where 2to3 still runs, and diff the result
[12:34] <ahasenack> so we would end up with exactly the same
[12:34] <ahasenack> in py3.10
[12:35] <cpaelzer> if it works it is fine for ubuntu overall, but if it explodes into something long and complex log your insight in a bug and assign the openstack team please
[12:36] <ahasenack> oh no, it's done
[12:36] <ahasenack> it's just not one of those smart patches you would put up in your CV
[12:37] <cpaelzer> with a package of this kind, that is just the right kind of fix for now
[12:37] <ahasenack> ok, I'll put it up
[12:37] <ahasenack> I even improved it a bit, the unit tests were not running
[12:37] <ahasenack> now they are :)
[12:37] <ahasenack> all 3 of them :P
[12:39]  * ahasenack can't stay away from getting tests to run
[12:39] <sdeziel> ahasenack: I wouldn't worry too much about stuff to actually put on your CV if I were you ;)
[12:39] <ahasenack> hah
[12:51] <cpaelzer> Hmm, am I overreacting on bug 1893716 (found in housekeeping of long dormant cases) or is it as important as I think?
[12:52] <cpaelzer> ahasenack: rbasak: (or anyone that wants) ^^ if I could have your sanity check before spending (potentially useless) time?
[12:53] <ahasenack> cpaelzer: kanashiro https://code.launchpad.net/~ahasenack/ubuntu/+source/python-tempita/+git/python-tempita/+merge/417740
[12:53] <ahasenack> (since you asked :P)
[12:54] <ahasenack> cpaelzer: taking a look at that other one
[12:55] <ahasenack> btw, migrations are very slow
[12:55] <cpaelzer> ahasenack: I know, I have a few I'm waiting on, but we are all behind the test queue delay
[12:56] <ahasenack> cpaelzer: about tempita, don't you/we need a pr to subscribe the openstack team to it?
[12:56] <cpaelzer> they are
[12:56] <cpaelzer> it is double subscribed, hence no need
[12:56] <ahasenack> n/m then :)
[12:56] <ahasenack> best outcome
[13:09] <rbasak> cpaelzer: I think your performance test is important. I was mentally dismissing the bug as "need metrics to convince me" until I saw that. Problem is, as you discovered, I don't think PAM makes any distinction on "interactivity".
[13:09] <rbasak> I wonder if instead we can figure out why pam_motd is slow and fix that.
[13:10] <rbasak> Because it seems to me the (only) problem is speed. Extra stuff happening on non-interactive ssh is not an issue AFAICT _except_ for speed.
[13:11] <rbasak> And plenty of other extra stuff happens all the time, and we generally accept that as a trade-off for convenience. Provided that there isn't actually a measureable performance penalty.
[13:46] <cpaelzer> rbasak: thanks, yes as I've also written - a lot more is happening on login anyway
[13:47] <cpaelzer> rbasak: I'll have a short time-boxed look if it could detect interactivity - if not then as I posted already we should at least make each of them cache the results
[13:47] <cpaelzer> rbasak: that way e.g. if only once evey 5 seconds things are "slow" it will be much less overhead
[13:47] <cpaelzer> and we have prior examples for that
[13:48] <ahasenack> sounded like landscape-sysinfo was the biggest culprit
[13:48] <ahasenack> i remember it checks the load before running, but yes, it should cache
[13:56] <rbasak> Maybe we need to refactor things to not happen by blocking login. Like in the background on an independent systemd timer.
[13:57] <rbasak> And rather than have every motd service reinvent the wheel, maybe they should be integrated somehow.
[13:57] <rbasak> Like a .d/ directory where a script's output is automatically cached
[14:17] <cpaelzer> rbasak: this time (we had that one) it is not about slowness and therefore not about background execution
[14:18] <cpaelzer> rbasak: it really seems to be more about useless work consuming cpu time
[14:18] <cpaelzer> rbasak: the problem with a global caching is that each sub-element might have different contraints how often or under what condition they need to be refreshed
[14:21] <rbasak> cpaelzer: surely "useless working consuming cpu time" is exactly "slowness" from a user perspective?
[14:21] <rbasak> If subelements have special needs then they don't have to use a general mechanism
[14:21] <rbasak> But most will probably be able to fit into one.
[14:22] <ahasenack> I think a long time ago landscape-sysinfo was showing cached information
[14:22] <ahasenack> it had a timestamp in the output because of it
[14:22] <ahasenack> I'm thinking precise, trusty
[14:22] <ahasenack> maybe lucid
[14:22] <sdeziel> putting a file in a `.d/$JOB.$TTL` would make it possible to have different expiry
[14:30] <ahasenack> rbasak: hi, are you going to take a look at https://code.launchpad.net/~athos-ribeiro/usd-importer/+git/usd-importer/+merge/416951 ? 
[14:30] <ahasenack> the snap isn't working on jammy
[14:34] <rbasak> Added to my list - thanks
[15:56] <lvoytek> This bug came up during my triage and I was wondering if anyone more familiar with smartmontools could see if anything can be done for it. From what I can tell it seems like a pretty rough race condition. https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1966610
[15:57] <bryceh> @lvoytek, have you run the core dump through gdb?
[15:58] <lvoytek> I haven't yet, no
[15:59] <bryceh> there's a page in UMH with some discussion on using gdb with .crash files, it's got some paint-by-numbers steps and tips for what to do once you have a core dump
[16:00] <lvoytek> Alright, I'll see what I can find with that
[16:01] <bryceh> generally with these types of problems, the crash itself can be identified and papered over, but it'll usually just start crashing somewhere else in the code, so having reliable steps to reproduce ends up being pretty important
[16:02] <bryceh> for triaging, it may be enough to try running the suggested command 10 or 20 times (if the command doesn't take too long), and if it doesn't repro ask reporter for help figuring out how to make it more reproducible
[16:02] <bryceh> but anything more probably turns more into bugwork than triaging :-)
[16:06] <bryceh> from gdb I suspect the best you can hope for is to identify what the variable with the invalid pointer is, and maybe what line of code is encountering it.  But the source of the invalidness can often be hard to tease out, esp. just from a backtrace alone
[16:06] <bryceh> if I understand correctly, looks like it's in malloc_printerr() and presumably the invalid pointer is the str entry being passed in?
[16:07] <bryceh> __pthread_kill_implementation suggests threading is involved, which is notoriously hard to debug, but could explain why it's hard to reproduce
[16:08] <bryceh> sergiodj might also have some tips, he's good with gdb stuff
[16:21] <lvoytek> Thanks for the help! I tried running the command 20 times with no errors. I'll ask them to provide the crash file for futher debugging and possibly help with repro
[16:29] <lotuspsychje> lvoytek: if it can help anyhow, i tested your command on sda1 on ubuntu-desktop 22.04, seems to work well on my side
[16:31] <lvoytek> Thanks for testing that, I tried with my nvme1on Jammy
[16:31] <lotuspsychje> on -server ?
[16:32] <lvoytek> I used desktop and lxd. That would be a good thing to try though
[18:48] <adac> I try to apply netplan, but I get the following error: https://pastebin.com/2v4VPNtQ Any ideas what is causing this?
[18:49] <adac> When I check the systemd output, all seems to be ok: https://pastebin.com/uMEY0qVF
[18:52] <adac> Hmm journal seems to tell us a bit more: https://pastebin.com/5mxZR1vx
[19:02] <ahasenack> adac: the journal seems to be about something else (openvpn?)
[19:02] <ahasenack> see if you can find this file, netplan-ovs-cleanup.service'
[19:02] <adac> I removed openvpn for now. Now I get: Failed to set up mount namespacing: /run/systemd/unit-root/: Host is down
[19:03] <ahasenack> maybe in /run/ or /etc/systemd/ somewhere
[19:03] <adac> systemd-networkd.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-networkd: Host is down
[19:03] <adac> ahasenack, will check
[19:05] <adac> ahasenack, https://pastebin.com/gScq0DCy
[19:07] <ahasenack> I don't know how ovs is normally configured...
[19:07] <adac> what is ovs even?
[19:07] <adac> what does it do?
[19:07] <adac> I'm not sure why it is even there
[19:08] <ahasenack> check the conf files in /etc/netplan/*, nothing mentions it?
[19:08] <ahasenack> oh, I have that too
[19:08] <ahasenack> interesting
[19:08] <adac> actuall no
[19:08] <ahasenack> do you have /usr/bin/ovs-vsctl? (I don't)
[19:08] <adac> no file mentions it
[19:08] <adac> nope I havent
[19:09] <ahasenack> does this work? systemctl start systemd-networkd.service netplan-ovs-cleanup.service
[19:09] <ahasenack> it's the command it was trying to run
[19:09] <ahasenack> or do you get that namespace error you pasted above
[19:10] <adac> ahasenack, let me try. What I try currently is "netplan try -timeout 120"
[19:10] <adac> since I'm online remote so it could kick me out otherwise
[19:10] <adac> that is a bit the problem
[19:11] <ahasenack> that's a bit of a problem indeed
[19:11] <ahasenack> my other suggestions won't apply then
[19:11] <adac> Maybe I need to stop KVM machines
[19:11] <adac> to make this workl
[19:12] <adac> Since they are still using the network interface
[19:12] <adac> that I want to have removed
[19:13] <adac> with my new netplan file
[19:13] <ahasenack> careful and good luck
[19:13] <adac> ahasenack, lets try. thanks man!
[19:15] <ahasenack> do you have network mounts?
[19:15] <ahasenack> like samba/cifs/windows, nfs, etc?
[19:20] <adac> ahasenack, i Have samba mount
[19:20] <ahasenack> is it working fine?
[19:20] <adac> ahasenack, unmounting now solved the issue!!!
[19:20] <adac> thanks so much!!
[19:36] <ahasenack> good to know, the "host is down" message was for the smb server then I guess