sparc64 bulk build report
Bulk build on sparc64-0.ports.openbsd.org Started : Fri May 1 08:27:17 MDT 2020 Finished: Sun May 3 18:51:33 MDT 2020 Duration: 2 Days 10 hours 24 minutes Built using OpenBSD 6.7-beta (GENERIC.MP) #301: Fri May 1 01:27:58 MDT 2020 Built 9913 packages Number of packages built each day: May 1: 7338 May 2: 2030 May 3: 545 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2020-05-01/summary.log Build failures: 7 http://build-failures.rhaalovely.net/sparc64/2020-05-01/graphics/birdfont.log http://build-failures.rhaalovely.net/sparc64/2020-05-01/graphics/libavif.log http://build-failures.rhaalovely.net/sparc64/2020-05-01/lang/hashlink.log http://build-failures.rhaalovely.net/sparc64/2020-05-01/productivity/gnucash.log http://build-failures.rhaalovely.net/sparc64/2020-05-01/x11/gnome/builder.log http://build-failures.rhaalovely.net/sparc64/2020-05-01/x11/gtk+4,-cloudprint.log http://build-failures.rhaalovely.net/sparc64/2020-05-01/x11/py-qt5,python3.log Recurrent failures: failures/graphics/libavif.log failures/lang/hashlink.log failures/x11/gnome/builder.log failures/x11/py-qt5,python3.log New failures: +failures/graphics/birdfont.log +failures/productivity/gnucash.log +failures/x11/gtk+4,-cloudprint.log Resolved failures: -failures/net/gnugk.log -failures/textproc/apertium-dicts/id-ms.log -failures/www/tomcat/v9.log -failures/www/webkitgtk4.log -failures/x11/gigolo.log -failures/x11/gnome/autoar.log -failures/x11/gnome/baobab.log -failures/x11/gnome/bijiben.log -failures/x11/gnome/books.log -failures/x11/gnome/calculator.log -failures/x11/gnome/calendar.log -failures/x11/gnome/characters.log -failures/x11/gnome/clocks.log -failures/x11/gnome/color-manager.log -failures/x11/gnome/contacts.log -failures/x11/gnome/control-center.log -failures/x11/gnome/dconf-editor.log -failures/x11/gnome/desktop.log -failures/x11/gnome/devhelp.log -failures/x11/gnome/dictionary.log -failures/x11/gnome/documents.log -failures/x11/gnome/eog.log -failures/x11/gnome/file-roller.log -failures/x11/gnome/font-viewer.log -failures/x11/gnome/gdl.log -failures/x11/gnome/gdm.log -failures/x11/gnome/gedit.log -failures/x11/gnome/grilo-plugins.log -failures/x11/gnome/grilo.log -failures/x11/gnome/gucharmap.log -failures/x11/gnome/gvfs,,-goa.log -failures/x11/gnome/initial-setup.log -failures/x11/gnome/keyring.log -failures/x11/gnome/libgnome.log -failures/x11/gnome/libgnomecanvas.log -failures/x11/gnome/libgnomeui.log -failures/x11/gnome/libgweather.log -failures/x11/gnome/maps.log -failures/x11/gnome/music.log -failures/x11/gnome/mutter.log -failures/x11/gnome/nautilus.log -failures/x11/gnome/online-accounts.log -failures/x11/gnome/online-miners.log -failures/x11/gnome/orca.log -failures/x11/gnome/photos.log -failures/x11/gnome/screenshot.log -failures/x11/gnome/session.log -failures/x11/gnome/settings-daemon.log -failures/x11/gnome/shell.log -failures/x11/gnome/sushi.log -failures/x11/gnome/system-monitor.log -failures/x11/gnome/terminal.log -failures/x11/gnome/themes-extra.log -failures/x11/gnome/todo.log -failures/x11/gnome/totem.log -failures/x11/gnome/tracker-miners.log -failures/x11/gnome/tweaks.log -failures/x11/gnome/usage.log -failures/x11/gnome/weather.log -failures/x11/gnome/yelp.log -failures/x11/gnome/zenity.log -failures/x11/gnustep/aclock.log -failures/x11/gnustep/affiche.log -failures/x11/gnustep/base.log -failures/x11/gnustep/batmon.log -failures/x11/gnustep/camera.log -failures/x11/gnustep/camerakit.log -failures/x11/gnustep/cdplayer.log -failures/x11/gnustep/corebase.log -failures/x11/gnustep/cynthiune.log -failures/x11/gnustep/databasin.log -failures/x11/gnustep/displaycalibrator.log -failures/x11/gnustep/edenmath.log -failures/x11/gnustep/examples.log -failures/x11/gnustep/fisicalab.log -failures/x11/gnustep/ftp.log -failures/x11/gnustep/gemas.log -failures/x11/gnustep/gmastermind.log -failures/x11/gnustep/gmines.log -failures/x11/gnustep/gnumail.log -failures/x11/gnustep/gomoku.log -failures/x11/gnustep/gorm.log -failures/x11/gnustep/graphos.log -failures/x11/gnustep/grr.log -failures/x11/gnustep/gshisen.log -failures/x11/gnustep/gspdf.log -failures/x11/gnustep/gworkspace.log -failures/x11/gnustep/imageviewer.log -failures/x11/gnustep/jigsaw.log -failures/x11/gnustep/lapispuzzle.log -failures/x11/gnustep/laternamagica.log -failures/x11/gnustep/make.log -failures/x11/gnustep/matharray.log -failures/x11/gnustep/mpdcon.log -failures/x11/gnustep/neos-theme.log -failures/x11/gnustep/netclasses.log -failures/x11/gnustep/paje.log -failures/x11/gnustep/price.log -failures/x11/gnustep/projectcenter.log -failures/x11/gnustep/remotedesk.log -failures/x11/gnustep/silver-theme.log -failures/x11/gnustep/simpleagenda.log -failures/x11/gnustep/sqlclient.log -failures/x11/gnustep/sudoku.log -failures/x11/gnustep/systempreferences.log -failures/x11/gnustep/terminal.log -failures/x11/gnustep/timemon.log -failures/x11/gnustep/webserver.log -failures/x11/gnustep/zipper.log
Re: [big endian] fix games/widelands colors
On Sat, May 02 2020, Charlene Wendling wrote:
> On Sat, 2 May 2020 00:38:01 +0200
> Charlene Wendling wrote:
>
>> On Fri, 01 May 2020 15:46:55 -0600
>> Anthony J. Bentley wrote:
>>
>> > Charlene Wendling writes:
>> > > On Fri, 01 May 2020 12:10:34 -0600
>> > > Anthony J. Bentley wrote:
>> > >
>> > > > Charlene Wendling writes:
>> > > > > Hi,
>> > > > >
>> > > > > Some texture colors are off on powerpc, upstream thinks it's
>> > > > > likely related to the old OpenGL versions or driver used on
>> > > > > macppc machines[0]. It's an obvious reminder, but all OpenGL
>> > > > > capable macppc machine are radeon(4) only.
>> > > > >
>> > > > > As such i'm proposing to mark it NOT_FOR_ARCHS, this saves 6
>> > > > > bulk machine hours.
>> > > > >
>> > > > > OK?
>> > > >
>> > > > Out of curiosity, does using software rendering look better?
>> > >
>> > > After a few minutes, the result is the same :)
>> >
>> > I'm speaking mostly from ignorance here, but this seems to suggest
>> > that it's not about the old OpenGL version; looking at glxinfo on
>> > one of my OpenGL 2.1 laptops, software rendering gives me OpenGL 3.3
>> > through llvmpipe.
>>
>> Even "native" and commercial Mac OS X games like postal have colors
>> off on macppc, making things difficult to analyse as i don't know
>> much as well, especially that i don't have Mac OS X on my macs so i
>> can't cross test without reinstalling; i don't have a spare IDE 2.5
>> disk.
>>
>
> So, as said somewhere else, i've pulled the trigger too early, another
> upstream member had a good guess :)
This has been merged into master upstream. Diff looks good, build on
amd64 / little-endian appears unaffected. ok jca@
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/widelands/Makefile,v
> retrieving revision 1.29
> diff -u -p -u -p -r1.29 Makefile
> --- Makefile 1 May 2020 21:17:03 - 1.29
> +++ Makefile 2 May 2020 17:01:59 -
> @@ -1,8 +1,5 @@
> # $OpenBSD: Makefile,v 1.29 2020/05/01 21:17:03 cwen Exp $
>
> -# See https://github.com/widelands/widelands/issues/3887
> -NOT_FOR_ARCHS = powerpc
> -
> COMMENT= economic and military simulation game
>
> V = 20
> @@ -10,7 +7,7 @@ DISTNAME = widelands-build${V}
> PKGNAME= widelands-0.${V}
> CATEGORIES= games
> EXTRACT_SUFX=.tar.bz2
> -REVISION=1
> +REVISION=2
>
> HOMEPAGE=https://wl.widelands.org/
> MASTER_SITES =
> https://launchpad.net/widelands/build${V}/build${V}/+download/
> Index: patches/patch-src_graphic_sdl_utils_cc
> ===
> RCS file: patches/patch-src_graphic_sdl_utils_cc
> diff -N patches/patch-src_graphic_sdl_utils_cc
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_graphic_sdl_utils_cc2 May 2020 17:01:59 -
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +
> +Fix colors on powerpc, see
> +https://github.com/widelands/widelands/pull/3890
> +
> +Index: src/graphic/sdl_utils.cc
> +--- src/graphic/sdl_utils.cc.orig
> src/graphic/sdl_utils.cc
> +@@ -23,6 +23,10 @@
> +
> + SDL_Surface* empty_sdl_surface(int16_t w, int16_t h) {
> + SDL_Surface* const surface =
> ++#if SDL_BYTEORDER == SDL_LIL_ENDIAN
> +SDL_CreateRGBSurface(SDL_SWSURFACE, w, h, 32, 0x00ff,
> 0xff00, 0x00ff, 0xff00);
> ++#else
> ++ SDL_CreateRGBSurface(SDL_SWSURFACE, w, h, 32, 0xff00,
> 0x00ff, 0xff00, 0x00ff);
> ++#endif
> + return surface;
> + }
>
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [sparc64/mips64] patch erlang21 to fix devel/rebar,erlang21
On Sat, May 02 2020, Kurt Mosiejczuk wrote:
> On Wed, Feb 19, 2020 at 05:06:53PM +1000, Jonathan Matthew wrote:
>> On Tue, Feb 18, 2020 at 11:49:43PM -0500, Kurt Mosiejczuk wrote:
>> > On Wed, Feb 19, 2020 at 11:48:28AM +1000, Jonathan Matthew wrote:
>
>> > > > I thought I'd have a look at this, since I'm actually using erlang
>> > > > on sparc64 now. The erlang21 flavor built, but the escriptized file
>> > > > ends up looking like this:
>
>> > > > -r-x--S--- 1 4087335480 1892169536 209098 Feb 19 07:36 rebar
>
>> > > > which looks like erlang21 is screwing up its chown and chmod syscalls.
>
>> > > This is fixed in otp 21.2.1, by this change:
>> > > https://github.com/erlang/otp/commit/df0638e021eb18a4271a02fdae08aa1779867209
>
>> > Based upon this information, here is a patch for lang/erlang/21 to add
>> > this patch to the current version.
>
>> > ok?
>
>> Looks good to me, and I built a package with this and it managed to build
>> rebar
>> with correct ownership and permissions.
>
> ok to commit this? I've been carrying the patch locally on the build cluster.
LGTM and indeed fixes the build of devel/rebar,erlang21. ok jca@
I think should should be in 6.7.
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/erlang/21/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- Makefile 25 Jun 2019 20:25:21 - 1.4
> +++ Makefile 3 May 2020 01:32:24 -
> @@ -13,8 +13,8 @@ PKGNAME=erlang-$V
> PKGNAME-main=erlang-$V
> PKGNAME-wx= erlang-wx-$V
>
> -REVISION-main= 2
> -REVISION-wx= 2
> +REVISION-main= 3
> +REVISION-wx= 3
>
> VERSION_SPEC=>=21v0,<22v0
> PKGSPEC-main=erlang-${VERSION_SPEC}
> Index: patches/patch-erts_emulator_nifs_common_prim_file_nif_c
> ===
> RCS file: patches/patch-erts_emulator_nifs_common_prim_file_nif_c
> diff -N patches/patch-erts_emulator_nifs_common_prim_file_nif_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-erts_emulator_nifs_common_prim_file_nif_c 3 May 2020
> 01:32:24 -
> @@ -0,0 +1,26 @@
> +$OpenBSD$
> +
> +erts: Fix warning and potential big-endian-bug in prim_file
> +https://github.com/erlang/otp/commit/df0638e021eb18a4271a02fdae08aa1779867209
> +
> +Index: erts/emulator/nifs/common/prim_file_nif.c
> +--- erts/emulator/nifs/common/prim_file_nif.c.orig
> erts/emulator/nifs/common/prim_file_nif.c
> +@@ -933,7 +933,7 @@ static ERL_NIF_TERM set_permissions_nif(ErlNifEnv *env
> + posix_errno_t posix_errno;
> +
> + efile_path_t path;
> +-Uint permissions;
> ++unsigned int permissions;
> +
> + if(argc != 2 || !enif_get_uint(env, argv[1], )) {
> + return enif_make_badarg(env);
> +@@ -952,7 +952,7 @@ static ERL_NIF_TERM set_owner_nif(ErlNifEnv *env, int
> + posix_errno_t posix_errno;
> +
> + efile_path_t path;
> +-Sint uid, gid;
> ++int uid, gid;
> +
> + if(argc != 3 || !enif_get_int(env, argv[1], )
> + || !enif_get_int(env, argv[2], )) {
>
<#secure method=pgpmime mode=sign>
--
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: j...@cvs.openbsd.org2020/05/03 16:37:29 Modified files: graphics/vulkan-loader: Makefile graphics/vulkan-loader/patches: patch-loader_CMakeLists_txt Log message: backout attempt to fix build on aarch64 Broke i386 as the clang 8.0 integrated assembler can not handle 'offset'. The amd64 path in the assembly does not use 'offset'. ok sthen@
Re: [macppc, !x86] Unbreak emulators/gsplus
Le Fri, 1 May 2020 23:40:59 +0200,
Charlene Wendling a écrit :
> Hi,
>
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/emulators/gsplus.log
>
> `__builtin_ppc_mftb()' is not available with clang.
>
> An easy solution would have been to change the ifdef, but as this is
> the same situation with retroarch [0], i preferred to use their logic.
> On top of that it should slightly improve the emulation on !{x86,ppc}.
>
> I don't know why upstream chose to #define a builtin, so it can't be
> applied on archs where it is native (x86). The intent of this patch is
> to be upstreamed so i preferred to stay minimal.
>
> This allows gsplus to be built on macppc, i can run System 6 without
> issues, excepted mouse clicks that don't register. The only other arch
> i have is amd64, where this diff makes no change.
>
> Comments/feedback are welcome,
>
> Charlène.
>
>
> [0] https://marc.info/?l=openbsd-ports-cvs=158816954508000=2
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/emulators/gsplus/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 Makefile
> --- Makefile 12 Mar 2020 12:24:08 - 1.1.1.1
> +++ Makefile 1 May 2020 21:36:37 -
> @@ -6,6 +6,7 @@ GH_ACCOUNT = digarok
> GH_PROJECT = gsplus
> GH_COMMIT = 480572054518112647c8fae5d7ea7046a6d6ecfb
> DISTNAME = ${GH_PROJECT}-20190816
> +REVISION = 0
>
> CATEGORIES = emulators
>
> Index: patches/patch-src_engine_c_c
> ===
> RCS file: patches/patch-src_engine_c_c
> diff -N patches/patch-src_engine_c_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_engine_c_c 1 May 2020 21:36:37 -
> @@ -0,0 +1,24 @@
> +$OpenBSD$
> +
> +Use posix timing to improve portability and avoid a build failure on
> +powerpc due to `__builtin_ppc_mftb' being gcc-specific.
> +
> +Index: src/engine_c.c
> +--- src/engine_c.c.orig
> src/engine_c.c
> +@@ -884,6 +884,15 @@ void fixed_memory_ptrs_shut() {
> +
> + #if defined(__i386__) || defined(__x86_64__)
> + #include
> ++ #elif defined(_POSIX_MONOTONIC_CLOCK)
> ++#include
> ++int64_t __rdtsc() {
> ++ struct timespec tp = {0};
> ++ int64_t timestamp = 0;
> ++ if (clock_gettime(CLOCK_MONOTONIC, ) == 0)
> ++timestamp = tp.tv_sec * 10 + tp.tv_nsec;
> ++ return timestamp;
> ++}
> + #elif defined(__powerpc__) || defined(__ppc__)
> + #define __rdtsc() __builtin_ppc_mftb()
> + #else
ok solene@
Is gsplus usable on powerpc?
Re: [UPDATE]: games/freeorion 0.49
May 2, 2020 11:16 AM, "Ingo Schwarze" wrote: > Hi Tom, > > Tom Murphy wrote on Fri, May 01, 2020 at 01:34:08PM +0100: > >> Any update on this? Can it be committed? >> (I am the maintainer) > > Thanks for working on this, but now is not the time to commit > an Update because we are preparing the OpenBSD 6.7 release > right now. Updating the game is non-essential for the release, > and besdes, FreeOrion is a very massive beast. > > I think this should better wait until after the release has been > rolled out of the door. > > Yours, > Ingo Hi Ingo, Not a problem, I know it was cutting it a bit fine. Hope the release process is going smoothly! Kind regards, Tom
Re: CVS: cvs.openbsd.org: ports
On 2020/05/03 15:20, Jonathan Gray wrote:
> >
> > The builtin assembler in clang 8.0 can not handle 'offset' here,
> > support was added in clang 10.0.
> >
> > While it should be possible to build with -fno-integrated-as on i386 to
> > force the use of gas this currently results in not being able to find
> > the generated gen_defines.asm file. I've not yet been able to convince
> > cmake to do the right thing with include paths. The file can not be
> > found even with an explicit -I${WRKBUILD}/loader/.
>
> So for release here is a revert.
Thanks, OK.
Re: pkg_add can't resolve package - bad major
Ian Darwin wrote: > On Sun, May 03, 2020 at 01:07:40PM +, katzeilla wrote: >> I am using OpenBSD 6.6 and I noticed that pkg_add can't install any new >> package: >> >> $ doas pkg_add emacs-26.3-no_x11 >> >> quirks-3.185 signed on 2020-04-30T09:14:52Z >> Can't install libxml-2.9.9 because of libraries >>|library iconv.7.0 not found >>| /usr/local/lib/libiconv.so.6.0 (libiconv-1.14p3): bad major > > Usual cause, and first thing to check, is using snapshot packages > on a -stable system. All ports development is done on -current > so newly-built ports can usually not be installed on the stable > version due to libraries. libiconv-1.16p0 is in 6.6 stable. libiconv-1.14p3 is in 6.5 stable. Did you forget to run "pkg_add -u" after the upgrade? Cheers, Stefan
Re: pkg_add can't resolve package - bad major
On Sun, May 03, 2020 at 01:07:40PM +, katzeilla wrote: > Hi everyone, > > I am using OpenBSD 6.6 and I noticed that pkg_add can't install any new > package: > > $ doas pkg_add emacs-26.3-no_x11 > > quirks-3.185 signed on 2020-04-30T09:14:52Z > Can't install libxml-2.9.9 because of libraries > |library iconv.7.0 not found > | /usr/local/lib/libiconv.so.6.0 (libiconv-1.14p3): bad major Usual cause, and first thing to check, is using snapshot packages on a -stable system. All ports development is done on -current so newly-built ports can usually not be installed on the stable version due to libraries.
Re: [NEW] www/p5-Catalyst-Controller-ActionRole
Hi wen, wen heping wrote: > You are right, I forgot the I had updated p5-Catalyst-Runtime > to 5.90126 in my local ports tree. Many ports depends on > p5-Catalyst-Runtime and I had not test all of them, so I hold the > patch in my system. > > I shall submit the patch later. No problem. I did the update locally. It builds and installs fine with all the dependencies. I tested: - www/p5-Catalyst-ActionRole-ACL - textproc/p5-String-Escape - www/p5-Catalyst-Authentication-Credential-HTTP - www/p5-HTML-FormFu-MultiForm - www/p5-Catalyst-Model-Adaptor Makefiles look good to me. Dependency check has no complaints. Tested on amd64. I cannot commit, but WorksForMe™. Cheers, Stefan
回复: [NEW] www/p5-Catalyst-Controller-ActionRole
Thank you , Stefan ! You are right, I forgot the I had updated p5-Catalyst-Runtime to 5.90126 in my local ports tree. Many ports depends on p5-Catalyst-Runtime and I had not test all of them, so I hold the patch in my system. I shall submit the patch later. Regards, wen 发件人: owner-po...@openbsd.org 代表 Stefan Hagen 发送时间: 2020年5月3日 20:10 收件人: ports@openbsd.org 主题: Re: [NEW] www/p5-Catalyst-Controller-ActionRole Hi wen, wen heping wrote: > Here is a patch to create new port > www/p5-Catalyst-Controller-ActionRole. Although it is marked > DEPRECATED upstream, it is needed by www/p5-Catalyst-ActionRole-ACL, > which is needed by the update of devel/catalyst. It build well and > pass all tests on amd64-current system. I'm not able to build it. It is looking for p5-Catalyst-Runtime-5.90013 which is only available in Version 5.90006 in the my current port tree. Did you miss sending it? Cheers, Stefan
Re: keynav man page
Hi Damien, thanks for trying to help! However, there are large numbers of questions to answer and large amounts of work to do before this can usefully go anywhere. One thing up front: Damien Thiriet wrote on Sat, May 02, 2020 at 06:30:25PM +0200: > Since I am not a programmer, and cannot run -current, the only way for > me to contribute to the project is to deal with documentation Even for that, you need to run -current, and even for working on ports, you need sufficient programming skills to work on Makefiles. If you lack parts of the needed skills, learn! So, here is a plan for you: 1. This port had its last release in 2011. So on first sight, it appears to be abandoned, i.e. no longer maintained upstream. Please contact upstream, thank them for their work, tell them that you use and enjoy it, ask them whether they still maintain it, tell them that you have started to prepare improvements, and ask them whether they might consider integrating improvements and roll a new release if it turns out they like your work. 2.a) If they say they have abandoned their program and won't make a new release, or if they do not answer, your only real option to improve the program is to take over upstream maintenance. Ask yourself whether you want to do that, and if yes, do take over. 2.b) If upstream is still active, instead work with upstream to get your improvements integrated. 3. If at this point, we don't have an upstream maintainer, we need to decide whether to keep the port around or whether to delete it outright from the OpenBSD ports tree. Security-critical or large programs without an upstream maintainer are usually deleted from the ports tree. Keeping small, relatively harmless programs around may be acceptable even when they are dead upstream, but we don't usually try to improve programs in the ports tree that are dead upstream. So, even if we keep the port around, you have more or less come to a dead end with your work until you find someone who maintains the program in general, not just in our ports tree. Again, that can be you. 4. If you want to submit patches to the OpenBSD port, no matter of which kind, even to just improve documentation, you *must* run OpenBSD-current. There is no excuse. We just don't do updates for -stable ports (except to fix security issues, and that is only done *after* fixing them in -current, and never by external contributors). 5. The OpenBSD port is outdated. We have 20101014, upstream has 20110708. The very first thing to do in our ports tree would be to decide whether the port can and should be updated to 20110708. If yes, do it. If no, dependiing on which issues prevent an update, try to resolve them. 6. Upstream is doing a very stupid thing. They do have a manual page, but they fail to include it in the distribution tarball. The manual page file is called "keynav.pod". It is neither in mdoc(7) nor in man(7) format, but it is still a manual page, using the third-best perlpod(1) format. Get upstream to include that file in the distribution tarball for their next release. 7. In the meantime, while upstream is working on the next release, if you are in a hurry to get the manual page into the port, make the port * download the manual page during the "fetch" target, see bsd.port.mk(1) for details, look for the DISTFILES variable in there, https://man.openbsd.org/bsd.port.mk#DISTFILES * then format it with pod2man(1) during the "post-build" phase, see the fifth and seventh entries in TARGETS near the very top of bsd.port.mk(1) * then install it during the "post-install" phase * then use "make update-plist" * then submit a port update with a REVISION bump 8. If you want to switch the manual page from perlpod(1) to mdoc(7), work with upstream to do so. We will not change the markup language of the documentation in the ports tree as long as upstream sticks to a different language. 9. If you want to improve the content of the manual page, work with upstream to do so. > You'll find below a keynav.mdoc file as a proposal for keynav ports. > Any hints to improve the structure with regards to OpenBSD standards > welcome. >From an extremely brief glance at your work, i see dozens of serious problems with it where that work can be improved (even though it seems to be good work). Unless you confirm that you have established contact with upstream and they want to take patches, or until you have taken over upstream maintenance, i am not planning to invest the time needed to explain all those deficencies. > I read the mdoc(7) and mandoc(8) man pages, used pod2mdoc to convert > keynav.pod, looked at several base examples (cwm.1, cwm.5, ksh.1, > grep.1, tmux.1) and made the converted file fit mdoc recommandations,
Re: [NEW] www/p5-Catalyst-Controller-ActionRole
Hi wen, wen heping wrote: > Here is a patch to create new port > www/p5-Catalyst-Controller-ActionRole. Although it is marked > DEPRECATED upstream, it is needed by www/p5-Catalyst-ActionRole-ACL, > which is needed by the update of devel/catalyst. It build well and > pass all tests on amd64-current system. I'm not able to build it. It is looking for p5-Catalyst-Runtime-5.90013 which is only available in Version 5.90006 in the my current port tree. Did you miss sending it? Cheers, Stefan
Re: [update] mail/mu-1.4.3
Stefan Hagen wrote:
> Miguel wrote:
>> - Added README for upgrade
>
> I just saw we can just put the release announcement here.
> https://github.com/djcb/mu/releases/tag/1.4
>
> The new release is incompatible. The mu commands are reporting the
> incompatibility, for example mu index -m ~/Mails reports, that you need
> to run mu init first and omit the -m. But it will break scripts if the
> user does not adapt them.
>
> I think it would make sense to add a pkg/MESSAGE to notified the user
> about the incompatibility.
I created a new patch, but now as I see it in action I'm unsure about
the MESSAGE:
===>Installing mu-1.4.3 from /usr/ports/packages/amd64/all/
mu-1.4.3: ok
New and changed readme(s):
/usr/local/share/doc/pkg-readmes/mu
--- +mu-1.4.3 ---
The mu tools command line interface and default paths have been changed.
Review share/doc/pkg-readmes/mu for details.
The last line may be redundant. What do you think?
Changes:
+ WANTLIB+= curses readline
+ README
+ MESSAGE
Cheers,
Stefan
Index: mail/mu/Makefile
===
RCS file: /cvs/ports/mail/mu/Makefile,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 Makefile
--- mail/mu/Makefile24 Jan 2020 10:36:41 - 1.19
+++ mail/mu/Makefile3 May 2020 11:05:11 -
@@ -1,9 +1,8 @@
# $OpenBSD: Makefile,v 1.19 2020/01/24 10:36:41 sthen Exp $
COMMENT= maildir indexer and searcher with emacs frontend
-
-DISTNAME= mu-1.2.0
-REVISION= 0
+V= 1.4.3
+DISTNAME= mu-${V}
CATEGORIES=mail
HOMEPAGE= http://www.djcbsoftware.nl/code/mu/
@@ -13,12 +12,12 @@ MAINTAINER= Stefan Hagen https://github.com/djcb/mu/releases/download/1.2/
+MASTER_SITES= https://github.com/djcb/mu/releases/download/${V}/
EXTRACT_SUFX= .tar.xz
BUILD_DEPENDS= emacs->=24:editors/emacs
Index: mail/mu/distinfo
===
RCS file: /cvs/ports/mail/mu/distinfo,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 distinfo
--- mail/mu/distinfo21 Jul 2019 00:10:04 - 1.7
+++ mail/mu/distinfo3 May 2020 11:05:11 -
@@ -1,2 +1,2 @@
-SHA256 (mu-1.2.0.tar.xz) = 9jTH8kTcaET/cdw8PhiT5I4ZPKqeDnR+umFjCXdfBTo=
-SIZE (mu-1.2.0.tar.xz) = 844192
+SHA256 (mu-1.4.3.tar.xz) =
f819db50a21eb200f015ff3486e9bb9db51e0a616aa9dd257b6654512c7c782a
+SIZE (mu-1.4.3.tar.xz) = 875272
Index: mail/mu/patches/patch-lib_parser_utils_cc
===
RCS file: /cvs/ports/mail/mu/patches/patch-lib_parser_utils_cc,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-lib_parser_utils_cc
--- mail/mu/patches/patch-lib_parser_utils_cc 26 Jul 2019 06:41:59 -
1.1
+++ mail/mu/patches/patch-lib_parser_utils_cc 3 May 2020 11:05:11 -
@@ -1,11 +1,11 @@
$OpenBSD: patch-lib_parser_utils_cc,v 1.1 2019/07/26 06:41:59 pvk Exp $
Bring g_vasprintf into scope
-Index: lib/parser/utils.cc
lib/parser/utils.cc.orig
-+++ lib/parser/utils.cc
-@@ -17,7 +17,7 @@
- ** 02110-1301, USA.
+Index: lib/utils/mu-utils.cc
+--- lib/utils/mu-utils.cc.orig
lib/utils/mu-utils.cc
+@@ -18,7 +18,7 @@
*/
+
-#define _XOPEN_SOURCE
+#define _XOPEN_SOURCE_EXTENDED 1
Index: mail/mu/pkg/MESSAGE
===
RCS file: mail/mu/pkg/MESSAGE
diff -N mail/mu/pkg/MESSAGE
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/mu/pkg/MESSAGE 3 May 2020 11:05:11 -
@@ -0,0 +1,2 @@
+The mu tools command line interface and default paths have been changed.
+Review share/doc/pkg-readmes/${PKGSTEM} for details.
Index: mail/mu/pkg/PLIST
===
RCS file: /cvs/ports/mail/mu/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- mail/mu/pkg/PLIST 20 May 2018 08:02:14 - 1.6
+++ mail/mu/pkg/PLIST 3 May 2020 11:05:11 -
@@ -8,6 +8,8 @@
@man man/man1/mu-find.1
@man man/man1/mu-help.1
@man man/man1/mu-index.1
+@man man/man1/mu-info.1
+@man man/man1/mu-init.1
@man man/man1/mu-mkdir.1
@man man/man1/mu-remove.1
@man man/man1/mu-script.1
@@ -22,6 +24,7 @@
share/doc/mu/
share/doc/mu/NEWS.org
share/doc/mu/mu4e-about.org
+share/doc/pkg-readmes/${PKGSTEM}
share/emacs/
share/emacs/site-lisp/
share/emacs/site-lisp/mu4e/
@@ -37,6 +40,8 @@ share/emacs/site-lisp/mu4e/mu4e-draft.el
share/emacs/site-lisp/mu4e/mu4e-draft.elc
share/emacs/site-lisp/mu4e/mu4e-headers.el
share/emacs/site-lisp/mu4e/mu4e-headers.elc
+share/emacs/site-lisp/mu4e/mu4e-icalendar.el
+share/emacs/site-lisp/mu4e/mu4e-icalendar.elc
share/emacs/site-lisp/mu4e/mu4e-lists.el
share/emacs/site-lisp/mu4e/mu4e-lists.elc
share/emacs/site-lisp/mu4e/mu4e-main.el
@@ -47,6 +52,8 @@ share/emacs/site-lisp/mu4e/mu4e-message.
share/emacs/site-lisp/mu4e/mu4e-message.elc
share/emacs/site-lisp/mu4e/mu4e-meta.el
share/emacs/site-lisp/mu4e/mu4e-meta.elc
+share/emacs/site-lisp/mu4e/mu4e-org.el
[NEW] www/p5-Catalyst-Model-Adaptor
Hi, ports@: Here is a patch to create new port www/p5-Catalyst-Model-Adaptor, which is needed by the update of devel/catalyst. It build well and pass all tests on amd64-current system. Regards, wen p5-Catalyst-Model-Adaptor.tar.gz Description: p5-Catalyst-Model-Adaptor.tar.gz
