CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/04/13 23:58:18 Modified files: x11/xfce4/xfwm4: Makefile distinfo x11/xfce4/xfwm4/pkg: PLIST Log message: Update to xfwm4 4.14.1
Re: CVS: cvs.openbsd.org: ports
On Mon, Apr 13, 2020, at 10:19 PM, Antoine Jacoutot wrote: > I don't think we want to modify a port to please another one that we > distribute in binary form, do we? The situation would be much easier if msbuild wasn't such a bestiality. I got it to build last year, but that didn't last as something upstream changed again. This was with a ~1G of dependencies from nuget. Even then, it only built some MSBuild projects, but not others (for example, it never worked to build recent FSharp). https://thfr.info/cgi-bin/cvsweb/mystuff/devel/msbuild/ This is how far I got when it worked; a crude draft. This broke later for unclear reasons, but if someone wants to take a jab at it, this could help... depotdownloader has proven very helpful for anyone running games on OpenBSD, and it would be sad to see it go. I see 3 other ways forward for depotdownloader, other than just disabling the port again. 1. fork and disable/fix whatever breaks with the AF_INET6 of OpenBSD 2. finding a way to convert from msbuild to xbuild. I'm not aware of any way to do this as mono has deprecated xbuild for years now. 3. provide different version of mono (5 and 6) - probably an unpopular approach as mainenance burden would go up a lot
Re: [sparc64/base-gcc] Fix build of x11/spice-gtk
Antoine Jacoutot wrote: > On Mon, Apr 13, 2020 at 08:13:50PM -0400, Brad Smith wrote: > > On 4/13/2020 5:26 PM, Antoine Jacoutot wrote: > > > > > On Mon, Apr 13, 2020 at 12:47:47PM -0400, Kurt Mosiejczuk wrote: > > > > Two things cause the build to fail on sparc64: "-Werror" and the need > > > > for C99. > > > > > > > > There are a bunch of deprecated functions that throw warnings and > > > > -Werror > > > > aborts the build, so there is a patch to remove that from meson.build. > > > > > > > > The C99 is fixed by adding -std=gnu99 to CFLAGS. > > > > > > > > This patch fixes the build on sparc64 (And presumably other base-gcc > > > > arches). > > > Can you put the same comment in the patch please. > > > So that I can remove all these tweaks once sparc64 moves to llvm. > > > > > > But there are more archs than just sparc64 which are !clang archs. > > That can run that kind of software? The schism of clangs vs gcc is becoming more narrow. The remaining gcc architectures are challenged in other ways. I hope this is making ports decisions easier. We hope to cross clang after 6.7, if a few issues which need handling are looked at by our experts. That's not certain, I'm only hoping. The sparc64 clang issues are much smaller than few months ago.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/04/13 22:46:12 Modified files: games/vitetris : Makefile distinfo Log message: Update vitetris to 0.58.0 Changelog: * Fix insecure use of printf * netplay.c: add missing includes generating warnings on compile * Update README * Remove old game server * Update INSTALL * Update configure script Update diff from Micah Muer, OK maintainer Ryan Freeman
Re: CVS: cvs.openbsd.org: ports
On Tue, Apr 14, 2020 at 01:50:03AM +0100, Stuart Henderson wrote: > On 2020/04/13 23:29, Antoine Jacoutot wrote: > > On Mon, Apr 13, 2020 at 01:26:20PM -0600, Robert Nagy wrote: > > > CVSROOT: /cvs > > > Module name: ports > > > Changes by: rob...@cvs.openbsd.org 2020/04/13 13:26:20 > > > > > > Modified files: > > > lang/mono : Makefile > > > lang/mono/patches: > > > > > > patch-mcs_class_System_System_Net_NetworkInformation_OpenBSDNetworkInterface_cs > > > > > > > > > Log message: > > > unbreak depotdownloader by re-defining AF_INET6 to 30 which is wrong as > > > that > > > is the value used by MacOS and not OpenBSD, however some ports are > > > distributed > > > in a binary form and they freak out if there is a mismatch between the > > > mono > > > runtime that they were compiled with and the one that they are running > > > with. > > > > > > the long-term solution is to get msbuild ported and compile > > > depotdownloader > > > with our own mono runtime, until then, break IPv6 , nobody is using it > > > anyway ;) > > https://www.google.com/intl/en/ipv6/statistics.html has picked up quite a > lot since mid March actually... > > > This is... horrible. > > I totally agree. It's even worse than the situation with jdk! I don't think we want to modify a port to please another one that we distribute in binary form, do we? -- Antoine
Re: [sparc64/base-gcc] Fix build of x11/spice-gtk
On Mon, Apr 13, 2020 at 08:13:50PM -0400, Brad Smith wrote: > On 4/13/2020 5:26 PM, Antoine Jacoutot wrote: > > > On Mon, Apr 13, 2020 at 12:47:47PM -0400, Kurt Mosiejczuk wrote: > > > Two things cause the build to fail on sparc64: "-Werror" and the need > > > for C99. > > > > > > There are a bunch of deprecated functions that throw warnings and -Werror > > > aborts the build, so there is a patch to remove that from meson.build. > > > > > > The C99 is fixed by adding -std=gnu99 to CFLAGS. > > > > > > This patch fixes the build on sparc64 (And presumably other base-gcc > > > arches). > > Can you put the same comment in the patch please. > > So that I can remove all these tweaks once sparc64 moves to llvm. > > > But there are more archs than just sparc64 which are !clang archs. That can run that kind of software? -- Antoine
Re: UPDATE: games/vitetris 0.57.0 -> 0.58.0
On Sun, Feb 23, 2020, at 10:30, Ryan Freeman wrote: > On Fri, Feb 21, 2020 at 06:59:37PM -0900, Micah Muer wrote: > > This patch updates games/vitetris from 0.57.0 to 0.58.0. This is the > > changelog: > > > > * Fix insecure use of printf > > * netplay.c: add missing includes generating warnings on compile > > * Update README > > * Remove old game server > > * Update INSTALL > > * Update configure script > > > > Ports-wise, I switched the Makefile to use github and updated the > > homepage. > > > > I've tested this on amd64 for a few weeks. > > Hi, thanks for this. Works good here on amd64 as well, > OK for anyone that wants to commit. > > -Ryan > > > > > Thanks, > > > > Micah > > > > Index: Makefile > > === > > RCS file: /cvs/ports/games/vitetris/Makefile,v > > retrieving revision 1.10 > > diff -u -p -u -p -r1.10 Makefile > > --- Makefile12 Jul 2019 20:46:26 - 1.10 > > +++ Makefile22 Feb 2020 03:47:14 - > > @@ -1,11 +1,13 @@ > > # $OpenBSD: Makefile,v 1.10 2019/07/12 20:46:26 sthen Exp $ > > > > COMMENT = terminal-based tetris clone in vein of nintendo tetris > > -DISTNAME = vitetris-0.57 > > CATEGORIES = games > > -REVISION = 3 > > > > -HOMEPAGE = http://victornils.net/tetris/ > > +GH_TAGNAME = v0.58.0 > > +GH_ACCOUNT = vicgeralds > > +GH_PROJECT = vitetris > > + > > +HOMEPAGE = https://www.victornils.net/tetris/ > > > > MAINTAINER = Ryan Freeman > > > > @@ -13,8 +15,6 @@ MAINTAINER = Ryan Freeman > PERMIT_PACKAGE = Yes > > > > WANTLIB = c curses > > - > > -MASTER_SITES = http://victornils.net/tetris/ > > > > RUN_DEPENDS = devel/desktop-file-utils > > > > Index: distinfo > > === > > RCS file: /cvs/ports/games/vitetris/distinfo,v > > retrieving revision 1.2 > > diff -u -p -u -p -r1.2 distinfo > > --- distinfo14 Jul 2013 07:12:22 - 1.2 > > +++ distinfo22 Feb 2020 03:47:14 - > > @@ -1,2 +1,2 @@ > > -SHA256 (vitetris-0.57.tar.gz) = > > DJ+myLFuL4lo9l4WqH8bzTm4J9UQxu+wdx8EAKuRzcI= > > -SIZE (vitetris-0.57.tar.gz) = 100660 > > +SHA256 (vitetris-0.58.0.tar.gz) = > > 5+fLdLuBS5/sgP5O3jw/BBNNghfWMOCSoJcjgkjWBPk= > > +SIZE (vitetris-0.58.0.tar.gz) = 96957 > > > Ping. There was an OK from the maintainer (Ryan Freeman) and a "Works here, ok rsadowski@".
Re: CVS: cvs.openbsd.org: ports
On 2020/04/13 23:29, Antoine Jacoutot wrote: > On Mon, Apr 13, 2020 at 01:26:20PM -0600, Robert Nagy wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: rob...@cvs.openbsd.org 2020/04/13 13:26:20 > > > > Modified files: > > lang/mono : Makefile > > lang/mono/patches: > > > > patch-mcs_class_System_System_Net_NetworkInformation_OpenBSDNetworkInterface_cs > > > > > > Log message: > > unbreak depotdownloader by re-defining AF_INET6 to 30 which is wrong as that > > is the value used by MacOS and not OpenBSD, however some ports are > > distributed > > in a binary form and they freak out if there is a mismatch between the mono > > runtime that they were compiled with and the one that they are running with. > > > > the long-term solution is to get msbuild ported and compile depotdownloader > > with our own mono runtime, until then, break IPv6 , nobody is using it > > anyway ;) https://www.google.com/intl/en/ipv6/statistics.html has picked up quite a lot since mid March actually... > This is... horrible. I totally agree. It's even worse than the situation with jdk!
Re: depotdownloader doesn't work after mono update
It's working again, thank you so much. On Mon, Apr 13, 2020 at 09:26:48PM +0200, Robert Nagy wrote: > fixored. explanation is in the commit > > On 13/04/20 13:13 -0500, Paul Valencia wrote: > > Hi, > > > > I tested depotdownloader-2.3.2 on -current (6.7 GENERIC.MP#125) with > > mono-6.8.0.105 and found that I cannot connect to Steam anymore: > > > > $ depotdownloader -app X -username reivyr -password X > > Connecting to Steam3...Connection to Steam failed. Trying again > > Connection to Steam failed. Trying again > > Connection to Steam failed. Trying again > > Connection to Steam failed. Trying again > > Connection to Steam failed. Trying again > > Connection to Steam failed. Trying again > > Connection to Steam failed. Trying again > > Connection to Steam failed. Trying again > > Timeout connecting to Steam3. > > Unable to get steam3 credentials. > > Error: InitializeSteam failed > > > > > > And there was an update today on depotdownloader to 2.3.3 and with the > > new -debug flag I get this log [1] > > > > But if I tested on -release (6.6 GENERIC#7) with mono-5.20.1.34 and > > depotdownloader-2.3.1 it works: > > > > $ depotdownloader -app X -username reivyr -password X > > Connecting to Steam3...[ServerList] Resolving server list > > [ServerList] Server list provider had no entries, will query SteamDirectory > > [ServerList] Resolved 200 servers > > [ServerList] Next server candidiate: 155.133.248.37:27020 (Tcp) > > [TcpConnection] Connecting to 155.133.248.37:27020... > > [TcpConnection] Connected to 155.133.248.37:27020 > > [EnvelopeEncryptedConnection] Got encryption request. Universe: Public > > Protocol ver: 1 > > [EnvelopeEncryptedConnection] Encryption result: OK > > Done! > > Logging 'reivyr' into Steam3...[CMClient] Sent -> EMsg: ClientLogon (Proto: > > True) > > [CMClient] <- Recv'd EMsg: Multi (1) (Proto: True) > > [CMClient] <- Recv'd EMsg: ClientLogOnResponse (751) (Proto: True) > > Disconnected from Steam > > This account is protected by Steam Guard. > > Please enter the authentication code sent to your email address: > > > > > > Finally, I tried 2.3.3 from GitHub[2] on -release and it worked too: > > > > $ mono DepotDownloader.dll -app X -username reivyr -password X > > Connecting to Steam3... Done! > > This account is protected by Steam Guard. > > Please enter the authentication code sent to your email address: > > > > > > On depotdownloader readme [3] indicates that it supports .NET Core 2.0 > > and on dotnet GitHub that it's compatible with mono-5 [4] > > > > [1] > > https://gist.githubusercontent.com/reivyr/e31b77a451d823477e192643d4c71a55/raw/cf9ca2311955d5d627289d061c382fb18cd6b584/depotdownloader-current-log > > [2] > > https://github.com/SteamRE/DepotDownloader/releases/download/DepotDownloader_2.3.3/depotdownloader-2.3.3.zip > > [3] https://github.com/SteamRE/DepotDownloader/blob/master/README.md > > [4] https://github.com/dotnet/standard/blob/master/docs/versions.md > > -- > Regards, > Robert Nagy >
Re: [sparc64/base-gcc] Fix build of x11/spice-gtk
On 4/13/2020 5:26 PM, Antoine Jacoutot wrote: On Mon, Apr 13, 2020 at 12:47:47PM -0400, Kurt Mosiejczuk wrote: Two things cause the build to fail on sparc64: "-Werror" and the need for C99. There are a bunch of deprecated functions that throw warnings and -Werror aborts the build, so there is a patch to remove that from meson.build. The C99 is fixed by adding -std=gnu99 to CFLAGS. This patch fixes the build on sparc64 (And presumably other base-gcc arches). Can you put the same comment in the patch please. So that I can remove all these tweaks once sparc64 moves to llvm. But there are more archs than just sparc64 which are !clang archs.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/04/13 15:43:55 Modified files: x11/gnustep/libobjc2: Makefile Log message: Restrict libobjc2 to base-clang, doesn't build with libestdc++-backed ports-clang Keep the sparc64 workaround even though this arch hasn't switched to base-clang yet.
Re: CVS: cvs.openbsd.org: ports
On Mon, Apr 13, 2020 at 01:26:20PM -0600, Robert Nagy wrote: > CVSROOT: /cvs > Module name: ports > Changes by: rob...@cvs.openbsd.org 2020/04/13 13:26:20 > > Modified files: > lang/mono : Makefile > lang/mono/patches: > > patch-mcs_class_System_System_Net_NetworkInformation_OpenBSDNetworkInterface_cs > > > Log message: > unbreak depotdownloader by re-defining AF_INET6 to 30 which is wrong as that > is the value used by MacOS and not OpenBSD, however some ports are distributed > in a binary form and they freak out if there is a mismatch between the mono > runtime that they were compiled with and the one that they are running with. > > the long-term solution is to get msbuild ported and compile depotdownloader > with our own mono runtime, until then, break IPv6 , nobody is using it anyway > ;) This is... horrible. -- Antoine
Re: [sparc64/base-gcc] Fix build of x11/spice-gtk
On Mon, Apr 13, 2020 at 12:47:47PM -0400, Kurt Mosiejczuk wrote:
> Two things cause the build to fail on sparc64: "-Werror" and the need
> for C99.
>
> There are a bunch of deprecated functions that throw warnings and -Werror
> aborts the build, so there is a patch to remove that from meson.build.
>
> The C99 is fixed by adding -std=gnu99 to CFLAGS.
>
> This patch fixes the build on sparc64 (And presumably other base-gcc
> arches).
Can you put the same comment in the patch please.
So that I can remove all these tweaks once sparc64 moves to llvm.
>
> cc maintainer
>
> ok?
>
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/spice-gtk/Makefile,v
> retrieving revision 1.45
> diff -u -p -r1.45 Makefile
> --- Makefile 3 Apr 2020 10:32:09 - 1.45
> +++ Makefile 13 Apr 2020 16:30:50 -
> @@ -65,4 +65,7 @@ CONFIGURE_ARGS += -Dpolkit=disabled
> # XXX requires the makecontext function (ucontext)
> CONFIGURE_ARGS +=-Dcoroutine=gthread
>
> +# base-gcc doesn't default to c99
> +CFLAGS +=-std=gnu99
> +
> .include
> Index: patches/patch-subprojects_spice-common_meson_build
> ===
> RCS file: patches/patch-subprojects_spice-common_meson_build
> diff -N patches/patch-subprojects_spice-common_meson_build
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-subprojects_spice-common_meson_build13 Apr 2020
> 16:30:50 -
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +Deprecated functions means -Werror aborts the build
> +
> +Index: subprojects/spice-common/meson.build
> +--- subprojects/spice-common/meson.build.orig
> subprojects/spice-common/meson.build
> +@@ -12,7 +12,6 @@ endif
> +
> + # some global vars
> + spice_common_global_cflags = ['-DG_LOG_DOMAIN="Spice"',
> +- '-Werror',
> + '-Wno-unused-parameter']
> +
> + if get_option('alignment-checks')
>
--
Antoine
[macppc] Unbreak x11/kde/arts3
Hi, arts3 is broken in the current macppc bulk: > /usr/obj/ports/arts-1.5.10/arts-1.5.10/mcop/debug.cc:797:3: error: > array type 'va_list' (aka '__builtin_va_list') is not assignable > G_VA_COPY (args2, args1); (there has been another occurrence later) This is happening because _CALL_SYSV is not defined by clang, it looks like it's a GCC-ism [0]. The below diff simplifies impacted conditionals so the proper definition of G_VA_COPY is used, and allows building arts3 on powerpc [1]. Comments/feedback are welcome, Charlène. [0] https://reviews.llvm.org/rG22d2435a00c9c288bf9bdd2d7f3e15557c3f4e06 [1] https://bin.charlenew.xyz/macppc/paths/x11/kde/arts3.log Index: patches/patch-flow_gsl_gslglib_h === RCS file: patches/patch-flow_gsl_gslglib_h diff -N patches/patch-flow_gsl_gslglib_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-flow_gsl_gslglib_h13 Apr 2020 19:21:48 - @@ -0,0 +1,19 @@ +$OpenBSD$ + +powerpc clang build fix for : +error: array type 'va_list' (aka '__builtin_va_list') is not assignable + +clang does not define _CALL_SYSV so the appropriate #define was not used. + +Index: flow/gsl/gslglib.h +--- flow/gsl/gslglib.h.orig flow/gsl/gslglib.h +@@ -505,7 +505,7 @@ gboolean g_path_is_absolute (const gchar *file_name); + * glibconfig.h may have already defined G_VA_COPY as va_copy or __va_copy. + */ + #if !defined (G_VA_COPY) +-# if defined (__GNUC__) && ( defined (__PPC__) || defined (__s390__) ) && (defined (_CALL_SYSV) || defined (_WIN32) || defined (__s390__) ) ++# if defined (__powerpc__) || defined (__s390__) + #define G_VA_COPY(ap1, ap2) (*(ap1) = *(ap2)) + # elif defined (G_VA_COPY_AS_ARRAY) + #define G_VA_COPY(ap1, ap2) g_memmove ((ap1), (ap2), sizeof (va_list)) Index: patches/patch-mcop_debug_cc === RCS file: patches/patch-mcop_debug_cc diff -N patches/patch-mcop_debug_cc --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-mcop_debug_cc 13 Apr 2020 19:21:48 - @@ -0,0 +1,19 @@ +$OpenBSD$ + +powerpc clang build fix for : +error: array type 'va_list' (aka '__builtin_va_list') is not assignable + +clang does not define _CALL_SYSV so the appropriate #define was not used. + +Index: mcop/debug.cc +--- mcop/debug.cc.orig mcop/debug.cc +@@ -381,7 +381,7 @@ typedef struct _GString GString; + * glibconfig.h may have already defined G_VA_COPY as va_copy or __va_copy. + */ + #if !defined (G_VA_COPY) +-# if defined (__GNUC__) && defined (__PPC__) && (defined (_CALL_SYSV) || defined (_WIN32) || defined(WIN32)) || defined(__s390__) || defined(__x86_64__) ++# if defined(__powerpc__) || defined(__s390__) || defined(__x86_64__) + #define G_VA_COPY(ap1, ap2) (*(ap1) = *(ap2)) + # elif defined (G_VA_COPY_AS_ARRAY) + #define G_VA_COPY(ap1, ap2) g_memmove ((ap1), (ap2), sizeof (va_list))
Re: depotdownloader doesn't work after mono update
fixored. explanation is in the commit On 13/04/20 13:13 -0500, Paul Valencia wrote: > Hi, > > I tested depotdownloader-2.3.2 on -current (6.7 GENERIC.MP#125) with > mono-6.8.0.105 and found that I cannot connect to Steam anymore: > > $ depotdownloader -app X -username reivyr -password X > Connecting to Steam3...Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Timeout connecting to Steam3. > Unable to get steam3 credentials. > Error: InitializeSteam failed > > > And there was an update today on depotdownloader to 2.3.3 and with the > new -debug flag I get this log [1] > > But if I tested on -release (6.6 GENERIC#7) with mono-5.20.1.34 and > depotdownloader-2.3.1 it works: > > $ depotdownloader -app X -username reivyr -password X > Connecting to Steam3...[ServerList] Resolving server list > [ServerList] Server list provider had no entries, will query SteamDirectory > [ServerList] Resolved 200 servers > [ServerList] Next server candidiate: 155.133.248.37:27020 (Tcp) > [TcpConnection] Connecting to 155.133.248.37:27020... > [TcpConnection] Connected to 155.133.248.37:27020 > [EnvelopeEncryptedConnection] Got encryption request. Universe: Public > Protocol ver: 1 > [EnvelopeEncryptedConnection] Encryption result: OK > Done! > Logging 'reivyr' into Steam3...[CMClient] Sent -> EMsg: ClientLogon (Proto: > True) > [CMClient] <- Recv'd EMsg: Multi (1) (Proto: True) > [CMClient] <- Recv'd EMsg: ClientLogOnResponse (751) (Proto: True) > Disconnected from Steam > This account is protected by Steam Guard. > Please enter the authentication code sent to your email address: > > > Finally, I tried 2.3.3 from GitHub[2] on -release and it worked too: > > $ mono DepotDownloader.dll -app X -username reivyr -password X > Connecting to Steam3... Done! > This account is protected by Steam Guard. > Please enter the authentication code sent to your email address: > > > On depotdownloader readme [3] indicates that it supports .NET Core 2.0 > and on dotnet GitHub that it's compatible with mono-5 [4] > > [1] > https://gist.githubusercontent.com/reivyr/e31b77a451d823477e192643d4c71a55/raw/cf9ca2311955d5d627289d061c382fb18cd6b584/depotdownloader-current-log > [2] > https://github.com/SteamRE/DepotDownloader/releases/download/DepotDownloader_2.3.3/depotdownloader-2.3.3.zip > [3] https://github.com/SteamRE/DepotDownloader/blob/master/README.md > [4] https://github.com/dotnet/standard/blob/master/docs/versions.md -- Regards, Robert Nagy
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/04/13 13:26:20 Modified files: lang/mono : Makefile lang/mono/patches: patch-mcs_class_System_System_Net_NetworkInformation_OpenBSDNetworkInterface_cs Log message: unbreak depotdownloader by re-defining AF_INET6 to 30 which is wrong as that is the value used by MacOS and not OpenBSD, however some ports are distributed in a binary form and they freak out if there is a mismatch between the mono runtime that they were compiled with and the one that they are running with. the long-term solution is to get msbuild ported and compile depotdownloader with our own mono runtime, until then, break IPv6 , nobody is using it anyway ;)
Re: [NEW] games/wrath
On Fri, Apr 10, 2020 at 12:39:33PM -0500, Paul Valencia wrote: > On Fri, Apr 10, 2020 at 01:44:54PM +0200, Solene Rapenne wrote: > > On Fri, Apr 10, 2020 at 02:40:22AM -0500, Paul Valencia wrote: > > > Hi, > > > > > > Here is a new port for the wrath-darkplaces engine [1] > > > which is used in the game WRATH: Aeon of Ruin. > > > > > > Some notes about this: > > > > > > - There is no release, so I used GH_COMMIT > > > > > > - Pass port-lib-depends-check and portcheck > > > > > > - I used games/xonotic as a reference for this port > > > since it is related to the darkplaces engine. > > > > > > - I renamed the binary to wrath as a recommendation > > > here [2] > > > > > > - I tested the three levels of the game on amd64 > > > > > > - In the game, I found an issue with the mouse when > > > you have different artifacts(3+) in your inventory > > > that only allows you to select the extreme left/right > > > artifact. > > > > > > OK's? Comments? > > > > > > [1] https://github.com/KillPixelGames/wrath-darkplaces > > > [2] https://github.com/KillPixelGames/wrath-darkplaces#running > > > > the port looks fine to me (and works well) altough > > > > - README should explain that you need to run wrath binary in a directory > > where the folder kp1 is available, or that you can use some args for > > that (at least the game tell you to use -basedir to find the assets) > > - version maybe be 20200228 instead of adding 0.0.0 as a prefix to > > commit date? > > Here is the port with the README change. I use the prefix 0.0.0 > for the version because there may be an official release in the > future (e.g. 1.X.X) and to avoid EPOCH if that happens. > > Thanks for your input. indeed, the prefix 0.0.0 make sense in that case you showed me others ports do the same. I'm ok to import it. Anyone else ok?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2020/04/13 13:14:28 Modified files: mail/opensmtpd-filters/libopensmtpd: Makefile distinfo Log message: Add support for smtpd filter protocol v0.6, which is imminent.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2020/04/13 12:46:02 Modified files: graphics/feh : Makefile distinfo graphics/feh/patches: patch-man_feh_pre patch-src_options_c Log message: Update to feh-3.4 Changelog: https://feh.finalrewind.org/archive/3.4/ Additional testing from Caspar Schutijser -- thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/04/13 12:40:25 Modified files: x11/mate/control-center: Makefile Log message: Fix build of mate/control-center for base-gcc arches ok jca@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/04/13 12:39:34 Modified files: misc/dtcltiny : Makefile Log message: Fix build of dtcltiny for sparc64/ld.bfd arches. ok jca@
Re: depotdownloader doesn't work after mono update
Hi I know what is going on and I will get it fixed soon. On 13/04/20 13:13 -0500, Paul Valencia wrote: > Hi, > > I tested depotdownloader-2.3.2 on -current (6.7 GENERIC.MP#125) with > mono-6.8.0.105 and found that I cannot connect to Steam anymore: > > $ depotdownloader -app X -username reivyr -password X > Connecting to Steam3...Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Connection to Steam failed. Trying again > Timeout connecting to Steam3. > Unable to get steam3 credentials. > Error: InitializeSteam failed > > > And there was an update today on depotdownloader to 2.3.3 and with the > new -debug flag I get this log [1] > > But if I tested on -release (6.6 GENERIC#7) with mono-5.20.1.34 and > depotdownloader-2.3.1 it works: > > $ depotdownloader -app X -username reivyr -password X > Connecting to Steam3...[ServerList] Resolving server list > [ServerList] Server list provider had no entries, will query SteamDirectory > [ServerList] Resolved 200 servers > [ServerList] Next server candidiate: 155.133.248.37:27020 (Tcp) > [TcpConnection] Connecting to 155.133.248.37:27020... > [TcpConnection] Connected to 155.133.248.37:27020 > [EnvelopeEncryptedConnection] Got encryption request. Universe: Public > Protocol ver: 1 > [EnvelopeEncryptedConnection] Encryption result: OK > Done! > Logging 'reivyr' into Steam3...[CMClient] Sent -> EMsg: ClientLogon (Proto: > True) > [CMClient] <- Recv'd EMsg: Multi (1) (Proto: True) > [CMClient] <- Recv'd EMsg: ClientLogOnResponse (751) (Proto: True) > Disconnected from Steam > This account is protected by Steam Guard. > Please enter the authentication code sent to your email address: > > > Finally, I tried 2.3.3 from GitHub[2] on -release and it worked too: > > $ mono DepotDownloader.dll -app X -username reivyr -password X > Connecting to Steam3... Done! > This account is protected by Steam Guard. > Please enter the authentication code sent to your email address: > > > On depotdownloader readme [3] indicates that it supports .NET Core 2.0 > and on dotnet GitHub that it's compatible with mono-5 [4] > > [1] > https://gist.githubusercontent.com/reivyr/e31b77a451d823477e192643d4c71a55/raw/cf9ca2311955d5d627289d061c382fb18cd6b584/depotdownloader-current-log > [2] > https://github.com/SteamRE/DepotDownloader/releases/download/DepotDownloader_2.3.3/depotdownloader-2.3.3.zip > [3] https://github.com/SteamRE/DepotDownloader/blob/master/README.md > [4] https://github.com/dotnet/standard/blob/master/docs/versions.md -- Regards, Robert Nagy
Re: [ld.bfd/sparc64] Fix build of misc/dtcltiny
On Mon, Apr 13 2020, Kurt Mosiejczuk wrote:
> On Fri, Mar 27, 2020 at 12:27:50PM -0400, Kurt Mosiejczuk wrote:
>> http://build-failures.rhaalovely.net/sparc64/2020-03-21/misc/dtcltiny.log
>
>> This fixes the build of misc/dtcltiny for sparc64 (and, presumably, other
>> ld.bfd architectures).
>
>> Not sure if the REVISION bump is necessary or not...
>
>> cc maintainer
>
> ping
ok jca@
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/misc/dtcltiny/Makefile,v
> retrieving revision 1.12
> diff -u -p -r1.12 Makefile
> --- Makefile 3 Feb 2020 12:40:23 - 1.12
> +++ Makefile 27 Mar 2020 16:26:03 -
> @@ -5,6 +5,7 @@ COMMENT = small SRCP client to control
> EPOCH = 0
> DISTNAME = dtcltiny-0.4.5
> CATEGORIES = misc x11
> +REVISION = 0
>
> HOMEPAGE = http://dtcltiny.sourceforge.net/
> MAINTAINER = Sebastian Reitenbach
> @@ -20,9 +21,12 @@ WANTLIB += Qt5Core Qt5Gui Qt5Network Qt
>
> COMPILER = base-clang ports-gcc base-gcc
>
> +LDFLAGS =-L${LOCALBASE}/lib \
> + -L${X11BASE}/lib
> +
> USE_GMAKE = Yes
> CONFIGURE_STYLE =gnu
> -CONFIGURE_ENV = LDFLAGS=-L${LOCALBASE}/lib
> CFLAGS=-I${LOCALBASE}/include \
> +CONFIGURE_ENV = LDFLAGS="${LDFLAGS}"
> CFLAGS=-I${LOCALBASE}/include \
> UIC_PATH=${MODQT_UIC}
> CONFIGURE_ARGS = --with-qt-libraries=${MODQT_LIBDIR} \
> --with-qt-includes=${MODQT_INCDIR}
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [base-gcc/sparc64] Fix build for x11/mate/control-center
On Mon, Apr 13 2020, Kurt Mosiejczuk wrote:
> On Sat, Mar 28, 2020 at 01:03:26AM -0400, Kurt Mosiejczuk wrote:
>> This is just like gnome/control-center. It needs C99.
>
>> ok?
>
> ping
ok jca@
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/mate/control-center/Makefile,v
> retrieving revision 1.21
> diff -u -p -r1.21 Makefile
> --- Makefile 21 Mar 2020 16:14:54 - 1.21
> +++ Makefile 28 Mar 2020 05:01:57 -
> @@ -46,4 +46,6 @@ FAKE_FLAGS= sysconfdir=${PREFIX}/share/
>
> CONFIGURE_STYLE= gnu
>
> +CFLAGS +=-std=gnu99
> +
> .include
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/04/13 12:29:36 Modified files: x11/libhandy : Makefile Log message: Fix build of x11/libhandy for ld-bfd architectures. This fixes the build on sparc64 ok and tweaks jca@
Re: [sparc64/base-gcc/ld.bfd] Fix build of x11/libhandy
On Mon, Apr 13 2020, Kurt Mosiejczuk wrote:
> On Thu, Mar 26, 2020 at 10:41:42AM -0400, Kurt Mosiejczuk wrote:
>> On Thu, Mar 26, 2020 at 03:10:04AM +0100, Jeremie Courreges-Anglas wrote:
>> > On Tue, Mar 24 2020, Kurt Mosiejczuk wrote:
>> > > x11/libhandy needs ports-gcc on base-gcc architectures and needs
>> > > -L${X11BASE}/lib added to CFLAGS to build properly on base-gcc
>> > > architectures.
>
>> > > No REVISION bump since it hasn't built on those other architectures
>> > > before.
>
>> > > (cc maintainer)
>
>> > Just like for colord-gtk, I suspect it would be cleaner to use LDFLAGS
>> > for this kind of tweak, but that requires adding LDFLAGS to
>> > CONFIGURE_ENV (meson.port.mk doesn't do it).
>
>> > Also cc'ing Antoine who maintains colord-gtk, it would be good to
>> > discuss this in a single email thread.
>
>> Here's a version of the libhandy diff that uses LDFLAGS like in
>> your diff for colord-gtk
>
> Ping
".if !${PROPERTIES:Mlld}" is self-documenting and doesn't affect lld
archs. ok jca@
You're adding an extra line after LIB_DEPENDS, please zap it.
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/libhandy/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- Makefile 2 Nov 2019 11:12:35 - 1.4
> +++ Makefile 26 Mar 2020 14:25:26 -
> @@ -16,6 +16,9 @@ MAINTAINER =Jasper Lievisse Adriaanse
> # LGPLv2.1
> PERMIT_PACKAGE = Yes
>
> +COMPILER = base-clang ports-gcc
> +COMPILER_LANGS = c
> +
> MODULES =devel/meson
>
> WANTLIB += atk-1.0 cairo gdk-3 gdk_pixbuf-2.0 gio-2.0 glib-2.0
> @@ -26,8 +29,15 @@ RUN_DEPENDS = devel/gobject-introspecti
> lang/vala
> LIB_DEPENDS =x11/gtk+3
>
> +
> CONFIGURE_ARGS +=-Dglade_catalog=disabled \
> -Dexamples=false
> +CONFIGURE_ENV = LDFLAGS=${LDFLAGS}
> +
> +.include
> +.if !${PROPERTIES:Mlld}
> +LDFLAGS =-L${X11BASE}/lib
> +.endif
>
> TEST_IS_INTERACTIVE =X11
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
depotdownloader doesn't work after mono update
Hi, I tested depotdownloader-2.3.2 on -current (6.7 GENERIC.MP#125) with mono-6.8.0.105 and found that I cannot connect to Steam anymore: $ depotdownloader -app X -username reivyr -password X Connecting to Steam3...Connection to Steam failed. Trying again Connection to Steam failed. Trying again Connection to Steam failed. Trying again Connection to Steam failed. Trying again Connection to Steam failed. Trying again Connection to Steam failed. Trying again Connection to Steam failed. Trying again Connection to Steam failed. Trying again Timeout connecting to Steam3. Unable to get steam3 credentials. Error: InitializeSteam failed And there was an update today on depotdownloader to 2.3.3 and with the new -debug flag I get this log [1] But if I tested on -release (6.6 GENERIC#7) with mono-5.20.1.34 and depotdownloader-2.3.1 it works: $ depotdownloader -app X -username reivyr -password X Connecting to Steam3...[ServerList] Resolving server list [ServerList] Server list provider had no entries, will query SteamDirectory [ServerList] Resolved 200 servers [ServerList] Next server candidiate: 155.133.248.37:27020 (Tcp) [TcpConnection] Connecting to 155.133.248.37:27020... [TcpConnection] Connected to 155.133.248.37:27020 [EnvelopeEncryptedConnection] Got encryption request. Universe: Public Protocol ver: 1 [EnvelopeEncryptedConnection] Encryption result: OK Done! Logging 'reivyr' into Steam3...[CMClient] Sent -> EMsg: ClientLogon (Proto: True) [CMClient] <- Recv'd EMsg: Multi (1) (Proto: True) [CMClient] <- Recv'd EMsg: ClientLogOnResponse (751) (Proto: True) Disconnected from Steam This account is protected by Steam Guard. Please enter the authentication code sent to your email address: Finally, I tried 2.3.3 from GitHub[2] on -release and it worked too: $ mono DepotDownloader.dll -app X -username reivyr -password X Connecting to Steam3... Done! This account is protected by Steam Guard. Please enter the authentication code sent to your email address: On depotdownloader readme [3] indicates that it supports .NET Core 2.0 and on dotnet GitHub that it's compatible with mono-5 [4] [1] https://gist.githubusercontent.com/reivyr/e31b77a451d823477e192643d4c71a55/raw/cf9ca2311955d5d627289d061c382fb18cd6b584/depotdownloader-current-log [2] https://github.com/SteamRE/DepotDownloader/releases/download/DepotDownloader_2.3.3/depotdownloader-2.3.3.zip [3] https://github.com/SteamRE/DepotDownloader/blob/master/README.md [4] https://github.com/dotnet/standard/blob/master/docs/versions.md
Re: NEW: devel/arduino-esp32 1.0.4
On Mon, 13 Apr 2020, Tracey Emery wrote: > On Sun, Apr 12, 2020 at 10:49:24AM +0200, Paco Esteban wrote: > > On Mon, 06 Apr 2020, Tracey Emery wrote: > > > > > Hello, > > > > > > This new port is the framework to program Espressif ESP32 chipsets via > > > the Arduino environment. > > > > > > Used and tested on amd64 for a few months. > > > > > > OK? > > > > Cannot test this one as I do not have any ESP32 boards. The port builds > > and installs fine as a dependency of devel/makeesparduino on amd64. > > > > > > -- > > Paco Esteban. > > 0x5818130B8A6DBC03 > > During compile testing, Paco discovered that a python symlink is > required for generating the bin files for the esp32. The attached port > has a patch adjustment to fix that problem. > > OK? Tried some simple projects and compilation works with this mod. As I said could not test flashing. ok paco -- Paco Esteban. 0x5818130B8A6DBC03
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 :
Index: Makefile
===
RCS file: /cvs/ports/lang/nim/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile31 Aug 2019 15:36:56 - 1.10
+++ Makefile13 Apr 2020 17:38:23 -
@@ -6,7 +6,7 @@ BROKEN-i386 = hardcodes gcc; see config/
COMMENT = statically typed, imperative programming language
-VERSION = 0.16.0
+VERSION = 1.2.0
DISTNAME = nim-${VERSION}
EXTRACT_SUFX = .tar.xz
REVISION = 0
@@ -39,10 +39,14 @@ do-build:
cd ${WRKSRC} && ./koch boot -d:release --parallelBuild:1 \
--nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
--listCmd --putenv:"PATH=${PATH}"
+ cd ${WRKSRC} && ./koch nimble -d:release --parallelBuild:1 \
+ --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
+ --listCmd --putenv:"PATH=${PATH}"
do-install:
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
${INSTALL_PROGRAM} ${WRKSRC}/bin/nim ${PREFIX}/bin
+ ${INSTALL_PROGRAM} ${WRKSRC}/bin/nimble ${PREFIX}/bin
${INSTALL_DATA_DIR} ${PREFIX}/lib/nim
cp -R ${WRKSRC}/lib/* ${PREFIX}/lib/nim
chown -R ${LIBOWN}:${LIBGRP} ${PREFIX}/lib/nim
Index: distinfo
===
RCS file: /cvs/ports/lang/nim/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo9 Jan 2017 10:32:33 - 1.4
+++ distinfo13 Apr 2020 17:38:23 -
@@ -1,2 +1,2 @@
-SHA256 (nim-0.16.0.tar.xz) = nhmYI75Hy6VeYt1pgvAs8KrXMvNpeZ/sQqTYwiZcUWc=
-SIZE (nim-0.16.0.tar.xz) = 2907076
+SHA256 (nim-1.2.0.tar.xz) = TpRYOjc5ZYIYBeZl4KBfUvthCRZnbtsJFIlBQVY3xXU=
+SIZE (nim-1.2.0.tar.xz) = 5869428
Index: patches/patch-build_sh
===
RCS file: patches/patch-build_sh
diff -N patches/patch-build_sh
--- patches/patch-build_sh 15 Jun 2016 00:19:59 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-build_sh,v 1.2 2016/06/15 00:19:59 juanfra Exp $
build.sh.orig Tue Jun 7 00:38:53 2016
-+++ build.sh Thu Jun 9 19:43:03 2016
-@@ -26,9 +26,9 @@ do
- esac
- done
-
--CC="gcc"
--LINKER="gcc"
--COMP_FLAGS="${CPPFLAGS:-} ${CFLAGS:-} -w -O3
-fno-strict-aliasing$extraBuildArgs"
-+#CC="gcc"
-+#LINKER="gcc"
-+COMP_FLAGS="${CPPFLAGS:-} ${CFLAGS:-} -w -fno-strict-aliasing$extraBuildArgs"
- LINK_FLAGS="${LDFLAGS:-} "
- PS4=""
- # platform detection
Index: patches/patch-compiler_extccomp_nim
===
RCS file: patches/patch-compiler_extccomp_nim
diff -N patches/patch-compiler_extccomp_nim
--- patches/patch-compiler_extccomp_nim 9 Jan 2017 10:32:33 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,47 +0,0 @@
-$OpenBSD: patch-compiler_extccomp_nim,v 1.3 2017/01/09 10:32:33 juanfra Exp $
compiler/extccomp.nim.orig Sun Jan 8 21:33:43 2017
-+++ compiler/extccomp.nim Mon Jan 9 02:22:00 2017
-@@ -21,7 +21,7 @@ import
- type
- TSystemCC* = enum
- ccNone, ccGcc, ccLLVM_Gcc, ccCLang, ccLcc, ccBcc, ccDmc, ccWcc, ccVcc,
--ccTcc, ccPcc, ccUcc, ccIcl, asmFasm
-+ccTcc, ccPcc, ccUcc, ccIcl, asmFasm, ccEGcc
- TInfoCCProp* = enum # properties of the C compiler:
- hasSwitchRange, # CC allows ranges in switch statements (GNU C)
- hasComputedGoto, # CC has computed goto (GNU C extension)
-@@ -69,8 +69,8 @@ compiler gcc:
- result = (
- name: "gcc",
- objExt: "o",
--optSpeed: " -O3 -ffast-math ",
--optSize: " -Os -ffast-math ",
-+optSpeed: " -O2 ",
-+optSize: " -Os ",
- compilerExe: "gcc",
- cppCompiler: "g++",
- compileTmpl: "-c $options $include -o $objfile $file",
-@@ -90,6 +90,13 @@ compiler gcc:
- props: {hasSwitchRange, hasComputedGoto, hasCpp, hasGcGuard, hasGnuAsm,
- hasAttribute})
-
-+compiler egcc:
-+result = gcc()
-+
-+result.name = "egcc"
-+result.compilerExe = "egcc"
-+result.cppCompiler = "eg++"
-+
- # LLVM Frontend for GCC/G++
- compiler llvmGcc:
- result = gcc() # Uses settings from GCC
-@@ -359,7 +366,8 @@ const
- pcc(),
- ucc(),
- icl(),
--fasm()]
-+fasm(),
-+egcc()]
-
- hExt* = ".h"
-
Index: patches/patch-config_nim_cfg
===
RCS file: /cvs/ports/lang/nim/patches/patch-config_nim_cfg,v
retrieving revision 1.3
diff -u -p -r1.3 patch-config_nim_cfg
--- patches/patch-config_nim_cfg9 Jan 2017 10:32:33 -
Re: NEW: devel/arduino-esp32 1.0.4
On Sun, Apr 12, 2020 at 10:49:24AM +0200, Paco Esteban wrote: > On Mon, 06 Apr 2020, Tracey Emery wrote: > > > Hello, > > > > This new port is the framework to program Espressif ESP32 chipsets via > > the Arduino environment. > > > > Used and tested on amd64 for a few months. > > > > OK? > > Cannot test this one as I do not have any ESP32 boards. The port builds > and installs fine as a dependency of devel/makeesparduino on amd64. > > > -- > Paco Esteban. > 0x5818130B8A6DBC03 During compile testing, Paco discovered that a python symlink is required for generating the bin files for the esp32. The attached port has a patch adjustment to fix that problem. OK? -- Tracey Emery arduino-esp32-1.0.4.tgz Description: Binary data
Re: [sparc64/base-gcc/ld.bfd] Fix build of x11/libhandy
On Thu, Mar 26, 2020 at 10:41:42AM -0400, Kurt Mosiejczuk wrote:
> On Thu, Mar 26, 2020 at 03:10:04AM +0100, Jeremie Courreges-Anglas wrote:
> > On Tue, Mar 24 2020, Kurt Mosiejczuk wrote:
> > > x11/libhandy needs ports-gcc on base-gcc architectures and needs
> > > -L${X11BASE}/lib added to CFLAGS to build properly on base-gcc
> > > architectures.
> > > No REVISION bump since it hasn't built on those other architectures
> > > before.
> > > (cc maintainer)
> > Just like for colord-gtk, I suspect it would be cleaner to use LDFLAGS
> > for this kind of tweak, but that requires adding LDFLAGS to
> > CONFIGURE_ENV (meson.port.mk doesn't do it).
> > Also cc'ing Antoine who maintains colord-gtk, it would be good to
> > discuss this in a single email thread.
> Here's a version of the libhandy diff that uses LDFLAGS like in
> your diff for colord-gtk
Ping
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/x11/libhandy/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile2 Nov 2019 11:12:35 - 1.4
+++ Makefile26 Mar 2020 14:25:26 -
@@ -16,6 +16,9 @@ MAINTAINER = Jasper Lievisse Adriaanse
# LGPLv2.1
PERMIT_PACKAGE = Yes
+COMPILER = base-clang ports-gcc
+COMPILER_LANGS = c
+
MODULES = devel/meson
WANTLIB += atk-1.0 cairo gdk-3 gdk_pixbuf-2.0 gio-2.0 glib-2.0
@@ -26,8 +29,15 @@ RUN_DEPENDS =devel/gobject-introspecti
lang/vala
LIB_DEPENDS = x11/gtk+3
+
CONFIGURE_ARGS += -Dglade_catalog=disabled \
-Dexamples=false
+CONFIGURE_ENV =LDFLAGS=${LDFLAGS}
+
+.include
+.if !${PROPERTIES:Mlld}
+LDFLAGS = -L${X11BASE}/lib
+.endif
TEST_IS_INTERACTIVE = X11
Re: [ld.bfd/sparc64] Fix build of misc/dtcltiny
On Fri, Mar 27, 2020 at 12:27:50PM -0400, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2020-03-21/misc/dtcltiny.log
> This fixes the build of misc/dtcltiny for sparc64 (and, presumably, other
> ld.bfd architectures).
> Not sure if the REVISION bump is necessary or not...
> cc maintainer
ping
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/misc/dtcltiny/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile3 Feb 2020 12:40:23 - 1.12
+++ Makefile27 Mar 2020 16:26:03 -
@@ -5,6 +5,7 @@ COMMENT = small SRCP client to control
EPOCH =0
DISTNAME = dtcltiny-0.4.5
CATEGORIES = misc x11
+REVISION = 0
HOMEPAGE = http://dtcltiny.sourceforge.net/
MAINTAINER = Sebastian Reitenbach
@@ -20,9 +21,12 @@ WANTLIB += Qt5Core Qt5Gui Qt5Network Qt
COMPILER = base-clang ports-gcc base-gcc
+LDFLAGS = -L${LOCALBASE}/lib \
+ -L${X11BASE}/lib
+
USE_GMAKE =Yes
CONFIGURE_STYLE = gnu
-CONFIGURE_ENV =LDFLAGS=-L${LOCALBASE}/lib
CFLAGS=-I${LOCALBASE}/include \
+CONFIGURE_ENV =LDFLAGS="${LDFLAGS}"
CFLAGS=-I${LOCALBASE}/include \
UIC_PATH=${MODQT_UIC}
CONFIGURE_ARGS = --with-qt-libraries=${MODQT_LIBDIR} \
--with-qt-includes=${MODQT_INCDIR}
Re: [base-gcc/sparc64] Fix build for x11/mate/control-center
On Sat, Mar 28, 2020 at 01:03:26AM -0400, Kurt Mosiejczuk wrote:
> This is just like gnome/control-center. It needs C99.
> ok?
ping
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/x11/mate/control-center/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile21 Mar 2020 16:14:54 - 1.21
+++ Makefile28 Mar 2020 05:01:57 -
@@ -46,4 +46,6 @@ FAKE_FLAGS= sysconfdir=${PREFIX}/share/
CONFIGURE_STYLE= gnu
+CFLAGS += -std=gnu99
+
.include
Re: NEW: devel/dyncall
On Mon, Apr 06, 2020 at 02:06:01PM -0400, Kurt Mosiejczuk wrote: > dyncall is a library used in lwjgl 3.x which I've been working on. > This looked straightforward. It just produces static libraries, which > seems weird to me. This is my first port using cmake, so if I did > anything wrong, let me know. portcheck and port-lib-depends-check > are both happy though. > DESCR: > The dyncall library encapsulates architecture-, OS- and compiler-specific > function call semantics in a virtual bind argument parameters from > left to right and then call interface allowing programmers to call > C functions in a completely dynamic manner. In other words, instead > of calling a function directly, the dyncall library provides a > mechanism to push the function parameters manually and to issue the > call afterwards. This means, that a program can determine at runtime > what function to call, and what parameters to pass to it. The library > is written in C and assembly and provides a very simple C interface > to program against. > ok? comments? ping --Kurt dyncall.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/04/13 11:01:46 Modified files: multimedia/motion: Makefile distinfo Log message: update to motion-4.3.1
[sparc64/base-gcc] Fix build of x11/spice-gtk
Two things cause the build to fail on sparc64: "-Werror" and the need
for C99.
There are a bunch of deprecated functions that throw warnings and -Werror
aborts the build, so there is a patch to remove that from meson.build.
The C99 is fixed by adding -std=gnu99 to CFLAGS.
This patch fixes the build on sparc64 (And presumably other base-gcc
arches).
cc maintainer
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/x11/spice-gtk/Makefile,v
retrieving revision 1.45
diff -u -p -r1.45 Makefile
--- Makefile3 Apr 2020 10:32:09 - 1.45
+++ Makefile13 Apr 2020 16:30:50 -
@@ -65,4 +65,7 @@ CONFIGURE_ARGS += -Dpolkit=disabled
# XXX requires the makecontext function (ucontext)
CONFIGURE_ARGS += -Dcoroutine=gthread
+# base-gcc doesn't default to c99
+CFLAGS += -std=gnu99
+
.include
Index: patches/patch-subprojects_spice-common_meson_build
===
RCS file: patches/patch-subprojects_spice-common_meson_build
diff -N patches/patch-subprojects_spice-common_meson_build
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-subprojects_spice-common_meson_build 13 Apr 2020 16:30:50
-
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+Deprecated functions means -Werror aborts the build
+
+Index: subprojects/spice-common/meson.build
+--- subprojects/spice-common/meson.build.orig
subprojects/spice-common/meson.build
+@@ -12,7 +12,6 @@ endif
+
+ # some global vars
+ spice_common_global_cflags = ['-DG_LOG_DOMAIN="Spice"',
+- '-Werror',
+ '-Wno-unused-parameter']
+
+ if get_option('alignment-checks')
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/04/13 10:25:42 Modified files: www/tor-browser/browser: Makefile distinfo www/tor-browser/browser/pkg: PLIST Added files: www/tor-browser/browser/files: tor-browser www/tor-browser/browser/patches: patch-toolkit_moz_configure patch-tor-browser_en-US_Browser_TorBrowser_Data_fontconfig_fonts_conf Log message: www/tor-browser: add defence against font fingerprinting, from maintainer Caspar Schutijser
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/04/13 10:12:25 Modified files: net/dhcpcd : Makefile distinfo net/dhcpcd/pkg : PLIST Removed files: net/dhcpcd/patches: patch-src_if-bsd_c Log message: update to dhcpcd-9.0.1
Re: [UPDATE] lang/nim-1.2.0
On 2020/04/13 17:20, Denis Fondras wrote:
> On Mon, Apr 13, 2020 at 08:29:23AM -0600, j...@bitminer.ca wrote:
> > Hi Denis,
> >
> > I think there is still an issue with the nimble install (thanks for
> > that by the way, I was thinking of this myself):
> >
> > > do-install:
> > > ${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
> > > ${INSTALL_PROGRAM} ${WRKSRC}/bin/nim ${PREFIX}/bin
> > > + ${INSTALL_PROGRAM} ${WRKSRC}/bin/nimble ${PREFIX}/bin
> > > ${INSTALL_DATA_DIR} ${PREFIX}/lib/nim
> > > cp -R ${WRKSRC}/lib/* ${PREFIX}/lib/nim
> > > chown -R ${LIBOWN}:${LIBGRP} ${PREFIX}/lib/nim
> > > ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/nim
> > > ${INSTALL_DATA} ${WRKSRC}/doc/*.txt ${PREFIX}/share/doc/nim
> > > + ${INSTALL_DATA_DIR} ${WRKINST}/etc/nim
> > > + ${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${WRKINST}/etc/nim
> >
> > The right-hand-side of ${INSTALL_DATA} or _DIR should include ${PREFIX}
> > not ${WRKINST}, no?
> >
>
> I don't know what I am doing, this is very "trial-and-error".
> What I noticed is that using ${WRKINST} allows to copy files to /etc instead
> of
> /usr/local/etc.
>
They aren't included in the package though. Those files are already handled
by copying them to share/examples and then @sample'd to ${SYSCONFDIR}/nim.cfg
etc.
in the PLIST.
Re: [UPDATE] lang/nim-1.2.0
On Mon, Apr 13, 2020 at 08:29:23AM -0600, j...@bitminer.ca wrote:
> Hi Denis,
>
> I think there is still an issue with the nimble install (thanks for
> that by the way, I was thinking of this myself):
>
> > do-install:
> > ${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
> > ${INSTALL_PROGRAM} ${WRKSRC}/bin/nim ${PREFIX}/bin
> > + ${INSTALL_PROGRAM} ${WRKSRC}/bin/nimble ${PREFIX}/bin
> > ${INSTALL_DATA_DIR} ${PREFIX}/lib/nim
> > cp -R ${WRKSRC}/lib/* ${PREFIX}/lib/nim
> > chown -R ${LIBOWN}:${LIBGRP} ${PREFIX}/lib/nim
> > ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/nim
> > ${INSTALL_DATA} ${WRKSRC}/doc/*.txt ${PREFIX}/share/doc/nim
> > + ${INSTALL_DATA_DIR} ${WRKINST}/etc/nim
> > + ${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${WRKINST}/etc/nim
>
> The right-hand-side of ${INSTALL_DATA} or _DIR should include ${PREFIX}
> not ${WRKINST}, no?
>
I don't know what I am doing, this is very "trial-and-error".
What I noticed is that using ${WRKINST} allows to copy files to /etc instead of
/usr/local/etc.
Re: Tor Browser font fingerprinting defense
On Mon, Apr 13, 2020 at 12:01:16PM +0100, Stuart Henderson wrote:
> On 2020/04/12 20:36, Caspar Schutijser wrote:
> > On Fri, Apr 10, 2020 at 09:24:31PM +0200, Caspar Schutijser wrote:
> > > Below is a WIP diff that makes font fingerprinting defense work in
> > > our port of Tor Browser.
> >
> > Thanks for your feedback from both of you. I incorporated sthen@'s
> > feedback in the diff below (and besides that there's some fixes and
> > cleanup compared to the previous diff).
> >
> > I haven't received any test reports yet but as far as I can see, this
> > diff works as advertised. Further feedback is welcome, of course.
>
> Could you change how the js change is done please, normally patches are
> a better idea for non-bulk changes like this, but it results in a line
> containing UTF-8 in the patch context which I think is likely to cause
> some future problems with sending/applying diffs - this should do the
> trick:
>
> sed -i 's/#ifdef XP_LINUX/#if defined(XP_LINUX) ||
> defined(XP_OPENBSD)/' \
> ${WRKSRC}/browser/app/profile/000-tor-browser.js
Yes, of course. The diff below does that. Thanks. Briefly tested on
amd64.
Index: browser/Makefile
===
RCS file: /cvs/ports/www/tor-browser/browser/Makefile,v
retrieving revision 1.43
diff -u -p -r1.43 Makefile
--- browser/Makefile9 Apr 2020 21:15:29 - 1.43
+++ browser/Makefile13 Apr 2020 15:06:20 -
@@ -16,9 +16,12 @@ PATCHORIG = .pat.orig
PKGNAME = ${TB_PREFIX}-browser-${TB_VERSION}
DISTNAME = src-firefox-tor-browser-68.7.0esr-9.0-2-build1
+REVISION = 0
+FIX_EXTRACT_PERMISSIONS= Yes
DISTFILES += ${DISTNAME}.tar.xz \
- src-tor-launcher-${TL_VERSION}.tar.xz
+ src-tor-launcher-${TL_VERSION}.tar.xz \
+ tor-browser-linux64-${TB_VERSION}_en-US.tar.xz
SO_VERSION = 5.0
MOZILLA_LIBS = xul clearkey lgpllibs mozavcodec mozavutil mozgtk
@@ -99,6 +102,7 @@ CONFIGURE_ARGS +=--with-libclang-path=$
CONFIGURE_ARGS += --with-clang-path=${LOCALBASE}/bin/clang
post-extract:
+ mv ${WRKDIR}/tor-browser_en-US ${WRKSRC}
mv ${WRKDIR}/tor-launcher-${TL_VERSION}/ \
${WRKSRC}/browser/extensions/tor-launcher
@@ -112,11 +116,17 @@ post-patch:
${SUBST_CMD}
${WRKSRC}/browser/extensions/tor-launcher/src/defaults/preferences/torlauncher-prefs.js
sed -i 's/"files":{[^}]*}/"files":{}/' \
${WRKSRC}/third_party/rust/bindgen/.cargo-checksum.json
+ # Not using a patch for this; patch context would contain UTF-8
+ sed -i 's/#ifdef XP_LINUX/#if defined(XP_LINUX) ||
defined(XP_OPENBSD)/' \
+ ${WRKSRC}/browser/app/profile/000-tor-browser.js
BROWSER_DIR = ${PREFIX}/lib/${BROWSER_NAME}
+TRUEBROWSER_DIR = ${TRUEPREFIX}/lib/${BROWSER_NAME}
BROWSER_CFG = ${BROWSER_DIR}/${BROWSER_NAME}.cfg
BROWSER_INI = ${BROWSER_DIR}/distribution/distribution.ini
+SUBST_VARS += TRUEBROWSER_DIR
+
post-install:
# install prefs, bookmarks, app config file for Tor browser
${INSTALL_DATA_DIR} ${BROWSER_DIR}/browser/defaults/preferences
@@ -150,5 +160,19 @@ post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/${BROWSER_NAME}
${SUBST_DATA} ${FILESDIR}/torrc-defaults \
${PREFIX}/share/${BROWSER_NAME}/torrc-defaults
+
+ # install fonts.conf and fonts
+ ${INSTALL_DATA_DIR} ${BROWSER_DIR}/browser/fontconfig
+ ${SUBST_DATA} \
+
${WRKSRC}/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig/fonts.conf \
+ ${BROWSER_DIR}/browser/fontconfig/fonts.conf
+ ${INSTALL_DATA_DIR} ${BROWSER_DIR}/browser/fonts
+ cp ${WRKSRC}/tor-browser_en-US/Browser/fonts/* \
+ ${BROWSER_DIR}/browser/fonts
+
+ # install wrapper script (remove symlink first)
+ rm ${PREFIX}/bin/${BROWSER_NAME}
+ ${SUBST_PROGRAM} ${FILESDIR}/${BROWSER_NAME} \
+ ${PREFIX}/bin/${BROWSER_NAME}
.include
Index: browser/distinfo
===
RCS file: /cvs/ports/www/tor-browser/browser/distinfo,v
retrieving revision 1.22
diff -u -p -r1.22 distinfo
--- browser/distinfo9 Apr 2020 21:15:29 - 1.22
+++ browser/distinfo13 Apr 2020 15:06:20 -
@@ -1,4 +1,6 @@
SHA256 (mozilla/src-firefox-tor-browser-68.7.0esr-9.0-2-build1.tar.xz) =
3paD2CYF+AUbO1xO0rAIHXSFqSGQeJmpJzg6F3/I+vg=
SHA256 (mozilla/src-tor-launcher-0.2.20.5.tar.xz) =
LVEbHAxcGf49cC8NF4bVYfFD7k2GA8SX+f+VA5p7L4U=
+SHA256 (mozilla/tor-browser-linux64-9.0.9_en-US.tar.xz) =
z5ELlXfclLz+72D+mQTn+PKSd78ac2BgDDKVYiXQRHM=
SIZE (mozilla/src-firefox-tor-browser-68.7.0esr-9.0-2-build1.tar.xz) =
348594032
SIZE (mozilla/src-tor-launcher-0.2.20.5.tar.xz) = 210916
+SIZE (mozilla/tor-browser-linux64-9.0.9_en-US.tar.xz) = 80156396
Index:
Re: [UPDATE] lang/nim-1.2.0
Hi Denis,
I think there is still an issue with the nimble install (thanks for
that by the way, I was thinking of this myself):
do-install:
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
${INSTALL_PROGRAM} ${WRKSRC}/bin/nim ${PREFIX}/bin
+ ${INSTALL_PROGRAM} ${WRKSRC}/bin/nimble ${PREFIX}/bin
${INSTALL_DATA_DIR} ${PREFIX}/lib/nim
cp -R ${WRKSRC}/lib/* ${PREFIX}/lib/nim
chown -R ${LIBOWN}:${LIBGRP} ${PREFIX}/lib/nim
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/nim
${INSTALL_DATA} ${WRKSRC}/doc/*.txt ${PREFIX}/share/doc/nim
+ ${INSTALL_DATA_DIR} ${WRKINST}/etc/nim
+ ${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${WRKINST}/etc/nim
The right-hand-side of ${INSTALL_DATA} or _DIR should include ${PREFIX}
not ${WRKINST}, no?
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/nim
${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${PREFIX}/share/examples/nim
As used here.
John
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2020/04/13 08:34:37 Modified files: www/kcgi : Makefile distinfo www/kcgi/pkg : PLIST Log message: Update kcgi to 0.12.0. See https://kristaps.bsd.lv/kcgi/archive.html for release notes.
Re: wip: mail/notmuch
Hi Olivier, On 2020-04-10 20:21, Olivier Taïbi wrote: Here is further progress on this port, following versions by Enric Morales and Stuart Henderson. I hope that this does not duplicate your efforts. Thanks a lot for providing your effort. It's great that you are working on this too, since I haven't had the time lately nor the knowledge. How is it working on your end? Any unstability so far?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/04/13 08:02:59 Modified files: www/webkitgtk4 : Makefile distinfo Log message: Update to webkitgtk4-2.28.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/04/13 07:50:19 Modified files: audio/mumble : Makefile Log message: unbreak pkgnames. hopefully nobody built from this in the meantime because handling an update from the invalid pkgname is way more hassle than it's worth.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/04/13 07:18:36 Modified files: infrastructure/db: user.list audio/mumble : Makefile Added files: audio/mumble/patches: patch-scripts_murmur_ini audio/mumble/pkg: DESCR-main DESCR-server PLIST-main PLIST-server murmurd.rc Removed files: audio/mumble/pkg: DESCR PLIST Log message: Build and package Mumble server component (murmur) Simple MULTI_PACKAGES addition, no FLAVOR. Diff from Thomas L. - thanks! Tweaks and tests from me "pkg_add murmur && rcctl start murmurd" just works on amd64 and sparc64
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/04/13 05:05:50 Modified files: net/dnsmasq: Makefile distinfo net/dnsmasq/patches: patch-dnsmasq_conf_example patch-man_dnsmasq_8 patch-src_config_h net/dnsmasq/pkg: PLIST Removed files: net/dnsmasq/patches: patch-src_forward_c Log message: update to dnsmasq-2.81, from Brad
Re: UPDATE: math/ebc 2.6.0 => 2.6.1 && rename package ebc => bc-gh
> > "+@pkgpath math/ebc" in PLIST only makes sense if you move this port to > > ports/math/bc-gh (I would support this move). > > > > That can certainly be done if that's the consensus. Makes sense. Whatever happens to the port directory name, changing the PKGNAME from ebc to bc-gh requires a quirks entry.
Re: Tor Browser font fingerprinting defense
On 2020/04/12 20:36, Caspar Schutijser wrote:
> On Fri, Apr 10, 2020 at 09:24:31PM +0200, Caspar Schutijser wrote:
> > Below is a WIP diff that makes font fingerprinting defense work in
> > our port of Tor Browser.
>
> Thanks for your feedback from both of you. I incorporated sthen@'s
> feedback in the diff below (and besides that there's some fixes and
> cleanup compared to the previous diff).
>
> I haven't received any test reports yet but as far as I can see, this
> diff works as advertised. Further feedback is welcome, of course.
Could you change how the js change is done please, normally patches are
a better idea for non-bulk changes like this, but it results in a line
containing UTF-8 in the patch context which I think is likely to cause
some future problems with sending/applying diffs - this should do the
trick:
sed -i 's/#ifdef XP_LINUX/#if defined(XP_LINUX) ||
defined(XP_OPENBSD)/' \
${WRKSRC}/browser/app/profile/000-tor-browser.js
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/04/13 04:29:36 Added files: www/chromium/patches: patch-content_public_browser_BUILD_gn Log message: add a missing internal dependency to avoid random build order failures during bulks
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/04/13 02:50:23 Removed files: cad/qcad/patches: patch-src_core_RSPlatform_cpp Log message: Remove patch. Forgotten in the last update commit
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/04/13 02:48:39 Modified files: cad/qcad : Makefile distinfo cad/qcad/patches: patch-scripts_Help_About_About_js patch-scripts_Widgets_CommandLine_CommandLine_js patch-src_core_RSettings_cpp cad/qcad/pkg : PLIST Log message: Update qcad to 3.24.3 OK paco@
Re: update: www/weboob 2.0
On Mon, Apr 13, 2020 at 07:17:03AM +0200, Sebastien Marie wrote: > On Wed, Apr 08, 2020 at 09:22:42AM +0200, Sebastien Marie wrote: > > Hi, > > > > The following diff update www/weboob to 2.0 > > I intent to commit it in the next days. > > Please note that keeping 1.5 for release is very useless: weboob is a web > scraping tool, websites are moving fast, and 1.5 serie doesn't receive modules > update anymore. > it worked for the few modules I use so I guess you can update ok solene@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/04/13 02:09:35 Modified files: net/wireshark/patches: patch-ui_qt_capture_interfaces_dialog_cpp Log message: wireshark: committed upstream
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/04/13 01:10:09 Modified files: x11/xfce4/xfce4-settings: Makefile distinfo x11/xfce4/xfce4-settings/pkg: PLIST Log message: Update to xfce4-settings 4.14.3
Re: Go and portgen(1)
On Mon, Apr 13, 2020 at 08:44:47AM +0200, Landry Breuil wrote:
> On Mon, Apr 06, 2020 at 05:15:17PM -0600, Aaron Bieber wrote:
> > Round two! This time with espie@'s bsd.port.mk fix:
> > https://marc.info/?l=openbsd-ports-cvs=158618354824687=2
> >
> > This resolves the issue with the conversion of [A-Z] letters to ![a-z] in
> > the
> > package path.
> >
> > With this diff I can generate ports for the following without issue:
> >
> > github.com/jrick/domain
> > github.com/jrick/ss
> > github.com/junegunn/fzf
> > github.com/qbit/gavin
> > golang.zx2c4.com/wireguard
> > humungus.tedunangst.com/r/honk
> > suah.dev/ogvt
> >
> > There are still some issues with things like github.com/restic/restic and
> > github.com/gohugoio/hugo . For some reason the build looks for some files
> > that
> > 'go mod graph' doesn't list.
> >
> > For most go apps that follow the module guidelines:
> > https://github.com/golang/go/wiki/Modules
>
> I wanted to port vgrep so i gave this a shot:
>
> [08:29] c64:/usr/ports/ $/usr/ports/infrastructure/bin/portgen go
> github.com/vrothberg/vgrep
> Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
> mystuff/go/vgrep)
> *** Error 1 in /home/ports/mystuff/go/vgrep
> (/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
> Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
> mystuff/go/vgrep)
> *** Error 1 in /home/ports/mystuff/go/vgrep
> (/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
> Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
> mystuff/go/vgrep)
> *** Error 1 in /home/ports/mystuff/go/vgrep
> (/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
> Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
> mystuff/go/vgrep)
> *** Error 1 in /home/ports/mystuff/go/vgrep
> (/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
> Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
> mystuff/go/vgrep)
> *** Error 1 in /home/ports/mystuff/go/vgrep
> (/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
> Can't stat : No such file or directory
> at /usr/ports/infrastructure/lib/OpenBSD/PortGen/Port.pm line 251.
> Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
> mystuff/go/vgrep)
> *** Error 1 in /home/ports/mystuff/go/vgrep
> (/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
> Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
> mystuff/go/vgrep)
> *** Error 1 in /home/ports/mystuff/go/vgrep
> (/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
> Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
> mystuff/go/vgrep)
> *** Error 1 in /home/ports/mystuff/go/vgrep
> (/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
> /usr/ports/mystuff/go/vgrep
>
> that's a lot of yelling at a user :)
>
> that generated this (under mystuff/go/vgrep):
>
> # $OpenBSD$
>
> COMMENT = todo
>
> MODGO_MODNAME = github.com/vrothberg/vgrep
> MODGO_VERSION = v0.0.0-20200412142857-0810837a928d
>
> DISTNAME = vgrep-${MODGO_VERSION}
> PKGNAME = vgrep-20200412142857
>
> CATEGORIES =go
>
> # unknown license -> 'unknown license'
> PERMIT_PACKAGE =unknown license
> PERMIT_DISTFILES = unknown license
>
> MODULES = lang/go
>
> MODGO_MODULES = github.com/davecgh/go-spew
> v1.1.1 \
> github.com/jessevdk/go-flags
> v1.4.0 \
> github.com/konsorten/go-windows-terminal-sequences
> v1.0.2 \
> github.com/kr/pretty
> v0.1.0 \
> github.com/kr/pty
> v1.1.1 \
> github.com/kr/text
> v0.1.0 \
> github.com/nightlyone/lockfile
> v0.0.0-20180618180623-0ad87eef1443 \
> github.com/pmezard/go-difflib
> v1.0.0 \
> github.com/sirupsen/logrus
> v1.5.0 \
> github.com/stretchr/objx
> v0.1.0 \
> github.com/stretchr/testify
> v1.4.0 \
> golang.org/x/sys
> v0.0.0-20191218084908-4a24b4065292 \
> gopkg.in/check.v1
> v1.0.0-20180628173108-788fd7840127 \
> gopkg.in/yaml.v2
> v2.2.2
> MODGO_MODFILES =github.com/davecgh/go-spew
>v1.1.0 \
> github.com/davecgh/go-spew
>v1.1.1 \
>
Re: Go and portgen(1)
On Mon, Apr 06, 2020 at 05:15:17PM -0600, Aaron Bieber wrote:
> Round two! This time with espie@'s bsd.port.mk fix:
> https://marc.info/?l=openbsd-ports-cvs=158618354824687=2
>
> This resolves the issue with the conversion of [A-Z] letters to ![a-z] in the
> package path.
>
> With this diff I can generate ports for the following without issue:
>
> github.com/jrick/domain
> github.com/jrick/ss
> github.com/junegunn/fzf
> github.com/qbit/gavin
> golang.zx2c4.com/wireguard
> humungus.tedunangst.com/r/honk
> suah.dev/ogvt
>
> There are still some issues with things like github.com/restic/restic and
> github.com/gohugoio/hugo . For some reason the build looks for some files that
> 'go mod graph' doesn't list.
>
> For most go apps that follow the module guidelines:
> https://github.com/golang/go/wiki/Modules
I wanted to port vgrep so i gave this a shot:
[08:29] c64:/usr/ports/ $/usr/ports/infrastructure/bin/portgen go
github.com/vrothberg/vgrep
Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
mystuff/go/vgrep)
*** Error 1 in /home/ports/mystuff/go/vgrep
(/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
mystuff/go/vgrep)
*** Error 1 in /home/ports/mystuff/go/vgrep
(/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
mystuff/go/vgrep)
*** Error 1 in /home/ports/mystuff/go/vgrep
(/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
mystuff/go/vgrep)
*** Error 1 in /home/ports/mystuff/go/vgrep
(/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
mystuff/go/vgrep)
*** Error 1 in /home/ports/mystuff/go/vgrep
(/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
Can't stat : No such file or directory
at /usr/ports/infrastructure/lib/OpenBSD/PortGen/Port.pm line 251.
Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
mystuff/go/vgrep)
*** Error 1 in /home/ports/mystuff/go/vgrep
(/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
mystuff/go/vgrep)
*** Error 1 in /home/ports/mystuff/go/vgrep
(/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
Fatal: one category in go lang/go should match PKGPATH=mystuff/go/vgrep (in
mystuff/go/vgrep)
*** Error 1 in /home/ports/mystuff/go/vgrep
(/usr/ports/infrastructure/mk/bsd.port.mk:3691 '.BEGIN': @exit 1)
/usr/ports/mystuff/go/vgrep
that's a lot of yelling at a user :)
that generated this (under mystuff/go/vgrep):
# $OpenBSD$
COMMENT = todo
MODGO_MODNAME = github.com/vrothberg/vgrep
MODGO_VERSION = v0.0.0-20200412142857-0810837a928d
DISTNAME = vgrep-${MODGO_VERSION}
PKGNAME = vgrep-20200412142857
CATEGORIES =go
# unknown license -> 'unknown license'
PERMIT_PACKAGE =unknown license
PERMIT_DISTFILES = unknown license
MODULES = lang/go
MODGO_MODULES = github.com/davecgh/go-spew v1.1.1
\
github.com/jessevdk/go-flags v1.4.0
\
github.com/konsorten/go-windows-terminal-sequences v1.0.2
\
github.com/kr/pretty v0.1.0
\
github.com/kr/ptyv1.1.1
\
github.com/kr/text v0.1.0
\
github.com/nightlyone/lockfile
v0.0.0-20180618180623-0ad87eef1443 \
github.com/pmezard/go-difflibv1.0.0
\
github.com/sirupsen/logrus v1.5.0
\
github.com/stretchr/objx v0.1.0
\
github.com/stretchr/testify v1.4.0
\
golang.org/x/sys
v0.0.0-20191218084908-4a24b4065292 \
gopkg.in/check.v1
v1.0.0-20180628173108-788fd7840127 \
gopkg.in/yaml.v2 v2.2.2
MODGO_MODFILES =github.com/davecgh/go-spew
v1.1.0 \
github.com/davecgh/go-spew
v1.1.1 \
github.com/jessevdk/go-flags
v1.4.0 \
github.com/konsorten/go-windows-terminal-sequences
v1.0.1 \
github.com/konsorten/go-windows-terminal-sequences
v1.0.2 \
github.com/kr/pretty
