Re: pkg_add - error while reading header / read short file / gzheader truncated
On Sat, 2023-12-09 at 11:55 +, Stuart Henderson wrote: > I suggest trying a mirror instead then, and see if there's any > difference. Pick one from www.openbsd.org/ftp.html. Good suggestion. Recent installer changes to simplify the sets "disk" option are awesome. At the same time, this likely increased the number of installations configured for cdn.openbsd.org (and maybe load on the server).
Re: pkg_add - error while reading header / read short file / gzheader truncated
On 2023/12/08 15:40, David Rinehart wrote: > On Fri, 2023-12-08 at 08:37 +, Stuart Henderson wrote: > > On 2023-12-07, David Rinehart wrote: > > > > > > I see the same with multiple installs - Started with 7.4. No > > > modification to default installurl. > > > > The contents of the 'default' installurl depend on whuch mirror you > > selected to install from. > > > > I select "disk" for file sets and do not recall selecting a mirror. I > believe this puts https://cdn.openbsd.org/pub/OpenBSD in the file. > > The issue may have started before 7.4, but was not seen at 7.3 release > timeframe. > > After giving it more thought, I believe I started seeing errors on > package installation before 7.4 release. I figured it was a web site > issue because I'm running -stable and no patches seemed related (so > more likely an external issue). Then, the errors were familiar when I > did reinstalls with 7.4. The errors are temporary and the package > installations will complete if run again, or maybe a couple times. > > Thanks, for the reply and any help! I suggest trying a mirror instead then, and see if there's any difference. Pick one from www.openbsd.org/ftp.html.
Re: pkg_add - error while reading header / read short file / gzheader truncated
On Fri, 2023-12-08 at 08:37 +, Stuart Henderson wrote: > On 2023-12-07, David Rinehart wrote: > > > > I see the same with multiple installs - Started with 7.4. No > > modification to default installurl. > > The contents of the 'default' installurl depend on whuch mirror you > selected to install from. > I select "disk" for file sets and do not recall selecting a mirror. I believe this puts https://cdn.openbsd.org/pub/OpenBSD in the file. The issue may have started before 7.4, but was not seen at 7.3 release timeframe. After giving it more thought, I believe I started seeing errors on package installation before 7.4 release. I figured it was a web site issue because I'm running -stable and no patches seemed related (so more likely an external issue). Then, the errors were familiar when I did reinstalls with 7.4. The errors are temporary and the package installations will complete if run again, or maybe a couple times. Thanks, for the reply and any help! -- David Rinehart
Re: pkg_add - error while reading header / read short file / gzheader truncated
On 2023-12-07, David Rinehart wrote: > > I see the same with multiple installs - Started with 7.4. No > modification to default installurl. The contents of the 'default' installurl depend on whuch mirror you selected to install from.
Re: pkg_add - error while reading header / read short file / gzheader truncated
I see the same with multiple installs - Started with 7.4. No modification to default installurl. It is amazing - For 5 years, I never considered that pkg_add(1) could fail (and it didn't)! Updating my install scripts to try until the last package add, with -l option, is confirmed. A little concerned that a package could be partially installed / marked manual and not work (I think this has happened and I restarted from scratch). On Thu, 2023-12-07 at 00:07 -0800, Joe B wrote: > Hello Misc, > > I am configuring a couple of laptops for my kids, i had installed 70 > with > i3 and gcompris in them, its been a while since the last update so i > decided to make a fresh install. > > So I installed 74 in both of them, used the autoinstall so the > process was > straightforward as always, rebooted, hw_update, syspatch, everything > as > expected. > > The problem comes when trying to install a package, i am trying just > to of > them: feh and gcompris, in both laptops, and i get the following > errors, > they are several since i do a few tries and then the problem goes and > comes > at different packages > > pkg_add: Ustar [package name, it is different every try, meaning > lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header > https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz > : > Read short file > > My configuration are: > 1 laptop, re0, trying pkg_add feh > 1 laptop, iwn0, trying pkg_add gcompris > > both with the same results, maybe i should try in another LAN, but > could it > be a problem with the CDN server ? > > Thank you for your time, > > -- Manuel Solis > > > > > > Hello, > > I'm new to openBSD about 3 days old. and I ran into the same issue as > you. I would > > pkg_add something and I kept getting the header message. someone on > IRC helped me > > Simple. change the cdn to another mirror > > look at https://www.openbsd.org/faq/faq15.html#Mirror > > Basically You find a mirror probably ftp like I did go to vim or nano > /etc/installurl > > delete the cdn add another mirror and re-run the pkg_add you might > need to pkg_delete > > the partial and then re-run. pkg_add After all that you might need > pkg_add -u to see if the new mirror > > fixes all the other partials > > > Hope this helps > > > ~ Joe B
Re: pkg_add - error while reading header / read short file / gzheader truncated
On Thu, Dec 07, 2023 at 12:35:01PM -, Stuart Henderson wrote: > pkg_add/ftp aren't good at retrying when network connections fail. > I'd think it's more likely a problem with your network connection > than the cdn server, but you could try one of the other mirrors > listed in www.openbsd.org/ftp.html (either set in /etc/installurl > or set in the PKG_PATH environment variable; you can just use the > hostname in the latter) Read the previous email carefully, paying attention to the bizarre quoting style... The person you replied to was actually answering the original question :-).
Re: pkg_add - error while reading header / read short file / gzheader truncated
On 2023-12-07, Joe B wrote: > Hello Misc, > > I am configuring a couple of laptops for my kids, i had installed 70 with > i3 and gcompris in them, its been a while since the last update so i > decided to make a fresh install. > > So I installed 74 in both of them, used the autoinstall so the process was > straightforward as always, rebooted, hw_update, syspatch, everything as > expected. > > The problem comes when trying to install a package, i am trying just to of > them: feh and gcompris, in both laptops, and i get the following errors, > they are several since i do a few tries and then the problem goes and comes > at different packages > > pkg_add: Ustar [package name, it is different every try, meaning > lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header > https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz: > Read short file > > My configuration are: > 1 laptop, re0, trying pkg_add feh > 1 laptop, iwn0, trying pkg_add gcompris > > both with the same results, maybe i should try in another LAN, but could it > be a problem with the CDN server ? pkg_add/ftp aren't good at retrying when network connections fail. I'd think it's more likely a problem with your network connection than the cdn server, but you could try one of the other mirrors listed in www.openbsd.org/ftp.html (either set in /etc/installurl or set in the PKG_PATH environment variable; you can just use the hostname in the latter) > Thank you for your time, > > -- Manuel Solis > >>> > > Hello, > > I'm new to openBSD about 3 days old. and I ran into the same issue as > you. I would > > pkg_add something and I kept getting the header message. someone on > IRC helped me > > Simple. change the cdn to another mirror > > look at https://www.openbsd.org/faq/faq15.html#Mirror > > Basically You find a mirror probably ftp like I did go to vim or nano > /etc/installurl > > delete the cdn add another mirror and re-run the pkg_add you might > need to pkg_delete > > the partial and then re-run. pkg_add After all that you might need > pkg_add -u to see if the new mirror > > fixes all the other partials > > > Hope this helps > > > ~ Joe B > -- Please keep replies on the mailing list.
pkg_add - error while reading header / read short file / gzheader truncated
Hello Misc, I am configuring a couple of laptops for my kids, i had installed 70 with i3 and gcompris in them, its been a while since the last update so i decided to make a fresh install. So I installed 74 in both of them, used the autoinstall so the process was straightforward as always, rebooted, hw_update, syspatch, everything as expected. The problem comes when trying to install a package, i am trying just to of them: feh and gcompris, in both laptops, and i get the following errors, they are several since i do a few tries and then the problem goes and comes at different packages pkg_add: Ustar [package name, it is different every try, meaning lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz: Read short file My configuration are: 1 laptop, re0, trying pkg_add feh 1 laptop, iwn0, trying pkg_add gcompris both with the same results, maybe i should try in another LAN, but could it be a problem with the CDN server ? Thank you for your time, -- Manuel Solis >> Hello, I'm new to openBSD about 3 days old. and I ran into the same issue as you. I would pkg_add something and I kept getting the header message. someone on IRC helped me Simple. change the cdn to another mirror look at https://www.openbsd.org/faq/faq15.html#Mirror Basically You find a mirror probably ftp like I did go to vim or nano /etc/installurl delete the cdn add another mirror and re-run the pkg_add you might need to pkg_delete the partial and then re-run. pkg_add After all that you might need pkg_add -u to see if the new mirror fixes all the other partials Hope this helps ~ Joe B
pkg_add - error while reading header / read short file / gzheader truncated
Hello Misc, I am configuring a couple of laptops for my kids, i had installed 70 with i3 and gcompris in them, its been a while since the last update so i decided to make a fresh install. So I installed 74 in both of them, used the autoinstall so the process was straightforward as always, rebooted, hw_update, syspatch, everything as expected. The problem comes when trying to install a package, i am trying just to of them: feh and gcompris, in both laptops, and i get the following errors, they are several since i do a few tries and then the problem goes and comes at different packages pkg_add: Ustar [package name, it is different every try, meaning lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz: Read short file My configuration are: 1 laptop, re0, trying pkg_add feh 1 laptop, iwn0, trying pkg_add gcompris both with the same results, maybe i should try in another LAN, but could it be a problem with the CDN server ? Thank you for your time, -- Manuel Solis
Re: pkg_add -vV slow progression
On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote: > Hello, > > Is there any recent major change in base packages or pkg_add? > I ask because the pkg_add -vV is slower than usual at each package, > most of the time spent in Extracting ... phase. > I use amd64 recent snapshot. I checked my disk and https downloads, > they are fine. No major change, but fs got simplified recently.
Re: pkg_add -vV slow progression
On Mon, Sep 18, 2023 at 7:09 PM Otto Moerbeek wrote: > > On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote: > > > Hello, > > > > Is there any recent major change in base packages or pkg_add? > > I ask because the pkg_add -vV is slower than usual at each package, > > most of the time spent in Extracting ... phase. > > I use amd64 recent snapshot. I checked my disk and https downloads, > > they are fine. > > > > Thank you. > > > > Maybe the switching off of softdep? But that's been a while already, > and you don't say if had that enabled. > > -Otto No softdep enabled! I will try another mirror next time, like Stuart said. I checked that mirror with a plain download inside a browser, it was fine, maybe things go bad after some repetitive downloads, I had this before. Thanks.
Re: pkg_add -vV slow progression
On 2023-09-18, Otto Moerbeek wrote: > On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote: > >> Hello, >> >> Is there any recent major change in base packages or pkg_add? >> I ask because the pkg_add -vV is slower than usual at each package, >> most of the time spent in Extracting ... phase. >> I use amd64 recent snapshot. I checked my disk and https downloads, >> they are fine. >> >> Thank you. >> > > Maybe the switching off of softdep? But that's been a while already, > and you don't say if had that enabled. Does it make a difference if you use a different mirror? -- Please keep replies on the mailing list.
Re: pkg_add -vV slow progression
On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote: > Hello, > > Is there any recent major change in base packages or pkg_add? > I ask because the pkg_add -vV is slower than usual at each package, > most of the time spent in Extracting ... phase. > I use amd64 recent snapshot. I checked my disk and https downloads, > they are fine. > > Thank you. > Maybe the switching off of softdep? But that's been a while already, and you don't say if had that enabled. -Otto
pkg_add -vV slow progression
Hello, Is there any recent major change in base packages or pkg_add? I ask because the pkg_add -vV is slower than usual at each package, most of the time spent in Extracting ... phase. I use amd64 recent snapshot. I checked my disk and https downloads, they are fine. Thank you.
Re: pkg_add -u
> Hello > > i did an upgrade from 7.1 to 7.2, everything went well, but, i did an > upgrade from 7.2 to 7.3 and then i got this message: > > ListUtil.c: loadable library and perl binaries are mismatched (got first > handshake key 0xec0, needed 0xeb8) > > The procedure for both upgrades was: > > # sysupgrade > # syspatch > # pkg_add -u > > What is wrong, and how to repair it please? > > Thanks. > > Ops i found the answer at misc archives: https://marc.info/?l=openbsd-misc=163762126127301=2 The point is that the server had a previous Administration, and then i did not know that there are some extraneous packages installed. I appreciate any other opinion. Thanks.
pkg_add -u
Hello i did an upgrade from 7.1 to 7.2, everything went well, but, i did an upgrade from 7.2 to 7.3 and then i got this message: ListUtil.c: loadable library and perl binaries are mismatched (got first handshake key 0xec0, needed 0xeb8) The procedure for both upgrades was: # sysupgrade # syspatch # pkg_add -u What is wrong, and how to repair it please? Thanks.
Re: `pkg_add -u` and caching
On Sun, Jul 9, 2023 at 11:11 Morgan Aldridge wrote: > Hi misc@ and Marc, > > I have a script for applying all updates/upgrades for upgrading my OpenBSD > workstation, dev machines, and servers. I'm currently in the process of > improving it to better support downloading pending updates in advance of > actual review and installation (see < > https://github.com/morgant/swupdate-openbsd/issues/14>. I've been > studying the pkg_add(1) manual, testing, and also reviewing the pkg_add > Perl source in src/usr.sbin/pkg_add/OpenBSD/, but while really well > structured and easy to read, the latter does take me longer to grok than > the former. > > I'm hoping you have a quick answer (even if it's 'no') to the following > question: Does `pkg_add -u` utilize PKG_CACHE other than with the `-n` > option? > > In my testing (on amd64/7.3-stable), the following will check for updates > and copy packages to `PKG_CACHE`, as described in pkg_add(1): > > PKG_CACHE=/home/_swupdate/7.3/packages/amd64 pkg_add -nu > > If I delete a cached package from the PKG_CACHE directory, re-executing > the above command will redownload the package. That's what I was hoping > for. I'm not quite sure whether some of the packages are being > re-downloaded by just looking at file modification dates (unfortunately, > `-v` doesn't note downloads, nor cache mis/hit.) > > The following seems to try to update packages from PKG_CACHE, if passed in > as PKG_PATH, but -- understandably -- does result in errors that some > packages (those that didn't need updates or have dependencies that did) > could not be found: > > PKG_PATH=/home/_swupdate/7.3/packages/amd64 pkg_add -u > > Naturally, if I append ':installpath' to the above PKG_PATH, it will not > give such errors: > > PKG_PATH=/home/_swupdate/7.3/packages/amd64:installpath pkg_add -u > > However, since '-v' also doesn't note which package repository (esp. > local or not) a package was processed from, I don't know whether it's > actually preferring the local repository. > > Additionally, if I set both PKG_CACHE and PKG_PATH to `pkg_add -u`, it > doesn't appear that packages are downloaded to PKG_CACHE: > > PKG_CACHE=/home/_swupdate/7.3/packages/amd64 > /home/_swupdate/7.3/packages/amd64 > pkg_add -u > Typo. The above command should have been: PKG_CACHE=/home/_swupdate/7.3/packages/amd64 \ PKG_PATH=/home/_swupdate/7.3/packages/amd64 \ pkg_add -u This is confirmed by deleting a package from PKG_CACHE and re-executing the > above, after which the deleted package is still missing from PKG_CACHE. Of > course, this absolutely feels sketchy to be caching to a package > repository, but was worth a try. > Thanks in advance and please CC me if replying to the list as I'm not subscribed to misc@. Morgan > -- Morgan --- http://makkintosshu.com/ https://centresteer.com/ https://tobuji.tech/ http://unna.org/
`pkg_add -u` and caching
Hi misc@ and Marc, I have a script for applying all updates/upgrades for upgrading my OpenBSD workstation, dev machines, and servers. I'm currently in the process of improving it to better support downloading pending updates in advance of actual review and installation (see < https://github.com/morgant/swupdate-openbsd/issues/14>. I've been studying the pkg_add(1) manual, testing, and also reviewing the pkg_add Perl source in src/usr.sbin/pkg_add/OpenBSD/, but while really well structured and easy to read, the latter does take me longer to grok than the former. I'm hoping you have a quick answer (even if it's 'no') to the following question: Does `pkg_add -u` utilize PKG_CACHE other than with the `-n` option? In my testing (on amd64/7.3-stable), the following will check for updates and copy packages to `PKG_CACHE`, as described in pkg_add(1): PKG_CACHE=/home/_swupdate/7.3/packages/amd64 pkg_add -nu If I delete a cached package from the PKG_CACHE directory, re-executing the above command will redownload the package. That's what I was hoping for. I'm not quite sure whether some of the packages are being re-downloaded by just looking at file modification dates (unfortunately, `-v` doesn't note downloads, nor cache mis/hit.) The following seems to try to update packages from PKG_CACHE, if passed in as PKG_PATH, but -- understandably -- does result in errors that some packages (those that didn't need updates or have dependencies that did) could not be found: PKG_PATH=/home/_swupdate/7.3/packages/amd64 pkg_add -u Naturally, if I append ':installpath' to the above PKG_PATH, it will not give such errors: PKG_PATH=/home/_swupdate/7.3/packages/amd64:installpath pkg_add -u However, since '-v' also doesn't note which package repository (esp. local or not) a package was processed from, I don't know whether it's actually preferring the local repository. Additionally, if I set both PKG_CACHE and PKG_PATH to `pkg_add -u`, it doesn't appear that packages are downloaded to PKG_CACHE: PKG_CACHE=/home/_swupdate/7.3/packages/amd64 /home/_swupdate/7.3/packages/amd64 pkg_add -u This is confirmed by deleting a package from PKG_CACHE and re-executing the above, after which the deleted package is still missing from PKG_CACHE. Of course, this absolutely feels sketchy to be caching to a package repository, but was worth a try. Thanks in advance, Morgan -- Morgan --- http://makkintosshu.com/ https://centresteer.com/ https://tobuji.tech/ http://unna.org/
pkg_add: Can't locate object method "new" via package "OpenBSD::PackingList::Depend"
Hi, looks like after recent changes in -current pkg_add become broken: $ pkg_add -n scapy quirks-6.130 signed on 2023-05-16T19:13:11Z scapy-2.4.4p4:py3-cparser-2.21: ok pkg_add: Can't locate object method "new" via package "OpenBSD::PackingList::Depend" (perhaps you forgot to load "OpenBSD::PackingList::Depend"?) Is it known issue? OpenBSD 7.3-current (GENERIC.MP) #1185: Wed May 17 08:26:47 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Re: Pkg_add Python version and LibreSSL seem to be incompatible in OpenBSD 7.3
On 2023-05-14, Judah Kocher wrote: > Some web searching has not turned up any details around this. I also do > not see python 3.9 as an installable option via pkg_add, just 3.10 and > 3.11. 3.9 is still there. > Does this mean that installing python via pkg_add installs a > python version that is incompatible with LibreSSL? 3.10 from packages works well with LibreSSL. There are some small local patches to disable a couple of things which aren't supported and are not at all widely used. Python's policy for 3.10+ is essentially "don't go out of the way to prevent running it with LibreSSL, but don't jump through hoops to make it work". urllib3 is going beyond that and explicitly checking for OpenSSL 1.1.1+ and refusing to run otherwise (including on 3.7-3.9 for which urllib3 claims support). >When I look at the > info for the OpenSSL package it includes this warning: > > This package is not intended for general-purpose use in OpenBSD - it > is present for test/comparison purposes, and occasionally to provide > support for applications which cannot be made compatible with LibreSSL > (mostly due to use of removed APIs); in the latter case care must be > taken - it will conflict if library dependencies use LibreSSL libraries. Essentially: if we built Python using OpenSSL instead of LibreSSL, things would break for any compiled modules linked to libraries which themselves link to LibreSSL's libssl/libcrypto - e.g. including things like py-curl, py-ldap, py-psycopg2, ...) > What would be the best way to resolve this issue? I would guess that > plenty of others are using python with OpenBSD so there must be a > recommended resolution, but I have not found it documented anywhere yet. I'd suggest installing urllib3 from OpenBSD packages instead. If you have some particular requirement to install some version via pip instead, pin to an older (pre 2.x) urllib3 for now. urllib3 seem to be considering relaxing this again (possibly largely thanks to Apple widely distributing a libressl-linked version of Python), https://github.com/urllib3/urllib3/issues/3020#issuecomment-1541523700) - I think that would be the right thing for them to do.
Re: Pkg_add Python version and LibreSSL seem to be incompatible in OpenBSD 7.3
Thank you Otto! pip install urllib3==1.26.15 replaced the v2 version with the latest non v2 version, and now my scripts work again. On 5/14/23 14:34, Otto Moerbeek wrote: On Sun, May 14, 2023 at 12:25:28PM -0400, Judah Kocher wrote: After updating one of my routers to OpenBSD 7.3, my python scripts that update various public DNS records when my public IP changes started failing with generic segfaults. I did see the note in the OpenBSD Upgrade Guide about 3.10 being the new default so I ran pkg_add -u which updated python to 3.10 and now the same scripts fail but with this error: ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with LibreSSL 3.7.2. See: https://github.com/urllib3/urllib3/issues/2168 The included github link mentions that older versions of SSL are no longer usable with the urllib library but makes no mention of LibreSSL. Some web searching has not turned up any details around this. I also do not see python 3.9 as an installable option via pkg_add, just 3.10 and 3.11. Does this mean that installing python via pkg_add installs a python version that is incompatible with LibreSSL? When I look at the info for the OpenSSL package it includes this warning: This package is not intended for general-purpose use in OpenBSD - it is present for test/comparison purposes, and occasionally to provide support for applications which cannot be made compatible with LibreSSL (mostly due to use of removed APIs); in the latter case care must be taken - it will conflict if library dependencies use LibreSSL libraries. What would be the best way to resolve this issue? I would guess that plenty of others are using python with OpenBSD so there must be a recommended resolution, but I have not found it documented anywhere yet. Thanks! Judah The problem is very likely a version of urllib3 installed via pip, and has little to do with the python version itself. -Otto -- Judah Kocher Assistant Chief Cochranville Fire Company 484-266-9257
Re: Pkg_add Python version and LibreSSL seem to be incompatible in OpenBSD 7.3
On Sun, May 14, 2023 at 12:25:28PM -0400, Judah Kocher wrote: > After updating one of my routers to OpenBSD 7.3, my python scripts that > update various public DNS records when my public IP changes started failing > with generic segfaults. I did see the note in the OpenBSD Upgrade Guide > about 3.10 being the new default so I ran pkg_add -u which updated python to > 3.10 and now the same scripts fail but with this error: > > ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' > module is compiled with LibreSSL 3.7.2. See: > https://github.com/urllib3/urllib3/issues/2168 > > The included github link mentions that older versions of SSL are no longer > usable with the urllib library but makes no mention of LibreSSL. > > Some web searching has not turned up any details around this. I also do not > see python 3.9 as an installable option via pkg_add, just 3.10 and 3.11. > Does this mean that installing python via pkg_add installs a python version > that is incompatible with LibreSSL? When I look at the info for the OpenSSL > package it includes this warning: > > This package is not intended for general-purpose use in OpenBSD - it > is present for test/comparison purposes, and occasionally to provide > support for applications which cannot be made compatible with LibreSSL > (mostly due to use of removed APIs); in the latter case care must be > taken - it will conflict if library dependencies use LibreSSL libraries. > > What would be the best way to resolve this issue? I would guess that plenty > of others are using python with OpenBSD so there must be a recommended > resolution, but I have not found it documented anywhere yet. > > > Thanks! > > Judah > The problem is very likely a version of urllib3 installed via pip, and has little to do with the python version itself. -Otto
Pkg_add Python version and LibreSSL seem to be incompatible in OpenBSD 7.3
After updating one of my routers to OpenBSD 7.3, my python scripts that update various public DNS records when my public IP changes started failing with generic segfaults. I did see the note in the OpenBSD Upgrade Guide about 3.10 being the new default so I ran pkg_add -u which updated python to 3.10 and now the same scripts fail but with this error: ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with LibreSSL 3.7.2. See: https://github.com/urllib3/urllib3/issues/2168 The included github link mentions that older versions of SSL are no longer usable with the urllib library but makes no mention of LibreSSL. Some web searching has not turned up any details around this. I also do not see python 3.9 as an installable option via pkg_add, just 3.10 and 3.11. Does this mean that installing python via pkg_add installs a python version that is incompatible with LibreSSL? When I look at the info for the OpenSSL package it includes this warning: This package is not intended for general-purpose use in OpenBSD - it is present for test/comparison purposes, and occasionally to provide support for applications which cannot be made compatible with LibreSSL (mostly due to use of removed APIs); in the latter case care must be taken - it will conflict if library dependencies use LibreSSL libraries. What would be the best way to resolve this issue? I would guess that plenty of others are using python with OpenBSD so there must be a recommended resolution, but I have not found it documented anywhere yet. Thanks! Judah
Re: pkg_add in -current
Stuart Henderson wrote: > On 2022/06/04 15:23, Theo de Raadt wrote: > > Stuart Henderson wrote: > > > > > If you are running -current and have not updated base recently, you > > > may run inTO "pkg_add: Unknown option: always-update ". > > > To fix it, just update to a newer base snapshot. > > > > > > > > What happened is that a developer made a change to the pkg tools which > > creates completely incompatible package files. > > > > Noone knew this was happening beforehands. An email was circulated > > after-the-fact to ports@ list (which is mostly read by developers, and > > not read by users). It has now been weeks, and it still hasn't been > > clearly communicated. > > People can decide for themselves about that, > > First commit enabling parsing in pkg_add > https://github.com/openbsd/src/commit/5cb7aebf4211294fd2891b0bc45c383ab7fd66af That commit message does not say: There will be no backwards compatiblity. > "REMINDER: snapshots go with -current" > https://marc.info/?l=openbsd-ports=165355109123377=2 That message says: There is zero effort being made for backwards compatiblity. It also says it is going to be FUN. Are we having fun? We are not having fun. This is the case of one developer (who did not even explain what was happening to any non-ports developer) making a decision in their own bubble, without communicating the impact in a way that everyone can understand. > Second commit, after base is updated with this subsequent package builds > use the new annotation > https://github.com/openbsd/src/commit/c2e596a17ac45689d758df0d67597fef94480ebe That commit message does not say: No effort has been made for backwards compatibility. > (Then it takes time for new packages to be built on the various archs > and it's not until *then* that errors would show up for people who > haven't updated base yet) So here we are: There is no backwards compatibility, and users are starting to encounter the problem, and the answer for them is that they must reboot. No it's not just that, they are being told the PROCESS WAS GREAT, and what is wrong here is *THEIR* process of using snapshots. It has also been pointed out that current.html has no information about this change. I have been saying for a while we should delete current.html because it seems to always contain useless information, and here we see it lacks crucial information.
Re: pkg_add in -current
On 2022/06/04 15:23, Theo de Raadt wrote: > Stuart Henderson wrote: > > > If you are running -current and have not updated base recently, you > > may run inTO "pkg_add: Unknown option: always-update ". > > To fix it, just update to a newer base snapshot. > > > > What happened is that a developer made a change to the pkg tools which > creates completely incompatible package files. > > Noone knew this was happening beforehands. An email was circulated > after-the-fact to ports@ list (which is mostly read by developers, and > not read by users). It has now been weeks, and it still hasn't been > clearly communicated. People can decide for themselves about that, First commit enabling parsing in pkg_add https://github.com/openbsd/src/commit/5cb7aebf4211294fd2891b0bc45c383ab7fd66af "REMINDER: snapshots go with -current" https://marc.info/?l=openbsd-ports=165355109123377=2 Second commit, after base is updated with this subsequent package builds use the new annotation https://github.com/openbsd/src/commit/c2e596a17ac45689d758df0d67597fef94480ebe (Then it takes time for new packages to be built on the various archs and it's not until *then* that errors would show up for people who haven't updated base yet)
Re: pkg_add in -current
Stuart Henderson wrote: > If you are running -current and have not updated base recently, you > may run inTO "pkg_add: Unknown option: always-update ". > To fix it, just update to a newer base snapshot. What happened is that a developer made a change to the pkg tools which creates completely incompatible package files. Noone knew this was happening beforehands. An email was circulated after-the-fact to ports@ list (which is mostly read by developers, and not read by users). It has now been weeks, and it still hasn't been clearly communicated. We break compatibility often, but generally ensure the right people -- both developers and users -- know when they need to know. This is important because people who follow snapshots (in various ways) should have a good experience because if they don't enjoy the snapshot experience, we may end up with a smaller test community between releases. Sometimes there are surprises in snapshots of a testing nature, but this particular change was not deployed or communicated as a test (we cannot go back). The normal model was not followed in this instance.
pkg_add in -current
If you are running -current and have not updated base recently, you may run inTO "pkg_add: Unknown option: always-update ". To fix it, just update to a newer base snapshot.
Re: Font Path prompt in pkg_add
Ah, I guessed it was a feature now and I like it, it just threw me the first time. On Friday, April 29, 2022, Marc Espie wrote: > On Thu, Apr 28, 2022 at 02:37:39PM -0500, Christopher Turkel wrote: > > I'm on OpenBSD AMD64 7.1, fresh install > > I noticed when adding fonts via pkg_add it no longer prints out "You may > > wish to" after installation is finished. > > It's related to the evolution of X windows. > > Quite a few years ago, fonts were mostly handled server-side. > > Keith Packard started a large change in X fonts a few years ago. > > Most modern applications deal with X fonts client side. > > The rationale behind the change is that people who deal with > server-side font info will know about the way to change the > server path. > > Most new font directories are related to new applications, so > those messages were irrelevant. > > > Side note: there's a big focus from some people in OpenBSD > to keeping tools mostly silent (as opposed to the awfully > chatty linux thingies). Sometimes, this has disproportionate > consequences. End users do see those messages, whereas there's > a HUGE amount of churn in the tools that DON'T end in any visible > messages and has FAR MORE REACHING consequences to the quality > of those tools. ;) >
Re: Font Path prompt in pkg_add
On Thu, Apr 28, 2022 at 02:37:39PM -0500, Christopher Turkel wrote: > I'm on OpenBSD AMD64 7.1, fresh install > I noticed when adding fonts via pkg_add it no longer prints out "You may > wish to" after installation is finished. It's related to the evolution of X windows. Quite a few years ago, fonts were mostly handled server-side. Keith Packard started a large change in X fonts a few years ago. Most modern applications deal with X fonts client side. The rationale behind the change is that people who deal with server-side font info will know about the way to change the server path. Most new font directories are related to new applications, so those messages were irrelevant. Side note: there's a big focus from some people in OpenBSD to keeping tools mostly silent (as opposed to the awfully chatty linux thingies). Sometimes, this has disproportionate consequences. End users do see those messages, whereas there's a HUGE amount of churn in the tools that DON'T end in any visible messages and has FAR MORE REACHING consequences to the quality of those tools. ;)
Re: Font Path prompt in pkg_add
Changelog (just the facts - Awesome!): https://www.openbsd.org/plus71.html A search for "font" on the page shows 3 entries... On 4/28/22 12:37, Christopher Turkel wrote: > I'm on OpenBSD AMD64 7.1, fresh install > I noticed when adding fonts via pkg_add it no longer prints out "You may > wish to" after installation is finished. > > is this a bug, or a feature?
Font Path prompt in pkg_add
I'm on OpenBSD AMD64 7.1, fresh install I noticed when adding fonts via pkg_add it no longer prints out "You may wish to" after installation is finished. is this a bug, or a feature?
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
> Please reconsider my suggestion made on 2022-01-14: Everybody wants to be a dev.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Mon, Jan 24, 2022 at 10:21:33AM +0100, Harald Dunkel wrote: > I highly appreciate the carefulness, but the error message doesn't > indicate a user "_pkgfetch", nor is it mentioned on pkg_add(1). > Please reconsider my suggestion made on 2022-01-14: > Note that smtpd(8) doesn't mention all the users and processes it used for privilege separation either. Those are implementation details and will work out-of-the-box unless you fiddle with parts you're not supposed to touch. and if you touch those parts... you're supposed to know where to look and how things work in the background.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
I highly appreciate the carefulness, but the error message doesn't indicate a user "_pkgfetch", nor is it mentioned on pkg_add(1). Please reconsider my suggestion made on 2022-01-14: > In general, if there is a permission problem due to file system > access bits, then it would be wise to include euid and egid in > the error message. Thank you very much Harri
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote: > On 2022-01-17 18:02:25, Marc Espie wrote: > > > > Lol. > > > > cert.pem only contains public certificates. Insisting on only root being > > able to read it means you are going to run code as root which doesn't > > require > > it. That seems way more unreasonable than your original assumption. > > > > I am not arguing about the access permissions (which I screwed > up), but I wonder why pkg_add run by root failed with EPERM? > Actually root was the only one *permitted* to access this file. > Thats not an error. Because we use this nifty technique called privilege separation to alleviate issues with bugs. Most specifically, pkg_add runs as root, which has wy too many rights, so it doesn't connect to the network directly, it starts ftp(1), which runs as _pkgfetch, which passes its result to signify which can check that the archive is properly signed before decompressing it with the zlib and finally putting the result on your disk. It's not rocket science, privilege separation has been around for over 20 years at this point ;)
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote: > On 2022-01-17 18:02:25, Marc Espie wrote: > > > > Lol. > > > > cert.pem only contains public certificates. Insisting on only root being > > able to read it means you are going to run code as root which doesn't > > require > > it. That seems way more unreasonable than your original assumption. > > > > I am not arguing about the access permissions (which I screwed > up), but I wonder why pkg_add run by root failed with EPERM? > Actually root was the only one *permitted* to access this file. > Thats not an error. > > If there was another user account involved, then show me. The user is called _pkgfetch -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-17 18:02:25, Marc Espie wrote: Lol. cert.pem only contains public certificates. Insisting on only root being able to read it means you are going to run code as root which doesn't require it. That seems way more unreasonable than your original assumption. I am not arguing about the access permissions (which I screwed up), but I wonder why pkg_add run by root failed with EPERM? Actually root was the only one *permitted* to access this file. Thats not an error. If there was another user account involved, then show me.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14, Harald Dunkel wrote: > On 2022-01-14 10:42:56, Harald Dunkel wrote: >> >> Hi folks, >> >> trying to upgrade the installed packages I get >> >> # pkg_add -u >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > chmod a+rx /etc/ssl > > did the trick, but this doesn't look reasonable. Lol. cert.pem only contains public certificates. Insisting on only root being able to read it means you are going to run code as root which doesn't require it. That seems way more unreasonable than your original assumption.
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
OpenBSD default is for /etc/ssl/ to be root:wheel u+w,a+rx Harold, you broke your own machine. Stuart Henderson wrote: > On 2022-01-14, Harald Dunkel wrote: > > On 2022-01-14 10:42:56, Harald Dunkel wrote: > >> > >> Hi folks, > >> > >> trying to upgrade the installed packages I get > >> > >> # pkg_add -u > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS > >> connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission > >> denied > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect > >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty > >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > > > chmod a+rx /etc/ssl > > > > did the trick, but this doesn't look reasonable. > > Why would that not be reasonable? It's setting it back to the default > permissions after whatever change you've made to it. > > There are various system daemons and utilities (including sysupgrade, > syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will > want to make TLS connections as a non-root user, at least in some > configurations. Some of these may open cert.pem while they still have > privileges but not always. > > > In general, if there is a permission problem due to file system > > access bits, then it would be wise to include euid and egid in > > the error message. > > Not sure if that helps really. If you'd seen that, maybe you would have > fixed it for _pkgfetch and not noticed some other software that would > like to use it.. > >
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14, Harald Dunkel wrote: > On 2022-01-14 10:42:56, Harald Dunkel wrote: >> >> Hi folks, >> >> trying to upgrade the installed packages I get >> >> # pkg_add -u >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > chmod a+rx /etc/ssl > > did the trick, but this doesn't look reasonable. Why would that not be reasonable? It's setting it back to the default permissions after whatever change you've made to it. There are various system daemons and utilities (including sysupgrade, syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will want to make TLS connections as a non-root user, at least in some configurations. Some of these may open cert.pem while they still have privileges but not always. > In general, if there is a permission problem due to file system > access bits, then it would be wise to include euid and egid in > the error message. Not sure if that helps really. If you'd seen that, maybe you would have fixed it for _pkgfetch and not noticed some other software that would like to use it..
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
| This happens on 2 OpenBSD hosts. On 5 others there is no such problem. Do you have an explanation why the 2 host out of 7 are behaving different? I don't find it "reasonable" that 2 host out of 7 manifest some different behavior on their own.
pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
Hi folks, trying to upgrade the installed packages I get # pkg_add -u https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... How comes? I am root. And openssl x509 -in /etc/ssl/cert.pem shows that I can read the certificate. This happens on 2 OpenBSD hosts. On 5 others there is no such problem. All use 7.0. http/tcp and https/tcp are not blocked by some forgotten pf rules. Every helpful hint is highly appreciated. Harri
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14 10:42:56, Harald Dunkel wrote: Hi folks, trying to upgrade the installed packages I get # pkg_add -u https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... chmod a+rx /etc/ssl did the trick, but this doesn't look reasonable. In general, if there is a permission problem due to file system access bits, then it would be wise to include euid and egid in the error message. Harri
Re: pkg_add issues
On Mon, Jan 03, 2022 at 12:21:17PM -, Stuart Henderson wrote: > On 2022-01-02, Jon Fineman wrote: > > I am in New Jersey. Is there a way for me to tell what the cdn was > > pointing to to help find the slow/sick server? > > It's shown in HTTP response headers from cdn. Almost certainly > it was pointing at a machine which only serves the cdn and you cannot > access directly. pkg_add explicitly shows it in the first file it retrieves. For various reasons (consistency), we don't do cdn round-robin on each package. The Redirect from the first connection will be automatically re-used in the subsequent connections.
Re: pkg_add issues
On 2022-01-02, Jon Fineman wrote: > I am in New Jersey. Is there a way for me to tell what the cdn was > pointing to to help find the slow/sick server? It's shown in HTTP response headers from cdn. Almost certainly it was pointing at a machine which only serves the cdn and you cannot access directly. -- Please keep replies on the mailing list.
pkg_add issues
Yesterday (1 Jan 2022) I was running pkg_add -u after a sysupgrade and on most of the larger downloads I was getting premature end of file on archive and other networking issues and generally poor performance. This started around 7am and I stepped away around 9am, then continued trying around 10pm. My installurl is set to: https://cdn.openbsd.org/pub/OpenBSD I finally changed it to (Rochester NY): https://ftp.usa.openbsd.org/pub/OpenBSD/ and the updates were able to complete and the performance was as usual. I am in New Jersey. Is there a way for me to tell what the cdn was pointing to to help find the slow/sick server? As of now it still appears overly slow. Thanks. Jon
Re: pkg_add python errors ...
On 2021-11-29, Why 42? The lists account. wrote: > > Well, errors related to the python package ... > > After updating to the latest snapshot and rebooting I ran "pkg_add -vu" > to update all my packages, which I think is the right thing to do. > > I noticed some strange errors related to python scroll past i.e. I made a mistake with the version switch from 3.8 to 3.9 as default and you updated to the one snapshot package build that had bad conflict markers - I have been told that running pkg_add -u a couple more times will clear it, if not then rm -r /var/db/pkg/partial-python* and run pkg_add -u again.
pkg_add python errors ...
Well, errors related to the python package ... After updating to the latest snapshot and rebooting I ran "pkg_add -vu" to update all my packages, which I think is the right thing to do. I noticed some strange errors related to python scroll past i.e. > ... > Update candidates: p7zip-16.02p6 -> p7zip-16.02p6 > Update candidates: partial-python-3.9.7p3 -> python-3.9.9 > Unexpected symlink: /usr/local/bin/2to3 > Unexpected symlink: /usr/local/bin/pydoc3 > Unexpected symlink: /usr/local/bin/python3 > Unexpected symlink: /usr/local/bin/python3-config > Unexpected symlink: /usr/local/lib/pkgconfig/python3-embed.pc > Unexpected symlink: /usr/local/lib/pkgconfig/python3.pc > Unexpected symlink: /usr/local/man/man1/python3.1 > Bad rename /usr/local/bin/2to3 to /usr/local/bin/2to3.X77AFtJWEq: No such > file or directory > Bad rename /usr/local/bin/pydoc3 to /usr/local/bin/pydoc3.FLyJqqVBCV: No such > file or directory > Bad rename /usr/local/bin/python3 to /usr/local/bin/python3.mct9eU2JKh: No > such file or directory > Bad rename /usr/local/bin/python3-config to > /usr/local/bin/python3-config.LVZ4scwF2N: No such file or directory > Bad rename /usr/local/lib/pkgconfig/python3-embed.pc to > /usr/local/lib/pkgconfig/python3-embed.pc.W3q0EmYVnC: No such file or > directory > Bad rename /usr/local/lib/pkgconfig/python3.pc to > /usr/local/lib/pkgconfig/python3.pc.0svv4fWReb: No such file or directory > Bad rename /usr/local/man/man1/python3.1 to > /usr/local/man/man1/python3.1.iWHWD3b3mt: No such file or directory > [python-3.9.9]partial-python-3.9.7p3->: ok > Update candidates: pcsc-tools-1.4.27p0 -> pcsc-tools-1.4.27p0 > Update candidates: picocom-3.1 -> picocom-3.1 > ... I'm not sure why the "bad rename" would occur, indeed the rename does seem to have taken place: > mjoelnir:log 29.11 # ls -l /usr/local/bin/2to3* > -rwxr-xr-x 1 root bin101 Nov 26 12:37 /usr/local/bin/2to3-3.8 > -rwxr-xr-x 1 root bin101 Nov 25 20:41 /usr/local/bin/2to3-3.9 > -rw--- 1 root wheel0 Nov 29 15:04 /usr/local/bin/2to3.H0cMphlKfH > -rw--- 1 root wheel0 Nov 29 15:34 /usr/local/bin/2to3.X77AFtJWEq (I ran the pkg_add a second time to capture the above error messages, so I imagine that is why there are now two temp filenames.) The pkg_add operation ended with: > ... > Update candidates: zsh-syntax-highlighting-0.7.1 -> > zsh-syntax-highlighting-0.7.1 > --- -partial-python-3.9.7p3 --- > Files kept as partial-python-3.9.7p3.1 package I now seem to have four different versions of the python package installed: partial-python-3.9.7p3.1 python-2.7.18p5 python-3.8.12p4 python-3.9.9 I'm not sure why python-3.9.7p3.1 has been kept around, according to pkg_info nothing requires it: > mjoelnir:/etc 29.11 # pkg_info -R partial-python-3.9.7p3.1 > mjoelnir:/etc 29.11 # Running sysclean doesn't report anything obviously python related. Has something gone wrong here? Do I need to to do any manual cleanup? Cheers, Robb. mjoelnir:/etc 29.11 # sysctl kern.version kern.version=OpenBSD 7.0-current (GENERIC.MP) #131: Mon Nov 29 00:32:40 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Re: After upgrade to 6.9 pkg_add -u throws ListUtil.c error
Dear Andrew, Moved the package out of the directory. Packages are updating. Thank you. Pascal. -Oorspronkelijk bericht- Van: Andrew Hewus Fresh Aan: pas...@pascallen.nl Cc: misc@openbsd.org Onderwerp: Re: After upgrade to 6.9 pkg_add -u throws ListUtil.c error Datum: Mon, 22 Nov 2021 14:45:19 -0800 On Mon, Nov 22, 2021 at 11:34:44PM +0100, pas...@pascallen.nl wrote: > After a sysupgrade to 6.9I try to update the packages but get thrown > an error: > router# pkg_add -UuListUtil.c: loadable library and perl binaries are > mismatched (gothandshake key 0xb60, needed 0xec0) This error generally means that you've installed perl modules(in this case List::Util) using a CPAN client instead of ports orpackages. > How can I recover? Remove any modules you've installed outside of the ports tree into/usr/local/libdata/perl5. Once you upgrade to OpenBSD 7.0, base tools got smarter so that theywon't be broken by this condition, but things outside of base willcontinue to have issues. I need to get back to some changes to improvethis in the future, but time has not been on my side. l8rZ,
Re: After upgrade to 6.9 pkg_add -u throws ListUtil.c error
Or upgrade to 7.0? No clue what I installed with CPAN -- Met vriendelijke groet, Pascal Huisman President Reagan has noted that there are too many economic pundits and forecasters and has decided on an excess prophets tax. -Oorspronkelijk bericht- Van: Andrew Hewus Fresh Aan: pas...@pascallen.nl Cc: misc@openbsd.org Onderwerp: Re: After upgrade to 6.9 pkg_add -u throws ListUtil.c error Datum: Mon, 22 Nov 2021 14:45:19 -0800 On Mon, Nov 22, 2021 at 11:34:44PM +0100, pas...@pascallen.nl wrote: > After a sysupgrade to 6.9 > I try to update the packages but get thrown an error: > > router# pkg_add -Uu > ListUtil.c: loadable library and perl binaries are mismatched (got > handshake key 0xb60, needed 0xec0) This error generally means that you've installed perl modules (in this case List::Util) using a CPAN client instead of ports or packages. > How can I recover? Remove any modules you've installed outside of the ports tree into /usr/local/libdata/perl5. Once you upgrade to OpenBSD 7.0, base tools got smarter so that they won't be broken by this condition, but things outside of base will continue to have issues. I need to get back to some changes to improve this in the future, but time has not been on my side. l8rZ, signature.asc Description: This is a digitally signed message part
Re: After upgrade to 6.9 pkg_add -u throws ListUtil.c error
On Mon, Nov 22, 2021 at 11:34:44PM +0100, pas...@pascallen.nl wrote: > After a sysupgrade to 6.9 > I try to update the packages but get thrown an error: > > router# pkg_add -Uu > ListUtil.c: loadable library and perl binaries are mismatched (got > handshake key 0xb60, needed 0xec0) This error generally means that you've installed perl modules (in this case List::Util) using a CPAN client instead of ports or packages. > How can I recover? Remove any modules you've installed outside of the ports tree into /usr/local/libdata/perl5. Once you upgrade to OpenBSD 7.0, base tools got smarter so that they won't be broken by this condition, but things outside of base will continue to have issues. I need to get back to some changes to improve this in the future, but time has not been on my side. l8rZ, -- andrew A printer consists of three main parts: the case, the jammed paper tray and the blinking red light.
After upgrade to 6.9 pkg_add -u throws ListUtil.c error
After a sysupgrade to 6.9 I try to update the packages but get thrown an error: router# pkg_add -Uu ListUtil.c: loadable library and perl binaries are mismatched (got handshake key 0xb60, needed 0xec0) How can I recover? -- Met vriendelijke groet, Pascal Huisman Win 98 Psychic edition: We'll tell you where you're going tomorrow signature.asc Description: This is a digitally signed message part
Re: pkg_add with certificate pinning
On 2021-11-19 08:12, Stuart Henderson wrote: On 2021-11-19, Fabio Martins wrote: Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. There doesn't seem a real advantage here. In terms of checking that files are from a known source, pkg_add checks signatures with signify (so updates over plain http are OK really). Also the checks are done with a tight pledge(7) restriction (and decompressors aren't called until signatures have been checked, they are also restricted). In terms of confidentiality, you can figure out a lot from what's available in the clear even with HTTPS. The IP addresses obviously. SNI hostnames. Request/response lengths are visible, and with a known set of files that anyone can easily fetch like packages (and known interdepencies) this makes it possible to figure out what's installed to some level of accuracy (IIRC espie@ did some research into this). The article you show talks about maliciously implanted root certs, typically installed on "managed" systems (corporate environment etc), or by malware. If something is changing that (/etc/ssl/cert.pem) without your knowledge you have bigger problems. Changes to that do show up in daily security mails though if somebody can change the file they can surely change the script too. If you really want to, you can do cert pinning. Put the desired ca certificate into a separate file, see ftp's -T cafile option, and pass the parameter from pkg_add via the FETCH_CMD variable. But I think it's not really worthwhile here. @stuart @Yifei Thanks for the inputs. Understood it isn't worth doing.
Re: pkg_add with certificate pinning
On 2021-11-19, Fabio Martins wrote: > Sorry if it is a bit off-topic. > > After reading an article about rogue CA's: > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > I wonder if there is any advantage of using certificate pinning in the > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. There doesn't seem a real advantage here. In terms of checking that files are from a known source, pkg_add checks signatures with signify (so updates over plain http are OK really). Also the checks are done with a tight pledge(7) restriction (and decompressors aren't called until signatures have been checked, they are also restricted). In terms of confidentiality, you can figure out a lot from what's available in the clear even with HTTPS. The IP addresses obviously. SNI hostnames. Request/response lengths are visible, and with a known set of files that anyone can easily fetch like packages (and known interdepencies) this makes it possible to figure out what's installed to some level of accuracy (IIRC espie@ did some research into this). The article you show talks about maliciously implanted root certs, typically installed on "managed" systems (corporate environment etc), or by malware. If something is changing that (/etc/ssl/cert.pem) without your knowledge you have bigger problems. Changes to that do show up in daily security mails though if somebody can change the file they can surely change the script too. If you really want to, you can do cert pinning. Put the desired ca certificate into a separate file, see ftp's -T cafile option, and pass the parameter from pkg_add via the FETCH_CMD variable. But I think it's not really worthwhile here. -- Please keep replies on the mailing list.
Re: pkg_add with certificate pinning
On 2021-11-19 06:57, Yifei Zhan wrote: On 21/11/19 06:26AM, Fabio Martins wrote: Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. OpenBSD does not use PKI/web of trust for integrity validation, thus I don't think certificate pinning makes sense for those operations. Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that purpose. Well said. I believe it would only improve confidentiality, as rogue middleware appliances would not be able to inspect the content of package updates.
pkg_add with certificate pinning
Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. -- Fabio http://nabundapode.com.br/
Re: pkg_add failing with TLS handshake failure
Check your system time maybe? On 11/1/21 18:06, rahul deshmukh wrote: Hi Team, while installing new packages i am getting below error. myhost01$ doas pkg_add rust https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS handshake failure: ocsp verify failed: ocsp response not current https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS handshake failure: ocsp verify failed: ocsp response not current https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty Can't find rust myhost01$ cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD myhost01$ uname -a OpenBSD Home01.home.net 7.0 GENERIC.MP#232 amd64
pkg_add failing with TLS handshake failure
Hi Team, while installing new packages i am getting below error. myhost01$ doas pkg_add rust https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS handshake failure: ocsp verify failed: ocsp response not current https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS handshake failure: ocsp verify failed: ocsp response not current https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty Can't find rust myhost01$ cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD myhost01$ uname -a OpenBSD Home01.home.net 7.0 GENERIC.MP#232 amd64 -- Thank you - Rahul Deshmukh
Re: Exit status of pkg_add
On Tue, Oct 19, 2021 at 10:42:04AM +0900, Yuichiro NAITO wrote:
> Following patch changes pkg_add to return a error code,
> if a package name is wrong.
>
> diff --git a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> index 7a968cbf05d..39bee874ff1 100644
> --- a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> +++ b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
> @@ -403,12 +403,13 @@ sub check_root
> sub choose_location
> {
> my ($state, $name, $list, $is_quirks) = @_;
> if (@$list == 0) {
> if (!$is_quirks) {
> $state->errsay("Can't find #1", $name);
> + $state->{bad}++;
> $state->run_quirks(
> sub {
> my $quirks = shift;
> $quirks->filter_obsolete([$name], $state);
> });
> }
>
> Is it OK?
>
> On 10/18/21 16:53, Yuichiro NAITO wrote:
> > Hi, I have a question about exit status of pkg_add command.
> >
> > When I wrote a package install script which included typo in a package name
> > (of course it's my fault), the script didn't stop in spite of `set -e`.
> >
> > Because pkg_add command returns 0 even if a package name is wrong.
> > Is this exit status intended or design policy of pkg_add command?
> >
> > If not, I want a error status getting returned.
> > It will save my time to look for a typo or similar bug.
> >
> > I can't see 'EXIT STATUS' section in the pkg_add manual of OpenBSD 7.0.
> > So, I e-mailed this question.
> >
Basically, there are a few traps in pkg_add wrt exit status.
The main trap is that making pkg_add error out in cases it didn't requires
testing, because various automated situations that already exist might fail.
I will most probably fix that one, assuming there is no fallout.
Re: Exit status of pkg_add
Following patch changes pkg_add to return a error code,
if a package name is wrong.
diff --git a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
index 7a968cbf05d..39bee874ff1 100644
--- a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
+++ b/usr.sbin/pkg_add/OpenBSD/AddDelete.pm
@@ -403,12 +403,13 @@ sub check_root
sub choose_location
{
my ($state, $name, $list, $is_quirks) = @_;
if (@$list == 0) {
if (!$is_quirks) {
$state->errsay("Can't find #1", $name);
+ $state->{bad}++;
$state->run_quirks(
sub {
my $quirks = shift;
$quirks->filter_obsolete([$name], $state);
});
}
Is it OK?
On 10/18/21 16:53, Yuichiro NAITO wrote:
Hi, I have a question about exit status of pkg_add command.
When I wrote a package install script which included typo in a package name
(of course it's my fault), the script didn't stop in spite of `set -e`.
Because pkg_add command returns 0 even if a package name is wrong.
Is this exit status intended or design policy of pkg_add command?
If not, I want a error status getting returned.
It will save my time to look for a typo or similar bug.
I can't see 'EXIT STATUS' section in the pkg_add manual of OpenBSD 7.0.
So, I e-mailed this question.
--
Yuichiro NAITO (naito.yuich...@gmail.com)
Exit status of pkg_add
Hi, I have a question about exit status of pkg_add command. When I wrote a package install script which included typo in a package name (of course it's my fault), the script didn't stop in spite of `set -e`. Because pkg_add command returns 0 even if a package name is wrong. Is this exit status intended or design policy of pkg_add command? If not, I want a error status getting returned. It will save my time to look for a typo or similar bug. I can't see 'EXIT STATUS' section in the pkg_add manual of OpenBSD 7.0. So, I e-mailed this question. -- Yuichiro NAITO (naito.yuic...@gmail.com)
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
On 2021-10-15, cho...@jtan.com wrote: > Bingo. I was even told about it in the email I ignored (there's > nothing wrong with *69): :) Been there done that. (If I am anywhere near tight on space in /usr I usually try to upgrade with the "untar on running system" method with a root shell open so I have some hope of fixing it..) And I have a number of systems where I have a gap in partition letters after growfs'ing /usr into what was previously the partition after it on disk. > Time to reinstall on a bigger disc. Thanks for the pointer, that > saves me some perplexed digging around. Good files to kill if you need to quickly make some breathing space (but of course will come back after reinstalling all sets): /usr/lib/lib[a-bd-z]*.a /usr/share/man Unless you are doing installs directly under /usr (usually self built software), removing everything reported by "sysclean | grep ^/usr" should be safe. It takes care of libraries needed for installed packages so you can try cleaning, making sure you have xbase and base sets fully unpacked, update packages, then run sysclean again and it will probably allow you to free up some more shared libraries. > btw Some of the space used on /usr will be old libraries (it's at > least as old as 6.8, clearly), but for the record it looks like the > minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), > 240MB for /usr/X11R6 and <75MB for everything else if the box isn't > doing a great deal. FWIW I usually try to give /usr at least 5GB. Maybe slight overkill but it's such a pain to shuffle partitions I'd rather waste a bit of space than have to do that again. The other place I often run out is / on systems where I run current as I often have a few different kernels lying around from trying to bisect when a problem was introduced. -- Please keep replies on the mailing list.
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Oh and it's also worth noting that despite that massive cock-up, the box is still (now) running just fine on this frankenhybrid and serving its git repositories and running its crons, all entirely hands-off and automated: # uname -a && uptime OpenBSD smoke.datum 7.0 GENERIC#224 amd64 4:29AM up 10:49, 2 users, load averages: 0.05, 0.02, 0.01 That's how engineering works. Take that, devops. Matthew
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Stuart Henderson writes: > On 2021-10-14, cho...@jtan.com wrote: > > Turns out, one of my less important boxes was still on 6.8. Whoops. > > > > After two sysupgrades, this is the result of pkg_add -u: > > > > quirks-4.53 signed on 2021-10-12T20:12:39Z > > Can't install cairo-1.16.0 because of libraries > >|library pixman-1.40.0 not found > > That file is in xserv70.tgz so you shouldn't be having that problem unless the > untar failed. Does the file exist (should be in /usr/X11R6/lib)? Are you ok > for > disk space in /usr/X11R6? Bingo. I was even told about it in the email I ignored (there's nothing wrong with *69): Installing base70.tgz91% |*** | 275 MB00:01 ETAtar: Failed write to file ./usr/share/relink/kernel.tgz: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libc.so.96.1.a: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libcrypto.so.47.0.a: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-CARP-MIB.txt: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-PF-MIB.txt: No space left on device Installing base70.tgz99% |* | 301 MB00:00 ETAtar: Failed write to file ./usr/share/zoneinfo/CST6CDT: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Paris: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Zaporozhye: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Pacific/Fiji: No space left on device Installing base70.tgz 100% |**| 302 MB00:14 Installation of base70.tgz failed. Continue anyway? [no] no Time to reinstall on a bigger disc. Thanks for the pointer, that saves me some perplexed digging around. Matthew btw Some of the space used on /usr will be old libraries (it's at least as old as 6.8, clearly), but for the record it looks like the minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), 240MB for /usr/X11R6 and <75MB for everything else if the box isn't doing a great deal.
pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Turns out, one of my less important boxes was still on 6.8. Whoops. After two sysupgrades, this is the result of pkg_add -u: quirks-4.53 signed on 2021-10-12T20:12:39Z Can't install cairo-1.16.0 because of libraries |library pixman-1.40.0 not found | /usr/X11R6/lib/libpixman-1.so.38.4 (system): bad major Direct dependencies for cairo-1.16.0->1.16.0 resolve to png-1.6.37 glib2-2.68.4 lzo2-2.10p2 Full dependency tree is libiconv-1.16p0 png-1.6.37 lzo2-2.10p2 pcre-8.44 libffi-3.3p1 sqlite3-3.35.5p0 gettext-runtime-0.21p1 xz-5.2.5 python-3.8.12 glib2-2.68.4 bzip2-1.0.8p0 Can't install texlive_base-2020p0 because of libraries Direct dependencies for texlive_base-2020p0->2020p0 resolve to harfbuzz-2.9.1 cairo-1.16.0 graphite2-1.3.14 libiconv-1.16p0 png-1.6.37 ghostscript-9.07p7 clisp-2.49p5 dvi2tty-5.3.1p0 detex-2.8.1 gd-2.3.2 texlive_texmf-buildset-2020p0 psutils-2.06 libpaper-1.1.28 ps2eps-1.68p0 zziplib-0.13.62p1 desktop-file-utils-0.26 lcdf-typetools-2.108p0 texlive_mktexlsr-2020p0 icu4c-69.1p0v0 t1utils-1.42 texlive_synctex-2020p0 Full dependency tree is detex-2.8.1 pcre-8.44 libevent-2.1.11 jbig2dec-0.11 libiconv-1.16p0 png-1.6.37 icu4c-69.1p0v0 gnutls-3.7.2 texlive_mktexlsr-2020p0 libnettle-3.7.3 avahi-libs-0.8p1 texlive_synctex-2020p0 libunistring-0.9.7 psutils-2.06 ghostscript-fonts-8.11p3 texlive_texmf-buildset-2020p0 zziplib-0.13.62p1 ijs-0.35p3 dvi2tty-5.3.1p0 libunbound-1.13.2 gd-2.3.2 graphite2-1.3.14 cairo-1.16.0 p11-kit-0.24.0 libffi-3.3p1 zstd-1.5.0 desktop-file-utils-0.26 libidn2-2.3.0p0 libtasn1-4.17.0 clisp-2.49p5 cups-libs-2.3.3.2p1 harfbuzz-2.9.1 xz-5.2.5 gettext-runtime-0.21p1 dbus-1.12.20p1v0 sqlite3-3.35.5p0 tiff-4.3.0 gmp-6.2.1p0 ps2eps-1.68p0 ffcall-1.10p5 libpaper-1.1.28 giflib-5.1.6 p5-IPC-Run3-0.048p0 lz4-1.9.3p0 lzo2-2.10p2 libsigsegv-2.12 ghostscript-9.07p7 lcdf-typetools-2.108p0 libwebp-1.2.1 t1utils-1.42 lcms2-2.12 bzip2-1.0.8p0 glib2-2.68.4 python-3.8.12 jpeg-2.1.1v0 Couldn't find updates for cairo-1.16.0 texlive_base-2020p0 Couldn't install cairo-1.16.0 texlive_base-2020p0 This will not be difficult to fix; remove and reinstall will probably do it. If this is the result of me skipping pkg_add -u on the 6.9 hop then there's nothing to see here but I've done the same thing a few times before without incident (I expect problems if I skip base releases, not so much with ports) so if this problem's unexpected, well, here it is. In other news, quite a few other headless hands-off servers' upgrades were absolutely seamless. Thank-you! Matthew
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
On 2021-10-14, cho...@jtan.com wrote: > Turns out, one of my less important boxes was still on 6.8. Whoops. > > After two sysupgrades, this is the result of pkg_add -u: > > quirks-4.53 signed on 2021-10-12T20:12:39Z > Can't install cairo-1.16.0 because of libraries >|library pixman-1.40.0 not found That file is in xserv70.tgz so you shouldn't be having that problem unless the untar failed. Does the file exist (should be in /usr/X11R6/lib)? Are you ok for disk space in /usr/X11R6? > This will not be difficult to fix; remove and reinstall will probably > do it. If this is the result of me skipping pkg_add -u on the 6.9 > hop then there's nothing to see here but I've done the same thing > a few times before without incident (I expect problems if I skip > base releases, not so much with ports) so if this problem's unexpected, > well, here it is. I've done a few from 6.8 direct to 7.0 (skipping base and package updates) and probably some from earlier, it's rare (read: I don't remember it happening) that I have any problems attributed to skipping versions. Not recommended unless you know how to fix things if they do arise, but still..
Re: pkg_add still reporting incorrect actions
On Sun, Oct 10, 2021 at 09:29:24AM -, Stuart Henderson wrote: > On 2021-10-10, Otto Moerbeek wrote: > > On Sun, Oct 10, 2021 at 11:09:58AM +0300, Mihai Popescu wrote: > > > >> On Sat, Oct 9, 2021 at 11:55 PM Chris Bennett < > >> cpb_m...@bennettconstruction.us> wrote: > >> > >> > On Sat, Oct 09, 2021 at 09:53:46PM +0300, Mihai Popescu wrote: > >> > > I am running amd64-current from snapshots. I am installing a lot of > >> > > packages using pkg_add -vV pkg1 pkg2 ... > >> > > > >> > > I got some strange reports, see below. This is the third email about > >> > this, > >> > > maybe isn't it a big deal. > >> > > > >> > > >> > pkg_add -Dsnap is needed when snapshots and release are next to each > >> > other > >> > . > >> > Chris > >> > > >> > > >> I am not on a release kernel. This was observed on my computer on other > >> snapshots, I have at least 2 reports on misc@. > >> I don't know perl, so I am not able yet to figure out what is happening. > >> But as with many other reports, sometimes it will be fixed. > > > > If you are running a snap kernel, it might think it is a release > > kernel close to release. That's the whole point. Use -D snap and > > you'll be ok. > > The reported problem is nothing to do with snapshot/release, it's a strange > ordering of the update set. > > Mihai, please ask on ports@, maybe cc espie to make sure he sees it, I think > he will know whether it's a problem or not. I expect it's probably just the summary line being slightly out-of-date. What's actually important is whether updates happened correctly or not, it is fairly low on my priority list.
Re: pkg_add still reporting incorrect actions
On 2021-10-10, Otto Moerbeek wrote: > On Sun, Oct 10, 2021 at 11:09:58AM +0300, Mihai Popescu wrote: > >> On Sat, Oct 9, 2021 at 11:55 PM Chris Bennett < >> cpb_m...@bennettconstruction.us> wrote: >> >> > On Sat, Oct 09, 2021 at 09:53:46PM +0300, Mihai Popescu wrote: >> > > I am running amd64-current from snapshots. I am installing a lot of >> > > packages using pkg_add -vV pkg1 pkg2 ... >> > > >> > > I got some strange reports, see below. This is the third email about >> > this, >> > > maybe isn't it a big deal. >> > > >> > >> > pkg_add -Dsnap is needed when snapshots and release are next to each >> > other >> > . >> > Chris >> > >> > >> I am not on a release kernel. This was observed on my computer on other >> snapshots, I have at least 2 reports on misc@. >> I don't know perl, so I am not able yet to figure out what is happening. >> But as with many other reports, sometimes it will be fixed. > > If you are running a snap kernel, it might think it is a release > kernel close to release. That's the whole point. Use -D snap and > you'll be ok. The reported problem is nothing to do with snapshot/release, it's a strange ordering of the update set. Mihai, please ask on ports@, maybe cc espie to make sure he sees it, I think he will know whether it's a problem or not.
Re: pkg_add still reporting incorrect actions
On Sun, Oct 10, 2021 at 11:09:58AM +0300, Mihai Popescu wrote: > On Sat, Oct 9, 2021 at 11:55 PM Chris Bennett < > cpb_m...@bennettconstruction.us> wrote: > > > On Sat, Oct 09, 2021 at 09:53:46PM +0300, Mihai Popescu wrote: > > > I am running amd64-current from snapshots. I am installing a lot of > > > packages using pkg_add -vV pkg1 pkg2 ... > > > > > > I got some strange reports, see below. This is the third email about > > this, > > > maybe isn't it a big deal. > > > > > > > pkg_add -Dsnap is needed when snapshots and release are next to each > > other > > . > > Chris > > > > > I am not on a release kernel. This was observed on my computer on other > snapshots, I have at least 2 reports on misc@. > I don't know perl, so I am not able yet to figure out what is happening. > But as with many other reports, sometimes it will be fixed. If you are running a snap kernel, it might think it is a release kernel close to release. That's the whole point. Use -D snap and you'll be ok. -Otto
Re: pkg_add still reporting incorrect actions
On Sat, Oct 9, 2021 at 11:55 PM Chris Bennett < cpb_m...@bennettconstruction.us> wrote: > On Sat, Oct 09, 2021 at 09:53:46PM +0300, Mihai Popescu wrote: > > I am running amd64-current from snapshots. I am installing a lot of > > packages using pkg_add -vV pkg1 pkg2 ... > > > > I got some strange reports, see below. This is the third email about > this, > > maybe isn't it a big deal. > > > > pkg_add -Dsnap is needed when snapshots and release are next to each > other > . > Chris > > I am not on a release kernel. This was observed on my computer on other snapshots, I have at least 2 reports on misc@. I don't know perl, so I am not able yet to figure out what is happening. But as with many other reports, sometimes it will be fixed.
Re: pkg_add still reporting incorrect actions
On Sat, Oct 09, 2021 at 09:53:46PM +0300, Mihai Popescu wrote: > I am running amd64-current from snapshots. I am installing a lot of > packages using pkg_add -vV pkg1 pkg2 ... > > I got some strange reports, see below. This is the third email about this, > maybe isn't it a big deal. > pkg_add -Dsnap is needed when snapshots and release are next to each other . Chris
pkg_add still reporting incorrect actions
I am running amd64-current from snapshots. I am installing a lot of packages using pkg_add -vV pkg1 pkg2 ... I got some strange reports, see below. This is the third email about this, maybe isn't it a big deal. [output cut] libreoffice-7.2.1.2v0:postgresql-client-13.4p0: 121/145 libreoffice-7.2.1.2v0:neon-0.31.2: 122/145 libreoffice-7.2.1.2v0:mariadb-client-10.6.4v1: 123/145 libreoffice-7.2.1.2v0:nspr-4.32: 124/146 libreoffice-7.2.1.2v0:nss-3.71: 125/146 libreoffice-7.2.1.2v0:clucene-core-2.3.3.4p3: 126/146 libreoffice-7.2.1.2v0:harfbuzz-icu-3.0.0: 127/146 libreoffice-7.2.1.2v0:glm-0.9.8.5: 128/146 libreoffice-7.2.1.2v0:orc-0.4.29: 129/154 libreoffice-7.2.1.2v0:graphene-1.10.6: 130/154 libreoffice-7.2.1.2v0:cdparanoia-3.a9.8p4: 131/154 libreoffice-7.2.1.2v0:libogg-1.3.5: 132/155 libreoffice-7.2.1.2v0:libvorbis-1.3.7: 133/155 libreoffice-7.2.1.2v0:libtheora-1.2.20190601p0: 134/155 libreoffice-7.2.1.2v0:gstreamer1-1.18.5: 135/155 libreoffice-7.2.1.2v0:opus-1.3.1: 136/155 libreoffice-7.2.1.2v0:libpsl-0.21.1: 137/162 libreoffice-7.2.1.2v0:brotli-1.0.9p0: 138/162 libreoffice-7.2.1.2v0:libsoup-2.74.0: 139/162 libreoffice-7.2.1.2v0:libgpg-error-1.42: 140/164 libreoffice-7.2.1.2v0:libgcrypt-1.9.4: 141/164 libreoffice-7.2.1.2v0:libsecret-0.20.4: 142/164 libreoffice-7.2.1.2v0:libusb1-1.0.23p2: 143/170 libreoffice-7.2.1.2v0:libassuan-2.5.5: 144/170 libreoffice-7.2.1.2v0:pinentry-1.1.1: 145/170 libreoffice-7.2.1.2v0:libksba-1.6.0: 146/170 libreoffice-7.2.1.2v0:npth-1.6: 147/170 libreoffice-7.2.1.2v0:gnupg-2.2.30p0: 148/170 libreoffice-7.2.1.2v0:gcr-3.40.0: 149/170 libreoffice-7.2.1.2v0:libb2-0.98.1v0: 150/171 libreoffice-7.2.1.2v0:libarchive-3.5.2: 151/171 libreoffice-7.2.1.2v0:avahi-glib-0.8p0: 152/171 libreoffice-7.2.1.2v0:gvfs-1.48.1p1: 153/171 libreoffice-7.2.1.2v0:gstreamer1-plugins-base-1.18.5: 154/171 libreoffice-7.2.1.2v0:mozilla-dicts-en-GB-1.3p1: 155/172 libreoffice-7.2.1.2v0:hunspell-1.7.0: 156/172 libreoffice-7.2.1.2v0:cyrus-sasl-2.1.27p2: 157/173 libreoffice-7.2.1.2v0:openldap-client-2.4.59v0: 158/173 libreoffice-7.2.1.2v0:libyajl-2.1.0: 159/174 libreoffice-7.2.1.2v0:libxslt-1.1.34p1: 160/174 libreoffice-7.2.1.2v0:raptor-2.0.15p4: 161/174 libreoffice-7.2.1.2v0:e2fsprogs-1.46.2p0: 162/178 libreoffice-7.2.1.2v0:mpfr-4.1.0: 163/178 libreoffice-7.2.1.2v0:rasqal-0.9.33p2: 164/178 libreoffice-7.2.1.2v0:libltdl-2.4.2p2: 165/178 libreoffice-7.2.1.2v0:redland-1.0.17p6: 166/178 libreoffice-7.2.1.2v0:glew-2.2.0: 167/178 libreoffice-7.2.1.2v0: 168/178 useradd: Warning: home directory `/var/postgresql' doesn't exist, and -m was not specified postgresql-server-13.4p0: 169/178 youtube-dl-2021.06.06: 170/178 geeqie-1.6p0v0:libexif-0.6.23p0: 171/181 geeqie-1.6p0v0:exiftran-2.14: 172/181 geeqie-1.6p0v0:jbigkit-2.1: 173/184 geeqie-1.6p0v0:fftw3-common-3.3.8p1: 174/185 geeqie-1.6p0v0:fftw3-3.3.8p1: 175/185 geeqie-1.6p0v0:djvulibre-3.5.27p6: 176/185 geeqie-1.6p0v0:ImageMagick-6.9.12.19: 177/185 geeqie-1.6p0v0: 178/185 audacity-2.4.2:flac-1.3.3p0: 179/195 audacity-2.4.2:libmad-0.15.1bp6: 180/195 audacity-2.4.2:libsndfile-1.0.31: 181/206 audacity-2.4.2:libsamplerate-0.1.9: 182/206 audacity-2.4.2:sdl2-2.0.16: 183/206 audacity-2.4.2:x264-20210415: 184/206 audacity-2.4.2:libv4l-1.20.0p0: 185/206 audacity-2.4.2:libass-0.15.2: 186/206 audacity-2.4.2:libvpx-1.10.0v0: 187/206 audacity-2.4.2:speexdsp-1.2.0: 188/207 audacity-2.4.2:speex-1.2.0: 189/207 audacity-2.4.2:libvidstab-1.1.0: 190/207 audacity-2.4.2:gsm-1.0.19: 191/207 audacity-2.4.2:xvidcore-1.3.7: 192/207 libreoffice-7.2.1.2v0:lame-3.100p1: 193/207 ^^ libreoffice dependency report in the middle of audacity install audacity-2.4.2:ffmpeg-4.4p4v1: 193/207 audacity-2.4.2:portaudio-svn-1960: 194/207 audacity-2.4.2:libnotify-0.7.9: 195/209 audacity-2.4.2:libmspack-0.10.1alphav2: 196/209 audacity-2.4.2:wxWidgets-gtk3-3.0.5.1: 197/209 audacity-2.4.2:vamp-plugin-sdk-2.9.0: 198/209 audacity-2.4.2:portmidi-217p0: 199/209 audacity-2.4.2:libsoxr-0.1.3: 200/209 audacity-2.4.2:libid3tag-0.15.1bp5: 201/209 audacity-2.4.2:soundtouch-2.1.2: 202/209 audacity-2.4.2: 203/209 inkscape-1.0.2p0:gdl-3.40.0: 204/219 inkscape-1.0.2p0:double-conversion-3.1.5: 205/219 inkscape-1.0.2p0:libsigc++-2.10.7: 206/224 inkscape-1.0.2p0:cairomm-1.14.3: 207/224 inkscape-1.0.2p0:glib2mm-2.66.2: 208/224 inkscape-1.0.2p0:pangomm-2.46.1: 209/224 inkscape-1.0.2p0:atk2mm-2.28.2: 210/224 inkscape-1.0.2p0:gtk3mm-3.24.5: 211/224 inkscape-1.0.2p0:potrace-1.16: 212/224 inkscape-1.0.2p0:aspell-0.60.6.1p11: 213/224 inkscape-1.0.2p0:cblas-1.0p7: 214/225 inkscape-1.0.2p0:py3-numpy-1.16.5p2: 215/225 inkscape-1.0.2p0:liberation-fonts-2.00.1p1: 216/225 inkscape-1.0.2p0:py3-lxml-4.3.3p5: 217/225 inkscape-1.0.2p0:gsl-1.15p3: 218/225 inkscape-1.0.2p0:boehm-gc-8.0.4: 219/225 inkscape-1.0.2p0: 220/225 mpv-0.33.1p2:lua-5.1.5p7: 221/231 mpv-0.33.1p2:libcddb-1.3.2p0: 222/232 mpv-0.33.1p2:libcdio-2.1.0: 223/232 mpv-0.33.1p2:libcdio-paranoia-2.0.0: 224/232 mpv-0.33.1p2:libbluray-1.3.0p0: 225/232 mpv-0.33.1p2:libplacebo-3.120.3: 226
Re: pkg_add multiple package install weird output
I have another instance of this, maybe someone can look if it really is of interest. Somehow, the current package name is messed up. geda-0.1p1:gerbv-2.7.0p0: 184/194 geda-0.1p1:tcl-8.5.19p4: 185/199 geda-0.1p1:tk-8.5.19p1: 186/199 geda-0.1p1:gtkglext-1.2.0.20191219: 187/199 geda-0.1p1:gd-2.3.2: 188/199 geda-0.1p1:libsigsegv-2.12: 189/200 geda-0.1p1:m4-1.4.18p1: 190/200 geda-0.1p1:pcb-4.3.0v0: 191/200 geda-0.1p1:gnucap-0.35p9: 192/200 geda-0.1p1:iverilog-11.0p0: 193/200 geda-0.1p1:gtkwave-3.3.108: 194/200 geda-0.1p1:slib-3b4p0: 195/202 geda-0.1p1:guile-1.8.8p9: 196/202 geda-0.1p1:geda-gaf-1.6.0p21: 197/202 geda-0.1p1:ngspice-31: 198/202 geda-0.1p1: 199/202 qucs-s-0.0.22p0:qt4-4.8.7p25: 200/203 qucs-s-0.0.22p0: 201/203 avr-0.1p0:avr-binutils-2.30: 202/209 avr-0.1p0:libmpc-1.1.0: 203/210 avr-0.1p0:avr-gcc-5.4.0p3: 204/210 avr-0.1p0:avr-libc-2.0.0: 205/210 avr-0.1p0:libconfuse-3.2.2: 206/214 avr-0.1p0:libusb1-1.0.23p2: 207/214 avr-0.1p0:libftdi1-1.5: 208/214 avr-0.1p0:libusb-compat-0.1.5p0: 209/214 avr-0.1p0:avrdude-6.3: 210/214 avr-0.1p0:arduino-1.8.10v0: 211/214 avr-0.1p0:avr-gdb-6.8p10: 212/214 geda-0.1p1:simulavr-0.1.2.7p0: 213/214 ^^^ here is invoked another package name avr-0.1p0: 213/214 Old post included: > Hello, I use to run pkg_add with multiple package names, something like: pkg_add -vV gimp libreoffice geeqie audacity inkscape vlc mupdf I am sure gimp is ahead of vlc in the command line. I saw something strange in output: [ ... ] gimp-2.10.22p1:aalib-1.4p7: 63/78 gimp-2.10.22p1:OpenEXR-2.5.4: 64/78 gimp-2.10.22p1:py3-cairo-1.20.0p0: 65/81 gimp-2.10.22p1:py3-gobject3-3.38.0p1: 66/81 gimp-2.10.22p1:exiv2-0.27.2v0: 67/81 gimp-2.10.22p1:libgexiv2-0.12.1p2: 68/81 gimp-2.10.22p1: 69/81 ^ < gimp finish [ ... ] inkscape-1.0.1p0:aspell-0.60.6.1p10: 151/160 inkscape-1.0.1p0:liberation-fonts-2.00.1p1: 152/160 inkscape-1.0.1p0:potrace-1.16: 153/160 inkscape-1.0.1p0:double-conversion-3.1.5: 154/160 inkscape-1.0.1p0:gcc-libs-8.4.0p1: 155/164 inkscape-1.0.1p0:blas-3.8.0p0: 156/164 inkscape-1.0.1p0:lapack-3.8.0p1: 157/164 inkscape-1.0.1p0:cblas-1.0p7: 158/164 inkscape-1.0.1p0:py3-numpy-1.16.5p1: 159/164 inkscape-1.0.1p0: 160/164 vlc-3.0.11.1p0:libcddb-1.3.2p0: 161/184 vlc-3.0.11.1p0:sdl-1.2.15p10: 162/184 vlc-3.0.11.1p0:libtar-1.2.20: 163/184 vlc-3.0.11.1p0:libnfs-4.0.0: 164/184 vlc-3.0.11.1p0:libebml-1.4.0: 165/184 vlc-3.0.11.1p0:libdvdcss-1.4.2p1: 166/185 vlc-3.0.11.1p0:libdvdread-6.1.1: 167/185 vlc-3.0.11.1p0:dbus-glib-0.110p1v0: 168/189 vlc-3.0.11.1p0:geoclue-0.12.99p9: 169/189 vlc-3.0.11.1p0:libxkbcommon-1.0.3: 170/189 vlc-3.0.11.1p0:pcre2-10.35: 171/189 gimp-2.10.22p1:iodbc-3.52.12p1: 172/189 ^ vlc-3.0.11.1p0:qtbase-5.13.2p0: 172/189 vlc-3.0.11.1p0:qtsvg-5.13.2: 173/189 vlc-3.0.11.1p0:libsmb2-3.0.0: 174/189 vlc-3.0.11.1p0:libdvdnav-6.1.0v0: 175/189 vlc-3.0.11.1p0:libplacebo-2.72.2: 176/189 vlc-3.0.11.1p0:qtx11extras-5.13.2: 177/189 vlc-3.0.11.1p0:libdvbpsi-1.3.3: 178/189 vlc-3.0.11.1p0:libb2-0.98.1v0: 179/190 vlc-3.0.11.1p0:libarchive-3.5.1: 180/190 vlc-3.0.11.1p0:sdl-image-1.2.12p4: 181/190 vlc-3.0.11.1p0:libbluray-1.2.1: 182/190 vlc-3.0.11.1p0:libidn-1.36: 183/190 vlc-3.0.11.1p0:protobuf-3.13.0: 184/190 vlc-3.0.11.1p0:taglib-1.11.1p3: 185/190 vlc-3.0.11.1p0:libmatroska-1.6.2: 186/190 vlc-3.0.11.1p0: 187/190 [ ... ] Long after gimp install finish, there is an entry about gimp in the middle of vlc install. Is this fine? <
Re: pkg_add fails: 6.9 no such directory
On Thu, Apr 15, 2021 at 09:25:31PM +0100, Björn Gohla wrote: > > hi all, > > i'm on 6.9 current. installing any package (example below) fails since there > is > apparently no 6.9 release directory. what am i doin wrong? > > thanks for any hints. Try again like this: pkg_add -Dsnap gbc This forces installation from snapshots/packages instead of 6.9/packages. > titanic# pkg_add gbc > https://cdn.openbsd.org/pub/OpenBSD/6.9/packages/amd64/: no such dir > Can't find gbc
pkg_add fails: 6.9 no such directory
hi all, i'm on 6.9 current. installing any package (example below) fails since there is apparently no 6.9 release directory. what am i doin wrong? thanks for any hints. --- titanic# pkg_add gbc https://cdn.openbsd.org/pub/OpenBSD/6.9/packages/amd64/: no such dir Can't find gbc titanic# uname -a OpenBSD titanic.my.domain 6.9 GENERIC.MP#457 amd64 titanic# curl https://cdn.openbsd.org/pub/OpenBSD/ [...] ../ 06-Jan-2019 18:35 - 6.4/ 29-Oct-2018 10:29 - 6.5/ 11-Aug-2019 08:18 - 6.6/ 23-Oct-2019 10:54 - 6.7/ 18-May-2020 08:55 - 6.8/ 07-Feb-2021 18:58 - Changelogs/ 15-Apr-2021 11:32 - [...] titanic#
Re: Q: pkg_add fails with: TLS handshake failure: ocsp verify failed: Undefined error ...
On Fri, Mar 19, 2021 at 04:56:11PM +, Stuart Henderson wrote: > In gmane.os.openbsd.misc, li...@y42.org wrote: > > > > Hi All, > > > > What would cause pkg_add -u to report this error? > >> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: TLS handshake > >> failure: ocsp verify failed: Undefined error: 0 > >> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: empty > >> Couldn't find updates for ... a long list of (all?) installed packages ... > > > > Error 0? > > There is some problem doing OCSP validation. It validates OK with openssl > 1.0.2u and 1.1.1j but not with libressl. DFN run their own PKI and OCSP > responder so it might hit some edge case that isn't seen with other > responders. I missed a typo in tobhe's diff. This fixes it for me. Index: x509/x509_purp.c === RCS file: /cvs/src/lib/libcrypto/x509/x509_purp.c,v retrieving revision 1.3 diff -u -p -r1.3 x509_purp.c --- x509/x509_purp.c13 Mar 2021 23:01:49 - 1.3 +++ x509/x509_purp.c19 Mar 2021 17:21:29 - @@ -571,7 +571,7 @@ x509v3_cache_extensions(X509 *x) if (x->skid == NULL && i != -1) x->ex_flags |= EXFLAG_INVALID; x->akid = X509_get_ext_d2i(x, NID_authority_key_identifier, , NULL); - if (x->skid == NULL && i != -1) + if (x->akid == NULL && i != -1) x->ex_flags |= EXFLAG_INVALID; /* Does subject name match issuer? */
Re: Q: pkg_add fails with: TLS handshake failure: ocsp verify failed: Undefined error ...
In gmane.os.openbsd.misc, li...@y42.org wrote: > > Hi All, > > What would cause pkg_add -u to report this error? >> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: TLS handshake >> failure: ocsp verify failed: Undefined error: 0 >> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: empty >> Couldn't find updates for ... a long list of (all?) installed packages ... > > Error 0? There is some problem doing OCSP validation. It validates OK with openssl 1.0.2u and 1.1.1j but not with libressl. DFN run their own PKI and OCSP responder so it might hit some edge case that isn't seen with other responders. > That directory, on fau.de, is not empty. > > I have just rebooted after running sysupgrade to arrive at: >> OpenBSD mjoelnir.fritz.box 6.9 GENERIC.MP#416 amd64 > > And as my next step I wanted to then upgrade my installed packages. > > Did I miss something? pkg_add doesn't get a directory index from ftp(1), it's limited in what it can do at that point. Workarounds are, use http (packages are signed anyway) use a different mirror set FETCH_CMD="ftp -S noverifytime" in the environment which disables OCSP I've included certs below if someone wants to reproduce to debug it. $ openssl ocsp -sha1 -issuer fau-ca.crt -cert fau-cert.crt -url http://ocsp.pca.dfn.de/OCSP-Server/OCSP -text -CAfile fau-ca.crt -no_nonce [...] Response Verify Failure 3535329314880:error:27FFF065:OCSP routines:CRYPTO_internal:certificate verify error:/usr/src/lib/libcrypto/ocsp/ocsp_vfy.c:141:Verify error:error number 1 fau-cert.crt: good This Update: Mar 19 12:22:25 2021 GMT Next Update: Mar 26 12:22:25 2021 GMT $ eopenssl ocsp -sha1 -issuer fau-ca.crt -cert fau-cert.crt -header host ocsp.pca.dfn.de -url http://ocsp.pca.dfn.de/OCSP-Server/OCSP -text -CAfile fau-ca.crt -no_nonce Response verify OK fau-cert.crt: good This Update: Mar 19 12:22:25 2021 GMT Next Update: Mar 26 12:22:25 2021 GMT $ eopenssl11 ocsp -sha1 -issuer fau-ca.crt -cert fau-cert.crt -header host=ocsp.pca.dfn.de -url http://ocsp.pca.dfn.de/OCSP-Server/OCSP -text -CAfile fau-ca.crt -no_nonce Response verify OK fau-cert.crt: good This Update: Mar 19 12:22:25 2021 GMT Next Update: Mar 26 12:22:25 2021 GMT cat > fau-cert.crt << EOF -BEGIN CERTIFICATE- MIIKjTCCCXWgAwIBAgIMIKr6htHOf3G7wcorMA0GCSqGSIb3DQEBCwUAMIGNMQsw CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVz IERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4t UEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5 MDMxNTEwMjI1MVoXDTIxMDYxNjEwMjI1MVowgZMxCzAJBgNVBAYTAkRFMQ8wDQYD VQQIDAZCYXllcm4xETAPBgNVBAcMCEVybGFuZ2VuMTwwOgYDVQQKDDNGcmllZHJp Y2gtQWxleGFuZGVyLVVuaXZlcnNpdGFldCBFcmxhbmdlbi1OdWVybmJlcmcxDTAL BgNVBAsMBFJSWkUxEzARBgNVBAMMCmZ0cC5mYXUuZGUwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQDw/LdY8/DG14NOIDqtJOsi14DwF6O7DHw11fqYuJZ6 3OBGOdHBRkTtUe2thjUny0LanvFLmuHqPzpYpDRuayTd156Rdr6dD5BpokVK6O/P TzQSREYHX0VdGsqN5kLYSsXzVuYxjlWKLJxxWXDmKHQdYJpIePzIyrTM2Y9nQQKv tq4y7EKaj7vFkRtRrX0opnJat33kip/KaWiAFhbJCIIy7Tjuh2sPJXYy9jigQ9OP YLrzPNADkoUkOUaYp0LyUOcvIi4lY2/IdQZZfW59Lu9o8PcNSF262OFvTi55IoWP sbuY6/h88XvycB8eqZTvToXIf9siAa/Hbf7xmTLnllOcegE9v5K6B9FSiuBEgcNe bXFq0OTYHSjrqOzeohUa8b5n2M7kQyXi1bGjH/JwcnpAbjwkMK7rq3dWs7rnCBlN fvoW/aSqjKgg5SCphl6YuxD49LqC5NIKqdqH/TbCbiVsXd/guM0HrEkGiAeNmqr+ HKvkRsr3fL7vwKEkitpC4jIG6XoDpqQskeS5bhsl49Sl9VsMfGTbr73Iv+A57Z5e zQPjG0hBReC5bNP9DOoKYkGNzWMG7Z98sj6XmYO39Jpwo+GmXOX7dr2zQJ8lcTR6 J4uvNFZYDku2UC5Acm2+sbeibOApJCeZgwRUo9bGZx0DYZeHPKfoDwwiI6pqj20W NQIDAQABo4IF4zCCBd8wWQYDVR0gBFIwUDAIBgZngQwBAgIwDQYLKwYBBAGBrSGC LB4wDwYNKwYBBAGBrSGCLAEBBDARBg8rBgEEAYGtIYIsAQEEAwkwEQYPKwYBBAGB rSGCLAIBBAMJMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoG CCsGAQUFBwMBMB0GA1UdDgQWBBRIst54HQp2KRkBTizEsSfkuCsuZDAfBgNVHSME GDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDBEBgNVHREEPTA7ggpmdHAuZmF1LmRl ghhmdHAucnJ6ZS51bmktZXJsYW5nZW4uZGWCE2Z0cC51bmktZXJsYW5nZW4uZGUw gY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4t Y2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2Rw Mi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmww gdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2Eu ZGZuLmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAx LnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5j cnQwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWds b2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwggNcBgorBgEEAdZ5AgQCBIID TASCA0gDRgB1AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABaYDg Q5QDAEYwRAIgOHt1Qj3kWYPCYkOE+Yktck4NtASSAmwmyGJiAgUU0IECIE/f 4U8U/djAkLHekTpgIb/+2X/pvv2sZ7a8zr2PJd2zAHYAqucLfzy41WbIbC8Wl5yf RF9pqw60U1WJsvd6AwEE880AAAFpgOBD1AAABAMARzBFAiANnF5N+jUtfc3NXPwO 4f1hTuQR3k1uPXQClzVqDfPkvwIhAM1NePQ2Ba71eYhQcnm059HMCGHRP8wElbsV aAyCCOg2AHUAVYHUwhaQNgFK6gubVzxT8MDkOHhwJQgXL6OqHQcT0wwAAAFpgOBE lQAABAMARjBEAiB/jZNuQ4ctEzWi0evXQR4e0gwWb
Q: pkg_add fails with: TLS handshake failure: ocsp verify failed: Undefined error ...
Hi All, What would cause pkg_add -u to report this error? > https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: TLS handshake > failure: ocsp verify failed: Undefined error: 0 > https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: empty > Couldn't find updates for ... a long list of (all?) installed packages ... Error 0? That directory, on fau.de, is not empty. I have just rebooted after running sysupgrade to arrive at: > OpenBSD mjoelnir.fritz.box 6.9 GENERIC.MP#416 amd64 And as my next step I wanted to then upgrade my installed packages. Did I miss something? Cheers, Robb.
Re: snapshot of today, pkg_add -u changed behaviour
sven.falem...@gmail.com (Sven F.), 2021.02.24 (Wed) 19:04 (CET): > On Wed, Feb 24, 2021 at 12:06 PM Stuart Henderson > wrote: > > > > On 2021-02-24, Marcus MERIGHI wrote: > > > Hello! > > > > > > I just ugraded two machines to the snapshot of the day: > > > > > > OpenBSD 6.9-beta (GENERIC.MP) #357: Tue Feb 23 22:09:48 MST 2021 > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > When I run pkg_add -u afterwards, it just sits there, without output, > > > for an unusually long time. > > > > > > With ^T it says: Processing Parameters. > > > > > > After some minutes the usual output starts. > > > > > > Just thought I'd mention it here, in case someone is worried about not > > > seeing the familiar behaviour (as I was). > > > > > > Marcus > > > > > > > > > > Check for running ftp processes and you might get a better idea what > > it's doing. Do you have a slow connection to the mirror you're using? > > > > FETCH_CMD="ftp -v" pkg_add -u ? Thanks for your assistance, Sven and Stuart! It's just that ftp2.eu.openbsd.org is slow for me. As nothing in my environment had changed and the download of the base system didn't take longer than usual, I thought pkg_add(1) might be doing something differently. speedtest-cli says 20 Mbit/s download speed, while lynx http://ftp2.eu.openbsd.org/pub/OpenBSD//snapshots/packages/amd64/ takes ages. FETCH_CMD="ftp -v" did not make much of a difference, as it's the initial ftp -v -o - http://ftp2.eu.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ that takes so long (I'm ctrl-c'ing it after 10 minutes right now, on my third machine to upgrade.) ftp.hostserver.de to the rescue... Sorry for the noise! Marcus
Re: snapshot of today, pkg_add -u changed behaviour
On Wed, Feb 24, 2021 at 12:06 PM Stuart Henderson wrote: > > On 2021-02-24, Marcus MERIGHI wrote: > > Hello! > > > > I just ugraded two machines to the snapshot of the day: > > > > OpenBSD 6.9-beta (GENERIC.MP) #357: Tue Feb 23 22:09:48 MST 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > When I run pkg_add -u afterwards, it just sits there, without output, > > for an unusually long time. > > > > With ^T it says: Processing Parameters. > > > > After some minutes the usual output starts. > > > > Just thought I'd mention it here, in case someone is worried about not > > seeing the familiar behaviour (as I was). > > > > Marcus > > > > > > Check for running ftp processes and you might get a better idea what > it's doing. Do you have a slow connection to the mirror you're using? > FETCH_CMD="ftp -v" pkg_add -u ? -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: snapshot of today, pkg_add -u changed behaviour
On 2021-02-24, Marcus MERIGHI wrote: > Hello! > > I just ugraded two machines to the snapshot of the day: > > OpenBSD 6.9-beta (GENERIC.MP) #357: Tue Feb 23 22:09:48 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > When I run pkg_add -u afterwards, it just sits there, without output, > for an unusually long time. > > With ^T it says: Processing Parameters. > > After some minutes the usual output starts. > > Just thought I'd mention it here, in case someone is worried about not > seeing the familiar behaviour (as I was). > > Marcus > > Check for running ftp processes and you might get a better idea what it's doing. Do you have a slow connection to the mirror you're using?
snapshot of today, pkg_add -u changed behaviour
Hello! I just ugraded two machines to the snapshot of the day: OpenBSD 6.9-beta (GENERIC.MP) #357: Tue Feb 23 22:09:48 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP When I run pkg_add -u afterwards, it just sits there, without output, for an unusually long time. With ^T it says: Processing Parameters. After some minutes the usual output starts. Just thought I'd mention it here, in case someone is worried about not seeing the familiar behaviour (as I was). Marcus
Re: pkg_add and an authenticating proxy
that is what I get for not keeping up to date. I have been using FETCH_CMD for a number of years to get through authenticating proxy, never bothered to see if support was added to fetch.c On Thu, Feb 11, 2021 at 3:18 PM Stuart Henderson wrote: > > On 2021-02-11, Stephan Mending wrote: > > I'm a dork. I actually tried that but forgot to set "keepenv" in doas.conf. > > :| > > This is fairly recent, jca fixed ftp to do http over an authenticated proxy > last year >
Re: pkg_add and an authenticating proxy
On 2021-02-11, Stephan Mending wrote: > I'm a dork. I actually tried that but forgot to set "keepenv" in doas.conf. :| This is fairly recent, jca fixed ftp to do http over an authenticated proxy last year
Re: pkg_add and an authenticating proxy
I'm a dork. I actually tried that but forgot to set "keepenv" in doas.conf. :| Thank you anyway for pointing me at it ! Best regards ! On Thu, Feb 11, 2021 at 05:03:59PM -0300, Fabio Martins wrote: > > Works here for me: > > export http_proxy="http://user:password@127.0.0.1:/; && pkg_add -nu > > > Hi, > > I was wondering if there was any way on how to allow pkg_add to use an > > authenticating http-proxy ? Unluckily I cannot > > find any documentation on the matter. > > > > Thanks alot so far. > > > > Best regards, > > Stephan > > > > > > > -- > Fabio Martins > PHOSPHORUS NETWORKS > https://phosphorusnetworks.com/ >
Re: pkg_add and an authenticating proxy
Works here for me: export http_proxy="http://user:password@127.0.0.1:/; && pkg_add -nu > Hi, > I was wondering if there was any way on how to allow pkg_add to use an > authenticating http-proxy ? Unluckily I cannot > find any documentation on the matter. > > Thanks alot so far. > > Best regards, > Stephan > > -- Fabio Martins PHOSPHORUS NETWORKS https://phosphorusnetworks.com/
Re: pkg_add and an authenticating proxy
try using a different command to fetch packages. take a look at man pkg_add(1) FETCH_CMD I just ran into this issue at work. I dug into fetch.c to see what it would take to extend system ftp, but ran out of cycles On Wed, Feb 10, 2021 at 2:27 PM Stephan Mending wrote: > > Hi, > I was wondering if there was any way on how to allow pkg_add to use an > authenticating http-proxy ? Unluckily I cannot > find any documentation on the matter. > > Thanks alot so far. > > Best regards, > Stephan
pkg_add and an authenticating proxy
Hi, I was wondering if there was any way on how to allow pkg_add to use an authenticating http-proxy ? Unluckily I cannot find any documentation on the matter. Thanks alot so far. Best regards, Stephan
pkg_add multiple package install weird output
Hello, I use to run pkg_add with multiple package names, something like: pkg_add -vV gimp libreoffice geeqie audacity inkscape vlc mupdf I am sure gimp is ahead of vlc in the command line. I saw something strange in output: [ ... ] gimp-2.10.22p1:aalib-1.4p7: 63/78 gimp-2.10.22p1:OpenEXR-2.5.4: 64/78 gimp-2.10.22p1:py3-cairo-1.20.0p0: 65/81 gimp-2.10.22p1:py3-gobject3-3.38.0p1: 66/81 gimp-2.10.22p1:exiv2-0.27.2v0: 67/81 gimp-2.10.22p1:libgexiv2-0.12.1p2: 68/81 gimp-2.10.22p1: 69/81 ^ < gimp finish [ ... ] inkscape-1.0.1p0:aspell-0.60.6.1p10: 151/160 inkscape-1.0.1p0:liberation-fonts-2.00.1p1: 152/160 inkscape-1.0.1p0:potrace-1.16: 153/160 inkscape-1.0.1p0:double-conversion-3.1.5: 154/160 inkscape-1.0.1p0:gcc-libs-8.4.0p1: 155/164 inkscape-1.0.1p0:blas-3.8.0p0: 156/164 inkscape-1.0.1p0:lapack-3.8.0p1: 157/164 inkscape-1.0.1p0:cblas-1.0p7: 158/164 inkscape-1.0.1p0:py3-numpy-1.16.5p1: 159/164 inkscape-1.0.1p0: 160/164 vlc-3.0.11.1p0:libcddb-1.3.2p0: 161/184 vlc-3.0.11.1p0:sdl-1.2.15p10: 162/184 vlc-3.0.11.1p0:libtar-1.2.20: 163/184 vlc-3.0.11.1p0:libnfs-4.0.0: 164/184 vlc-3.0.11.1p0:libebml-1.4.0: 165/184 vlc-3.0.11.1p0:libdvdcss-1.4.2p1: 166/185 vlc-3.0.11.1p0:libdvdread-6.1.1: 167/185 vlc-3.0.11.1p0:dbus-glib-0.110p1v0: 168/189 vlc-3.0.11.1p0:geoclue-0.12.99p9: 169/189 vlc-3.0.11.1p0:libxkbcommon-1.0.3: 170/189 vlc-3.0.11.1p0:pcre2-10.35: 171/189 gimp-2.10.22p1:iodbc-3.52.12p1: 172/189 ^ vlc-3.0.11.1p0:qtbase-5.13.2p0: 172/189 vlc-3.0.11.1p0:qtsvg-5.13.2: 173/189 vlc-3.0.11.1p0:libsmb2-3.0.0: 174/189 vlc-3.0.11.1p0:libdvdnav-6.1.0v0: 175/189 vlc-3.0.11.1p0:libplacebo-2.72.2: 176/189 vlc-3.0.11.1p0:qtx11extras-5.13.2: 177/189 vlc-3.0.11.1p0:libdvbpsi-1.3.3: 178/189 vlc-3.0.11.1p0:libb2-0.98.1v0: 179/190 vlc-3.0.11.1p0:libarchive-3.5.1: 180/190 vlc-3.0.11.1p0:sdl-image-1.2.12p4: 181/190 vlc-3.0.11.1p0:libbluray-1.2.1: 182/190 vlc-3.0.11.1p0:libidn-1.36: 183/190 vlc-3.0.11.1p0:protobuf-3.13.0: 184/190 vlc-3.0.11.1p0:taglib-1.11.1p3: 185/190 vlc-3.0.11.1p0:libmatroska-1.6.2: 186/190 vlc-3.0.11.1p0: 187/190 [ ... ] Long after gimp install finish, there is an entry about gimp in the middle of vlc install. Is this fine?
Re: pkg_add version scripting ?
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 1 November 2020 12:53, Marc Espie wrote: > On Sun, Nov 01, 2020 at 12:23:44PM +, Laura Smith wrote: > > > Hi > > As far as I can tell from the docs, only pkg_info supports spec style ? > > I am trying to script an OpenBSD setup and as part of that certain packages > > need to be installed. For most packages that is not a problem, however, for > > example, with gnupg, there are two versions in the 6.8 repo : > > gnupg-1.4.23p4.tgz > > gnupg-2.2.23p0.tgz > > I cannot seem to find a way to tell pkg_add to install >=2 (or better > > still, install "the latest" version). > > "Better still" to be discussed. > > Newer is not always better, especially when some things stop working and > stuff like that. > > It's generally considered that scripting is meant to give you a reliable > system... > > > Any ideas ? > > You should read pkg_add(1) more closely. > > pkg_add also understands ‘stems’, that is, package names without any > version specification. For instance, with ‘pkg_add kdelibs’, pkg_add > will look in the current directory (or the PKG_PATH) for a kdelibs > package. > > pkg_add may ask questions in interactive mode, or error out otherwise. > Interactive mode is the default on a tty, see options -I/i. > > For instance ‘pkg_add screen’ is ambiguous as it matches screen-4.03p6 > and screen-4.03p6-shm. > > To avoid ambiguities, pkg_add supports ‘stems with flavors’, that is, a > stem separated from flavors with a double dash. For instance, the > previous ambiguity could be resolved by using ‘pkg_add screen--’ (matches > only the empty flavor) or ‘pkg_add screen--shm’ (matches only the shm > flavor). > > There is also an ambiguity related to ports with multiple branches. For > instance ‘pkg_add python’ is ambiguous, as there are several versions of > python in the ports tree. So is ‘pkg_add postfix’. The special form > ‘pkgname%branch’ can be used to restrict matches to a branch matching the > pkgpath(7). > > The above ambiguities can be resolved using ‘pkg_add postfix%stable’ and > ‘pkg_add python%3.4’, respectively. > > stuff like pkg_add gnupg%gnupg and pkg_add gnupg%gnupg2 > in 6.8, with possibly a bit more to take care of flavors as well. > > (note that pkg_info -z will give you the exact specs you want) I did actually try "pkg_add gnupg%2" but pkg_add didn't like that. Will go try "pkg_add gnupg%gnupg2" instead
pkg_add version scripting ?
Hi As far as I can tell from the docs, only pkg_info supports spec style ? I am trying to script an OpenBSD setup and as part of that certain packages need to be installed. For most packages that is not a problem, however, for example, with gnupg, there are two versions in the 6.8 repo : gnupg-1.4.23p4.tgz gnupg-2.2.23p0.tgz I cannot seem to find a way to tell pkg_add to install >=2 (or better still, install "the latest" version). Any ideas ? Laura
Re: pkg_add version scripting ?
On 2020-11-01, Laura Smith wrote:
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Sunday, 1 November 2020 12:53, Marc Espie wrote:
>
>> On Sun, Nov 01, 2020 at 12:23:44PM +, Laura Smith wrote:
>>
>> > Hi
>> > As far as I can tell from the docs, only pkg_info supports spec style ?
>> > I am trying to script an OpenBSD setup and as part of that certain
>> > packages need to be installed. For most packages that is not a problem,
>> > however, for example, with gnupg, there are two versions in the 6.8 repo :
>> > gnupg-1.4.23p4.tgz
>> > gnupg-2.2.23p0.tgz
>> > I cannot seem to find a way to tell pkg_add to install >=2 (or better
>> > still, install "the latest" version).
>>
>> "Better still" to be discussed.
>>
>> Newer is not always better, especially when some things stop working and
>> stuff like that.
>>
>> It's generally considered that scripting is meant to give you a reliable
>> system...
>>
>> > Any ideas ?
>>
>> You should read pkg_add(1) more closely.
>>
>> pkg_add also understands ‘stems’, that is, package names without any
>> version specification. For instance, with ‘pkg_add kdelibs’, pkg_add
>> will look in the current directory (or the PKG_PATH) for a kdelibs
>> package.
>>
>> pkg_add may ask questions in interactive mode, or error out otherwise.
>> Interactive mode is the default on a tty, see options -I/i.
>>
>> For instance ‘pkg_add screen’ is ambiguous as it matches screen-4.03p6
>> and screen-4.03p6-shm.
>>
>> To avoid ambiguities, pkg_add supports ‘stems with flavors’, that is, a
>> stem separated from flavors with a double dash. For instance, the
>> previous ambiguity could be resolved by using ‘pkg_add screen--’ (matches
>> only the empty flavor) or ‘pkg_add screen--shm’ (matches only the shm
>> flavor).
>>
>> There is also an ambiguity related to ports with multiple branches. For
>> instance ‘pkg_add python’ is ambiguous, as there are several versions of
>> python in the ports tree. So is ‘pkg_add postfix’. The special form
>> ‘pkgname%branch’ can be used to restrict matches to a branch matching the
>> pkgpath(7).
>>
>> The above ambiguities can be resolved using ‘pkg_add postfix%stable’ and
>> ‘pkg_add python%3.4’, respectively.
>>
>> stuff like pkg_add gnupg%gnupg and pkg_add gnupg%gnupg2
>> in 6.8, with possibly a bit more to take care of flavors as well.
>>
>> (note that pkg_info -z will give you the exact specs you want)
>
>
>
> I did actually try "pkg_add gnupg%2" but pkg_add didn't like that. Will go
> try "pkg_add gnupg%gnupg2" instead
The exact string you want depends on the subdirectory name used in
ports. This varies between ports - some ports are laid out like
ports/category/name/{1,2} and others ports/category/{name,name2}.
Note that for gnupg this changes after 6.8 because the old 1.x port
has been removed so there's now only gnupg 2.x.
Re: pkg_add version scripting ?
On Sun, Nov 01, 2020 at 12:59:22PM +, Laura Smith wrote: > > > I did actually try "pkg_add gnupg%2" but pkg_add didn't like that. Will go > try "pkg_add gnupg%gnupg2" instead The branches are directly picked from the pkgpath in the ports tree. It's the one case where they have an actual meaning for end user. and there are good reasons to use them (some ports have stable and snapshot branches)
Re: pkg_add version scripting ?
On Sun, Nov 01, 2020 at 12:23:44PM +, Laura Smith wrote: > Hi > > As far as I can tell from the docs, only pkg_info supports spec style ? > > I am trying to script an OpenBSD setup and as part of that certain packages > need to be installed. For most packages that is not a problem, however, for > example, with gnupg, there are two versions in the 6.8 repo : > gnupg-1.4.23p4.tgz > gnupg-2.2.23p0.tgz > > I cannot seem to find a way to tell pkg_add to install >=2 (or better still, > install "the latest" version). "Better still" to be discussed. Newer is not always better, especially when some things stop working and stuff like that. It's generally considered that scripting is meant to give you a reliable system... > Any ideas ? You should read pkg_add(1) more closely. pkg_add also understands ‘stems’, that is, package names without any version specification. For instance, with ‘pkg_add kdelibs’, pkg_add will look in the current directory (or the PKG_PATH) for a kdelibs package. pkg_add may ask questions in interactive mode, or error out otherwise. Interactive mode is the default on a tty, see options -I/i. For instance ‘pkg_add screen’ is ambiguous as it matches screen-4.03p6 and screen-4.03p6-shm. To avoid ambiguities, pkg_add supports ‘stems with flavors’, that is, a stem separated from flavors with a double dash. For instance, the previous ambiguity could be resolved by using ‘pkg_add screen--’ (matches only the empty flavor) or ‘pkg_add screen--shm’ (matches only the shm flavor). There is also an ambiguity related to ports with multiple branches. For instance ‘pkg_add python’ is ambiguous, as there are several versions of python in the ports tree. So is ‘pkg_add postfix’. The special form ‘pkgname%branch’ can be used to restrict matches to a branch matching the pkgpath(7). The above ambiguities can be resolved using ‘pkg_add postfix%stable’ and ‘pkg_add python%3.4’, respectively. stuff like pkg_add gnupg%gnupg and pkg_add gnupg%gnupg2 in 6.8, with possibly a bit more to take care of flavors as well. (note that pkg_info -z will give you the exact specs you want)
pkg_add man page doesn't document default path properly
Hi misc@, (Sent here instead of bugs@ in case I'm missing something obvious.) The pkg_add(1) man page claims the default path (if [TRUSTED_]_PKG_PATH are unset) is "./:installpath", where "‘installpath’ refers to the contents of installurl(5)". As far as I can tell, the default path is actually something like "(content of /etc/installurl)/%c/packages/%a", or perhaps something involving %m. Is this an error in the man page, or did I miss something? (And why is there a "./" before ":installpath"?) (It would be nice if the pkg_add man page, and maybe https://www.openbsd.org/faq/faq15.html , said prominently that the packages downloaded depend on the OpenBSD flavour you have installed. I was trying to figure out whether that was the case or whether it just downloads "latest" packages by default whether or not I'm on a release. Neither page seems to give a straightforward answer. Eventually I figured it out by looking at the output of pkg_info.) -- James (previously jc...@cs.berkeley.edu)
Re: TLS stall ftp or pkg_add
On Sat, 18 Jul 2020 at 20:01, Kevin Chadwick wrote: > > Has anyone else noticed stalls when using a https link in /etc/installurl. In a qemu guest in user mode networking, which is notoriously not very efficient: oc@OpenBSD:~$ uname -sr OpenBSD 6.6 oc@OpenBSD:~$ cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD oc@OpenBSD:~$ doas pkg_add bzip2 quirks-3.187 signed on 2020-05-19T14:41:48Z bzip2-1.0.8: ok No stalls here. -- Ottavio Caruso
Re: TLS stall ftp or pkg_add
I think that machine is badly filtered. I don't think it is our problem. Kevin Chadwick wrote: > Has anyone else noticed stalls when using a https link in /etc/installurl. > > I found that downloading the following file works fine in Chrome but stalls at > 128K every time via ftp before completing a significant time later. > > https://ftp.heanet.ie/pub/OpenBSD/snapshots/packages/amd64/bzip2-1.0.8.tgz > > It also downloads without stalling via ftp as an http link. >
TLS stall ftp or pkg_add
Has anyone else noticed stalls when using a https link in /etc/installurl. I found that downloading the following file works fine in Chrome but stalls at 128K every time via ftp before completing a significant time later. https://ftp.heanet.ie/pub/OpenBSD/snapshots/packages/amd64/bzip2-1.0.8.tgz It also downloads without stalling via ftp as an http link.
Re: Forgetting pkg_add -u after sysupgrade can cause ansible msyscall errors
On Sun, May 31, 2020 at 08:19:18PM +0200, Jurjen Oskam wrote: > Hi, > > For the sake of the archives and future search engine users, I'll share what > can happen when you use sysupgrade to upgrade your OpenBSD host but then > forget to run update your installed packages. (Yep, silly mistake, I know...) > > After upgrading my Ansible host to 6.7, I noticed that each ansible command > outputted the following error, but it continued normally after that: > > msyscall 1ba41d145000 a5000 error > > The second word varied with each invocation, and I did not notice any other > adverse effects on that box. The error occurred with all ansible commands, > such as ansible, ansible-playbook and ansible-connection. > > I was >< this close to sending a help request to this list, but I realized > I had not tried to see what would happen on a freshly installed 6.7 box. > It was then that I noticed that the new box had ansible-2.9.7 and > python-3.7.7, while the upgraded box had ansible-2.7.9 and python-3.6.8p0. > This caused me to realize I had forgotten to update my packages after doing > the sysupgrade... A quick "pkg_add -u" later and my problem was gone. D'oh! > > So, moral of the story: don't forget to update your packages after a > sysupgrade. Heh Always a good idea. msyscall was kind of a "flag day". In case you don't know, most anything dynamic that uses syscalls has to go through a specific area in libc now, it makes all kinds of attacks more complex. Some of us running current went through similar burps in case we forgot. I must say, I'm happy I added @tag support a while back, this made this specific package update much less painful.
Forgetting pkg_add -u after sysupgrade can cause ansible msyscall errors
Hi, For the sake of the archives and future search engine users, I'll share what can happen when you use sysupgrade to upgrade your OpenBSD host but then forget to run update your installed packages. (Yep, silly mistake, I know...) After upgrading my Ansible host to 6.7, I noticed that each ansible command outputted the following error, but it continued normally after that: msyscall 1ba41d145000 a5000 error The second word varied with each invocation, and I did not notice any other adverse effects on that box. The error occurred with all ansible commands, such as ansible, ansible-playbook and ansible-connection. I was >< this close to sending a help request to this list, but I realized I had not tried to see what would happen on a freshly installed 6.7 box. It was then that I noticed that the new box had ansible-2.9.7 and python-3.7.7, while the upgraded box had ansible-2.7.9 and python-3.6.8p0. This caused me to realize I had forgotten to update my packages after doing the sysupgrade... A quick "pkg_add -u" later and my problem was gone. D'oh! So, moral of the story: don't forget to update your packages after a sysupgrade. Regards, Jurjen Oskam
