Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 11:58:03PM +0200, Mark Kettenis wrote: > > Date: Thu, 7 Sep 2023 22:02:12 +0200 > > From: Matthieu Herrb > > > > basically just define the CARDnn types in terms on uint_nn everywhere. > > Like for signal.h all systems still supported by X have stdint and the > > uintnn_t types. > > The problem with this is that you're changing the type of CARD32 and > CARD64. Which means that if these types are used in C++ code, the > mangling changes, and therefore you risk breaking the ABI. And I bet > you there is C++ code that uses the CARD32 and CARD64 types. > > How did the commit break the tree? The actual error messages were > never mailed out as far as I can tell. > > I think you should simply revert to the pre-hackathon state. Done. Indeed this needs more thinking. I've reverted those commits. Here are the errors with llvm 16 on the tree before p2k23 (and -current) in xserver/glamor_egl: libtool: compile: /usr/local/bin/clang-16 -DHAVE_CONFIG_H -I. -I/local/OpenBSD/xenocara/xserver/hw/xfree86/glamor_egl -I../../../include -I/local/OpenBSD/xenocara/xserver/hw/xfree86 -I/local/OpenBSD/xenocara/xserver/hw/xfree86/include -I/local/OpenBSD/xenocara/xserver/hw/xfree86/common -I/local/OpenBSD/xenocara/xserver/hw/xfree86/os-support -I/local/OpenBSD/xenocara/xserver/hw/xfree86/os-support/bus -I/local/OpenBSD/xenocara/xserver/os -I/local/OpenBSD/xenocara/xserver/dri3 -I/local/OpenBSD/xenocara/xserver/glamor -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -fno-strict-aliasing -I/usr/X11R6/include -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/X11R6/include/X11/dri -I/usr/X11R6/include/libdrm -I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include/freetype2 -I/local/OpenBSD/xenocara/xserver/include -I../../../include -I/local/OpenBSD/xenocara/xserver/Xext -I/local/OpenBSD/xenocara/xserver/composite -I/local/OpenBSD/xenocara/xserver/damageext -I/local/OpenBSD/xenocara/xserver/xfixes -I/local/OpenBSD/xenocara/xserver/Xi -I/local/OpenBSD/xenocara/xserver/mi -I/local/OpenBSD/xenocara/xserver/miext/sync -I/local/OpenBSD/xenocara/xserver/miext/shadow -I/local/OpenBSD/xenocara/xserver/miext/damage -I/local/OpenBSD/xenocara/xserver/render -I/local/OpenBSD/xenocara/xserver/randr -I/local/OpenBSD/xenocara/xserver/fb -I/local/OpenBSD/xenocara/xserver/dbe -I/local/OpenBSD/xenocara/xserver/present -fvisibility=hidden -I/usr/X11R6/include -DHAVE_XORG_CONFIG_H -fvisibility=hidden -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/libdrm -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/libdrm -I/usr/X11R6/include -O2 -pipe -pthread -c /local/OpenBSD/xenocara/xserver/glamor/glamor_egl.c -fPIC -DPIC -o .libs/glamor_egl.o /local/OpenBSD/xenocara/xserver/glamor/glamor_egl.c:849:24: error: incompatible function pointer types initializing 'dri3_pixmap_from_fds_proc' (aka 'struct _Pixmap *(*)(struct _Screen *, unsigned char, const int *, unsigned short, unsigned short, const unsigned int *, const unsigned int *, unsigned char, unsigned char, unsigned long)') with an expression of type 'PixmapPtr (ScreenPtr, CARD8, const int *, CARD16, CARD16, const CARD32 *, const CARD32 *, CARD8, CARD8, uint64_t)' (aka 'struct _Pixmap *(struct _Screen *, unsigned char, const int *, unsigned short, unsigned short, const unsigned int *, const unsigned int *, unsigned char, unsigned char, unsigned long long)') [-Wincompatible-function-pointer-types] .pixmap_from_fds = glamor_pixmap_from_fds, ^~ 1 error generated. *** Error 1 in xserver/obj/hw/xfree86/glamor_egl (Makefile:635 'glamor_egl.lo') in xserver/hw/xfree86/drivers/modesetting: source='/local/OpenBSD/xenocara/xserver/hw/xfree86/drivers/modesetting/dri2.c' object='dri2.lo' libtool=yes DEPDIR=.deps depmode=none /bin/sh /local/OpenBSD/xenocara/xserver/depcomp /bin/sh ../../../../libtool --tag=CC --mode=compile /usr/local/bin/clang-16 -DHAVE_CONFIG_H -I. -I/local/OpenBSD/xenocara/xserver/hw/xfree86/drivers/modesetting -I../../../../include -I/local/OpenBSD/xenocara/xserver/hw/xfree86 -I/local/OpenBSD/xenocara/xserver/hw/xfree86/include -I/local/OpenBSD/xenocara/xserver/hw/xfree86/common -I/local/OpenBSD/xenocara/xserver/hw/xfree86/os-support -I/local/OpenBSD/xenocara/xserver/hw/xfree86/os-support/bus -I/local/OpenBSD/xenocara/xserver/os -I/local/OpenBSD/xenocara/xserver/glamor
Re: CVS: cvs.openbsd.org: xenocara
> Date: Thu, 7 Sep 2023 22:02:12 +0200
> From: Matthieu Herrb
>
> On Thu, Sep 07, 2023 at 05:24:56PM +0200, Matthieu Herrb wrote:
> > On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote:
> > > On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote:
> > > > CVSROOT:/cvs
> > > > Module name:xenocara
> > > > Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37
> > > >
> > > > Modified files:
> > > > driver/xf86-video-amdgpu/src: amdgpu_present.c
> > > > drmmode_display.h
> > > > xserver/glamor : glamor.h glamor_egl.c
> > > >
> > > > Log message:
> > > > unbreak build with clang-16 by fixing up function definitions to match
> > > >
> > > > our uint64_t is an unsinged long long, but CARD64 is defined as
> > > > unsigned long
> > > > so the function pointer types in both glamor and xf86-video-amdgpu were
> > > > mismatched and clang-16 treats that as an error
> > > >
> > > > ok matthieu@
> > >
> > > This broke the tree. Here's a potential fix.
> >
> > Hmm no, this one reverts parts of the llvm 16 diffs.
> >
> > What about this that gets rid of CARD64 completely in this context ?
> >
> > hint for the X developpers: CARD64 and friends are normally reserved
> > for the X protocol specification and implementation
> >
> > All other uses as cheap substites for uint64_t or similar are just
> > historical artefacts from an era where there was no standard integer
> > types with known fixed lengths.
>
> This is still not enough.
>
> I've deciced to cure the problem at its root.
>
> Whith this patch, the tree builds with both base llvm and llvm 16 on
> amd64. I've started a build i386 to double check 32 bit arches.
>
> And it will allow to revert some other patches to reduce the number of
> local changes. I also think that it has some chances to be accepted
> upstreams.
>
> basically just define the CARDnn types in terms on uint_nn everywhere.
> Like for signal.h all systems still supported by X have stdint and the
> uintnn_t types.
The problem with this is that you're changing the type of CARD32 and
CARD64. Which means that if these types are used in C++ code, the
mangling changes, and therefore you risk breaking the ABI. And I bet
you there is C++ code that uses the CARD32 and CARD64 types.
How did the commit break the tree? The actual error messages were
never mailed out as far as I can tell.
I think you should simply revert to the pre-hackathon state.
> Index: proto/xorgproto/include/X11/Xmd.h
> ===
> RCS file: /local/cvs/xenocara/proto/xorgproto/include/X11/Xmd.h,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 Xmd.h
> --- proto/xorgproto/include/X11/Xmd.h 11 Nov 2021 08:55:42 - 1.2
> +++ proto/xorgproto/include/X11/Xmd.h 7 Sep 2023 16:20:01 -
> @@ -57,6 +57,8 @@ SOFTWARE.
> # include /* Solaris: defines _LP64 if necessary */
> # endif
>
> +#include
> +
> #if defined(__SIZEOF_LONG__)
> # if __SIZEOF_LONG__ == 8
> # define LONG64 /* 32/64-bit architecture */
> @@ -107,15 +109,10 @@ typedef short INT16;
>
> typedef signed charINT8;
>
> -# ifdef LONG64
> -typedef unsigned long CARD64;
> -typedef unsigned int CARD32;
> -# else
> -typedef unsigned long long CARD64;
> -typedef unsigned long CARD32;
> -# endif
> -typedef unsigned short CARD16;
> -typedef unsigned char CARD8;
> +typedef uint64_t CARD64;
> +typedef uint32_t CARD32;
> +typedef uint16_t CARD16;
> +typedef uint8_t CARD8;
>
> typedef CARD32 BITS32;
> typedef CARD16 BITS16;
>
> >
> > Index: src/drmmode_display.c
> > ===
> > RCS file:
> > /local/cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
> > retrieving revision 1.4
> > diff -u -p -u -r1.4 drmmode_display.c
> > --- src/drmmode_display.c 5 Dec 2022 16:41:17 - 1.4
> > +++ src/drmmode_display.c 7 Sep 2023 15:20:36 -
> > @@ -197,7 +197,7 @@ drmmode_wait_vblank(xf86CrtcPtr crtc, dr
> > * version and DRM kernel module configuration, the vblank
> > * timestamp can either be in real time or monotonic time
> > */
> > -int drmmode_get_current_ust(int drm_fd, CARD64 * ust)
> > +int drmmode_get_current_ust(int drm_fd, uint64_t * ust)
> > {
> > uint64_t cap_value;
> > int ret;
> > @@ -211,14 +211,14 @@ int drmmode_get_current_ust(int drm_fd,
> > ret = clock_gettime(CLOCK_MONOTONIC, );
> > if (ret)
> > return ret;
> > - *ust = ((CARD64) now.tv_sec * 100) + ((CARD64) now.tv_nsec / 1000);
> > + *ust = ((uint64_t) now.tv_sec * 100) + ((uint64_t) now.tv_nsec /
> > 1000);
> > return 0;
> > }
> >
> > /*
> > * Get current frame count and frame count timestamp of the crtc.
> > */
> > -int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
> > +int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t
>
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 10:02:12PM +0200, Matthieu Herrb wrote:
> On Thu, Sep 07, 2023 at 05:24:56PM +0200, Matthieu Herrb wrote:
> > On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote:
> > > On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote:
> > > > CVSROOT:/cvs
> > > > Module name:xenocara
> > > > Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37
> > > >
> > > > Modified files:
> > > > driver/xf86-video-amdgpu/src: amdgpu_present.c
> > > > drmmode_display.h
> > > > xserver/glamor : glamor.h glamor_egl.c
> > > >
> > > > Log message:
> > > > unbreak build with clang-16 by fixing up function definitions to match
> > > >
> > > > our uint64_t is an unsinged long long, but CARD64 is defined as
> > > > unsigned long
> > > > so the function pointer types in both glamor and xf86-video-amdgpu were
> > > > mismatched and clang-16 treats that as an error
> > > >
> > > > ok matthieu@
> > >
> > > This broke the tree. Here's a potential fix.
> >
> > Hmm no, this one reverts parts of the llvm 16 diffs.
> >
> > What about this that gets rid of CARD64 completely in this context ?
> >
> > hint for the X developpers: CARD64 and friends are normally reserved
> > for the X protocol specification and implementation
> >
> > All other uses as cheap substites for uint64_t or similar are just
> > historical artefacts from an era where there was no standard integer
> > types with known fixed lengths.
>
> This is still not enough.
>
> I've deciced to cure the problem at its root.
>
> Whith this patch, the tree builds with both base llvm and llvm 16 on
> amd64. I've started a build i386 to double check 32 bit arches.
>
> And it will allow to revert some other patches to reduce the number of
> local changes. I also think that it has some chances to be accepted
> upstreams.
>
> basically just define the CARDnn types in terms on uint_nn everywhere.
> Like for signal.h all systems still supported by X have stdint and the
> uintnn_t types.
>
If this builds please land it.
>
> Index: proto/xorgproto/include/X11/Xmd.h
> ===
> RCS file: /local/cvs/xenocara/proto/xorgproto/include/X11/Xmd.h,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 Xmd.h
> --- proto/xorgproto/include/X11/Xmd.h 11 Nov 2021 08:55:42 - 1.2
> +++ proto/xorgproto/include/X11/Xmd.h 7 Sep 2023 16:20:01 -
> @@ -57,6 +57,8 @@ SOFTWARE.
> # include /* Solaris: defines _LP64 if necessary */
> # endif
>
> +#include
> +
> #if defined(__SIZEOF_LONG__)
> # if __SIZEOF_LONG__ == 8
> # define LONG64 /* 32/64-bit architecture */
> @@ -107,15 +109,10 @@ typedef short INT16;
>
> typedef signed charINT8;
>
> -# ifdef LONG64
> -typedef unsigned long CARD64;
> -typedef unsigned int CARD32;
> -# else
> -typedef unsigned long long CARD64;
> -typedef unsigned long CARD32;
> -# endif
> -typedef unsigned short CARD16;
> -typedef unsigned char CARD8;
> +typedef uint64_t CARD64;
> +typedef uint32_t CARD32;
> +typedef uint16_t CARD16;
> +typedef uint8_t CARD8;
>
> typedef CARD32 BITS32;
> typedef CARD16 BITS16;
>
> >
> > Index: src/drmmode_display.c
> > ===
> > RCS file:
> > /local/cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
> > retrieving revision 1.4
> > diff -u -p -u -r1.4 drmmode_display.c
> > --- src/drmmode_display.c 5 Dec 2022 16:41:17 - 1.4
> > +++ src/drmmode_display.c 7 Sep 2023 15:20:36 -
> > @@ -197,7 +197,7 @@ drmmode_wait_vblank(xf86CrtcPtr crtc, dr
> > * version and DRM kernel module configuration, the vblank
> > * timestamp can either be in real time or monotonic time
> > */
> > -int drmmode_get_current_ust(int drm_fd, CARD64 * ust)
> > +int drmmode_get_current_ust(int drm_fd, uint64_t * ust)
> > {
> > uint64_t cap_value;
> > int ret;
> > @@ -211,14 +211,14 @@ int drmmode_get_current_ust(int drm_fd,
> > ret = clock_gettime(CLOCK_MONOTONIC, );
> > if (ret)
> > return ret;
> > - *ust = ((CARD64) now.tv_sec * 100) + ((CARD64) now.tv_nsec / 1000);
> > + *ust = ((uint64_t) now.tv_sec * 100) + ((uint64_t) now.tv_nsec /
> > 1000);
> > return 0;
> > }
> >
> > /*
> > * Get current frame count and frame count timestamp of the crtc.
> > */
> > -int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
> > +int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t
> > *msc)
> > {
> > ScrnInfoPtr scrn = crtc->scrn;
> > uint32_t seq;
> > @@ -303,7 +303,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
> > drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
> > ScrnInfoPtr scrn = crtc->scrn;
> > AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(scrn);
> > - CARD64 ust;
> > + uint64_t ust;
> > int ret;
> >
> > if
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 05:24:56PM +0200, Matthieu Herrb wrote:
> On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote:
> > On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote:
> > > CVSROOT: /cvs
> > > Module name: xenocara
> > > Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37
> > >
> > > Modified files:
> > > driver/xf86-video-amdgpu/src: amdgpu_present.c drmmode_display.h
> > > xserver/glamor : glamor.h glamor_egl.c
> > >
> > > Log message:
> > > unbreak build with clang-16 by fixing up function definitions to match
> > >
> > > our uint64_t is an unsinged long long, but CARD64 is defined as unsigned
> > > long
> > > so the function pointer types in both glamor and xf86-video-amdgpu were
> > > mismatched and clang-16 treats that as an error
> > >
> > > ok matthieu@
> >
> > This broke the tree. Here's a potential fix.
>
> Hmm no, this one reverts parts of the llvm 16 diffs.
>
> What about this that gets rid of CARD64 completely in this context ?
>
> hint for the X developpers: CARD64 and friends are normally reserved
> for the X protocol specification and implementation
>
> All other uses as cheap substites for uint64_t or similar are just
> historical artefacts from an era where there was no standard integer
> types with known fixed lengths.
This is still not enough.
I've deciced to cure the problem at its root.
Whith this patch, the tree builds with both base llvm and llvm 16 on
amd64. I've started a build i386 to double check 32 bit arches.
And it will allow to revert some other patches to reduce the number of
local changes. I also think that it has some chances to be accepted
upstreams.
basically just define the CARDnn types in terms on uint_nn everywhere.
Like for signal.h all systems still supported by X have stdint and the
uintnn_t types.
Index: proto/xorgproto/include/X11/Xmd.h
===
RCS file: /local/cvs/xenocara/proto/xorgproto/include/X11/Xmd.h,v
retrieving revision 1.2
diff -u -p -u -r1.2 Xmd.h
--- proto/xorgproto/include/X11/Xmd.h 11 Nov 2021 08:55:42 - 1.2
+++ proto/xorgproto/include/X11/Xmd.h 7 Sep 2023 16:20:01 -
@@ -57,6 +57,8 @@ SOFTWARE.
# include /* Solaris: defines _LP64 if necessary */
# endif
+#include
+
#if defined(__SIZEOF_LONG__)
# if __SIZEOF_LONG__ == 8
# define LONG64 /* 32/64-bit architecture */
@@ -107,15 +109,10 @@ typedef short INT16;
typedef signed charINT8;
-# ifdef LONG64
-typedef unsigned long CARD64;
-typedef unsigned int CARD32;
-# else
-typedef unsigned long long CARD64;
-typedef unsigned long CARD32;
-# endif
-typedef unsigned short CARD16;
-typedef unsigned char CARD8;
+typedef uint64_t CARD64;
+typedef uint32_t CARD32;
+typedef uint16_t CARD16;
+typedef uint8_t CARD8;
typedef CARD32 BITS32;
typedef CARD16 BITS16;
>
> Index: src/drmmode_display.c
> ===
> RCS file: /local/cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
> retrieving revision 1.4
> diff -u -p -u -r1.4 drmmode_display.c
> --- src/drmmode_display.c 5 Dec 2022 16:41:17 - 1.4
> +++ src/drmmode_display.c 7 Sep 2023 15:20:36 -
> @@ -197,7 +197,7 @@ drmmode_wait_vblank(xf86CrtcPtr crtc, dr
> * version and DRM kernel module configuration, the vblank
> * timestamp can either be in real time or monotonic time
> */
> -int drmmode_get_current_ust(int drm_fd, CARD64 * ust)
> +int drmmode_get_current_ust(int drm_fd, uint64_t * ust)
> {
> uint64_t cap_value;
> int ret;
> @@ -211,14 +211,14 @@ int drmmode_get_current_ust(int drm_fd,
> ret = clock_gettime(CLOCK_MONOTONIC, );
> if (ret)
> return ret;
> - *ust = ((CARD64) now.tv_sec * 100) + ((CARD64) now.tv_nsec / 1000);
> + *ust = ((uint64_t) now.tv_sec * 100) + ((uint64_t) now.tv_nsec /
> 1000);
> return 0;
> }
>
> /*
> * Get current frame count and frame count timestamp of the crtc.
> */
> -int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
> +int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t *msc)
> {
> ScrnInfoPtr scrn = crtc->scrn;
> uint32_t seq;
> @@ -303,7 +303,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
> drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
> ScrnInfoPtr scrn = crtc->scrn;
> AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(scrn);
> - CARD64 ust;
> + uint64_t ust;
> int ret;
>
> if (drmmode_crtc->dpms_mode == DPMSModeOn && mode != DPMSModeOn) {
> @@ -321,7 +321,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
> "%s cannot get last vblank counter\n",
> __func__);
> else {
> - CARD64 nominal_frame_rate, pix_in_frame;
> + uint64_t
Re: freetype bumps [Re: CVS: cvs.openbsd.org: xenocara]
On 2018/05/25 22:55, Matthieu Herrb wrote: > On Fri, May 25, 2018 at 12:11:27PM +0100, Stuart Henderson wrote: > > > > Some packages depend on freetype AND another X lib that depends on freetype, > > Until new packages are available and the user has run pkg_add -u, this > > results > > in two conflicting versions of freetype being pulled in. > > > > WANTLIB is not the problem. WANTLIBs are correct. The packages do get > > updated once new packages are available, the problem is in the interim > > between bumping libs and new packages becoming available. > > > > Build times: > > > > aarch64 ~4 days > > amd64 1 day > > arm ~10 days > > hppa~4 days > > i38628-50 hours > > mips64 4 days > > mips64el6 weeks > > powerpc ~2..3 weeks > > sparc64 ~2..3 weeks > > > > But unless bulk builders know that they need to restart builds, the previous > > build needs to finish before the new one can start, so it can be double > > those > > times before packages built against new libs are shipped. > > > > I don't know what the case is with libc/libm. We *do* do this type of > > bump in libssl/libcrypto/libtls because we know things break otherwise. > > And there is a clear problem with the freetype chain because it keeps > > happening again and again. > > > > By bumping the other libs e.g. fontconfig, already-installed software > > will continue to use the version of the other libs already on their > > disk, which uses the old freetype, avoiding the conflict. > > > > Ok, thanks. I keep forgetting about this delay in builing packages. > In that case I understand that it will help. > > So ok for the following diff and a (late) bump of the 3 mentionned > libs ? > > Index: shlib_version > === > RCS file: /cvs/OpenBSD/xenocara/lib/freetype/shlib_version,v > retrieving revision 1.28 > diff -u -r1.28 shlib_version > --- shlib_version 21 May 2018 11:52:24 - 1.28 > +++ shlib_version 25 May 2018 20:54:40 - > @@ -1,2 +1,4 @@ > major=29 > minor=0 > +# note: If bumping the major, also bump major for libXft, libXfont2 > +# and libfontconfig > > -- > Matthieu Herrb Bumping would certainly help. Arches currently building packages look like this: $ grep libfreetype.so. */*sig.log aarch64/arm64-1.sig.log:/usr/X11R6/lib/libfreetype.so.29.0 aarch64/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.29.0 arm/armv7-1.sig.log:/usr/X11R6/lib/libfreetype.so.28.2 arm/armv7-2.sig.log:/usr/X11R6/lib/libfreetype.so.28.2 arm/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 hppa/hppa-1.sig.log:/usr/X11R6/lib/libfreetype.so.28.2 hppa/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 i386/i386-2.sig.log:/usr/X11R6/lib/libfreetype.so.29.0 i386/i386.sig.log: /usr/X11R6/lib/libfreetype.so.29.0 i386/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.29.0 powerpc/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 powerpc/macppc-0.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 sparc64/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 sparc64/sparc64-0.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 sparc64/sparc64-2.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 only fast arches already have 29.0 so won't be too badly hurt by bumping the other libraries now, and will help the slower-building arches. So OK with bumps. For the comment, I'm unsure what is needed when the minor is bumped, it depends whether ld.so picks up an exact match if available, or if it always looks for the highest minor version. The text we have in libcrypto's shlib_version is "Don't forget to give libssl and libtls the same type of bump!" so at least at some time somebody thought it was needed for minor bumps too. Someone else reading can probably give better advice on this.
Re: freetype bumps [Re: CVS: cvs.openbsd.org: xenocara]
On Fri, May 25, 2018 at 12:11:27PM +0100, Stuart Henderson wrote: > > Some packages depend on freetype AND another X lib that depends on freetype, > Until new packages are available and the user has run pkg_add -u, this results > in two conflicting versions of freetype being pulled in. > > WANTLIB is not the problem. WANTLIBs are correct. The packages do get > updated once new packages are available, the problem is in the interim > between bumping libs and new packages becoming available. > > Build times: > > aarch64 ~4 days > amd64 1 day > arm ~10 days > hppa~4 days > i38628-50 hours > mips64 4 days > mips64el6 weeks > powerpc ~2..3 weeks > sparc64 ~2..3 weeks > > But unless bulk builders know that they need to restart builds, the previous > build needs to finish before the new one can start, so it can be double those > times before packages built against new libs are shipped. > > I don't know what the case is with libc/libm. We *do* do this type of > bump in libssl/libcrypto/libtls because we know things break otherwise. > And there is a clear problem with the freetype chain because it keeps > happening again and again. > > By bumping the other libs e.g. fontconfig, already-installed software > will continue to use the version of the other libs already on their > disk, which uses the old freetype, avoiding the conflict. > Ok, thanks. I keep forgetting about this delay in builing packages. In that case I understand that it will help. So ok for the following diff and a (late) bump of the 3 mentionned libs ? Index: shlib_version === RCS file: /cvs/OpenBSD/xenocara/lib/freetype/shlib_version,v retrieving revision 1.28 diff -u -r1.28 shlib_version --- shlib_version 21 May 2018 11:52:24 - 1.28 +++ shlib_version 25 May 2018 20:54:40 - @@ -1,2 +1,4 @@ major=29 minor=0 +# note: If bumping the major, also bump major for libXft, libXfont2 +# and libfontconfig -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara - pledge update for xterm
> Unsurprisingly, xterm(1) still works for me. > > Should we just put it in? I spent a few hours reviewing as well with no conclusion. I would be in favor of committing the diff. It's easy to diagnose and fix in case we break something. I ran with this since semarie wrote, so basic functionality is guaranteed.
Re: CVS: cvs.openbsd.org: xenocara - pledge update for xterm
> Should we just put it in? > I think we are still far enough away from the 6.1 release. > If people report that some arcane feature stops working, > a decision can be made whether it should or should not work. Yes, put it in. However I'm willing to bet it will break, but there is enough time to discover that.
Re: CVS: cvs.openbsd.org: xenocara - pledge update for xterm
Hi,
Sebastien Marie wrote on Tue, Oct 25, 2016 at 08:46:10AM +0200:
> On Mon, Oct 24, 2016 at 01:31:35PM -0600, Matthieu Herrb wrote:
>> CVSROOT: /cvs
>> Module name: xenocara
>> Changes by: matth...@cvs.openbsd.org2016/10/24 13:31:35
>>
>> Modified files:
>> app/xterm : Makefile xterm.man xtermcfg.h
>>
>> Log message:
>> Disable Tektronics 4014 emulation. ok natano@, naddy@, schwarze@
> With the disabling of Tektronics emulation, the pledge(2) promises could
> be reduced a bit: no more "cpath" should be required.
>
> The commit message for 1.35 which introduced pledge(2) in xterm(1)
> stated that "cpath" was for Tek emulation window. I also reviewed
> several functions for ensuring no others use of "cpath" after pledging.
>
> Ideally, additionnal review would be welcome: xterm(1) is a big program,
> and #ifdef maze is a bit complex to follow :)
Basic review confirms that this is likely correct:
* O_CREAT is only used in misc.c,
and apart from #ifdef VMS,
only in creat_as(), which is called
- from main.c only for if_DEBUG (off by default)
- from misc.c, open_userfile, StartLog
only for #ifdef ALLOWLOGGIN (off by default)
* mk[dos]*temp(3)
is only called from misc.c,
but only for !HAVE_LIB_XCURSOR (on by default)
or from StartLog (see above)
* link, symlink, unlink, rename, mkdir, rmdir
and the *at variants are not called
* remove(3) - which may call rmdir
tmpfile(3) - which may call unlink
not called
However, i have no idea how to audit this mess:
LDADD+= -L${X11BASE}/lib -lXaw -lXpm -lXt -lSM -lICE -lXmu \
-lXft -lXrender -lXinerama -lX11 -lxcb -lXext -lXau -lXdmcp \
-lfontconfig -lexpat -lfreetype -lutil -ltermcap -lz
No doubt there are uses of link, symlink, unlink, rename, mkdir, rmdir
or O_CREAT somewhere in there, but making sure they are not reachable
from xterm(1) does not seem feasible. Personally, i wouldn't wish
that xterm(1) created, deleted or moved files or directories by
using X library interfaces - but who knows?
Unsurprisingly, xterm(1) still works for me.
Should we just put it in?
I think we are still far enough away from the 6.1 release.
If people report that some arcane feature stops working,
a decision can be made whether it should or should not work.
Yours,
Ingo
> Index: main.c
> ===
> RCS file: /cvs/xenocara/app/xterm/main.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 main.c
> --- main.c7 Aug 2016 21:27:36 - 1.39
> +++ main.c25 Oct 2016 06:41:00 -
> @@ -2634,12 +2634,12 @@ main(int argc, char *argv[]ENVP_ARG)
> if (data &&
> (strstr(data, "exec-formatted") || strstr(data,
> "exec-selectable"))) {
>
> -if (pledge("stdio rpath wpath cpath id proc exec tty", NULL) ==
> -1) {
> +if (pledge("stdio rpath wpath id proc exec tty", NULL) == -1) {
> xtermWarning("pledge\n");
> exit(1);
> }
> } else {
> -if (pledge("stdio rpath wpath cpath id proc tty", NULL) == -1) {
> +if (pledge("stdio rpath wpath id proc tty", NULL) == -1) {
> xtermWarning("pledge\n");
> exit(1);
> }
Re: CVS: cvs.openbsd.org: xenocara - pledge update for xterm
On Mon, Oct 24, 2016 at 01:31:35PM -0600, Matthieu Herrb wrote:
> CVSROOT: /cvs
> Module name: xenocara
> Changes by: matth...@cvs.openbsd.org2016/10/24 13:31:35
>
> Modified files:
> app/xterm : Makefile xterm.man xtermcfg.h
>
> Log message:
> Disable Tektronics 4014 emulation. ok natano@, naddy@, schwarze@
>
Hi,
With the disabling of Tektronics emulation, the pledge(2) promises could
be reduced a bit: no more "cpath" should be required.
The commit message for 1.35 which introduced pledge(2) in xterm(1)
stated that "cpath" was for Tek emulation window. I also reviewed
several functions for ensuring no others use of "cpath" after pledging.
Ideally, additionnal review would be welcome: xterm(1) is a big program,
and #ifdef maze is a bit complex to follow :)
Thanks.
--
Sebastien Marie
Index: main.c
===
RCS file: /cvs/xenocara/app/xterm/main.c,v
retrieving revision 1.39
diff -u -p -r1.39 main.c
--- main.c 7 Aug 2016 21:27:36 - 1.39
+++ main.c 25 Oct 2016 06:41:00 -
@@ -2634,12 +2634,12 @@ main(int argc, char *argv[]ENVP_ARG)
if (data &&
(strstr(data, "exec-formatted") || strstr(data,
"exec-selectable"))) {
-if (pledge("stdio rpath wpath cpath id proc exec tty", NULL) ==
-1) {
+if (pledge("stdio rpath wpath id proc exec tty", NULL) == -1) {
xtermWarning("pledge\n");
exit(1);
}
} else {
-if (pledge("stdio rpath wpath cpath id proc tty", NULL) == -1) {
+if (pledge("stdio rpath wpath id proc tty", NULL) == -1) {
xtermWarning("pledge\n");
exit(1);
}
