Mark Patruck:
> lang/gcc always fails with the following error on amd64 -current (~6 hours
> old)
>
>
> Check for missing set procedures in body
> OK
>
> All tests completed successfully, no errors detected
>
> raised ADA.IO_EXCEPTIONS.USE_ERROR : sinfo.h: No such
On 2019-07-29, Rafael Sadowski wrote:
> - It doesn't make any sense to keep the m88k XXX tags. CMake don't build
> under m88k, correct?
Remove anything referring to m88k in a port when you see it.
We do not support that platform. The two remaining people in the world
who use m88k can figure i
On 2019-08-04, Antoine Jacoutot wrote:
> That gerbil port has *never* built successfully for me on exopi (amd64) since
> its first import.
By contrast, it builds fine on amd64*.ports.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2019-08-05, Jeremie Courreges-Anglas wrote:
> Or maybe amd64.p and exopi don't use the same limits (login.conf)?
> naddy, ajacoutot?
amd64.p uses the pbuild limits from the default login.conf.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Brian Callahan:
> do-configure:
> + sed -i -e "s,LMAJ,`echo ${LIBmpv_VERSION} | cut -f 1 -d .`,g" \
> + -e "s,LMIN,`echo ${LIBmpv_VERSION} | cut -f 2 -d .`,g" \
> + ${WRKSRC}/libmpv/client.h
> ${DO_WAF} configure ${CONFIGURE_ARGS}
sed -i -e 's,LMAJ,${LIB
On 2019-07-29, Rafael Sadowski wrote:
>> I sent[1] a cmake update to 3.14 which unfortunately has received no
>> attention two months ago. Anyway this is a new try to update cmake.
>
> Here was a small typo at the end of the line. Fixed version below.
I ran this through a full amd64 bulk build,
Jeremie Courreges-Anglas:
> > The below diff allows to build flac on macppc, where tests are passing
> > [1]. I've not bumped revision, the change impacts powerpc where it has
> > never been built.
>
> Good enough for ports, ok jca@
ok naddy@
> If we want this fixed upstream, someone (tm) shoul
In the weeks before a new Firefox release I usually switch to
landry@'s port of the beta version, which I compile myself.
Firefox 69 no longer builds in 5 GB on amd64: llvm runs out of
memory when compiling gkrust.
5.5 GB is sufficient.
I guess we'll have to bump datasize-cur for the pbuild user
The update to FFmpeg 4.2 has introduced a regression in MPlayer. For (at
least) the ubiquitous H.264 videos in MKV containers, seeking in MPlayer
is broken, e.g. when jumping back and forth with the arrow keys. Effects
are desynchronized faulty video and failure to seek. This appears to
affect the
Klemens Nanni:
> Skimming mplayer(1) I could not find out quickly how to seek so far.
Page up/down: +/- 10 min
Cursor up/down:+/- 1 min
Cursor right/left: +/- 10 s
> Can you tell me how to seek in mplayer and also try reproducing it with
> mpv?
On FreeBSD mplayer has the same problem,
Brad Smith:
> > The update to FFmpeg 4.2 has introduced a regression in MPlayer. For (at
> > least) the ubiquitous H.264 videos in MKV containers, seeking in MPlayer
> > is broken, e.g. when jumping back and forth with the arrow keys.
>
> Does this resolve the issue?
-snip-
Yes, it does!
--
Ch
Grepping the ports tree for uses of /usr/bin/gcc turned up
devel/arm-elf/gcc. That port has been marked BROKEN "due to frequent
segfaults during build" for 4.5 years. I guess nobody has missed
it since.
I was going to suggest that we remove the port, but it's part of
four related ones:
devel/ar
A few days ago, I did a test bulk build on amd64 with gcc, g++, and
libstdc++ removed from the system. Ports should not use these any
longer on clang platforms.
security/ghidra failed to build right away since it has stdc++ in
WANTLIB. Further testing shows:
* If you build ghidra on a system wh
Update archivers/bzip2 to 1.0.8. The original author is involved
again.
>From CHANGES:
* Accept as many selectors as the file format allows.
This relaxes the fix for CVE-2019-12900 from 1.0.7
so that bzip2 allows decompression of bz2 files that
use (too) many selectors again.
* Cleanup of b
Rafael Sadowski:
> naddy@ reported build output explosion in the latest bulk after cmake
> update.
In numbers: The log file grows from 8 MB to 319 MB.
> I would suggest turning off the compiler flags.
This does not address the underlying problem. Before the cmake update,
widelands used the _sa
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
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-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
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
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
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:
> 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:
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
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
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
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
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
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
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
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
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
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
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
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
[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-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
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
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-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 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-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
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
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:
-
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
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
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
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
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
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
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
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
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
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-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
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
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
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
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
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
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-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-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
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
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
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)
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
(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
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
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
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
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
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-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
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...@
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
productivity/aqbanking
Logs:
http://build-failures.rhaalovely.net/amd64/2020-08-07/
--
Christian "naddy" Weisgerber na...@mips.inka.de
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
==
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
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
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
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.
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
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
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
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.
--
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.
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
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
==
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
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
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
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
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
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
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
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
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
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
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
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
201 - 300 of 1824 matches
Mail list logo
