Re: [macppc] Unbreak print/pdflib
On Tue, Apr 28 2020, Charlene Wendling wrote:
> Before anything else, the version we ship is soon 18 years old. Newer
> versions seem being closed source.
I think we should remove this port. Two other ports depend on it:
- math/grace (we're at 5.1.15 from 2004, latest upstream is 5.1.25 from
2015). Use of pdflib can be disabled in the current version
with --without-pdf-library
- print/bg5pdf (no update since import in 2001)
However I suspect it would be nicer to wait after 6.7 is tagged to
discuss the fate of those ports.
> So here is the failure in the current macppc bulk:
>
>> /usr/bin/libtool --mode=compile cc -c -I/usr/local/include -DHAVE_DLFCN_H=1
>> -O2 -pipe -DPDF_PLATFORM=\""OpenBSD 6.7"\"./p_basic.c
>> cc -c -I/usr/local/include -DHAVE_DLFCN_H=1 -O2 -pipe
>> -DPDF_PLATFORM="OpenBSD 6.7" ./p_basic.c -fPIC -DPIC -o .libs/p_basic.o
>> In file included from ./p_basic.c:42:
>> In file included from ./p_intern.h:43:
>> ./p_config.h:142:9: warning: 'PDF_PLATFORM' macro redefined
>> [-Wmacro-redefined]
>> #define PDF_PLATFORM"Mac OS"
>> :2:9: note: previous definition is here
>> #define PDF_PLATFORM "OpenBSD 6.7"
>> ./p_basic.c:61:10: fatal error: 'Files.h' file not found
>> #include
>
> It appears that because ${WRKSRC}/pdflib/p_config.h assumes
> __POWERPC__ is Mac OS 9 (no endianness involved). It's breaking with
> clang because gcc does not define __POWERPC__.
>
> Instead of patching, because that ifdef is at various places, i've
> chosen to undef __POWERPC__ globally, reverting to the gcc situation.
>
> With the below diff it builds on macppc [0]. I've updated HOMEPAGE,
> the distfile is not fetchable from upstream, it's not due to that
> change.
Well in that case you might as well zap MASTER_SITES.
> Comments/feedback are welcome,
ok jca@
> Charlène.
>
>
> [0] https://bin.charlenew.xyz/macppc/paths/print/pdflib.log
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/print/pdflib/Makefile,v
> retrieving revision 1.29
> diff -u -p -u -p -r1.29 Makefile
> --- Makefile 14 Jul 2019 00:39:39 - 1.29
> +++ Makefile 28 Apr 2020 17:17:44 -
> @@ -3,15 +3,15 @@
> COMMENT= C library to produce PDF files
>
> DISTNAME=pdflib-4.0.3
> -REVISION = 5
> +REVISION = 6
> CATEGORIES= print
> SHARED_LIBS= pdf 2.3
>
> -HOMEPAGE=http://www.pdflib.com/pdflib/
> +HOMEPAGE=https://www.pdflib.com/pdflib/
>
> PERMIT_PACKAGE= Yes
>
> -MASTER_SITES=http://www.pdflib.com/pdflib/download/
> +MASTER_SITES=${HOMEPAGE}download/
>
> WANTLIB= m z jpeg png>=2 tiff>=35
>
> @@ -38,6 +38,12 @@ CONFIGURE_ENV= LDFLAGS="-L${LOCALBASE}/
> MAKE_ENV=${CONFIGURE_ENV}
>
> TEST_TARGET= test
> +
> +# In various places in the code, it's assumed that the __POWERPC__ define
> +# is Mac OS 9 specific, but our clang defines it as well, breaking the build.
> +.if ${MACHINE_ARCH:Mpowerpc}
> +CFLAGS +=-U__POWERPC__
> +.endif
>
> post-install:
> ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/pdflib
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Fix GIMP crash with x11/gtk+2 diff [Was: Re: GIMP open file crash in gimp-2.10.18p1 still exists]
Stuart Henderson writes:
> On 2020/05/01 04:30, Nam Nguyen wrote:
>> Stuart Henderson writes:
>>
>> > On 2020/04/29 15:13, Jacqueline Jolicoeur wrote:
>> >> Hi,
>> >>
>> >> I have noticed gimp-2.10.18p1 crashes everytime I try to open a file.
>> >> Removing all my GIMP cache and config files has not resolved it.
>> >>
>> >> I am aware this was posted earlier. I wanted to report that this bug
>> >> still exists as of today with the recent snapshots.
>> >
>> > We don't have any ideas yet. I haven't been able to reproduce it recently,
>> > the crash is in gtk+2 in possibly something theme-related so maybe try a
>> > different
>> > theme or try a different window manager or desktop environment and see if
>> > that
>> > makes it go away?
>> >
>> > The upstream bug is currently at
>> > https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/148
>>
>> Here is a diff for x11/gtk+2 to fix GIMP crashing. Feedback and tests
>> are welcome.
>
> awesome, thanks!
>
> Your diff makes sense to me but I would like to have input from someone
> upstream who knows the area. Could you post this to the bug on GNOME gitlab
> please? Or if you don't have / don't want to make an account do you mind if
> I post it?
Thanks. I followed up with upstream. They added my fix upstream, so I
backported it here. Here is a fresh diff with better links.
https://gitlab.gnome.org/GNOME/gtk/-/commit/fc1bd0cf2c33cd3f34cb48c2a13718a32c2d28b9
https://gitlab.gnome.org/GNOME/gtk/-/issues/2684
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
retrieving revision 1.233
diff -u -p -u -p -r1.233 Makefile
--- Makefile10 Nov 2019 21:44:07 - 1.233
+++ Makefile1 May 2020 23:18:56 -
@@ -9,7 +9,7 @@ GNOME_PROJECT= gtk+
PKGNAME-main= gtk+2-${GNOME_VERSION}
PKGNAME-cups= gtk+2-cups-${GNOME_VERSION}
-REVISION-main= 8
+REVISION-main= 9
REVISION-cups= 4
CATEGORIES=x11 devel
Index: patches/patch-modules_engines_pixbuf_pixbuf-render_c
===
RCS file: patches/patch-modules_engines_pixbuf_pixbuf-render_c
diff -N patches/patch-modules_engines_pixbuf_pixbuf-render_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-modules_engines_pixbuf_pixbuf-render_c1 May 2020
23:18:56 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+
+backport fix for graphics/gimp segfault from accessing memory past end of
pixbuf
+
+https://gitlab.gnome.org/GNOME/gtk/-/commit/fc1bd0cf2c33cd3f34cb48c2a13718a32c2d28b9
+https://gitlab.gnome.org/GNOME/gtk/-/issues/2684
+
+Index: modules/engines/pixbuf/pixbuf-render.c
+--- modules/engines/pixbuf/pixbuf-render.c.orig
modules/engines/pixbuf/pixbuf-render.c
+@@ -603,7 +603,7 @@ compute_hint (GdkPixbuf *pixbuf,
+ if (r != *(p++) ||
+ g != *(p++) ||
+ b != *(p++) ||
+-(n_channels != 4 && a != *(p++)))
++(n_channels == 4 && a != *(p++)))
+ {
+ hints &= ~THEME_CONSTANT_ROWS;
+ if (!(hints & THEME_MISSING))
回复: [NEW] www/p5-Catalyst-Action-REST
ping ... 发件人: Andrew Hewus Fresh 发送时间: 2020年1月27日 5:05 收件人: wen heping 抄送: ports@openbsd.org 主题: Re: [NEW] www/p5-Catalyst-Action-REST On Fri, Dec 20, 2019 at 06:37:07AM +, wen heping wrote: > Hi, ports@: > >Here is a patch to create www/p5-Catalyst-Action-REST, > which is required by the future update of www/p5-Catalyst-*. > It build well and pass all tests on amd64-current system. > > Comments? OK? > wen OK afresh1@
Re: [macppc] Unbreak mail/hashcash
Instead of adding a check for __OpenBSD__ change __UNIX__ to __unix__. On 5/1/2020 6:03 PM, Charlene Wendling wrote: Hi, http://build-failures.rhaalovely.net/powerpc/2020-04-09/mail/hashcash.log Because clang defines __POWERPC__ while gcc does not, it's assumed we're Mac OS [0]. Reverting to the gcc behaviour allows hashcash to be built once again. I did not bump REVISION because it has never been built since the clang switch. Comments/feedback are welcome, Charlène. [0] https://en.wikipedia.org/wiki/Gestalt_(Mac_OS) Index: patches/patch-libfastmint_c === RCS file: patches/patch-libfastmint_c diff -N patches/patch-libfastmint_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-libfastmint_c 1 May 2020 22:00:35 - @@ -0,0 +1,16 @@ +$OpenBSD$ + +OpenBSD/macppc is not Mac OS, we don't ship Gestalt. + +Index: libfastmint.c +--- libfastmint.c.orig libfastmint.c +@@ -6,7 +6,7 @@ + #include + #endif + +-#if defined(__POWERPC__) && !defined(__MACH__) && !defined(__UNIX__) && !defined(__CARBON__) ++#if defined(__POWERPC__) && !defined(__MACH__) && !defined(__OpenBSD__) && !defined(__UNIX__) && !defined(__CARBON__) + #include + #endif +
Re: CVS: cvs.openbsd.org: ports
On 2020/04/28 22:11, Jonathan Gray wrote: > CVSROOT: /cvs > Module name: ports > Changes by: j...@cvs.openbsd.org2020/04/28 22:11:29 > > Modified files: > graphics/vulkan-loader: Makefile > graphics/vulkan-loader/patches: patch-loader_CMakeLists_txt > > Log message: > backport a patch to fix build when there is no as(1) > fixes build on aarch64 > > ok phessler@ maintainer thfr@ does not have time to review but is fine > with this going in > This breaks i386: >>> Building on i386-3 under graphics/vulkan-loader BDEPENDS = [lang/python/3.7;devel/cmake;graphics/vulkan-headers;devel/ninja] DIST = [graphics/vulkan-loader:Vulkan-Loader-sdk-1.1.108.0.tar.gz] FULLPKGNAME = vulkan-loader-1.1.108.0p0 RDEPENDS = [graphics/vulkan-headers] (Junk lock failure for i386-3 at 1588370583.50357) Received IO (Junk lock obtained for i386-3 at 1588370584.55) Received IO Woken up graphics/vulkan-loader >>> Running depends in graphics/vulkan-loader at 1588370585.24 last junk was in net/ocserv /usr/sbin/pkg_add -aI -Drepair cmake-3.16.2p1v0 ninja-1.10.0 python-3.7.7 vulkan-headers-1.1.108.0p0 was: /usr/sbin/pkg_add -aI -Drepair cmake-3.16.2p1v0 ninja-1.10.0 python-3.7.7 vulkan-headers-1.1.108.0p0 /usr/sbin/pkg_add -aI -Drepair cmake-3.16.2p1v0 ninja-1.10.0 python-3.7.7 vulkan-headers-1.1.108.0p0 >>> Running show-prepare-results in graphics/vulkan-loader at 1588370598.20 ===> graphics/vulkan-loader ===> vulkan-loader-1.1.108.0p0 depends on: vulkan-headers-* -> vulkan-headers-1.1.108.0p0 ===> vulkan-loader-1.1.108.0p0 depends on: cmake-* -> cmake-3.16.2p1v0 ===> vulkan-loader-1.1.108.0p0 depends on: ninja->=1.5.1 -> ninja-1.10.0 ===> vulkan-loader-1.1.108.0p0 depends on: python->=3.7,<3.8 -> python-3.7.7 ===> Verifying specs: m pthread ===> found m.10.1 pthread.26.1 cmake-3.16.2p1v0 ninja-1.10.0 python-3.7.7 vulkan-headers-1.1.108.0p0 (Junk lock released for i386-3 at 1588370598.78) distfiles size=1342959 >>> Running build in graphics/vulkan-loader at 1588370598.81 ===> graphics/vulkan-loader ===> Checking files for vulkan-loader-1.1.108.0p0 `/mnt/distfiles/Vulkan-Loader-sdk-1.1.108.0.tar.gz' is up to date. >> (SHA256) Vulkan-Loader-sdk-1.1.108.0.tar.gz: OK ===> Extracting for vulkan-loader-1.1.108.0p0 ===> Patching for vulkan-loader-1.1.108.0p0 ===> Applying OpenBSD patch patch-CMakeLists_txt Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-CMakeLists_txt,v 1.2 2019/06/22 17:02:24 ajacoutot Exp $ | |Index: CMakeLists.txt |--- CMakeLists.txt.orig |+++ CMakeLists.txt -- Patching file CMakeLists.txt using Plan A... Hunk #1 succeeded at 77. Hunk #2 succeeded at 97. done ===> Applying OpenBSD patch patch-loader_CMakeLists_txt Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-loader_CMakeLists_txt,v 1.2 2020/04/29 04:11:29 jsg Exp $ | |Avoid vulkan-validation-layers vk_loader_platform.h being used. | |loader: move to using gcc for asm compiles on Linux. |85836796b3574fa8fa593a1da4d2a710f3467168 | |Index: loader/CMakeLists.txt |--- loader/CMakeLists.txt.orig |+++ loader/CMakeLists.txt -- Patching file loader/CMakeLists.txt using Plan A... Hunk #1 succeeded at 15. Hunk #2 succeeded at 148. Hunk #3 succeeded at 241. done ===> Applying OpenBSD patch patch-loader_loader_c Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-loader_loader_c,v 1.1.1.1 2019/06/22 15:28:42 thfr Exp $ | |revert commit ecb0b1e69fb2f4d3cae262e6da24c170ce62ae13 to attempt to |fix vulkaninfo | |Index: loader/loader.c |--- loader/loader.c.orig |+++ loader/loader.c -- Patching file loader/loader.c using Plan A... Hunk #1 succeeded at 229. Hunk #2 succeeded at 6756. done ===> Applying OpenBSD patch patch-loader_trampoline_c Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-loader_trampoline_c,v 1.1.1.1 2019/06/22 15:28:42 thfr Exp $ | |revert commit ecb0b1e69fb2f4d3cae262e6da24c170ce62ae13 to attempt to |fix vulkaninfo | |Index: loader/trampoline.c |--- loader/trampoline.c.orig |+++ loader/trampoline.c -- Patching file loader/trampoline.c using Plan A... Hunk #1 succeeded at 778. done ===> Applying OpenBSD patch patch-loader_vk_loader_platform_h Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-loader_vk_loader_platform_h,v 1.1.1.1 2019/06/22 15:28:42 thfr Exp $ | |Index: loader/vk_loader_platform.h |--- loader/vk_loader_platform.h.orig |+++ loader/vk_loader_platform.h -- Patching file loader/vk_loader_platform.h using Plan A... Hunk #1 succeeded at 31. done ===> Compiler link: clang -> /usr/bin/clang ===> Compiler
Re: [macppc] mark games/widelands NOT_FOR_ARCHS, colors are partly off
On Fri, 01 May 2020 15:46:55 -0600 Anthony J. Bentley wrote: > Charlene Wendling writes: > > On Fri, 01 May 2020 12:10:34 -0600 > > Anthony J. Bentley wrote: > > > > > Charlene Wendling writes: > > > > Hi, > > > > > > > > Some texture colors are off on powerpc, upstream thinks it's > > > > likely related to the old OpenGL versions or driver used on > > > > macppc machines[0]. It's an obvious reminder, but all OpenGL > > > > capable macppc machine are radeon(4) only. > > > > > > > > As such i'm proposing to mark it NOT_FOR_ARCHS, this saves 6 > > > > bulk machine hours. > > > > > > > > OK? > > > > > > Out of curiosity, does using software rendering look better? > > > > After a few minutes, the result is the same :) > > I'm speaking mostly from ignorance here, but this seems to suggest > that it's not about the old OpenGL version; looking at glxinfo on one > of my OpenGL 2.1 laptops, software rendering gives me OpenGL 3.3 > through llvmpipe. Even "native" and commercial Mac OS X games like postal have colors off on macppc, making things difficult to analyse as i don't know much as well, especially that i don't have Mac OS X on my macs so i can't cross test without reinstalling; i don't have a spare IDE 2.5 disk.
Re: Fix GIMP crash with x11/gtk+2 diff [Was: Re: GIMP open file crash in gimp-2.10.18p1 still exists]
On 2020/05/01 23:53, Jeremie Courreges-Anglas wrote:
> The ticket has been moved to
>
> https://gitlab.gnome.org/GNOME/gtk/-/issues/2684
>
> so the comment in the patch ought to be updated.
>
> As mentioned by Jacqueline Jolicoeur, the crash happens very often when
> running gimp with MALLOC_OPTIONS=S. With this fix in place I could not
> reproduce a crash with repeated C-o cycles.
>
> Rationale and code changes LGTM. ok jca@
Committed upstream so I've added the full comment. ok Antoine?
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
retrieving revision 1.233
diff -u -p -r1.233 Makefile
--- Makefile10 Nov 2019 21:44:07 - 1.233
+++ Makefile1 May 2020 22:23:27 -
@@ -9,7 +9,7 @@ GNOME_PROJECT= gtk+
PKGNAME-main= gtk+2-${GNOME_VERSION}
PKGNAME-cups= gtk+2-cups-${GNOME_VERSION}
-REVISION-main= 8
+REVISION-main= 9
REVISION-cups= 4
CATEGORIES=x11 devel
Index: patches/patch-modules_engines_pixbuf_pixbuf-render_c
===
RCS file: patches/patch-modules_engines_pixbuf_pixbuf-render_c
diff -N patches/patch-modules_engines_pixbuf_pixbuf-render_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-modules_engines_pixbuf_pixbuf-render_c1 May 2020
22:23:27 -
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+From d1b21ff1598cfab03e6b918edd76de766356566c Mon Sep 17 00:00:00 2001
+From: Nam Nguyen
+Date: Fri, 1 May 2020 21:55:49 +
+Subject: [PATCH] Resolve GIMP segfault from accessing memory past end of
+ pixbuf Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2684
+
+GIMP segfaults while switching themes between dark and gray and inputting
Ctrl-O
+to open a file. This is because p advances past end of pixbuf in
pixbuf-render.c
+compute_hint() with num_channels = 3 (no alpha). This is resolved by fixing the
+if statement to only check for alpha, thereby advancing p, if there is an alpha
+channel.
+
+Index: modules/engines/pixbuf/pixbuf-render.c
+--- modules/engines/pixbuf/pixbuf-render.c.orig
modules/engines/pixbuf/pixbuf-render.c
+@@ -603,7 +603,7 @@ compute_hint (GdkPixbuf *pixbuf,
+ if (r != *(p++) ||
+ g != *(p++) ||
+ b != *(p++) ||
+-(n_channels != 4 && a != *(p++)))
++(n_channels == 4 && a != *(p++)))
+ {
+ hints &= ~THEME_CONSTANT_ROWS;
+ if (!(hints & THEME_MISSING))
Re: purritobin-0.1.2 - new package + dependencies
Dear Thomas, On 5/1/20 1:08 PM, Thomas Frohwein wrote: > On Thu, Apr 30, 2020 at 11:16:06PM -0400, Aisha Tammy wrote: >> fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS >> >> attached new tar.gz >> >> OK ? > This looks like an interesting port, but with the release approaching, > it may be best to take time after 6.7 is out. Especially as upstream is > currently issuing a new release every day [1]. Probably best to let this Of course, I totally agree. I'm in no hurry to get this in just now. I'm just sending it out so that it can stay in my mail box and I don't forget about it in my git mess. > mature a little more. It also helps to attract interest in a new port by > describing a bit more what it does when you propose it; its use case, > where it may fill a need not currently met by other ports etc... Thanks a lot, I will add all this to the port DESCR and attach it with the bug fixes mentioned by Brian Callahan (thanks Brian). Aisha
[macppc] Unbreak mail/hashcash
Hi, > http://build-failures.rhaalovely.net/powerpc/2020-04-09/mail/hashcash.log Because clang defines __POWERPC__ while gcc does not, it's assumed we're Mac OS [0]. Reverting to the gcc behaviour allows hashcash to be built once again. I did not bump REVISION because it has never been built since the clang switch. Comments/feedback are welcome, Charlène. [0] https://en.wikipedia.org/wiki/Gestalt_(Mac_OS) Index: patches/patch-libfastmint_c === RCS file: patches/patch-libfastmint_c diff -N patches/patch-libfastmint_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-libfastmint_c 1 May 2020 22:00:35 - @@ -0,0 +1,16 @@ +$OpenBSD$ + +OpenBSD/macppc is not Mac OS, we don't ship Gestalt. + +Index: libfastmint.c +--- libfastmint.c.orig libfastmint.c +@@ -6,7 +6,7 @@ + #include + #endif + +-#if defined(__POWERPC__) && !defined(__MACH__) && !defined(__UNIX__) && !defined(__CARBON__) ++#if defined(__POWERPC__) && !defined(__MACH__) && !defined(__OpenBSD__) && !defined(__UNIX__) && !defined(__CARBON__) + #include + #endif +
Re: Fix GIMP crash with x11/gtk+2 diff [Was: Re: GIMP open file crash in gimp-2.10.18p1 still exists]
On Fri, May 01 2020, Stuart Henderson wrote: > On 2020/05/01 04:30, Nam Nguyen wrote: >> Stuart Henderson writes: >> >> > On 2020/04/29 15:13, Jacqueline Jolicoeur wrote: >> >> Hi, >> >> >> >> I have noticed gimp-2.10.18p1 crashes everytime I try to open a file. >> >> Removing all my GIMP cache and config files has not resolved it. >> >> >> >> I am aware this was posted earlier. I wanted to report that this bug >> >> still exists as of today with the recent snapshots. >> > >> > We don't have any ideas yet. I haven't been able to reproduce it recently, >> > the crash is in gtk+2 in possibly something theme-related so maybe try a >> > different >> > theme or try a different window manager or desktop environment and see if >> > that >> > makes it go away? >> > >> > The upstream bug is currently at >> > https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/148 >> >> Here is a diff for x11/gtk+2 to fix GIMP crashing. Feedback and tests >> are welcome. > > awesome, thanks! Lovely indeed. This is a fix for a bug introduced 18 years ago. > Your diff makes sense to me but I would like to have input from someone > upstream who knows the area. Could you post this to the bug on GNOME gitlab > please? Or if you don't have / don't want to make an account do you mind if > I post it? > > (The bug will need moving from gdk-pixbuf to gtk, hopefully someone from > upstream on the ticket can do that). The ticket has been moved to https://gitlab.gnome.org/GNOME/gtk/-/issues/2684 so the comment in the patch ought to be updated. As mentioned by Jacqueline Jolicoeur, the crash happens very often when running gimp with MALLOC_OPTIONS=S. With this fix in place I could not reproduce a crash with repeated C-o cycles. Rationale and code changes LGTM. ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Update: net/megatools 1.10.2 -> 1.10.3
On Fri, May 01, 2020 at 02:15:00PM -0600, Anthony J. Bentley wrote:
> I was holding off because of 6.7. But if it's fine with naddy/sthen,
> it's ok with me. It's a very small update in a leaf port (unlikely to
> break things) and does add significant functionality ("new-style" mega
> links that are becoming more common).
If it fixes a core functionality of the package, especially if it is
such a leaf port, by all means: put this into 6.7 so that releaes won't
ship a broken tool.
OK kn
Re: [macppc] mark games/widelands NOT_FOR_ARCHS, colors are partly off
Charlene Wendling writes: > On Fri, 01 May 2020 12:10:34 -0600 > Anthony J. Bentley wrote: > > > Charlene Wendling writes: > > > Hi, > > > > > > Some texture colors are off on powerpc, upstream thinks it's likely > > > related to the old OpenGL versions or driver used on macppc > > > machines[0]. It's an obvious reminder, but all OpenGL capable > > > macppc machine are radeon(4) only. > > > > > > As such i'm proposing to mark it NOT_FOR_ARCHS, this saves 6 bulk > > > machine hours. > > > > > > OK? > > > > Out of curiosity, does using software rendering look better? > > After a few minutes, the result is the same :) I'm speaking mostly from ignorance here, but this seems to suggest that it's not about the old OpenGL version; looking at glxinfo on one of my OpenGL 2.1 laptops, software rendering gives me OpenGL 3.3 through llvmpipe.
[macppc, !x86] Unbreak emulators/gsplus
Hi,
> http://build-failures.rhaalovely.net/powerpc/2020-04-09/emulators/gsplus.log
`__builtin_ppc_mftb()' is not available with clang.
An easy solution would have been to change the ifdef, but as this is
the same situation with retroarch [0], i preferred to use their logic.
On top of that it should slightly improve the emulation on !{x86,ppc}.
I don't know why upstream chose to #define a builtin, so it can't be
applied on archs where it is native (x86). The intent of this patch is
to be upstreamed so i preferred to stay minimal.
This allows gsplus to be built on macppc, i can run System 6 without
issues, excepted mouse clicks that don't register. The only other arch
i have is amd64, where this diff makes no change.
Comments/feedback are welcome,
Charlène.
[0] https://marc.info/?l=openbsd-ports-cvs=158816954508000=2
Index: Makefile
===
RCS file: /cvs/ports/emulators/gsplus/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 Makefile
--- Makefile12 Mar 2020 12:24:08 - 1.1.1.1
+++ Makefile1 May 2020 21:36:37 -
@@ -6,6 +6,7 @@ GH_ACCOUNT =digarok
GH_PROJECT = gsplus
GH_COMMIT =480572054518112647c8fae5d7ea7046a6d6ecfb
DISTNAME = ${GH_PROJECT}-20190816
+REVISION = 0
CATEGORIES = emulators
Index: patches/patch-src_engine_c_c
===
RCS file: patches/patch-src_engine_c_c
diff -N patches/patch-src_engine_c_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_engine_c_c1 May 2020 21:36:37 -
@@ -0,0 +1,24 @@
+$OpenBSD$
+
+Use posix timing to improve portability and avoid a build failure on
+powerpc due to `__builtin_ppc_mftb' being gcc-specific.
+
+Index: src/engine_c.c
+--- src/engine_c.c.orig
src/engine_c.c
+@@ -884,6 +884,15 @@ void fixed_memory_ptrs_shut() {
+
+ #if defined(__i386__) || defined(__x86_64__)
+ #include
++ #elif defined(_POSIX_MONOTONIC_CLOCK)
++#include
++int64_t __rdtsc() {
++ struct timespec tp = {0};
++ int64_t timestamp = 0;
++ if (clock_gettime(CLOCK_MONOTONIC, ) == 0)
++timestamp = tp.tv_sec * 10 + tp.tv_nsec;
++ return timestamp;
++}
+ #elif defined(__powerpc__) || defined(__ppc__)
+ #define __rdtsc() __builtin_ppc_mftb()
+ #else
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2020/05/01 15:17:03 Modified files: games/widelands: Makefile Log message: widelands: add powerpc to NOT_FOR_ARCHS Some texture colors are off on powerpc, upstream thinks it's likely related to the old OpenGL versions or driver used on macppc machines. OK bentley@
Re: [macppc] mark games/widelands NOT_FOR_ARCHS, colors are partly off
On Fri, 01 May 2020 12:10:34 -0600 Anthony J. Bentley wrote: > Charlene Wendling writes: > > Hi, > > > > Some texture colors are off on powerpc, upstream thinks it's likely > > related to the old OpenGL versions or driver used on macppc > > machines[0]. It's an obvious reminder, but all OpenGL capable > > macppc machine are radeon(4) only. > > > > As such i'm proposing to mark it NOT_FOR_ARCHS, this saves 6 bulk > > machine hours. > > > > OK? > > Out of curiosity, does using software rendering look better? After a few minutes, the result is the same :) > But obviously that's no solution, so ok bentley@. >
Re: [UPDATE] lang/nim-1.2.0
From: Denis Fondras
Date: Mon, 13 Apr 2020 17:40:15 +
To: openbsd-ports
Subject: Re: [UPDATE] lang/nim-1.2.0
On Mon, Apr 13, 2020 at 11:07:27AM -0600, j...@bitminer.ca wrote:
Denis, the PLIST file does most of this work, just adjust it to add
nimble,
the directory ${SYSCONFDIR}/nim and modify the cfg entries to add the
/nim/
directory in their path. And lose the manual copies from the Makefile.
Here is an updated diff :
This diff works for me. Hopefully it can be added prior to the ports
freeze (there are no ports depending on nim).
John
Re: Update: net/megatools 1.10.2 -> 1.10.3
Kurt Mosiejczuk writes:
> Came across a couple mega links that megatools said weren't valid. They
> did work in the browser though. So I looked and saw that there was a
> new release in the past 2 weeks.
>
> This release works with the problematic links. Tested on amd64.
>
> (cc maintainer)
>
> ok?
I was holding off because of 6.7. But if it's fine with naddy/sthen,
it's ok with me. It's a very small update in a leaf port (unlikely to
break things) and does add significant functionality ("new-style" mega
links that are becoming more common).
Update: net/megatools 1.10.2 -> 1.10.3
Came across a couple mega links that megatools said weren't valid. They did work in the browser though. So I looked and saw that there was a new release in the past 2 weeks. This release works with the problematic links. Tested on amd64. (cc maintainer) ok? --Kurt Index: Makefile === RCS file: /cvs/ports/net/megatools/Makefile,v retrieving revision 1.19 diff -u -p -r1.19 Makefile --- Makefile12 Jul 2019 20:48:32 - 1.19 +++ Makefile1 May 2020 20:06:28 - @@ -4,8 +4,7 @@ PORTROACH = limit:[0-9]\.tar\.gz COMMENT = command line client application for Mega -DISTNAME = megatools-1.10.2 -REVISION = 2 +DISTNAME = megatools-1.10.3 CATEGORIES = net Index: distinfo === RCS file: /cvs/ports/net/megatools/distinfo,v retrieving revision 1.6 diff -u -p -r1.6 distinfo --- distinfo8 Sep 2018 21:50:08 - 1.6 +++ distinfo1 May 2020 20:06:28 - @@ -1,2 +1,2 @@ -SHA256 (megatools-1.10.2.tar.gz) = F56Exo4kaWwXEjinK8/l4oGY5MTp+QQ3BPNuXAsXw4o= -SIZE (megatools-1.10.2.tar.gz) = 300486 +SHA256 (megatools-1.10.3.tar.gz) = jcHKNIYz/UnefrgysyPo3ClfHFWu+0hNMOZHUhhVi9s= +SIZE (megatools-1.10.3.tar.gz) = 196361
Re: [macppc] mark games/widelands NOT_FOR_ARCHS, colors are partly off
Charlene Wendling writes: > Hi, > > Some texture colors are off on powerpc, upstream thinks it's likely > related to the old OpenGL versions or driver used on macppc machines[0]. > It's an obvious reminder, but all OpenGL capable macppc machine are > radeon(4) only. > > As such i'm proposing to mark it NOT_FOR_ARCHS, this saves 6 bulk > machine hours. > > OK? Out of curiosity, does using software rendering look better? But obviously that's no solution, so ok bentley@.
Re: purritobin-0.1.2 - new package + dependencies
On Thu, Apr 30, 2020 at 11:16:06PM -0400, Aisha Tammy wrote: > fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS > > attached new tar.gz > > OK ? This looks like an interesting port, but with the release approaching, it may be best to take time after 6.7 is out. Especially as upstream is currently issuing a new release every day [1]. Probably best to let this mature a little more. It also helps to attract interest in a new port by describing a bit more what it does when you propose it; its use case, where it may fill a need not currently met by other ports etc...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/05/01 08:06:44 Modified files: security/vault : Makefile distinfo security/vault/files: vault.hcl security/vault/pkg: PLIST vault.rc Added files: security/vault/patches: patch-builtin_logical_ssh_path_sign_go security/vault/pkg: README Log message: Update vault 1.4.0 -> 1.4.1 Changelog: https://github.com/hashicorp/vault/blob/master/CHANGELOG.md Port changes: * Vault config moved to /etc/vault/vault.hcl * Added default config with internal Raft storage * Add patch for signing SSH keys using rsa-sha2-256 algorithm * Add locations for vault db/plugins/logs * Use logger for Vault server logging to /var/log/vault/vault.log * Add pkg README ok ajacoutot@
Re: Fix GIMP crash with x11/gtk+2 diff [Was: Re: GIMP open file crash in gimp-2.10.18p1 still exists]
On May 01 04:30, Nam Nguyen wrote: > As others have reported, this was hard to reproduce. I just remembered I have been running my OpenBSD 6.7-beta with: $ sysctl vm.malloc_conf=S Thanks for the patch.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/05/01 07:56:30 ports/security/vault/patches Update of /cvs/ports/security/vault/patches In directory cvs.openbsd.org:/tmp/cvs-serv38534/patches Log Message: Directory /cvs/ports/security/vault/patches added to the repository
Re: [UPDATE]: games/freeorion 0.49
Hi, Any update on this? Can it be committed? (I am the maintainer) I believe the memory issues for compiling are just that ulimit -d needs to be increased to allow it to compile. Thanks, Tom
Re: [UPDATE] games/ezquake 3.2
Hi, Any update on this? Can it be committed? (I am the maintainer) Thanks, Tom
回复: [NEW] www/p5-Plack-Middleware-MethodOverride
发件人: Andrew Hewus Fresh 发送时间: 2020年1月27日 6:28 收件人: wen heping 抄送: ports@openbsd.org 主题: Re: [NEW] www/p5-Plack-Middleware-MethodOverride On Fri, Dec 20, 2019 at 02:24:13AM +, wen heping wrote: > Hi, ports@: > >Here is a patch to create www/p5-Plack-Middleware-MethodOverride, > which is required by the future update of www/p5-Catalyst-*. > It build well and pass all tests on amd64-current system. > > Comments? OK? > wen OK afresh1@
回复: [NEW] www/p5-Plack-Middleware-MethodOverride
ping ... 发件人: Andrew Hewus Fresh 发送时间: 2020年1月27日 6:28 收件人: wen heping 抄送: ports@openbsd.org 主题: Re: [NEW] www/p5-Plack-Middleware-MethodOverride On Fri, Dec 20, 2019 at 02:24:13AM +, wen heping wrote: > Hi, ports@: > >Here is a patch to create www/p5-Plack-Middleware-MethodOverride, > which is required by the future update of www/p5-Catalyst-*. > It build well and pass all tests on amd64-current system. > > Comments? OK? > wen OK afresh1@
Re: Fix GIMP crash with x11/gtk+2 diff [Was: Re: GIMP open file crash in gimp-2.10.18p1 still exists]
On 2020/05/01 04:30, Nam Nguyen wrote:
> Stuart Henderson writes:
>
> > On 2020/04/29 15:13, Jacqueline Jolicoeur wrote:
> >> Hi,
> >>
> >> I have noticed gimp-2.10.18p1 crashes everytime I try to open a file.
> >> Removing all my GIMP cache and config files has not resolved it.
> >>
> >> I am aware this was posted earlier. I wanted to report that this bug still
> >> exists as of today with the recent snapshots.
> >
> > We don't have any ideas yet. I haven't been able to reproduce it recently,
> > the crash is in gtk+2 in possibly something theme-related so maybe try a
> > different
> > theme or try a different window manager or desktop environment and see if
> > that
> > makes it go away?
> >
> > The upstream bug is currently at
> > https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/148
>
> Here is a diff for x11/gtk+2 to fix GIMP crashing. Feedback and tests
> are welcome.
awesome, thanks!
Your diff makes sense to me but I would like to have input from someone
upstream who knows the area. Could you post this to the bug on GNOME gitlab
please? Or if you don't have / don't want to make an account do you mind if
I post it?
(The bug will need moving from gdk-pixbuf to gtk, hopefully someone from
upstream on the ticket can do that).
> "Image Data" and "Example 1. put_pixel() example" were useful.
>
> https://developer.gimp.org/api/2.0/gdk-pixbuf/gdk-pixbuf-gdk-pixbuf.html
>
> Example 1 was very similar to the code in pixbuf-render.c's compute_hint
> function.
>
> https://marc.info/?l=openbsd-ports=157538140605480=2
>
> I got the same stacktrace as brynet@ posted here. (x0=23, x1=24, y0=31,
> y1=32.) Some stuff was optimized out but I got it to print by going back
> to earlier stack frames or by slightly modifying the code with a fix
> that didn't work (that's how I got num_channels = 3).
>
> Given these values of x0, x1, y0, y1 and num_channels it seems like it
> goes beyond the end of the pixbuf buffer. It was going out of bounds on
> (n_channels != 4 && a != *(p++)) according to gdb. If anything,
> num_channels being 3 with my change prevents it from advancing the p
> pointer too far.
>
> RGBA each has a byte for red, green, blue and alpha. In this case,
> num_channels = 3 so there is no alpha channel.
>
> Each row looks like this with possible padding at the end:
> RGBARGBA...
> In this case there is no alpha either so it could look like:
> RGBRGB...
>
> rowstride = 72 in this case so there are 72 bytes in each row
>
> if (r != *(p++) ||
> g != *(p++) ||
> b != *(p++) ||
> (n_channels != 4 && a != *(p++)))
>
> p is positioned to where it wants to compute hints like
> THEME_CONSTANT_ROWS. I infer that THEME_CONSTANT_ROWS means r = g = b
> like the grey theme that crashes. The first 2 lines should be sufficient
> to check r = g = b, so I think that even the last two lines with b and
> n_channels can be removed. Although, I don't know the exact meaning of
> THEME_CONSTANT_ROWS and how alpha affects it so this could be something
> to ask upstream.
>
> The last line currently reads: if there is no alpha channel and alpha is
> not equal to X (where X is RGBAX) then the theme has a false bit for
> THEME_CONSTANT_ROWS.
>
> I think this is incorrect and should say if there _is_ an alpha channel.
>
> Testing
> ===
> As others have reported, this was hard to reproduce.
>
> To test keep spamming this loop until it crashes. It crashes randomly
> but within the first ~10 tries on the current version of gtk+2.
>
> Edit > Preferences > Themes > Grey
> Ctrl-O for open file prompt
> Escape to close
> Edit > Preferences > Themes > Dark
> Ctrl-O for open file prompt
> Escape to close
>
> With this patch it no longer crashes in my testing.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/gtk+2/Makefile,v
> retrieving revision 1.233
> diff -u -p -u -p -r1.233 Makefile
> --- Makefile 10 Nov 2019 21:44:07 - 1.233
> +++ Makefile 1 May 2020 10:30:50 -
> @@ -9,7 +9,7 @@ GNOME_PROJECT=gtk+
> PKGNAME-main=gtk+2-${GNOME_VERSION}
> PKGNAME-cups=gtk+2-cups-${GNOME_VERSION}
>
> -REVISION-main= 8
> +REVISION-main= 9
> REVISION-cups= 4
>
> CATEGORIES= x11 devel
> Index: patches/patch-modules_engines_pixbuf_pixbuf-render_c
> ===
> RCS file: patches/patch-modules_engines_pixbuf_pixbuf-render_c
> diff -N patches/patch-modules_engines_pixbuf_pixbuf-render_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-modules_engines_pixbuf_pixbuf-render_c 1 May 2020
> 10:30:50 -
> @@ -0,0 +1,18 @@
> +$OpenBSD$
> +
> +fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/148
> +
> +only check for alpha if there is an alpha channel
> +
> +Index: modules/engines/pixbuf/pixbuf-render.c
> +--- modules/engines/pixbuf/pixbuf-render.c.orig
>
Fix GIMP crash with x11/gtk+2 diff [Was: Re: GIMP open file crash in gimp-2.10.18p1 still exists]
Stuart Henderson writes:
> On 2020/04/29 15:13, Jacqueline Jolicoeur wrote:
>> Hi,
>>
>> I have noticed gimp-2.10.18p1 crashes everytime I try to open a file.
>> Removing all my GIMP cache and config files has not resolved it.
>>
>> I am aware this was posted earlier. I wanted to report that this bug still
>> exists as of today with the recent snapshots.
>
> We don't have any ideas yet. I haven't been able to reproduce it recently,
> the crash is in gtk+2 in possibly something theme-related so maybe try a
> different
> theme or try a different window manager or desktop environment and see if that
> makes it go away?
>
> The upstream bug is currently at
> https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/148
Here is a diff for x11/gtk+2 to fix GIMP crashing. Feedback and tests
are welcome.
"Image Data" and "Example 1. put_pixel() example" were useful.
https://developer.gimp.org/api/2.0/gdk-pixbuf/gdk-pixbuf-gdk-pixbuf.html
Example 1 was very similar to the code in pixbuf-render.c's compute_hint
function.
https://marc.info/?l=openbsd-ports=157538140605480=2
I got the same stacktrace as brynet@ posted here. (x0=23, x1=24, y0=31,
y1=32.) Some stuff was optimized out but I got it to print by going back
to earlier stack frames or by slightly modifying the code with a fix
that didn't work (that's how I got num_channels = 3).
Given these values of x0, x1, y0, y1 and num_channels it seems like it
goes beyond the end of the pixbuf buffer. It was going out of bounds on
(n_channels != 4 && a != *(p++)) according to gdb. If anything,
num_channels being 3 with my change prevents it from advancing the p
pointer too far.
RGBA each has a byte for red, green, blue and alpha. In this case,
num_channels = 3 so there is no alpha channel.
Each row looks like this with possible padding at the end:
RGBARGBA...
In this case there is no alpha either so it could look like:
RGBRGB...
rowstride = 72 in this case so there are 72 bytes in each row
if (r != *(p++) ||
g != *(p++) ||
b != *(p++) ||
(n_channels != 4 && a != *(p++)))
p is positioned to where it wants to compute hints like
THEME_CONSTANT_ROWS. I infer that THEME_CONSTANT_ROWS means r = g = b
like the grey theme that crashes. The first 2 lines should be sufficient
to check r = g = b, so I think that even the last two lines with b and
n_channels can be removed. Although, I don't know the exact meaning of
THEME_CONSTANT_ROWS and how alpha affects it so this could be something
to ask upstream.
The last line currently reads: if there is no alpha channel and alpha is
not equal to X (where X is RGBAX) then the theme has a false bit for
THEME_CONSTANT_ROWS.
I think this is incorrect and should say if there _is_ an alpha channel.
Testing
===
As others have reported, this was hard to reproduce.
To test keep spamming this loop until it crashes. It crashes randomly
but within the first ~10 tries on the current version of gtk+2.
Edit > Preferences > Themes > Grey
Ctrl-O for open file prompt
Escape to close
Edit > Preferences > Themes > Dark
Ctrl-O for open file prompt
Escape to close
With this patch it no longer crashes in my testing.
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
retrieving revision 1.233
diff -u -p -u -p -r1.233 Makefile
--- Makefile10 Nov 2019 21:44:07 - 1.233
+++ Makefile1 May 2020 10:30:50 -
@@ -9,7 +9,7 @@ GNOME_PROJECT= gtk+
PKGNAME-main= gtk+2-${GNOME_VERSION}
PKGNAME-cups= gtk+2-cups-${GNOME_VERSION}
-REVISION-main= 8
+REVISION-main= 9
REVISION-cups= 4
CATEGORIES=x11 devel
Index: patches/patch-modules_engines_pixbuf_pixbuf-render_c
===
RCS file: patches/patch-modules_engines_pixbuf_pixbuf-render_c
diff -N patches/patch-modules_engines_pixbuf_pixbuf-render_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-modules_engines_pixbuf_pixbuf-render_c1 May 2020
10:30:50 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/148
+
+only check for alpha if there is an alpha channel
+
+Index: modules/engines/pixbuf/pixbuf-render.c
+--- modules/engines/pixbuf/pixbuf-render.c.orig
modules/engines/pixbuf/pixbuf-render.c
+@@ -603,7 +603,7 @@ compute_hint (GdkPixbuf *pixbuf,
+ if (r != *(p++) ||
+ g != *(p++) ||
+ b != *(p++) ||
+-(n_channels != 4 && a != *(p++)))
++(n_channels == 4 && a != *(p++)))
+ {
+ hints &= ~THEME_CONSTANT_ROWS;
+ if (!(hints & THEME_MISSING))
[macppc] mark games/widelands NOT_FOR_ARCHS, colors are partly off
Hi, Some texture colors are off on powerpc, upstream thinks it's likely related to the old OpenGL versions or driver used on macppc machines[0]. It's an obvious reminder, but all OpenGL capable macppc machine are radeon(4) only. As such i'm proposing to mark it NOT_FOR_ARCHS, this saves 6 bulk machine hours. OK? Charlène. [0] https://github.com/widelands/widelands/issues/3887 Index: Makefile === RCS file: /cvs/ports/games/widelands/Makefile,v retrieving revision 1.28 diff -u -p -u -p -r1.28 Makefile --- Makefile9 Sep 2019 04:42:10 - 1.28 +++ Makefile1 May 2020 10:44:41 - @@ -1,5 +1,8 @@ # $OpenBSD: Makefile,v 1.28 2019/09/09 04:42:10 rsadowski Exp $ +# See https://github.com/widelands/widelands/issues/3887 +NOT_FOR_ARCHS =powerpc + COMMENT= economic and military simulation game V =20
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/05/01 04:20:17 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Register salt CVE quirk On behalf of robert
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2020/05/01 04:13:59 Modified files: graphics/krita : Makefile Log message: krita: mark BROKEN-powerpc It is unuseable as-is on powerpc, colors are off, and even "corrupts" KDE widgets colors. Marking it BROKEN saves 28 machine hours during the bulk. OK sthen@ and rsadowski@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/05/01 03:09:14 Modified files: mail/alpine: Makefile Added files: mail/alpine/patches: patch-imap_src_osdep_unix_ssl_unix_c Log message: Add workarounds to fix alpine with TLSv1.3 Servers enforcing that clients send an SNI become more common. Backport the mechanism for sending SNI from alpine 2.22. Our new TLSv1.3 stack requires more retries than the old one so retry SSL_write() if the API tells us to do so. Issue reported, fix tested and "ok" procter. ok jca sthen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/05/01 02:01:08 Modified files: sysutils/salt : Makefile Added files: sysutils/salt/patches: patch-salt_master_py patch-salt_tokens_localfs_py patch-salt_utils_verify_py patch-salt_wheel_config_py patch-salt_wheel_file_roots_py Log message: backport patches for two security issues: commit f47e4856497231eb672da2ce0df3e641581d47e6 Author: Daniel A. Wozniak Date: Mon Apr 13 06:41:04 2020 + Fix CVE-2020-11651 Resolve issue which allows access to un-intended methods in the ClearFuncs class of the salt-master process commit 7bd0ab195fbec4f34523dad11149f741c154e2b7 Author: Daniel A. Wozniak Date: Mon Apr 13 06:44:58 2020 + Fix CVE-2020-11652 Sanitize paths in ClearFuncs methods provided by salt-master. This ensures we do not allow access to un-intended files and directories. ok sthen@, jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/05/01 01:36:37 Modified files: sysutils/awscli: Makefile distinfo Log message: Update to awscli-1.18.50.
sparc64 bulk build report
Bulk build on sparc64-0.ports.openbsd.org Started : Wed Apr 29 11:21:53 MDT 2020 Finished: Fri May 1 01:34:07 MDT 2020 Duration: 1 Days 14 hours 12 minutes Built using OpenBSD 6.7-beta (GENERIC.MP) #298: Wed Apr 29 05:04:57 MDT 2020 Built 8838 packages Number of packages built each day: Apr 29: 6852 Apr 30: 1969 May 1: 17 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2020-04-29/summary.log Build failures: 295 http://build-failures.rhaalovely.net/sparc64/2020-04-29/graphics/libavif.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/lang/hashlink.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/net/gnugk.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/textproc/apertium-dicts/id-ms.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/www/tomcat/v9.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/www/webkitgtk4.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gigolo.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/autoar.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/baobab.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/bijiben.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/books.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/builder.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/calculator.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/calendar.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/characters.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/clocks.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/color-manager.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/contacts.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/control-center.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/dconf-editor.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/desktop.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/devhelp.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/dictionary.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/documents.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/eog.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/file-roller.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/font-viewer.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/gdl.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/gdm.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/gedit.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/grilo.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/grilo-plugins.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/gucharmap.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/gvfs,,-goa.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/initial-setup.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/keyring.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/libgnome.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/libgnomecanvas.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/libgnomeui.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/libgweather.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/maps.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/music.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/mutter.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/nautilus.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/online-accounts.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/online-miners.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/orca.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/photos.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/screenshot.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/session.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/settings-daemon.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/shell.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/sushi.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/system-monitor.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/terminal.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/themes-extra.log http://build-failures.rhaalovely.net/sparc64/2020-04-29/x11/gnome/todo.log
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/05/01 01:35:33 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py3-botocore-1.16.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/05/01 01:35:43 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py3-boto3-1.13.0.
Re: purritobin-0.1.2 - new package + dependencies
fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS attached new tar.gz OK ? Aisha On 4/30/20 2:44 PM, Aisha Tammy wrote: > Updated to latest 0.1.3 and attached. > > On 4/30/20 8:05 AM, Aisha Tammy wrote: >> Hey All, >> I am adding a new package with its 2 dependencies, so a total >> of 3 new packages. >> >> Tested on amd64 and arm64, currently hosted at https://bsd.ac . >> None of the code is platform specific so should be working on all. >> >> comments? OK? >> >> Aisha >> purritobin-0.1.3.tar.gz Description: application/gzip
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/05/01 01:13:46 Modified files: x11/gnome/mutter: Makefile distinfo Removed files: x11/gnome/mutter/patches: patch-src_compositor_compositor_c Log message: bugfix update to mutter-3.34.6
Re: GIMP open file crash in gimp-2.10.18p1 still exists
I understand the workaround now. By default GIMP uses the "Dark" theme /usr/local/share/gimp/2.0/themes/Dark Menu -> Edit -> Preferences -> Interface -> Theme Select "System" /usr/local/share/gimp/2.0/themes/System That resolves the crash for me. Thanks.
Re: GIMP open file crash in gimp-2.10.18p1 still exists
On Apr 30 18:15, Stuart Henderson wrote: > We don't have any ideas yet. I haven't been able to reproduce it recently, > the crash is in gtk+2 in possibly something theme-related so maybe try a > different > theme or try a different window manager or desktop environment and see if that > makes it go away? I created a new default user via adduser, logged into X (fvwm) using the new user, ran gimp from xterm, pressed CTRL+O and made gimp crash. My sysclean output is free of old files, and I've just successfully run pkg_check without errors. I am able to run gtk-demo, choose the "Pickers" and select a file without issue. Not sure if this info helps. Thanks for your efforts. Currently running (updated today): kern.version=OpenBSD 6.7-beta (GENERIC.MP) #167: Thu Apr 30 17:55:56 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP gimp-2.10.18p1 gtk+2-2.24.32p8
