Re: editors/libreoffice: fix with poppler-24.10.0
ok On 22/10/24 20:15 +0200, Matthias Kilian wrote: > Fix build with poppler-24.10.0. > > ok? > > Ciao, > Kili > > Index: patches/patch-sdext_source_pdfimport_xpdfwrapper_pdfioutdev_gpl_cxx > === > RCS file: patches/patch-sdext_source_pdfimport_xpdfwrapper_pdfioutdev_gpl_cxx > diff -N patches/patch-sdext_source_pdfimport_xpdfwrapper_pdfioutdev_gpl_cxx > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-sdext_source_pdfimport_xpdfwrapper_pdfioutdev_gpl_cxx > 22 Oct 2024 18:04:36 - > @@ -0,0 +1,17 @@ > +Fix build with poppler-24.10.0. > + > +Index: sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx > +--- sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx.orig > sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx > +@@ -1306,9 +1306,9 @@ poppler_bool PDFOutDev::tilingPatternFill(GfxState *st > + 0, nBitmapWidth * nBitmapHeight, Object(objNull))); > + auto aDecode = Object(objNull); > + std::unique_ptr pRgbIdentityColorMap(new > GfxImageColorMap(8, &aDecode, > +-new GfxDeviceRGBColorSpace())); > ++std::unique_ptr (new GfxDeviceRGBColorSpace(; > + std::unique_ptr pGrayIdentityColorMap(new > GfxImageColorMap(8, &aDecode, > +-new GfxDeviceGrayColorSpace())); > ++std::unique_ptr (new GfxDeviceGrayColorSpace(; > + > + OutputBuffer aBuf; initBuf(aBuf); > + writePng_(aBuf, pRgbStr.get(), nBitmapWidth, nBitmapHeight, > pRgbIdentityColorMap.get(), -- Regards, Robert Nagy
Re: fix configure for editors/libreoffice on arm64 openbsd
ah that fucker again, of course On 21/09/24 21:47 GMT, Peter Hessler wrote: > configure: error: Unsupported host_cpu aarch64 for host_os openbsd7.6 > > Looks like a merge error in the last update. openbsd_aarch64 slipped up > into the netbsd*) block, move it back to the openbsd block. > > OK for 7.6? > > > > Index: editors/libreoffice/patches/patch-configure > === > RCS file: /cvs/openbsd/ports/editors/libreoffice/patches/patch-configure,v > diff -u -p -u -p -r1.72 patch-configure > --- editors/libreoffice/patches/patch-configure 17 Sep 2024 16:27:53 > - 1.72 > +++ editors/libreoffice/patches/patch-configure 21 Sep 2024 18:27:35 > - > @@ -11,7 +11,7 @@ Index: configure > using_x11=yes > PTHREAD_CFLAGS="-D_THREAD_SAFE" > PTHREAD_LIBS="-pthread" > -@@ -15375,6 +15378,11 @@ linux-android*) > +@@ -15408,6 +15411,11 @@ openbsd*) > P_SEP=: > > case "$host_cpu" in > > > -- > Never offend people with style when you can offend them with substance. > -- Sam Brown, "The Washington Post", January 26, 1977 -- Regards, Robert Nagy
Re: net/zabbix server readme
commited,, thanks On 11/09/24 16:29 GMT, Renaud Allard wrote: > Hello, > > With the current readme for zabbix server, it creates the MySQL database > with "character set utf8", but this throws an error in zabbix "Unsupported > charset or collation for tables". > This should be changed to "character set utf8mb4 collate utf8mb4_bin" > Patch attached > > Best Regards -- Regards, Robert Nagy
Re: Small issue with net/zabbix web
Hi I think the default config should be ammended to reflect the default openbsd behaviour. Do you want to come up with a patch? On 11/09/24 16:11 GMT, Renaud Allard wrote: > Hello, > > When I install the package zabbix-web, it installs the file > /var/www/zabbix/conf/zabbix.conf.php with some default variables. So, by > default, it tries to connect to MySQL DB on default unix socket without any > password. This means that if you try to run https://server/zabbix/setup.php > (without having MySQL listening on a unix socket without password), it will > throw a custom error "no such file or directory". This is extremely hard to > debug why because it doesn't log any useful error message and doesn't relate > to database. Also, there is no mention of that in the package README file. > > Since the preferred way of configuring zabbix seems to be through setup.php, > it might be a good idea to remove that default config to prevent clueless > errors. Or maybe at least mention it in the package README. > > What do you think? > > Best Regards -- Regards, Robert Nagy
Re: [update] www/nginx 1.26.2
ok
On 19/08/24 15:50 GMT, Stuart Henderson wrote:
> ok
>
> On 2024/08/19 11:10, Landry Breuil wrote:
> > Le Mon, Aug 19, 2024 at 10:43:59AM +0200, Landry Breuil a écrit :
> > > hi,
> > >
> > > simple update:
> > > *) Security: processing of a specially crafted mp4 file by the
> > >ngx_http_mp4_module might cause a worker process crash
> > >(CVE-2024-7347).
> > >
> > > builds fine here
> >
> > updated diff after stuart's commit
> >
>
> > ? nginx-1.18.0.diff
> > ? nginx-mjs.diff
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/www/nginx/Makefile,v
> > diff -u -r1.183 Makefile
> > --- Makefile19 Aug 2024 08:50:45 - 1.183
> > +++ Makefile19 Aug 2024 09:08:20 -
> > @@ -19,11 +19,9 @@
> > COMMENT-stream=nginx TCP/UDP proxy module
> > COMMENT-xslt= nginx XSLT filter module
> >
> > -VERSION= 1.26.1
> > +VERSION= 1.26.2
> > DISTNAME= nginx-${VERSION}
> > CATEGORIES=www
> > -REVISION-main= 2
> > -REVISION= 1
> >
> > PKGNAME-main= ${DISTNAME}
> > PKGNAME-cache_purge= nginx-cache_purge-${VERSION}
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/www/nginx/distinfo,v
> > diff -u -r1.87 distinfo
> > --- distinfo19 Aug 2024 08:50:45 - 1.87
> > +++ distinfo19 Aug 2024 09:08:20 -
> > @@ -4,7 +4,7 @@
> > SHA256 (leev-ngx_http_geoip2_module-3.4.tar.gz) =
> > rXL8IzSNcVozCZSYRTH6ubNgbhYEgyNnN/mkppV9lFI=
> > SHA256 (nbs-system-naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz)
> > = 2+IXdBFFfxy6mO5Gc84xh2mUrQa9zl7MDuZjhO8OQg4=
> > SHA256 (nginx-1.20.1-chroot.patch) =
> > SS1TB0j8N4/dn5pUTGT6WvkN3aAUuKz5+R0Nt+MG0gk=
> > -SHA256 (nginx-1.26.1.tar.gz) = +Rh0aP8usVkmC/1Thnwl/44zRyYjes8ie56HDlPT42s=
> > +SHA256 (nginx-1.26.2.tar.gz) = Yn/ghiCbuoCihToK3Z2VjX673/oahGeleEyaa08D1zg=
> > SHA256
> > (nginx-modules-ngx_http_hmac_secure_link_module-48c4625fbbf51ed5a95bfec23fa444f6c3702e50.tar.gz)
> > = ZXpA2rODS1enIREzlD1OqWwpWcv3NOUXH4eUOgOAmqg=
> > SHA256 (nginx-njs-0.8.4.tar.gz) =
> > /hl+JUIEwV6fHfCs83Wt1XvjQWkB7I17hzGdzLSQ+Q0=
> > SHA256 (openresty-headers-more-nginx-module-v0.34.tar.gz) =
> > DA0s7SzolbP0XrKyMM2QUIqyp3MpnxU94UpD5EwSCbM=
> > @@ -16,7 +16,7 @@
> > SIZE (leev-ngx_http_geoip2_module-3.4.tar.gz) = 8877
> > SIZE (nbs-system-naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) =
> > 237272
> > SIZE (nginx-1.20.1-chroot.patch) = 8783
> > -SIZE (nginx-1.26.1.tar.gz) = 1244738
> > +SIZE (nginx-1.26.2.tar.gz) = 1244789
> > SIZE
> > (nginx-modules-ngx_http_hmac_secure_link_module-48c4625fbbf51ed5a95bfec23fa444f6c3702e50.tar.gz)
> > = 6159
> > SIZE (nginx-njs-0.8.4.tar.gz) = 743910
> > SIZE (openresty-headers-more-nginx-module-v0.34.tar.gz) = 28827
>
--
Regards,
Robert Nagy
lyx 2.4.1 crashes at startup (including patch)
Hi, on -current LyX crashes at startup with "Abort trap" and writes "backwards memcpy" into /var/log/messages. Exchanging memcpy in src/support/gzstream.cpp helps. (Tested with manually applying the patches from ports to downloaded source on 7.5 and newly sysupgraded snapshot.) I successfully started LyX, created a document, compiled, viewed and saved it. My patch to gzstream.cpp below. Best regards Robert --- src/support/gzstream.cpp.orig Sun Aug 18 18:41:04 2024 +++ src/support/gzstream.cppSun Aug 18 18:41:28 2024 @@ -32,7 +32,7 @@ #include #ifdef HAVE_STRING_H -# include // for memcpy +# include // for memmove #endif using namespace std; @@ -92,7 +92,7 @@ int n_putback = gptr() - eback(); if ( n_putback > 4) n_putback = 4; -memcpy( buffer + (4 - n_putback), gptr() - n_putback, n_putback); +memmove( buffer + (4 - n_putback), gptr() - n_putback, n_putback); int num = gzread( file, buffer+4, bufferSize-4); if (num <= 0) // ERROR or EOF
Re: Chromium VAAPI support
On 07/08/24 17:46 GMT, José Maldonado wrote: > El mié, 7 ago 2024 a la(s) 5:39 p.m., Theo de Raadt > (dera...@openbsd.org) escribió: > > > > This is so backwards. > > > > What do you expect to happen? Oh robert will commit it, without any > > testing. Oh and only he should work on it, right? Noone else needs > > to, they can just sit on the mailing list and ask "when?" > > > > Yes there is a reason. It is one guy doing it all, and asking is > > NOT ACTUALLY HELPING. Think about it. > > > > > > José Maldonado wrote: > > > > > Hi everyone! > > > > > > Seeing the progress of VAAPI support in OpenBSD + Firefox, yesterday I > > > wanted to take a look at VAAPI support in Chromium. Checking the > > > Chromium dev site, I see that there are a couple of options that need > > > to be enabled to achieve this, and checking the port I see that they > > > are currently disabled. > > > > > > More precisely the option in question is: > > > > > > GN_ARGS+= use_vaapi=false > > > > > > Is there a reason that blocks VAAPI activation in Chromium at this > > > point? Thanks for your response. > > > > > > -- > > > "Dios en su Cielo, todo bien en la Tierra" > > > *** > > > > > I agree with that Theo, but that's exactly why I'm asking, to find out > if there are any known issues, not to put pressure on it. > > I understand that Robert is the only one working on that port, in > fact, I CC'd him so he can respond if there's any problem with it. > > Anyway, right now I'm compiling the port with use_vaapi=true to test > and report any issues. It will fail quiet early in the configure stage. We are using an external libvpx from ports and not the bundled one because we have patches for BTI and it only makes sense to use that instead of copying the patches all over. vaapi needs the internal copy of to build the vp8-9 encoders and decoders and that is broken at the moment. I will look into this once I am back from holidays.
Re: SDL2 libs names
Zitat von Thomas Frohwein :
On Fri, Aug 02, 2024 at 09:25:41AM +0200, Robert Palm wrote:
Quoting Thomas Frohwein :
> On Wed, Jul 31, 2024 at 09:48:31PM +0200, Robert Palm wrote:
> >
> > Hi,
> >
> > I would like to know why, the following libs are named
> >
> > libSDL2_image.so.1.1
> > libSDL2_ttf.so.0.1
> >
> > and not
> >
> > libSDL2_image-2.0.so.0
> > libSDL2_ttf-2.0.so.0
> >
> > Ports:
> > devel/sdl2-image
> > devel/sdl2_ttf
> >
> > Is it because of CMAKE_SHARED_LIBRARY_SUFFIX ? How does it work?
> >
> > Thank you.
> >
>
> As to the why in the sense of the reason for the decision - this
> decision was made before my time. My understanding is that upstream
> decision to append '-2.0' didn't serve a useful purpose (SDL2 in the
> library name really tells you everything and at this point it looks
> like the next version will be SDL3).
>
> Also note the comment in CMakeLists.txt:
>
> # For historical reasons, the library name redundantly includes the major
> # version twice: libSDL2-2.0.so.0.
>
> As to the technical why - the port uses configure/Makefile and the patch
> for Makefile.in removes the use of LT_RELEASE which is responsible for
> the '-2.0' in other platforms.
>
> This is for devel/sdl2, probably similar for the sdl2-* ports. At this
> point this is moot as upstream has already acknowledged that this
> library naming will be stopped with SDL3.
Hi Thomas,
understand - thanks a lot for your detailed explanations!
I'll simply use symlinks so that the sdl2 libs can be found...typically,
they are refered to by the 2 "standard" designators like
("libSDL2_ttf-2.0.so.0" "libSDL2_ttf")
("libSDL2_image-2.0.so.0" "libSDL2_image")
Looking forward for SDL3 then.
Best, Robert
Not sure what project this is referring to... as long as this is open
source, you can probably patch it to dlopen 'libSDL2_ttf.so' without
the version suffix and same for SDL2_image, as jsg@ pointed out.
Thanks again jsg@ and thfr@.
https://github.com/Failproofshark/cl-sdl2-ttf
https://github.com/lispgames/cl-sdl2-image
I can work around it, but was interested why it's "different"...
Re: SDL2 libs names
Quoting Thomas Frohwein :
On Wed, Jul 31, 2024 at 09:48:31PM +0200, Robert Palm wrote:
Hi,
I would like to know why, the following libs are named
libSDL2_image.so.1.1
libSDL2_ttf.so.0.1
and not
libSDL2_image-2.0.so.0
libSDL2_ttf-2.0.so.0
Ports:
devel/sdl2-image
devel/sdl2_ttf
Is it because of CMAKE_SHARED_LIBRARY_SUFFIX ? How does it work?
Thank you.
As to the why in the sense of the reason for the decision - this
decision was made before my time. My understanding is that upstream
decision to append '-2.0' didn't serve a useful purpose (SDL2 in the
library name really tells you everything and at this point it looks
like the next version will be SDL3).
Also note the comment in CMakeLists.txt:
# For historical reasons, the library name redundantly includes the major
# version twice: libSDL2-2.0.so.0.
As to the technical why - the port uses configure/Makefile and the patch
for Makefile.in removes the use of LT_RELEASE which is responsible for
the '-2.0' in other platforms.
This is for devel/sdl2, probably similar for the sdl2-* ports. At this
point this is moot as upstream has already acknowledged that this
library naming will be stopped with SDL3.
Hi Thomas,
understand - thanks a lot for your detailed explanations!
I'll simply use symlinks so that the sdl2 libs can be
found...typically, they are refered to by the 2 "standard" designators
like
("libSDL2_ttf-2.0.so.0" "libSDL2_ttf")
("libSDL2_image-2.0.so.0" "libSDL2_image")
Looking forward for SDL3 then.
Best, Robert
SDL2 libs names
Hi, I would like to know why, the following libs are named libSDL2_image.so.1.1 libSDL2_ttf.so.0.1 and not libSDL2_image-2.0.so.0 libSDL2_ttf-2.0.so.0 Ports: devel/sdl2-image devel/sdl2_ttf Is it because of CMAKE_SHARED_LIBRARY_SUFFIX ? How does it work? Thank you.
Re: [update] devel/intellij to 2024.1.4
Well, can we update to 2024.1.4, please? Am 26. Juni 2024, 13:25, um 13:25, "Kirill A. Korinsky" schrieb: >On Wed, 26 Jun 2024 09:30:58 +0100, >Robert Palm wrote: >> >> Using current version idea-IC-241.14494.240 I see some messages in >the >> console at startup. Maybe the JNA warning is something to look at? >Other >> warnings seem IDE related... >> >> >> 2024-06-26 10:19:46,572 [ 71] WARN - #c.i.p.i.b.AppStarter - >> Unable to load JNA library (os=OpenBSD 7.5, >> jna.boot.library.path=/usr/local/intellij/lib/jna/amd64) >> java.lang.UnsatisfiedLinkError: Unable to locate JNA native support >library >> at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:1014) >> >> > >Well, the problem is that IDEA doesn't support OpenBSD. Or at least it >seems >so by examining the JNA sources [1]. Probably a Linux version can be >ported >... but after that we should rebuild IDEA from scratch. > >So fsNotifier depends on /proc [2] and seems to be very Linux specific. > >And frankly speaking I see that only fsNotifier and LinuxGlobalMenu can >be >ported, everything else is MacOS or Windows specific. > >Footnotes: >[1] https://github.com/JetBrains/intellij-community/tree/master/native > >[2] >https://github.com/JetBrains/intellij-community/blob/master/native/fsNotifier/linux/inotify.c > >-- >wbr, Kirill
Re: nginx: imrpove compatibiliy with unwind and
go ahead
On 04/07/24 12:27 GMT, Kirill A. Korinsky wrote:
> ports@, Robert,
>
> I'd like to ping about this trivial patch that allows me to use nginx with
> unwind for last weeks.
>
> Additionally, I had added ngx_cache_purge as new subpackage which brings
> qutie stable module https://github.com/FRiCKLE/ngx_cache_purge which allows
> to purge some elements of cache via HTTP request. I don't include it into
> default build, and build it as dynamic module.
>
> The original point about unwind patch:
>
> On Sat, 15 Jun 2024 12:09:21 +0100,
> Kirill A. Korinsky wrote:
> >
> > ports@
> >
> > Here a trivial patch which improves compatibility with unwind.
> >
> > I'm using the following unwind.config:
> >
> > preference { recursor oDoT-autoconf }
> >
> > forwarder { 172.31.2.1 }
> >
> > force accept bogus forwarder {
> > some.internal.domain
> > }
> >
> > where 172.31.2.1 is Unifi GW and nginx is configured as:
> >
> > server {
> > listen 127.0.0.1:80;
> >
> > resolver127.0.0.1;
> >
> > set $nas_uri
> > "http://nas.some.internal.domain";;
> >
> > location / {
> > proxy_pass $nas_uri;
> > }
> > }
> >
> > it can't be used due errors in log:
> >
> > 2024/06/15 11:53:55 [error] 30452#0: invalid UDP DNS response 49184
> > fl:81A0
> > 2024/06/15 11:54:00 [error] 30452#0: invalid UDP DNS response 30883
> > fl:81A0
> > 2024/06/15 11:54:00 [error] 30452#0: invalid UDP DNS response 49184
> > fl:81A0
> > 2024/06/15 11:54:05 [error] 30452#0: invalid UDP DNS response 30883
> > fl:81A0
> >
> > because nginx rejects response with enabled AD bit.
> >
>
> And, finally, the diff:
>
> diff --git www/nginx/Makefile www/nginx/Makefile
> index 7d86279085c..203e8aa3fc5 100644
> --- www/nginx/Makefile
> +++ www/nginx/Makefile
> @@ -17,15 +17,17 @@ COMMENT-njs= nginx javascript scripting
> module
> COMMENT-passenger= nginx passenger (ruby/python/nodejs) integration module
> COMMENT-rtmp=nginx module for RTMP streaming
> COMMENT-securelink= nginx HMAC secure link module
> +COMMENT-cache_purge= nginx module which adds ability to purge cache content
>
> VERSION= 1.26.1
> DISTNAME=nginx-${VERSION}
> CATEGORIES= www
> -REVISION-main= 0
> +REVISION-main= 1
> REVISION-passenger= 0
>
> VERSION-njs= 0.8.2
> VERSION-rtmp=1.2.1
> +VERSION-cache_purge= 2.3
>
> PKGNAME-main=${DISTNAME}
> PKGNAME-image_filter=nginx-image_filter-${VERSION}
> @@ -42,6 +44,7 @@ PKGNAME-njs=nginx-njs-${VERSION}
> PKGNAME-passenger= nginx-passenger-${VERSION}
> PKGNAME-rtmp=nginx-rtmp-${VERSION}
> PKGNAME-securelink= nginx-securelink-${VERSION}
> +PKGNAME-cache_purge= ngx_cache_purge-${VERSION}
>
> ONLY_FOR_ARCHS-passenger= aarch64 amd64 arm i386
>
> @@ -59,7 +62,8 @@ _GH_MODS= \
> nginx njs ${VERSION-njs} \
> simpl ngx_devel_kit v0.3.0 \
> leevngx_http_geoip2_module 3.3 \
> - nginx-modules ngx_http_hmac_secure_link_module
> 48c4625fbbf51ed5a95bfec23fa444f6c3702e50
> + nginx-modules ngx_http_hmac_secure_link_module
> 48c4625fbbf51ed5a95bfec23fa444f6c3702e50 \
> + FRiCKLE ngx_cache_purge ${VERSION-cache_purge}
>
> .for _a _p _c in ${_GH_MODS}
> DISTFILES.a+=${_p}-{${_a}/${_p}/archive/}${_c}.tar.gz
> @@ -76,7 +80,7 @@ MULTI_PACKAGES =-main -naxsi -perl ${MODULE_PACKAGES}
>
> MODULE_PACKAGES =-image_filter -geoip2 -xslt -mailproxy -stream \
> -passenger -headers_more -ldap_auth -lua -njs \
> - -rtmp -securelink
> + -rtmp -securelink -cache_purge
>
> FLAVOR ?=
> PSEUDO_FLAVORS = no_lua no_njs no_passenger
> @@ -100,6 +104,7 @@ WANTLIB-headers_more=
> WANTLIB-perl=c m perl
> WANTLIB-passenger= m pthread ${COMPILER_LIBCXX}
> WANTLIB-securelink= crypto
> +WANTLIB-cache_purge=
>
> LIB_DEPENDS-main=devel/pcre2
> LIB_DEPENDS-xslt=textproc/libxml \
> @@ -114,6 +119,7 @@ LIB_DEPENDS-securelink=
> LIB_DEPENDS-njs= devel/pcre2 \
> textproc/libxslt \
> textproc/libxml
> +LIB_
Re: [update] devel/intellij to 2024.1.4
Using current version idea-IC-241.14494.240 I see some messages in the console at startup. Maybe the JNA warning is something to look at? Other warnings seem IDE related... 2024-06-26 10:19:46,572 [ 71] WARN - #c.i.p.i.b.AppStarter - Unable to load JNA library (os=OpenBSD 7.5, jna.boot.library.path=/usr/local/intellij/lib/jna/amd64) java.lang.UnsatisfiedLinkError: Unable to locate JNA native support library at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:1014) 2024-06-26 10:19:50,807 [ 4306] SEVERE - #c.i.o.e.c.i.EditorColorsManagerImpl - id is not specified for extension /schemes/classic-no-italics java.lang.Throwable: id is not specified for extension /schemes/classic-no-italics at com.intellij.openapi.diagnostic.Logger.error(Logger.java:376) 2024-06-26 10:19:50,857 [ 4356] SEVERE - #c.i.o.e.c.i.EditorColorsManagerImpl - id is not specified for extension /schemes/machine-no-italics java.lang.Throwable: id is not specified for extension /schemes/machine-no-italics at com.intellij.openapi.diagnostic.Logger.error(Logger.java:376) 2024-06-26 10:19:50,889 [ 4388] SEVERE - #c.i.o.e.c.i.EditorColorsManagerImpl - id is not specified for extension /schemes/octagon-no-italics java.lang.Throwable: id is not specified for extension /schemes/octagon-no-italics at com.intellij.openapi.diagnostic.Logger.error(Logger.java:376) 2024-06-26 10:19:50,899 [ 4398] SEVERE - #c.i.o.e.c.i.EditorColorsManagerImpl - id is not specified for extension /schemes/ristretto-no-italics java.lang.Throwable: id is not specified for extension /schemes/ristretto-no-italics at com.intellij.openapi.diagnostic.Logger.error(Logger.java:376) 2024-06-26 10:19:50,908 [ 4407] SEVERE - #c.i.o.e.c.i.EditorColorsManagerImpl - id is not specified for extension /schemes/spectrum-no-italics java.lang.Throwable: id is not specified for extension /schemes/spectrum-no-italics at com.intellij.openapi.diagnostic.Logger.error(Logger.java:376) 2024-06-26 10:19:50,922 [ 4421] SEVERE - #c.i.o.e.c.i.EditorColorsManagerImpl - id is not specified for extension /schemes/default-no-italics java.lang.Throwable: id is not specified for extension /schemes/default-no-italics at com.intellij.openapi.diagnostic.Logger.error(Logger.java:376) 2024-06-26 10:19:52,825 [ 6324] SEVERE - #c.i.s.ComponentManagerImpl - Unknown OS [Plugin: com.jetbrains.codeWithMe] com.intellij.diagnostic.PluginException: Unknown OS [Plugin: com.jetbrains.codeWithMe] at com.intellij.serviceContainer.ServiceInstanceInitializer.createInstance$suspendImpl(ServiceInstanceInitializer.kt:53) 2024-06-26 10:20:33,104 [ 46603] SEVERE - #c.j.r.p.c.CodeWithMeCleanup - Unknown OS java.lang.IllegalStateException: Unknown OS at com.intellij.remoteDev.OsRegistryConfigProvider.get(OsRegistryConfigProvider.kt:51) Quoting Lucas Raab : Hello, Here's a lightly tested update for intellij to 2024.1.4. Other tests? changelogs: https://blog.jetbrains.com/idea/2024/04/intellij-idea-2024-1-1/ https://blog.jetbrains.com/idea/2024/05/intellij-idea-2024-1-2/ https://blog.jetbrains.com/idea/2024/06/intellij-idea-2024-1-3/ https://blog.jetbrains.com/idea/2024/06/intellij-idea-2024-1-4/ Thanks, Lucas
Re: import devel/rust-bindgen v0.69.4
ok and thanks On 13/06/24 09:32 GMT, Sebastien Marie wrote: > Hi, > > I would like to import devel/rust-bindgen, a cli utility to generate > Rust interface from C (or some C++) headers. > > It is using llvm to read/parse C files (libclang.so). > > The library is loaded at runtime, but the binary doesn't automatically > find it (/usr/local/llvmXX/lib path isn't a standard one). So I moved > the binary to libexec and created a small shell wrapper to autodetect > the library path. It is still possible to manually override the library > path using environment variable. > > I didn't set any devel/llvm version in RUN_DEPENDS as it is working with > all versions (so I don't force installing a specific version). > > It could be done differently if requested. > > All tests are passing (tested on amd64). > > Comments or OK ? > -- > Sebastien Marie > -- Regards, Robert Nagy
Re: www/nginx: add mjs to mime.types for nextcloud ?
would not hurt, goahead
On 02/06/24 10:57 GMT, Landry Breuil wrote:
> hi,
>
> as discussed for httpd in https://marc.info/?t=17161976911&r=1&w=2
> (but apparently didnt get commited ?), same thing for nginx.
>
> i have it locally in the nextcould vhost but ...
>
> discussed upstream in https://trac.nginx.org/nginx/ticket/2216 but
> apparently that hasn't been commited (neither in freenginx)
>
> note that im not entering the heated 'text/javascript' vs
> 'application/javascript' discussions from
> https://trac.nginx.org/nginx/ticket/1407 /
> https://mailman.nginx.org/pipermail/nginx-devel/2022-May/7PN54GRH2S4ESBBTUTGZDXEKPEZGCWOJ.html
>
> i'd trust the commitees but.. *shrug*
>
> https://developer.mozilla.org/en-US/docs/Learn/Server-side/Configuring_server_MIME_types
>
> Landry
> ? nginx-1.18.0.diff
> ? nginx-mjs.diff
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/nginx/Makefile,v
> diff -u -r1.179 Makefile
> --- Makefile 30 May 2024 12:41:00 - 1.179
> +++ Makefile 2 Jun 2024 08:51:26 -
> @@ -21,6 +21,7 @@
> VERSION= 1.26.1
> DISTNAME=nginx-${VERSION}
> CATEGORIES= www
> +REVISION-main= 0
>
> VERSION-njs= 0.8.2
> VERSION-rtmp=1.2.1
> Index: patches/patch-conf_mime_types
> ===
> RCS file: /cvs/ports/www/nginx/patches/patch-conf_mime_types,v
> diff -u -r1.6 patch-conf_mime_types
> --- patches/patch-conf_mime_types 30 May 2022 08:17:35 - 1.6
> +++ patches/patch-conf_mime_types 2 Jun 2024 08:51:26 -
> @@ -1,7 +1,17 @@
> +chunk 1: https://trac.nginx.org/nginx/ticket/2216
> +
> Index: conf/mime.types
> --- conf/mime.types.orig
> +++ conf/mime.types
> -@@ -58,6 +58,7 @@ types {
> +@@ -3,6 +3,7 @@ types {
> + text/htmlhtml htm shtml;
> + text/css css;
> + text/xml xml;
> ++text/javascript mjs;
> + image/gifgif;
> + image/jpeg jpeg jpg;
> + application/javascript js;
> +@@ -58,6 +59,7 @@ types {
> application/x-java-archive-diff jardiff;
> application/x-java-jnlp-file jnlp;
> application/x-makeself run;
> @@ -9,7 +19,7 @@
> application/x-perl pl pm;
> application/x-pilot prc pdb;
> application/x-rar-compressed rar;
> -@@ -78,6 +79,7 @@ types {
> +@@ -78,6 +80,7 @@ types {
> application/octet-stream iso img;
> application/octet-stream msi msp msm;
>
> @@ -17,7 +27,7 @@
> audio/midi mid midi kar;
> audio/mpeg mp3;
> audio/oggogg;
> -@@ -92,6 +94,7 @@ types {
> +@@ -92,6 +95,7 @@ types {
> video/webm webm;
> video/x-flv flv;
> video/x-m4v m4v;
--
Regards,
Robert Nagy
Re: [update] nginx 1.26.1
ok
On 30/05/24 12:29 GMT, Landry Breuil wrote:
> yo,
>
> list of changes:
>
> *) Security: when using HTTP/3, processing of a specially crafted QUIC
>session might cause a worker process crash, worker process memory
>disclosure on systems with MTU larger than 4096 bytes, or might have
>potential other impact (CVE-2024-32760, CVE-2024-31079,
>CVE-2024-35200, CVE-2024-34161).
>Thanks to Nils Bars of CISPA.
>
> *) Bugfix: reduced memory consumption for long-lived requests if "gzip",
>"gunzip", "ssi", "sub_filter", or "grpc_pass" directives are used.
>
> *) Bugfix: nginx could not be built by gcc 14 if the --with-atomic
>option was used.
>Thanks to Edgar Bonet.
>
> *) Bugfix: in HTTP/3.
>
> ok ?
> ? nginx-1.18.0.diff
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/nginx/Makefile,v
> diff -u -r1.178 Makefile
> --- Makefile 17 May 2024 12:36:29 - 1.178
> +++ Makefile 30 May 2024 10:27:53 -
> @@ -18,7 +18,7 @@
> COMMENT-rtmp=nginx module for RTMP streaming
> COMMENT-securelink= nginx HMAC secure link module
>
> -VERSION= 1.26.0
> +VERSION= 1.26.1
> DISTNAME=nginx-${VERSION}
> CATEGORIES= www
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/www/nginx/distinfo,v
> diff -u -r1.84 distinfo
> --- distinfo 27 Apr 2024 07:24:04 - 1.84
> +++ distinfo 30 May 2024 10:27:53 -
> @@ -2,7 +2,7 @@
> SHA256 (lua-nginx-module-v0.10.11.tar.gz) =
> wPuR/P0cbn3sNMpkgm74H/66/e9hdNJURnY284BWZiY=
> SHA256 (naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) =
> 2+IXdBFFfxy6mO5Gc84xh2mUrQa9zl7MDuZjhO8OQg4=
> SHA256 (nginx-1.20.1-chroot.patch) =
> SS1TB0j8N4/dn5pUTGT6WvkN3aAUuKz5+R0Nt+MG0gk=
> -SHA256 (nginx-1.26.0.tar.gz) = 0ubIQ51sbbUBXY6qskcKtSrvhae/NjGCh5l34IQ3BJc=
> +SHA256 (nginx-1.26.1.tar.gz) = +Rh0aP8usVkmC/1Thnwl/44zRyYjes8ie56HDlPT42s=
> SHA256 (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) =
> aQxOW9sq4ZsP7nXNNW0YATRo20cmFrYJeloLvjRshGQ=
> SHA256 (nginx-rtmp-module-v1.2.1.tar.gz) =
> h6pZdACwtaBSdO4tI9jLgiThJoYiegq+MdeDs6ZF6jc=
> SHA256 (ngx_devel_kit-v0.3.0.tar.gz) =
> iOBamainQZBm9a51lm+x78QJutRSLRSYbaB0VUrmFhk=
> @@ -13,7 +13,7 @@
> SIZE (lua-nginx-module-v0.10.11.tar.gz) = 616653
> SIZE (naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) = 237272
> SIZE (nginx-1.20.1-chroot.patch) = 8783
> -SIZE (nginx-1.26.0.tar.gz) = 1244118
> +SIZE (nginx-1.26.1.tar.gz) = 1244738
> SIZE (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) =
> 18542
> SIZE (nginx-rtmp-module-v1.2.1.tar.gz) = 519919
> SIZE (ngx_devel_kit-v0.3.0.tar.gz) = 66455
--
Regards,
Robert Nagy
Re: [maintainer update] x11/copyq
Any suggestions? Robert Bagdan ezt írta (időpont: 2024. márc. 17., V, 12:39): > > Hi, > I updated copyq to 8.0.0, built without problem, works fine for me. > > Changelog: > > # Added > - Tab item limit has been increased to 100,000 (#1144). > - New macOS builds for M1/arm64 architectures are available (#1884). > - New Debian/Raspbian builds for arm/arm64 architectures are available. > - Allows overriding item activation using `paste()`. > - Allows overriding script functions to handle some events: items > added/removed/changed (`onItemsAdded()`, `onItemsRemoved()`, > `onItemsChanged()`), tab items loaded (`onItemsLoaded()`), tab > selected (`onTabSelected()`) (#59). > - Allows to cancel removing items by overriding `onItemsRemoved()` > script function. If the exit code is non-zero (for example `fail()` is > called), items will not be removed. But this can also cause a new > items not to be added if the tab is full. > - Allows overriding current clipboard owner > (`currentClipboardOwner()`) used by the clipboard monitor process. By > default it uses `currentWindowTitle()`. > - Allows using Ctrl+C to copy items even if search entry box is > focused unless it has a selection (#2440). > - Linux: Adds build option to disable X11 support (`cmake > -DWITH_X11=OFF ...`) (#2532). > - Linux: Adds build option to disable autostart which is useful mainly > for Flatpak builds (#2517, #2518). > > # Changed > - Windows binaries (which are 64 bit) are now by default installed to > "Program Files" instead of incorrect "Program Files (X86)". After > installing the new version, the **old path must be manually removed**. > - Windows and macOS builds are now based on newer Qt 6. > - Avoids accessing clipboard from password managers (#2282, #2495, > #2500). This disallows storing and processing such data. > Specifically, the clipboard is ignored if it contains following data: > `Clipboard Viewer Ignore` on Windows, > `application/x-nspasteboard-concealed-type` on macOS, > `x-kde-passwordManagerHint` with `secret` value on Linux. > - Large data items in tabs are now stored in separate location unless > Synchronize or Encryption plugins are active for the tab. This allows > storing more items in tabs while using less memory. The data path can > be printed via `copyq info data` command and overridden using > `COPYQ_ITEM_DATA_PATH` environment variable. To disable this > functionality use `copyq config item_data_threshold -1` - the default > value is 1024 and items larger than this amount of bytes are stored in > the separate location. > - Command dialog now shows advanced properties for built-in commands > allowing to copy the command line to set global shortcut in system. > - Global shortcuts are now also visible in menus (#2382). > - Avoids pasting all image formats as new item. > - Display commands are now applied to tray menu items too. > - Linux: Last stored text item is updated from any new mouse selection > only if the item content matches the start or the end of the selection > (but not the middle like previously). This may avoid some unexpected > item updates. > - Updates icon font from Font-Awesome 6.5.1. > > # Fixed > - Fixes drag'n'drop ordering for plugins and commands. This could have > caused a missing icon, app crash or various inconsistencies. > - Fixes managing keys with gpg 2.1 and above (#2463, #1208). > - Fixes creating duplicate item with Synchronize plugin when adding a > tag for example (#2355). > - Fixes conflicting notes and text with Synchronize plugin (#2355) > - Fixes deleted global object after running scripts (#2542). > - Wayland: Fixes copying images to another app instance. > > > Regards, > kikadf -- kikadf
Re: [NEW] net/megacmd
I updated megacmd to 1.7.0 release (with sdk-4.31.0b). Official
changelog or release notes not available. I use the new release on
OpenBSD-7.5 amd64, works fine.
Robert Bagdan ezt írta (időpont: 2023. jún. 26.,
H, 17:25):
>
> Removed sdk/configure patch which removes the stdc++fs check, add .if
> ${PROPERTIES:Mclang} + sed to the Makefile as post-patch.
>
> Stuart Henderson ezt írta (időpont: 2023. jún.
> 23., P, 18:02):
> >
> > On 2023/06/23 17:37, Robert Bagdan wrote:
> > > >
> > > > can replicate the linking failure, but haven't looked into it.
> > > >
> > >
> > > I patched the configure script of sdk to not add -lstdc++fs as
> > > LDFLAGS, I hope this fixes the linking error.
> > > I think you have installed gcc so the configure script found
> > > libstdc++fs, which is causing the linking error. #fixme
> > >
> > >
> > > --
> > > kikadf
> >
> > ah, that might need to be made conditional, presumably it is needed if
> > you build on an arch which doesn't use clang.
> >
> > easiest way is probably to use sed rather than a patch and do e.g.
> >
> > .include
> > .if ${PROPERTIES:Mclang}
> > post-extract:
> > sed -i <...>
> > .endif
> >
>
>
> --
> kikadf
--
kikadf
megacmd-1.7.0.tar.gz
Description: application/gzip
Re: [NEW] btop++
Morning ports
did this made it into the source tree, already ?
Thanks.
Quoting Jos Dehaes :
Thanks Stuart! This works. Can it be included in the ports tree now?
Cheers,
Jos
On Mon, 8 Apr 2024 at 17:07, Stuart Henderson wrote:
Attached.
On 2024/04/06 21:57, Jos Dehaes wrote:
> Hi,
>
> With the 7.5 release, I tried again, and finally btop now builds with
attached port. However,
> I'm struggling with the PLIST file, it seems the fake install is messing
up the prefix
> somehow.
>
> Can someone help?
>
> Cheers,
> Jos
>
> On Tue, 5 Sept 2023 at 19:59, Stuart Henderson
wrote:
>
> On 2023/09/05 15:58, Stuart Henderson wrote:
> > On 2023/09/05 16:34, Jos Dehaes wrote:
> > > Hi,
> > >
> > > I want to add the btop port. I used a package from the tech
mailing list by
> > > Stuart Henderson as a base. The problem is that btop needs to be
compiled
> > > with C++20 compiler. He suggested using clang 16, but I could
not get that
> > > to work.
> > >
> > > I just used the native g++ detection in the btop Makefile, and
this works,
> > > provided that g++ version 11 is installed. I could not find a
way to encode
> > > that in the port.
> > >
> > > Kindly provide guidance on how to get this included.
> > >
> > > Cheers,
> > > Jos
> >
> > As I said before, GCC 11 cannot be used as a build dependency in
ports.
> >
> > The clang 16 bits in the tree are very new, wait for it to settle
a bit.
> >
>
> the attached tar does build with clang 16 but it still fails:
>
> c++ -std=c++20 -pthread -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS
-D_FILE_OFFSET_BITS=64
> -fexceptions -fstack-clash-protection -fcf-protection
-fstack-protector -lkvm -O2
> -ftree-vectorize -flto=thin -Wall -Wextra -pedantic -isystem include
-Isrc -MMD -c -o obj/
> btop.o src/btop.cpp
> clang-16: warning: -lkvm: 'linker' input unused
[-Wunused-command-line-argument]
> clang-16: warning: argument unused during compilation:
'-fstack-clash-protection'
> [-Wunused-command-line-argument]
> In file included from src/btop.cpp:47:
> src/btop_tools.hpp:159:48: error: no member named 'count_if' in
namespace 'std::ranges'
> return (wide ? wide_ulen(str) :
std::ranges::count_if(str, [](char c) {
> return (static_cast(c) & 0xC0) != 0x80; }));
> ~^
> src/btop_tools.hpp:179:16: error: no member named 'for_each' in
namespace 'std::ranges'
> std::ranges::for_each(str, [](auto& c) { c =
::toupper(c); } );
> ~^
> src/btop_tools.hpp:185:16: error: no member named 'for_each' in
namespace 'std::ranges'
> std::ranges::for_each(str, [](char& c) { c =
::tolower(c); } );
> ~^
> src/btop_tools.hpp:214:10: error: no member named 'distance' in
namespace 'std::ranges';
> did you mean 'std::distance'?
> return std::ranges::distance(vec.begin(),
std::ranges::find(vec,
> find_val));
>^
>std::distance
> /usr/include/c++/v1/__iterator/distance.h:47:1: note:
'std::distance' declared here
> distance(_InputIter __first, _InputIter __last)
> ^
> 4 errors generated.
>
>
Re: 7.5: www/ungoogled-chromium is missing a lib
On 05/04/24 15:11 +0200, Solène Rapenne wrote: > on a fresh 7.5 > > $ ungoogled-chromium > ld.so: ungoogled-chromium: can't load library 'libvpx.so.17.0' > > installing libvpx package seems to solve, but chromim instantly reboots my > computer > but the port has a dependency on libvpx and if it reboots instantly, i think you might have a hardware issue
[maintainer update] x11/copyq
Hi,
I updated copyq to 8.0.0, built without problem, works fine for me.
Changelog:
# Added
- Tab item limit has been increased to 100,000 (#1144).
- New macOS builds for M1/arm64 architectures are available (#1884).
- New Debian/Raspbian builds for arm/arm64 architectures are available.
- Allows overriding item activation using `paste()`.
- Allows overriding script functions to handle some events: items
added/removed/changed (`onItemsAdded()`, `onItemsRemoved()`,
`onItemsChanged()`), tab items loaded (`onItemsLoaded()`), tab
selected (`onTabSelected()`) (#59).
- Allows to cancel removing items by overriding `onItemsRemoved()`
script function. If the exit code is non-zero (for example `fail()` is
called), items will not be removed. But this can also cause a new
items not to be added if the tab is full.
- Allows overriding current clipboard owner
(`currentClipboardOwner()`) used by the clipboard monitor process. By
default it uses `currentWindowTitle()`.
- Allows using Ctrl+C to copy items even if search entry box is
focused unless it has a selection (#2440).
- Linux: Adds build option to disable X11 support (`cmake
-DWITH_X11=OFF ...`) (#2532).
- Linux: Adds build option to disable autostart which is useful mainly
for Flatpak builds (#2517, #2518).
# Changed
- Windows binaries (which are 64 bit) are now by default installed to
"Program Files" instead of incorrect "Program Files (X86)". After
installing the new version, the **old path must be manually removed**.
- Windows and macOS builds are now based on newer Qt 6.
- Avoids accessing clipboard from password managers (#2282, #2495,
#2500). This disallows storing and processing such data.
Specifically, the clipboard is ignored if it contains following data:
`Clipboard Viewer Ignore` on Windows,
`application/x-nspasteboard-concealed-type` on macOS,
`x-kde-passwordManagerHint` with `secret` value on Linux.
- Large data items in tabs are now stored in separate location unless
Synchronize or Encryption plugins are active for the tab. This allows
storing more items in tabs while using less memory. The data path can
be printed via `copyq info data` command and overridden using
`COPYQ_ITEM_DATA_PATH` environment variable. To disable this
functionality use `copyq config item_data_threshold -1` - the default
value is 1024 and items larger than this amount of bytes are stored in
the separate location.
- Command dialog now shows advanced properties for built-in commands
allowing to copy the command line to set global shortcut in system.
- Global shortcuts are now also visible in menus (#2382).
- Avoids pasting all image formats as new item.
- Display commands are now applied to tray menu items too.
- Linux: Last stored text item is updated from any new mouse selection
only if the item content matches the start or the end of the selection
(but not the middle like previously). This may avoid some unexpected
item updates.
- Updates icon font from Font-Awesome 6.5.1.
# Fixed
- Fixes drag'n'drop ordering for plugins and commands. This could have
caused a missing icon, app crash or various inconsistencies.
- Fixes managing keys with gpg 2.1 and above (#2463, #1208).
- Fixes creating duplicate item with Synchronize plugin when adding a
tag for example (#2355).
- Fixes conflicting notes and text with Synchronize plugin (#2355)
- Fixes deleted global object after running scripts (#2542).
- Wayland: Fixes copying images to another app instance.
Regards,
kikadf
Index: x11/copyq/Makefile
===
RCS file: /cvs/ports/x11/copyq/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- x11/copyq/Makefile 16 Sep 2023 08:22:06 - 1.5
+++ x11/copyq/Makefile 17 Mar 2024 11:30:16 -
@@ -1,7 +1,7 @@
COMMENT = Qt5 based clipboard manager
GH_ACCOUNT = hluk
GH_PROJECT = CopyQ
-GH_TAGNAME = v7.1.0
+GH_TAGNAME = v8.0.0
PKGNAME = ${DISTNAME:L}
CATEGORIES = x11
Index: x11/copyq/distinfo
===
RCS file: /cvs/ports/x11/copyq/distinfo,v
retrieving revision 1.4
diff -u -r1.4 distinfo
--- x11/copyq/distinfo 16 Sep 2023 08:22:06 - 1.4
+++ x11/copyq/distinfo 17 Mar 2024 11:30:16 -
@@ -1,2 +1,2 @@
-SHA256 (CopyQ-7.1.0.tar.gz) = zgJlsKhjUP2nv6Gp1LdNeUpAd1UbKBhgEmg1Z9b9gVg=
-SIZE (CopyQ-7.1.0.tar.gz) = 3351093
+SHA256 (CopyQ-8.0.0.tar.gz) = SINTgYLfgdHIhJfT8rew2dH1mgOBZUhpxF3M/Hja+ao=
+SIZE (CopyQ-8.0.0.tar.gz) = 3381697
Re: Salt master on -stable and communication with minions on -current 3006.7 version
On 06/03/24 10:44 +0100, Uwe Werler wrote:
> Salü Robert,
>
> it seems that patches/patch-salt_utils_network_py is already in the attic...
>
> Best regards
>
> Uwe
Why whould we need that patch? I am confused.
> On 06 Mar 08:56, Robert Nagy wrote:
> > On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > > I think we can backport this until there is a new release out.
> >
> > Please try the following diff:
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/sysutils/salt/Makefile,v
> > diff -u -p -u -r1.183 Makefile
> > --- Makefile1 Mar 2024 12:02:55 - 1.183
> > +++ Makefile6 Mar 2024 07:56:07 -
> > @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> > MODPY_EGG_VERSION =3006.7
> > DISTNAME = salt-${MODPY_EGG_VERSION}
> >
> > +REVISION = 0
> > +
> > CATEGORIES = sysutils net devel
> >
> > HOMEPAGE = https://saltproject.io/
> > Index: patches/patch-salt_channel_server_py
> > ===
> > RCS file: patches/patch-salt_channel_server_py
> > diff -N patches/patch-salt_channel_server_py
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-salt_channel_server_py6 Mar 2024 07:56:07 -
> > @@ -0,0 +1,52 @@
> > +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a
> > newline, this breaks minion auth.
> > +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> > +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> > from disk.
> > +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> > +
> > +Index: salt/channel/server.py
> > +--- salt/channel/server.py.orig
> > salt/channel/server.py
> > +@@ -52,6 +52,16 @@ class ReqServerChannel:
> > + transport = salt.transport.request_server(opts, **kwargs)
> > + return cls(opts, transport)
> > +
> > ++@classmethod
> > ++def compare_keys(cls, key1, key2):
> > ++"""
> > ++Normalize and compare two keys
> > ++
> > ++Returns:
> > ++bool: ``True`` if the keys match, otherwise ``False``
> > ++"""
> > ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> > ++
> > + def __init__(self, opts, transport):
> > + self.opts = opts
> > + self.transport = transport
> > +@@ -371,7 +381,7 @@ class ReqServerChannel:
> > + elif os.path.isfile(pubfn):
> > + # The key has been accepted, check it
> > + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys did not match. This may be an attempt to
> > compromise "
> > +@@ -480,7 +490,7 @@ class ReqServerChannel:
> > + # case. Otherwise log the fact that the minion is still
> > + # pending.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "key in pending did not match. This may be an
> > "
> > +@@ -536,7 +546,7 @@ class ReqServerChannel:
> > + # so, pass on doing anything here, and let it get
> > automatically
> > + # accepted below.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + &quo
Re: Salt master on -stable and communication with minions on -current 3006.7 version
On 06/03/24 08:43 +0100, Robert Nagy wrote:
> I think we can backport this until there is a new release out.
Please try the following diff:
Index: Makefile
===
RCS file: /cvs/ports/sysutils/salt/Makefile,v
diff -u -p -u -r1.183 Makefile
--- Makefile1 Mar 2024 12:02:55 - 1.183
+++ Makefile6 Mar 2024 07:56:07 -
@@ -18,6 +18,8 @@ COMMENT = remote execution and configur
MODPY_EGG_VERSION =3006.7
DISTNAME = salt-${MODPY_EGG_VERSION}
+REVISION = 0
+
CATEGORIES = sysutils net devel
HOMEPAGE = https://saltproject.io/
Index: patches/patch-salt_channel_server_py
===
RCS file: patches/patch-salt_channel_server_py
diff -N patches/patch-salt_channel_server_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-salt_channel_server_py6 Mar 2024 07:56:07 -
@@ -0,0 +1,52 @@
+52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a newline,
this breaks minion auth.
+4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
+0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key from
disk.
+ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
+
+Index: salt/channel/server.py
+--- salt/channel/server.py.orig
salt/channel/server.py
+@@ -52,6 +52,16 @@ class ReqServerChannel:
+ transport = salt.transport.request_server(opts, **kwargs)
+ return cls(opts, transport)
+
++@classmethod
++def compare_keys(cls, key1, key2):
++"""
++Normalize and compare two keys
++
++Returns:
++bool: ``True`` if the keys match, otherwise ``False``
++"""
++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
++
+ def __init__(self, opts, transport):
+ self.opts = opts
+ self.transport = transport
+@@ -371,7 +381,7 @@ class ReqServerChannel:
+ elif os.path.isfile(pubfn):
+ # The key has been accepted, check it
+ with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
+-if salt.crypt.clean_key(pubfn_handle.read()) != load["pub"]:
++if not self.compare_keys(pubfn_handle.read(), load["pub"]):
+ log.error(
+ "Authentication attempt from %s failed, the public "
+ "keys did not match. This may be an attempt to
compromise "
+@@ -480,7 +490,7 @@ class ReqServerChannel:
+ # case. Otherwise log the fact that the minion is still
+ # pending.
+ with salt.utils.files.fopen(pubfn_pend, "r") as pubfn_handle:
+-if salt.crypt.clean_key(pubfn_handle.read()) !=
load["pub"]:
++if not self.compare_keys(pubfn_handle.read(),
load["pub"]):
+ log.error(
+ "Authentication attempt from %s failed, the
public "
+ "key in pending did not match. This may be an "
+@@ -536,7 +546,7 @@ class ReqServerChannel:
+ # so, pass on doing anything here, and let it get
automatically
+ # accepted below.
+ with salt.utils.files.fopen(pubfn_pend, "r") as pubfn_handle:
+-if salt.crypt.clean_key(pubfn_handle.read()) !=
load["pub"]:
++if not self.compare_keys(pubfn_handle.read(),
load["pub"]):
+ log.error(
+ "Authentication attempt from %s failed, the
public "
+ "keys in pending did not match. This may be an "
Index: patches/patch-salt_grains_core_py
===
RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
diff -u -p -u -r1.12 patch-salt_grains_core_py
--- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 - 1.12
+++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
@@ -24,7 +24,7 @@ Index: salt/grains/core.py
return grains
-@@ -2652,10 +2654,12 @@ def os_data():
+@@ -2744,10 +2746,12 @@ def os_data():
# derive osrelease from kernelversion prior to that
grains["osrelease"] = grains["kernelrelease"].split("-")[0]
grains.update(_bsd_cpudata(grains))
Re: Salt master on -stable and communication with minions on -current 3006.7 version
I think we can backport this until there is a new release out. On 06/03/24 09:26 +0100, Uwe Werler wrote: > Hi all, > > it seems that it has to do with eol in minion keys: > > https://github.com/saltstack/salt/issues/66126 > There's also a PR: https://github.com/saltstack/salt/pull/66140 > > Best regards > > Uwe > > On 05 Mar 17:24, Uwe Werler wrote: > > Hi Micholaj, > > > > to upgrade minions to a higher version than the master is usually a bad > > idea. > > > > I noticed the same problem. Installed salt at my alpine machines (3006.7) > > and lost connection to the master. But after upgrading my master to 3006.7 > > my OpenBSD minions (3006.5) lost connection too. When I registered the > > minions new the keys were stored under accepted keys and immediately under > > denied keys too. I guess this has something to do with the upgrades in > > cryptography/pyopenssl. I didn't investigate further but upgraded all > > machines to 3006.7. > > > > Best regards > > > > Uwe > > > > Am 5. März 2024 16:29:55 MEZ schrieb Mikolaj Kucharski > > : > > >Hi Robert. > > > > > >I've notived this problem on my Debian Bookworm machines, which recently > > >got upgraded to 3006.7 and now I also see this on my OpenBSD -current, > > >which also started to run 3006.7 minions. I have Salt master running > > >on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7 > > >lost communication to the master: > > > > > >openbsd-current-minion# tail -n10 /var/log/salt/minion > > >The master public key can be found at: > > >/etc/salt/pki/minion/minion_master.pub > > >2024-03-05 15:13:22,252 [salt.minion:1157][ERROR ][44088] Error while > > >bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 > > >responding? The error message was Unable to sign_in to master: Invalid > > >master key > > >2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR ][44088] The master key > > >has changed, the salt master could have been subverted, verify salt > > >master's public key > > >2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master > > >server's public key did not authenticate! > > >The master may need to be updated if it is a version of Salt lower than > > >3006.7, or > > >If you are confident that you are connecting to a valid Salt Master, then > > >remove the master public key and restart the Salt Minion. > > >The master public key can be found at: > > >/etc/salt/pki/minion/minion_master.pub > > >2024-03-05 15:13:32,727 [salt.minion:1157][ERROR ][44088] Error while > > >bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 > > >responding? The error message was Unable to sign_in to master: Invalid > > >master key > > > > > >I didn't check does upgrade to 3006.7 on master help. I don't want > > >to touch my -stable machines. I could setup Salt master on -current > > >and test, but all this problem started on Debian and OpenBSD after > > >minion upgrade to 3006.7. I do follow -stable packages and syspatch > > >on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD, > > >I suspect compatibility issue on Salt side. > > > > > >openbsd-salt-master# sysctl -n kern.version > > >OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 > > > > > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > >openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail > > >drwxr-xr-x 2 0 0 512B Jan 17 23:23 brotli-1.0.9p0 > > >drwxr-xr-x 2 0 0 512B Jan 17 23:23 taskd-1.1.0p5 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 ngtcp2-0.19.1 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp3-0.15.0 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp2-1.57.0 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 git-2.42.0 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 curl-8.6.0 > > >drwxr-xr-x 2 0 0 512B Feb 14 00:47 libunbound-1.19.1 > > >drwxr-xr-x 2 0 0 512B Feb 14 00:47 gnutls-3.8.3 > > >drwxr-xr-x 2 0 0 512B Feb 24 17:56 quirks-6.160 > > > > > > > > >openbsd-current-minion# sysctl -n kern.version > > >OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar 3 22:36:54 MST 2024 > > >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > >Are you aware of this problem? Ports mailing list, did you notice this, > > >by any chance? > > > > > >-- > > >Regards, > > > Mikolaj > > > > > > > -- > > Mit freundlichen Grüssen / Með bestu kveðju / With kind regards > > > > Uwe Werler > > -- > wq: ~uw -- Regards, Robert Nagy
Re: UPDATE sysutils/salt 3006.7
salt.utils.vt.${MODPY_PYC_MAGIC_TAG}pyc
> -lib/python${MODPY_VERSION}/site-packages/salt/utils/pyinstaller/rthooks/${MODPY_PYCACHE}pyi_rth_subprocess.${MODPY_PYC_MAGIC_TAG}pyc
> -lib/python${MODPY_VERSION}/site-packages/salt/utils/pyinstaller/rthooks/_overrides.py
> -lib/python${MODPY_VERSION}/site-packages/salt/utils/pyinstaller/rthooks/pyi_rth_salt.utils.vt.py
> -lib/python${MODPY_VERSION}/site-packages/salt/utils/pyinstaller/rthooks/pyi_rth_subprocess.py
> lib/python${MODPY_VERSION}/site-packages/salt/utils/pyobjects.py
> lib/python${MODPY_VERSION}/site-packages/salt/utils/reactor.py
> lib/python${MODPY_VERSION}/site-packages/salt/utils/reclass.py
--
Regards,
Robert Nagy
Re: multimedia/libvpx: ENDBR64
It seems that we need more here. This makes all the regression tests pass. I suspect there will be still more needed, but we need something to uncover those. Index: Makefile === RCS file: /cvs/ports/multimedia/libvpx/Makefile,v diff -u -p -u -r1.55 Makefile --- Makefile24 Feb 2024 17:39:07 - 1.55 +++ Makefile28 Feb 2024 11:40:27 - @@ -6,7 +6,7 @@ GH_TAGNAME= v1.13.1 EPOCH= 0 CATEGORIES=multimedia -REVISION= 2 +REVISION= 3 SHARED_LIBS= vpx 16.0 Index: patches/patch-vp8_common_x86_subpixel_ssse3_asm === RCS file: patches/patch-vp8_common_x86_subpixel_ssse3_asm diff -N patches/patch-vp8_common_x86_subpixel_ssse3_asm --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-vp8_common_x86_subpixel_ssse3_asm 28 Feb 2024 11:40:27 - @@ -0,0 +1,67 @@ +Index: vp8/common/x86/subpixel_ssse3.asm +--- vp8/common/x86/subpixel_ssse3.asm.orig vp8/common/x86/subpixel_ssse3.asm +@@ -37,6 +37,7 @@ SECTION .text + ;) + globalsym(vp8_filter_block1d8_h6_ssse3) + sym(vp8_filter_block1d8_h6_ssse3): ++_endbr64 + pushrbp + mov rbp, rsp + SHADOW_ARGS_TO_STACK 6 +@@ -180,6 +181,7 @@ vp8_filter_block1d8_h4_ssse3: + ;) + globalsym(vp8_filter_block1d16_h6_ssse3) + sym(vp8_filter_block1d16_h6_ssse3): ++_endbr64 + pushrbp + mov rbp, rsp + SHADOW_ARGS_TO_STACK 6 +@@ -287,6 +289,7 @@ sym(vp8_filter_block1d16_h6_ssse3): + ;) + globalsym(vp8_filter_block1d4_h6_ssse3) + sym(vp8_filter_block1d4_h6_ssse3): ++_endbr64 + pushrbp + mov rbp, rsp + SHADOW_ARGS_TO_STACK 6 +@@ -417,6 +420,7 @@ sym(vp8_filter_block1d4_h6_ssse3): + ;) + globalsym(vp8_filter_block1d16_v6_ssse3) + sym(vp8_filter_block1d16_v6_ssse3): ++_endbr64 + pushrbp + mov rbp, rsp + SHADOW_ARGS_TO_STACK 6 +@@ -605,6 +609,7 @@ sym(vp8_filter_block1d16_v6_ssse3): + ;) + globalsym(vp8_filter_block1d8_v6_ssse3) + sym(vp8_filter_block1d8_v6_ssse3): ++_endbr64 + pushrbp + mov rbp, rsp + SHADOW_ARGS_TO_STACK 6 +@@ -745,6 +750,7 @@ sym(vp8_filter_block1d8_v6_ssse3): + ;) + globalsym(vp8_filter_block1d4_v6_ssse3) + sym(vp8_filter_block1d4_v6_ssse3): ++_endbr64 + pushrbp + mov rbp, rsp + SHADOW_ARGS_TO_STACK 6 +@@ -884,6 +890,7 @@ sym(vp8_filter_block1d4_v6_ssse3): + ;) + globalsym(vp8_bilinear_predict16x16_ssse3) + sym(vp8_bilinear_predict16x16_ssse3): ++_endbr64 + pushrbp + mov rbp, rsp + SHADOW_ARGS_TO_STACK 6 +@@ -1147,6 +1154,7 @@ sym(vp8_bilinear_predict16x16_ssse3): + ;) + globalsym(vp8_bilinear_predict8x8_ssse3) + sym(vp8_bilinear_predict8x8_ssse3): ++_endbr64 + pushrbp + mov rbp, rsp + SHADOW_ARGS_TO_STACK 6 Index: patches/patch-vp8_encoder_x86_copy_sse3_asm === RCS file: patches/patch-vp8_encoder_x86_copy_sse3_asm diff -N patches/patch-vp8_encoder_x86_copy_sse3_asm --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-vp8_encoder_x86_copy_sse3_asm 28 Feb 2024 11:40:27 - @@ -0,0 +1,12 @@ +Index: vp8/encoder/x86/copy_sse3.asm +--- vp8/encoder/x86/copy_sse3.asm.orig vp8/encoder/x86/copy_sse3.asm +@@ -94,6 +94,8 @@ SECTION .text + globalsym(vp8_copy32xn_sse3) + sym(vp8_copy32xn_sse3): + ++_endbr64 ++ + STACK_FRAME_CREATE_X3 + + .block_copy_sse3_loopx4: Index: patches/patch-vp8_encoder_x86_dct_sse2_asm === RCS file: patches/patch-vp8_encoder_x86_dct_sse2_asm diff -N patches/patch-vp8_encoder_x86_dct_sse2_asm --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-vp8_encoder_x86_dct_sse2_asm 28 Feb 2024 11:40:27 - @@ -0,0 +1,21 @@ +Index: vp8/encoder/x86/dct_sse2.asm +--- vp8/encoder/x86/dct_sse2.asm.orig vp8/encoder/x86/dct_sse2.asm +@@ -66,6 +66,8 @@ SECTION .text + globalsym(vp8_short_fdct4x4_sse2) + sym(vp8_short_fdct4x4_sse2): + ++_endbr64 ++ + STACK_FRAME_CREATE + + movqxmm0, MMWORD PTR[input] ;03 02 01 00 +@@ -170,6 +172,8 @@ sym(vp8_short_fdct4x4_sse2): + ;void vp8_short_fdct8x4_sse2(short *input, short *output, int pitch) + globalsym(vp8_short_fdct8x4_sse2) + sym(vp8_short_fdct8x4_sse2): ++ ++_endbr64 + + STACK_FRAME_CREATE + Index: patches/patch-vp8_encoder_x86_fwalsh_sse2_asm === RCS file: patches/patch-vp8_encoder_x86_fwalsh_sse2_asm diff -N patches/patch-vp8_encoder_x86_fwalsh_sse2_asm --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-vp8_encoder_x86_fwalsh_sse2_asm 28 Feb 2024 11:40:27 - @@ -0,0 +1,11 @@ +Index: vp8/encoder/x86/fwalsh_sse2.asm +--- vp8/encoder/x86/fwalsh_sse2.asm.orig vp8/encoder/x86/fwalsh_sse2.asm +@@ -16,6 +16,7
Re: multimedia/libvpx: ENDBR64
works, ok On 24/02/24 18:30 +0100, Mark Kettenis wrote: > The asm in this port seems to have some x265 heritage. So there is a > x86inc.asm file that we can patch. But it uses yasm instead of nasm > and yasm doesn't know about endbr64. So just dump the bytes for that > instruction into place. > > Seems to be fix playing youtube vids in chromium again. > > ok? > > > Index: multimedia/libvpx/Makefile > === > RCS file: /cvs/ports/multimedia/libvpx/Makefile,v > retrieving revision 1.54 > diff -u -p -r1.54 Makefile > --- multimedia/libvpx/Makefile8 Feb 2024 13:39:39 - 1.54 > +++ multimedia/libvpx/Makefile24 Feb 2024 17:29:40 - > @@ -6,7 +6,7 @@ GH_TAGNAME= v1.13.1 > EPOCH= 0 > CATEGORIES= multimedia > > -REVISION=1 > +REVISION=2 > > SHARED_LIBS= vpx 16.0 > > Index: multimedia/libvpx/patches/patch-third_party_x86inc_x86inc_asm > === > RCS file: multimedia/libvpx/patches/patch-third_party_x86inc_x86inc_asm > diff -N multimedia/libvpx/patches/patch-third_party_x86inc_x86inc_asm > --- /dev/null 1 Jan 1970 00:00:00 - > +++ multimedia/libvpx/patches/patch-third_party_x86inc_x86inc_asm 24 Feb > 2024 17:29:40 - > @@ -0,0 +1,13 @@ > +Index: third_party/x86inc/x86inc.asm > +--- third_party/x86inc/x86inc.asm.orig > third_party/x86inc/x86inc.asm > +@@ -860,6 +860,9 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg, > + %endif > + align function_align > + %2: > ++%if VPX_ARCH_X86_64 > ++dd 0xfa1e0ff3 > ++%endif > + RESET_MM_PERMUTATION; needed for x86-64, also makes disassembly > somewhat nicer > + %xdefine rstk rsp ; copy of the original stack pointer, used > when greater alignment than the known stack alignment is required > + %assign stack_offset 0 ; stack pointer offset relative to the > return address -- Regards, Robert Nagy
Re: UPDATE: libvpx 1.14.0
EST_DATA_PATH); $${sha1sum} -c);\
> + (cd "$(LIBVPX_TEST_DATA_PATH)"; $${sha1sum} -c);\
> done; \
> else\
> -@@ -656,7 +643,7 @@ BINS-yes += $(LIBVPX_TEST_BIN)
> +@@ -657,7 +644,7 @@ BINS-yes += $(LIBVPX_TEST_BIN)
>
> CODEC_LIB=$(if $(CONFIG_DEBUG_LIBS),vpx_g,vpx)
> CODEC_LIB_SUF=$(if $(CONFIG_SHARED),$(SHARED_LIB_SUF),.a)
> @@ -59,7 +59,7 @@ Index: libs.mk
> $(LIBVPX_TEST_BIN): $(TEST_LIBS)
> $(eval $(call linkerxx_template,$(LIBVPX_TEST_BIN), \
> $(LIBVPX_TEST_OBJS) \
> -@@ -715,6 +702,8 @@ test_shard.$(1) test_shard_ndc.$(1): $(LIBVPX_TEST_BIN
> +@@ -716,6 +703,8 @@ test_shard.$(1) test_shard_ndc.$(1): $(LIBVPX_TEST_BIN
> @set -e; \
>export GTEST_SHARD_INDEX=$(1); \
>export GTEST_TOTAL_SHARDS=$(2); \
> Index: patches/patch-vpx_ports_aarch32_cpudetect_c
> ===
> RCS file: patches/patch-vpx_ports_aarch32_cpudetect_c
> diff -N patches/patch-vpx_ports_aarch32_cpudetect_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-vpx_ports_aarch32_cpudetect_c 22 Feb 2024 07:59:17
> -
> @@ -0,0 +1,23 @@
> +Allow ARM CPU runtime detection code to build on OpenBSD.
> +
> +Index: vpx_ports/aarch32_cpudetect.c
> +--- vpx_ports/aarch32_cpudetect.c.orig
> vpx_ports/aarch32_cpudetect.c
> +@@ -12,7 +12,7 @@
> + #include "./vpx_config.h"
> + #include "arm_cpudetect.h"
> +
> +-#if !CONFIG_RUNTIME_CPU_DETECT
> ++#if !CONFIG_RUNTIME_CPU_DETECT || defined(__OpenBSD__)
> +
> + static int arm_get_cpu_caps(void) {
> + // This function should actually be a no-op. There is no way to adjust
> any of
> +@@ -25,7 +25,7 @@ static int arm_get_cpu_caps(void) {
> + return flags;
> + }
> +
> +-#elif defined(_MSC_VER) // end !CONFIG_RUNTIME_CPU_DETECT
> ++#elif defined(_MSC_VER) // end !CONFIG_RUNTIME_CPU_DETECT || __OpenBSD__
> +
> + static int arm_get_cpu_caps(void) {
> + int flags = 0;
> Index: patches/patch-vpx_ports_aarch64_cpudetect_c
> ===
> RCS file: patches/patch-vpx_ports_aarch64_cpudetect_c
> diff -N patches/patch-vpx_ports_aarch64_cpudetect_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-vpx_ports_aarch64_cpudetect_c 22 Feb 2024 07:59:17
> -
> @@ -0,0 +1,23 @@
> +Allow ARM CPU runtime detection code to build on OpenBSD.
> +
> +Index: vpx_ports/aarch64_cpudetect.c
> +--- vpx_ports/aarch64_cpudetect.c.orig
> vpx_ports/aarch64_cpudetect.c
> +@@ -15,7 +15,7 @@
> + #include
> + #endif
> +
> +-#if !CONFIG_RUNTIME_CPU_DETECT
> ++#if !CONFIG_RUNTIME_CPU_DETECT || defined(__OpenBSD__)
> +
> + static int arm_get_cpu_caps(void) {
> + // This function should actually be a no-op. There is no way to adjust
> any of
> +@@ -28,7 +28,7 @@ static int arm_get_cpu_caps(void) {
> + return flags;
> + }
> +
> +-#elif defined(__APPLE__) // end !CONFIG_RUNTIME_CPU_DETECT
> ++#elif defined(__APPLE__) // end !CONFIG_RUNTIME_CPU_DETECT || __OpenBSD__
> +
> + // sysctlbyname() parameter documentation for instruction set
> characteristics:
> + //
> https://developer.apple.com/documentation/kernel/1387446-sysctlbyname/determining_instruction_set_characteristics
> Index: patches/patch-vpx_ports_arm_cpudetect_c
> ===
> RCS file: patches/patch-vpx_ports_arm_cpudetect_c
> diff -N patches/patch-vpx_ports_arm_cpudetect_c
> --- patches/patch-vpx_ports_arm_cpudetect_c 13 Mar 2022 13:50:53 -
> 1.4
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,23 +0,0 @@
> -Allow ARM CPU runtime detection code to build on OpenBSD.
> -
> -Index: vpx_ports/arm_cpudetect.c
> vpx_ports/arm_cpudetect.c.orig
> -+++ vpx_ports/arm_cpudetect.c
> -@@ -38,7 +38,7 @@ static int arm_cpu_env_mask(void) {
> - return env && *env ? (int)strtol(env, NULL, 0) : ~0;
> - }
> -
> --#if !CONFIG_RUNTIME_CPU_DETECT
> -+#if !CONFIG_RUNTIME_CPU_DETECT || defined(__OpenBSD__)
> -
> - int arm_cpu_caps(void) {
> - /* This function should actually be a no-op. There is no way to adjust
> any of
> -@@ -56,7 +56,7 @@ int arm_cpu_caps(void) {
> - return flags & mask;
> - }
> -
> --#elif defined(_MSC_VER) /* end !CONFIG_RUNTIME_CPU_DETECT */
> -+#elif defined(_MSC_VER) /* end !CONFIG_RUNTIME_CPU_DETECT || __OpenBSD__ */
> - /*For GetExceptionCode() and EXCEPTION_ILLEGAL_INSTRUCTION.*/
> - #ifndef WIN32_LEAN_AND_MEAN
> - #define WIN32_LEAN_AND_MEAN
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/multimedia/libvpx/pkg/PLIST,v
> retrieving revision 1.10
> diff -u -p -u -p -r1.10 PLIST
> --- pkg/PLIST 11 Mar 2022 19:39:22 - 1.10
> +++ pkg/PLIST 22 Feb 2024 07:59:17 -
> @@ -11,6 +11,7 @@ include/vpx/vpx_ext_ratectrl.h
> include/vpx/vpx_frame_buffer.h
> include/vpx/vpx_image.h
> include/vpx/vpx_integer.h
> +include/vpx/vpx_tpl.h
> @static-lib lib/libvpx.a
> @lib lib/libvpx.so.${LIBvpx_VERSION}
> lib/pkgconfig/vpx.pc
>
--
Regards,
Robert Nagy
libvpx target detection and optimizations
Hi
The following diff fixes target os detection in libvpx by actually
trying to use ${CC} instead of hardcoding gcc.
This patch also fixes *chromium, iridium video and screen sharing
because some code is only enabled on the non-generic target platform.
I've also fixed up tests which now can be exeuted in the port.
ok?
Index: Makefile
===
RCS file: /cvs/ports/multimedia/libvpx/Makefile,v
diff -u -p -u -r1.52 Makefile
--- Makefile2 Oct 2023 18:11:05 - 1.52
+++ Makefile8 Feb 2024 09:04:55 -
@@ -6,6 +6,8 @@ GH_TAGNAME= v1.13.1
EPOCH= 0
CATEGORIES=multimedia
+REVISION= 0
+
SHARED_LIBS= vpx 16.0
HOMEPAGE= https://www.webmproject.org/
@@ -34,14 +36,14 @@ CONFIGURE_ARGS+=--enable-shared \
--enable-runtime-cpu-detect \
--enable-vp9-highbitdepth \
--prefix=${PREFIX} \
- --disable-optimizations \
- --disable-unit-tests
+ --enable-optimizations \
+ --enable-unit-tests \
+ --enable-decode-perf-tests \
+ --enable-encode-perf-tests
.if ${MACHINE_ARCH} == "arm"
CONFIGURE_ARGS+=--disable-neon
.endif
-
-NO_TEST= Yes
ALL_TARGET=
Index: patches/patch-build_make_configure_sh
===
RCS file: patches/patch-build_make_configure_sh
diff -N patches/patch-build_make_configure_sh
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-build_make_configure_sh 8 Feb 2024 09:04:55 -
@@ -0,0 +1,77 @@
+Index: build/make/configure.sh
+--- build/make/configure.sh.orig
build/make/configure.sh
+@@ -700,8 +700,8 @@ post_process_cmdline() {
+ }
+
+ setup_gnu_toolchain() {
+- CC=${CC:-${CROSS}gcc}
+- CXX=${CXX:-${CROSS}g++}
++ CC=${CC:-${CROSS}cc}
++ CXX=${CXX:-${CROSS}c++}
+ AR=${AR:-${CROSS}ar}
+ LD=${LD:-${CROSS}${link_with_cc:-ld}}
+ AS=${AS:-${CROSS}as}
+@@ -745,7 +745,7 @@ check_xcode_minimum_version() {
+
+ process_common_toolchain() {
+ if [ -z "$toolchain" ]; then
+-gcctarget="${CHOST:-$(gcc -dumpmachine 2> /dev/null)}"
++gcctarget="${CHOST:-$(${CC} -dumpmachine 2> /dev/null)}"
+ # detect tgt_isa
+ case "$gcctarget" in
+ aarch64*)
+@@ -988,7 +988,7 @@ process_common_toolchain() {
+
+ case ${tgt_cc} in
+ gcc)
+- link_with_cc=gcc
++ link_with_cc=${CC}
+ setup_gnu_toolchain
+ arch_int=${tgt_isa##armv}
+ arch_int=${arch_int%%te}
+@@ -1203,7 +1203,7 @@ EOF
+ esac
+ ;;
+ mips*)
+- link_with_cc=gcc
++ link_with_cc=${CC}
+ setup_gnu_toolchain
+ tune_cflags="-mtune="
+ if enabled dspr2; then
+@@ -1254,7 +1254,7 @@ EOF
+ check_add_asflags -KPIC
+ ;;
+ ppc64le*)
+- link_with_cc=gcc
++ link_with_cc=${CC}
+ setup_gnu_toolchain
+ # Do not enable vsx by default.
+ # https://bugs.chromium.org/p/webm/issues/detail?id=1522
+@@ -1311,7 +1311,7 @@ EOF
+ esac
+ ;;
+ gcc*)
+- link_with_cc=gcc
++ link_with_cc=${CC}
+ tune_cflags="-march="
+ setup_gnu_toolchain
+ #for 32 bit x86 builds, -O3 did not turn on this flag
+@@ -1442,7 +1442,7 @@ EOF
+ esac
+ ;;
+ loongarch*)
+- link_with_cc=gcc
++ link_with_cc=${CC}
+ setup_gnu_toolchain
+
+ enabled lsx && check_inline_asm lsx '"vadd.b $vr0, $vr1, $vr1"'
+@@ -1451,7 +1451,7 @@ EOF
+ enabled lasx && soft_enable runtime_cpu_detect
+ ;;
+ *-gcc|generic-gnu)
+- link_with_cc=gcc
++ link_with_cc=${CC}
+ enable_feature gcc
+ setup_gnu_toolchain
+ ;;
Index: patches/patch-libs_mk
===
RCS file: /cvs/ports/multimedia/libvpx/patches/patch-libs_mk,v
diff -u -p -u -r1.22 patch-libs_mk
--- patches/patch-libs_mk 4 Oct 2022 11:30:19 - 1.22
+++ patches/patch-libs_mk 8 Feb 2024 09:04:55 -
@@ -41,3 +41,29 @@ Index: libs.mk
INSTALL-LIBS-$(CONFIG_SHARED) += $(LIBSUBDIR)/$(LIBVPX_SO)
INSTALL-LIBS-$(CONFIG_SHARED) += $(if
$(LIBVPX_SO_IMPLIB),$(LIBSUBDIR)/$(LIBVPX_SO_IMPLIB))
+@@ -544,7 +531,7 @@ testdata: $(LIBVPX_TEST_DATA)
+ set -e;\
+ echo "Checking test data:";\
+ for f in $(call enabled,LIBVPX_TEST_DATA); do\
+-grep $$f $(SRC_PATH_BARE)/test/test-data.sha1 |\
++grep $$f $(SRC_PATH_BARE)/test/test-data.sha1 | tr -d '*' |\
+ (cd $(LIBVPX_TEST_DATA_PATH); $${sha1sum} -c);\
+ done; \
+ else\
+@@ -656,7 +643,7 @@ BINS-yes += $(LIBVPX_TEST_BIN)
+
+ CODEC_LIB=$(if $(CONFIG_DEBUG_LIBS),vpx_g,vpx)
+ CODEC_LIB_SUF=$(if $(CONFIG_SHARED),$(SHARED_LIB_SUF),.a)
+-TEST_LIBS := lib$(CODEC_LIB)$(CODEC_LIB_SUF) libgtest.a
++TEST_LIBS := lib$(CODEC_LIB)$(CODE
Re: Chromium error
Thanks a lot - that worked! Deleted files in
.config/chromium/Default/GPUCache
Quoting "Lorenz (xha)" :
i sometimes have this issue on my work pc running alpine linux. i don't
know if it is the same issue, but in this case i always have to delete
the shader cache, somwhere in .config/chromium//GPUCache
searching the internet for "chromium delete shader cache" or "chromium
delete gpu cache" should give you some options on what to delete
On Wed, Dec 13, 2023 at 04:41:47PM +0100, Robert Palm wrote:
Chromium is not properly working ? Pages look gibberish...
tron$ doas pkg_info chromium
Information for inst:chromium-120.0.6099.
Error:
[3083:287610160:1213/164024.536817:ERROR:shared_context_state.cc(100)] Skia
shader compilation error
// Vertex SKSL
#extension GL_NV_shader_noperspective_interpolation: require
uniform float4 sk_RTAdjust;in float2 position;in half4 color;noperspective
out half4 vcolor_S0;void main() {// Primitive Processor
QuadPerEdgeAAGeometryProcessor
vcolor_S0 = color;sk_Position = position.xy01;}
// Fragment SKSL
#extension GL_NV_shader_noperspective_interpolation: require
noperspective in half4 vcolor_S0;void main() {// Stage 0,
QuadPerEdgeAAGeometryProcessor
half4 outputColor_S0;outputColor_S0 = vcolor_S0;const half4
outputCoverage_S0 = half4(1);{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_S0 * outputCoverage_S0;}}
// Vertex GLSL
#version 300 es
#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
in highp vec2 position;
in mediump vec4 color;
noperspective out mediump vec4 vcolor_S0;
void main() {
vcolor_S0 = color;
gl_Position = vec4(position, 0.0, 1.0);
gl_Position = vec4(gl_Position.xy * sk_RTAdjust.xz + gl_Position.ww *
sk_RTAdjust.yw, 0.0, gl_Position.w);
}
// Fragment GLSL
#version 300 es
#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
out mediump vec4 sk_FragColor;
noperspective in mediump vec4 vcolor_S0;
void main() {
mediump vec4 outputColor_S0 = vcolor_S0;
{
sk_FragColor = outputColor_S0;
}
}
Chromium error
Chromium is not properly working ? Pages look gibberish...
tron$ doas pkg_info chromium
Information for inst:chromium-120.0.6099.
Error:
[3083:287610160:1213/164024.536817:ERROR:shared_context_state.cc(100)]
Skia shader compilation error
// Vertex SKSL
#extension GL_NV_shader_noperspective_interpolation: require
uniform float4 sk_RTAdjust;in float2 position;in half4
color;noperspective out half4 vcolor_S0;void main() {// Primitive
Processor QuadPerEdgeAAGeometryProcessor
vcolor_S0 = color;sk_Position = position.xy01;}
// Fragment SKSL
#extension GL_NV_shader_noperspective_interpolation: require
noperspective in half4 vcolor_S0;void main() {// Stage 0,
QuadPerEdgeAAGeometryProcessor
half4 outputColor_S0;outputColor_S0 = vcolor_S0;const half4
outputCoverage_S0 = half4(1);{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_S0 * outputCoverage_S0;}}
// Vertex GLSL
#version 300 es
#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
in highp vec2 position;
in mediump vec4 color;
noperspective out mediump vec4 vcolor_S0;
void main() {
vcolor_S0 = color;
gl_Position = vec4(position, 0.0, 1.0);
gl_Position = vec4(gl_Position.xy * sk_RTAdjust.xz +
gl_Position.ww * sk_RTAdjust.yw, 0.0, gl_Position.w);
}
// Fragment GLSL
#version 300 es
#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
out mediump vec4 sk_FragColor;
noperspective in mediump vec4 vcolor_S0;
void main() {
mediump vec4 outputColor_S0 = vcolor_S0;
{
sk_FragColor = outputColor_S0;
}
}
Firefox issue
Just noticed firefox seems not working: GENERIC.MP#1483 amd64 tron$ pkg_info firefox Information for inst:firefox-120.0.1 tron$ firefox XPCOMGlueLoad error for file /usr/local/lib/firefox/libmozwayland.so.132.0: File not found Couldn't load XPCOM.
Re: llvm: arm64 bti lld fix
t ElfSym {
> // __bss_start
> static Defined *bss;
>
> @@ -30,7 +40,7 @@ Index: lld/ELF/Symbols.h
> // etext and _etext
> static Defined *etext1;
> static Defined *etext2;
> -@@ -546,6 +552,8 @@ void reportDuplicate(const Symbol &sym, const InputFil
> +@@ -546,6 +555,8 @@ void reportDuplicate(const Symbol &sym, const InputFil
>InputSectionBase *errSec, uint64_t errOffset);
> void maybeWarnUnorderableSymbol(const Symbol *sym);
> bool computeIsPreemptible(const Symbol &sym);
> Index: patches/patch-lld_ELF_Thunks_cpp
> ===
> RCS file: patches/patch-lld_ELF_Thunks_cpp
> diff -N patches/patch-lld_ELF_Thunks_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lld_ELF_Thunks_cpp 26 Nov 2023 14:11:32 -
> @@ -0,0 +1,14 @@
> +Index: lld/ELF/Thunks.cpp
> +--- lld/ELF/Thunks.cpp.orig
> lld/ELF/Thunks.cpp
> +@@ -1217,7 +1217,9 @@ bool PPC64LongBranchThunk::isCompatibleWith(const Inpu
> + return rel.type == R_PPC64_REL24 || rel.type == R_PPC64_REL14;
> + }
> +
> +-Thunk::Thunk(Symbol &d, int64_t a) : destination(d), addend(a), offset(0) {}
> ++Thunk::Thunk(Symbol &d, int64_t a) : destination(d), addend(a), offset(0) {
> ++ destination.thunkAccessed = true;
> ++}
> +
> + Thunk::~Thunk() = default;
> +
> Index: patches/patch-lld_test_ELF_aarch64-feature-bti-plt_s
> ===
> RCS file: patches/patch-lld_test_ELF_aarch64-feature-bti-plt_s
> diff -N patches/patch-lld_test_ELF_aarch64-feature-bti-plt_s
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lld_test_ELF_aarch64-feature-bti-plt_s 26 Nov 2023
> 14:11:32 -
> @@ -0,0 +1,58 @@
> +Index: lld/test/ELF/aarch64-feature-bti-plt.s
> +--- lld/test/ELF/aarch64-feature-bti-plt.s.orig
> lld/test/ELF/aarch64-feature-bti-plt.s
> +@@ -0,0 +1,54 @@
> ++# REQUIRES: aarch64
> ++
> ++# RUN: rm -rf %t && split-file %s %t
> ++
> ++# RUN: llvm-mc --triple=aarch64 --filetype=obj -o %t.o %t/a.s
> ++# RUN: ld.lld --shared -T %t/largegap.lds -z force-bti %t.o -o %t.elf
> ++# RUN: llvm-objdump -d %t.elf | FileCheck %s
> ++
> ++#--- largegap.lds
> ++SECTIONS {
> ++ .plt : { *(.plt) }
> ++ .text.near 0x1000 : AT(0x1000) { *(.text.near) }
> ++ .text.far 0xf000 : AT(0xf000) { *(.text.far) }
> ++}
> ++
> ++#--- a.s
> ++# CHECK:<.plt>:
> ++# CHECK-NEXT: bti c
> ++
> ++## foo@plt is targeted by a range extension thunk with an indirect branch.
> ++## Add a bti c instruction.
> ++# CHECK::
> ++# CHECK-NEXT: bti c
> ++
> ++## biz is not targeted by a thunk using an indirect branch, so no need for
> bti c.
> ++# CHECK::
> ++# CHECK-NEXT: adrpx16, {{.*}}
> ++
> ++# CHECK: :
> ++# CHECK-NEXT: bl {{.*}}
> ++# CHECK-NEXT: bl {{.*}}
> ++
> ++# CHECK: :
> ++# CHECK-NEXT: bl {{.*}} <__AArch64ADRPThunk_foo>
> ++
> ++# CHECK: <__AArch64ADRPThunk_foo>:
> ++# CHECK-NEXT: adrpx16, 0x0
> ++# CHECK-NEXT: add x16, x16, {{.*}}
> ++# CHECK-NEXT: br x16
> ++
> ++.global foo
> ++.global biz
> ++.section .text.near, "ax", %progbits
> ++bar:
> ++.type bar, %function
> ++bl foo
> ++bl biz
> ++ret
> ++
> ++.section .text.far, "ax", %progbits
> ++func:
> ++.type func, %function
> ++bl foo
> ++ret
--
Regards,
Robert Nagy
Re: lang/mono: stop using syscall(2)
> @@ -0,0 +1,14 @@ > +It is *ONLY* Linux that does special shit in fork(2) just drop this comment because it is not true at all, and then it is ok to be commited
Re: Unbreak devel/llvm/{13,16} build on sparc64
On 13/10/23 08:11 +0200, Theo Buehler wrote: > On Fri, Oct 13, 2023 at 07:51:17AM +0200, Robert Nagy wrote: > > Is having unwind.h in !sparc64 going to cause any breakage? > > I honestly have no idea. I don't know what exactly your commit > > https://github.com/openbsd/ports/commit/2a0e3678f1ba1beaada027f5f9a2405b3e0cce96 > > was supposed to be fixing. > > /usr/include/unwind.h is present in the distrib/sets/comp/md.* files for > the gcc architectures, but we only care about sparc64 here. > > I would be inclinded to leave the header in place (which is what my diff > does) and think about removing it from the llvm port if we find actual > breakage related to it. ok let's see
Re: Unbreak devel/llvm/{13,16} build on sparc64
Is having unwind.h in !sparc64 going to cause any breakage?
On 12/10/23 22:18 +0200, Theo Buehler wrote:
> As can be seen in [1], llvm/16 doesn't build because of
>
> /usr/bin/ld: unrecognized option '-Bsymbolic-functions'
>
> which due to missing patches for the OPENBSD_LD_IS_LLD hack.
>
> It does seem to work, more or less: I got a working ksh and libcrypto,
> although I did see a segfault of lld once when building dsa_ameth.c.
>
>
> As can be seen in [2], llvm/13 doesn't package because of
>
> Error:
> /usr/obj/ports/llvm-13.0.0/fake-sparc64/usr/local/llvm13/lib/clang/13.0.0/include/unwind.h
> does not exist
>
> (this also affects llvm/16)
>
> The reason for this is that sparc64 has /usr/include/unwind.h from gcc,
> so it's removed by the post-install hook in Makefile.inc.
>
> Not sure if exempting unwind.h from removal is the right approach, or
> if it should be @commented in the PLIST, or if there is another approach
> for special casing this on sparc64.
>
> The diff below addresses both of these with no package change for other
> architectures, so no bump. I'm certain about the fix for 16. I leave the
> fix for unwind.h for others to evaluate.
>
> [1]:
> http://build-failures.rhaalovely.net/sparc64/2023-10-08/devel/llvm/16,-lldb.log
> [2]: http://build-failures.rhaalovely.net/sparc64/2023-10-08/devel/llvm/13.log
>
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/devel/llvm/Makefile.inc,v
> retrieving revision 1.9
> diff -u -p -r1.9 Makefile.inc
> --- Makefile.inc 23 Sep 2023 12:31:55 - 1.9
> +++ Makefile.inc 12 Oct 2023 18:45:52 -
> @@ -183,8 +183,9 @@ post-install:
> rm -rf ${PREFIX}/${LLVM_BASE}/man
>
> # search and remove headers that might conflict with base
> + # explicitly leave unwind.h in place for sparc64 (base-gcc)
> cd ${PREFIX}/${CLANG_INCLUDE_PATH} && \
> - find . -name '*.h' | sed "s,./,,g" | while read h; \
> + find . -name '*.h' | fgrep -v './unwind.h' | sed "s,./,,g" |
> while read h; \
> do \
> if test -e /usr/include/$${h}; then rm $${h}; fi; \
> done
> Index: 16/patches/patch-clang_tools_clang-shlib_CMakeLists_txt
> ===
> RCS file: 16/patches/patch-clang_tools_clang-shlib_CMakeLists_txt
> diff -N 16/patches/patch-clang_tools_clang-shlib_CMakeLists_txt
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ 16/patches/patch-clang_tools_clang-shlib_CMakeLists_txt 12 Oct 2023
> 18:45:52 -
> @@ -0,0 +1,13 @@
> +-Bsymbolic-functions is not supported by our ld.bfd version.
> +
> +Index: clang/tools/clang-shlib/CMakeLists.txt
> +--- clang/tools/clang-shlib/CMakeLists.txt.orig
> clang/tools/clang-shlib/CMakeLists.txt
> +@@ -50,6 +50,6 @@ add_clang_library(clang-cpp
> + ${_DEPS})
> + # Optimize function calls for default visibility definitions to avoid PLT
> and
> + # reduce dynamic relocations.
> +-if (NOT APPLE AND NOT MINGW)
> ++if (NOT APPLE AND NOT MINGW AND ${OPENBSD_LD_IS_LLD})
> + target_link_options(clang-cpp PRIVATE LINKER:-Bsymbolic-functions)
> + endif()
> Index: 16/patches/patch-llvm_tools_llvm-shlib_CMakeLists_txt
> ===
> RCS file: 16/patches/patch-llvm_tools_llvm-shlib_CMakeLists_txt
> diff -N 16/patches/patch-llvm_tools_llvm-shlib_CMakeLists_txt
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ 16/patches/patch-llvm_tools_llvm-shlib_CMakeLists_txt 12 Oct 2023
> 18:45:52 -
> @@ -0,0 +1,14 @@
> +-Bsymbolic-functions is not supported by our ld.bfd version.
> +
> +Index: llvm/tools/llvm-shlib/CMakeLists.txt
> +--- llvm/tools/llvm-shlib/CMakeLists.txt.orig
> llvm/tools/llvm-shlib/CMakeLists.txt
> +@@ -51,7 +51,7 @@ if(LLVM_BUILD_LLVM_DYLIB)
> + # Solaris ld does not accept global: *; so there is no way to version
> *all* global symbols
> + set(LIB_NAMES
> -Wl,--version-script,${LLVM_LIBRARY_DIR}/tools/llvm-shlib/simple_version_script.map
> ${LIB_NAMES})
> + endif()
> +-if (NOT MINGW)
> ++if (NOT MINGW AND ${OPENBSD_LD_IS_LLD})
> + # Optimize function calls for default visibility definitions to avoid
> PLT and
> + # reduce dynamic relocations.
> + # Note: for -fno-pic default, the address of a function may be
> different from
--
Regards,
Robert Nagy
Re: devel/llvm: add mk.conf notes to README
ok
On 12/10/23 18:04 +, Klemens Nanni wrote:
> Robert Nagy wrote:
> > Then you can put these in /etc/mk.conf:
> >
> > AR=/usr/local/llvm16/bin/llvm-ar
> > AS=/usr/local/llvm16/bin/llvm-as
> > CC=/usr/local/llvm16/bin/clang
> > CXX=/usr/local/llvm16/bin/clang++
> > CPP=/usr/local/llvm16/bin/clang-cpp
> > LD=/usr/local/llvm16/bin/ld.lld
>
> This is useful to know when wanting to use ports clang for, e.g. base builds.
>
> Can we provide something like this in the port for testers to refer to?
>
>
> Index: 13/Makefile
> ===
> RCS file: /cvs/ports/devel/llvm/13/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- 13/Makefile 23 Sep 2023 12:31:55 - 1.11
> +++ 13/Makefile 6 Oct 2023 10:28:27 -
> @@ -2,7 +2,7 @@ LLVM_MAJOR = 13
> LLVM_VERSION = ${LLVM_MAJOR}.0.0
> LLVM_PKGSPEC = >=13,<14
>
> -REVISION-main = 16
> +REVISION-main = 17
> REVISION-lldb = 5
> REVISION-python =4
>
> Index: 16/Makefile
> ===
> RCS file: /cvs/ports/devel/llvm/16/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- 16/Makefile 23 Sep 2023 12:31:55 - 1.10
> +++ 16/Makefile 6 Oct 2023 10:28:34 -
> @@ -2,7 +2,7 @@ LLVM_MAJOR = 16
> LLVM_VERSION = ${LLVM_MAJOR}.0.6
> LLVM_PKGSPEC = >=16,<17
>
> -REVISION-main = 8
> +REVISION-main = 9
> REVISION-lldb = 2
> REVISION-python =1
>
> Index: files/README-main
> ===
> RCS file: /cvs/ports/devel/llvm/files/README-main,v
> retrieving revision 1.1
> diff -u -p -r1.1 README-main
> --- files/README-main 3 Sep 2023 16:04:02 - 1.1
> +++ files/README-main 6 Oct 2023 10:40:42 -
> @@ -2,6 +2,17 @@
> | Running ${PKGSTEM} on OpenBSD
> +---
>
> +To use different compiler versions for, e.g. release(8), point mk.conf(5)
> +at this port:
> +
> + AR=${PREFIX}/${LLVM_BASE}/bin/llvm-ar
> + AS=${PREFIX}/${LLVM_BASE}/bin/llvm-as
> + CC=${PREFIX}/${LLVM_BASE}/bin/clang
> + CXX=${PREFIX}/${LLVM_BASE}/bin/clang++
> + CPP=${PREFIX}/${LLVM_BASE}/bin/clang-cpp
> + LD=${PREFIX}/${LLVM_BASE}/bin/ld.lld
> +
> +
> For more information about using scan-build for the static analyser,
> look at:
> http://clang-analyzer.llvm.org/scan-build.html
--
Regards,
Robert Nagy
[maintainer update] x11/copyq
I updated copyq to 7.1.0, built without problem, works fine for me.
Changelog:
# Changed
- Image editor (if set) will now open instead of built-in text editor
when selecting Edit action on image items containing no text.
- Encryption now uses larger/safer keys (#2385).
# Fixed
- Fixes saving and opening empty encrypted tabs.
- Fixes minimal size of dialogs (#2299).
- Fixes importing commands with regular expressions containing slash
characters in scripts.
- Fixes font weight with Qt 6.
- Fixes closing the app with Qt 6.
- Fixes the build and calling some script functions with Qt 6.5.
- X11: Fixes crash when entering search with some keyboard layouts (#2171).
--
kikadf
Index: x11/copyq/Makefile
===
RCS file: /cvs/ports/x11/copyq/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- x11/copyq/Makefile 15 May 2023 12:21:54 - 1.4
+++ x11/copyq/Makefile 10 Sep 2023 16:28:58 -
@@ -1,7 +1,7 @@
COMMENT = Qt5 based clipboard manager
GH_ACCOUNT = hluk
GH_PROJECT = CopyQ
-GH_TAGNAME = v7.0.0
+GH_TAGNAME = v7.1.0
PKGNAME = ${DISTNAME:L}
CATEGORIES = x11
Index: x11/copyq/distinfo
===
RCS file: /cvs/ports/x11/copyq/distinfo,v
retrieving revision 1.3
diff -u -r1.3 distinfo
--- x11/copyq/distinfo 15 May 2023 12:21:54 - 1.3
+++ x11/copyq/distinfo 10 Sep 2023 16:28:58 -
@@ -1,2 +1,2 @@
-SHA256 (CopyQ-7.0.0.tar.gz) = WJi6ICX46fYaS0cy6FrfOxZT+tILXB8bDIeae3LNTUg=
-SIZE (CopyQ-7.0.0.tar.gz) = 3323354
+SHA256 (CopyQ-7.1.0.tar.gz) = zgJlsKhjUP2nv6Gp1LdNeUpAd1UbKBhgEmg1Z9b9gVg=
+SIZE (CopyQ-7.1.0.tar.gz) = 3351093
Re: Longtime BROKEN ports
On 06/09/23 22:12 +0200, Christian Weisgerber wrote: > How long does a port have to stay marked BROKEN before we concede that > it won't be fixed, and we remove it? > > I did some grep, got blame, sort, etc. and here are some contenders > that have been BROKEN since before 2020: > > portmarked broken > math/wxMaxima 2014-07-24 edd > sysutils/cfengine 2016-11-19 sthen > games/speeddreams 2018-01-25 pascal > www/pecl-pecl_http 2019-03-08 sthen > lang/ponyc 2019-07-06 jca > delete delete delete
Re: chrome: unveil AT SPI2 socket to enable screen reader
go ahead
On 05/08/23 05:25 +, Klemens Nanni wrote:
> On Fri, Aug 04, 2023 at 10:27:46PM +, Klemens Nanni wrote:
> > https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/
> >
> > In there is a D-Bus socket used to communicate with tools like
> > x11/gnome/orca. Use orca(1) -s and tick the 'Speak object under mouse' box
> > to hear it reading out elements, texts, etc.
> >
> > I'm new to accessibility features and noticed that browsers wouldn't work
> > whereas other ports without pledge/unveil would.
> >
> > Patch is for Firefox and Firefox ESR.
> > Will check the Chromes next.
>
> I've verified that they need the same treatment for orca to work.
>
> >
> > Feedback? Objection? OK?
>
>
> Index: chromium/Makefile
> ===
> RCS file: /cvs/ports/www/chromium/Makefile,v
> retrieving revision 1.730
> diff -u -p -r1.730 Makefile
> --- chromium/Makefile 26 Jul 2023 18:27:38 - 1.730
> +++ chromium/Makefile 5 Aug 2023 05:16:27 -
> @@ -7,6 +7,7 @@ DPB_PROPERTIES= parallel parallel2
> COMMENT= Chromium browser
>
> V= 115.0.5790.110
> +REVISION=0
>
> DISTNAME=chromium-${V}
>
> Index: chromium/files/unveil.main
> ===
> RCS file: /cvs/ports/www/chromium/files/unveil.main,v
> retrieving revision 1.13
> diff -u -p -r1.13 unveil.main
> --- chromium/files/unveil.main31 May 2023 11:34:32 - 1.13
> +++ chromium/files/unveil.main5 Aug 2023 05:18:40 -
> @@ -54,6 +54,7 @@
> ~/.terminfo r
>
> ~/.cache/chromium rwc
> +~/.cache/at-spi rw
> ~/.cache/dconf rwc
> ~/.cache/fontconfig rwc
> ~/.cache/gvfsd rwc
> Index: ungoogled-chromium/Makefile
> ===
> RCS file: /cvs/ports/www/ungoogled-chromium/Makefile,v
> retrieving revision 1.68
> diff -u -p -r1.68 Makefile
> --- ungoogled-chromium/Makefile 1 Aug 2023 07:29:25 - 1.68
> +++ ungoogled-chromium/Makefile 5 Aug 2023 05:18:25 -
> @@ -11,7 +11,7 @@ V= 115.0.5790.110
> UGV= ${V}-1
>
> DISTNAME=ungoogled-chromium-${V}
> -REVISION=0
> +REVISION=1
>
> DISTFILES+= ${CHROMIUM_DISTFILES} \
> ${UGOOGLE_DISTFILES}:0 \
> Index: ungoogled-chromium/files/unveil.main
> ===
> RCS file: /cvs/ports/www/ungoogled-chromium/files/unveil.main,v
> retrieving revision 1.2
> diff -u -p -r1.2 unveil.main
> --- ungoogled-chromium/files/unveil.main 5 May 2023 10:59:18 -
> 1.2
> +++ ungoogled-chromium/files/unveil.main 5 Aug 2023 05:18:23 -
> @@ -54,6 +54,7 @@
> ~/.terminfo r
>
> ~/.cache/ungoogled-chromium rwc
> +~/.cache/at-spi rw
> ~/.cache/dconf rwc
> ~/.cache/fontconfig rwc
> ~/.cache/thumbnails rwc
> Index: iridium/Makefile
> ===
> RCS file: /cvs/ports/www/iridium/Makefile,v
> retrieving revision 1.178
> diff -u -p -r1.178 Makefile
> --- iridium/Makefile 24 Jul 2023 14:15:42 - 1.178
> +++ iridium/Makefile 5 Aug 2023 05:17:40 -
> @@ -11,6 +11,7 @@ DPB_PROPERTIES+=lonesome
> COMMENT= Iridium browser
>
> V= 2023.07.115.1
> +REVISION=0
>
> DISTNAME=iridium-browser-${V}
> PKGNAME= iridium-${V}
> Index: iridium/files/unveil.main
> ===
> RCS file: /cvs/ports/www/iridium/files/unveil.main,v
> retrieving revision 1.12
> diff -u -p -r1.12 unveil.main
> --- iridium/files/unveil.main 21 Jul 2023 17:36:58 - 1.12
> +++ iridium/files/unveil.main 5 Aug 2023 05:19:00 -
> @@ -54,6 +54,7 @@
> ~/.terminfo r
>
> ~/.cache/iridium rwc
> +~/.cache/at-spi rw
> ~/.cache/dconf rwc
> ~/.cache/fontconfig rwc
> ~/.cache/gvfsd rwc
--
Regards,
Robert Nagy
Re: mono build fails on my Tigerlake without USE_NOBTCFI
Yes I left it out so that I can start having a look into it
but I guess it is going to take a lot of time so please go
ahead and add USE_NOBTCFI.
On 15/07/23 19:35 -0400, Thomas Frohwein wrote:
> I've tried building the latest version 3 times without USE_NOBTCFI=Yes,
> but every time it crashed with a native error. I'm attaching the error
> log.
>
> Adding USE_NOBTCFI=Yes fixes the build and I can run csharp interactive
> shell again, as well as some FNA games. Diff at the bottom to add this.
> ok?
>
> cd /usr/ports/pobj/mono-6.12.0.199/mono-6.12.0.199/mcs && gmake
> --no-print-directory -s NO_DIR_CHECK=1
> PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14
> ' CC='cc' all-profiles
>
> =
> Native Crash Reporting
> =
> Got a TERM while executing native code. [...]
>
> =
> Native stacktrace:
> =
> 0x9a1d4bb22f1 -
> /usr/ports/pobj/mono-6.12.0.199/mono-6.12.0.199/mono/mini/mono : mono_breakpoi
> nt_clean_code
> 0x9a1d4b4790e -
> /usr/ports/pobj/mono-6.12.0.199/mono-6.12.0.199/mono/mini/mono : mono_debugger
> _run_finally
>
> [...]
>
> =
> Managed Stacktrace:
> =
> at System.OutOfMemoryException:.ctor <0x0>
> at :runtime_invoke_void__this___object <0x000c3>
> =
> Abort trap (core dumped)
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/mono/Makefile,v
> retrieving revision 1.153
> diff -u -p -r1.153 Makefile
> --- Makefile 15 Jul 2023 11:52:42 - 1.153
> +++ Makefile 15 Jul 2023 23:30:44 -
> @@ -1,4 +1,5 @@
> USE_WXNEEDED=Yes
> +USE_NOBTCFI= Yes
>
> COMMENT= cross platform, open source .NET developement framework
>
> @@ -6,6 +7,7 @@ V=6.12.0.199
> MONOLITEV= 1A5E0066-58DC-428A-B21C-0AD6CDAE2789
>
> DISTNAME=mono-${V}
> +REVISION=0
>
> CATEGORIES= lang devel
>
--
Regards,
Robert Nagy
Re: multimedia/libv4l: ignore libudev-openbsd if installed
Hi
I think we should look into fixing libv4l because at one point
we plan to enable libudev-openbsd port.
On 15/07/23 20:26 +0200, Matthieu Herrb wrote:
> Hi,
>
> For my wlroots/sway work I have sysutils/libudev-openbsd installed as
> a dependecy. This breaks multimedia/libv4l (which is needed as
> dependency for ffmpeg, which is a run-dependency for wlroots).
>
> The patch below is a way to fix this. Comments, ok ?
>
> Index: Makefile
> ===
> RCS file: /local/cvs/ports/multimedia/libv4l/Makefile,v
> retrieving revision 1.30
> diff -u -p -u -r1.30 Makefile
> --- Makefile 3 Mar 2023 11:42:45 - 1.30
> +++ Makefile 15 Jul 2023 18:24:16 -
> @@ -3,7 +3,7 @@ COMMENT = libv4l userspace library
> VERSION =1.20.0
> DISTNAME = v4l-utils-${VERSION}
> PKGNAME =libv4l-${VERSION}
> -REVISION = 3
> +REVISION = 4
>
> SHARED_LIBS += v4l10.0 # 0.0
> SHARED_LIBS += v4l20.0 # 0.0
> Index: patches/patch-configure_ac
> ===
> RCS file: patches/patch-configure_ac
> diff -N patches/patch-configure_ac
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-configure_ac15 Jul 2023 18:24:16 -
> @@ -0,0 +1,16 @@
> +Ignore libudev-openbsd if present
> +
> +Index: configure.ac
> +--- configure.ac.orig
> configure.ac
> +@@ -291,8 +291,8 @@ else
> +AC_MSG_WARN(ALSA library not available)
> + fi
> +
> +-PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes, have_libudev=no)
> +-if test "x$have_libudev" = "xyes"; then
> ++# PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes, have_libudev=no)
> ++if /bin/false; then
> + AC_DEFINE([HAVE_LIBUDEV], [], [Use libudev])
> + LIBUDEV_CFLAGS="$libudev_CFLAGS"
> + LIBUDEV_LIBS="$libudev_LIBS"
>
> --
> Matthieu Herrb
>
--
Regards,
Robert Nagy
Re: multimedia/dav1d arm64 fixes
pc_neon, export=1 > clz w9, w3 > @@ -617,7 +689,7 @@ Index: src/arm/64/ipred.S > add x6, x0, x1 > lsl x1, x1, #1 > br x7 > -@@ -4186,11 +4216,13 @@ function ipred_cfl_top_8bpc_neon, export=1 > +@@ -4186,11 +4224,13 @@ function ipred_cfl_top_8bpc_neon, export=1 > dup v0.8h, v2.h[0] > b L(ipred_cfl_splat_w16) > > @@ -635,7 +707,7 @@ Index: src/arm/64/ipred.S > endfunc > > // void ipred_cfl_left_8bpc_neon(pixel *dst, const ptrdiff_t stride, > -@@ -4201,15 +4233,15 @@ function ipred_cfl_left_8bpc_neon, export=1 > +@@ -4201,15 +4241,15 @@ function ipred_cfl_left_8bpc_neon, export=1 > sub x2, x2, w4, uxtw > clz w9, w3 > clz w8, w4 > @@ -657,7 +729,7 @@ Index: src/arm/64/ipred.S > add x6, x0, x1 > lsl x1, x1, #1 > br x7 > -@@ -4248,11 +4280,13 @@ L(ipred_cfl_left_h32): > +@@ -4248,11 +4288,13 @@ L(ipred_cfl_left_h32): > dup v0.8h, v2.h[0] > br x9 > > @@ -675,7 +747,7 @@ Index: src/arm/64/ipred.S > endfunc > > // void ipred_cfl_8bpc_neon(pixel *dst, const ptrdiff_t stride, > -@@ -4266,16 +4300,15 @@ function ipred_cfl_8bpc_neon, export=1 > +@@ -4266,16 +4308,15 @@ function ipred_cfl_8bpc_neon, export=1 > clz w9, w3 > clz w6, w4 > dup v16.8h, w8 // width + height > @@ -696,7 +768,7 @@ Index: src/arm/64/ipred.S > ushrv16.8h, v16.8h, #1 // (width + height) >> 1 > dup v17.8h, w8 // -ctz(width + height) > add x6, x0, x1 > -@@ -4392,15 +4425,17 @@ L(ipred_cfl_w32): > +@@ -4392,15 +4433,17 @@ L(ipred_cfl_w32): > dup v0.8h, v0.h[0] > b L(ipred_cfl_splat_w16) > > @@ -722,7 +794,7 @@ Index: src/arm/64/ipred.S > endfunc > > // void cfl_ac_420_8bpc_neon(int16_t *const ac, const pixel *const ypx, > -@@ -4409,14 +,14 @@ endfunc > +@@ -4409,14 +4452,14 @@ endfunc > function ipred_cfl_ac_420_8bpc_neon, export=1 > clz w8, w5 > lsl w4, w4, #2 > @@ -740,7 +812,7 @@ Index: src/arm/64/ipred.S > sub w8, w6, w4 // height - h_pad > rbitw9, w5 // rbit(width) > rbitw10, w6 // rbit(height) > -@@ -4555,9 +4590,9 @@ L(ipred_cfl_ac_420_w8_subtract_dc): > +@@ -4555,9 +4598,9 @@ L(ipred_cfl_ac_420_w8_subtract_dc): > > L(ipred_cfl_ac_420_w16): > AARCH64_VALID_JUMP_TARGET > @@ -753,7 +825,7 @@ Index: src/arm/64/ipred.S > br x7 > > L(ipred_cfl_ac_420_w16_wpad0): > -@@ -4714,17 +4749,19 @@ L(ipred_cfl_ac_420_w16_hpad): > +@@ -4714,17 +4757,19 @@ L(ipred_cfl_ac_420_w16_hpad): > lsl w6, w6, #1 > b L(ipred_cfl_ac_420_w8_calc_subtract_dc) > > @@ -781,7 +853,7 @@ Index: src/arm/64/ipred.S > endfunc > > // void cfl_ac_422_8bpc_neon(int16_t *const ac, const pixel *const ypx, > -@@ -4733,14 +4770,14 @@ endfunc > +@@ -4733,14 +4778,14 @@ endfunc > function ipred_cfl_ac_422_8bpc_neon, export=1 > clz w8, w5 > lsl w4, w4, #2 > @@ -799,7 +871,7 @@ Index: src/arm/64/ipred.S > sub w8, w6, w4 // height - h_pad > rbitw9, w5 // rbit(width) > rbitw10, w6 // rbit(height) > -@@ -4831,9 +4868,9 @@ L(ipred_cfl_ac_422_w8_wpad): > +@@ -4831,9 +4876,9 @@ L(ipred_cfl_ac_422_w8_wpad): > > L(ipred_cfl_ac_422_w16): > AARCH64_VALID_JUMP_TARGET > @@ -812,7 +884,7 @@ Index: src/arm/64/ipred.S > br x7 > > L(ipred_cfl_ac_422_w16_wpad0): > -@@ -4936,17 +4973,19 @@ L(ipred_cfl_ac_422_w16_wpad3): > +@@ -4936,17 +4981,19 @@ L(ipred_cfl_ac_422_w16_wpad3): > mov v1.16b, v3.16b > b L(ipred_cfl_ac_420_w16_hpad) > > @@ -840,7 +912,7 @@ Index: src/arm/64/ipred.S > endfunc > > // void cfl_ac_444_8bpc_neon(int16_t *const ac, const pixel *const ypx, > -@@ -4955,14 +4994,14 @@ endfunc > +@@ -4955,14 +5002,14 @@ endfunc > function ipred_cfl_ac_444_8bpc_neon, export=1 > clz w8, w5 > lsl w4, w4, #2 > @@ -858,7 +930,7 @@ Index: src/arm/64/ipred.S > sub w8, w6, w4 // height - h_pad > rbitw9, w5 // rbit(width) > rbitw10, w6 // rbit(height) > -@@ -5083,9 +5122,10 @@ L(ipred_cfl_ac_444_w16_wpad): > +@@ -5083,9 +5130,10 @@ L(ipred_cfl_ac_444_w16_wpad): > > L(ipred_cfl_ac_444_w32): > AARCH64_VALID_JUMP_TARGET > @@ -872,7 +944,7 @@ Index: src/arm/64/ipred.S > br x7 > > L(ipred_cfl_ac_444_w32_wpad0): > -@@ -5231,15 +5271,17 @@ L(ipred_cfl_ac_444_w32_hpad): > +@@ -5231,15 +5279,17 @@ L(ipred_cfl_ac_444_w32_hpad): > dup v4.8h, v4.h[0] > b L(ipred_cfl_ac_420_w8_subtract_dc) > -- Regards, Robert Nagy
Re: [NEW] net/megacmd
Removed sdk/configure patch which removes the stdc++fs check, add .if
${PROPERTIES:Mclang} + sed to the Makefile as post-patch.
Stuart Henderson ezt írta (időpont: 2023. jún.
23., P, 18:02):
>
> On 2023/06/23 17:37, Robert Bagdan wrote:
> > >
> > > can replicate the linking failure, but haven't looked into it.
> > >
> >
> > I patched the configure script of sdk to not add -lstdc++fs as
> > LDFLAGS, I hope this fixes the linking error.
> > I think you have installed gcc so the configure script found
> > libstdc++fs, which is causing the linking error. #fixme
> >
> >
> > --
> > kikadf
>
> ah, that might need to be made conditional, presumably it is needed if
> you build on an arch which doesn't use clang.
>
> easiest way is probably to use sed rather than a patch and do e.g.
>
> .include
> .if ${PROPERTIES:Mclang}
> post-extract:
> sed -i <...>
> .endif
>
--
kikadf
megacmd.tar.gz
Description: application/gzip
Re: [NEW] net/megacmd
> > can replicate the linking failure, but haven't looked into it. > I patched the configure script of sdk to not add -lstdc++fs as LDFLAGS, I hope this fixes the linking error. I think you have installed gcc so the configure script found libstdc++fs, which is causing the linking error. #fixme -- kikadf megacmd.tar.gz Description: application/gzip
misc/screen segfault on arm64
Hi, I installed the misc/screen port. Anybody knows why this happens on arm64 ? ws-4# uname -aOpenBSD ws-4.my.domain 7.3 GENERIC.MP#2164 arm64 ws-4# screen -vSegmentation fault (core dumped) No problem with amd64: ws-3# uname -aOpenBSD ws-3.my.domain 7.3 GENERIC#1072 amd64 ws-3# screen -vScreen version 4.09.00 (GNU) 30-Jan-22 Thank you.
Re: [NEW] net/megacmd
I upgraded Makefile to use GH_DISTFILE.
Also I found a commit from upstream to fix some implicit conversion
warnings:
https://github.com/meganz/sdk/commit/a0e222bf72640c85c89ff9d26c1c1a467565cc8f
What is the correct way to backport these changes to the sdk version
that is used by megacmd? Backport all changes and generate file by
file patches to the patches/ directory or use one patch with all
changes, put the files/ directory and apply in Makefile at post-patch
time? (sdk patch not work as PATCHFILES because the sdk path is
${WRKSRC}/sdk)
I built megacmd with the shared lib, but I haven't got linking error.
I see you have libstdc++fs, but I haven’t, in my configure output:
checking for main in -lstdc++fs... no
Stuart Henderson ezt írta (időpont: 2023. jún.
20., K, 21:48):
>
> On 2023/06/20 17:00, Stuart Henderson wrote:
> > I don't have an account to test runtime, but this is looking much
> > better to me now.
>
> oh, ermm, linking fails - did you actually get it built with the
> shared lib?
>
> mv -f src/.deps/mega_cmd_server-comunicationsmanagerfilesockets.Tpo src/.deps/
> mega_cmd_server-comunicationsmanagerfilesockets.Po
> /usr/bin/libtool --mode=link c++ -g -O2 -pthread -L/usr/local/lib -o me
> ga-cmd-server src/mega_cmd_server-megacmd.o src/mega_cmd_server-comunications
> manager.o src/mega_cmd_server-megacmdutils.o src/mega_cmd_server-megacmdcomm
> onutils.o src/mega_cmd_server-configurationmanager.o src/mega_cmd_server-meg
> acmdlogger.o src/mega_cmd_server-megacmdsandbox.o src/mega_cmd_server-listen
> ers.o src/mega_cmd_server-megacmdexecuter.o src/mega_cmd_server-megacmdtrans
> fermanager.o src/mega_cmd_server-comunicationsmanagerportsockets.o src/mega
> _cmd_server-comunicationsmanagerfilesockets.o -lsqlite3 -lpcrecpp -lpcre ./s
> dk/src/libmega.la
> libtool: link: c++ -o .libs/mega-cmd-server -pthread -g -O2 src/mega_cmd_serve
> r-megacmd.o src/mega_cmd_server-comunicationsmanager.o src/mega_cmd_server-meg
> acmdutils.o src/mega_cmd_server-megacmdcommonutils.o src/mega_cmd_server-confi
> gurationmanager.o src/mega_cmd_server-megacmdlogger.o src/mega_cmd_server-mega
> cmdsandbox.o src/mega_cmd_server-listeners.o src/mega_cmd_server-megacmdexecut
> er.o src/mega_cmd_server-megacmdtransfermanager.o src/mega_cmd_server-comunica
> tionsmanagerportsockets.o src/mega_cmd_server-comunicationsmanagerfilesockets.
> o -L.libs -lsqlite3 -lz -lm -lpthread -lpcrecpp -lpcre -lmega /usr/local/lib/l
> ibstdc++fs.a -lcares -lcurl -lnghttp3 -lngtcp2_crypto_openssl -lngtcp2 -lssl -
> lcrypto -lnghttp2 -luv -lcryptopp -lsodium -Wl,-rpath-link,/usr/local/lib
> megacmd.cpp(src/mega_cmd_server-megacmd.o:(megacmd::executecommand(char*))): w
> arning: sprintf() is often misused, please use snprintf()
> megacmdutils.cpp(src/mega_cmd_server-megacmdutils.o:(megacmd::getTimeStampAfte
> r(long long, std::__1::basic_string, std::__
> 1::allocator >))): warning: strcpy() is almost always misused, please us
> e strlcpy()
> ld: error: .libs/libmega.so.0.0: undefined reference to std::__throw_length_er
> ror(char const*) [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::_V2::system_categ
> ory() [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::_V2::generic_cate
> gory() [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::__throw_logic_err
> or(char const*) [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::runtime_error::ru
> ntime_error(std::__cxx11::basic_string, std::allo
> cator > const&) [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::system_error::~sy
> stem_error() [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::__codecvt_utf8_ba
> se::~__codecvt_utf8_base() [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::_Hash_bytes(void
> const*, unsigned long, unsigned long) [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::__throw_out_of_ra
> nge_fmt(char const*, ...) [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::codecvt char, __mbstate_t> const& std::use_facet _t> >(std::locale const&) [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::codecvt char, __mbstate_t>::codecvt(unsigned long) [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::__codecvt_utf8_ba
> se::do_max_length() const [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to std::__codecvt_utf8_ba
> se::do_out(__mbstate_t&, wchar_t const*, wchar_t const*, wchar_t cons
> t*&, char*, char*, char*&) const [--no-allow-shlib-undefined]
> ld: error: .libs/libmega.so.0.0: undefined reference to typeinfo for std::syst
> em_error [--no-allow-shlib-undefined]
> ld: e
Re: [NEW] net/megacmd
I updated megacmd files with your mentions:
1) Sorted the variables as per Makefile.template
2) Renamed the sdk distname
3) Set DISTFILES once
4) I don't add bash as RUN_DEPENDS because it isn't need to use
megacmd, works well with other shells, I use with the default ksh
5) gtest to TEST_DEPENDS
6) Splitted and sorted CONFIGURE_ARGS
7) Consistently use of variable declarations
8) Fix PLIST
9) Remove AI_V4MAPPED from http.cpp, and fix http.h patch to not declare that
10) Use shared libs (I forgot why I used the static library…)
11) I don't split the sdk library, as use this only megacmd and not
possible to set the sdk libs as external dependency in configure
script of megacmd
12) patching megacmd to use the default bash-completion path
13) Change DESCR
I built and tested on -current, works for me.
Robert Bagdan ezt írta (időpont: 2023. jún. 15.,
Cs, 18:05):
>
> Thanks to your reviews, I will install -current OpenBSD to a vm in the
> next few days, and fix this port with your modifications and
> proposals.
> I will come back soon.
>
> Stuart Henderson ezt írta (időpont: 2023. jún.
> 15., Cs, 9:24):
> >
> > On 2023/06/14 13:13, Omar Polo wrote:
> >
> > > the patches seemed fine for me. I'd wish we could avoid patching for
> > > ereadline.
> >
> > that's normal for our renamed ports version of readline.
> >
> > > The only odd one is patches/patch-sdk_include_mega_http_h which
> > > defines AI_V4MAPPED...
> >
> > sdk/include/mega/http.h
> > 44-
> > 45-#if defined(__FreeBSD__) || defined(__OpenBSD__)
> > 46-#include
> > 47:#define AI_V4MAPPED 0x0800
> > 48-#endif
> > 49-
> > 50-namespace mega {
> >
> > yes, don't set it to some random value
> >
> > sdk/src/http.cpp
> > 270-hints.ai_family = AF_UNSPEC;
> > 271-
> > 272-#ifndef __MINGW32__
> > 273:hints.ai_flags = AI_V4MAPPED | AI_ADDRCONFIG;
> > 274-#endif
> > 275-
> > 276-if (!getaddrinfo("ns.mega.co.nz", NULL, &hints, &aiList))
> >
> > since it's only used in this one place, best bet is to remoce the http.h
> > patch and remove AI_V4MAPPED from http.cpp.
> >
> > (if it was used more often, I'd define it, but to 0).
> >
> >
> > > - the bundled sdk installs also the headers, a static library and a
> > >pkgconfig file:
> > >
> > > 1. we usually prefer dynamic linking
> > > 2. would it make sense (maybe in the future) to split the sdk off
> > > this port? There are other projects we may want that need
> > > this sdk too? Maybe there's already something in ports that
> > > optionally looks for this and could statically link to
> > > libmega?
> >
> > I think I would have used a separate port for the sdk, but think this
> > way is ok too (especially if nothing else uses the sdk).
> >
> > > - i'd probably install the bash completions in
> > >/usr/local/share/bash-completion and avoid to @sample, but I don't
> > >use bash and don't really know the difference (if there is) to
> > >install in /etc/bash_completion.d.
> >
> > yes, please use /usr/local/share/bash-completion like other ports do.
> >
> > "MEGAcmd provides non UI access to MEGA services"
> >
> > I see this is just copied from the readme, but "non UI" doesn't make
> > much sense. Something like "MEGAcmd provides scriptable command-line
> > tools and an interactive shell to access services from mega.nz"?
> >
>
>
> --
> kikadf
--
kikadf
megacmd.tar.gz
Description: application/gzip
Re: [NEW] net/megacmd
Thanks to your reviews, I will install -current OpenBSD to a vm in the
next few days, and fix this port with your modifications and
proposals.
I will come back soon.
Stuart Henderson ezt írta (időpont: 2023. jún.
15., Cs, 9:24):
>
> On 2023/06/14 13:13, Omar Polo wrote:
>
> > the patches seemed fine for me. I'd wish we could avoid patching for
> > ereadline.
>
> that's normal for our renamed ports version of readline.
>
> > The only odd one is patches/patch-sdk_include_mega_http_h which
> > defines AI_V4MAPPED...
>
> sdk/include/mega/http.h
> 44-
> 45-#if defined(__FreeBSD__) || defined(__OpenBSD__)
> 46-#include
> 47:#define AI_V4MAPPED 0x0800
> 48-#endif
> 49-
> 50-namespace mega {
>
> yes, don't set it to some random value
>
> sdk/src/http.cpp
> 270-hints.ai_family = AF_UNSPEC;
> 271-
> 272-#ifndef __MINGW32__
> 273:hints.ai_flags = AI_V4MAPPED | AI_ADDRCONFIG;
> 274-#endif
> 275-
> 276-if (!getaddrinfo("ns.mega.co.nz", NULL, &hints, &aiList))
>
> since it's only used in this one place, best bet is to remoce the http.h
> patch and remove AI_V4MAPPED from http.cpp.
>
> (if it was used more often, I'd define it, but to 0).
>
>
> > - the bundled sdk installs also the headers, a static library and a
> >pkgconfig file:
> >
> > 1. we usually prefer dynamic linking
> > 2. would it make sense (maybe in the future) to split the sdk off
> > this port? There are other projects we may want that need
> > this sdk too? Maybe there's already something in ports that
> > optionally looks for this and could statically link to
> > libmega?
>
> I think I would have used a separate port for the sdk, but think this
> way is ok too (especially if nothing else uses the sdk).
>
> > - i'd probably install the bash completions in
> >/usr/local/share/bash-completion and avoid to @sample, but I don't
> >use bash and don't really know the difference (if there is) to
> >install in /etc/bash_completion.d.
>
> yes, please use /usr/local/share/bash-completion like other ports do.
>
> "MEGAcmd provides non UI access to MEGA services"
>
> I see this is just copied from the readme, but "non UI" doesn't make
> much sense. Something like "MEGAcmd provides scriptable command-line
> tools and an interactive shell to access services from mega.nz"?
>
--
kikadf
Re: [NEW] net/megacmd
Hi! To build megacmd: get the 7.3 branch of the ports tree, extract magacmd.tar.gz attachment to the net subdirectory in your ports tree, and run "make FETCH_PACKAGES= install" from net/megacmd subdirectory. I don't know megatools, so I can't help with that.
Re: Python 3.10 required by py3-bsddb3 but not supported
On 01/06/23 11:02 +0100, Stuart Henderson wrote: > [moved to ports@; reply-to set] > > On 2023-05-31, Roger Marsh wrote: > > Script started on Wed May 31 10:43:00 2023 > > This pkg_info report shows Python 3.10 required by py3-bsddb3 after upgrade > > from OpenBSD 7.2 to 7.3 and package upgrade. > > > > As bsddb3 does not support Python 3.10 or later but does support Python 3.9 > > and earlier, surely the requirement should be on Python 3.9, or perhaps the > > py3-bsddb3 port should be removed. > > All py3-* ports are built against a single Python branch, in OpenBSD 7.3 > this is 3.10. It can't be mixed-and-matched. > > I think py-bsddb3 should be removed. > > Upstream has replaced it with py-berkeleydb > (https://www.jcea.es/programacion/pybsddb.htm) but we can't switch to that > unless someone updates databases/db to a newer version (probably either > 4.8.30 or 5.3.28 - newer ones have switched to a much more restrictive > license). > > Two ports used py-bsddb3: gramps (though this has preferred sqlite since 5.1 > back in 2019) - I've just removed the dependency, and kopano-core - I think > only a few parts of kopano-core use bsddb3, and AIUI users of kopano should > be migrating to grommunio anyway, I think robert@ was planning to remove the > port sometime. Anyway we either need to remove the dep on py-bsddb3, or > remove kopano-core, before we can remove the py-bsddb3 port. > I think kopano can be unhooked from the builds and we can still keep the port if someone really needs it for migration.
Re: NEW: asio
On 25/05/23 10:56 -0400, A Tammy wrote: > > On 5/25/23 10:22, Brad Smith wrote: > > ping. > > in case you missed the emails, both sthen@ and I (aisha@) gave OK > > I also sent OK for galera. The galera part cannot be commited until someone tests it with an actual cluster.
Re: [maintainer update] x11/copyq
Add the forgotten patch.
Robert Bagdan ezt írta (időpont: 2023. máj. 15.,
H, 11:44):
>
> I updated copyq to 7.0.0, built without problem, works fine for me.
>
> Changelog:
> * Changed
> - The preferred format to edit is now "text/plain;charset=utf-8" with
> "text/plain" as fallback. Additionally, if no such format is
> available, "text/uri-list" is used.
> - Toggle Clipboard Storing menu item uses static text and icon instead
> of changing these dynamically after each use (#2255).
> - Settings integrity is now handled solely by Qt. Previously,
> additional *.bak files where created for configuration files.
> - Commands are no longer migrated to the new format on start. The old
> command configuration file has been last used in version 3.9.0
> (released on 2019-06-27).
> - Native notification text length is limited now to avoid slow downs
> when showing notifications in some desktop environments. The limit is
> about 100,000 characters and 100 lines.
> * Fixed
> - Fixes Sort/Reverse Selected Items menu actions (#2267).
> - Fixes moving items to a tab in tab bar using drag'n'drop (#1246).
> - Fixes possibly buggy window manager frame geometry (#2247).
>
>
> --
> kikadf
--
kikadf
Index: x11/copyq/Makefile
===
RCS file: /cvs/ports/x11/copyq/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- x11/copyq/Makefile 24 Jan 2023 13:14:15 - 1.2
+++ x11/copyq/Makefile 14 May 2023 17:52:38 -
@@ -1,7 +1,7 @@
COMMENT = Qt5 based clipboard manager
GH_ACCOUNT = hluk
GH_PROJECT = CopyQ
-GH_TAGNAME = v6.4.0
+GH_TAGNAME = v7.0.0
PKGNAME = ${DISTNAME:L}
CATEGORIES = x11
Index: x11/copyq/distinfo
===
RCS file: /cvs/ports/x11/copyq/distinfo,v
retrieving revision 1.2
diff -u -r1.2 distinfo
--- x11/copyq/distinfo 24 Jan 2023 13:14:15 - 1.2
+++ x11/copyq/distinfo 14 May 2023 17:52:38 -
@@ -1,2 +1,2 @@
-SHA256 (CopyQ-6.4.0.tar.gz) = rGdXoQ7S1inemsu2Rs27pc9RGX6d/jnT2y/zQGn8SDE=
-SIZE (CopyQ-6.4.0.tar.gz) = 3316278
+SHA256 (CopyQ-7.0.0.tar.gz) = WJi6ICX46fYaS0cy6FrfOxZT+tILXB8bDIeae3LNTUg=
+SIZE (CopyQ-7.0.0.tar.gz) = 3323354
[maintainer update] x11/copyq
I updated copyq to 7.0.0, built without problem, works fine for me. Changelog: * Changed - The preferred format to edit is now "text/plain;charset=utf-8" with "text/plain" as fallback. Additionally, if no such format is available, "text/uri-list" is used. - Toggle Clipboard Storing menu item uses static text and icon instead of changing these dynamically after each use (#2255). - Settings integrity is now handled solely by Qt. Previously, additional *.bak files where created for configuration files. - Commands are no longer migrated to the new format on start. The old command configuration file has been last used in version 3.9.0 (released on 2019-06-27). - Native notification text length is limited now to avoid slow downs when showing notifications in some desktop environments. The limit is about 100,000 characters and 100 lines. * Fixed - Fixes Sort/Reverse Selected Items menu actions (#2267). - Fixes moving items to a tab in tab bar using drag'n'drop (#1246). - Fixes possibly buggy window manager frame geometry (#2247). -- kikadf
Re: [NEW] net/megacmd
I've attached the updated version of net/megacmd, which provides non UI access to MEGA services. It intends to offer all the functionality with your MEGA account via commands. It features synchronization,backup of local folders into your MEGA account. I use on amd64 7.3, works fine for me. -- kikadf megacmd.tar.gz Description: application/gzip
Re: UPDATE www/nginx-1.24.0
h->hash = 0;
> ++h->value.len = 0;
> ++}
> ++
> ++h = *headers;
> ++
> ++h->value = *value;
> ++
> ++if (value->len == 0) {
> ++h->hash = 0;
> ++
> ++} else {
> ++h->hash = hv->hash;
> ++}
> ++
> ++return NGX_OK;
> ++}
> ++
> ++create:
> ++
> ++for (ph = headers; *ph; ph = &(*ph)->next) { /* void */ }
> ++
> ++ho = ngx_list_push(&r->headers_out.headers);
> ++if (ho == NULL) {
> ++return NGX_ERROR;
> ++}
> ++
> ++ho->value = *value;
> ++
> ++if (value->len == 0) {
> ++ho->hash = 0;
> ++
> ++} else {
> ++ho->hash = hv->hash;
> ++}
> ++
> ++ho->key = hv->key;
> ++ho->next = NULL;
> ++*ph = ho;
> ++
> ++return NGX_OK;
> ++#else
> + ngx_array_t *pa;
> + ngx_table_elt_t *ho, **ph;
> + ngx_uint_ti;
> +@@ -378,6 +441,7 @@ create:
> + *ph = ho;
> +
> + return NGX_OK;
> ++#endif
> + }
> +
> +
> diff --git patches/patch-naxsi_naxsi_src_naxsi_net_h
> patches/patch-naxsi_naxsi_src_naxsi_net_h
> deleted file mode 100644
> index 4debf4b57a3..000
> --- patches/patch-naxsi_naxsi_src_naxsi_net_h
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -already committed upstream
> -https://github.com/nbs-system/naxsi/commit/0395b102b7e9b5165e89e99bb62e9ddaa0a74910
> -
> -Index: naxsi/naxsi_src/naxsi_net.h
> naxsi/naxsi_src/naxsi_net.h.orig
> -+++ naxsi/naxsi_src/naxsi_net.h
> -@@ -7,7 +7,7 @@
> - #ifndef __NAXSI_NET_H__
> - #define __NAXSI_NET_H__
> -
> --#if defined(__FreeBSD__)
> -+#if defined(__FreeBSD__) || defined(__OpenBSD__)
> - #include
> - #include
> - #include
>
--
Regards,
Robert Nagy
Re: firefox crashes on an M1 macbook
On 12/04/23 10:27 +0100, Stuart Henderson wrote: > On 2023/04/12 11:15, Jan Stary wrote: > > On Apr 12 11:11:01, h...@stare.cz wrote: > > > This is current/arm64 on an Apple M1 MacBook Air (dmesg below). > > > While everything mostly works, Firefox keeps crashing. > > > > > > Reproducibly, it always crashes on calendar.google.com; > > > _sometimes_ it crashes when playing a video. > > > On simple sites, it works withotu problems. > > > > > > How can I debug this? Is it related to > > > the lack of video acceleration on these machines? > > > > > > Thanks, > > > > > > Jan > > > > message says: > > > > firefox[8493]: pledge "", syscall 289 > > firefox[68604]: pledge "", syscall 289 > > firefox[94066]: pledge "", syscall 289 > > firefox[66504]: pledge "", syscall 289 > > firefox[95111]: pledge "", syscall 289 > > It is doing a call (probably via an X library) to shmget which is not > permitted by any possible pledge, you need to either disable pledge > or find/patch the library to avoid shmget. > > There is a chance it is this one, based on a 2019 diff from matthieu@ > > Index: dri_sw_winsys.c > === > RCS file: /cvs/xenocara/lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c,v > retrieving revision 1.13 > diff -u -p -r1.13 dri_sw_winsys.c > --- dri_sw_winsys.c 2 Sep 2022 05:46:51 - 1.13 > +++ dri_sw_winsys.c 12 Apr 2023 09:25:42 - > @@ -144,7 +144,7 @@ dri_sw_displaytarget_create(struct sw_wi > > dri_sw_dt->shmid = -1; > > -#ifdef HAVE_SYS_SHM_H > +#if defined(HAVE_SYS_SHM_H) && !defined(__OpenBSD__) > if (ws->lf->put_image_shm) >dri_sw_dt->data = alloc_shm(dri_sw_dt, size); > #endif I would rather not touch xenocara like that. I would rather fixup firefox.
Re: [NEW] lang/gleam
FWIW I am giving a talk at BSDCan this year relating to plumbing OpenBSD specific system calls through to the BEAM. I personally don't lisp, but I'm really happy to see more BEAM languages become available, there are interesting use cases ( I think ). On Wed, Mar 15, 2023 at 4:17 PM Volker Schlecht wrote: > Thanks Omar! > > I'll put this and the remaining erlang.port.mk changes on the back > burner and resubmit after 7.3 > > On 3/15/23 15:09, Omar Polo wrote: > > On 2023/03/12 17:57:17 +0100, Volker Schlecht < > openbsd-po...@schlecht.dev> wrote: > >> One ping just in case - if nobody else is interested, I'll shut up about > >> that one. > > > > The port looks fine to me, plus all the tests are passing. Played a > > bit with it following the tour on the website; not exactly my thing > > but it's always nice to have more languages to play with in the port > > tree! :) > > > > nitpick: the README.md doesn't seem terrificantly informative so I'd > > drop it from the do-install. I'd drop the LICENSE too as I'd really > > like to avoid wasting bytes on the disk for it, but the point 4 of the > > Apache license states that "You may reproduce and distribute copies of > > the Work [...] with or without modifications, and in source or object > > form, provided that you meet the following conditions" and the very > > first one is to give other recipients of the work a copy of the > > license. shrug. > > > > Reattaching a tarball that don't install the README and indents the > > continuation lines in the post-patch target. It's ok op@ to import. > > > > Thanks! > > > > > >
Re: gtk+4 slow application startup
the chromium bits are in
Re: gtk+4 slow application startup
On 20/02/23 14:56 +0100, Landry Breuil wrote: > Le Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray a écrit : > > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote: > > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote: > > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > > > > Hi. > > > > > > > > > > There seems to be a regression with mesa that makes gtk+4 application > > > > > very slow > > > > > to start. > > > > > By default the GSK renderer uses OpenGL. > > > > > As a workaround, you can temporarily use this to go back to the cairo > > > > > renderer > > > > > which makes gtk+4 applications fast again: > > > > > > > > > > export GSK_RENDERER=cairo > > > > > > > > What hardware is this on? Is there a Mesa or gtk bug for it? > > > > > > See dmesg below. > > > > > > > When did this behaviour start? Before the gtk update that recently > > > > went in? Does it occur with GSK_RENDERER=vulkan? > > > > GSK_RENDERER described in > > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer > > > > > > It did not happen on my previous amd ryzen. > > > As soon as I switched to the new intel laptop, I was that bug (exact same > > > installation, I rsync'd everything). > > > > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is buggy > > > (not > > > built by default) and segfaults on a regular basis. > > > > > > > There is > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113 > > > > which briefly touches on shader cache. We disable the shader > > > > cache to be able to uses pledge(2). > > > > > > Yes, that is the bug I was looking into. > > > > Here is a xenocara diff to enable the shader cache. > > It is created in ~/.cache/mesa_shader_cache/ > > > > On an Intel system (x250 with Broadwell) launching gtk4-demo results in > > a 1.6M cache. The time to a window appearing is noticeably shorter > > running it again after that. > > > > The various firefox and chromium ports will need to change > > unveil/pledge policies to use it. Chromium at least still runs but > > there are multiple warnings that directories can't be created. This just needs an unveil of that directory in the gpu process and an flock pledge for chromium to use it. Seems okay to me. I think this should go in.
Re: ffmpeg x-only fix
works on i386 as well, so ok
On 24/01/23 14:36 +0100, Mark Kettenis wrote:
> This makes all the tests pass on an amd64 machine with PKU. The trick
> is to put the dispatch tables in .data.rel.ro. That means we can have
> relocations there but that the tables become read-only after the
> relocations have been processed. Since the table now contains the
> actual addresses of the functions the extra PIC code isn't needed
> anymore. Bumped REVISION to make sure folks get an updated version.
>
> According to robert@ it builds on i386, but the tests fail because the
> -Wl,-znotext isn't passed down to the tests for some reason. But that
> isn't a new problem as far as I can tell.
>
> Upstream probably cares about platforms without relro (which is fairly
> specific to ELF), so this is probably not upstreamable without some
> further abstractions/changes.
>
> ok?
>
>
> Index: graphics/ffmpeg/Makefile
> ===
> RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
> retrieving revision 1.230
> diff -u -p -r1.230 Makefile
> --- graphics/ffmpeg/Makefile 24 Jan 2023 12:08:40 - 1.230
> +++ graphics/ffmpeg/Makefile 24 Jan 2023 13:27:45 -
> @@ -2,7 +2,7 @@ COMMENT= audio/video converter and strea
>
> V= 4.4.3
> DISTNAME=ffmpeg-${V}
> -REVISION=2
> +REVISION=3
> EPOCH= 1
> CATEGORIES= graphics multimedia
> MASTER_SITES=https://ffmpeg.org/releases/
> Index: graphics/ffmpeg/patches/patch-libavcodec_x86_fft_asm
> ===
> RCS file: graphics/ffmpeg/patches/patch-libavcodec_x86_fft_asm
> diff -N graphics/ffmpeg/patches/patch-libavcodec_x86_fft_asm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ graphics/ffmpeg/patches/patch-libavcodec_x86_fft_asm 24 Jan 2023
> 13:27:45 -
> @@ -0,0 +1,37 @@
> +Index: libavcodec/x86/fft.asm
> +--- libavcodec/x86/fft.asm.orig
> libavcodec/x86/fft.asm
> +@@ -548,10 +548,6 @@ DEFINE_ARGS zc, w, n, o1, o3
> + %macro FFT_DISPATCH 2; clobbers 5 GPRs, 8 XMMs
> + lea r2, [dispatch_tab%1]
> + mov r2, [r2 + (%2q-2)*gprsize]
> +-%ifdef PIC
> +-lea r3, [$$]
> +-add r2, r3
> +-%endif
> + call r2
> + %endmacro ; FFT_DISPATCH
> +
> +@@ -731,11 +727,7 @@ DECL_PASS pass_interleave_3dnow, PASS_BIG 0
> + %define pass_interleave_3dnowext pass_interleave_3dnow
> + %endif
> +
> +-%ifdef PIC
> +-%define SECTION_REL - $$
> +-%else
> + %define SECTION_REL
> +-%endif
> +
> + %macro DECL_FFT 1-2 ; nbits, suffix
> + %ifidn %0, 1
> +@@ -773,8 +765,10 @@ fft %+ n %+ fullsuffix:
> + %endrep
> + %undef n
> +
> ++[SECTION .data.rel.ro write]
> + align 8
> + dispatch_tab %+ fullsuffix: pointer list_of_fft
> ++__?SECT?__
> + %endmacro ; DECL_FFT
> +
> + %if HAVE_AVX_EXTERNAL
--
Regards,
Robert Nagy
Re: [m8r update] x11/copyq
Maintainer, sorry :) Stuart Henderson ezt írta (időpont: 2023. jan. 24., K 13:46): > On 2023/01/24 10:37, Robert Bagdan wrote: > > I updated copyq, built without problem, works fine for me. > > Looks alright and nothing concerning in the changelog. > > What's "m8r"? > >
[m8r update] x11/copyq
I updated copyq, built without problem, works fine for me.
--
kikadf
Index: x11/copyq/Makefile
===
RCS file: /cvs/ports/x11/copyq/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- x11/copyq/Makefile 14 Oct 2022 13:39:34 - 1.1.1.1
+++ x11/copyq/Makefile 24 Jan 2023 09:32:13 -
@@ -1,7 +1,7 @@
COMMENT = Qt5 based clipboard manager
GH_ACCOUNT = hluk
GH_PROJECT = CopyQ
-GH_TAGNAME = v6.3.2
+GH_TAGNAME = v6.4.0
PKGNAME = ${DISTNAME:L}
CATEGORIES = x11
Index: x11/copyq/distinfo
===
RCS file: /cvs/ports/x11/copyq/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- x11/copyq/distinfo 14 Oct 2022 13:39:34 - 1.1.1.1
+++ x11/copyq/distinfo 24 Jan 2023 09:32:13 -
@@ -1,2 +1,2 @@
-SHA256 (CopyQ-6.3.2.tar.gz) = zhIu1/jj4jCxxtzOjx7G1xfu+MWYKTkMrhdQw1s0LEo=
-SIZE (CopyQ-6.3.2.tar.gz) = 3325217
+SHA256 (CopyQ-6.4.0.tar.gz) = rGdXoQ7S1inemsu2Rs27pc9RGX6d/jnT2y/zQGn8SDE=
+SIZE (CopyQ-6.4.0.tar.gz) = 3316278
[m8r update] x11/copyq
I updated copyq, built without problem, works fine for me.
--
kikadf
Index: x11/copyq/Makefile
===
RCS file: /cvs/ports/x11/copyq/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- x11/copyq/Makefile 14 Oct 2022 13:39:34 - 1.1.1.1
+++ x11/copyq/Makefile 24 Jan 2023 09:32:13 -
@@ -1,7 +1,7 @@
COMMENT = Qt5 based clipboard manager
GH_ACCOUNT = hluk
GH_PROJECT = CopyQ
-GH_TAGNAME = v6.3.2
+GH_TAGNAME = v6.4.0
PKGNAME = ${DISTNAME:L}
CATEGORIES = x11
Index: x11/copyq/distinfo
===
RCS file: /cvs/ports/x11/copyq/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- x11/copyq/distinfo 14 Oct 2022 13:39:34 - 1.1.1.1
+++ x11/copyq/distinfo 24 Jan 2023 09:32:13 -
@@ -1,2 +1,2 @@
-SHA256 (CopyQ-6.3.2.tar.gz) = zhIu1/jj4jCxxtzOjx7G1xfu+MWYKTkMrhdQw1s0LEo=
-SIZE (CopyQ-6.3.2.tar.gz) = 3325217
+SHA256 (CopyQ-6.4.0.tar.gz) = rGdXoQ7S1inemsu2Rs27pc9RGX6d/jnT2y/zQGn8SDE=
+SIZE (CopyQ-6.4.0.tar.gz) = 3316278
Re: UPDATE net/luasocket 3.0rc1p1 -> 3.1.0
On 14/01/23 14:39 -0700, Ashlen wrote: > On 23/01/07 00:20, Ashlen wrote: > > As for the renaming thing, I realized I didn't actually provide any links > > showing why I kept this in. I looked at the commits and it appears their > > rationale is that anyone that writes a Lua script and imports luasocket as > > well > > as another module that happens to have an identical buffer_* will have a > > headache due to name collisions. Though if that's the case, it makes me > > wonder > > why FreeBSD backed out the patch in the commit op@ mentioned. > > > > https://cvsweb.openbsd.org/ports/net/luasocket/patches/patch-src_buffer_c?rev=1.2&content-type=text/x-cvsweb-markup > > https://marc.info/?l=freebsd-ports-bugs&m=125089202109336&w=2 > > https://marc.info/?l=freebsd-ports&m=125097467421558&w=2 > > Hey Robert, I CC'ed you because I need to ask you something. You were > originally > the person who made patches renaming 'buffer_*' to 'ls_buffer_*' in > net/luasocket due to them creating a namespace clash with other ports. I know > this was all the way back in 2009, but can you let me know if changing those > is > still necessary? I'm guessing the answer is yes, but I wanted to double check > to > make sure since there was some discussion about it earlier. > > I meant to test it myself and therefore avoid bothering you, but it's been a > week and I'm realizing I'm not going to get to it in a timely manner (I don't > know how to write in Lua yet). > > (Side note for the other people in the thread: testing against those two other > ports is on my TODO list. Life has just been crazy lately and it's been a > struggle to get organized again... sorry for the delay on that) I haven't used this for a long time using that module, but it might not be the case anymore. It has to be tested I guess,
Re: chromium and clang 15
On 11/01/23 13:17 +0100, Jeremie Courreges-Anglas wrote: > On Wed, Jan 11 2023, Robert Nagy wrote: > > On 10/01/23 18:41 +0100, Jeremie Courreges-Anglas wrote: > >> On Sun, Jan 08 2023, Jeremie Courreges-Anglas wrote: > Hi, > > > No. Please keep the OpenBSD ifdef. > > This part is bugging me. #ifdef $OS is bad practice in my book, and > stdlib.h is the standard way to access malloc/calloc declarations > (malloc.h isn't). But hey, you're the maintainer, your call. ;) The chromium patches are shared between OpenBSD and FreeBSD where malloc.h is available. Yes including stdlib.h would most probably work there as well, but that can be cleaned up later.
Re: chromium and clang 15 (was: Re: amd64-clang bulk build report (llvm 15))
On 10/01/23 18:41 +0100, Jeremie Courreges-Anglas wrote: > On Sun, Jan 08 2023, Jeremie Courreges-Anglas wrote: > > [...] > > >> https://wxcvbn.org/~jca/build-failures/amd64-clang/2023-01-03/www/chromium.txt > > [patch] > > ../../third_party/libsync/src/sync.c:117:17: error: incompatible integer to > > pointer conversion assigning to 'struct sync_fence_info_data *' from 'int' > > [-Wint-conversion] > > legacy_info = malloc(4096); > > ^ > > > >> https://wxcvbn.org/~jca/build-failures/amd64-clang/2023-01-03/www/iridium.txt > > [patch] > > ../../third_party/libsync/src/sync.c:117:17: error: incompatible integer to > > pointer conversion assigning to 'struct sync_fence_info_data *' from 'int' > > [-Wint-conversion] > > legacy_info = malloc(4096); > > ^ > > https://wxcvbn.org/~jca/build-failures/amd64-clang/2023-01-03/www/ungoogled-chromium.txt > > [patch] > > ../../third_party/libsync/src/sync.c:117:17: error: incompatible integer to > > pointer conversion assigning to 'struct sync_fence_info_data *' from 'int' > > [-Wint-conversion] > > legacy_info = malloc(4096); > > ^ > > Diff for those below, they are sufficient for thise ports to package > successfully when built with clang 15. I'll add the REVISION bump at > commit time. ok? > > llvm 15 test material: > git branch: https://github.com/jcourreges/openbsd-src/tree/llvm15-6 > amd64 snaps: https://pbuild-amd64.wxcvbn.org/pub/OpenBSD/snapshots/amd64/ > > > Index: www/chromium/patches/patch-third_party_libsync_src_sync_c > === > RCS file: > /home/cvs/ports/www/chromium/patches/patch-third_party_libsync_src_sync_c,v > retrieving revision 1.2 > diff -u -p -r1.2 patch-third_party_libsync_src_sync_c > --- www/chromium/patches/patch-third_party_libsync_src_sync_c 2 Feb 2022 > 17:36:39 - 1.2 > +++ www/chromium/patches/patch-third_party_libsync_src_sync_c 27 Dec 2022 > 12:00:45 - > @@ -1,17 +1,16 @@ > Index: third_party/libsync/src/sync.c > --- third_party/libsync/src/sync.c.orig > +++ third_party/libsync/src/sync.c > -@@ -17,7 +17,9 @@ > +@@ -17,7 +17,7 @@ >*/ > > #include > -+#if !defined(__OpenBSD__) > - #include > -+#endif > +-#include > ++#include > #include > #include > #include > -@@ -29,6 +31,12 @@ > +@@ -29,6 +29,12 @@ > > #include > > Index: www/iridium/patches/patch-third_party_libsync_src_sync_c > === > RCS file: > /home/cvs/ports/www/iridium/patches/patch-third_party_libsync_src_sync_c,v > retrieving revision 1.5 > diff -u -p -r1.5 patch-third_party_libsync_src_sync_c > --- www/iridium/patches/patch-third_party_libsync_src_sync_c 28 Mar 2022 > 10:49:15 - 1.5 > +++ www/iridium/patches/patch-third_party_libsync_src_sync_c 27 Dec 2022 > 12:00:55 - > @@ -1,17 +1,16 @@ > Index: third_party/libsync/src/sync.c > --- third_party/libsync/src/sync.c.orig > +++ third_party/libsync/src/sync.c > -@@ -17,7 +17,9 @@ > +@@ -17,7 +17,7 @@ >*/ > > #include > -+#if !defined(__OpenBSD__) > - #include > -+#endif > +-#include > ++#include > #include > #include > #include > -@@ -29,6 +31,12 @@ > +@@ -29,6 +29,12 @@ > > #include > > Index: www/ungoogled-chromium/patches/patch-third_party_libsync_src_sync_c > === > RCS file: > /home/cvs/ports/www/ungoogled-chromium/patches/patch-third_party_libsync_src_sync_c,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 patch-third_party_libsync_src_sync_c > --- www/ungoogled-chromium/patches/patch-third_party_libsync_src_sync_c > 4 Oct 2022 12:56:00 - 1.1.1.1 > +++ www/ungoogled-chromium/patches/patch-third_party_libsync_src_sync_c > 30 Dec 2022 18:50:07 - > @@ -1,17 +1,16 @@ > Index: third_party/libsync/src/sync.c > --- third_party/libsync/src/sync.c.orig > +++ third_party/libsync/src/sync.c > -@@ -17,7 +17,9 @@ > +@@ -17,7 +17,7 @@ >*/ > > #include > -+#if !defined(__OpenBSD__) > - #include > -+#endif > +-#include > ++#include > #include > #include > #include > -@@ -29,6 +31,12 @@ > +@@ -29,6 +29,12 @@ > > #include > > Hi No. Please keep the OpenBSD ifdef. I am just doing an update of chromium so I will take care of these if you don't mind.
[NEW] net/megacmd
Hi! I've attached the port of net/megacmd, which provides non UI access to MEGA services. It intends to offer all the functionality with your MEGA account via commands. It features synchronization,backup of local folders into your MEGA account. I use on amd64 7.2, works fine for me. -- kikadf megacmd.tar.gz Description: application/gzip
Re: security update www/nginx to 1.22.1
On 15/11/22 14:56 +, Sergey A. Osokin wrote: > Hi, > > On Thu, Oct 27, 2022 at 01:58:01PM +, Sergey A. Osokin wrote: > > > > [...] > > Could you please provide an update. > Thank you. > > -- > Sergey A. Osokin Hi I've looked into your diff and there are a lot of issues that needs to be fixed, so please address these first: - this is not freebsd, there is no PORTREVISION, so why did you add it? - you do an update but you forgot to remove REVISION-main - rearringing variables in an alphabetical order is nice, but completely useless in this case and it also makes the diff harder to read - the distfile for the njs module is added, some variables are configured for it but then you don't actually enable the module, so it never get built (this module also has to be dynamic) - missing plist and descr for the new module Thanks -- Regards, Robert Nagy
Re: [NEW][E stuff 2/3] x11/enlightenment-wm
I added a patch to fix hibernate command: acpiconf -s4 to ZZZ. -- kikadf enlightenment-wm.tar.gz Description: application/gzip
Re: [NEW] audio/sayonara
I forgot to attaching... Robert Bagdan ezt írta (időpont: 2022. nov. 1., K, 12:18): > > Hi! > > I've attached the port of audio/sayonara, which is a small, clear and > fast audio player written in C++, supported by the Qt framework. It > uses GStreamer as audio backend. One of Sayonara's goals is intuitive > and easy usability. > > I built without problem, and patched to the correct man installing. I > use on amd64 7.2, works fine for me. > > -- > kikadf -- kikadf sayonara.tar.gz Description: application/gzip
[NEW] audio/sayonara
Hi! I've attached the port of audio/sayonara, which is a small, clear and fast audio player written in C++, supported by the Qt framework. It uses GStreamer as audio backend. One of Sayonara's goals is intuitive and easy usability. I built without problem, and patched to the correct man installing. I use on amd64 7.2, works fine for me. -- kikadf
Possible fixes in readme files of cups+sane-backend
I’ve an HP DeskJet 2630 multi-function printer, use that with usb cable. I installed sane-backend and cups to use the printer, for settings I read README files of these packages: chown _cups:_saned /dev/ugen0.* /dev/usb0 chmod 660 /dev/ugen0.* and added my user to the _saned group. However the scanning (sane-find-scanner) doesn’t work with my user, nor as _saned user, until I set the permissions to /dev/usb0 as well. Can you confirm this? Should the README files be updated from “chmod 660 /dev/ugen1.*” to “chmod 660 /dev/ugen1.* /dev/usb0” ? -- kikadf
Re: [NEW][E stuff 2/3] x11/enlightenment-wm
Thanks to your review, I removed the login file, fixed the README file, and added @conflict and @pkgpath markers to the PLIST. I've attached the new version. Stuart Henderson ezt írta (időpont: 2022. okt. 24., H, 16:17): > > On 2022/10/24 14:43, Robert Bagdan wrote: > > I've attached the port of x11/enlightenment-wm, which is the graphical > > desktop shell from the Enlightenment project. It resembles a > > traditional UNIX/X1 style desktop by design but has a range of > > add-ons, as well as a different core design philosophy. Enlightenment > > manages windows and files. It's a compositor and is also capable of > > launching applications, handling the user interface and even system > > settings. > > > > This is the part of 2 to the Enlightenment wm stuff, which is based on > > the latest releases, not on the DR16 based version, which is already > > in the ports tree. I checked the PLISTs, the DR16 and this version are > > not conflicting. > > > > I use and test them (EFl, Enlightenment, Terminology) since 2 month on > > OpenBSD 7.1 and after 7.2, works fine for me. > > > > Some notes: > > 1) I am not sure the name of this port, as enlightenment already > > exists in the tree, but that is the DR16 version. > > > > 2) I added the enlightenment login class to the ports, as need to > > increase the resource limits to run enlightenment. Enlightenment’s > > efreetd caching all installed icons, when can be knocked out by the > > resource limits. > > > > 2.a) portcheck tell me: > > extra file: pkg/enlightenment.login > > > > I found login files for other ports, but isn’t this the correct way to > > offer the resource limits increase? Should I only write this to the > > README file? > > These pkg/XX.login files are only useful for ports with daemons which > run from the rc.d framework, the pkg-readme is probably the best place > for it (NB spelling: should be "successful") > > > 3) The port has patches to fix locale changing, only removing old > > OpenBSD relevant ifdefs, which already just broke the locale switch. I > > sent the patches to the upstream, not accepted yet. > > > > Any suggestions for the port? > > > > -- > > kikadf > > -- kikadf enlightenment-wm-v2.tar.gz Description: application/gzip
Re: [NEW][E stuff 1/3] x11/efl
Stuart Henderson ezt írta (időpont: 2022. okt.
24., H, 16:23):
>
> On 2022/10/24 15:12, Stuart Henderson wrote:
> > On 2022/10/24 14:42, Robert Bagdan wrote:
> > > 2) I add the files/libversion-fix.sh script to the ports, and call
> > > that the post-extract time. Not so beautiful, but I can’t found better
> > > way to fix EFL’s src/lib/ecore_audio/ecore_audio.c and
> > > src/lib/ecore_con/ecore_con_url_curl.c LOAD("libpulse.so.0") -like
> > > runtime library loading way. The libversion-fix.sh script replaces the
> > > soversions to the OpenBSD's soversions.
> >
> > Don't do this - use e.g. "libpulse.so" and let dlopen find the version
> > instead.
> >
I removed the files/libversion-fix.sh script, and patched as you
mentioned, LOAD("libpulse.so") -like. I use the new version of EFL, I
don't find any issue, log files are clear as well. Thank you.
> > > 4.b) Python module without compiled version, consider using
> > > ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py: share/eo/gdb/eo_gdb.py
> > >
> > > I don’t know how to fix this. My /usr/local/share/eo/gdb/eo_gdb.py
> > > file starts with this lines (1-6):
> >
> > I would ignore that
> >
> > > 4.c) the following libraries in WANTLIB look like masked by
> > > RUN_DEPENDS: rsvg-2 scim-1.0
> > >
> > > I didn’t find how to fix, or maybe false positive results?
> >
> > I think you need to add x11/gnome/librsvg to LIB_DEPENDS and
> > remove inputmethods/scim from RUN_DEPENDS and BUILD_DEPENDS and
> > add it to LIB_DEPENDS.
> >
Done, and works, no more this report.
> > > 5) I found in PLIST, that efl install:
> > > share/gdb/auto-load/usr/lib/libeo.so.1.26.3-gdb.py
> > >
> > > Should I fix it to use the “share/gdb/auto-load/usr/local/lib/” path
> > > as other ports?
> >
> > Yes.
OK, fixed with patching the relevant meson.build file to use the correct path.
> >
> > > Any suggestions for the port?
> >
> > I haven't tried building but otherwise looks alright from a read-through,
> > could maybe do with someone who is familiar with meson in OpenBSD ports
> > to take a look at the meson.build patches
> >
>
> Oh, also: enlightenment E17 ports were previously in x11/e17 and
> removed fairly recently, there may be some @conflict/@pkgpath markers
> needed to cope with cases where users still have those lying around.
>
> https://github.com/openbsd/ports/commit/cb698c3bc1783e2d170f6ff8e5e294040c987e78
>
I added the markers to the PLIST, I hope I use them well. I've
attached the new version.
--
kikadf
efl-v2.tar.gz
Description: application/gzip
[NEW][E stuff 3/3] x11/terminology
I've attached the port of x11/terminology, an EFL based terminal emulator bristling with advanced features. This is the part of 3 to the Enlightenment wm stuff, which is based on the latest releases, not on the DR16 based version, which is already in the ports tree. I use and test them (EFl, Enlightenment, Terminology) since 2 month on OpenBSD 7.1 and after 7.2, works fine for me. Any suggestions for the port? -- kikadf terminology.tar.gz Description: application/gzip
[NEW][E stuff 2/3] x11/enlightenment-wm
I've attached the port of x11/enlightenment-wm, which is the graphical desktop shell from the Enlightenment project. It resembles a traditional UNIX/X1 style desktop by design but has a range of add-ons, as well as a different core design philosophy. Enlightenment manages windows and files. It's a compositor and is also capable of launching applications, handling the user interface and even system settings. This is the part of 2 to the Enlightenment wm stuff, which is based on the latest releases, not on the DR16 based version, which is already in the ports tree. I checked the PLISTs, the DR16 and this version are not conflicting. I use and test them (EFl, Enlightenment, Terminology) since 2 month on OpenBSD 7.1 and after 7.2, works fine for me. Some notes: 1) I am not sure the name of this port, as enlightenment already exists in the tree, but that is the DR16 version. 2) I added the enlightenment login class to the ports, as need to increase the resource limits to run enlightenment. Enlightenment’s efreetd caching all installed icons, when can be knocked out by the resource limits. 2.a) portcheck tell me: extra file: pkg/enlightenment.login I found login files for other ports, but isn’t this the correct way to offer the resource limits increase? Should I only write this to the README file? 3) The port has patches to fix locale changing, only removing old OpenBSD relevant ifdefs, which already just broke the locale switch. I sent the patches to the upstream, not accepted yet. Any suggestions for the port? -- kikadf enlightenment-wm.tar.gz Description: application/gzip
[NEW][E stuff 1/3] x11/efl
Hi!
I've attached the port of x11/efl, the Enlightenment Foundation
Libraries, which is a collection of libraries for handling many common
tasks a developer may have such as data structures, communication,
rendering, widgets and more.
This is the part of 1 to the Enlightenment wm stuff, which is based on
the latest releases, not on the DR16 based version, which is already
in the ports tree.
I use and test them (EFl, Enlightenment, Terminology) since 2 month on
OpenBSD 7.1 and after 7.2, works fine for me.
Some notes:
1) The Makefile contains the LibreSSl 3.5.x relevant patches from the
EFL master branch. These are not backported to the 1.26.0 branch, so
will be available only with the 1.27.x EFL release. The patches
affected more files, so I think it is easier to handle than on the
patches directory of the port.
2) I add the files/libversion-fix.sh script to the ports, and call
that the post-extract time. Not so beautiful, but I can’t found better
way to fix EFL’s src/lib/ecore_audio/ecore_audio.c and
src/lib/ecore_con/ecore_con_url_curl.c LOAD("libpulse.so.0") -like
runtime library loading way. The libversion-fix.sh script replaces the
soversions to the OpenBSD's soversions.
3) I add 2 other patches in the patch directory, which just fix the
build error (simple renaming) because of the added
${LIBelementary_VERSION} and ${LIBemotion_VERSION} these module
libraries.
4) portcheck tell me:
4.a) installs icon README in share/icons/Enlightenment-X, it should go
in share/Enlightenment-X/icons/ or like instead
I think not need to change the path, as Enlightenment-X is an icon theme.
4.b) Python module without compiled version, consider using
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py: share/eo/gdb/eo_gdb.py
I don’t know how to fix this. My /usr/local/share/eo/gdb/eo_gdb.py
file starts with this lines (1-6):
—--
import gdb
"""
All of this script relies heavily on Eo internals and will break if they
change. Need to make sure this is always in sync.
"""
—--
4.c) the following libraries in WANTLIB look like masked by
RUN_DEPENDS: rsvg-2 scim-1.0
I didn’t find how to fix, or maybe false positive results?
5) I found in PLIST, that efl install:
share/gdb/auto-load/usr/lib/libeo.so.1.26.3-gdb.py
Should I fix it to use the “share/gdb/auto-load/usr/local/lib/” path
as other ports?
Any suggestions for the port?
--
kikadf
efl.tar.gz
Description: application/gzip
Re: security update www/nginx to 1.22.1
On 19/10/22 18:23 +0100, Stuart Henderson wrote: > On 2022/10/19 16:30, Sergey A. Osokin wrote: > > Hi, > > > > could you please review the following changes for the security > > update www/nginx to the recent stable version, 1.22.1. > > adding maintainer to CC, it's usually helpful .. that release and cve only affects the ngx_http_mp4_module which we do not enable
Re: www/ungoogled-chromium
On 09/10/22 16:34 -0700, Heppler, J. Scott wrote: > On current, ungoogled-chromium errors out - unable to access > /dev/drm/card0. I replaced with www/iridium and it ran fine. > I suspect pledge/unveil was not fully implemented in ungoogled-chromium. > > A second issue is that it likely cannot be installed with www/chromium > as both use ~/.config/chromium. This has been fixed in -current.
WYRD in the openbsd ports tree
Hello. It looks like you were the ports maintainer for the package "wyrd" which is a curses based front end to the remind programming language, written in ocaml: https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/productivity/wyrd/ I think maybe wyrd was dropped because it was not maintained because the package was not maintained or updated in years (I think maybe the writer is retired). However, the package is not dead: https://dianne.skoll.ca/pipermail/remind-fans/2022/003955.html The person who now maintains is uses linux and has pushed out packages for Debian and OpenSUSE, but declined my request to support it on OpenBSD. I've tried to build it from source, but I don't seem to understand enough ocaml to do so. How do I request that it go back into the ports tree, and more importantly that the binany is again included in my OpenBSD install? Thanks very much, Robert
unbrak cmake in case of OBJECT library type
Hi
Our cmake has some hacks and due to that we cannot build binaries that
link to libraries with an OBJECT type because that means that all the object
files are pulled instead of linking to a static library. e.g.:
Source/WTF/wtf/CMakeFiles/WTF.dir/./ApproximateTime.cpp.o
But our cmake code modifies that to be -lApproximateTime.cpp.o which will
fail obviously.
The following hack on top of our hack fixes the issue. aja@ is running a bulk
wit this already:
Index: Makefile
===
RCS file: /cvs/ports/devel/cmake/Makefile,v
retrieving revision 1.206
diff -u -p -u -r1.206 Makefile
--- Makefile18 Mar 2022 21:05:31 - 1.206
+++ Makefile23 Mar 2022 16:07:03 -
@@ -6,7 +6,7 @@ VER = 3.20.3
EPOCH =0
DISTNAME = cmake-${VER}
CATEGORIES = devel
-REVISION = 5
+REVISION = 6
HOMEPAGE = https://www.cmake.org/
Index: patches/patch-Source_cmComputeLinkInformation_cxx
===
RCS file:
/cvs/ports/devel/cmake/patches/patch-Source_cmComputeLinkInformation_cxx,v
retrieving revision 1.29
diff -u -p -u -r1.29 patch-Source_cmComputeLinkInformation_cxx
--- patches/patch-Source_cmComputeLinkInformation_cxx 11 Mar 2022 18:49:50
- 1.29
+++ patches/patch-Source_cmComputeLinkInformation_cxx 23 Mar 2022 16:07:03
-
@@ -12,7 +12,7 @@ Index: Source/cmComputeLinkInformation.c
this->OrderRuntimeSearchPath->SetImplicitDirectories(this->ImplicitLinkDirs);
if (this->OrderDependentRPath) {
this->OrderDependentRPath->SetImplicitDirectories(this->ImplicitLinkDirs);
-@@ -713,10 +714,16 @@ void cmComputeLinkInformation::AddItem(BT
+@@ -713,10 +714,20 @@ void cmComputeLinkInformation::AddItem(BT
// This is a directory.
this->DropDirectoryItem(item.Value);
} else {
@@ -25,14 +25,18 @@ Index: Source/cmComputeLinkInformation.c
+ this->AddFullItem(item);
+ this->AddLibraryRuntimeInfo(item.Value);
+} else {
-+ std::string file = cmSystemTools::GetFilenameName(item.Value);
-+ this->AddUserItem(file, false);
++ if (cmHasLiteralSuffix(item.Value, ".o"))
++this->AddFullItem(item);
++ else {
++std::string file = cmSystemTools::GetFilenameName(item.Value);
++this->AddUserItem(file, false);
++}
+ this->OrderLinkerSearchPath->AddLinkLibrary(item.Value);
+}
}
} else {
// This is a library or option specified by the user.
-@@ -1049,11 +1056,18 @@ void cmComputeLinkInformation::AddTargetItem(BTSharedLibrariesLinked.insert(target);
}
@@ -55,7 +59,7 @@ Index: Source/cmComputeLinkInformation.c
}
// For compatibility with CMake 2.4 include the item's directory in
-@@ -1066,6 +1080,27 @@ void cmComputeLinkInformation::AddTargetItem(BTItems.emplace_back(item, true, target);
Re: sparc64 bulk build report (net/zabbix: fix intptr detection on sparc/sparc64)
a/postgresql/Makefile.in
> +share/zabbix-proxy/schema/postgresql/data.sql
> +share/zabbix-proxy/schema/postgresql/double.sql
> +share/zabbix-proxy/schema/postgresql/images.sql
> +share/zabbix-proxy/schema/postgresql/schema.sql
> +share/zabbix-proxy/schema/postgresql/timescaledb.sql
> +share/zabbix-server/
> Index: pkg/PLIST-proxy
> ===
> RCS file: /home/cvs/ports/net/zabbix/pkg/PLIST-proxy,v
> retrieving revision 1.7
> diff -u -p -r1.7 PLIST-proxy
> --- pkg/PLIST-proxy 27 Jul 2020 14:32:03 - 1.7
> +++ pkg/PLIST-proxy 19 Feb 2022 20:24:50 -
> @@ -1,9 +1,10 @@
> @comment $OpenBSD: PLIST-proxy,v 1.7 2020/07/27 14:32:03 jasper Exp $
> @pkgpath net/zabbix,-proxy
> @extraunexec rm -rf /var/log/zabbix/*
> +@rcscript ${RCDIR}/zabbix_proxy
> +@sample ${SYSCONFDIR}/zabbix/
> @man man/man8/zabbix_proxy.8
> @bin sbin/zabbix_proxy
> -@sample ${SYSCONFDIR}/zabbix/
> share/examples/zabbix/zabbix_proxy.conf
> @mode 640
> @group _zabbix
> @@ -13,6 +14,24 @@ share/examples/zabbix/zabbix_proxy.conf
> share/zabbix-proxy/
> share/zabbix-proxy/schema/
> share/zabbix-proxy/schema/mysql/
> +share/zabbix-proxy/schema/sqlite3/
> +@comment share/zabbix-proxy/schema/sqlite3/Makefile
> +@comment share/zabbix-proxy/schema/sqlite3/Makefile.am
> +@comment share/zabbix-proxy/schema/sqlite3/Makefile.in
> +share/zabbix-proxy/schema/sqlite3/data.sql
> +share/zabbix-proxy/schema/sqlite3/images.sql
> +share/zabbix-proxy/schema/sqlite3/schema.sql
> +@mode 750
> +@owner _zabbix
> +@group _zabbix
> +@sample /var/db/zabbix/
> +@mode 0755
> +@group
> +@sample /var/log/zabbix/
> +@mode
> +@owner
> +share/zabbix-server/schema/
> +share/zabbix-server/schema/mysql/
> @comment share/zabbix-server/schema/mysql/Makefile
> @comment share/zabbix-server/schema/mysql/Makefile.am
> @comment share/zabbix-server/schema/mysql/Makefile.in
> @@ -29,21 +48,3 @@ share/zabbix-server/schema/postgresql/do
> share/zabbix-server/schema/postgresql/images.sql
> share/zabbix-server/schema/postgresql/schema.sql
> share/zabbix-server/schema/postgresql/timescaledb.sql
> -share/zabbix-proxy/schema/sqlite3/
> -@comment share/zabbix-proxy/schema/sqlite3/Makefile
> -@comment share/zabbix-proxy/schema/sqlite3/Makefile.am
> -@comment share/zabbix-proxy/schema/sqlite3/Makefile.in
> -share/zabbix-proxy/schema/sqlite3/data.sql
> -share/zabbix-proxy/schema/sqlite3/images.sql
> -share/zabbix-proxy/schema/sqlite3/schema.sql
> -@mode 750
> -@owner _zabbix
> -@group _zabbix
> -@sample /var/db/zabbix/
> -@mode
> -@group
> -@mode 0755
> -@sample /var/log/zabbix/
> -@owner
> -@mode
> -@rcscript ${RCDIR}/zabbix_proxy
> Index: pkg/PLIST-web
> ===
> RCS file: /home/cvs/ports/net/zabbix/pkg/PLIST-web,v
> retrieving revision 1.43
> diff -u -p -r1.43 PLIST-web
> --- pkg/PLIST-web 13 Sep 2021 08:51:22 - 1.43
> +++ pkg/PLIST-web 19 Feb 2022 20:24:50 -
> @@ -1361,9 +1361,8 @@ zabbix/vendor/xmlseclibs/src/XMLSecurity
> zabbix/vendor/xmlseclibs/src/XMLSecurityKey.php
> zabbix/vendor/xmlseclibs/xmlseclibs.php
> zabbix/zabbix.php
> +@cwd ${LOCALBASE}/share/doc/pkg-readmes
> +${PKGSTEM}
> @cwd ${LOCALBASE}
> -share/examples/php-${MODPHP_VERSION}/
> share/examples/php-${MODPHP_VERSION}/zabbix.ini
> @sample ${SYSCONFDIR}/php-${MODPHP_VERSION}.sample/zabbix.ini
> -@cwd ${LOCALBASE}/share/doc/pkg-readmes
> -${PKGSTEM}
--
Regards,
Robert Nagy
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 21/01/22 11:42 -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > > > We have chronically fewer people who can give okays than ports waiting. > > > > One big "meta" stuff that needs doing is pointing out (especially from > > new guys) what can be improved in the documentation of the porting > > process... > > sometimes pointing people in the right direction. > > > > Informal poll: what thing weirded you guys out the first time you touched > > OpenBSD ports coming from other platforms. > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). > > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. > Big NO. We use CVS, deal with it. If you want to help people who are lazy to cvs diff and send an email, write a script that that does a submission for them automatically in a format we prefer. If you want to use git, fine, you can send git diffs to the mailing list. If someone does not have enough brain to figure out how to do things our way then we probably do not want that submission either. On the other hand, I think the issue here is not the version control system or the development method we are using, but the lack of interest or need. The openbsd ports and packages are quiet good compared to others and things just work. There is always room for imrovement of course.
Re: [PATCH] update www/nginx to 1.20.2
commited, thanks On 16/11/21 18:23 +, Sergey A. Osokin wrote: > Hi Robert, > > good point! Updated and attached, thanks! > > On Tue, Nov 16, 2021 at 07:07:19PM +0100, Robert Nagy wrote: > > you are missing the REVISION changes / removals from the Makefile > > > > On 16/11/21 17:38 +, Sergey A. Osokin wrote: > > > and here's the commit log. > > > > > > On Tue, Nov 16, 2021 at 05:35:33PM +, Sergey A. Osokin wrote: > > > > Hello, > > > > > > > > hope you're doing well. > > > > Here's the patch to update www/nginx to its recent stable version. > > > > Thanks. > > -- > Sergey Osokin -- Regards, Robert Nagy
Re: [PATCH] update www/nginx to 1.20.2
you are missing the REVISION changes / removals from the Makefile
On 16/11/21 17:38 +, Sergey A. Osokin wrote:
> and here's the commit log.
>
> On Tue, Nov 16, 2021 at 05:35:33PM +, Sergey A. Osokin wrote:
> > Hello,
> >
> > hope you're doing well.
> > Here's the patch to update www/nginx to its recent stable version.
> > Thanks.
> >
> > --
> > Sergey Osokin
>
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/www/nginx/Makefile,v
> > retrieving revision 1.156
> > diff -u -p -r1.156 Makefile
> > --- Makefile10 Sep 2021 15:19:00 - 1.156
> > +++ Makefile16 Nov 2021 17:33:58 -
> > @@ -17,7 +17,7 @@ COMMENT-passenger=nginx passenger (ruby
> > COMMENT-rtmp= nginx module for RTMP streaming
> > COMMENT-securelink=nginx HMAC secure link module
> >
> > -VERSION= 1.20.1
> > +VERSION= 1.20.2
> > DISTNAME= nginx-${VERSION}
> > CATEGORIES=www
> >
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/www/nginx/distinfo,v
> > retrieving revision 1.77
> > diff -u -p -r1.77 distinfo
> > --- distinfo25 May 2021 19:43:55 - 1.77
> > +++ distinfo16 Nov 2021 17:33:58 -
> > @@ -2,7 +2,7 @@ SHA256 (headers-more-nginx-module-v0.33.
> > SHA256 (lua-nginx-module-v0.10.11.tar.gz) =
> > wPuR/P0cbn3sNMpkgm74H/66/e9hdNJURnY284BWZiY=
> > SHA256 (naxsi-1.3.tar.gz) = Q5yGdzctJZe0Ngu8wQvIZJDeH8dWlbGTrV3xVKIU1ig=
> > SHA256 (nginx-1.20.1-chroot.patch) =
> > SS1TB0j8N4/dn5pUTGT6WvkN3aAUuKz5+R0Nt+MG0gk=
> > -SHA256 (nginx-1.20.1.tar.gz) = 5GLhFTPVwwuqBd92UhYP9ZeVkdKRc2z6Xtuf0u20jEk=
> > +SHA256 (nginx-1.20.2.tar.gz) = lYh2dXeCGQoWU+FNwm38e6Jj3jEOBMET4R6X0b70WkI=
> > SHA256 (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) =
> > aQxOW9sq4ZsP7nXNNW0YATRo20cmFrYJeloLvjRshGQ=
> > SHA256 (nginx-rtmp-module-v1.2.1.tar.gz) =
> > h6pZdACwtaBSdO4tI9jLgiThJoYiegq+MdeDs6ZF6jc=
> > SHA256 (ngx_devel_kit-v0.3.0.tar.gz) =
> > iOBamainQZBm9a51lm+x78QJutRSLRSYbaB0VUrmFhk=
> > @@ -12,7 +12,7 @@ SIZE (headers-more-nginx-module-v0.33.ta
> > SIZE (lua-nginx-module-v0.10.11.tar.gz) = 616653
> > SIZE (naxsi-1.3.tar.gz) = 235626
> > SIZE (nginx-1.20.1-chroot.patch) = 8783
> > -SIZE (nginx-1.20.1.tar.gz) = 1061461
> > +SIZE (nginx-1.20.2.tar.gz) = 1062124
> > SIZE (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) =
> > 18542
> > SIZE (nginx-rtmp-module-v1.2.1.tar.gz) = 519919
> > SIZE (ngx_devel_kit-v0.3.0.tar.gz) = 66455
>
>
>
> www/nginx: update to 1.20.2.
>
>
>
> *) Feature: OpenSSL 3.0 compatibility.
>
> *) Bugfix: SSL variables might be empty when used in logs; the bug had
>appeared in 1.19.5.
>
> *) Bugfix: keepalive connections with gRPC backends might not be closed
>after receiving a GOAWAY frame.
>
> *) Bugfix: backend SSL connections in the stream module might hang after
>an SSL handshake.
>
> *) Bugfix: SSL connections with gRPC backends might hang if select,
>poll, or /dev/poll methods were used.
>
> *) Bugfix: in the $content_length variable when using chunked transfer
>encoding.
>
> *) Bugfix: requests might hang when using HTTP/2 and the "aio_write"
>directive.
>
>
--
Regards,
Robert Nagy
Re: x11/gtk+2 python tweak
I have the same uncommited change in my tree, so go ahead please.
> On 2021. Nov 6., at 17:21, Rafael Sadowski wrote:
>
> On Sat Nov 06, 2021 at 04:10:48PM +, Klemens Nanni wrote:
>>> On Sat, Nov 06, 2021 at 05:01:32PM +0100, Antoine Jacoutot wrote:
>>> On Sat, Nov 06, 2021 at 04:51:54PM +0100, Rafael Sadowski wrote:
Without this tweak, the build fails for me. gtk+-2 expects python3
executable. I also have this problem with gtk+-3 and I think the
problem also exists in 4.
>>>
>>>
>>> That looks wrong.
>>> Looks like you have a broken system missing python3.
>>
>> Yes, python3 is provided by the default python package, python%3.9
>> at the moment.
>>
>> Ports symlink `pyhthon' to MODPY_BIN which is legit, i.e. they're
>> catching the unversioned interpreter with this.
>>
>> Our chrome browsers are the only two exceptions to this, so they should
>> probably be fixed as well.
>>
>> OK?
>>
>
> That makes sense now!
>
>>
>>
>> Index: www/iridium/Makefile
>> ===
>> RCS file: /cvs/ports/www/iridium/Makefile,v
>> retrieving revision 1.120
>> diff -u -p -r1.120 Makefile
>> --- www/iridium/Makefile2 Nov 2021 09:06:54 -1.120
>> +++ www/iridium/Makefile6 Nov 2021 16:08:58 -
>> @@ -194,7 +194,6 @@ GN_ARGS+=is_component_build=false
>>
>> pre-configure:
>>@ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python
>> -@ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python3
>> .for _arch in x64 ia32 arm64
>> . for _dir in avcodec avformat avutil
>>@cp -pR
>> ${WRKSRC}/third_party/ffmpeg/chromium/config/Chrome/linux/${_arch}/lib${_dir}
>> \
>> Index: www/chromium/Makefile
>> ===
>> RCS file: /cvs/ports/www/chromium/Makefile,v
>> retrieving revision 1.593
>> diff -u -p -r1.593 Makefile
>> --- www/chromium/Makefile30 Oct 2021 17:49:27 -1.593
>> +++ www/chromium/Makefile6 Nov 2021 16:09:08 -
>> @@ -192,7 +192,6 @@ GN_ARGS+=is_component_build=false
>>
>> pre-configure:
>>@ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python
>> -@ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python3
>> .for _arch in x64 ia32 arm64
>> . for _dir in avcodec avformat avutil
>>@cp -pR
>> ${WRKSRC}/third_party/ffmpeg/chromium/config/Chrome/linux/${_arch}/lib${_dir}
>> \
>>
Re: After latest update, neither Salt Master nor Minion start
Hi
Fixed in current.
On 20/09/21 23:16 +0100, Raf Czlonka wrote:
> Hello,
>
> I've emailed Robert (Salt port maintainer) directly, but I guess I
> should have sent it here with him CC'd, especially when the lock
> is nigh.
>
> Anyhow, as it stands, Salt - neither master nor minion - is currently
> usable.
>
> Regards,
>
> Raf
>
> On Fri, Sep 17, 2021 at 11:20:27PM BST, Raf Czlonka wrote:
> > Hi Robert,
> >
> > You might have noticed it by now but in case you hadn't, after the
> > latest Salt update, neither Master nor Minion start.
> >
> > Attempting to start either with debug logging, doesn't show anything.
> >
> > This is what I get attempting to start the master by hand:
> >
> > Traceback (most recent call last):
> > File "/usr/local/bin/salt-master", line 33, in
> > sys.exit(load_entry_point('salt==3003.3', 'console_scripts',
> > 'salt-master')())
> > File "/usr/local/lib/python3.8/site-packages/salt/scripts.py", line
> > 95, in salt_master
> > import salt.cli.daemons
> > File "/usr/local/lib/python3.8/site-packages/salt/cli/daemons.py",
> > line 17, in
> > from salt.utils import migrations
> > File
> > "/usr/local/lib/python3.8/site-packages/salt/utils/migrations.py", line 12,
> > in
> > import salt.syspaths as syspaths
> > File "/usr/local/lib/python3.8/site-packages/salt/syspaths.py", line
> > 21, in
> > import salt.utils.platform
> > File "/usr/local/lib/python3.8/site-packages/salt/utils/platform.py",
> > line 10, in
> > from salt.utils.decorators import memoize as real_memoize
> > File
> > "/usr/local/lib/python3.8/site-packages/salt/utils/decorators/__init__.py",
> > line 19, in
> > import salt.utils.args
> > File "/usr/local/lib/python3.8/site-packages/salt/utils/args.py",
> > line 15, in
> > import salt.utils.versions
> > File "/usr/local/lib/python3.8/site-packages/salt/utils/versions.py",
> > line 30, in
> > import salt.version
> > File "/usr/local/lib/python3.8/site-packages/salt/version.py", line
> > 9, in
> > import salt.utils.entrypoints
> > File
> > "/usr/local/lib/python3.8/site-packages/salt/utils/entrypoints.py", line
> > 36, in
> > import pkg_resources
> > File
> > "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line
> > 3243, in
> > def _initialize_master_working_set():
> > File
> > "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line
> > 3226, in _call_aside
> > f(*args, **kwargs)
> > File
> > "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line
> > 3255, in _initialize_master_working_set
> > working_set = WorkingSet._build_master()
> > File
> > "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line
> > 568, in _build_master
> > ws.require(__requires__)
> > File
> > "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line
> > 886, in require
> > needed = self.resolve(parse_requirements(requirements))
> > File
> > "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line
> > 772, in resolve
> > raise DistributionNotFound(req, requirers)
> > pkg_resources.DistributionNotFound: The 'contextvars' distribution was
> > not found and is required by salt
> >
> > and minion:
> >
> > Traceback (most recent call last):
> > File "/usr/local/bin/salt-minion", line 33, in
> > sys.exit(load_entry_point('salt==3003.3', 'console_scripts',
> > 'salt-minion')())
> > File "/usr/local/lib/python3.8/site-packages/salt/scripts.py", line
> > 178, in salt_minion
> > import salt.utils.platform
> > File "/usr/local/lib/python3.8/site-packages/salt/utils/platform.py",
> > line 10, in
> > from salt.utils.decorators import memoize as real_memoize
> > File
> > "/usr/local/lib/python3.8/site-packages/salt/utils/decorators/__init__.py",
> > line 19, in
> > import salt.utils.args
&
Re: x11/mate/caja crashes often at startup when not run from mate
4201.6 > #6 0x00079e766f01 in _rthread_start (v= Unhandled dwarf expression opcode 0xa3>) at > /usr/src/lib/librthread/rthread.c:96 > #7 0x0007ddaf95fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > (gdb) thread 5 > [Switching to thread 5 (thread 576065)] > #0 stat () at /tmp/-:3 > 3 /tmp/-: No such file or directory. > (gdb) bt > #0 stat () at /tmp/-:3 > #1 0x000821c8dbcd in g_file_test () from > /usr/local/lib/libglib-2.0.so.4201.6 > #2 0x0007e6a8c1e1 in get_thumbnail_attributes () from > /usr/local/lib/libgio-2.0.so.4200.13 > #3 0x0007e6a8b908 in _g_local_file_info_get () from > /usr/local/lib/libgio-2.0.so.4200.13 > #4 0x0007e6a878a6 in g_local_file_query_info () from > /usr/local/lib/libgio-2.0.so.4200.13 > #5 0x0007e6995466 in query_info_async_thread () from > /usr/local/lib/libgio-2.0.so.4200.13 > #6 0x0007e69eff2e in g_task_thread_pool_thread () from > /usr/local/lib/libgio-2.0.so.4200.13 > #7 0x000821cd8939 in g_thread_pool_thread_proxy () from > /usr/local/lib/libglib-2.0.so.4201.6 > #8 0x000821cd7425 in g_thread_proxy () from > /usr/local/lib/libglib-2.0.so.4201.6 > #9 0x00079e766f01 in _rthread_start (v= Unhandled dwarf expression opcode 0xa3>) at > /usr/src/lib/librthread/rthread.c:96 > #10 0x0007ddaf95fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > (gdb) thread 6 > [Switching to thread 6 (thread 233739)] > #0 _thread_sys_poll () at /tmp/-:3 > 3 /tmp/-: No such file or directory. > (gdb) bt > #0 _thread_sys_poll () at /tmp/-:3 > #1 0x0007ddb0237e in _libc_poll_cancel (fds=0x85da8a4c0, nfds=1, > timeout=-1) at /usr/src/lib/libc/sys/w_poll.c:27 > #2 0x000821ca6d32 in g_main_context_iterate () from > /usr/local/lib/libglib-2.0.so.4201.6 > #3 0x000821ca6e65 in g_main_context_iteration () from > /usr/local/lib/libglib-2.0.so.4201.6 > #4 0x00082362e9dd in dconf_gdbus_worker_thread () from > /usr/local/lib/gio/modules/libdconfsettings.so > #5 0x000821cd7425 in g_thread_proxy () from > /usr/local/lib/libglib-2.0.so.4201.6 > #6 0x00079e766f01 in _rthread_start (v= Unhandled dwarf expression opcode 0xa3>) at > /usr/src/lib/librthread/rthread.c:96 > #7 0x0007ddaf95fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > (gdb) thread 7 > [Switching to thread 7 (thread 177670)] > #0 futex () at /tmp/-:3 > 3 /tmp/-: No such file or directory. > (gdb) bt > #0 futex () at /tmp/-:3 > #1 0x0007ddad6d45 in _twait (p=0x8727626d0, val=1, clockid=3, > abs=0x7e6c7e820) at /usr/src/lib/libc/thread/synch.h:36 > #2 _rthread_cond_timedwait (cond=0x8727626d0, mutexp=0x87370dd50, > abs=0x7e6c7e820) at /usr/src/lib/libc/thread/rthread_cond.c:106 > #3 0x000821d06560 in g_cond_wait_until () from > /usr/local/lib/libglib-2.0.so.4201.6 > #4 0x000821c6b6e6 in g_async_queue_pop_intern_unlocked () from > /usr/local/lib/libglib-2.0.so.4201.6 > #5 0x000821cd890a in g_thread_pool_thread_proxy () from > /usr/local/lib/libglib-2.0.so.4201.6 > #6 0x000821cd7425 in g_thread_proxy () from > /usr/local/lib/libglib-2.0.so.4201.6 > #7 0x00079e766f01 in _rthread_start (v= Unhandled dwarf expression opcode 0xa3>) at > /usr/src/lib/librthread/rthread.c:96 > #8 0x0007ddaf95fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > (gdb) thread 8 > [Switching to thread 8 (thread 535484)] > #0 futex () at /tmp/-:3 > 3 in /tmp/- > (gdb) bt > #0 futex () at /tmp/-:3 > #1 0x0007ddad6d45 in _twait (p=0x8727626d0, val=1, clockid=3, > abs=0x7975f8460) at /usr/src/lib/libc/thread/synch.h:36 > #2 _rthread_cond_timedwait (cond=0x8727626d0, mutexp=0x87370dd50, > abs=0x7975f8460) at /usr/src/lib/libc/thread/rthread_cond.c:106 > #3 0x000821d06560 in g_cond_wait_until () from > /usr/local/lib/libglib-2.0.so.4201.6 > #4 0x000821c6b6e6 in g_async_queue_pop_intern_unlocked () from > /usr/local/lib/libglib-2.0.so.4201.6 > #5 0x000821cd890a in g_thread_pool_thread_proxy () from > /usr/local/lib/libglib-2.0.so.4201.6 > #6 0x000821cd7425 in g_thread_proxy () from > /usr/local/lib/libglib-2.0.so.4201.6 > #7 0x00079e766f01 in _rthread_start (v= Unhandled dwarf expression opcode 0xa3>) at > /usr/src/lib/librthread/rthread.c:96 > #8 0x0007ddaf95fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > -- Regards, Robert Nagy
Re: nginx gracefull shutdown
Hi
Okay
On 27/08/21 15:01 +0200, Antoine Jacoutot wrote:
> Hi.
>
> According to nginx man page:
>
> SIGINT, SIGTERM Shut down quickly.
> SIGQUIT Shut down gracefully.
>
> While I am not a fan of rewriting rc_ functions, I don't think this particular
> use case warrants new code to implement some new "rc_stop_sig" feature so I
> propose this to the rc.d script (and fix the reload case to add the proper
> rtable).
>
> OK?
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/nginx/Makefile,v
> retrieving revision 1.153
> diff -u -p -r1.153 Makefile
> --- Makefile 25 May 2021 19:43:55 - 1.153
> +++ Makefile 27 Aug 2021 12:56:50 -
> @@ -38,6 +38,8 @@ PKGNAME-passenger= nginx-passenger-${VER
> PKGNAME-rtmp=nginx-rtmp-${VERSION}
> PKGNAME-securelink= nginx-securelink-${VERSION}
>
> +REVISION-main= 0
> +
> ONLY_FOR_ARCHS-passenger= aarch64 amd64 arm i386
>
> MASTER_SITES=https://nginx.org/download/
> Index: pkg/nginx.rc
> ===
> RCS file: /cvs/ports/www/nginx/pkg/nginx.rc,v
> retrieving revision 1.14
> diff -u -p -r1.14 nginx.rc
> --- pkg/nginx.rc 11 Jan 2018 19:27:11 - 1.14
> +++ pkg/nginx.rc 27 Aug 2021 12:56:50 -
> @@ -9,7 +9,12 @@ daemon="${TRUEPREFIX}/sbin/nginx"
> pexp="nginx: master process ${daemon}${daemon_flags:+ ${daemon_flags}}"
>
> rc_reload() {
> - ${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"
> + ${daemon} ${daemon_flags} -t &&
> + pkill -HUP -T "${daemon_rtable}" -xf "${pexp}"
> +}
> +
> +rc_stop() {
> + pkill -QUIT -T "${daemon_rtable}" -xf "${pexp}"
> }
>
> rc_cmd $1
>
>
> --
> Antoine
--
Regards,
Robert Nagy
Re: update amdgpu-firmware to 20210818
ok
On 18/08/21 22:43 +1000, Jonathan Gray wrote:
> update amdgpu-firmware to linux-firmware 20210818
>
> "Newer firmware seems to cause random stability issues that
> are hard to reproduce reliably to root cause. Revert
> back to the older SDMA firmware until the issue is fixed."
>
> $ git log --oneline 20210716..20210818 amdgpu
> d843e52 amdgpu: revert back to older raven2 sdma firmware
> 99d7250 amdgpu: revert back to older raven sdma firmware
> d7b50e6 amdgpu: revert back to older picasso sdma firmware
> 243bc09 amdgpu: add initial vangogh support
> 1a14ded amdgpu: update vega20 firmware from 21.30
> 61f0e52 amdgpu: update vega12 firmware from 21.30
> 7a2b4d8 amdgpu: update vega10 firmware from 21.30
> a187709 amdgpu: update renoir firmware from 21.30
> b5f611f amdgpu: update raven2 firmware from 21.30
> bbdfd34 amdgpu: update raven firmware from 21.30
> 8b09c77 amdgpu: update polaris12 firmware from 21.30
> fbb372e amdgpu: update picasso firmware from 21.30
> 39f2a1e amdgpu: update dimgrey cavefish firmware from 21.30
> bfbdd73 amdgpu: update navy flounder firmware from 21.30
> 6b8436a amdgpu: update sienna cichlid firmware from 21.30
> 922b548 amdgpu: update navi14 firmware from 21.30
> f654bd7 amdgpu: update navi12 firmware from 21.30
> 3252b10 amdgpu: update navi10 firmware from 21.30
> 8f14593 amdgpu: update green sardine firmware from 21.30
> e087519 amdgpu: update arcturus firmware from 21.30
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/firmware/amdgpu/Makefile,v
> retrieving revision 1.9
> diff -u -p -r1.9 Makefile
> --- Makefile 28 Jul 2021 02:54:39 - 1.9
> +++ Makefile 18 Aug 2021 12:21:28 -
> @@ -1,7 +1,7 @@
> # $OpenBSD: Makefile,v 1.9 2021/07/28 02:54:39 jsg Exp $
>
> FW_DRIVER= amdgpu
> -FW_VER= 20210716
> +FW_VER= 20210818
> DISTNAME=linux-firmware-${FW_VER}
> EXTRACT_SUFX=.tar.xz
> EXTRACT_FILES= ${DISTNAME}/{LICENSE.\*,\*.bin}
> Index: distinfo
> ===
> RCS file: /cvs/ports/sysutils/firmware/amdgpu/distinfo,v
> retrieving revision 1.8
> diff -u -p -r1.8 distinfo
> --- distinfo 28 Jul 2021 02:54:39 - 1.8
> +++ distinfo 18 Aug 2021 12:22:04 -
> @@ -1,2 +1,2 @@
> -SHA256 (firmware/linux-firmware-20210716.tar.xz) =
> JYCrrY/PL8kwN8ozjWHWc3qJlwYHaW1+3x4X4Rsg51M=
> -SIZE (firmware/linux-firmware-20210716.tar.xz) = 171482168
> +SHA256 (firmware/linux-firmware-20210818.tar.xz) =
> vvPTF8NI2WKzoblctOGepPKC4YESssZpz/dPkmfOOJM=
> +SIZE (firmware/linux-firmware-20210818.tar.xz) = 172748332
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/sysutils/firmware/amdgpu/pkg/PLIST,v
> retrieving revision 1.8
> diff -u -p -r1.8 PLIST
> --- pkg/PLIST 28 Jul 2021 02:54:39 - 1.8
> +++ pkg/PLIST 18 Aug 2021 12:22:33 -
> @@ -355,6 +355,17 @@ firmware/amdgpu/topaz_rlc.bin
> firmware/amdgpu/topaz_sdma.bin
> firmware/amdgpu/topaz_sdma1.bin
> firmware/amdgpu/topaz_smc.bin
> +firmware/amdgpu/vangogh_asd.bin
> +firmware/amdgpu/vangogh_ce.bin
> +firmware/amdgpu/vangogh_dmcub.bin
> +firmware/amdgpu/vangogh_me.bin
> +firmware/amdgpu/vangogh_mec.bin
> +firmware/amdgpu/vangogh_mec2.bin
> +firmware/amdgpu/vangogh_pfp.bin
> +firmware/amdgpu/vangogh_rlc.bin
> +firmware/amdgpu/vangogh_sdma.bin
> +firmware/amdgpu/vangogh_toc.bin
> +firmware/amdgpu/vangogh_vcn.bin
> firmware/amdgpu/vega10_acg_smc.bin
> firmware/amdgpu/vega10_asd.bin
> firmware/amdgpu/vega10_ce.bin
--
Regards,
Robert Nagy
[cdrtools package] Consider updating to schilytools
Greetings, Upstream has recently integrated cdrtools into the larger schilytools project. There have not been any separate cdrtools releases since 2018, but the project is still being updated in the schilytools upstream. Please consider switching to the new upstream to receive updates. Yours, Robert Clausecker
Re: LibreOffice libpdfiumlo.so undefined symbol
Hi I've found an issue and fixed it in my next libreoffice update which should be commited this weekend. On 25/06/21 20:02 +0200, Caspar Schutijser wrote: > Hi, > > LibreOffice sometimes crashes with the following message on my > OpenBSD/amd64 machine: > > $ libreoffice > Warning: failed to launch javaldx - java may not function correctly > soffice.bin:/usr/local/lib/libreoffice/program/libpdfiumlo.so: undefined > symbol '_ZN12CFX_GEModule13PlatformIface6CreateEv' > ld.so: soffice.bin: lazy binding failed! > > This can be reproduced by creating a new presentation and then adding > a PDF image by selecting Insert > Image, then picking a PDF file and > then pressing Open. I don't do this myself but people send me .odp files > with contents which trigger this upon opening the .odp file. > > Caspar Schutijser > -- Regards, Robert Nagy
Re: nginx 1.20.1
okay
On 25/05/21 20:34 +0100, Stuart Henderson wrote:
> updates to the most recent stable branch, only lightly tested but seems ok so
> far.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/nginx/Makefile,v
> retrieving revision 1.152
> diff -u -p -r1.152 Makefile
> --- Makefile 10 May 2021 15:06:06 - 1.152
> +++ Makefile 25 May 2021 19:32:36 -
> @@ -17,17 +17,10 @@ COMMENT-passenger=nginx passenger (ruby
> COMMENT-rtmp=nginx module for RTMP streaming
> COMMENT-securelink= nginx HMAC secure link module
>
> -VERSION= 1.18.0
> +VERSION= 1.20.1
> DISTNAME=nginx-${VERSION}
> CATEGORIES= www
>
> -REVISION-main= 4
> -REVISION-lua=0
> -REVISION-xslt= 0
> -REVISION-passenger= 0
> -REVISION-stream= 0
> -REVISION-naxsi= 0
> -
> VERSION-rtmp=1.2.1
>
> PKGNAME-main=${DISTNAME}
> @@ -49,7 +42,8 @@ ONLY_FOR_ARCHS-passenger= aarch64 amd64
>
> MASTER_SITES=https://nginx.org/download/
> MASTER_SITES0= https://github.com/
> -MASTER_SITES1=
> https://raw.githubusercontent.com/rnagy/nginx_chroot_patch/master/
> +MASTER_SITES1=
> https://raw.githubusercontent.com/rnagy/nginx_chroot_patch/master/ \
> +
> https://raw.githubusercontent.com/sthen/nginx_chroot_patch/add_1.20.1/
>
> DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
>
> @@ -136,7 +130,7 @@ CFLAGS+= -Wall -Wpointer-arith \
> LDFLAGS+=-L ${LOCALBASE}/lib -L ${X11BASE}/lib
> CONFIGURE_ENV+= LDFLAGS="${LDFLAGS}"
>
> -PATCHFILES+= nginx-1.16.1-chroot.patch:1
> +PATCHFILES+= nginx-1.20.1-chroot.patch:1
> PATCH_DIST_STRIP=-p1
>
> CONFIGURE_STYLE= simple
> Index: distinfo
> ===
> RCS file: /cvs/ports/www/nginx/distinfo,v
> retrieving revision 1.76
> diff -u -p -r1.76 distinfo
> --- distinfo 2 Feb 2021 22:54:04 - 1.76
> +++ distinfo 25 May 2021 19:32:36 -
> @@ -1,8 +1,8 @@
> SHA256 (headers-more-nginx-module-v0.33.tar.gz) =
> o9y6sRepwQO8HqUgD8AKe30q+X/3/VJfFvisJjLjD78=
> SHA256 (lua-nginx-module-v0.10.11.tar.gz) =
> wPuR/P0cbn3sNMpkgm74H/66/e9hdNJURnY284BWZiY=
> SHA256 (naxsi-1.3.tar.gz) = Q5yGdzctJZe0Ngu8wQvIZJDeH8dWlbGTrV3xVKIU1ig=
> -SHA256 (nginx-1.16.1-chroot.patch) =
> ohNkspocgL7QnBX7q8Kgv2lgrN0ndgLKd0v5nSCLQRU=
> -SHA256 (nginx-1.18.0.tar.gz) = TDc+erW/kdNKTxGgyUllYQYbpe7mAg2ycqF6cijTX5k=
> +SHA256 (nginx-1.20.1-chroot.patch) =
> SS1TB0j8N4/dn5pUTGT6WvkN3aAUuKz5+R0Nt+MG0gk=
> +SHA256 (nginx-1.20.1.tar.gz) = 5GLhFTPVwwuqBd92UhYP9ZeVkdKRc2z6Xtuf0u20jEk=
> SHA256 (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) =
> aQxOW9sq4ZsP7nXNNW0YATRo20cmFrYJeloLvjRshGQ=
> SHA256 (nginx-rtmp-module-v1.2.1.tar.gz) =
> h6pZdACwtaBSdO4tI9jLgiThJoYiegq+MdeDs6ZF6jc=
> SHA256 (ngx_devel_kit-v0.3.0.tar.gz) =
> iOBamainQZBm9a51lm+x78QJutRSLRSYbaB0VUrmFhk=
> @@ -11,8 +11,8 @@ SHA256 (ngx_http_hmac_secure_link_module
> SIZE (headers-more-nginx-module-v0.33.tar.gz) = 28130
> SIZE (lua-nginx-module-v0.10.11.tar.gz) = 616653
> SIZE (naxsi-1.3.tar.gz) = 235626
> -SIZE (nginx-1.16.1-chroot.patch) = 8220
> -SIZE (nginx-1.18.0.tar.gz) = 1039530
> +SIZE (nginx-1.20.1-chroot.patch) = 8783
> +SIZE (nginx-1.20.1.tar.gz) = 1061461
> SIZE (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) =
> 18542
> SIZE (nginx-rtmp-module-v1.2.1.tar.gz) = 519919
> SIZE (ngx_devel_kit-v0.3.0.tar.gz) = 66455
> Index: patches/patch-man_nginx_8
> ===
> RCS file: /cvs/ports/www/nginx/patches/patch-man_nginx_8,v
> retrieving revision 1.5
> diff -u -p -r1.5 patch-man_nginx_8
> --- patches/patch-man_nginx_8 8 Jun 2020 06:03:50 - 1.5
> +++ patches/patch-man_nginx_8 25 May 2021 19:32:36 -
> @@ -1,8 +1,9 @@
> $OpenBSD: patch-man_nginx_8,v 1.5 2020/06/08 06:03:50 landry Exp $
> +
> Index: man/nginx.8
> --- man/nginx.8.orig
> +++ man/nginx.8
> -@@ -92,6 +92,23 @@ Do not run, just test the configuration file.
> +@@ -99,6 +99,23 @@ Do not run, just test the configuration file.
> .Nm
> checks the configuration file syntax and then tries to open files
> referenced in the configuration file.
>
--
Regards,
Robert Nagy
Re: [Update] www/chromium
ok
> On 2021. May 13., at 21:24, Tracey Emery wrote:
>
> On Thu, May 13, 2021 at 12:38:19PM -0600, Tracey Emery wrote:
>> Hello ports and robert,
>>
>> I installed a fresh copy of chrome the other day and it complained about
>> not finding libtiff. The following adds the run dependency. Fix some
>> WANTLIBS while here. Not sure how you want those ordered.
>>
>> Ok?
>>
>> --
>>
>> Tracey Emery
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/www/chromium/Makefile,v
>> retrieving revision 1.565
>> diff -u -p -u -r1.565 Makefile
>> --- Makefile11 May 2021 07:23:43 -1.565
>> +++ Makefile13 May 2021 18:35:57 -
>> @@ -14,6 +14,7 @@ DPB_PROPERTIES=parallel parallel2
>> COMMENT=Chromium browser
>>
>> V=90.0.4430.212
>> +REVISION=0
>>
>> DISTNAME=chromium-${V}
>>
>> @@ -72,16 +73,18 @@ WANTLIB += drm epoxy fontconfig freetype
>> WANTLIB += gthread-2.0 intl pangoft2-1.0 pcre pixman-1
>> WANTLIB += plc4 plds4 util xcb-dri2 xcb-glx xcb-render xcb-shm
>> WANTLIB += xml2 z
>> -WANTLIB += harfbuzz harfbuzz-subset
>> +WANTLIB += harfbuzz harfbuzz-subset harfbuzz-gobject
>> WANTLIB += ffi png
>> WANTLIB += iconv lzma
>> WANTLIB += fido2 cbor usbhid crypto
>> WANTLIB += gbm xkbcommon
>> +WANTLIB += tiff xshmfence
>>
>> RUN_DEPENDS=devel/xdg-utils \
>>devel/desktop-file-utils \
>>fonts/noto/fonts \
>>graphics/libexif \
>> +graphics/tiff \
>>x11/gtk+3,-guic \
>>x11/gtk+3,-cups
>> BUILD_DEPENDS=archivers/bzip2 \
>
> sthen@ points out this should be a LIB_DEPENDS and not a RUN_DEPENDS.
> Here is the new patch.
>
> Ok?
>
> --
>
> Tracey Emery
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/chromium/Makefile,v
> retrieving revision 1.565
> diff -u -p -u -r1.565 Makefile
> --- Makefile11 May 2021 07:23:43 -1.565
> +++ Makefile13 May 2021 19:22:46 -
> @@ -14,6 +14,7 @@ DPB_PROPERTIES=parallel parallel2
> COMMENT=Chromium browser
>
> V=90.0.4430.212
> +REVISION=0
>
> DISTNAME=chromium-${V}
>
> @@ -72,11 +73,12 @@ WANTLIB += drm epoxy fontconfig freetype
> WANTLIB += gthread-2.0 intl pangoft2-1.0 pcre pixman-1
> WANTLIB += plc4 plds4 util xcb-dri2 xcb-glx xcb-render xcb-shm
> WANTLIB += xml2 z
> -WANTLIB += harfbuzz harfbuzz-subset
> +WANTLIB += harfbuzz harfbuzz-subset harfbuzz-gobject
> WANTLIB += ffi png
> WANTLIB += iconv lzma
> WANTLIB += fido2 cbor usbhid crypto
> WANTLIB += gbm xkbcommon
> +WANTLIB += tiff xshmfence
>
> RUN_DEPENDS=devel/xdg-utils \
>devel/desktop-file-utils \
> @@ -97,6 +99,7 @@ BUILD_DEPENDS=archivers/bzip2 \
>${MODGCC4_CPPDEP}
> LIB_DEPENDS=devel/harfbuzz \
>devel/libexecinfo \
> +graphics/tiff \
>security/nss \
>textproc/libxslt \
>x11/gtk+3 \
Re: lang/mono for arm64
e
> ++#endif
> +
> + #include
> +
> +@@ -63,6 +65,15 @@ void OPENSSL_cpuid_setup(void) {
> + if (ID_AA64ISAR0_SHA2_VAL(isar0_val) >= ID_AA64ISAR0_SHA2_BASE) {
> + OPENSSL_armcap_P |= ARMV8_SHA256;
> + }
> ++}
> ++
> ++#elif defined(__OpenBSD__)
> ++
> ++#include
> ++#include
> ++
> ++void OPENSSL_cpuid_setup(void) {
> ++ OPENSSL_armcap_P |= ARMV7_NEON;
> + }
> +
> + #else // linux
> diff --git a/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
> b/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
> new file mode 100644
> index 000..0d036cac533
> --- /dev/null
> +++ b/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
> @@ -0,0 +1,18 @@
> +$OpenBSD$
> +
> +Index: mono/utils/mono-sigcontext.h
> +--- mono/utils/mono-sigcontext.h.orig
> mono/utils/mono-sigcontext.h
> +@@ -472,6 +472,12 @@ typedef struct ucontext {
> + #define UCONTEXT_REG_SP(ctx)
> (((ucontext_t*)(ctx))->uc_mcontext.mc_gpregs.gp_sp)
> + #define UCONTEXT_REG_R0(ctx)
> (((ucontext_t*)(ctx))->uc_mcontext.mc_gpregs.gp_x [ARMREG_R0])
> + #define UCONTEXT_GREGS(ctx)
> (&(((ucontext_t*)(ctx))->uc_mcontext.mc_gpregs.gp_x))
> ++#elif defined(__OpenBSD__)
> ++/* ucontext_t == sigcontext */
> ++#define UCONTEXT_REG_PC(ctx) (((ucontext_t*)(ctx))->sc_elr)
> ++#define UCONTEXT_REG_SP(ctx) (((ucontext_t*)(ctx))->sc_sp)
> ++#define UCONTEXT_REG_R0(ctx) (((ucontext_t*)(ctx))->sc_x [ARMREG_R0])
> ++#define UCONTEXT_GREGS(ctx) (&(((ucontext_t*)(ctx))->sc_x))
> + #else
> + #include
> + #define UCONTEXT_REG_PC(ctx) (((ucontext_t*)(ctx))->uc_mcontext.pc)
--
Regards,
Robert Nagy
Re: powerpc64 bulk build report
On 30/01/21 22:17 -0800, Greg Steuck wrote:
> jas...@openbsd.org writes:
>
> > Bulk build on powerpc64.ports.openbsd.org
> >
> > Started : Mon Jan 25 11:41:33 MST 2021
> > Finished: Sat Jan 30 12:29:09 MST 2021
> > Duration: 5 Days 0 hours 48 minutes
> ...
> > Build failures: 25
> > http://build-failures.rhaalovely.net/powerpc64/2021-01-25/devel/electron.log
> > http://build-failures.rhaalovely.net/powerpc64/2021-01-25/www/chromium.log
> > http://build-failures.rhaalovely.net/powerpc64/2021-01-25/www/iridium.log
>
> These end with:
> ...
> [182/182] LINK gn
> [0x24fdbd234a00:0127/183158.750205:FATAL:args.cc(361)] Check failed: false.
> OS architecture not handled. (powerpc64)
>
> The three ports above might go a bit further if variants of the
> following patch were to be applied. Only tested to still compile on
> amd64.
>
> Let me know how we should test this.
>
> From 8698fa1f94a1efd5f4ea126bbf4f6dd77d653821 Mon Sep 17 00:00:00 2001
> From: Greg Steuck
> Date: Sat, 30 Jan 2021 22:04:46 -0800
> Subject: [PATCH] Support powerpc64 in gn
>
> ---
> .../patches/patch-tools_gn_src_gn_args_cc| 16
> 1 file changed, 16 insertions(+)
> create mode 100644 www/chromium/patches/patch-tools_gn_src_gn_args_cc
>
> diff --git www/chromium/patches/patch-tools_gn_src_gn_args_cc
> www/chromium/patches/patch-tools_gn_src_gn_args_cc
> new file mode 100644
> index 000..4aefe14a3aa
> --- /dev/null
> +++ www/chromium/patches/patch-tools_gn_src_gn_args_cc
> @@ -0,0 +1,16 @@
> +$OpenBSD$
> +
> +OpenBSD has a different architecture name not seen before in gn.
> +
> +Index: tools/gn/src/gn/args.cc
> +--- tools/gn/src/gn/args.cc.orig
> tools/gn/src/gn/args.cc
> +@@ -356,7 +356,7 @@ void Args::SetSystemVarsLocked(Scope* dest) const {
> + arch = kMips64;
> + else if (os_arch == "s390x")
> + arch = kS390X;
> +- else if (os_arch == "ppc64" || os_arch == "ppc64le")
> ++ else if (os_arch == "ppc64" || os_arch == "ppc64le" || os_arch ==
> "powerpc64")
> + // We handle the endianness inside //build/config/host_byteorder.gni.
> + // This allows us to use the same toolchain as ppc64 BE
> + // and specific flags are included using the host_byteorder logic.
> --
> 2.30.0
Hi
I do not see the point in having this at the moment, because I am 100% sure
that it will fail just a bit later on.
Re: libc++ 10.0: editors/libreoffice
sure
On 11/01/21 00:27 +0100, Christian Weisgerber wrote:
> Here is some black magic extracted from upstream that fixes building
> editors/libreoffice with libc++ 10.0, at least on amd64.
>
> https://github.com/LibreOffice/core/commit/cc5a6c6afeed1d2cf76d288133971d29ee8d893e
>
> ok?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/editors/libreoffice/Makefile,v
> retrieving revision 1.239
> diff -u -p -r1.239 Makefile
> --- Makefile 22 Dec 2020 15:28:19 - 1.239
> +++ Makefile 10 Jan 2021 23:21:17 -
> @@ -38,6 +38,8 @@ DPB_PROPERTIES= parallel
>
> EPOCH= 0
>
> +REVISION=0
> +
> MAINTAINER= Robert Nagy
>
> HOMEPAGE=http://www.libreoffice.org/
> Index: patches/patch-bridges_source_cpp_uno_gcc3_linux_x86-64_except_cxx
> ===
> RCS file: patches/patch-bridges_source_cpp_uno_gcc3_linux_x86-64_except_cxx
> diff -N patches/patch-bridges_source_cpp_uno_gcc3_linux_x86-64_except_cxx
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-bridges_source_cpp_uno_gcc3_linux_x86-64_except_cxx 10 Jan
> 2021 23:21:17 -
> @@ -0,0 +1,69 @@
> +$OpenBSD$
> +
> +gcc3_linux_x86_64 needs a hack to detect the reserve member in LLVM >= 10
> +libcxxabi __cxa_exception, in addition to the existing hack for LLVM 5.
> +https://github.com/LibreOffice/core/commit/cc5a6c6afeed1d2cf76d288133971d29ee8d893e
> +
> +Index: bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx
> +--- bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx.orig
> bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx
> +@@ -82,6 +82,59 @@ extern "C" {
> + static void _GLIBCXX_CDTOR_CALLABI deleteException( void * pExc )
> + {
> + __cxxabiv1::__cxa_exception const * header =
> static_cast<__cxxabiv1::__cxa_exception const *>(pExc) - 1;
> ++#if defined _LIBCPPABI_VERSION // detect libc++abi
> ++// First, the libcxxabi commit
> ++// <http://llvm.org/viewvc/llvm-project?view=revision&revision=303175>
> ++// "[libcxxabi] Align unwindHeader on a double-word boundary" towards
> ++// LLVM 5.0 changed the size of __cxa_exception by adding
> ++//
> ++// __attribute__((aligned))
> ++//
> ++// to the final member unwindHeader, on x86-64 effectively adding a
> hole of
> ++// size 8 in front of that member (changing its offset from 88 to 96,
> ++// sizeof(__cxa_exception) from 120 to 128, and alignof(__cxa_exception)
> ++// from 8 to 16); the "header1" hack below to dynamically determine
> whether we run against a
> ++// LLVM 5 libcxxabi is to look at the exceptionDestructor member, which
> must
> ++// point to this function (the use of __cxa_exception in
> fillUnoException is
> ++// unaffected, as it only accesses members towards the start of the
> struct,
> ++// through a pointer known to actually point at the start). The
> libcxxabi commit
> ++//
> <https://github.com/llvm/llvm-project/commit/9ef1daa46edb80c47d0486148c0afc4e0d83ddcf>
> ++// "Insert padding before the __cxa_exception header to ensure the
> thrown" in LLVM 6
> ++// removes the need for this hack, so the "header1" hack can be removed
> again once we can be
> ++// sure that we only run against libcxxabi from LLVM >= 6.
> ++//
> ++// Second, the libcxxabi commit
> ++//
> <https://github.com/llvm/llvm-project/commit/674ec1eb16678b8addc02a4b0534ab383d22fa77>
> ++// "[libcxxabi] Insert padding in __cxa_exception struct for
> compatibility" in LLVM 10 changed
> ++// the layout of the start of __cxa_exception to
> ++//
> ++// [8 byte void *reserve]
> ++// 8 byte size_t referenceCount
> ++//
> ++// so the "header2" hack below to dynamically determine whether we run
> against a LLVM >= 10
> ++// libcxxabi is to look whether the exceptionDestructor (with its known
> value) has increased its
> ++// offset by 8. As described in the definition of __cxa_exception
> ++// (bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx), the "header2"
> hack (together with the
> ++// "#if 0" in the definition of __cxa_exception and the corresponding
> hack in fillUnoException)
> ++// can be dropped once we can be sure that we only run against new
> libcxxabi that has the
> ++// reserve member.
> ++if (header->exceptionDestructor != &deleteException) {
> ++auto const header1 = reinterpret_cast<__cxa_exception const *>(
> ++reinte
Re: bsd.port.mk: add .rpm to EXTRACT_CASES
On 09/01/21 22:50 +0100, Klemens Nanni wrote: > On Sat, Jan 09, 2021 at 10:38:36PM +0100, Klemens Nanni wrote: > > Coming from sysutils/mdprint I want ordinary distfiles handling. > > Since we have more than one port using RPM files, here is a straight > > forward diff to unify each of their quirky handling. > > > > Less code, no plist change and we can use EXTRACT_FILES if need be. > Pardon, here's there correct diff that actually simplifies kopano/webapp > as intended. > > Cc'ed robert as its maintianer. i am fine with this
Re: [NEW] graphics/libva and graphics/intel-vaapi-driver
The upcoming chromium update also requires libva, so I've fixed up and updated the submitted libva port. Attached is the new version. libva.tar.gz Description: Binary data
