Ryan Freeman:
> From FreeBSD, a bit hard to follow as their commit (re)touched the
> original patches
>
> Once this builds, the game doesn't seem very playable.
I already looked at this. If you build it with -fcommon, it already
isn't playable. That needs to be fixed first--or the port should
The GNU toolchain explicitly avoids common variables. Whoever
hacked up this derived version didn't understand that.
* binutils: Since linkrelax is already defined as a global variable,
it is already initialized to 0, so we can simply drop this
initialization.
* gcc-bootstrap, gcc: Use the m
It looks like this could be updated.
http://ftp.geda-project.org/geda-gaf/stable/v1.10/1.10.2/
--
Christian "naddy" Weisgerber na...@mips.inka.de
Ryan Freeman:
> First time trying to remove something, here is a patch to move
> games/prboom to the attic. games/prboom-plus does everything it
> did and more with fixes.
>
> anything I've forgotten for removal?
Port removals need an entry in devel/quirks.
--
Christian "naddy" Weisgerber
Charlene Wendling:
> > util.o: In function `tvstddev':
> > util.c:(.text+0x6f4): undefined reference to `sqrt'
>
> The autoconf stuff really detects the need for`-lm' as seen in
> config.log: 'ac_cv_lib_m_sqrt=yes', but is not used anywhere at all.
No, we are preloading the autoconf cache with t
Edd Barrett:
> I think this is right. The variables in question are already defined in
> mon-init.c, so just the missing `extern` qualifiers.
Yes, that's exactly right.
> No bump required I think.
Maybe, but I suggest to bump all ports that get fixed nevertheless.
--
Christian "naddy" Weisger
Here is an updated list of ports that fail to build with -fno-common:
astro/wmspaceweather- ports@openbsd.org
astro/wmsun - ports@openbsd.org
audio/audacity UPDATEports@openbsd.org
audio/gtkpod
Here is an updated list of ports that fail to build with -fno-common.
Reminder: The compiler default has been switched to -fno-common.
These are now regular build failures in every bulk build (on the
clang architectures). I have cc'ed everybody who is listed as a
maintainer of at least one of the
Christian Weisgerber:
> In my latest amd64 bulk build, www/liferea failed to build.
> Maybe somebody has an idea what triggered this:
>
> ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to
> WebCore::presentingApplicationPID()
> ld: error: .libs/libweb
In my latest amd64 bulk build, www/liferea failed to build.
Maybe somebody has an idea what triggered this:
ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to
WebCore::presentingApplicationPID()
ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to
WebCore::Process::se
I fixed up x11/xfed for -fno-common, but trying to run it with a
random .bdf file from xenocara, I just get a parse error. Judging
by the time stamps in the archive, it was packaged in 1998 with the
actual source files having dates from 1989 and 1991. The master
site disappeared a long time ago.
Here is an updated list of ports that fail to build with -fno-common.
This is now the default for base clang, so those are now regular
bulk build failures. "UPDATE" means that an update is available
according to portroach.
astro/wmspaceweather- ports@openbsd.org
astro
In my latest amd64 bulk build, textproc/calibre failed to build.
Error:
/usr/obj/ports/calibre-2.85.1/fake-amd64/usr/local/share/bash-completion/completions/calibre
does not exist
Wild guess: A stealth dependency on bash? Full log attached.
--
Christian "naddy" Weisgerber
Charlene Wendling:
> The below diff allows building skippy with -fno-common. While here:
>
> - MASTER_SITES and HOMEPAGE are 404'd, drop them
> - refresh WANTLIB
> - don't hardcode PREFIX, don't build with -g
> - add -fno-common fix, from Gentoo [0] (and add a missing RCS tag)
Hmm, a port withou
multimedia/avinfo needs to be fixed for -fno-common, but I'm leaning
towards just removing it.
Avinfo is an utility for displaying AVI, MPEG, OGG/OGM, MKV,
IFO header information. It returns the length of a clip, FPS,
resolution, codecs, sound parameters, and the number, type and
langua
k...@intricatesoftware.com:
> gettext fails to build on hppa with an undefined reference to
> `__sync_val_compare_and_swap_4'. The following allows it to build
> but it uses the fallback code that is not threadsafe. okay?
ok naddy@
--
Christian "naddy" Weisgerber na...@
Greg Steuck:
> iverilog still starts.
But the regression tests fail:
driver/iverilog -B. -BMvpi -BPivlpp -tcheck -ocheck.vvp ./examples/hello.vl
Cannot locate IVL modules : couldn't get command path from OS.
gmake: *** [Makefile:141: check] Error 1
--
Christian "naddy" Weisgerber
Fix build with -fno-common.
The header file erroneously defines the global variables instead of
simply declaring them.
No recent upstream activity.
ok?
Index: Makefile
===
RCS file: /cvs/ports/x11/menu-cache/Makefile,v
retrieving r
Here is an updated list of ports that fail to build with -fno-common.
astro/wmglobe - ports@openbsd.org
astro/wmmoonclock - ports@openbsd.org
astro/wmspaceweather- ports@openbsd.org
astro/wmsun
This updates devel/libmtp to the latest release 1.1.18, which also
includes a -fno-common fix. No major changes, one function was added.
No idea how to test actual functionality.
OK?
Index: Makefile
===
RCS file: /cvs/ports/devel/l
Klemens Nanni:
> Upstream is completely dead, even FreeBSD has marked their port as such
> (EXPIRATION DATE: 2021-04-01, not sure what will happen then, though).
It will be removed.
r...@freebsd.org performs regular "Remove expired ports" commits.
--
Christian "naddy" Weisgerber
Yozo TODA:
> here attached xvkbd updates to 4.1 where
> * -fno-common problem is fixed
> * change CONFIGURE_STYLE to gnu since configure is provided
> * port-lib-depends-check passes
> * compiles and works on amd64, with Xquartz/macOS as X server
>
> anyone please check and commit to the
In my latest amd64 bulk build, audio/libgpod failed to build:
configure: error: pygobject support explicitly requested but pygobject couldn't
be found
>>> Building on localhost under audio/libgpod
BDEPENDS =
[grap
On 2021-01-30, Klemens Nanni wrote:
> Imported in 1998 and modified in 2009 to "fix Y2K bug" which means
> "we may not distribute modified versions [due to its license]".
> Feedback? Objections? OK?
ok
FreeBSD removed it in 2011, "No more public distfiles".
--
Christian "naddy" Weisgerber
Here are the results from a first amd64 bulk build with -fno-common.
It's very much a case of mixed news.
The good news is that few ports with a significant number of
dependencies failed, and consequently most of the tree built.
The bad news is that there are about 300 mostly leaf ports that
fail
Christian Weisgerber:
> I'll send a followup message with additional background information.
So what's a "common (variable)"? When multiple object files have
an externally visible variable with the same name, the linker will
merge these variables so that they all r
textproc/py-sphinx,python3 failed to build in my latest amd64 bulk
build.
ModuleNotFoundError: No module named 'setuptools_scm'
>>> Building on amd64-2 under textproc/py-sphinx,python3
BDEPENDS =
[www/py-jinja2,pyt
On 2021-01-14, Ed Ahlsen-Girard wrote:
> Libreoffice puts the splash screen up and closes within two
> seconds, with a message on the command line of Application Error.
> Nothing is logged in messages.
So it seems that LibreOffice is broken with libc++ 10.0 and the
upstream fix I added is not en
Stefan Hagen:
> > The diff below reverts the getcwd check in question and the testsuite
> > will pass.
>
> New patch. The previous was full with stuff I tried...
Thanks. I have reported the problem upstream. There is no urgency
to updating the port, so let's wait a bit and see if they come up
Here is some black magic extracted from upstream that fixes building
editors/libreoffice with libc++ 10.0, at least on amd64.
https://github.com/LibreOffice/core/commit/cc5a6c6afeed1d2cf76d288133971d29ee8d893e
ok?
Index: Makefile
==
On 2021-01-09, Jan Stary wrote:
> The current ports.tar.gz contains a dev/ and deve/ directory
> beside the expected devel/ category. Is that intended?
The creation of those directories wasn't intended as such, they're
the result of cvs import accidents, but once a directory has been
created in
Stefan Hagen:
> portcheck, make port-lib-depends-check: ok
> make test:
> amd64 - up to test 165 all good, then I ran out of disk space
> sparc64 - passed
Well, I get:
89: extracting even when . and .. are unreadableFAILED (extrac09.at:37)
Looking at tests/testsuite.dir/089/testsuite.
In my latest amd64 package bulk build, print/py-pikepdf,python3 failed
to build.
Specifically, page.o couldn't be compiled:
src/qpdf/page.cpp:82:10: error: no matching member function for call to 'def'
.def("externalize_inline_images",
&QPDFPageObjectHelper::externalizeInlineImages,
Ingo Schwarze:
> > In the groff port, we could add #include "config.h" to all files
> > that don't do so already and include .
>
> I plan to prepare, test, and post patches for the groff port when i find
> time (which will not take more than two days), but if others beat me to
> it, i do not obje
textproc/groff fails to build with libc++ 10.0. groff blocks over
a thousand package paths, so this needs to be fixed before we can
switch to the newer libc++.
Analysis:
groff includes a copy of gnulib. gnulib provides *.h wrappers for
some standard header files. Those wrappers are not standal
games/dangerdeep fails to build with libc++ 10.0.
Here's a build fix, adapted from FreeBSD (which has since removed
the port because of the scons -> python2 dependency).
OK?
Index: patches/patch-src_coastmap_h
===
RCS file: /cvs/por
Ricardo Mestre:
> Latest release of the year, OK?
Can't you just take maintainer and commit those directly?
--
Christian "naddy" Weisgerber na...@mips.inka.de
Landry Breuil:
> i think print/gtklp can be used to test it..
That appears to require a running CUPS server.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Antoine Jacoutot:
> CVSROOT: /cvs
> Module name: ports
> Changes by: ajacou...@cvs.openbsd.org 2020/12/06 02:00:22
>
> Modified files:
> x11/gtk+3 : Makefile distinfo
> x11/gtk+3/pkg : PLIST-main
>
> Log message:
> Update to gtk+3-3.24.24.
> Amongst other change
Jeremy Evans:
> Now that PostgreSQL 13.1 is out, I think we can consider upgrading to
> it. The diff below was tested on amd64 on a partial bulk of the ports
> depending on PostgreSQL.
>
> Could we please have this tested in a bulk?
I ran this through a bulk build on amd64. Two build failures
Ingo Schwarze:
> > It is GNU project policy that distribution tarballs include
> > pre-formatted .info files so that makeinfo is NOT required.
>
> tar -tzvf groff-1.23.0.rc1.tar.gz | grep -F .info
>
> tells me the groff project doesn't include it in the tarball, but
> maybe i can convince them
Ingo Schwarze:
> There is another reason why now is a good time to switch priorities.
> Upstream has been doing lots of work on documentation, and in that
> context, they decided to use newer makeinfo(1) features that our
> ancient /usr/bin/makeinfo does not support. The natural consequence
> is
Marc Espie:
> On Sat, Nov 14, 2020 at 07:36:31PM +, Mikolaj Kucharski wrote:
> > Before I dig into this, would it be okay, if make clean=depends also
> > cleaned up test dependencies?
Yes, please!
> The other issue is: what semantics.
> make clean=depends will clean build/run depends recursi
Charlene Wendling:
> As such, i'm proposing again the powerpc fixes i brought then
> (see [0]):
>
> - `rlwimi' requires 32-bit integers
> - add AltiVec detection for OpenBSD
My ok from back then still stands.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Emil Engler:
> The cURL project moved to a new domain a few days ago:
> https://daniel.haxx.se/blog/2020/11/04/the-journey-to-a-curl-domain/
>
> This patch changes the domain from curl.haxx.se to curl.se
Thanks. Note that changing the HOMEPAGE also requires a REVISION
bump.
curl.haxx.se will c
Daniel Dickman:
> The comment looks a bit odd.
> -COMMENT= Berkeley's implementation of the logo programming language#'
> +COMMENT= Berkeley's implementation of the logo programming language
An unbalanced single quote causes a problem somewhere. I forgot.
Maybe just syntax highlight
On 2020-09-28, Christian Weisgerber wrote:
>> http://build-failures.rhaalovely.net/aarch64/2020-09-22/x11/e17/elementary.log
>
> Mesa link error. Didn't this use to crash?
The complaints about undefined _mesa_* symbols are a red herring.
edje_cc still crashes as before.
--
On 2020-09-25, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on Tue Sep 22 10:58:30 MDT 2020
> finished at Fri Sep 25 03:27:49 MDT 2020
> http://build-failures.rhaalovely.net/aarch64/2020-09-22/converters/wv2.log
> http://build-failures.rhaalovely.net/aarch64/202
Preparations for the release are proceeding apace and ports need
to keep up with base.
ALL COMMITS NOW NEED TO BE APPROVED BY naddy@ OR sthen@.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Remi Pointel:
> this is the diff to update Python 3.8 to latest release.
>
> sthen@ or naddy@: someone of you could test a bulk build with this diff?
There was one build error (x11/xcolor), but it's not clear that it
was caused by the Python update. I sent details to Remi and Laurence.
--
Chr
The 6.8 release is coming up, and it is time to finalize the ports
tree for the release.
Please, no more new ports and no casual updates. Let's focus on
fixing bugs.
If you don't want to surprised by your favorite application being
broken in the release, make sure to test it NOW. Time is short.
Rafael Sadowski:
> It is very easy to reproduce:
> $ cd /usr/ports/security/argon2 && make test
>
> ===> Regression tests for argon2-20190702
> Building without optimizations
> cc -O2 -pipe -std=c89 -Wall -g -Iinclude -Isrc -pthread -Wextra
> -Wno-type-limits src/argon2.c src/core.c src/blake2
Otto Moerbeek:
> > Is it possible that char* (env_vers_cstr) points to null or garbage
> > because env changed? Or is this nonsense and this cannot happen and
> > env_vers_cstr is always valid with the first match?
>
> No, Posix allows previous values of getenv() to be invalidated by
> subsequenc
On 2020-08-26, "Theo de Raadt" wrote:
> I've encountered a few situations with _mostly offline machines_ where
> the rsync package is need, and thus, 1 file can be copied over for
> pkg_add. I don't think I'm the only person to encounter this situation.
We could link rsync statically with some
Stuart Henderson:
> build failures: 7
> devel/cutter
Here's a fix. If I understand the code correctly, this struct
element is assigned an iterator over a std::unordered_map.
I have confirmed that cutter builds with this on i386.
Index: Makefile
==
The remaining build failures on amd64 due to the LLVM 10 update:
devel/py-llvmlite,python3 needs update to 0.34.0
productivity/aqbanking
Logs:
http://build-failures.rhaalovely.net/amd64/2020-08-07/
--
Christian "naddy" Weisgerber na...@mips.inka.de
The remaining build failures on amd64 due to the LLVM 10 update:
devel/py-llvmlite,python3 needs update to 0.34.0
games/fs2open
productivity/aqbanking
Logs:
http://build-failures.rhaalovely.net/amd64/2020-08-07/
--
Christian "naddy" Weisgerber na...@mips.inka.de
The remaining build failures on amd64 due to the LLVM 10 update:
devel/py-llvmlite,python3 needs update to 0.34.0
games/fs2open
print/scribus
productivity/aqbanking
Logs:
http://build-failures.rhaalovely.net/amd64/2020-08-07/
--
Christian "naddy" Weisgerber na...@
On 2020-08-18, Stuart Henderson wrote:
> build failures: 12
These are the actual i386 failures:
> audio/mscore: out of memory linking
> devel/cutter: narrowing from type 'const unsigned long long' to 'size_t' (aka
> 'unsigned long')
> devel/geany: linking (scintilla)
> geo/pgrouting: ICE (log
Rafael Sadowski:
> > The remaining build failures on amd64 due to the LLVM 10 update:
> > devel/rttr
>
> fixed
I still get the same build errors.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2020-08-13, Christian Weisgerber wrote:
> A shared library has been built with the version number from
> SHARED_LIBS, but during the fake stage this is forgotten and the
> upstream version number used. This produces an error, because the
> file doesn't exist.
>
> It o
The remaining build failures on amd64 due to the LLVM 10 update:
devel/py-llvmlite,python3 needs update to 0.34.0
devel/rttr
games/fs2open
print/scribus
productivity/aqbanking
x11/gnustep/back\ -fuse-ld=bfd not passed through
x11/gnustep/renaissance / sebastia@ is loo
Jeremie Courreges-Anglas:
> > Shared libraries should be linked with -fpic/-fPIC.
>
> naddy committed a fix using -fPIC which is safe to use on all arches.
>
> (I don't know if ports should use ${PICFLAG} from bsd.own.mk when
> practical, but a few ports do it already.)
Once upon a time, it was
Occasionally, print/poppler fails to build with a curious error:
A shared library has been built with the version number from
SHARED_LIBS, but during the fake stage this is forgotten and the
upstream version number used. This produces an error, because the
file doesn't exist.
It only happens _so
(No change from 2020-08-10.)
Here is the list of build failures from the amd64 bulk build started
on 2020-08-12. These are the remaining LLVM 10 fallout:
devel/py-llvmlite,python3
devel/rttr
games/fs2open
net/bro
print/scribus
productivity/aqbanking
x11/gnustep/back
x11/gnustep/renaissance
I di
Jeremie Courreges-Anglas:
> I don't have an i386 ports test rig. naddy, do you still run i386 test
> builds? Else I can just push it in the tree for sthen to pick up in
> the next bulk, it won't make things worse...
I've installed i386 on my spare APU2. I can't run full builds
there, but I can
On 2020-08-10, Stuart Henderson wrote:
> x11/qt4
>
> ld: error: relocation R_386_PC32 cannot be used against symbol cti_vm_throw;
> recompile with -fPIC
defined in ../../JavaScriptCore/release/libjscore.a(JITStubs.o)
referenced by JITStubs.cpp
JITStubs.o:(.text+0x21)
On 2020-08-12, Stuart Henderson wrote:
>> print/scribus
> /pobj/scribus-1.5.5/scribus-1.5.5/scribus/third_party/lib2geom/path.h:260:11:
> error: no viable overloaded '='
This one is probably an easy fix for somebody who actually knows C++.
The problem is in an ancient embedded copy of lib2geom
Christian Weisgerber:
> Here is the list of build failures from the amd64 bulk build started
> on 2020-08-10.
2020-08-09 actually, not that it matters.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Here is the list of build failures from the amd64 bulk build started
on 2020-08-10. These are the remaining LLVM 10 fallout:
devel/py-llvmlite,python3
devel/rttr
games/fs2open
net/bro
print/scribus
productivity/aqbanking
x11/gnustep/back
x11/gnustep/renaissance
I didn't upload new logs. These a
On 2020-08-04, Klemens Nanni wrote:
> I also looked at iconv but rsync configures and builds with it even when
> --disable-iconv gets passed, this smells like some configure* bug.
3.2.2p0 now does not pick up iconv.
I quickly looked over configure.ac, and as far as I can tell (1)
detection that
Here is the list of build failures from the amd64 bulk build started
on 2020-08-07. Unless otherwise marked, these are due to LLVM 10.
cad/qcad
databases/pgadmin3
devel/py-llvmlite
devel/rttr
emulators/dolphin # fix pending
games/fs2open
graphics/dia
mail/rspamd
net/bro
net/libtorre
On 2020-08-08, Stuart Henderson wrote:
> Updated failure logs. Many of these are broken on amd64 too, but
> some are not.
# comments
> built packages
> build failures: 23
> databases/mariadb
> databases/pgadmin3# amd64
> devel/geany
> devel/py-llvmlite # amd64
> devel/rt
Christian Weisgerber:
> > > http://build-failures.rhaalovely.net/amd64/2020-08-03/
> > >
> > > emulators/dolphin
> > > games/gzdoom
> >
> > These two should be 1-liner fixes. See:
> >
> > https://github.com/KhronosGroup/glslang/pull/20
Daniel Dickman:
> > http://build-failures.rhaalovely.net/amd64/2020-08-03/
> >
> > emulators/dolphin
> > games/gzdoom
>
> These two should be 1-liner fixes. See:
>
> https://github.com/KhronosGroup/glslang/pull/2010/commits/24b3e8384e93f3e73b6aa14ea00a30574112f9ba
Yup, and this one, too:
emula
The base system has officially switched to LLVM 10. Snapshots with
the new compiler are available.
Right now I'm signing and uploading the first set of official amd64
snapshot packages built with LLVM 10.
Logs from the remaining build failure:
http://build-failures.rhaalovely.net/amd64/2020-08-0
Stuart Henderson:
> > Wow, that's crazy. Can we have a "bloated" flavor instead so
> > everyone is not subjected to this nonsense?
>
> Or a "weak_hash" flavour for MD5 fans.
xxHash is explicitly a NON-cryptographic hash. It's selling point
is that it is much faster than MD5.
--
Christian "na
On 2020-07-30, Klemens Nanni wrote:
> Any OKs for this diff which updates and brings in all the support?
I haven't gotten around to really looking at this... but since it's
committed now:
This changed rsync from a self-contained port that you could quickly
compile on a clean box to something wi
Matthieu Herrb:
> While building ports as a regular user is discouraged, it's still
> possible. I figured out that openbox doesn't build as myself since I'm
> using /usr/local/bin/tcsh as my shell.
That use of ${SHELL} is definitely wrong. I think it's a quoting
error and wasn't intended.
> The
On 2020-08-01, Christian Weisgerber wrote:
> I have uploaded the failure logs from early builds at
> http://build-failures.rhaalovely.net/amd64-clang/
There's a new 2020-08-01/ subdirectory with the results from the
latest build. With pango fixed, nearly the complete ports tree
I don't think there was any public announcement, but most will have
surmised it by now: The base compiler will soon switch from LLVM 8
to LLVM 10 on all CLANG_ARCHS. This also concerns the linker on
LLD_ARCHS.
This will cause a certain amount of breakage in the ports tree.
We are working on it no
Antoine Jacoutot:
> Sure ok.
> Is there a missing pango bump?
It's only changing the fallthrough annotation so
-Werror=implicit-fallthrough won't abort the build.
There is no code change.
--
Christian "naddy" Weisgerber na...@mips.inka.de
devel/pango fails to build with LLVM 10, which takes out a large part
of the ports tree.
http://build-failures.rhaalovely.net/amd64-clang/2020-07-31/devel/pango.log
The fix has two parts, picked from upstream:
(1) In glib2, define G_GNUC_FALLTHROUGH in such a way that is also
available with LL
mail/bogofilter's build failure with LLVM 10 is another silly case
of a configure script failing to recognize the compiler and treating
is as gcc3 or older.
http://build-failures.rhaalovely.net/amd64-clang/2020-07-31/mail/bogofilter%2Cqdbm.log
$ cc -dumpversion
10.0.0
ok?
Index: patches/patch-co
Omar Polo:
> The following patch is to make audio working on games/godot via libao.
>
> Six years ago, Anton Yabchinskiy added a libao driver[0] to have audio
> working on OpenBSD, but a year later[1] that code was removed. (n.b.:
> all of this was pre godot 2.0)
Frankly, if you are adding an au
In my latest amd64 bulk build, x11/remmina failed to build.
/usr/obj/ports/remmina-1.3.6/Remmina-1.3.6/plugins/www/www_plugin.c:47:10:
fatal error: 'webkit2/webkit2.h' file not found
#include
^~~
1 error generated.
(Full log attached.)
--
Christian "naddy" Weisgerber
On 2020-07-14, Nils Reuße wrote:
> I am not too sure about adding "-I$(top_srcdir)" to the DEFAULT_INCLUDES
> in the two Makefiles (for the two subdirectories), but I couldn't get it
> to compile otherwise. The affected includes are in subdirectories of
> the source, but the compilation step
On 2020-07-14, Jordan Geoghegan wrote:
> I was grepping around the ports tree and I found a few places where
> unnecessary brackets were used with 'tr'. Using square brackets with tr
> for character ranges is unnecessary, and in fact the brackets are
> treated literally:
This is a historical
Parallel building devel/bison fails. There is a race where the
build tries to run the newly compiled bison for its --help output
but doesn't wait for the binary to actually be available.
This is one of these cases that espie@ grumbles about, because it
is due to a problem in our make(1) that trea
In my last amd64 bulk build, textproc/zathura/core failed to build.
Here's the log:
>>> Building on amd64-3 under textproc/zathura/core
BDEPENDS =
[x11/girara;textproc/py-docutils;print/texlive/base,-synctex;devel/
The freedb.org database of compact track listings has shut down.
Any program functionality that tries to fetch from or submit data
to freedb.org is broken now.
An alternative service is available at gnudb.org, see
https://www.gnudb.org/
Below is a list of ports that still appear to use freedb.org
The way we merge back security changes to -stable creates the
situation where we have packages with the same name, but different
contents, e.g. pcre2-10.34 in OPENBSD_6_7 and pcre2-10.34 in
OPENBSD_6_6.
This causes PLIST conflicts when building such packages. I just
tried to build a bunch of port
In my latest amd64 bulk build, emulators/vbam failed to build:
/bin/sh: /usr/local/bin/llvm-ar: not found
Presumably it detects llvm-ar if installed at configure time, and
tries to use it later. Since there is no dependency on devel/llvm,
llvm-ar may have been removed by dpb junking in the meant
Charlene Wendling:
> > Even better, you could add code to query machdep.altivec via sysctl(3)
> > on OpenBSD.
>
> I did that in the attached diff.
ok naddy@
> It appears that running agartest
> freezes my PowerBook and trashed my filesystems without a trace
> as soon as i start a benchmark, som
Charlene Wendling:
> > http://build-failures.rhaalovely.net/powerpc/2020-05-26/x11/agar/agar.log
>
> `rlwimi' needs a 32-bit integer to work with, taken from another
> upstream for the same code [0].
That's the correct fix.
(Although I have to wonder whether that handcrafted optimization
is eve
Charlene Wendling:
> > http://build-failures.rhaalovely.net/powerpc/2020-05-09/devel/geany.log
>
> It's a wild guess, but i think it wants a template with a long argument
> because on macppc:
>
> $ c++ -dM -E - < /dev/null | grep PTRDIFF_MAX
> #define __PTRDIFF_MAX__ 2147483647L
> $ c++ -dM -E -
On 2020-06-13, Klemens Nanni wrote:
> For small ports not so much, but when updating bigger ones with lots of
> patches and/or churn, I always find cumbersome to go scroll back in my
> terminal to look for failed hunks or cd into WRKSRC and look for .rej
> files,
PATCH_DEBUG=No
--
Christian "n
telephony/resiprocate fails to build on non-x86 architectures.
The reason is amazing:
error: Need some way to seed the random number generator
http://build-failures.rhaalovely.net/aarch64/2020-05-30/telephony/resiprocate%2C.log
The culprit is stunRand() in rutil/stun/Stun.cxx. Depending on
opera
Rafael Sadowski:
> On Sun May 17, 2020 at 05:40:31PM +0200, Christian Weisgerber wrote:
> > In my amd64 bulk builds, I keep seeing the occasional print/poppler
> > build failure.
> >
> > In the build stage, libpoppler-glib is built with our SHARED_LIBS
> > versio
devel/tbb fails to build on aarch64:
build/common.inc:81: *** Architecture not detected. Stop.
http://build-failures.rhaalovely.net/aarch64/2020-05-21/devel/tbb.log
The architecture determination logic, which is in a GNU make file
we supply, is incoherent.
The patch below sets the uname_p varia
301 - 400 of 1995 matches
Mail list logo
