On 2020-05-23, "Anthony J. Bentley" wrote:
> Formats like .woff and .woff2, which are meant to be served over
> the web, don't benefit in the same way, because they're installed to
> /usr/local/share and need to be copied to a web server directory
> to be of any use. [...]
> A few recent port sub
On 2020-05-18, Klemens Nanni wrote:
> Passing EXTRACT_FILES as is has the advantage of using sh(1)'s brace
> expansion as shown in the diff, using make's :QL would have the
> advantage of not preventing porters from passing bogus values,
I'm undecided, but I will mention that brace expansion is
On 2020-05-17, Christian Weisgerber wrote:
> Should we have infrastructure support for this, like FreeBSD's
> EXTRACT_ONLY?
For the record: I misremembered. FreeBSD's EXTRACT_ONLY is something
else entirely.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2020-05-15, Klemens Nanni wrote:
> The distfile is only about 40M big but extracts to 205M sources, of
> which we only ever need two directories that sum up to 7M; it also
> makes it clearer what this port actually requires from upstream and
> WRKSRC is lot cleaner.
Didn't this come up with
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
version number, e.g. libpoppler-glib.so.19.5.
In the fake stage, cmake tries to install the library with the upstream
version number, e.g. libpopple
Alessandro De Laurenzis:
> I extensively use wmctrl, but it never worked reliably for me on all my
> amd64 machines (specifically, the -l option didn't list all X clients and
> the workspace number for sticky windows was clearly wrong).
>
> I recently decided to have a look at the code and discov
Martijn van Duren:
> So msgfmt crashes an insane amount of times on alpha (rough guess is 75%
> of the time) which is a pain when building other packages.
That is odd. Why does this only happen on alpha? When did it start
happening on alpha? Years ago I had an alpha and this is a "new"
problem
Stuart Henderson:
> ---
> uacme is a lightweight client for the RFC8555 ACMEv2 protocol used with
> certificate authorities to validate and issue X509 certificates. It is
> written in plain C with minimal dependencies (libcurl and one of GnuTLS,
> OpenSSL or mbedTLS) and can handle all authenticat
The ports tree is locked for 6.7 now.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Aisha Tammy:
> Another bump because this makes gpg wks service work correctly.
> Would love to get this into 6.7.
Thanks for being so persistent. I couldn't raise the maintainer
either, so I took a look:
> >> CONFIGURE_ARGS += docdir=${LOCALBASE}/share/doc/gnupg2 \
> >> +
On 2020-04-18, Charlene Wendling wrote:
> - 'configure' only allows overriding of LLVM_LLD with a path, thanks to
> ac_cv_path_LLVM_LLD, and we don't want "hardcoded" paths where we can
> avoid them
We don't?
Something like ac_cv_path_TAR=/bin/tar is totally fine.
Not sure how this applies t
On 2020-04-25, phess...@openbsd.org wrote:
> started on Wed Apr 22 00:58:02 MDT 2020
> finished at Fri Apr 24 19:24:46 MDT 2020
> http://build-failures.rhaalovely.net/aarch64/2020-04-22/editors/xwpe.log
clang backend error
> http://build-failures.rhaalovely.net/aarch64/2020-04-22/graphics/vul
With the release approaching, ports work should slow down.
If you want to update a port, ask yourself: Do we need this now?
Is it important? What does it fix? Assume you'll break something:
How much effort will be required to fix it?
There's a new gettext point release. Nothing important in NE
On 2020-04-16, Brian Callahan wrote:
> Here is an update to GNU awk, released yesterday.
> The announcement, including the major changes, is here:
> https://lists.gnu.org/archive/html/info-gnu/2020-04/msg7.html
Do we need this now?
Maybe wait until after the release?
--
Christian "naddy"
On 2020-04-17, Christopher Zimmermann wrote:
> here's a straightforward minor update of OCaml.
Since every update to OCaml seems to cause some breakage that needs
sorting out afterwards, I suggest to hold off on this until after
the release.
--
Christian "naddy" Weisgerber
On 2020-04-14, phess...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/aarch64/2020-04-11/games/burgerspace.log
Cannot read
/usr/obj/ports/sdl-mixer-1.2.12/fake-aarch64/usr/local/lib/libSDL_mixer.la: No
such file or directory
This looks odd. Did something go wrong on the build mac
On 2020-04-14, Brad Smith wrote:
> But there are more archs than just sparc64 which are !clang archs.
Realistically, once sparc64 has crossed, the ports situation on the
remaining !clang architectures will deteriorate fast. The only
other !clang arch on which we still build release packages is
We are approaching the 6.7 release. The ports tree is not locked
yet, but it's time to slowly take the foot off the pedal and to
refrain from far-reaching changes.
I'd love if the fallout from switching powerpc to clang could be
cleaned up in time for the release. Using clang is intended to
make
On 2020-04-08, Bjorn Ketelaars wrote:
> Diff below brings audacious to 4.0.1. Changes:
> https://audacious-media-player.org/news/45-audacious-4-0-released
> https://audacious-media-player.org/news/46-audacious-4-0-1-released
>
> Upstream has switched to Qt5 by default but still offers GTK2 suppor
math/py-scipy,python3 failed to build in my latest amd64 bulk build.
This was before the py-numpy update.
It seems that libcblas is picked up during the build, but there is
no dependency. Anyway, I'm appending the full log. Somebody with
interest in that area please have a look.
--
Christian "
People have been switching ports from Python2 to Python3. In some
cases, this appears to bubble up to dependent ports and break them:
games/freeorion undefined symbol: PyString_FromStringAndSize
games/gemrb undefined symbol: Py_InitModule4_64
graphics/piglit Could NOT
On 2020-03-28, Stuart Henderson wrote:
>> > Can somenoe commit the numpy update as well then?
>>
>> I am about to start a test bulk build on i386 with this.
>
> No build problems relating to the numpy update.
Meanwhile, the existing port (1.14.6p2) errored out in my latest bulk
build:
numpy/co
On 2020-03-27, Brad Smith wrote:
>> Here are updates to SDL2 2.0.12, SDL2_gfx 1.0.4 and SDL2_ttf 2.0.15.
>
> Here is an updated diff. Reverts a commit in the new release for the
> time being which broke building with CMake based ports using SDL2.
I put this through a full bulk build on amd64; no
Klemens Nanni:
> > * Use the -delete operator to remove files and empty directories.
> > I'm ambivalent about this since it isn't POSIX, but people seem
> > to like it.
> All major find implementations have it, its faster and much less error
> prone;
Well...
I have a few more tweaks to existi
Tim Kuijsten:
> > Missing type checks should be easily added to every incovation lacking
> > them, they're clearer to read and might even speed things up by
> > preventing direcctory names to be matched against "*.orig" for example.
>
> I've always thought *not* using -type and matching purely on
Make use of "find -exec {} +" (which is POSIX) and "find -delete"
(which is not) throughout the ports Makefiles.
Specifically:
* Replace find|xargs with find -exec {} +
find|xargs is an outdated construct. The -exec {} + invocation
automatically avoids a number of corner cases (see xargs -0,
This updates MASTER_SITE_OSDN_JP to a haphazardly chosen list of mirrors
that
- support https
- resolve to different IP addresses
- are geographically distributed
- support IPv6 (except for the primary one, sigh)
OK?
Frankly I wonder if there is any point to maintaining such mirror
lists...
Inde
Marc Espie:
> --- bin/portbump 27 Jun 2018 16:20:08 - 1.22
> +++ bin/portbump 19 Feb 2020 15:52:58 -
> @@ -98,6 +98,18 @@ my @_REV_NEIGHBORS_WEAK = qw(
> );
> my $_rev_neighbors_plain_all = join('|', @_REV_NEIGHBORS,
> @_REV_NEIGHBORS_WEAK);
>
> +sub run_make
> +{
> +
I tried to add a debug package for shells/bash, but the result would
only contain debug data for some loadable modules and skip the actual
bash binary.
Oh, of course. It is marked @shell and not @bin in the PLIST.
We could change OpenBSD/PackingElement.pm to add @shell to the
binary types... but
Charlene Wendling:
> > http://build-failures.rhaalovely.net/sparc64/2020-02-05/devel/ddd.log
> (not yet on powerpc)
>
> This is happening since the libXt update and the subsequent fix of ddd.
> Putting _X_NORETURN as a declaration identifier [0] fixes the issue on
> powerpc [1] and does not break
Rafael Sadowski:
> Ninja 0.10.0 was released a while ago. Here is a link to the notes:
> https://groups.google.com/forum/#!msg/ninja-build/piOltAhywFA/zPfkrTtRCwAJ
>
> This diff needs a hand full of OKs from persons in charge of the bulks.
No problems in a bulk build on amd64.
--
Christian "na
On 2020-02-04, Jeremie Courreges-Anglas wrote:
> It fails to package though, because of an installed (gmp-6.1.2p3) vs
> built packages mismatch. My brain is unavail right now, so I'll let you
> sort this out. :)
The problem is that the LIB_DEPENDS resolves to a package spec of
gmp-*. We could
Stuart Henderson:
> Really ports-gcc ought to be using a compatible version of gas.. Do we need
> a ports-binutils?
ports-gcc doesn't generate the assembly in question. It's original
assembly code that the compiler just passes through to as(1).
--
Christian "naddy" Weisgerber
Jeremie Courreges-Anglas:
> Fails to build on sparc64:
> build log: https://pbot.rmdir.de/9cefjLlzIP4QEsKwn-g0UA
> tmp-gcd_11.s: https://pbot.rmdir.de/pWyiZKnS6FSGcqsuuLs-YQ
Thanks.
The problem is this upstream commit:
https://gmplib.org/repo/gmp/rev/20cf1131dc94
It uses %gdop(), which is not i
This updates devel/gmp to 6.2.0.
gmp has a ton of machine-specific optimizations, so success on one
arch doesn't mean it will work elsewhere.
I have successfully run the regression tests on
* aarch64
* amd64
* i386
I'd like to see it tested on a few more archs, say, powerpc/sparc64/
mips64, befor
I'll quote the GNU make 4.3 release notes:
--->
* NOTE: Deprecated behavior.
Contrary to the documentation, suffix rules with prerequisites are being
treated BOTH as simple targets AND as pattern rules. Further, the
prerequisites are ignored by the pattern rules. POSIX spec
Christian Weisgerber:
> I'll start another test build shortly.
Remaining fallout:
multimedia/gstreamer-0.10/plugins-good
multimedia/gstreamer-0.10/plugins-bad
These need the same fix as plugins-base.
devel/jdk/11
Upstream fix available.
Commits ready, pending approval from the re
On 2020-01-22, Christian Weisgerber wrote:
> These failed to build:
multimedia/gstreamer-0.10/plugins-base fixed
devel/libfirmfixed
emulators/mame commit pending
devel/jdk/11 tentative upstream fix availa
Christian Weisgerber:
> These failed to build:
>
> devel/jdk/11?
> devel/libfirm # vs. \#
> emulators/mame spaces not added by +=
> multimedia/gstreamer-0.10/plugins-
On 2020-01-20, Christian Weisgerber wrote:
> I'll run an amd64 bulk build with it sometime in the next few days.
> The "WARNING: Backward-incompatibility!" changes could break some
> cruft.
These failed to build:
devel/jdk/11
Brian Callahan:
> Attached is an update to gmake.
I worked on this independently and comparing the results, I have
some objections:
* We can use the .tar.lz distfile.
* MODGNU_CONFIG_GUESS_DIRS should not be removed but set to the
correct ${WRKSRC}/build-aux.
* Instead of patching tests/scri
What's the policy for adding debug packages to ports?
Is the intend to add debug packages...
* eventually to all ports
or
* only to ports where they seem particularly useful?
--
Christian "naddy" Weisgerber na...@mips.inka.de
Thomas Frohwein:
> It looks like this is because the bundled OCaml deps in
> ocamldeps/extlib contain binary-compiled parts in the .cmx files [1].
> My bad, I thought this was only interpreted code.
>
> I propose either setting the port to ONLY_FOR_ARCHS=amd64 as in the
> diff below, or BROKEN un
(ddd is cruft, the latest release dates from 2009, so this isn't
really important.)
After the libXt 1.2.0 update in xenocara, devel/ddd fails to build:
--->
/usr/obj/ddd-3.3.12/ddd-3.3.12/ddd/exit.C:815:12: error: no matching function
for call to 'XtAppSetErrorHandler'
(void)
On 2019-12-26, Jeremie Courreges-Anglas wrote:
> /usr/local/lib/libgmp.so.10.0: warning: vsprintf() is often misused, please
> use vsnprintf()
On a side note, this warning is unfixable. gmp_sprintf() and
gmp_vsprintf() are part of the GMP API and inherently have to use
vsprintf().
--
Christi
Brian Callahan:
> Attached is a new port, sysutils/mangl. Mangl is a graphical manual page
> viewer using mandoc.
That's better than xman!
> It uses OpenGL to display man pages with clickable hyperlinks and smooth
> scrolling.
Bug: If you start it with the name of a page on the command line,
e
Reyk Floeter:
> TL;DR: this is an experimental port update to add U2F/FIDO support and
> I'd appreciate testing and feedback.
https://demo.yubico.com/webauthn/
Registration and subsequent login work fine for me with
* HyperFIDO Titanium (9 EUR, Amazon's Choice)
* Yubico Security Key
--
Christ
Rafael Sadowski:
> Thanks for the bulk build and the report. libobjc2 uses
> CMAKE_THREAD_LIBS_INIT wrong. CMAKE_THREAD_LIBS_INIT is the lib and not
> a linker flag. Tested with current and upcoming cmake.
FYI, I tried another bulk build with the cmake 3.16.0 update and
this libobjc2 patch, and t
Rafael Sadowski:
> here is a relatively straightforward update to the latest stable
> version. As always, we need brave people to test this diff
> in a bulk build.
The only build error was x11/gnustep/libobjc2.
However note that this takes out x11/gnustep/* and a few other
ports.
---
Brian Callahan:
> Attached is a straightforward update to misc/ytree.
> Switches things to HTTPS, cleans up a warning.
> The update itself doesn't add new functionality, but clarifies/updates
> the license.
ok
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2019-12-02, Kurt Mosiejczuk wrote:
> I'm noticing lang/guile2 being one of the longer builds that doesn't
> do multiple jobs at once for the sparc64 builds. I've run it with
> MAKE_JOBS=4 several times on my amd64 test box and had no issues.
I haven't noticed it as a bottleneck. And in fact,
On 2019-12-03, Antoine Jacoutot wrote:
>> # XXX libreoffice has its own way to build things in parallel
>> USES_PARALLEL_MAKE = No
>>
>> ?
>
> +1
Like USES_GMAKE, USES_GROFF, USES_LIBTOOL, ...?
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2019-12-01, Marc Espie wrote:
> This patch:
> - admits that parallel make is going to be used;
> - renames PARALLEL_BUILD to something that reflects its actual usage
> (and consumers as well): PARALLEL_USES_MAKE
> - adds a PARALLEL_MAKE_JOBS that allows the user to tweak the number
> of MAKE_J
On 2019-12-01, Christian Weisgerber wrote:
>> Here's an update for shells/tcsh to 6.21.00, which came out in May.
And now to 6.22.01, which was released yesterday.
Both 6.21 and 6.22 are bug fix releases with no new features.
All regression tests pass.
>> Comments, OKs, prefe
Christian Weisgerber:
> Here's an update for shells/tcsh to 6.21.00, which came out in May.
> People who actually use tcsh--I don't--might want to give it a try.
>
> A number of regression tests used to fail because the built-in echo
> in our sh always interprets backsla
Here's an update for shells/tcsh to 6.21.00, which came out in May.
People who actually use tcsh--I don't--might want to give it a try.
A number of regression tests used to fail because the built-in echo
in our sh always interprets backslash sequences. The switch to the
latest autoconf has fixed
On 2019-11-29, Stuart Henderson wrote:
> Currently we require BUILD_DEPENDS to avoid tripping the (very useful)
> poisoning that we have to detect ports with a missing dependency on
> gettext-tools. This used to be fine, but now gettext-tools includes
> libraries, a port may have LIB_DEPENDS inst
On 2019-11-27, Stuart Henderson wrote:
> Wondering whether it's worth adding this to the port, or whether it's
> uncommon enough that we might as well just wait and pick it up with the
> next upstream release:
> https://gitlab.com/libtiff/libtiff/commit/0356ea76bac908c61160d735f078437ace953bd3
M
On 2019-11-26, Landry Breuil wrote:
> How about enabling xz and zstd, per
> https://marc.info/?l=openbsd-ports&m=155263750504508&w=2 ?
New diff.
Index: Makefile
===
RCS file: /cvs/ports/graphics/tiff/Makefile,v
retrieving revision
On 2019-11-26, Landry Breuil wrote:
> How about enabling xz and zstd, per
> https://marc.info/?l=openbsd-ports&m=155263750504508&w=2 ? Got zero
> feedback on it, but the complete geo/gis stack would have a use for it
> (via geotiff & gdal..)
Fine by me.
WANTLIB+=lzma zstd will eventually have
Maintenance update of graphics/tiff to 4.1.0.
http://www.simplesystems.org/libtiff/v4.1.0.html
As far as I can tell, the changes only warrant a minor bump of the
library.
The ChangeLog file in the tarball has more details than the web
page, something like 25 integer overflows. This might warrant
Pierre-Emmanuel Andr?:
> Updated diff attached.
I tried another test build, but that was derailed by the libcroco
issue, so I don't have full results. A partial result is that
databases/postgresql-plr
geo/pgpointcloud
fail to build. See the attached log files.
I'll try yet another test build
Christian Weisgerber:
> > > Diff updated to the latest version of PostgreSQL : 12.1.
> > > I think it's time to put it in a bulk.
> >
> > Updated diff after the upgrade to 11.6.
>
> I have started an amd64 bulk build with this.
databases/postgresql fail
Pierre-Emmanuel Andr?:
> > Diff updated to the latest version of PostgreSQL : 12.1.
> > I think it's time to put it in a bulk.
>
> Updated diff after the upgrade to 11.6.
I have started an amd64 bulk build with this.
--
Christian "naddy" Weisgerber na...@mips.inka.de
net/qbittorrent/qbittorrent-nox failed to build in my latest amd64 bulk
build. This looks like an accidental/forgotten dependency on
security/libgcrypt:
>>> Building on amd64-3 under net/qbittorrent/qbittorrent-nox
Klemens Nanni:
> I've also squeezed a syntax check into fake because why not bail out on
> errors rather than packaging them.
>
> Overall diff below.
> OK?
Obviously ok naddy@
But let's wait what the MAINTAINER... oh, never mind then. :-)
--
Christian "naddy" Weisgerber
On 2019-11-14, Klemens Nanni wrote:
> Feedback? OK?
Here's a bunch more script tweaks. This is somewhat style/personal
preference territory. --exclude can be used with listing mode.
--- reposync.orig Thu Nov 14 21:24:57 2019
+++ reposyncThu Nov 14 21:32:45 2019
@@ -31,30 +31,30 @@
I would like to update the arbitrary-precision arithmetic libraries
devel/mpfr -> 4.0.2pl1
devel/libmpc -> 1.1.0
The versions we have in the tree are quite old and portroach didn't
pick up the new releases.
These ports are dependencies for lang/gcc/8, which makes them important.
I've built thes
The adastrap depends on several libraries (libc, libm, libz, libgmp,
libmpfr, libmpc), but currently only libc and libm ship with it.
If one of the other libs changes, boom, the build breaks. Also,
having to manually specify the library versions in the Makefile is
cumbersome.
I have revised the a
-HOMEPAGE= http://sourceforge.net/projects/braincurses/
-
-MAINTAINER=Christian Weisgerber
# GPLv2
PERMIT_PACKAGE=Yes
-MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=braincurses/}
-
-WANTLIB= c m curses ${COMPILER_LIBCXX}
+WANTLIB= c curses m ${COMPILER
Charlene Wendling:
> games/bastet is segfaulting at startup on macppc when built with
> ports-clang. If built with ports-gcc [0], the runtime is good.
ok
> Also, it's BROKEN-sparc64, but the last attempt is old, it may be
> worth trying it again.
Yes.
> # Block.s: Assembler messages:
> # Bl
The removal of mobileip(4) has broken shells/nsh.
The patches below simply remove mobileip support from nsh and update
the MANUAL, including a paragraph that became obsolete when mobileip(4)
was added. I don't use nsh at all, but with this it compiles again.
ok?
Index: Makefile
During my latest amd64 bulk build, devel/boost failed to build
because it couldn't find . I assume this is a race
condition, hidden dependency, or some such, since boost built fine
before. Any ideas?
Here's the tail end of the build:
-
Nick Holland:
> I live in EST5EDT. (actually, I normally use
>/usr/share/zoneinfo/right/US/Michigan )
^
I suspect this to be the trigger for your problem. You have put
yourself into a parallel universe whose time is offset by 27 seconds
from our world. Don't do
On 2019-10-22, Stuart Henderson wrote:
> Here are some of the ports persistently seeing this error from cmake/ninja:
FWIW, I don't see this on amd64 at all.
--
Christian "naddy" Weisgerber na...@mips.inka.de
The 6.6 release is largely done and the ports tree is open for
commits again.
I would like to ask everybody to take things still slowly for the
next few days and avoid library bumps or big rototilling commits
(PostgresQL...). Imports are fine.
--
Christian "naddy" Weisgerber
On 2019-10-10, adr wrote:
> I found that '|' can't be used in exrc files, unless a 0x16 precedes
> it. This is what the code does in seq.c. The problem is in both
> editors/nvi and base.
I have the vaguest memory that '|' might be special in exrc...
In my mutt configuration, I call vi with this
The ports tree is now locked for the 6.6 release. No more commits.
If something truly critical comes up, talk to sthen@ and me.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2019-10-06, phess...@openbsd.org wrote:
> critical path missing pkgs:
> http://build-failures.rhaalovely.net/aarch64/2019-10-04/summary.log
This is an excellent result. The ports situation on aarch64 has
made a lot of progress over the course of this release cycle, with
changes both big an
On 2019-10-07, Charlene Wendling wrote:
>> I admit I haven't followed the subject of __atomic* at all.
>> What's the reason to enable the use of these primitives only for
>> powerpc/hppa and not on all archs?
>
> GCC has no 64-bits __sync* operators support on macppc and hppa, the
> newer __atomi
[I already sent pascal@ a private copy of this.]
graphics/openimageio fails to build on aarch64:
http://build-failures.rhaalovely.net/aarch64/2019-10-04/graphics/openimageio.log
There is an upstream commit that is supposed to fix this...
https://github.com/OpenImageIO/oiio/commit/c4a107aa3480be12
On 2019-10-06, Charlene Wendling wrote:
> Upstream introduced since 1.1.4 a cmake flag allowing the use of
> __atomic* functions instead of unsupported __sync* ones.
>
> Once provided, it builds fine on macppc [0]. I have not bumped
> REVISION, it never had a package built before that.
I admit
security/aircrack-ng fails to build on aarch64 and arm:
http://build-failures.rhaalovely.net/aarch64/2019-09-27/security/aircrack-ng.loghttp://build-failures.rhaalovely.net/arm/2019-07-19/security/aircrack-ng.log
clang refuses to compile the code that makes use of the NEON SIMD
instructions:
https
www/py-webpy,python3 failed to package in my latest amd64 bulk build.
>>> Building on localhost under www/py-webpy,python3
BDEPENDS = [devel/py-setuptools,python3;lang/python/3.7]
DIST = [www/py-webpy:web.py
On 2019-10-04, Klemens Nanni wrote:
>> Traceback (most recent call last):
>> File "./setup.py", line 48, in
>> ver = Cython.__version__
>> AttributeError: module 'Cython' has no attribute '__version__'
>> *** Error 1 in math/py-pandas (/usr/ports/lang/python/python.port.mk:226
>> 'do-buil
On 2019-10-03, Jeremy Evans wrote:
> Unless another kind soul takes care of it first, I will be working
> on updating the rest of the ports tree to work with PostgreSQL 12
> during p2k19.
Good plan. This will not make 6.6.
--
Christian "naddy" Weisgerber na...@mips.in
The cutoff for the OpenBSD 6.6 release is approaching quickly.
It's time to stop importing new ports, to consider whether an update
is NEEDED for the release, and to address known problems instead.
Also, the time to test packages is running short. If you want to
check that your favorite applicat
math/py-pandas,python3 failed to build in my latest amd64 bulk build.
Here's the tail end of the build (the full log is attached):
Compiling pandas/_libs/writers.pyx because it depends on
/usr/local/lib/python3.7/site-packages/Cython/Includes/cpython/pystate.pxd.
Compiling pandas/io/msgpack/_pack
xpdf 4.02 fixed an out-of-bounds write, CVE-2019-16927.
The German Federal CERT classified the vulnerability as "high risk",
"remote attack", and "arbitrary code execution".
Based on the report and the vague response...
https://forum.xpdfreader.com/viewtopic.php?f=3&t=41885
... I extracted and ada
Currently, if you try to build the "float" flavor of math/fftw3 before
the "double" flavor, packaging will fail. The *.cmake files are in
fact not shared between the flavors; there are separate FFTW3Config and
FFTW3fConfig files. The patch below moves them from -common to the
flavored -main packa
Kurt Miller:
> It looks like colord failure took out a lot of ports. I am unable
> to reproduce the segfault in the build log:
This is a sporadic segfault. It is machine independent and happens
on amd64, too. It is fairly easy to reproduce on amd64, just run
colord in a build loop. Nobody has
On 2019-09-14, phess...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/aarch64/2019-09-12/security/nss.log
Fixed.
--
Christian "naddy" Weisgerber na...@mips.inka.de
One of the longstanding build failures on aarch64 is x11/e17/elementary.
This turned out to be actually not one, but two problems.
Enlightenment comes with its own script language engine that is
used during the build. The lexer doesn't handle input bytes with
the eighth bit set. On signed char a
Rafael Sadowski:
> I built widelands without any warnings with the diff below. That was
> simple.
ok naddy@
(sparc64 might still be broken, but let's give it a try.)
> --- Makefile 28 Aug 2019 14:12:49 - 1.27
> +++ Makefile 5 Sep 2019 18:20:50 -
> @@ -1,15 +1,13 @@
> # $OpenBSD:
The distfiles for the x11/e17/* ports are no longer available from
the master site (but they are on the OpenBSD distfile mirror).
It looks like they actually are still available at
http://download.enlightenment.org/att/releases/
However, only as tar.bz2 and our ports currently have the tar.gz
vers
Rafael Sadowski:
> With my patch the build creates ~1-2MB log file without ~316MB.
> What's wrong with disabling these flags?
Before the cmake 3.15 change the port used the same flags but did
not spew so many compiler warnings. Clearly the actual problem is
with the the cmake change, but you wan
Klemens Nanni:
> - introduce ${MK} helper variable: better readability, less repitition
>
> Tested on amd64 with obviously no PLIST change.
> Feedback? OK?
MK isn't defined anywhere in this diff.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2019-08-27, Jeremie Courreges-Anglas wrote:
> lang/g77 is the only user of devel/libf2c.
> ok to remove lang/g77 and devel/libf2c?
ok
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2019-08-21, Stuart Henderson wrote:
>> > * If you build ghidra on a system where gcc/g++/libstdc++ are
>> > available, it does indeed link something against libstdc++ and
>> > port-lib-depends-check indicates WANTLIB+=stdc++.
>> >
>> > * If you build ghidra on a system where gcc/g++/libst
On 2019-08-22, Kurt Mosiejczuk wrote:
> I figure it's worth adding the old PERMIT_* forms to the positioned
> obsolete entries in /usr/ports/infrastructure/tempalte/mk.conf.template.
I wanted to suggest the same, but espie@ added them to a list of
forbidden variables in bsd.ports.mk (line 320 ff
401 - 500 of 1995 matches
Mail list logo
