Re: -current amd64 packages not updated? Impatient or broken?
On Thu, Jan 07, 2021 at 05:44:05PM -0700, Theo de Raadt wrote: > Chris Cappuccio wrote: > > > Mihai Popescu [mih...@gmail.com] wrote: > > > I was in the same situation, impatient to have a 2021 snapshot. > > > > > > Warning: I am not sure you will not finish with a Frankenstein system. I > > > am > > > not so good with compiler-linker stuff. > > > > For those trying to use the latest snap and the latest ports, try link > > libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0 > > for now. Frankenstein, indeed. You'll feel dirty just doing it. > > DO NOT DO THAT. > > We do not want reports from people about weird troubles, after they do > such things. > ... and this is the sort of thing that may work now and then bite you weeks later. -ml
Re: -current amd64 packages not updated? Impatient or broken?
Chris Cappuccio wrote: > Mihai Popescu [mih...@gmail.com] wrote: > > I was in the same situation, impatient to have a 2021 snapshot. > > > > Warning: I am not sure you will not finish with a Frankenstein system. I am > > not so good with compiler-linker stuff. > > For those trying to use the latest snap and the latest ports, try link > libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0 > for now. Frankenstein, indeed. You'll feel dirty just doing it. DO NOT DO THAT. We do not want reports from people about weird troubles, after they do such things.
Re: -current amd64 packages not updated? Impatient or broken?
Mihai Popescu [mih...@gmail.com] wrote: > I was in the same situation, impatient to have a 2021 snapshot. > > Warning: I am not sure you will not finish with a Frankenstein system. I am > not so good with compiler-linker stuff. For those trying to use the latest snap and the latest ports, try link libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0 for now. Frankenstein, indeed. You'll feel dirty just doing it.
Re: -current amd64 packages not updated? Impatient or broken?
I was in the same situation, impatient to have a 2021 snapshot. Dirty hint: the .hk mirror still has the base part from 2020! But try it as a last option, the folks there are not so bandwidth fortunate. After installing the base, please switch /etc/installurl to something more suitable as distance and bandwidth. Warning: I am not sure you will not finish with a Frankenstein system. I am not so good with compiler-linker stuff.
Re: help needed with httpd.conf and rewrite directive
Yeah, or that... I realized that after but didn't want to double post.
I emailed Kevin off-list to mention that the "/" character isn't special so
it doesn't need to be escaped so Edgar's example can be modified to:
location match "^/sendy/l/([%w/]+)$" {
request rewrite "/sendy/l.php?i=$1"
I didn't hear back if it worked or not though.
John
On Thu, Jan 7, 2021 at 2:44 PM Christian Weisgerber
wrote:
> On 2021-01-07, John McGuigan wrote:
>
> > httpd's regex is based on Lua's, the following site will help you figure
> it out:
>
> Or, you know, the patterns(7) man page.
>
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
>
Re: help needed with httpd.conf and rewrite directive
On 2021-01-07, John McGuigan wrote: > httpd's regex is based on Lua's, the following site will help you figure it > out: Or, you know, the patterns(7) man page. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: -current amd64 packages not updated? Impatient or broken?
On 07/01/2021 1:30 p.m., Christian Weisgerber wrote: Steve Williams: I hesitate to send this because perhaps I'm just too impatient, but then again, perhaps not. This is not critical/time sensitive. I just thought I'd check if there a problem with the current packages folder from the mirrors? No, the amd64 package builds have been slightly delayed. First by a problem in lang/rust, which semarie@ fixed in admirably short time. Then the package build was cut short because the machine running dpb(1) panicked with filesystem corruption. A new build is running now and will take another 24h to complete if all goes well. Hi, Thanks for the update! Ah, the joys of big builds! I remember being in CPSC in University in the early 1980's and doing ray tracing. We did a 20 second movie @ 24 frames per second (16 mm film!!!). Each frame took at least 5 minutes to render on "leading edge" (at the time) SGI hardware. We would start it Friday night and it would complete before classes on Monday AM. We had to hold our breath that nothing would go wrong over the weekend or that someone wouldn't start playing flight simulator on the network with the other 2 workstations! lol Good luck with everything! It's an amazing job you are doing keeping all the balls in the air at once (juggling). Cheers, Steve W.
Re: -current amd64 packages not updated? Impatient or broken?
Steve Williams: > I hesitate to send this because perhaps I'm just too impatient, but then > again, perhaps not. This is not critical/time sensitive. > > I just thought I'd check if there a problem with the current packages folder > from the mirrors? No, the amd64 package builds have been slightly delayed. First by a problem in lang/rust, which semarie@ fixed in admirably short time. Then the package build was cut short because the machine running dpb(1) panicked with filesystem corruption. A new build is running now and will take another 24h to complete if all goes well. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: -current amd64 packages not updated? Impatient or broken?
Thanks for the correction! amit On Thu, Jan 7, 2021 at 11:59 AM Patrick Wildt wrote: > > No, that's not correct. The libc++ 11 (*not* LLVM 11) has not yet been > committed. This issue is because of libunwind 11. With libc++ 11 we > have made a separate ports build first, to check the fallout. Once the > fallout is mostly fixed, we'll do the switch to libc++ 11. Until then > snapshots are not harmed in anyway, apart from the libunwind update. > > Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni: > > Like naddy@ mentioned on ports@ they are trying to figure out the > > fallout from the switch to LLVM 11 as system compiler. This is why the > > packages are being delayed. Please wait a while till it is sorted out. > > > > thanks > > > > On Thu, Jan 7, 2021 at 10:56 AM Steve Williams > > wrote: > > > > > > Hi, > > > > > > I hesitate to send this because perhaps I'm just too impatient, but then > > > again, perhaps not. This is not critical/time sensitive. > > > > > > I just thought I'd check if there a problem with the current packages > > > folder from the mirrors? > > > > > > I am trying to update my development system (to resume work on a port). > > > > > > I did the initial upgrade on January 4, 2020 and my packages wouldn't > > > update because of missing library versions. I was told this is just a > > > discrepancy between the OS and the packages and to "wait a few days" for > > > everything to synchronize. > > > "Unfortunate timing as key system libraries have had version bumps > > > recently. Wait for a new package build (usually a few days on the faster > > > cpu architectures) and try again." > > > > > > I am watching the packages folder on various mirrors and they are all > > > from January 3, 2020, which is when my kernel is from. > > > pulseaudio-14.0.tgz03-Jan-2021 > > > > > > I am currently on: > > > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > > > > > This morning, I still can't add/update select packages. > > > > > > desktop# sysupgrade -s > > > Fetching from > > > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > > > SHA256.sig 100% > > > |***| > > > 2144 00:00 > > > Signature Verified > > > Already on latest snapshot. > > > desktop# pkg_add pulseaudio > > > quirks-3.506 signed on 2021-01-03T15:41:44Z > > > Can't install spidermonkey78-78.5.0v1 because of libraries > > > |library c++.5.0 not found > > > | /usr/lib/libc++.so.4.0 (system): bad major > > > | /usr/lib/libc++.so.6.0 (system): bad major > > > |library c++abi.3.0 not found > > > | /usr/lib/libc++abi.so.2.1 (system): bad major > > > | /usr/lib/libc++abi.so.4.0 (system): bad major > > > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > > > nspr-4.29 icu4c-68.2v0 > > > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > > > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > > > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > > > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > > > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > > > spidermonkey78-78.5.0v1 > > > desktop# > > > > > > Am I being too impatient? > > > > > > Thanks, > > > Steve Williams > > > > > > > > > > >
Re: -current amd64 packages not updated? Impatient or broken?
Impatient it is :D Thanks for the update! Cheers, Steve W. On 07/01/2021 10:56 a.m., Patrick Wildt wrote: I committed an update to libunwind which made a major bump necessary. Maybe I should have asked ports to run with the build first, so that base and packages would be aligned. Too late for that now. Time will fix it though. Am Thu, Jan 07, 2021 at 09:54:39AM -0700 schrieb Steve Williams: Hi, I hesitate to send this because perhaps I'm just too impatient, but then again, perhaps not. This is not critical/time sensitive. I just thought I'd check if there a problem with the current packages folder from the mirrors? I am trying to update my development system (to resume work on a port). I did the initial upgrade on January 4, 2020 and my packages wouldn't update because of missing library versions. I was told this is just a discrepancy between the OS and the packages and to "wait a few days" for everything to synchronize. "Unfortunate timing as key system libraries have had version bumps recently. Wait for a new package build (usually a few days on the faster cpu architectures) and try again." I am watching the packages folder on various mirrors and they are all from January 3, 2020, which is when my kernel is from. pulseaudio-14.0.tgz 03-Jan-2021 I am currently on: OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 This morning, I still can't add/update select packages. desktop# sysupgrade -s Fetching from https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ SHA256.sig 100% |***| 2144 00:00 Signature Verified Already on latest snapshot. desktop# pkg_add pulseaudio quirks-3.506 signed on 2021-01-03T15:41:44Z Can't install spidermonkey78-78.5.0v1 because of libraries |library c++.5.0 not found | /usr/lib/libc++.so.4.0 (system): bad major | /usr/lib/libc++.so.6.0 (system): bad major |library c++abi.3.0 not found | /usr/lib/libc++abi.so.2.1 (system): bad major | /usr/lib/libc++abi.so.4.0 (system): bad major Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 nspr-4.29 icu4c-68.2v0 Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 Can't install consolekit2-1.2.2: can't resolve polkit-0.118 Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 spidermonkey78-78.5.0v1 desktop# Am I being too impatient? Thanks, Steve Williams
Re: msdos partition is too small in arm64/miniroot68.img
On Thu, Jan 07, 2021 at 01:01:53PM +, tech-lists wrote: > On Wed, Jan 06, 2021 at 09:01:19PM +, a...@sdf.org wrote: > > [...method...] > > thanks for that, I'll let you know how I get on. I think your > problem with spontaneous crashes might be down to swapfile, > sdcard is unsuitable for this. I've had good results with > arm64/freebsd-current/swapfile on usb3 spinning rust/ > tmpdir on tmpfs. Very quick for what it is. This other rpi4 > will hopefully be a desktop replacement. Part of the reason > I'd like openbsd for this is for binary OS upgrades on this > platform. > -- > J. So after advising the list to put tmp on mfs, you think I'm using swap. In the sd card. Come on man!
Re: -current amd64 packages not updated? Impatient or broken?
Oh, and another correction: it's libc++ 10.0.1, we're not going 11 yet. Am Thu, Jan 07, 2021 at 06:59:52PM +0100 schrieb Patrick Wildt: > No, that's not correct. The libc++ 11 (*not* LLVM 11) has not yet been > committed. This issue is because of libunwind 11. With libc++ 11 we > have made a separate ports build first, to check the fallout. Once the > fallout is mostly fixed, we'll do the switch to libc++ 11. Until then > snapshots are not harmed in anyway, apart from the libunwind update. > > Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni: > > Like naddy@ mentioned on ports@ they are trying to figure out the > > fallout from the switch to LLVM 11 as system compiler. This is why the > > packages are being delayed. Please wait a while till it is sorted out. > > > > thanks > > > > On Thu, Jan 7, 2021 at 10:56 AM Steve Williams > > wrote: > > > > > > Hi, > > > > > > I hesitate to send this because perhaps I'm just too impatient, but then > > > again, perhaps not. This is not critical/time sensitive. > > > > > > I just thought I'd check if there a problem with the current packages > > > folder from the mirrors? > > > > > > I am trying to update my development system (to resume work on a port). > > > > > > I did the initial upgrade on January 4, 2020 and my packages wouldn't > > > update because of missing library versions. I was told this is just a > > > discrepancy between the OS and the packages and to "wait a few days" for > > > everything to synchronize. > > > "Unfortunate timing as key system libraries have had version bumps > > > recently. Wait for a new package build (usually a few days on the faster > > > cpu architectures) and try again." > > > > > > I am watching the packages folder on various mirrors and they are all > > > from January 3, 2020, which is when my kernel is from. > > > pulseaudio-14.0.tgz03-Jan-2021 > > > > > > I am currently on: > > > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > > > > > This morning, I still can't add/update select packages. > > > > > > desktop# sysupgrade -s > > > Fetching from > > > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > > > SHA256.sig 100% > > > |***| > > > 2144 00:00 > > > Signature Verified > > > Already on latest snapshot. > > > desktop# pkg_add pulseaudio > > > quirks-3.506 signed on 2021-01-03T15:41:44Z > > > Can't install spidermonkey78-78.5.0v1 because of libraries > > > |library c++.5.0 not found > > > | /usr/lib/libc++.so.4.0 (system): bad major > > > | /usr/lib/libc++.so.6.0 (system): bad major > > > |library c++abi.3.0 not found > > > | /usr/lib/libc++abi.so.2.1 (system): bad major > > > | /usr/lib/libc++abi.so.4.0 (system): bad major > > > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > > > nspr-4.29 icu4c-68.2v0 > > > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > > > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > > > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > > > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > > > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > > > spidermonkey78-78.5.0v1 > > > desktop# > > > > > > Am I being too impatient? > > > > > > Thanks, > > > Steve Williams > > > > > > > > > > > >
Re: -current amd64 packages not updated? Impatient or broken?
No, that's not correct. The libc++ 11 (*not* LLVM 11) has not yet been committed. This issue is because of libunwind 11. With libc++ 11 we have made a separate ports build first, to check the fallout. Once the fallout is mostly fixed, we'll do the switch to libc++ 11. Until then snapshots are not harmed in anyway, apart from the libunwind update. Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni: > Like naddy@ mentioned on ports@ they are trying to figure out the > fallout from the switch to LLVM 11 as system compiler. This is why the > packages are being delayed. Please wait a while till it is sorted out. > > thanks > > On Thu, Jan 7, 2021 at 10:56 AM Steve Williams > wrote: > > > > Hi, > > > > I hesitate to send this because perhaps I'm just too impatient, but then > > again, perhaps not. This is not critical/time sensitive. > > > > I just thought I'd check if there a problem with the current packages > > folder from the mirrors? > > > > I am trying to update my development system (to resume work on a port). > > > > I did the initial upgrade on January 4, 2020 and my packages wouldn't > > update because of missing library versions. I was told this is just a > > discrepancy between the OS and the packages and to "wait a few days" for > > everything to synchronize. > > "Unfortunate timing as key system libraries have had version bumps > > recently. Wait for a new package build (usually a few days on the faster > > cpu architectures) and try again." > > > > I am watching the packages folder on various mirrors and they are all > > from January 3, 2020, which is when my kernel is from. > > pulseaudio-14.0.tgz03-Jan-2021 > > > > I am currently on: > > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > > > This morning, I still can't add/update select packages. > > > > desktop# sysupgrade -s > > Fetching from > > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > > SHA256.sig 100% > > |***| > > 2144 00:00 > > Signature Verified > > Already on latest snapshot. > > desktop# pkg_add pulseaudio > > quirks-3.506 signed on 2021-01-03T15:41:44Z > > Can't install spidermonkey78-78.5.0v1 because of libraries > > |library c++.5.0 not found > > | /usr/lib/libc++.so.4.0 (system): bad major > > | /usr/lib/libc++.so.6.0 (system): bad major > > |library c++abi.3.0 not found > > | /usr/lib/libc++abi.so.2.1 (system): bad major > > | /usr/lib/libc++abi.so.4.0 (system): bad major > > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > > nspr-4.29 icu4c-68.2v0 > > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > > spidermonkey78-78.5.0v1 > > desktop# > > > > Am I being too impatient? > > > > Thanks, > > Steve Williams > > > > > > >
Re: msdos partition is too small in arm64/miniroot68.img
tech-lists wrote: > On Thu, Jan 07, 2021 at 09:55:28AM -0700, Theo de Raadt wrote: > >tech-lists wrote: > > > >> On Wed, Jan 06, 2021 at 09:25:01AM -0700, Theo de Raadt wrote: > >> >The miniroot is 33MB because it contains many install firmwares, and > >> >it is 97% full. > >> > > >> >I suggest you find another way of installing. > >> > > >> > >> Is there a technical (or some other reason I'm not seeing) why > >> miniroot68.fs > >> has been made as small as it is, and not some other size like 48MB, which > >> would allow the msdos partition to be made larger? > > > >Why 48MB? Why not 2GB? Why not make miniroot68.img be 2GB for download > >to satisfy some bizzare usage pattern? > > > >All media are created to be small, no larger than they need to be. > > OK I get it. The install requires an additional USB storage device. > > What I wanted to do was to write latest firmwares from > https://github.com/pftf/RPi4 as described in > OpenBSD/6.8/arm64/INSTALL.arm64 > into the (mdconfig-mounted) msdos partition of miniroot68.img prior to writing > it to the sdcard, as I didn't have an additional USB storage device. Modifying the miniroot is not a stock usage case. I firmly believe that INSTALL.arm64 text *should not exist*. Such special cases increase the messiness of using OpenBSD. > The latest firmwares (v1.22) unzip to 5.4MB but the msdos partition is only > 4.0MB. The firmware should be updated in the tree, and instructions encouraging people to do weird stuff should not exist. That is my take on this.
Re: -current amd64 packages not updated? Impatient or broken?
Like naddy@ mentioned on ports@ they are trying to figure out the fallout from the switch to LLVM 11 as system compiler. This is why the packages are being delayed. Please wait a while till it is sorted out. thanks On Thu, Jan 7, 2021 at 10:56 AM Steve Williams wrote: > > Hi, > > I hesitate to send this because perhaps I'm just too impatient, but then > again, perhaps not. This is not critical/time sensitive. > > I just thought I'd check if there a problem with the current packages > folder from the mirrors? > > I am trying to update my development system (to resume work on a port). > > I did the initial upgrade on January 4, 2020 and my packages wouldn't > update because of missing library versions. I was told this is just a > discrepancy between the OS and the packages and to "wait a few days" for > everything to synchronize. > "Unfortunate timing as key system libraries have had version bumps > recently. Wait for a new package build (usually a few days on the faster > cpu architectures) and try again." > > I am watching the packages folder on various mirrors and they are all > from January 3, 2020, which is when my kernel is from. > pulseaudio-14.0.tgz03-Jan-2021 > > I am currently on: > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > This morning, I still can't add/update select packages. > > desktop# sysupgrade -s > Fetching from > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > SHA256.sig 100% > |***| > 2144 00:00 > Signature Verified > Already on latest snapshot. > desktop# pkg_add pulseaudio > quirks-3.506 signed on 2021-01-03T15:41:44Z > Can't install spidermonkey78-78.5.0v1 because of libraries > |library c++.5.0 not found > | /usr/lib/libc++.so.4.0 (system): bad major > | /usr/lib/libc++.so.6.0 (system): bad major > |library c++abi.3.0 not found > | /usr/lib/libc++abi.so.2.1 (system): bad major > | /usr/lib/libc++abi.so.4.0 (system): bad major > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > nspr-4.29 icu4c-68.2v0 > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > spidermonkey78-78.5.0v1 > desktop# > > Am I being too impatient? > > Thanks, > Steve Williams > > >
Re: -current amd64 packages not updated? Impatient or broken?
I committed an update to libunwind which made a major bump necessary. Maybe I should have asked ports to run with the build first, so that base and packages would be aligned. Too late for that now. Time will fix it though. Am Thu, Jan 07, 2021 at 09:54:39AM -0700 schrieb Steve Williams: > Hi, > > I hesitate to send this because perhaps I'm just too impatient, but then > again, perhaps not. This is not critical/time sensitive. > > I just thought I'd check if there a problem with the current packages folder > from the mirrors? > > I am trying to update my development system (to resume work on a port). > > I did the initial upgrade on January 4, 2020 and my packages wouldn't update > because of missing library versions. I was told this is just a discrepancy > between the OS and the packages and to "wait a few days" for everything to > synchronize. > "Unfortunate timing as key system libraries have had version bumps > recently. Wait for a new package build (usually a few days on the faster cpu > architectures) and try again." > > I am watching the packages folder on various mirrors and they are all from > January 3, 2020, which is when my kernel is from. > pulseaudio-14.0.tgz 03-Jan-2021 > > I am currently on: > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > This morning, I still can't add/update select packages. > > desktop# sysupgrade -s > Fetching from > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > SHA256.sig 100% > |***| > 2144 00:00 > Signature Verified > Already on latest snapshot. > desktop# pkg_add pulseaudio > quirks-3.506 signed on 2021-01-03T15:41:44Z > Can't install spidermonkey78-78.5.0v1 because of libraries > |library c++.5.0 not found > | /usr/lib/libc++.so.4.0 (system): bad major > | /usr/lib/libc++.so.6.0 (system): bad major > |library c++abi.3.0 not found > | /usr/lib/libc++abi.so.2.1 (system): bad major > | /usr/lib/libc++abi.so.4.0 (system): bad major > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > nspr-4.29 icu4c-68.2v0 > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > spidermonkey78-78.5.0v1 > desktop# > > Am I being too impatient? > > Thanks, > Steve Williams > > >
Re: msdos partition is too small in arm64/miniroot68.img
On Thu, Jan 07, 2021 at 09:55:28AM -0700, Theo de Raadt wrote: tech-lists wrote: On Wed, Jan 06, 2021 at 09:25:01AM -0700, Theo de Raadt wrote: >The miniroot is 33MB because it contains many install firmwares, and >it is 97% full. > >I suggest you find another way of installing. > Is there a technical (or some other reason I'm not seeing) why miniroot68.fs has been made as small as it is, and not some other size like 48MB, which would allow the msdos partition to be made larger? Why 48MB? Why not 2GB? Why not make miniroot68.img be 2GB for download to satisfy some bizzare usage pattern? All media are created to be small, no larger than they need to be. OK I get it. The install requires an additional USB storage device. What I wanted to do was to write latest firmwares from https://github.com/pftf/RPi4 as described in OpenBSD/6.8/arm64/INSTALL.arm64 into the (mdconfig-mounted) msdos partition of miniroot68.img prior to writing it to the sdcard, as I didn't have an additional USB storage device. The latest firmwares (v1.22) unzip to 5.4MB but the msdos partition is only 4.0MB. thanks, -- J. signature.asc Description: PGP signature
Re: msdos partition is too small in arm64/miniroot68.img
tech-lists wrote: > On Wed, Jan 06, 2021 at 09:25:01AM -0700, Theo de Raadt wrote: > >The miniroot is 33MB because it contains many install firmwares, and > >it is 97% full. > > > >I suggest you find another way of installing. > > > > Is there a technical (or some other reason I'm not seeing) why miniroot68.fs > has been made as small as it is, and not some other size like 48MB, which > would allow the msdos partition to be made larger? Why 48MB? Why not 2GB? Why not make miniroot68.img be 2GB for download to satisfy some bizzare usage pattern? All media are created to be small, no larger than they need to be.
-current amd64 packages not updated? Impatient or broken?
Hi, I hesitate to send this because perhaps I'm just too impatient, but then again, perhaps not. This is not critical/time sensitive. I just thought I'd check if there a problem with the current packages folder from the mirrors? I am trying to update my development system (to resume work on a port). I did the initial upgrade on January 4, 2020 and my packages wouldn't update because of missing library versions. I was told this is just a discrepancy between the OS and the packages and to "wait a few days" for everything to synchronize. "Unfortunate timing as key system libraries have had version bumps recently. Wait for a new package build (usually a few days on the faster cpu architectures) and try again." I am watching the packages folder on various mirrors and they are all from January 3, 2020, which is when my kernel is from. pulseaudio-14.0.tgz 03-Jan-2021 I am currently on: OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 This morning, I still can't add/update select packages. desktop# sysupgrade -s Fetching from https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ SHA256.sig 100% |***| 2144 00:00 Signature Verified Already on latest snapshot. desktop# pkg_add pulseaudio quirks-3.506 signed on 2021-01-03T15:41:44Z Can't install spidermonkey78-78.5.0v1 because of libraries |library c++.5.0 not found | /usr/lib/libc++.so.4.0 (system): bad major | /usr/lib/libc++.so.6.0 (system): bad major |library c++abi.3.0 not found | /usr/lib/libc++abi.so.2.1 (system): bad major | /usr/lib/libc++abi.so.4.0 (system): bad major Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 nspr-4.29 icu4c-68.2v0 Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 Can't install consolekit2-1.2.2: can't resolve polkit-0.118 Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 spidermonkey78-78.5.0v1 desktop# Am I being too impatient? Thanks, Steve Williams
Re: msdos partition is too small in arm64/miniroot68.img
Christer Solskogen wrote: > On Wed, Jan 6, 2021 at 5:39 PM Theo de Raadt wrote: > > The miniroot is 33MB because it contains many install firmwares, and > it is 97% full. > > True, but the miniroot has space available to expand the msdos partition. The miniroot has two filesystems. a is UFS and 97% full i is msdos and 93% full. We build all miniroots as small as possible. Can this conversation backtrack please: Explain why you think the filesystems need to be larger.
Re: msdos partition is too small in arm64/miniroot68.img
On Thu, Jan 07, 2021 at 02:20:54PM +, a...@sdf.org wrote: On Thu, Jan 07, 2021 at 01:01:53PM +, tech-lists wrote: On Wed, Jan 06, 2021 at 09:01:19PM +, a...@sdf.org wrote: [...method...] thanks for that, I'll let you know how I get on. I think your problem with spontaneous crashes might be down to swapfile, sdcard is unsuitable for this. I've had good results with arm64/freebsd-current/swapfile on usb3 spinning rust/ tmpdir on tmpfs. Very quick for what it is. This other rpi4 will hopefully be a desktop replacement. Part of the reason I'd like openbsd for this is for binary OS upgrades on this platform. -- J. So after advising the list to put tmp on mfs, you think I'm using swap. In the sd card. Come on man! ;) (in mitigation, I didn't want to presume). Also, I don't know what openbsd actually has in this context, as I've not got to the install stage yet. It's just that I found similar random crashes with raspios, and that *did* have a swapfile. I'm not sure how it's mounted or how it works in the raspios context, other than "it is a swapfile". -- J. signature.asc Description: PGP signature
Re: Bug in pkgtools version parsing logic?
On Wed, Jan 6, 2021, at 17:16, Jeremy O'Brien wrote:
> Hi there,
>
> I'm looking through the pkgtools code to determine how the version
> comparison logic works, and I came across this block of code at
> /usr/libdata/perl5/OpenBSD/PackageName.pm:385:
>
> sub from_string
> {
> my ($class, $string) = @_;
> my $o = bless { deweys => [ split(/\./o, $string) ],
> suffix => '', suffix_value => 0}, $class;
> if ($o->{deweys}->[-1] =~ m/^(\d+)(rc|alpha|beta|pre|pl)(\d*)$/) {
> $o->{deweys}->[-1] = $1;
> $o->{suffix} = $2;
> $o->{suffix_value} = $3;
> }
> return $o;
> }
>
> From what I understand, this is looking for one of OpenBSD "special"
> suffixes for a given version part of a package version. This code seems
> to only match cases where the "special" portion (rc, alpha, beta etc)
> of the version sits between a required decimal on the left and an
> optional decimal on the right. Looking through the current package
> listing, I found this one:
>
> clementine-1.4.0rc1p0.tgz
>
> Given the above regex, the rc1 portion of the package name will not be
> pulled into the suffix, and I believe that (given a comparison where
> the 1.4.0 portion of the version doesn't change) a future version
> comparison with this package version will potentially be done
> alphabetically?
>
> Is this intentional? Or perhaps I'm missing something here or elsewhere
> with this code.
>
> Thank you,
> Jeremy
>
>
Nevermind; I found where the hole in my logic was:
OpenBSD::PackageName::version handles the p/v cases. Sorry for the noise!
Re: msdos partition is too small in arm64/miniroot68.img
On Wed, Jan 06, 2021 at 09:01:19PM +, a...@sdf.org wrote: [...method...] thanks for that, I'll let you know how I get on. I think your problem with spontaneous crashes might be down to swapfile, sdcard is unsuitable for this. I've had good results with arm64/freebsd-current/swapfile on usb3 spinning rust/ tmpdir on tmpfs. Very quick for what it is. This other rpi4 will hopefully be a desktop replacement. Part of the reason I'd like openbsd for this is for binary OS upgrades on this platform. -- J. signature.asc Description: PGP signature
Re: msdos partition is too small in arm64/miniroot68.img
On Wed, Jan 06, 2021 at 09:25:01AM -0700, Theo de Raadt wrote: The miniroot is 33MB because it contains many install firmwares, and it is 97% full. I suggest you find another way of installing. Is there a technical (or some other reason I'm not seeing) why miniroot68.fs has been made as small as it is, and not some other size like 48MB, which would allow the msdos partition to be made larger? thanks, -- J. signature.asc Description: PGP signature
Re: npppd - problem with simultaneous sessions
Hi,
> It seems that only last person can use the tunnel. This reminds me
> problems through NAT.
True. Can it be caused by wrong PF rules?
> Both sessions seem to be connected from A.B.C.D. Are the clients
> behind a NAT?
Yes, both client are behind the same router/NAT.
I have a 66/i386 box running npppd on producion and my two clients can be
connected the same time flawlessly.
> How about the npppd side? Does the client directly connect to
>
> > tunnel L2TP protocol l2tp {
> > listen on X.Y.Z.13
> > }
>
> X.Y.Z.13 ? Or a NAT is there?
It is directly connected do X.Y.Z.13, no NAT.
On Thu, 07 Jan 2021 16:27:57 +0900 (JST)
YASUOKA Masahiko wrote:
> Hi,
>
> On Wed, 6 Jan 2021 21:33:49 +0100
> Radek wrote:
> > I have a box with relatively fresh install of 68/amd64, fully
> > syspatched. There is a npppd server running on it. The problem is
> > that I can have only one nppp session at one time. If the second
> > vpn user connects the box, the first nppp session hangs/drops. I
> > probably have missed something obvious in my setup but I really
> > can't find what it is.
>
> It seems that only last person can use the tunnel. This reminds me
> problems through NAT.
>
> > Jan 6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base
> > logtype=TUNNELSTART user="rdk" duration=1sec layer2=L2TP
> > layer2from=A.B.C.D:1701 auth=MS-CHAP-V2 ip=10.109.4.1 iface=pppx0
>
> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=base
> > logtype=TUNNELSTART user="rdk-test" duration=1sec layer2=L2TP
> > layer2from=A.B.C.D:1701 auth=MS-CHAP-V2 ip=10.109.4.11 iface=pppx0
>
> Both sessions seem to be connected from A.B.C.D. Are the clients
> behind a NAT?
>
> How about the npppd side? Does the client directly connect to
>
> > tunnel L2TP protocol l2tp {
> > listen on X.Y.Z.13
> > }
>
> X.Y.Z.13 ? Or a NAT is there?
>
> On Wed, 6 Jan 2021 21:33:49 +0100
> Radek wrote:
> > Hi @misc,
> >
> > I have a box with relatively fresh install of 68/amd64, fully
> > syspatched. There is a npppd server running on it. The problem is
> > that I can have only one nppp session at one time. If the second
> > vpn user connects the box, the first nppp session hangs/drops. I
> > probably have missed something obvious in my setup but I really
> > can't find what it is.
> >
> > Please help me to solve the problem.
> > Thank you.
> >
> > $cat /etc/npppd/npppd.conf
> > authentication LOCAL type local {
> > users-file "/etc/npppd/npppd-users"
> > }
> > tunnel L2TP protocol l2tp {
> > listen on X.Y.Z.13
> > }
> > ipcp IPCP {
> > pool-address 10.109.4.1-10.109.4.32
> > dns-servers 1.1.1.1
> > }
> > # use pppx(4) interface. use an interface per a ppp session.
> > interface pppx0 address 10.109.4.254 ipcp IPCP
> > bind tunnel from L2TP authenticated by LOCAL to pppx0
> >
> > $cat /etc/hostname.enc0
> > up
> >
> >
> > $cat /etc/sysctl.conf
> > net.inet.ip.forwarding=1
> > net.inet.ipcomp.enable=1
> > net.inet.esp.enable=1
> > net.inet.gre.allow=1
> > net.pipex.enable=1
> >
> > $cat /etc/rc.conf.local
> > ipsec=YES
> > ipsec_rules=/etc/ipsec.conf
> > isakmpd_flags="-K"
> > npppd_flags=""
> >
> > $cat /etc/ipsec.conf
> > wan_ipv4 = X.Y.Z.13
> > ike passive esp transport \
> > proto udp from $wan_ipv4 to any port 1701 \
> > main auth "hmac-sha1" enc "3des" group modp1024 \
> > quick auth "hmac-sha1" enc "aes" group modp1024 \
> > psk "pskpskpsk"
> >
> > $cat /etc/pf.conf
> > [...]
> > vpn_if = "pppx"
> > vpn_local = "10.109.4.0/24"
> >
> > pass in on $ext_if proto udp from any to (egress:0) port
> > {isakmp,ipsec-nat-t,l2tp}
> > pass in on $ext_if proto {ah,esp}
> > pass log proto { gre } from any to any keep state
> >
> > # filter all IPSec traffic on the enc interface
> > pass on enc0 keep state (if-bound)
> >
> > # allow all trafic in on and out to the VPN network
> > pass on $vpn_if from $vpn_local
> > pass on $vpn_if to $vpn_local
> >
> > # NAT VPN traffic going out on the public interface with the public
> > IP
> > match out log on $ext_if inet proto { tcp, udp, icmp } from
> > $vpn_local nat-to ($ext_if) set prio (3,7)
> >
> > some logs...
> >
> > Jan 6 20:53:14 fw-u last message repeated 4 times
> > Jan 6 20:53:16 fw-u isakmpd[11638]: attribute_unacceptable:
> > ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
> > Jan 6 20:53:16 fw-u last message repeated 2 times
> > Jan 6 20:53:16 fw-u isakmpd[11638]: attribute_unacceptable:
> > GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
> > Jan 6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 logtype=Started
> > RecvSCCRQ from=A.B.C.D:1701/udp tunnel_id=1/26 protocol=1.0
> > winsize=8 hostname=w520 vendor=Microsoft firm=0601
> > Jan 6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 SendSCCRP
> > Jan 6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 RecvSCCN
> > Jan 6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 SendZLB
> > Jan 6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 RecvZLB
> > Jan 6 20:53:16 fw-u npppd[82720]:
