| === genii is now known as genii-core | ||
| === sem2peie- is now known as sem2peie | ||
| === sem2peie- is now known as sem2peie | ||
| === RikMills__ is now known as RikMills | ||
| xypron | I am looking for a sponsor for vim: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1944419 | 10:31 |
|---|---|---|
| ubottu | Launchpad bug 1944419 in vim (Ubuntu) "vim: impish missing in debchangelog.vim" [Undecided, New] | 10:31 |
| rbasak | xypron: that looks good, but Impish is in freeze now, and vim is seeded. So it needs to wait. | 10:32 |
| xypron | rbasak: thanks for reviewing. So it could be sponsored directly after release date? | 10:33 |
| rbasak | xypron: probably best to do it after beta is released, before final release. | 10:35 |
| xypron | rbasak: thanks | 10:35 |
| rbasak | xypron: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2021-September/001297.html has the details if you haven't seen that | 10:35 |
| === cpaelzer_ is now known as cpaelzer | ||
| seb128 | rbasak, xypron, the release team recommendation has always been 'just upload, queue will be reviewed when suitable', I don't think we should restain from queuing changes during freezes | 10:54 |
| rbasak | seb128: the email says "Please hold off | 11:05 |
| rbasak | with everything else until after we release on Thursday." | 11:05 |
| rbasak | Which I take to mean "don't upload". | 11:05 |
| rbasak | Otherwise "please hold off" has no meaning for non-release-team uploaders. | 11:05 |
| seb128 | rbasak, you are right, I've read the email now and I understand it like that | 11:05 |
| seb128 | my memory failed me there or recommendations changed | 11:06 |
| rbasak | No worries! | 11:06 |
| jawn-smith | bryceh, cjwatson: I've made some progress in determining the issues with the new openssh merge from Debian. It appears to be an actual regression with openssh built with glibc 2.34 running on kernels that don't have the close_range syscall. | 14:28 |
| jawn-smith | This appears when trying to run sshd in a chroot. Strace shows an ENOSYS when calling close_from, and then libc's closefrom tries to open /proc/self/fd in the chroot, which doesn't exist | 14:30 |
| jawn-smith | What I'm still failing to understand is why we're only seeing the issue on armhf. I'll keep digging on that part, but wanted to give you updated | 14:31 |
| jawn-smith | keep* you updated | 14:31 |
| cjwatson | jawn-smith: Isn't it likely just the seccomp filter? | 14:42 |
| cjwatson | It's not uncommon for that to need to differ across architectures. | 14:42 |
| jawn-smith | cjwatson: I will look into that. The issue exists upstream as well, just FYI | 14:43 |
| cjwatson | jawn-smith: Indeed | 14:43 |
| cjwatson | jawn-smith: It probably just needs a patch sent upstream to add close_range to the seccomp filter with suitable rationale, which we can then cherry-pick | 14:44 |
| jawn-smith | cjwatson: Excellent I'll take a look at that. Thanks! | 14:44 |
| bryceh | jawn-smith, thanks for the update | 14:45 |
| cjwatson | (FWIW I am working on a full upstream update, but need to first sort out the GSSAPI patch for which we share maintenance with Fedora) | 14:52 |
| bdmurray | oSoMoN: Do you know how to test https://code.launchpad.net/~osomon/ubuntu-release-upgrader/+git/ubuntu-release-upgrader/+merge/408838 ? | 16:16 |
| oSoMoN | bdmurray, I did run the unit tests, and also ran a dist-upgrade in a hirsute VM per instructions in README.devel | 16:18 |
| oSoMoN | are there other types of tests that can be run? | 16:18 |
| bdmurray | Oh, I hadn't reloaded since comment #6 | 16:19 |
| === sem2peie- is now known as sem2peie | ||
| === sem2peie- is now known as sem2peie | ||
| Eickmeyer | juliank: Sorry about the bad patch for packagekit. I have it fixed now, submitted upstream. I think it's safe to wait until after beta to upload. | 17:58 |
| juliank | Eickmeyer: ack, ping me after the beta in case I forget to sponsor a new patch | 18:02 |
| Eickmeyer | juliank: Thanks. :) | 18:07 |
| ijohnson[m] | what is the link to view oops ID's again? I can't seem to find it going to errors.ubuntu.com ? I was added to the group to oops for snaps a while ago but can't remember the way to view a particular oops given the ID | 20:08 |
| cjwatson | ijohnson[m]: oops.canonical.com and there's a text box | 20:08 |
| ijohnson[m] | ahhh that's the link thanks @cjwatson | 20:09 |
| cjwatson | Though the snap API is mostly on Sentry nowadays, I thought? | 20:09 |
| cjwatson | SSO and LP use oops | 20:09 |
| ijohnson[m] | oh hmm | 20:09 |
| ijohnson[m] | I am trying to debug a failure from snapd with the OOPS ID fc126488-17ef-11ec-bc20-fa163e983629 | 20:10 |
| ijohnson[m] | I guess next question then is how do I access sentry :-) | 20:10 |
| bdmurray | https://errors.ubuntu.com/oops/fc126488-17ef-11ec-bc20-fa163e983629 | 20:11 |
| ijohnson[m] | ah perfect thanks @bdmurray | 20:11 |
| cjwatson | Ah OK, so that's snapd client rather than snap store API, I see | 20:11 |
| ijohnson[m] | yeah it came from snapd after failing to install a snap | 20:13 |
| Eickmeyer | It appears the latest gtk+3.0 upload broke Electron-based apps. bug 1944468 | 20:41 |
| ubottu | Bug 1944468 in gtk+3.0 (Ubuntu) "Electron applications all crash upon launch" [High, New] https://launchpad.net/bugs/1944468 | 20:41 |
| sarnold | does downgrading the gtk+3.0 packages make it work again? | 20:58 |
| mwhudson | jawn-smith, cjwatson: we only see it on armhf because that is the only environment we test old kernel + new userland in | 21:29 |
| mwhudson | jawn-smith, cjwatson: there is nothing seccomp or architecture specific in all this aiui | 21:29 |
| Eickmeyer | sarnold: I need to try that, but I'd have to find the package first. | 21:29 |
| jawn-smith | mwhudson: thanks for the input. I hadn't realized armhf was the only environment with old kernel + new userland | 21:30 |
| jawn-smith | back to the upstream bugs plan then | 21:30 |
| mwhudson | jawn-smith: please (i mean they might point fingers at each other but well) | 21:30 |
| cjwatson | mwhudson: That would explain why it only shows up on this architecture, but the ENOSYS still indicates that it's likely to do with OpenSSH's seccomp sandbox, surely | 21:32 |
| cjwatson | Or do I have the wrong end of the stick somehow? | 21:32 |
| mwhudson | cjwatson: close_range was only added in 5.8 or somethign? | 21:33 |
| jawn-smith | mwhudson: 5.9 | 21:33 |
| bdmurray | Eickmeyer: the ones here? https://launchpad.net/ubuntu/+source/gtk+3.0/3.24.29-1ubuntu1/+build/21598221 | 21:33 |
| mwhudson | jawn-smith: thanks for knowing the details :) | 21:33 |
| cjwatson | mwhudson: Oh I see, now that I look at libc's closefrom.c it makes sense | 21:33 |
| Eickmeyer | bdmurray: Yeah, those. Actually, I get you to it, I'm there already | 21:34 |
| Eickmeyer | *beat | 21:34 |
| Eickmeyer | /s/get/beat | 21:34 |
| cjwatson | So the real difference is that now OpenSSH is using libc's closefrom when it previously used its own version? | 21:34 |
| mwhudson | cjwatson: yeah, the "eh /proc/self/fd isn't there let's do nothing" is certainly a design choice of some kind | 21:34 |
| cjwatson | In that case telling configure that libc doesn't have closefrom would also be a viable workaround here, given the limited environment in sshd's network monitor | 21:35 |
| mwhudson | yeah i think that's probably best | 21:35 |
| cjwatson | Configure with ac_cv_func_closefrom=false or so | 21:36 |
| cjwatson | Should still file an upstream bug since maybe they'll want to just avoid glibc's closefrom or maybe do something else, but that would be an easy packaging fix | 21:36 |
| cjwatson | Or indeed perhaps use glibc's closefrom everywhere except the sshd network monitor with its weird environment | 21:37 |
| Eickmeyer | *sigh* downgrading didn't work. Back to the drawing board. | 21:37 |
| Eickmeyer | Unless I need to reboot to clear the gtk cache. | 21:38 |
| cjwatson | (Or wherever it is. I'm assuming it must be in the monitor because otherwise you'd think /proc/self/fd would exist) | 21:38 |
| jawn-smith | cjwatson: to make sure I have this straight: I should file the upstream bugs and also make an update to our openssh package to configure differently | 21:38 |
| cjwatson | Well, see if ac_cv_func_closefrom=false fixes it first, especially if you have some way to run tests on armhf without making an upload | 21:39 |
| mwhudson | cjwatson: the test case is running sftp chrooted | 21:39 |
| jawn-smith | cjwatson: that's correct, running sshd -oChrootDirectory=/var/run and then attempting to sftp from that | 21:40 |
| mwhudson | this sort of thing https://www.thegeekstuff.com/2012/03/chroot-sftp-setup/ | 21:40 |
| cjwatson | But if that does the job then I think an upstream bug would be worthwhile explaining that glibc's new closefrom implementation breaks openssh's regression tests, <big explanation with example output etc.>, here's what we did to workaround it but maybe you have a better idea, would be worthwhile | 21:40 |
| jawn-smith | also, I have an unreasonable number of Pi's here so I can definitely recreate this locally without having to do an upload | 21:40 |
| cjwatson | OK, that's not the monitor, different kind of restricted environment | 21:40 |
| cjwatson | The monitor is the thing that sshd's privilege separation runs so that it can do preauth parsing of network packets with significantly reduced scope for compromise in case of parsing bugs | 21:41 |
| cjwatson | From what you've both said, I'd suggest building upstream master from git and running its regression tests on an x86 system with latest glibc and pre-5.9 kernel | 21:42 |
| cjwatson | That would make for a nice standalone bug report | 21:43 |
| jawn-smith | cjwatson: I can do that | 21:43 |
| cjwatson | And nobody would have to spend time arguing whether if it's arm-specific weirdness | 21:43 |
| cjwatson | s/ if// | 21:43 |
| Eickmeyer | sarnold, bdmurray: The downgrade didn't work, so I tried downgrading nvidia drivers from 470 to 460, no change in behavior. | 21:50 |
| Eickmeyer | Meaning, it's not GTK, but maybe someone else can help me figure this out because I'm coming up on EOD. | 21:57 |
| sarnold | Eickmeyer: dang :( | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!