Extend README for miniupnpd with NAT-PMP
Hi,
I've added a few extra lines for the miniupnpd port for an easier
experience with setting up port forwarding. It took me quite a while
to figure out this small thing, so I personally think it would be
useful for newer users like myself.
Cheers,
Aisha
diff --git a/net/miniupnp/miniupnpd/pkg/README
b/net/miniupnp/miniupnpd/pkg/README
index d499602bdde..94725f0340e 100644
--- a/net/miniupnp/miniupnpd/pkg/README
+++ b/net/miniupnp/miniupnpd/pkg/README
@@ -9,6 +9,11 @@ needs to be generated for the gateway and "uuid=" set
accordingly in
${SYSCONFDIR}/miniupnpd.conf. To do so, either uuid(1) from the uuid
package or uuidgen(1) from the e2fsprogs package can be used.
+Many torrent programs use NAT-PMP to request for a forwarded port, which
+needs to be enabled in the config file. NAT-PMP listens on port 5351,
+which should be allowed on the internal interfaces:
+pass in on $internal_interface proto udp to port 5351
+
Then the following pf(4) anchor needs to be added to pf.conf(5):
anchor "miniupnpd"
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/09/14 23:16:24 Modified files: multimedia/mpv : Makefile Log message: Disable the sndio backend again Too many errors have been reported with it. Leave the backend in for anyone else that might want to look at the code and work on it. >From Brad
Re: lang/ghc
Matthias Kilian writes:
> New diff, where I only changed the debug stuff (and introduced a
> new typedef for it).
Your change is OK by me.
> The reason I didn't touch the other message
> printing functions is that they call printf(3)-like functions several
> times and don't do any error checking at all, and it's not clear
> what to do with those functions.
One step at a time sounds good to me.
> Fortunately, changing vdebugBelch() / debugMsgFn, rtsDebugMsgFn()
> are enough to kill the %n, and rtsDebugMsgFn() calls vfprintf(3) only
> once, so it's easy to let rtsDebugMsgFn() return the result of
> vfprintf(3).
>
> If upstream is interested, the next thing would be to remove those
> (unnecessary) indirections via function pointers.
Sure, might as well discuss this with them while landing your patch.
Thanks
Greg
>
> Ciao,
> Kili
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ghc/Makefile,v
> retrieving revision 1.188
> diff -u -p -r1.188 Makefile
> --- Makefile 16 Aug 2021 21:23:18 - 1.188
> +++ Makefile 12 Sep 2021 19:40:01 -
> @@ -19,6 +19,8 @@ DISTNAME = ghc-${GHC_VERSION}
> CATEGORIES = lang devel
> HOMEPAGE = https://www.haskell.org/ghc/
>
> +REVISION = 0
> +
> # Version of the precompiled binaries
> BIN_VER =8.10.3.20210429
>
> Index: patches/patch-includes_rts_Messages_h
> ===
> RCS file: patches/patch-includes_rts_Messages_h
> diff -N patches/patch-includes_rts_Messages_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-includes_rts_Messages_h 12 Sep 2021 19:40:01 -
> @@ -0,0 +1,34 @@
> +$OpenBSD$
> +
> +The debug message function has to return the number of bytes written
> +(like printf(3)), to allow killing a %n format specifier in one in
> +one invocation of statsPrintf() in report_summary() (rts/Stats.c).
> +
> +Index: includes/rts/Messages.h
> +--- includes/rts/Messages.h.orig
> includes/rts/Messages.h
> +@@ -85,20 +85,21 @@ void vsysErrorBelch(const char *s, va_list ap);
> + void debugBelch(const char *s, ...)
> +GNUC3_ATTRIBUTE(format (PRINTF, 1, 2));
> +
> +-void vdebugBelch(const char *s, va_list ap);
> ++int vdebugBelch(const char *s, va_list ap);
> +
> +
> + /* Hooks for redirecting message generation: */
> +
> + typedef void RtsMsgFunction(const char *, va_list);
> ++typedef int RtsMsgFunctionRetLen(const char *, va_list);
> +
> + extern RtsMsgFunction *fatalInternalErrorFn;
> +-extern RtsMsgFunction *debugMsgFn;
> ++extern RtsMsgFunctionRetLen *debugMsgFn;
> + extern RtsMsgFunction *errorMsgFn;
> +
> + /* Default stdio implementation of the message hooks: */
> +
> + extern RtsMsgFunction rtsFatalInternalErrorFn;
> +-extern RtsMsgFunction rtsDebugMsgFn;
> ++extern RtsMsgFunctionRetLen rtsDebugMsgFn;
> + extern RtsMsgFunction rtsErrorMsgFn;
> + extern RtsMsgFunction rtsSysErrorMsgFn;
> Index: patches/patch-rts_RtsMessages_c
> ===
> RCS file: patches/patch-rts_RtsMessages_c
> diff -N patches/patch-rts_RtsMessages_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-rts_RtsMessages_c 12 Sep 2021 19:40:01 -
> @@ -0,0 +1,65 @@
> +$OpenBSD$
> +
> +The debug message function has to return the number of bytes written
> +(like printf(3)), to allow killing a %n format specifier in one in
> +one invocation of statsPrintf() in report_summary() (rts/Stats.c).
> +
> +Index: rts/RtsMessages.c
> +--- rts/RtsMessages.c.orig
> rts/RtsMessages.c
> +@@ -36,7 +36,7 @@
> +
> + // Default to the stdio implementation of these hooks.
> + RtsMsgFunction *fatalInternalErrorFn = rtsFatalInternalErrorFn;
> +-RtsMsgFunction *debugMsgFn = rtsDebugMsgFn;
> ++RtsMsgFunctionRetLen *debugMsgFn = rtsDebugMsgFn;
> + RtsMsgFunction *errorMsgFn = rtsErrorMsgFn;
> + RtsMsgFunction *sysErrorMsgFn= rtsSysErrorMsgFn;
> +
> +@@ -102,10 +102,10 @@ debugBelch(const char*s, ...)
> + va_end(ap);
> + }
> +
> +-void
> ++int
> + vdebugBelch(const char*s, va_list ap)
> + {
> +- (*debugMsgFn)(s,ap);
> ++ return (*debugMsgFn)(s,ap);
> + }
> +
> + /*
> -
> +@@ -285,16 +285,16 @@ rtsSysErrorMsgFn(const char *s, va_list ap)
> + #endif
> + }
> +
> +-void
> ++int
> + rtsDebugMsgFn(const char *s, va_list ap)
> + {
> ++ int r;
> + #if defined(mingw32_HOST_OS)
> + /* Ensure we're in text mode so newlines get encoded properly. */
> + int mode = _setmode (_fileno(stderr), _O_TEXT);
> + if (isGUIApp())
> + {
> + char buf[BUFSIZE];
> +- int r;
> +
> + r = vsnprintf(buf, BUFSIZE, s, ap);
> + if (r > 0 && r < BUFSIZE) {
> +@@ -305,12 +305,13 @@ rtsDebugMsgFn(const char *s, va_list ap)
> + #endif
> + {
> + /* don't fflush(stdout); WORKAROUND bug in
Re: [update] chafa 1.8.0
Hi,
this is an revised update for chafa to 1.8.0.
Changes are listed here[1].
Port-wise I've bumped SHARED_LIBS and added pkg/README to mention
ffmpeg for extra format support. This will result in a leaner port as
submitted before.
Some additions to WANTLIB and removed fftw3.7.
Some testing done on amd64 + i386 via ssh and X11 with xterm and st.
No issues found.
Tests on big endian architectures welcome.
portcheck, 'make lib-depends-check' and 'make test' are happy.
Comments? OK?
Thanks!
[1] https://github.com/hpjansson/chafa/blob/master/NEWS
Index: Makefile
===
RCS file: /cvs/ports/graphics/chafa/Makefile,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 Makefile
--- Makefile19 Jun 2021 11:35:54 - 1.4
+++ Makefile14 Sep 2021 20:09:06 -
@@ -1,9 +1,9 @@
# $OpenBSD: Makefile,v 1.4 2021/06/19 11:35:54 sthen Exp $
COMMENT = character art facsimile generator
-DISTNAME = chafa-1.6.1
+DISTNAME = chafa-1.8.0
-SHARED_LIBS += chafa 1.0 # 5.0
+SHARED_LIBS += chafa 2.0 # 1.0
CATEGORIES = graphics
@@ -15,10 +15,10 @@ MAINTAINER =Florian Viehweger https://hpjansson.org/chafa/releases/
EXTRACT_SUFX = .tar.xz
Index: distinfo
===
RCS file: /cvs/ports/graphics/chafa/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo19 Jun 2021 11:35:54 - 1.3
+++ distinfo14 Sep 2021 20:09:06 -
@@ -1,2 +1,2 @@
-SHA256 (chafa-1.6.1.tar.xz) = dsmJMOmbPl+tuYYUi5nWVjbp6WGRJOVo/xPTZO3on6U=
-SIZE (chafa-1.6.1.tar.xz) = 418720
+SHA256 (chafa-1.8.0.tar.xz) = If9lLYNrogcJjEDEWWUrLx3myKZPv/xi58YxnO0yKGs=
+SIZE (chafa-1.8.0.tar.xz) = 435712
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/chafa/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 PLIST
--- pkg/PLIST 10 Feb 2021 20:18:11 - 1.2
+++ pkg/PLIST 14 Sep 2021 20:09:06 -
@@ -20,6 +20,7 @@ lib/libchafa.la
@lib lib/libchafa.so.${LIBchafa_VERSION}
lib/pkgconfig/chafa.pc
@man man/man1/chafa.1
+share/doc/pkg-readmes/${PKGSTEM}
share/gtk-doc/html/chafa/
share/gtk-doc/html/chafa/api-index-full.html
share/gtk-doc/html/chafa/ch01.html
Index: pkg/README
===
RCS file: pkg/README
diff -N pkg/README
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/README 14 Sep 2021 20:09:06 -
@@ -0,0 +1,9 @@
+# $OpenBSD: Makefile,v 1.4 2021/06/19 11:35:54 sthen Exp $
+
++---
+| Running ${PKGSTEM} on OpenBSD
++---
+
+For broader format support, install the "ffmpeg" package:
+
+# pkg_add ffmpeg
--
greetings,
Florian Viehweger
Re: misc/uniutils fix %n
Hi Stefan, Stefan Hagen wrote on Tue, Sep 14, 2021 at 07:37:20PM +0200: > I really appreciate you (and Theo) taking the time to explain > these things. You are welcome, and thank you for trying to help fix stuff (i think i forgot saying that in my previous mail because i got a bit worked up about the horrible code in that file, which has nothing to do with you). > I noticed the weird output, In such a case, it is useful to add a sentence like this: With my patch, it no longer crashes for me, but i'm not completely sure whether it is right because the output looks weird. It prints far too many '0' characters (32 too many if i count correctly) - compare the size of the 0-padding printed to the desired size mentioned in the text "..." printed in the first half of the line before the base-2 number. In general, if you have specific doubts, mentioning them specifically is better than just asking "is it better?" > but couldn't make sense of it as the > upstream version crashes (abort trap) here. > > Regarding my terrible C skills, I think I'll step back from trying to > fix C code for a bit. I'm wasting peoples time here to educate me on > topics I could as well learn elsewhere. (Except you tell me to continue > submitting bad fixes and learn here...). Well, your patch was still half-useful in so far as it correctly spotted the one place in the code that needs to be fixed (i did extensive grepping anyway to make sure, but it is reassuring that we both came to the same conclusion). There is a saying here "bad patches trigger good ones". Also, bug reports that contain *only* a verbal description of the problem or *only* a patch often leave me wondering what the sender is driving at. When *both* a verbal description and a patch are supplied together, even if the patch is bad, it very rarely happens that the intention of the sender remains nebulous. > I feel embarrassed, because I can't even explain why I used > snprintf there. I guess you looked at the rest of the code in the file, which uses lots and lots of superfluous static buffers and lots of pointless snprintf(3). Existence determines consciousness: what code one reads influences what kind of code one writes (though not deterministically, and of course it isn't the only factor). So make sure you read sufficient amounts of good code. Either way, learning from feedback is better than feeling too embarassed. > Your fix looks good to me. But my opinion doesn't matter at this point. Well, a test report from a real-world user is always useful, can make the difference between committing quickly and waiting for more feedback from developers, and is usually acknowledged by something like OK some_developer@, and also tested by <...@...> in the commit message. So thanks for testing and reviewing. Yours, Ingo
Re: [maintainer update] yle-dl-20210808
On Mon, Sep 13, 2021 at 06:57:04AM +0300, Timo Myyr?? wrote: > Here's an update to yle-dl to bring it to latest release. Committed thanks! I regenerated the PLIST beforehand, so the jsonhelpers module gets installed, as the program wouldn't run without it. > Also noticed that yle-dl has not used py-progress in a while and neither > seems other ports so I think the devel/py-progress package can be > removed from ports as well. No opinion on this, so I will defer to other porters. It's still being maintained upstream though, so I don't see any harm in keeping it in the ports tree either.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2021/09/14 13:53:00 Modified files: multimedia/yle-dl: Makefile distinfo multimedia/yle-dl/pkg: PLIST Log message: Update yle-dl to 20210808. >From maintainer Timo Myyra, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: phess...@cvs.openbsd.org2021/09/14 13:09:38 Modified files: x11/gnome/gdm : Makefile Log message: several of the build machines added the xserv set, which adds some files that gdm look for. bump the REVISION because binaries will change. OK tb@
[update] www/ruby-mustermann 1.0.1 -> 1.1.1
Update www/ruby-mustermann 1.0.1 to 1.1.1
Changelog can be seen here:
https://github.com/sinatra/mustermann/blob/master/README.md
Needs the previously sent devel/ruby-ruby2_keywords port.
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/www/ruby-mustermann/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile12 Jul 2019 20:51:04 - 1.3
+++ Makefile14 Sep 2021 18:19:48 -
@@ -2,7 +2,7 @@
COMMENT = string matching library
-DISTNAME = mustermann-1.0.1
+DISTNAME = mustermann-1.1.1
CATEGORIES = www
HOMEPAGE = https://github.com/sinatra/mustermann
@@ -12,6 +12,9 @@ PERMIT_PACKAGE = Yes
MODULES = lang/ruby
CONFIGURE_STYLE = ruby gem
+
+BUILD_DEPENDS =${RUN_DEPENDS}
+RUN_DEPENDS = devel/ruby-ruby2_keywords,${MODRUBY_FLAVOR}
# Tests require code not shipped in gem
Index: distinfo
===
RCS file: /cvs/ports/www/ruby-mustermann/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo14 Nov 2017 16:49:55 - 1.1.1.1
+++ distinfo14 Sep 2021 18:19:48 -
@@ -1,2 +1,2 @@
-SHA256 (mustermann-1.0.1.gem) = W2rGefqn5N5d5V09KOWcR2+G5/hGpXdU33XJ1raFzXI=
-SIZE (mustermann-1.0.1.gem) = 51712
+SHA256 (mustermann-1.1.1.gem) = CiHP5QWGnM6c4XmY21JgNE5434GuhXwHpiFD/TAplTE=
+SIZE (mustermann-1.1.1.gem) = 51712
Re: [New] devel/ruby-ruby2_keywords
On Tue, Sep 14, 2021 at 02:32:34PM -0400, Kurt Mosiejczuk wrote: > This is a new port required to be able to update www/ruby-mustermann. > (It's a requirement starting in mustermann 1.1.0). > DESCR: > Provides empty Module#ruby2_keywords method, for forward > source-level compatibility against ruby2.7 and ruby3. > ok to import? Now with 100% more attached port! (Thanks tb) --Kurt ruby-ruby2_keywords.tgz Description: application/tar-gz
[New] devel/ruby-ruby2_keywords
This is a new port required to be able to update www/ruby-mustermann. (It's a requirement starting in mustermann 1.1.0). DESCR: Provides empty Module#ruby2_keywords method, for forward source-level compatibility against ruby2.7 and ruby3. ok to import? --Kurt
Re: [remove-or-fix] x11/ion
On Tue, Sep 14, 2021 at 07:44:52PM +0200, Stefan Hagen wrote: > I found the cause and also why it's only happening here. It has nothing > to do with luajit. This was an accidental correlation. > Setting MAKE_JOBS>1 breaks it. When not using MAKE_JOBS, it works every > time. > According to README.internals MAKE_JOBS is used by dpb, so I wonder why > this didn't come up in bulk builds. dpb won't use more than one job unless DPB_PROPERTIES has parallel or parallel2. > Let's not touch it any further, besides the mandoc bit you committed > already. > Best regards, > Stefan --Kurt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/09/14 11:53:11 Modified files: lang/ghc : Makefile Added files: lang/ghc/patches: patch-includes_rts_Messages_h patch-rts_RtsMessages_c patch-rts_Stats_c Log message: Kill a %n format specifier used in report_summary(). Reminder to also handle the vdebugBelch() case by gnezdo@
Re: [remove-or-fix] x11/ion
Stuart Henderson wrote: > On 2021/09/14 14:06, Stefan Hagen wrote: > > Stuart Henderson wrote: > > > On 2021/09/14 07:43, Stefan Hagen wrote: > > > > X11/ion is currently broken. > > > > > > Hmm? It does build, though it does either need a BUILD_DEPENDS on groff > > > or your change for mandoc to produce consistent results (i.e. including > > > the manpage contents in welcome.txt etc). > > I've committed an alternative for the nroff fix. (Generally prefer to > use patch rather than sed unless there are a large number of files). > > > > $ ls -l */ion-* > > > -rw-r--r-- 1 root wheel 760147 Sep 13 07:16 aarch64/ion-20090110p4.tgz > > > -rw-r--r-- 1 root wheel 846233 Sep 13 07:03 amd64/ion-20090110p4.tgz > > > -rw-r--r-- 2 root wheel 756225 Jun 2 08:13 arm/ion-20090110p4.tgz > > > -rw-r--r-- 1 root wheel 760814 Sep 6 07:23 i386/ion-20090110p4.tgz > > > -rw-r--r-- 1 root wheel 869767 Aug 22 07:40 mips64/ion-20090110p4.tgz > > > -rw-r--r-- 1 root wheel 843277 Jun 25 07:55 mips64el/ion-20090110p4.tgz > > > -rw-r--r-- 1 root wheel 849572 Sep 9 09:59 powerpc/ion-20090110p4.tgz > > > -rw-r--r-- 1 root wheel 835022 Sep 10 07:12 > > > powerpc64/ion-20090110p4.tgz > > > -rw-r--r-- 1 root wheel 810101 Sep 11 09:30 sparc64/ion-20090110p4.tgz > > > > > > What problem are you seeing with the various exports.h files? Is there > > > something out of the ordinary with your lua installation? > > > > You're right. Once luajit is installed, it doesn't compile anymore. > > If I deinstall luajit, it works again. > > > > With the diff it works in both cases. > > Still strange as I don't see that here, and don't recall ever seeing a > problem in bulk builds with this. Have just tested with both in-tree > luajit and a local build of luajit 2.1. And I don't see any mechanism in > system.mk that ought to trigger the problem by having luajit installed > really.. > > I'm not seeing a good reason to remove it at this point, even with a > successor. > > > If we want to keep it, I'll look closer to find the root cause for the > > behavior change. > > > AFAIR it worked even with luajit a few months ago. > > > > This is the error I'm seeing: > > [...] > > Scanning mplex.c for exports. > > The command line running libextl-mkexports might give clues. Here's the > full build log from mine. Typical invocations are like this: > > `which lua51` ../libextl/libextl-mkexports -module mod_tiling -o exports.c -h > exports.h \ > main.c tiling.c placement.c split.c split-stdisp.c splitfloat.c panehandle.c > ops.c I found the cause and also why it's only happening here. It has nothing to do with luajit. This was an accidental correlation. Setting MAKE_JOBS>1 breaks it. When not using MAKE_JOBS, it works every time. According to README.internals MAKE_JOBS is used by dpb, so I wonder why this didn't come up in bulk builds. Let's not touch it any further, besides the mandoc bit you committed already. Best regards, Stefan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2021/09/14 11:42:08 Modified files: devel/got : Makefile distinfo Log message: update to got 0.59 - fix copy-pasto in got.conf man page - add -q quiet mode to checkout and update (tracey) - make 'got send' send commits which are referenced only by tags (found by Omar) - add -S option to 'got status' for suppressing certain status codes (tracey) - make 'got checkout' display the checked out reference and commit ID - make 'got update' display the worktree's branch name upon success
Re: misc/uniutils fix %n
Ingo Schwarze wrote: > Hi, > > Stefan Hagen wrote on Sat, Sep 11, 2021 at 09:00:18AM +0200: > > > Is this better? > > No, it is no good whatsoever. > > * It introduces yet another pointless static buffer. > * It pointlessly uses snprintf(3) where printf(3) >is obviously sufficient. > * It introduces error checking for operations >that obviously cannot fail when done properly. > * It needlessly does pointer arithmetic. > > So far, so bad, but the worst part is that it apparently wasn't > tested on a 64-bit platform (a platform where sizeof(long) == 64, > for example amd64). On such a platform, there is another bug on > the very same line. The function binfmtl() has platform-dependent > behaviour and does not behave as intended on a 64-bit platform and > prints 32 spurious zero-digit characters, breaking the desired > output alignment and making the content of the output > self-contradictory on top of that. > > Rather than try to change binfmtl(), which is mostly pointless > in the first place, let's just trivially inline the desired > functionality, it's just two lines of very simple C code. I really appreciate you (and Theo) taking the time to explain these things. I noticed the weird output, but couldn't make sense of it as the upstream version crashes (abort trap) here. Regarding my terrible C skills, I think I'll step back from trying to fix C code for a bit. I'm wasting peoples time here to educate me on topics I could as well learn elsewhere. (Except you tell me to continue submitting bad fixes and learn here...). I feel embarrassed, because I can't even explain why I used snprintf there. Your fix looks good to me. But my opinion doesn't matter at this point. Thanks, Stefan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2021/09/14 11:17:17 Modified files: astro/ansiweather: Makefile distinfo Log message: Update ansiweather to 1.18.0.
Re: misc/uniutils fix %n
Hi,
Stefan Hagen wrote on Sat, Sep 11, 2021 at 09:00:18AM +0200:
> Is this better?
No, it is no good whatsoever.
* It introduces yet another pointless static buffer.
* It pointlessly uses snprintf(3) where printf(3)
is obviously sufficient.
* It introduces error checking for operations
that obviously cannot fail when done properly.
* It needlessly does pointer arithmetic.
So far, so bad, but the worst part is that it apparently wasn't
tested on a 64-bit platform (a platform where sizeof(long) == 64,
for example amd64). On such a platform, there is another bug on
the very same line. The function binfmtl() has platform-dependent
behaviour and does not behave as intended on a 64-bit platform and
prints 32 spurious zero-digit characters, breaking the desired
output alignment and making the content of the output
self-contradictory on top of that.
Rather than try to change binfmtl(), which is mostly pointless
in the first place, let's just trivially inline the desired
functionality, it's just two lines of very simple C code.
OK?
Ingo
P.S.
Usually, we would want to upstream such a bugfix. But the overall
quality of this code is so abysmal that i'm not sure upstreaming
anything is worth the hassle. Doing minimal cleanup of the most
glaring style issues in this code would require changing 99% of it,
and given how it is written throughout, my suspicion is that it is
likely full of bugs, and having two bugs on this one line may not
be an exception. Just look at the totally ridiculous tempstr
gymnastics right below, which is incredibly stupid. Or look just
a few lines above and admire the hand-rolled code handling six-byte
UTF-8 characters (which are invalid according to the standard).
The code is just very, very bad throughout in large numbers of
respects.
I'm ashamed to admit that i have occasionally been using this port
myself, and after looking at the code, i'm no longer convinced i
should do that. Not sure yet what to do about that. Cleaning this
up looks like a project of significant size, and quite a painful one.
I just looked up the author of this code:
https://en.wikipedia.org/wiki/William_Poser
https://billposer.org/
It looks like he is probably an eminent linguist, but he is clearly
not a software developer by any stretch of the imagination.
Index: Makefile
===
RCS file: /cvs/ports/misc/uniutils/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile28 Jun 2021 21:34:19 - 1.9
+++ Makefile14 Sep 2021 15:52:32 -
@@ -3,7 +3,7 @@
COMMENT= Unicode utilities
DISTNAME= uniutils-2.27
-REVISION= 3
+REVISION= 4
CATEGORIES=misc
HOMEPAGE= http://billposer.org/Software/unidesc.html
Index: patches/patch-ExplicateUTF8_c
===
RCS file: patches/patch-ExplicateUTF8_c
diff -N patches/patch-ExplicateUTF8_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-ExplicateUTF8_c 14 Sep 2021 15:52:32 -
@@ -0,0 +1,30 @@
+$OpenBSD$
+
+Remove %n format specifier
+and stop using the platform-dependent function binfmtl().
+We want 32 bits here, not whatever sizeof(long) might be.
+
+Index: ExplicateUTF8.c
+--- ExplicateUTF8.c.orig
ExplicateUTF8.c
+@@ -87,7 +87,7 @@ main(int ac, char **av){
+ int UsefulBits;
+ unsigned char c[6];
+ int i;
+- UTF32 ch;
++ UTF32 ch, mask;
+ unsigned char *cptr;
+ unsigned char ShiftedByte;
+ char tempstr[33];
+@@ -214,7 +214,10 @@ main(int ac, char **av){
+ printf("%s ",tempstr);
+ }
+ printf("\n");
+- printf("This is padded to 32 places with %d zeros:
%n%s\n",(32-GotBits),,binfmtl(ch));
++ spaces = printf("This is padded to 32 places with %d zeros: ",(32-GotBits));
++ for (mask = 1UL << 31; mask; mask >>= 1)
++putchar(ch & mask ? '1' : '0');
++ putchar('\n');
+ sprintf(tempstr,"");
+ sprintf(tempstr,"%08lX",ch);
+ tempstr[28] = tempstr[7];
Re: lang/clisp: fix parallel make build
On Mon, 13 Sep 2021 16:42:21 +0200 Christian Weisgerber wrote: > gllib libgnu_sc.a : force > rm -f libgnu_sc.a > mkdir -p gllib > test -f gllib/Makefile || sh config.status gllib/Makefile depfiles > cd gllib; \ > $(MAKE) [...] ; \ > $(LN) libgnu.a ../libgnu_sc.a > > It defines two targets that are prerequisites for other targets. > gmake executes the recipe separately for each target. In parallel > mode, the commands end up being run more than once in parallel and > step on each other. GNU make 4.3 added the &: operator for "a recipe that generates multiple files from a single invocation" (info 'GNU make', 4.10 Multiple Targets in a Rule). The &: operator is specific to GNU make; a plain : would work in OpenBSD make. I changed 3 of your patches to use &: and completed make MAKE_JOBS=4 on amd64. To show what I mean, here are the 3 patches, but I forgot to edit the patch comment. --George --- /dev/null Tue Sep 14 12:07:14 2021 +++ patches/patch-modules_regexp_Makefile_inTue Sep 14 11:57:58 2021 @@ -0,0 +1,17 @@ +$OpenBSD$ + +Fix parallel make: reach target by a single name so the build recipe +is not run multiple times in parallel. + +Index: modules/regexp/Makefile.in +--- modules/regexp/Makefile.in.orig modules/regexp/Makefile.in +@@ -44,7 +44,7 @@ preload.lisp : $(srcdir)/preload.lisp + am--refresh : + + # regexp relies on src/gllib, so we must also include files in the build dir +-gllib libgnu_rx.a : force ++gllib libgnu_rx.a &: force + rm -f libgnu_rx.a + mkdir -p gllib + test -f gllib/Makefile || sh config.status gllib/Makefile depfiles --- /dev/null Tue Sep 14 12:07:23 2021 +++ patches/patch-modules_syscalls_Makefile_in Tue Sep 14 11:57:58 2021 @@ -0,0 +1,17 @@ +$OpenBSD$ + +Fix parallel make: reach target by a single name so the build recipe +is not run multiple times in parallel. + +Index: modules/syscalls/Makefile.in +--- modules/syscalls/Makefile.in.orig modules/syscalls/Makefile.in +@@ -47,7 +47,7 @@ preload.lisp : $(srcdir)/preload.lisp + am--refresh : + + # syscalls relies on src/gllib, so we must also include files in the build dir +-gllib libgnu_sc.a : force ++gllib libgnu_sc.a &: force + rm -f libgnu_sc.a + mkdir -p gllib + test -f gllib/Makefile || sh config.status gllib/Makefile depfiles --- /dev/null Tue Sep 14 12:07:29 2021 +++ patches/patch-modules_wildcard_Makefile_in Tue Sep 14 11:57:58 2021 @@ -0,0 +1,17 @@ +$OpenBSD$ + +Fix parallel make: reach target by a single name so the build recipe +is not run multiple times in parallel. + +Index: modules/wildcard/Makefile.in +--- modules/wildcard/Makefile.in.orig modules/wildcard/Makefile.in +@@ -34,7 +34,7 @@ wildcard.o : wildcard.c config.h gllib + am--refresh : + + # wildcard relies on src/gllib, so we must also include files in the build dir +-gllib libgnu_wc.a : force ++gllib libgnu_wc.a &: force + rm -f libgnu_wc.a + mkdir -p gllib + test -f gllib/Makefile || sh config.status gllib/Makefile depfiles
Re: UPDATE: x11/fvwm2 fix %n
On Sun, Sep 12, 2021 at 05:50:15PM +0200, Christian Weisgerber wrote:
> Michael:
>
> > +Index: modules/FvwmScript/Instructions.c
> > +--- modules/FvwmScript/Instructions.c.orig
> > modules/FvwmScript/Instructions.c
> > +@@ -665,7 +665,7 @@ static char *GetTime (int *NbArg,long *TabArg)
> > +
> > + str = (char*)safecalloc(20,sizeof(char));
> > + t = time(NULL);
> > +- sprintf(str,"%ld",(long)t-x11base->BeginTime);
> > ++ sprintf(str,"%lld",(long)t-x11base->BeginTime);
>
> That is incoherent. The cast should match the format string:
>
> sprintf(str,"%lld",(long long)t-x11base->BeginTime);
Thanks, updated diff below.
Index: Makefile
===
RCS file: /cvs/ports/x11/fvwm2/Makefile,v
retrieving revision 1.70
diff -u -p -u -p -r1.70 Makefile
--- Makefile8 Jan 2021 15:53:33 - 1.70
+++ Makefile14 Sep 2021 16:12:07 -
@@ -3,7 +3,7 @@
COMMENT= multiple virtual desktop window manager
VERSION= 2.6.9
-REVISION= 0
+REVISION= 1
DISTNAME= fvwm-${VERSION}
PKGNAME= fvwm2-${VERSION}
Index: patches/patch-bin_Makefile_in
===
RCS file: /cvs/ports/x11/fvwm2/patches/patch-bin_Makefile_in,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-bin_Makefile_in
--- patches/patch-bin_Makefile_in 13 Dec 2020 21:17:02 - 1.2
+++ patches/patch-bin_Makefile_in 14 Sep 2021 16:12:07 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-bin_Makefile_in,v 1.2 20
Index: bin/Makefile.in
--- bin/Makefile.in.orig
+++ bin/Makefile.in
-@@ -824,14 +824,13 @@ info: info-am
+@@ -835,14 +835,13 @@ info: info-am
info-am:
Index: patches/patch-configure
===
RCS file: /cvs/ports/x11/fvwm2/patches/patch-configure,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 patch-configure
--- patches/patch-configure 13 Dec 2020 21:17:02 - 1.4
+++ patches/patch-configure 14 Sep 2021 16:12:07 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-configure,v 1.4 2020/12/
Index: configure
--- configure.orig
+++ configure
-@@ -11756,7 +11756,7 @@ if test "${with_intl_library+set}" = set; then :
+@@ -11355,7 +11355,7 @@ if test "${with_intl_library+set}" = set; then :
else
with_intl=maybe
Index: patches/patch-fvwm_Makefile_in
===
RCS file: /cvs/ports/x11/fvwm2/patches/patch-fvwm_Makefile_in,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 patch-fvwm_Makefile_in
--- patches/patch-fvwm_Makefile_in 13 Dec 2020 21:17:02 - 1.8
+++ patches/patch-fvwm_Makefile_in 14 Sep 2021 16:12:07 -
@@ -3,16 +3,16 @@ $OpenBSD: patch-fvwm_Makefile_in,v 1.8 2
Index: fvwm/Makefile.in
--- fvwm/Makefile.in.orig
+++ fvwm/Makefile.in
-@@ -79,7 +79,7 @@ PRE_UNINSTALL = :
+@@ -89,7 +89,7 @@ PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
-bin_PROGRAMS = fvwm$(EXEEXT)
+bin_PROGRAMS = fvwm2$(EXEEXT)
subdir = fvwm
- DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
- $(top_srcdir)/etc/depcomp
-@@ -549,7 +549,7 @@ uninstall-binPROGRAMS:
+ ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
+ am__aclocal_m4_deps = $(top_srcdir)/acinclude.m4 \
+@@ -576,7 +576,7 @@ uninstall-binPROGRAMS:
clean-binPROGRAMS:
-test -z "$(bin_PROGRAMS)" || rm -f $(bin_PROGRAMS)
@@ -21,7 +21,7 @@ Index: fvwm/Makefile.in
@rm -f fvwm$(EXEEXT)
$(AM_V_CCLD)$(LINK) $(fvwm_OBJECTS) $(fvwm_LDADD) $(LIBS)
-@@ -795,7 +795,7 @@ install-dvi: install-dvi-am
+@@ -881,7 +881,7 @@ install-dvi: install-dvi-am
install-dvi-am:
Index: patches/patch-libs_ColorUtils_c
===
RCS file: patches/patch-libs_ColorUtils_c
diff -N patches/patch-libs_ColorUtils_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-libs_ColorUtils_c 14 Sep 2021 16:12:07 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+
+Index: libs/ColorUtils.c
+--- libs/ColorUtils.c.orig
libs/ColorUtils.c
+@@ -405,15 +405,15 @@ int pixel_to_color_string(
+ XQueryColor(dpy, cmap, );
+ if (!use_hash)
+ {
+- sprintf(
+- output, "rgb:%04x/%04x/%04x%n", (int)color.red,
+- (int)color.green, (int)color.blue, );
++ n = sprintf(
++ output, "rgb:%04x/%04x/%04x", (int)color.red,
++ (int)color.green, (int)color.blue);
+ }
+ else
+ {
+- sprintf(
+- output, "#%04x%04x%04x%n", (int)color.red,
+- (int)color.green, (int)color.blue, );
++ n = sprintf(
++ output, "#%04x%04x%04x", (int)color.red,
++ (int)color.green, (int)color.blue);
+ }
+
+ return n;
Index: patches/patch-libs_Module_c
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2021/09/14 08:03:32 Modified files: www/webkitgtk4 : Makefile www/webkitgtk4/patches: patch-Source_JavaScriptCore_jit_ExecutableAllocator_cpp Log message: bump arm64 memory limit up to 512M (from upstream) because it is partitioned down in the JIT code so it will not hit the limit and allow amd64 to allocate 128M by default ok aja@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: abie...@cvs.openbsd.org 2021/09/14 07:57:09 Modified files: net/headscale : Makefile distinfo Log message: Update to 0.8.1, which removes the annoying NO_COLOR trace when said var is set!
Re: [remove-or-fix] x11/ion
On 2021/09/14 14:06, Stefan Hagen wrote: > Stuart Henderson wrote: > > On 2021/09/14 07:43, Stefan Hagen wrote: > > > X11/ion is currently broken. > > > > Hmm? It does build, though it does either need a BUILD_DEPENDS on groff > > or your change for mandoc to produce consistent results (i.e. including > > the manpage contents in welcome.txt etc). I've committed an alternative for the nroff fix. (Generally prefer to use patch rather than sed unless there are a large number of files). > > $ ls -l */ion-* > > -rw-r--r-- 1 root wheel 760147 Sep 13 07:16 aarch64/ion-20090110p4.tgz > > -rw-r--r-- 1 root wheel 846233 Sep 13 07:03 amd64/ion-20090110p4.tgz > > -rw-r--r-- 2 root wheel 756225 Jun 2 08:13 arm/ion-20090110p4.tgz > > -rw-r--r-- 1 root wheel 760814 Sep 6 07:23 i386/ion-20090110p4.tgz > > -rw-r--r-- 1 root wheel 869767 Aug 22 07:40 mips64/ion-20090110p4.tgz > > -rw-r--r-- 1 root wheel 843277 Jun 25 07:55 mips64el/ion-20090110p4.tgz > > -rw-r--r-- 1 root wheel 849572 Sep 9 09:59 powerpc/ion-20090110p4.tgz > > -rw-r--r-- 1 root wheel 835022 Sep 10 07:12 powerpc64/ion-20090110p4.tgz > > -rw-r--r-- 1 root wheel 810101 Sep 11 09:30 sparc64/ion-20090110p4.tgz > > > > What problem are you seeing with the various exports.h files? Is there > > something out of the ordinary with your lua installation? > > You're right. Once luajit is installed, it doesn't compile anymore. > If I deinstall luajit, it works again. > > With the diff it works in both cases. Still strange as I don't see that here, and don't recall ever seeing a problem in bulk builds with this. Have just tested with both in-tree luajit and a local build of luajit 2.1. And I don't see any mechanism in system.mk that ought to trigger the problem by having luajit installed really.. I'm not seeing a good reason to remove it at this point, even with a successor. > If we want to keep it, I'll look closer to find the root cause for the > behavior change. > AFAIR it worked even with luajit a few months ago. > > This is the error I'm seeing: > [...] > Scanning mplex.c for exports. The command line running libextl-mkexports might give clues. Here's the full build log from mine. Typical invocations are like this: `which lua51` ../libextl/libextl-mkexports -module mod_tiling -o exports.c -h exports.h \ main.c tiling.c placement.c split.c split-stdisp.c splitfloat.c panehandle.c ops.c +++ Tue Sep 14 13:20:57 BST 2021 ===> Checking files for ion-20090110p5 `/y/Download/ftp/pub/OpenBSD/distfiles/ion-3-20090110.tar.gz' is up to date. >> (SHA256) ion-3-20090110.tar.gz: OK ===> Extracting for ion-20090110p5 ===> Patching for ion-20090110p5 ===> Applying OpenBSD patch patch-etc_cfg_ioncore_lua Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-etc_cfg_ioncore_lua,v 1.8 2013/04/29 12:40:49 gonzalo Exp $ |--- etc/cfg_ioncore.lua.orig Fri Jan 9 20:19:49 2009 |+++ etc/cfg_ioncore.luaMon Apr 8 11:20:13 2013 -- Patching file etc/cfg_ioncore.lua using Plan A... Hunk #1 succeeded at 65. Hunk #2 succeeded at 137. Hunk #3 succeeded at 156. done ===> Applying OpenBSD patch patch-man_Makefile Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-man_Makefile,v 1.1 2021/09/14 12:16:15 sthen Exp $ | |Index: man/Makefile |--- man/Makefile.orig |+++ man/Makefile -- Patching file man/Makefile using Plan A... Hunk #1 succeeded at 25. done ===> Applying OpenBSD patch patch-system_mk Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-system_mk,v 1.12 2014/03/23 18:17:35 kili Exp $ |--- system.mk.orig Fri Jan 9 23:20:27 2009 |+++ system.mk Tue Mar 18 11:41:59 2014 -- Patching file system.mk using Plan A... Hunk #1 succeeded at 8. Hunk #2 succeeded at 16. Hunk #3 succeeded at 54. Hunk #4 succeeded at 64. Hunk #5 succeeded at 82. Hunk #6 succeeded at 115. Hunk #7 succeeded at 131. Hunk #8 succeeded at 153. done ===> Applying OpenBSD patch patch-utils_ion-statusd_statusd_mail_lua Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-utils_ion-statusd_statusd_mail_lua,v 1.1 2013/04/29 12:40:49 gonzalo Exp $ |--- utils/ion-statusd/statusd_mail.lua.origMon Apr 8 11:59:40 2013 |+++ utils/ion-statusd/statusd_mail.lua Mon Apr 8 12:00:34 2013 -- Patching file utils/ion-statusd/statusd_mail.lua using Plan A... Hunk #1 succeeded at 12. done ===> Compiler link: clang -> ccache /usr/bin/clang ===> Compiler link: clang++ -> ccache /usr/bin/clang++ ===> Compiler link: cc -> ccache /usr/bin/cc ===> Compiler link: c++ -> ccache /usr/bin/c++ ===> Generating configure for ion-20090110p5 ===> Configuring for ion-20090110p5 /usr/bin/perl
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2021/09/14 06:21:58 Modified files: www/sogo : Makefile distinfo www/sogo/patches: patch-Tests_Unit_GNUmakefile patch-UI_MailPartViewers_GNUmakefile www/sogo/pkg : PLIST Log message: update 5.1.1 -> 5.2.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2021/09/14 06:21:38 Modified files: www/sope : Makefile distinfo Log message: update 5.1.1 -> 5.2.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/09/14 06:16:15 Modified files: x11/ion: Makefile Added files: x11/ion/patches: patch-man_Makefile Log message: use mandoc instead of nroff when formatting manpages to include in txt files. similar effect to a diff from Stefan Hagen.
Re: [remove-or-fix] x11/ion
Stuart Henderson wrote: > On 2021/09/14 07:43, Stefan Hagen wrote: > > X11/ion is currently broken. > > Hmm? It does build, though it does either need a BUILD_DEPENDS on groff > or your change for mandoc to produce consistent results (i.e. including > the manpage contents in welcome.txt etc). > > $ ls -l */ion-* > -rw-r--r-- 1 root wheel 760147 Sep 13 07:16 aarch64/ion-20090110p4.tgz > -rw-r--r-- 1 root wheel 846233 Sep 13 07:03 amd64/ion-20090110p4.tgz > -rw-r--r-- 2 root wheel 756225 Jun 2 08:13 arm/ion-20090110p4.tgz > -rw-r--r-- 1 root wheel 760814 Sep 6 07:23 i386/ion-20090110p4.tgz > -rw-r--r-- 1 root wheel 869767 Aug 22 07:40 mips64/ion-20090110p4.tgz > -rw-r--r-- 1 root wheel 843277 Jun 25 07:55 mips64el/ion-20090110p4.tgz > -rw-r--r-- 1 root wheel 849572 Sep 9 09:59 powerpc/ion-20090110p4.tgz > -rw-r--r-- 1 root wheel 835022 Sep 10 07:12 powerpc64/ion-20090110p4.tgz > -rw-r--r-- 1 root wheel 810101 Sep 11 09:30 sparc64/ion-20090110p4.tgz > > What problem are you seeing with the various exports.h files? Is there > something out of the ordinary with your lua installation? You're right. Once luajit is installed, it doesn't compile anymore. If I deinstall luajit, it works again. With the diff it works in both cases. If we want to keep it, I'll look closer to find the root cause for the behavior change. AFAIR it worked even with luajit a few months ago. This is the error I'm seeing: [...] Scanning mplex.c for exports. cc -O2 -pipe -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -I/usr/X11R6/include -I.. -I.. -I.. -c sizehint.c -o sizehint.o cc -O2 -pipe -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -I/usr/X11R6/include -I.. -I.. -I.. -c window.c -o window.o cc -O2 -pipe -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -I/usr/X11R6/include -I.. -I.. -I.. -c ioncore.c -o ioncore.o cc -O2 -pipe -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -I/usr/X11R6/include -I.. -I.. -I.. -c xic.c -o xic.o cc -O2 -pipe -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -I/usr/local/include -I/usr/local/include/lua-5.1 -I/usr/X11R6/include -I.. -I.. -I.. -c selection.c -o selection.o ioncore.c:66:10: fatal error: 'exports.h' file not found #include "exports.h" ^~~ 1 error generated. gmake[1]: *** [../build/rules.mk:189: ioncore.o] Error 1 gmake[1]: *** Waiting for unfinished jobs Scanning bindmaps.c for exports. Scanning gr.c for exports. Scanning infowin.c for exports. Scanning activity.c for exports. Scanning netwm.c for exports. Scanning frame-draw.c for exports. Scanning kbresize.c for exports. Scanning rectangle.c for exports. Scanning xwindow.c for exports. Scanning presize.c for exports. Scanning extlrx.c for exports. Scanning pholder.c for exports. Scanning mplexpholder.c for exports. Scanning llist.c for exports. Scanning basicpholder.c for exports. Scanning sizepolicy.c for exports. Scanning stacking.c for exports. Scanning group.c for exports. Scanning grouppholder.c for exports. Scanning group-cw.c for exports. Scanning navi.c for exports. Scanning group-ws.c for exports. Scanning float-placement.c for exports. Scanning framedpholder.c for exports. Scanning return.c for exports. Scanning detach.c for exports. Scanning screen-notify.c for exports. Scanning ../libmainloop/select.c for exports. Scanning ../libmainloop/defer.c for exports. Scanning ../libmainloop/signal.c for exports. Scanning ../libmainloop/hooks.c for exports. Scanning ../libmainloop/exec.c for exports. gmake[1]: Leaving directory '/usr/ports/pobj/ion-20090110/ion-3-20090110/ioncore' gmake: *** [build/rules.mk:242: subdirs] Error 2 *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2956 '/usr/ports/pobj/ion-20090110/.build_done': @cd /usr/ports/pobj/ion-20090110...) *** Error 2 in /usr/ports/x11/ion (/usr/ports/infrastructure/mk/bsd.port.mk:2602 'all': @lock=ion-20090110p4; export _LOCKS_HELD=" ion-2009...) ion# Best regards, Stefan
Re: [update] net/usockets-0.7.1 ,www/uwebsockets-19.5.0, www/purritobin-0.6.7, databases/lmdbxx (new)
Sorry the delay.
This look OK for me, anyone else want to test it? :D
On 9/11/21 23:47, aisha wrote:
Hi,
I've attached updates to uwebsockets, usockets and purritobin
Additions to www/purritobin
- auto cleaning of pastes
- web portal for pasting
- in-built http server, good for tiny pastes and testing setups
- http header manipulation
depends on a new port databases/lmdbxx, which is attached in the
patch as well.
Thanks,
Aisha
diff --git a/databases/lmdbxx/Makefile b/databases/lmdbxx/Makefile
new file mode 100644
index 000..240bf325f17
--- /dev/null
+++ b/databases/lmdbxx/Makefile
@@ -0,0 +1,42 @@
+# $OpenBSD: $
+
+COMMENT = C++17 wrapper for Lightning Memory-Mapped Database
+
+VERSION = 1.0.0
+PKGNAME = lmdbxx-${VERSION}
+DISTNAME = ${PKGNAME}
+
+CATEGORIES = databases
+
+GH_ACCOUNT = hoytech
+GH_PROJECT = lmdbxx
+#GH_TAGNAME = 1.0.0
+GH_COMMIT =f1f00acf5f5045b43d7189c2b23ae5ca103a6faa
+
+HOMEPAGE = https://github.com/hoytech/lmdbxx
+
+MAINTAINER = Aisha Tammy
+
+# Unlicense
+PERMIT_PACKAGE = Yes
+
+COMPILER = base-clang
+
+NO_BUILD = Yes
+
+RUN_DEPENDS = databases/lmdb
+
+do-install:
+ cd ${WRKSRC} && \
+ mkdir -p ${PREFIX}/include && \
+ ${INSTALL_DATA} lmdb++.h ${PREFIX}/include
+
+do-test:
+ cd ${WRKSRC} && \
+ rm -rf testdb && \
+ mkdir -p testdb && \
+ ${CXX} ${CXXFLAGS} -std=c++17 -Wall -I${LOCALBASE}/include -I. \
+ -o check check.cc ${LDFLAGS} -L${LOCALBASE}/lib -llmdb && \
+ ./check
+
+.include
diff --git a/databases/lmdbxx/distinfo b/databases/lmdbxx/distinfo
new file mode 100644
index 000..2cd8254361c
--- /dev/null
+++ b/databases/lmdbxx/distinfo
@@ -0,0 +1,2 @@
+SHA256 (lmdbxx-1.0.0-f1f00acf.tar.gz) =
hcZXFqDBZaZ8N3t6DP6m5mMypWnY2kadLD49v5mwSZo=
+SIZE (lmdbxx-1.0.0-f1f00acf.tar.gz) = 53347
diff --git a/databases/lmdbxx/pkg/DESCR b/databases/lmdbxx/pkg/DESCR
new file mode 100644
index 000..29e045d9927
--- /dev/null
+++ b/databases/lmdbxx/pkg/DESCR
@@ -0,0 +1,4 @@
+A comprehensive C++ wrapper for the LMDB embedded
+database library, offering both an error-checked
+procedural interface and an object-oriented resource
+interface with RAII semantics.
diff --git a/databases/lmdbxx/pkg/PLIST b/databases/lmdbxx/pkg/PLIST
new file mode 100644
index 000..cdf3f124dec
--- /dev/null
+++ b/databases/lmdbxx/pkg/PLIST
@@ -0,0 +1,2 @@
+@comment $OpenBSD: PLIST,v$
+include/lmdb++.h
diff --git a/net/usockets/Makefile b/net/usockets/Makefile
index a484c23f93a..7e58acda8a5 100644
--- a/net/usockets/Makefile
+++ b/net/usockets/Makefile
@@ -3,38 +3,34 @@
COMMENT = eventing, networking & crypto for async applications
CATEGORIES = net
-VERSION = 0.6.0
-REVISION = 1
+VERSION = 0.7.1
DISTNAME = usockets-${VERSION}
PKGNAME = ${DISTNAME:L}
-SHARED_LIBS = usockets 1.0
+SHARED_LIBS = usockets 2.0
GH_ACCOUNT = uNetworking
GH_PROJECT = uSockets
-#GH_TAGNAME = v0.6.0
-# cstdlib include error
-GH_COMMIT =7683672d87067cd75b854f4e36b9820f4809a4be
-
+#GH_TAGNAME = v0.7.1
+GH_COMMIT =c06112c89b4c1cf5a09b5f8daa2def756b925889
MAINTAINER = Aisha Tammy
# Apache 2.0
PERMIT_PACKAGE = Yes
-WANTLIB += ${COMPILER_LIBCXX} crypto ssl uv
+WANTLIB += ${COMPILER_LIBCXX} crypto ssl uv
# C11 C++17
COMPILER =base-clang ports-gcc
LIB_DEPENDS = devel/libuv
-USE_GMAKE = Yes
-MAKE_FLAGS = CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \
- CC="${CC}" CXX="${CXX}" \
- LIBusockets_VERSION="${LIBusockets_VERSION}"
+MAKE_ENV = LIBusockets_VERSION="${LIBusockets_VERSION}"
+
+FAKE_FLAGS = PREFIX=${TRUEPREFIX}
-NO_TEST = Yes
+# tests need A LOT of file desrciptors ~5000-6000
.include
diff --git a/net/usockets/distinfo b/net/usockets/distinfo
index 964ba508e9e..39993074785 100644
--- a/net/usockets/distinfo
+++ b/net/usockets/distinfo
@@ -1,2 +1,2 @@
-SHA256 (usockets-0.6.0-7683672d.tar.gz) =
0OooGCHD8ezNIcaB1zDPK6RQLGGYGZJb24Vemjlat7c=
-SIZE (usockets-0.6.0-7683672d.tar.gz) = 57634
+SHA256 (usockets-0.7.1-c06112c8.tar.gz) =
UFCe4o0SB63gVyGZvrBNW01tkoUxBvxfnfPn9crer1Q=
+SIZE (usockets-0.7.1-c06112c8.tar.gz) = 65495
diff --git a/net/usockets/patches/patch-Makefile
b/net/usockets/patches/patch-Makefile
index e718b65a265..5ea504d9f0f 100644
--- a/net/usockets/patches/patch-Makefile
+++ b/net/usockets/patches/patch-Makefile
@@ -1,4 +1,4 @@
-$OpenBSD: patch-Makefile,v 1.3 2020/12/11 22:33:22 sthen Exp $
+: patch-Makefile,v 1.3 2020/12/11 22:33:22 sthen Exp $
add shared + static lib + pkg-config file
remove -flto -O3
@@ -6,7 +6,7 @@ remove -flto -O3
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -1,60 +1,40 @@
+@@ -1,72 +1,46 @@
-# WITH_OPENSSL=1 enables OpenSSL 1.1+ support or BoringSSL
-# For now we need to link with C++ for OpenSSL support, but should be
removed with time
-ifeq ($(WITH_OPENSSL),1)
@@ -30,69 +30,85 @@ Index:
Re: net/epic5 new port
On Mon, Sep 13, 2021 at 10:51:30PM +0300, Mikhail wrote: > Extremely customizable IRC client, evolution of net/epic4. Updated port with REVISION removed. epic5.tar.gz Description: application/tar-gz
Re: [NEW] textproc/py-marisa (previously posted as devel/py-marisa)
On Mon, Sep 13, 2021 at 02:22:38PM +0100, Stuart Henderson wrote:
> On 2021/09/12 23:45, Kinichiro Inoguchi wrote:
> > - Added "REVISION-main=0".
> > I didn't add REVISION-main with my last diff since I thought
> > 'libmarisa-main'
> > would be the first revision but it was wrong.
>
> That would be correct if the PKGNAME changed, but it doesn't, it is still
> "libmarisa-$VERSION".
>
> > +PKGNAME-python = libmarisa-python-${V}
>
> Please set this to py3-libmarisa-${V}
>
> > +.if ${BUILD_PACKAGES:M-python}
> > +BUILD_DEPENDS =devel/swig
>
> and please use BUILD_DEPENDS +=, not just =. Just defense against adding
> a BUILD_DEPENDS for the non-Python version later.
>
> OK sthen@ with those two changes.
I've committed with your two inputs, thanks for your comments and advise.
And, SASANO-san, thanks for your understanding, and go ahead your libskk!
Re: [BUG] net/qbittorrent and net/deluge not working
On Tue, Sep 14, 2021 at 10:19:41AM +0100, Stuart Henderson wrote:
> Maybe relevant: https://github.com/arvidn/libtorrent/issues/6405
I tried updating libtorrent-rasterbar to 1.2.14 and bumping
TORRENT_{READ,WRITE}_HANDLER_MAX_SIZE by 16 bytes to match what was
discussed in that thread for libtorrent 2.0.x. I still get the same
abort (also the bogus pointer (double free?) seen in the backtrace
suggests that the problem is a different one.
>
> Users of other software that uses boost: please test snapshots ASAP and
> report back if there are recent problems.
>
> --
> Sent from a phone, apologies for poor formatting.
>
> On 14 September 2021 03:24:53 "Elias M. Mariani"
> wrote:
> > Thanks for the links Theo, I didn't know about those mirrors with the
> > previous builds.
> > Yep, the problem seems to lie with the boost update from 1.76 to 1.77.
> > Using 1.76 works OK.
> >
> > On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler wrote:
> > On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote:
> > > I should add some more info:
> > > - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so
> > > ago. I just tested deluge because it uses the same libraries.
> > > - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same
> > > applies for deluge.
> > > I tested both in a vanilla -current machine just to be sure that nothing
> > > was on the way...
> >
> > There was a similar report on bugs (Sep 9):
> > https://marc.info/?l=openbsd-bugs=163120864431955=2
> >
> > The timeframe of "one week or so" and the trace make it likely that it
> > is the boost 1.77 update.
> >
> > This is the last snapshot with boost-1.76p0:
> > https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/
> > If that works and the next snapshot with boost-1.77 is broken...
> > https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: inogu...@cvs.openbsd.org2021/09/14 04:51:53 Modified files: textproc/libmarisa: Makefile Added files: textproc/libmarisa/pkg: DESCR-main DESCR-python PLIST-main PLIST-python Removed files: textproc/libmarisa/pkg: DESCR PLIST Log message: Add libmarisa python binding inputs and OK sthen@ "please go ahead" from uaa@
Re: Warnings for %n in format strings
On 2021/09/14 05:42, Theo Buehler wrote: > On Tue, Sep 07, 2021 at 09:10:39PM +0100, Stuart Henderson wrote: > > > devel/libvstr The OpenBSD ports mailing-list > > > > I don't remember what libvstr was imported for originally but it's > > unused in ports, I propose removing it > > Converting it to avoid %n will be a bit of work (18 files with > non-trivial %n usage). Was this ever used in the tree? I couldn't find > any consumers. It wasn't. I suspect I may have added it for an early attempt at porting strongswan. > ok tb > > to remove it. Done :)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/09/14 04:40:30 Modified files: devel : Makefile devel/quirks : Makefile devel/quirks/files: Quirks.pm Removed files: devel/libvstr : Makefile distinfo devel/libvstr/pkg: DESCR PLIST Log message: remove libvstr, i imported it ages ago but can't remember what for and it was never used in-tree. ok tb@
Re: net/epic4 update
On Mon, Sep 13, 2021 at 09:34:54PM +0300, Mikhail wrote:
> Hello, this is update for net/epic4 port from 2.10.5 to 2.10.10.
>
> patch-include_irc_h and patch-source_irc_c were incorporated upstream
> and should be rm'ed
>
On IRC I was advised to remove REVISION, new patch is inline.
The maintainer has been contacted, seem he ignores the updates.
diff --git a/net/epic4/Makefile b/net/epic4/Makefile
index 4fab14b1dc7..46b792ee41f 100644
--- a/net/epic4/Makefile
+++ b/net/epic4/Makefile
@@ -2,13 +2,12 @@
COMMENT= (E)nhanced (P)rogrammable (I)RC-II (C)lient
-VERSION= 2.10.5
-REVISION= 2
+VERSION= 2.10.10
HELP_DATE= 20050315
DISTNAME= epic4-${VERSION}
CATEGORIES=net
MASTER_SITES= http://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/
-DISTFILES= epic4-${VERSION}.tar.bz2 epic4-help-${HELP_DATE}.tar.bz2
+DISTFILES= epic4-${VERSION}.tar.xz epic4-help-${HELP_DATE}.tar.bz2
HOMEPAGE= http://www.epicsol.org/
diff --git a/net/epic4/distinfo b/net/epic4/distinfo
index bcabd3b06db..b00b971e5d9 100644
--- a/net/epic4/distinfo
+++ b/net/epic4/distinfo
@@ -1,4 +1,4 @@
-SHA256 (epic4-2.10.5.tar.bz2) = /KexeIveUmh/0BwzxedNDhb8xlanazh94YUE7adk/4A=
+SHA256 (epic4-2.10.10.tar.xz) = 0SJxvL/YJ+nnWcMrumDs6AWul40z7ZHZIH3kNtBx+8U=
SHA256 (epic4-help-20050315.tar.bz2) =
p7cCbs/ACrcEDvXkNdcv00fUj6sShyLU4hPboZTNW74=
-SIZE (epic4-2.10.5.tar.bz2) = 636364
+SIZE (epic4-2.10.10.tar.xz) = 587056
SIZE (epic4-help-20050315.tar.bz2) = 238390
Re: [fix] www/luakit display version correctly
On 2021/09/14 08:21, Stefan Hagen wrote:
> Hi,
>
> This is a small fix for the luakit port, it leads to the correct
> `luakit --version` output and also prevents a shell script from running
> for each C file.
>
> I saw that build-utils/getversion.sh I called for every file when I had
> an error in there and the error showed up after each file.
>
> Setting VERSION directly prevents it from running getversion.sh.
>
> OK?
>
> Best regards,
> Stefan
>
> Index: www/luakit/Makefile
> ===
> RCS file: /cvs/ports/www/luakit/Makefile,v
> retrieving revision 1.31
> diff -u -p -u -p -r1.31 Makefile
> --- www/luakit/Makefile 1 Sep 2021 08:20:22 - 1.31
> +++ www/luakit/Makefile 13 Sep 2021 16:47:36 -
> @@ -5,7 +5,7 @@ COMMENT = fast, small, webkit based brow
> GH_ACCOUNT = luakit
> GH_PROJECT = luakit
> GH_TAGNAME = 2.3
> -REVISION = 1
> +REVISION = 2
>
> EPOCH = 1
>
> @@ -56,6 +56,7 @@ MAKE_FLAGS += LUA_BIN_NAME=${MODLUA_BIN}
> PIXMAPDIR=${PREFIX}/share/pixmaps/ \
> APPDIR=${PREFIX}/share/applications/ \
> PREFIX=${PREFIX} \
> - DEVELOPMENT_PATHS=0
> + DEVELOPMENT_PATHS=0 \
> + VERSION=${GH_TAGNAME}
>
> .include
>
Committed with a small tweak, to add a comment near GH_TAGNAME to
mention that it's used later in the Makefile. Experience has shown that
this is easy to miss this if a later update a port later (for example
if it moves to proper release tarballs).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/09/14 04:34:18 Modified files: www/luakit : Makefile Log message: fix luakit version display; from maintainer Stefan Hagen small tweak from me, to add a comment near GH_TAGNAME to mention that it's used later in the Makefile
Re: [remove-or-fix] x11/ion
On 2021/09/14 07:43, Stefan Hagen wrote: > X11/ion is currently broken. Hmm? It does build, though it does either need a BUILD_DEPENDS on groff or your change for mandoc to produce consistent results (i.e. including the manpage contents in welcome.txt etc). $ ls -l */ion-* -rw-r--r-- 1 root wheel 760147 Sep 13 07:16 aarch64/ion-20090110p4.tgz -rw-r--r-- 1 root wheel 846233 Sep 13 07:03 amd64/ion-20090110p4.tgz -rw-r--r-- 2 root wheel 756225 Jun 2 08:13 arm/ion-20090110p4.tgz -rw-r--r-- 1 root wheel 760814 Sep 6 07:23 i386/ion-20090110p4.tgz -rw-r--r-- 1 root wheel 869767 Aug 22 07:40 mips64/ion-20090110p4.tgz -rw-r--r-- 1 root wheel 843277 Jun 25 07:55 mips64el/ion-20090110p4.tgz -rw-r--r-- 1 root wheel 849572 Sep 9 09:59 powerpc/ion-20090110p4.tgz -rw-r--r-- 1 root wheel 835022 Sep 10 07:12 powerpc64/ion-20090110p4.tgz -rw-r--r-- 1 root wheel 810101 Sep 11 09:30 sparc64/ion-20090110p4.tgz What problem are you seeing with the various exports.h files? Is there something out of the ordinary with your lua installation?
Re: [BUG] net/qbittorrent and net/deluge not working
Maybe relevant: https://github.com/arvidn/libtorrent/issues/6405 Users of other software that uses boost: please test snapshots ASAP and report back if there are recent problems. -- Sent from a phone, apologies for poor formatting. On 14 September 2021 03:24:53 "Elias M. Mariani" wrote: Thanks for the links Theo, I didn't know about those mirrors with the previous builds. Yep, the problem seems to lie with the boost update from 1.76 to 1.77. Using 1.76 works OK. On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler wrote: On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote: I should add some more info: - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so ago. I just tested deluge because it uses the same libraries. - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same applies for deluge. I tested both in a vanilla -current machine just to be sure that nothing was on the way... There was a similar report on bugs (Sep 9): https://marc.info/?l=openbsd-bugs=163120864431955=2 The timeframe of "one week or so" and the trace make it likely that it is the boost 1.77 update. This is the last snapshot with boost-1.76p0: https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/ If that works and the next snapshot with boost-1.77 is broken... https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/
[maintainer update] remind 3.3.7 -> 3.3.8
This patch updates remind from 3.3.7 to 3.3.8. Tested on two amd64 systems (one cli only, one with tkremind) Index: Makefile === RCS file: /cvs/ports/misc/remind/Makefile,v retrieving revision 1.46 diff -u -p -r1.46 Makefile --- Makefile7 Jun 2021 18:26:22 - 1.46 +++ Makefile14 Sep 2021 05:58:44 - @@ -2,8 +2,8 @@ COMMENT= scripting language for reminders, with a Tk front end -DISTNAME= remind-03.03.07 -PKGNAME= remind-3.3.7 +DISTNAME= remind-03.03.08 +PKGNAME= remind-3.3.8 CATEGORIES=misc Index: distinfo === RCS file: /cvs/ports/misc/remind/distinfo,v retrieving revision 1.18 diff -u -p -r1.18 distinfo --- distinfo7 Jun 2021 18:26:22 - 1.18 +++ distinfo14 Sep 2021 05:58:44 - @@ -1,2 +1,2 @@ -SHA256 (remind-03.03.07.tar.gz) = h8lOKdHhiVT/XSIkfX7KMHzmIeEdIsFCCPkD9oo7ij0= -SIZE (remind-03.03.07.tar.gz) = 404576 +SHA256 (remind-03.03.08.tar.gz) = JeoSzZFLfUrsxXMbW8uBKVwOPflj2GuRcaTsoUW3t4g= +SIZE (remind-03.03.08.tar.gz) = 407339
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2021/09/14 01:23:12 Modified files: sysutils/salt : Makefile distinfo sysutils/salt/patches: patch-salt_grains_core_py patch-salt_modules_vmctl_py patch-salt_utils_network_py sysutils/salt/pkg: PLIST Log message: update to 3003.3
[fix] www/luakit display version correctly
Hi,
This is a small fix for the luakit port, it leads to the correct
`luakit --version` output and also prevents a shell script from running
for each C file.
I saw that build-utils/getversion.sh I called for every file when I had
an error in there and the error showed up after each file.
Setting VERSION directly prevents it from running getversion.sh.
OK?
Best regards,
Stefan
Index: www/luakit/Makefile
===
RCS file: /cvs/ports/www/luakit/Makefile,v
retrieving revision 1.31
diff -u -p -u -p -r1.31 Makefile
--- www/luakit/Makefile 1 Sep 2021 08:20:22 - 1.31
+++ www/luakit/Makefile 13 Sep 2021 16:47:36 -
@@ -5,7 +5,7 @@ COMMENT = fast, small, webkit based brow
GH_ACCOUNT = luakit
GH_PROJECT = luakit
GH_TAGNAME = 2.3
-REVISION = 1
+REVISION = 2
EPOCH =1
@@ -56,6 +56,7 @@ MAKE_FLAGS += LUA_BIN_NAME=${MODLUA_BIN}
PIXMAPDIR=${PREFIX}/share/pixmaps/ \
APPDIR=${PREFIX}/share/applications/ \
PREFIX=${PREFIX} \
- DEVELOPMENT_PATHS=0
+ DEVELOPMENT_PATHS=0 \
+ VERSION=${GH_TAGNAME}
.include
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2021/09/14 00:19:48 Modified files: www/chromium : Makefile distinfo www/chromium/patches: patch-chrome_browser_about_flags_cc patch-chrome_browser_prefs_browser_prefs_cc patch-third_party_angle_src_gpu_info_util_SystemInfo_linux_cpp patch-third_party_blink_renderer_core_exported_web_view_impl_cc patch-ui_compositor_compositor_cc Added files: www/chromium/patches: patch-chrome_browser_ui_views_tabs_tab_hover_card_bubble_view_cc Log message: update to 93.0.4577.82
Re: Teeworlds update - Teeworlds 0.7.5
Daniel Dickman wrote: > I’ve tried the update and unfortunately it doesn’t work for me. Which > is too bad because I really want to switch this one over to python3. > > After I launch teeworlds, I see a loading bar and hear the music. Then > the screen goes red and I don’t see anything. > > I’m on the latest OpenBSD release that sysupgrade gives me. And this > box (a lenovo amd64 laptop) has an amdgpu video card. > > If you want me to try anything else let me know. This is unexpected, because I'm running it on amdgpu as well. See: https://codevoid.de/9/p/rec-screen-20210914_080244.mp4 Is there any console output that looks interesting? Something in /var/log/messages or Xorg.0.log? The only issue on amdgpu for me (which is not present on intel) is that amdgpu freaks out when switching from window mode to fullscreen mode. Starting the game in one of these modes is fine, but switching within the game leads to weird flickering and I need to restart X. Best regards, Stefan
