Stuart Henderson:
> I have been running bulks with this for ages and forgotten about it
> until it actually triggered today. It extends the gettext-tools
> poisoning to a few more scripts, and adds the same for asciidoc,
> making hidden dependencies more obvious.
I'm fine with the gettext-tools p
It annoys me that lang/clisp fails to build with parallel make
(MAKE_JOBS). I would like to fix that so MAKE_JOBS builds of ports
and their dependencies don't error out when they recurse into clisp.
Clisp hasn't had a release since 2010, but there has been upstream
development up to 2018 in a Mer
The OpenBSD 7.0 release is approaching fast.
Ports development needs to wind down. Please finish pending imports
and updates, and remember that not everything needs to make the
release. Let's concentrate on fixing bugs.
This is also a call for people to start testing packages in earnest.
If you
ok?
Index: Makefile
===
RCS file: /cvs/ports/print/lcdf-typetools/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile2 Sep 2020 10:34:28 - 1.1.1.1
+++ Makefile12 Sep 2021 19:22:54 -
Straightforward, I guess.
ok?
Index: patches/patch-link-parser_command-line_c
===
RCS file: patches/patch-link-parser_command-line_c
diff -N patches/patch-link-parser_command-line_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patch
net/libsmi: avoid printf %n
Bizarrely, that code block starts with a comment that Microsoft has
disabled %n, then adds an Microsoft-approved workaround. I've left
that in place, even though it is entirely useless with the simple
fix below. The value is only used to format the field width of
subs
Michael:
> +Index: modules/FvwmScript/Instructions.c
> +--- modules/FvwmScript/Instructions.c.orig
> modules/FvwmScript/Instructions.c
> +@@ -665,7 +665,7 @@ static char *GetTime (int *NbArg,long *TabArg)
> +
> + str = (char*)safecalloc(20,sizeof(char));
> + t = time(NULL);
> +- sprintf
./security/libssh2.log:subsystem_netconf.c:267:17: warning: '%n' format
specifier support is deactivated and will call abort(3)
./security/libssh2.log:subsystem_netconf.c:285:17: warning: '%n' format
specifier support is deactivated and will call abort(3)
This is in example code that isn't actua
jas...@openbsd.org:
> http://build-failures.rhaalovely.net/powerpc64/2021-09-09/sysutils/ggrep.log
I guess something like this?
Index: Makefile
===
RCS file: /cvs/ports/sysutils/ggrep/Makefile,v
retrieving revision 1.39
diff -u -p -
Standard %n fix, I guess.
Mark as NO_TEST while here; there is no check or test target.
ok?
Index: Makefile
===
RCS file: /cvs/ports/textproc/openjade/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- Makefile2 S
Here's the list of remaining ports with
warning: '%n' format specifier support is deactivated and will call abort(3)
These need to be fixed before the release.
databases/openldap23The OpenBSD ports mailing-list
devel/adb The OpenBSD ports mailing-list
devel/libvstr
George Koehler:
> WRKSRC/mpn/asm-defs.m4:1054,
>
> ifelse(`PIC_ALWAYS',`yes',`define(`PIC')')
>
> Notice that `PIC_ALWAYS' is in quotes, so the macro PIC_ALWAYS is not
> expanded. This faulty check compares the literal string "PIC_ALWAYS"
> with the literal string "yes"; these strings never mat
Stuart Henderson:
> henning: do you still use openldap 2.3? if not, the port is a bit of a
> source of problems and it would be helpful to remove it (these days 2.4
> has a backend which is nothing to do with berkeley db which iirc was the
> original problem)
In case we still need it, we can just
Earlier today, semarie@ committed a change that will now cause base
clang to warn when the %n specifier appears in a format string for
the printf(3) family of functions:
warning: '%n' format specifier support is deactivated and will call abort(3)
I already ran a full amd64 bulk build with this.
databases/mongodb failed to build in my latest amd64 bulk build.
Presumably this is fallout from the Boost 1.77 update.
I'm attaching the build log.
--
Christian "naddy" Weisgerber na...@mips.inka.de
mongodb.log.xz
Description: application/xz
Jeremie Courreges-Anglas:
> Ports may suffer from this at build time *and* runtime. Regarding
> issues at build time we can ease the debugging with the diff below.
I've been running with this for months, but nobody asked me for
results and I didn't push the issue. Grepping /var/log/messages.*
a
Moritz Buhl:
> this diff fixes CVE-2020-14387 for net/rsync.
The same change was committed upstream:
https://github.com/WayneD/rsync/commit/c3f7414c450faaf6a8281cc4a4403529aeb7d859
However...
> +-exec $RSYNC_SSL_OPENSSL s_client $caopt $certopt -quiet -verify_quiet
> -servername $hostname
Kurt Miller:
> > x11/gtk+2 and x11/gtk+3 include a patch to change the default
> > keybindings to "emacs". The decision can be traced back to 2005:
> >
> >Revision 1.1, Wed Sep 7 20:51:14 2005 UTC (15 years, 10 months ago) by
> > kurt
> >Branch: MAIN
> >
> >make emacs the default ke
The update of net/neon to 0.31 has broken the ever more aptly named
net/cadaver:
checking linking against neon... yes
configure: incompatible neon library version 0.31.2: wanted 0.27 28 29 30
configure: error: could not use external neon library
We already had to expand the range of allowable ver
Solene Rapenne:
> this updates nano to latest version
That's missing a PLIST update. A Slovak message catalog has been
added.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Kurt Mosiejczuk:
> The most recent version of mpg123 uses C99 for loop initialization.
It already did before.
The issue here is that upstream changed configure.ac to be compatible
with autoconf 2.71, then went back and used 2.69.
* With 2.71, AC_PROG_CC tries to enable C89/C99/C11 and AC_PROG_C
Alexander Bluhm:
> A test dependecy to devel/p5-Devel-FindPerl is missing.
>
> I think @comment the dummy module out.
Incorporated.
OK to import?
--
Christian "naddy" Weisgerber na...@mips.inka.de
find2perl.tgz
Description: application/gtar-compressed
Alexander Bluhm:
> A test dependecy to devel/p5-Devel-FindPerl is missing.
> I have attached this new port.
That one is even simpler; ok naddy@
--
Christian "naddy" Weisgerber na...@mips.inka.de
Randal Schwartz mentioned find2perl on comp.unix.shell, which made
me realize that it isn't any longer shipped as part of Perl.
So here's a port for App-find2perl from CPAN.
find2perl is a little translator to convert find(1) command lines to
equivalent Perl code. The resulting code is typica
Todd C. Miller:
> That's odd, I was just now able to reproduce it on amd64 without
> any difficulty:
>
> bison -y -v $flags -pyyansi_c --defines=ansi_c_y.tab.h parser.y -o
> ansi_c_y.tab.cpp
> parser.y:36.22-27: warning: POSIX Yacc does not support string literals [
>
> at which point it dumps
Todd C. Miller:
> > > - devel/cbmc: repeatable bison segfault, seems related to
> > > curses/libtextstyle.
> > I can't reproduce this on amd64.
>
> That's because I disabled use of libtextstyle in later bison diffs :-)
No, I dropped the --without-libtextstyle-prefix for testing purposes
and the
Stuart Henderson:
> Updated diff below, there were some missing library deps and I've enabled
> building a debug package. My build is still running, so far I've run
> into errors in these which seem related:
>
> - devel/cbmc: repeatable bison segfault, seems related to curses/libtextstyle.
I can
Christian Weisgerber:
> > > Hmm, why does bison.info get rebuilt anyway? GNU software ships
> > > with a pre-built .info file included. Maybe we can just disable
> > > the regeneration?
> >
> > I was unsuccessful in doing that, though I'm sure so
Todd C. Miller:
> > Hmm, why does bison.info get rebuilt anyway? GNU software ships
> > with a pre-built .info file included. Maybe we can just disable
> > the regeneration?
>
> I was unsuccessful in doing that, though I'm sure someone with more
> automake knowledge could. Just touching the ap
"Todd C. Miller":
> Another port I'd like to update needs a newer version of bison that
> we provide so I've updated to the lastest version.
>
> The only problem I encountered is that makeinfo in base is old and
> doesn't understand some of these new-fangled directives. They
> appear to just be
Marc Espie:
> > It's a POSIX shell built-in, so no separate man page. It's documented
> > in sh(1) and ksh(1).
>
> It's fairly recent as a built-in apparently, it wasn't in OpenGroups 2017
> or so.
Not true. It's in their online copy of the 2008 edition.
I don't know where to find older versio
Stuart Henderson:
> I suppose it doesn't really matter (and mediainfo uses it already),
> but it feels a bit unusual to set DISTFILES instead of DISTNAME and
> EXTRACT_SUFX.
Well, DISTNAME provides the base from which PKGNAME, DISTFILES, and
WRKDIST are derived. But due to upstream's naming sche
Marc Espie:
> > Switch the argument parsing from the deprecated getopt to getopts.
> >
> Not before I see actual documentation pointing to getopts
>
> Specifically: I wasn't even aware getopts existed.
>
> It is a built-in in sh (ksh ?)
It's a POSIX shell built-in, so no separate man page. It
Switch the argument parsing from the deprecated getopt to getopts.
ok?
Index: fetch_cmd.template
===
RCS file: /cvs/ports/infrastructure/templates/fetch_cmd.template,v
retrieving revision 1.1
diff -u -p -r1.1 fetch_cmd.template
--- f
+COMMENT= utility for reading information from audio/video files
-VERSION= 20.09
+VERSION= 21.03
PKGNAME= mediainfo-${VERSION}
CATEGORIES=multimedia
+
HOMEPAGE= https://mediaarea.net/en/MediaInfo
MAINTAINER=Christian Weisgerber
-# BSD-style
+# BSD
The second part, attached, is multimedia/libmediainfo:
read metadata from media files
MediaInfo is a library used for retrieving technical information and other
metadata about audio or video files.
A non-exhaustive list of the information MediaInfo can retrieve from media
files include
For years, people have been asking me on and off to make libmediainfo
available for use by other ports. This finally reworks the existing
all-in-one multimedia/mediainfo port and breaks it into three parts
by using the "split sources for Linux package creation":
devel/libzen
multimedia/libmed
Rafael Sadowski:
> Let's disable doxygen to be safe. No plist changes. Spotted by stehn@.
So how does the presence of doxygen relate to cmake rerunning itself
with --regenerate-during-build?
--
Christian "naddy" Weisgerber na...@mips.inka.de
comms/gnuradio fails every other build or so.
sthen has already run out of patience and marked it BROKEN-i386.
The problem is machine-independent, though. cmake builds a shared
library with our SHARED_LIBS version, then in the fake stage it
tries to install it with the upstream version. This hap
Patrick Wildt:
> sthen, naddy: OK to put it in, or too late?
ok
--
Christian "naddy" Weisgerber na...@mips.inka.de
Rafael Sadowski:
> To me it looks like the build directory was corrupted after the build
> task and cmake re-run/try the configure task. Also not reproducible
> here.
I think both the hydrogen and the nextcloudclient failure haven't
happened before. I assume it is some sort of race that will onl
net/nextcloudclient failed to build in my latest amd64 bulk build.
===> Faking installation for nextcloudclient-3.1.3
[0/1] /usr/local/bin/cmake --regenerate-during-build
-S/usr/obj/ports/nextcloudclient-3.1.3/desktop-3.1.3
-B/usr/obj/ports/nextcloudclient-3.1.3/build-amd64
... and then it goe
audio/hydrogen failed to build in my latest amd64 bulk build.
===> Faking installation for hydrogen-1.0.1
[0/1] /usr/local/bin/cmake --regenerate-during-build
-S/usr/obj/ports/hydrogen-1.0.1/hydrogen-1.0.1
-B/usr/obj/ports/hydrogen-1.0.1/build-amd64
... and then it goes off the rails.
Full log
Christian Weisgerber:
> Marc Espie:
>
> > g_setenv ("LANGUAGE", language, TRUE);
> > setlocale (LC_ALL, "");
>
> From the gettext manual:
> Note: The variable LANGUAGE is ignored if the locale is set to 'C'. In
> other words
Marc Espie:
> g_setenv ("LANGUAGE", language, TRUE);
> setlocale (LC_ALL, "");
>From the gettext manual:
Note: The variable LANGUAGE is ignored if the locale is set to 'C'. In
other words, you have to first enable localization, by setting LANG (or
LC_ALL) to a value other than 'C', befo
As we are approaching the 6.9 release, the next days will be the
final opportunity for testing. Install a snapshot and snapshot
packages now if you don't want to find out only after the release
that your favorite application is broken!
If nobody knows that it's broken, it can't be fixed, and time
We're moving towards locking the ports tree for the 6.9 release.
All ports commits now need to be approved by sthen@ or me.
Please limit your approval requests to important things.
No more imports.
If there are any special concerns (e.g. "we need such and such for
-stable"), talk to sthen@ and me
We'll start preparing the OpenBSD 6.9 release real soon now. It's
time for ports work to slow down. Any imports still pending?
Anything important in there?
Other important changes that need to be handled before the release?
--
Christian "naddy" Weisgerber na...@mips.in
Matthew Martin:
> A while back [1] it was noted zsh's $OSTYPE is out of sync with the OS
> version.
>
> 1: https://marc.info/?l=openbsd-ports&m=160940571013139&w=2
I don't think there's a problem to solve.
OSTYPE describes the operating system this instance of zsh (or bash)
was compiled on. Th
On 2021-03-22, Marc Espie wrote:
> I'm on the fence between marking it as BROKEN and give Chris a chance to
> fix the code, or downright removing it.
Also, fixes have been limited to keeping up with removals. How
many networking things have been added to OpenBSD over the last
four years?
--
C
Alessandro De Laurenzis:
> In tcsh 6.22.03:
>
> > {1} set a=foo
> > {3} echo $a:h
> >
>
> This is breaking most of cad/qflow scripts (and possibly creating other
> issues in the tree).
This was reported upstream and Christos replied with a fix:
https://mailman.astron.com/pipermail/tcsh/2020-No
Christian Weisgerber:
> On 2021-03-09, Stuart Henderson wrote:
>
> > Some ports have failures that appear to be issues with the compiler/diff
> > and I haven't listed them below; the following are problems with the
> > ports themselves:
All of those have been
The recent network changes to inet{4,6} autoconf have broken shells/nsh.
AGAIN.
I'm getting rather tired of cleaning this up each time. sthen@ too,
I think.
>>> Building on amd64-1 under shells/nsh
BDEPENDS = [datab
Christian Weisgerber:
> emulators/BasiliskIIundeclared identifier sem_timedwait
> graphics/delaboratory unknown type name sem_t
Quick analysis: Those fail because they include their own semaphore.h
header, which is picked up by /usr/include/c++/v1/__threading_support.
I
All build failures caused by the new -fno-common compiler default
have now been resolved one way or the other.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2021-03-09, Stuart Henderson wrote:
> Some ports have failures that appear to be issues with the compiler/diff
> and I haven't listed them below; the following are problems with the
> ports themselves:
devel/electron destructor cannot be declared using a type alias
emulators/Basi
Stuart Henderson:
> > Released today, and amongst others it adds DW_OP (DW_OP_entry_value, 0xa3)
> > which I think should fix with LLVM 11 on amd64. (The existing dwz is ok
> > on i386 with LLVM 11).
>
> tidier Makefile patch (thanks naddy) -
Seems to produce usable debug packages with clang 10,
Martin Vahlensieck:
> Rather mechanical fix for -fno-common.
This would be a great opportunity to update the port to the latest
release 1.90 instead of letting the obsolete version sit there.
> Builds and starts, but I don't
> know how to play it, so can't judge if that works.
Yes, that's a pro
What, you thought the last few would resolve themselves by magic?
Here are the remaining ports that fail to build due to the new
-fno-common compiler default:
games/oolite
lang/moarvm
multimedia/lives
net/yersinia# update/fix on ports@ waiting for ok
--
Christian "naddy" Weisgerber
Alex Raschi:
> > Now I can't properly control the character. The cursor keys only
> > allow movement in two directions.
>
> I found a patch for this here:
> http://egoboo.sourceforge.net/phpBB3/viewtopic.php?f=3&t=1177&start=15#p61333
Thanks!
I went through the Git history and picked the upstre
This is the second time in recent weeks that the
net/nagios/check_mssql_health port failed to build during an amd64
bulk build, with the same weird reason: a supposed syntax error
in an awk regular expression. See below.
Re-running the same command in the work directory does not reproduce
the err
I tried to update games/egoboo to 2.8.1 but failed.
It builds.
It requires the included libenet. The API is not compatible with
the version in our net/enet port.
I packaged it.
I fixed a crash on startup in some code that roots around in SDL
bitmaps.
Now I can't properly control the character.
Only ten ports are left that fail to build due to the new -fno-common
compiler default. Come on, everybody, let's finish this!
emulators/pcsxr
games/egoboo
games/mirrormagic
games/oolite
lang/moarvm
multimedia/audiopreview
multimedia/lives
net/angst
net/ettercap
net/yersinia
--
Christian "naddy
Greg Steuck:
> I confirmed that it runs and plays pieces of videos.
Should we remove it instead?
Upstream is completely gone, there is no master site. And it depends
on gstreamer-0.10, which I think we also want to get rid of.
FreeBSD culled it in 2019 with their ruthless "unfetchable,
unmainta
Bjorn Ketelaars:
> I overlooked the second parser, good catch. I think you are right that
> we need to make current_line and root_line static, thus limiting the
> visibility of things within the same file.
Also, I suggest to patch the *.y source files rather than the
generated *.c ones.
--
Chri
Bjorn Ketelaars:
> +--- src/parser-cw.c.orig
> src/parser-cw.c
> +@@ -32,8 +32,8 @@
> + #include "program-cw.h"
> + #include "options.h"
> +
> +- int current_line;
> +- struct cw_line *root_line;
> ++ extern int current_line;
> ++ extern struct cw_line *root_line;
Hmm. There are two
Daniel Dickman:
> > games/sdlpop
>
> I was able to play through level 1 with the below.
Looks like the version number is going backwards.
--
Christian "naddy" Weisgerber na...@mips.inka.de
We're almost there! The end is in sight! We can make it!
Here are the remaining ports that fail to build due to the new
-fno-common compiler default:
comms/xdx
emulators/pcsxr
games/corewars
games/egoboo
games/freedroidrpg
games/mirrormagic
games/oolite
games/sdlpop
lang/moarvm
mail/wmmultipop3
Well, if we don't delete scmxx, we might as well update it to the last
release 0.9.0, which incidentally also builds fine with -fno-common and
removes the need for most patches.
Not tested due to a lack of an ancient Siemens phone.
OK?
Index: Makefile
Patch files should not have MS-DOS line endings "\r\n".
I have cleaned up most instanced in the ports tree, removed the
carriage return characters, and listed the files to be patched in
FIX_CRLF_FILES.
Two ports remain:
* devel/sdl-pango
This applies a distpatch to a file with \r\n line ending
Here is the updated list of ports that now fail to build due to the
new -fno-common compiler default.
audio/gtkpod- ports@openbsd.org
audio/nspmod- ports@openbsd.org
audio/wmtune- ports@open
x11/golem is an old window manager. This is another port that is
broken by -fno-common.
Our port is at version 0.0.5, which is 19 years old. When you start
it, there is a spew of errors about undefined symbols and the plugins
can't be loaded. I don't think anybody uses this.
There is a newer d
net/argus-clients: fix for -fno-common
This removes an unused variable from the static library argus_common.a.
It clashes with one in the raconvert tool. You could argue the latter
one should be renamed instead, but then again, the library variable
isn't referenced anywhere.
OK?
Index: Makefile
net/argus: fix the build with -fno-common
This is just unused code that is copy-pasted from ArgusUdp.c where
is also unused.
OK?
Index: Makefile
===
RCS file: /cvs/ports/net/argus/Makefile,v
retrieving revision 1.25
diff -u -p -r1.2
Greg Steuck:
> I confirmed that uwm still launches and managed to exercise the Exit
> item in the menu.
Launching an xterm also works.
> Happy to either apply the patch or remove the port as it looks pretty
> dead upstream.
Hey, I was looking at it at the same time. It's functional, I see
no r
Here is the updated list of ports that now fail to build due to the
new -fno-common compiler default.
(It looks like portroach now fails to show available updates for
master site Sourceforge.)
audio/gtkpod- ports@openbsd.org
audio/nspmod
The latest flurry of python changes appears to have triggered this
build failure of games/renpy in my latest bulk build:
>>> Building on localhost under games/renpy
BDEPENDS =
[lang/cython;archivers/bzip2;graphics/g
Here is the updated list of ports that now fail to build due to the
new -fno-common compiler default.
audio/gtkpodUPDATEports@openbsd.org
audio/nspmod- ports@openbsd.org
audio/wmtune- ports@open
Klemens Nanni:
> > That's a hint that it's defined in a header file that is included
> > everywhere. You just need to mark it extern and copy the definition
> > into a *.c file.
> Right, but if I mark that symbol `extern' others now show up as well:
I see. There are a lot of tables that are def
weex is still maintained, sort of, by the Debian packager.
Update to latest release 2.8.3, which also fixes the build with
-fno-common.
With some guidance from the FreeBSD port how to wrangle the incoherent
autotool files into buildable shape.
Note: I don't use this, I haven't tested it.
OK?
Pat
Klemens Nanni:
> I went the easy way just like Debian did; the update itself did not
> change "-fno-common" behaviour, i.e. it's the same twenty files that
> clash on the `gamgi' symbol.
That's a hint that it's defined in a header file that is included
everywhere. You just need to mark it exter
Stuart Henderson:
> > > comms/birda - ports@openbsd.org
> > > comms/jpilot- ports@openbsd.org
> > > comms/scmxx UPDATEports@openbsd.org
> for old mobile phones/portable devices
I already sugges
Stuart Henderson:
> I think we are getting to the stage where we should just mark them BROKEN
> with an identifiable tag, so that we don't have to wade through them when
> identifying other ports breakage in builds.
>
> Then if no updates happen maybe remove them in a few months (say, a bit
> aft
Is anybody still interested in games/spider? It's a 30-year old
solitaire game.
Our master site is gone, but I've found another one. The port fails
to build with -fno-common. When built with -fcommon, it runs, so
it could be repaired. But getting there means wading through reams and
reams of w
Here is the updated list of ports that now fail to build due to the
new -fno-common compiler default.
I have again cc'ed everybody who is listed as maintainer of at least
one affected port. "UPDATE" means that portroach says that an
update is available.
audio/gtkpodUP
Greg Steuck:
> I tested that benchmarks/tsung still works as a proxy for
> all-things-erlang21. This is to be followed by erlang/19 directory
> removal.
devel/rebar and devel/rebar3 still have erlang19 flavors.
--
Christian "naddy" Weisgerber na...@mips.inka.de
games/freeblocks fails to build with -fno-common. Upstream has not
yet addressed this problem.
The patches below fix dozens of multiple variable definitions.
Some need an extern, some need to be defined in a source module in
the first place. One had a wrong enum type.
Alternatively, this may be
Even more so than the micro-controller toolchains that I already
touched, this port feels massively outdated and should probably be
replaced by some newer version. That, however, is a substantial
undertaking and needs to be done by somebody who can verify that
the result actually works.
So here a
comms/scmxx fails to build with -fno-common. There is actually a
slightly newer version 0.9.0 from 2006 available, which will
presumably need the same fix.
"data exchange utility for Siemens mobile phones"
Hmm. Siemens Mobile folded 15 years ago. I guess it's _possible_
that somebody still use
There has been a flurry of activity, so here is again the updated
list of ports that fail to build with -fno-common:
audio/gtkpodUPDATEports@openbsd.org
audio/nspmod- ports@openbsd.org
audio/wmtune-
Ryan Freeman:
> Took a stab here, FreeBSD has moved to 2.0.20 and uses Debian's mirror
> to fetch the distfile. I followed suit.
Charlene already proposed something similar:
https://marc.info/?l=openbsd-ports&m=161256652328956&w=2
--
Christian "naddy" Weisgerber na...@
Bjorn Ketelaars:
> Yes, you are right, it is worth an update. For now update to 3.22.0 as
> newer versions depend on libgnome-games-support, which - I think - is
> not in ports. Upstream provided the -fno-common fix.
>
> Run tested on amd64.
I managed to make water. ok naddy@
--
Christian "na
Klemens Nanni:
> OK kn to remove this, although I certainly do not object to fixing it
> if someone wants to do the legwork -- it just seems unreasonable to me
> (if done by people who only fix it "to fix the tree").
FWIW, the FreeBSD port is equally unplayable.
--
Christian "naddy" Weisgerber
graphics/enjoympeg fails to build with -fno-error. A glance at DESCR
Enjoympeg is a MPEG-1 video player based on the source
of plaympeg from the SMPEG library. It has [... who cares...]
makes me think that this port can be removed. FreeBSD did so about
a decade ago. MPEG-1 video (Video CD
Rafael Sadowski:
> Next victim of "-fno-common". The project is dead and I don't think we
> should save this application. Alternatives are available.
Similar history on FreeBSD and OpenBSD: kevlo@ imported it in July
2010, and since then the respective ports have only received
mechanical infrastr
Bjorn Ketelaars:
> Fix taken from
> https://github.com/compiz-reloaded/compiz-plugins-main/commit/1f39291442513c08930bef308d0ce9dccea74589
That enum isn't used anywhere?!
Oh well, no point in diverging from upstream.
ok naddy@
--
Christian "naddy" Weisgerber na...@mips
Ryan Freeman:
> > anything I've forgotten for removal?
>
> Thanks naddy, kn, edd for the hints on Quirks and the main category unhook.
> This more like it?
devel/quirks needs a version bump when an entry is added.
Also...
> --- devel/quirks/files/Quirks.pm 10 Feb 2021 12:49:31 - 1
Bjorn Ketelaars:
> Fix taken from
> https://gitlab.gnome.org/GNOME/atomix/-/commit/be7f44f1945a569494d46c60eaf6e7b39b2bb48b.patch
There also seem to be much newer versions available.
https://download.gnome.org/sources/atomix/3.34/
atomix-3.34.0.tar.xz519.6 KiB 2019-Sep-09 19:16
That w
Here is an updated list of ports that fail to build with -fno-common:
audio/audacity UPDATEports@openbsd.org
audio/gtkpodUPDATEports@openbsd.org
audio/nspmod- ports@openbsd.org
audio/wmtune
Stuart Henderson:
> naddy had a similar diff and same problem. Looking at the compiler
> warnings it doesn't exactly seem LP64-clean (or, well, clean at all);
Speaking in general terms: A lot of the crufty X11 code in the
ports tree has a pattern where they use callback APIs that take a
pointer
201 - 300 of 1995 matches
Mail list logo
