On Wed May 03, 2023 at 05:19:46PM +0000, Klemens Nanni wrote: > On Mon, May 01, 2023 at 01:37:46PM +0200, Rafael Sadowski wrote: > > On Mon May 01, 2023 at 09:16:12AM +0000, Klemens Nanni wrote: > > > On Mon, Apr 10, 2023 at 08:30:03AM +0200, Rafael Sadowski wrote: > > > > Hi ports hackers, > > > > > > > > here are some new Qt6 modules. OK to import? > > > > > > All build/package with complete WANTLIB, Makefiles look good. > > > > Thanks! > > > > > > > > I can't `cd $(make show=WRKSRC)' due to o=0 permissions. > > > Do we need qt(6?)-wide FIX_EXTRACT_PERMISSIONS=Yes? > > x11/qt6/qt5compat and x11/qt5/qtvirtualkeyboard as random samples have the > same has the same issue: > > $ stat -f%Sp `mk show=WRKSRC` > drwx------ > > > I'd use FIX_EXTRACT_PERMISSIONS for them all, diff below. > Feedback? Objection? OK? > > > > > I do not build with PORTS_PRIVSEP=yes. > > Please do, otherwise ports may work for you (doing network, writing > outside of pobj, etc.), but fail for other porters and on bulk machines.
I switched my ports setup to PORTS_PRIVSEP=yes. Thanks for the note.
>
> > > All but qtgrpc need update-plist to remove common directories.
> >
> > Hm, I have no changes here.
>
> Do you have pkglocatedb package installed? update-plist(1) -f is the
> default and checks against already registered files.
Still no changes at all:
$ make update-plist
...
===> Updating plist for qt6-qtgrpc-6.5.0
Reading existing plist for qt6-qtgrpc-6.5.0
Scanning /usr/ports/pobj/qt6-qtgrpc-6.5.0/fake-amd64
Removing .debug artefacts
Figuring out tie points
Tieing loose objects
Copying objects
Stripping directories from x11/qt6/qtbase,-main
Stripping directories from math/double-conversion
Stripping directories from archivers/brotli
Stripping directories from devel/harfbuzz,-main
Stripping directories from graphics/graphite2
Stripping directories from print/cups,-libs
Stripping directories from net/avahi,-libs
Stripping directories from devel/libevent2
Stripping directories from devel/pango
Stripping directories from devel/glib2
Stripping directories from devel/libffi
Stripping directories from lang/python/3.10,-main
Stripping directories from databases/sqlite3
Stripping directories from archivers/bzip2
Stripping directories from archivers/xz
Stripping directories from devel/fribidi
Stripping directories from archivers/zstd
Stripping directories from archivers/lz4
Stripping directories from security/libb2
Stripping directories from x11/gnome/at-spi2-core
Stripping directories from textproc/libxml,-main
Stripping directories from converters/libiconv
Stripping directories from graphics/cairo
Stripping directories from archivers/lzo2
Stripping directories from graphics/png
Stripping directories from x11/xkbcommon
Stripping directories from databases/iodbc,-main
Stripping directories from devel/gettext,-runtime
Stripping directories from graphics/gdk-pixbuf2
Stripping directories from misc/shared-mime-info
Stripping directories from graphics/tiff
Stripping directories from graphics/jpeg
Stripping directories from textproc/icu4c,-main
Stripping directories from x11/gtk+3,-main
Stripping directories from devel/dconf
Stripping directories from x11/gnome/adwaita-icon-theme
Stripping directories from x11/gnome/librsvg
Stripping directories from devel/desktop-file-utils
Stripping directories from x11/gtk+4,-guic
Stripping directories from x11/hicolor-icon-theme
Stripping directories from x11/dbus,-main
Stripping directories from devel/pcre2
Stripping directories from devel/protobuf
Looking for unregistered conflicts
BUT there are changes in all other new ports :-D
>
> > > I see you define PX_OPENBSD in various places, but also define PX_LINUX,
> > > why?
> >
> > PX_LINUX is default and enabled and we use it but for some cases we need
> > PX_OPENBSD.
>
> Shouldn't all PX_LINUX checks eventually honour PX_OPENBSD as well?
> Or do you want to piggy back PX_LINUX and only maintain the bare minimum of
> OpenBSD specific macro foo?
We need PX_OPENBSD only for some corner cases.
>
> > > This port uses syscall(2), i.e. `syscall(getthrid)', which sohuld be
> > > direct.
> >
> > "which sohuld be direct"? Why?
>
> *NOT*, sorry
>
> Syscalls must come from libc, lots of ports have been patched and fixed
> upstream to not use direct syscall(2) but instead call into libc functions.
Ops, for sure! I forgot to add a "!", patch fixed!
>
> > > What's the story with s/NULL/0/ in the patches?
> >
> > This fix (our?) clang build. C++ template magic.
>
> Can you mention this in a comment? It saves time and effort for anyone not
> intimitely familiar with the C++ ecosystem; I can't tell if this is a legit
> fix (in our OpenBSD ports case) or just a workaround.
Comments added, new tarball attached.
>
>
>
> Index: x11/qt5/Makefile.inc
> ===================================================================
> RCS file: /cvs/ports/x11/qt5/Makefile.inc,v
> retrieving revision 1.20
> diff -u -p -r1.20 Makefile.inc
> --- x11/qt5/Makefile.inc 13 Jul 2022 15:48:56 -0000 1.20
> +++ x11/qt5/Makefile.inc 3 May 2023 17:15:20 -0000
> @@ -1,5 +1,7 @@
> ONLY_FOR_ARCHS ?= ${GCC4_ARCHS} ${CLANG_ARCHS}
>
> +FIX_EXTRACT_PERMISSIONS ?= Yes
> +
> .include "Makefile.version"
>
> # DIST_VERSION should be defined, e.g., when patch distfile gets issued,
> Index: x11/qt6/Makefile.inc
> ===================================================================
> RCS file: /cvs/ports/x11/qt6/Makefile.inc,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile.inc
> --- x11/qt6/Makefile.inc 28 May 2022 06:20:04 -0000 1.5
> +++ x11/qt6/Makefile.inc 3 May 2023 17:15:27 -0000
> @@ -1,5 +1,7 @@
> ONLY_FOR_ARCHS ?= ${GCC4_ARCHS} ${CLANG_ARCHS}
>
> +FIX_EXTRACT_PERMISSIONS ?= Yes
> +
> .include "Makefile.version"
>
> VERSION ?= ${QT6_VERSION}
binVJEU1Eg1Uz.bin
Description: application/tar-gz
