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
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
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
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
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
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,
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
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
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
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,
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-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
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-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
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
Remi Pointel:
> this diff updates python 3.7 to latest release 3.7.4.
> Could you test it in a bulk build please?
There were no problems on amd64.
--
Christian "naddy" Weisgerber na...@mips.inka.de
A few words about cleaning up PERMIT_PACKAGE_*, since I've done
similar changes before.
You might think this will take care of itself over time, as ports
are updated and modified, they'll eventually all get cleaned up.
Past experience suggests that this won't happen or will take a very
long time.
Raphael Graf:
> Does anyone know why the large file support is disabled in mpg123?
Because it doesn't make sense. off_t is always the same on OpenBSD
and does not change depending on how code defines _FILE_OFFSET_BITS.
--
Christian "naddy" Weisgerber na...@mips.inka.de
The update to LLVM 8.0.0 broke a few ports. Most have been fixed, but
these remain:
===> games/dxx-rebirth
"undefined symbol: dxx_error_object_type_mismatch()"
http://build-failures.rhaalovely.net/amd64-clang/2019-06-19/games/dxx-rebirth.log
The FreeBSD port has a newer version that appears to ha
databases/skytools fails to build:
txid.c:207:6: error: use of undeclared identifier 'SerializableSnapshot'
This first showed up in a test build with LLVM 8.0...
http://build-failures.rhaalovely.net/amd64-clang/2019-06-19/databases/skytools.log
... but that was a coincidence. It also happens wit
Matthias Kilian:
> I'd like to drop the default FLAVOR?=no_qt5 bootstrap and also the
> pseudo flavor bootstrap in the next update of poppler (poppler-0.77.0),
> unless full bulk builders protest.
>
> BTW: is it really a problem if the default poppler build also needs
> qt5 during bulk builds?
I
This is a randomly recurring print/poppler build failure:
--->
CMake Error at glib/cmake_install.cmake:47 (file):
file INSTALL cannot find
"/usr/obj/ports/poppler-0.76.1/build-amd64/glib/libpoppler-glib.so.8.12".
Call Stack (most recent call first):
cmake_install.cmake:238 (in
Christian Weisgerber:
[ninja 1.9.0]
> > Anybody willing to give it a chance in a bulk?
>
> I have started an amd64 bulk build with this.
All errors are of this type:
ninja: error: build.ninja: multiple rules generate XXX [-w dupbuild=err]
The initial build failures were
devel/d
Rafael Sadowski:
> Anybody willing to give it a chance in a bulk?
I have started an amd64 bulk build with this.
> > --- Makefile24 Oct 2018 14:28:00 - 1.26
> > +++ Makefile14 Apr 2019 18:05:49 -
> > @@ -9,8 +9,7 @@ COMMENT = small build system with a foc
>
Stuart Henderson:
> > ld: error: undefined symbol: std::__1::basic_ostream > std::__1::char_traits >::operator<<(std::__1::basic_ostream > std::__1::char_traits >& (*)(std::__1::basic_ostream > std::__1::char_traits >&))
> > >>> referenced by TodoDB.cc
> > >>>
> > >>> TodoDB.o:(Todo
patrick@ is preparing to update the system compiler to LLVM 8.0.0.
A first step is updating libc++, libc++abi, libunwind.
(There's a diff at cvs:~patrick/abi.diff.2.)
I'm currently running a test build with this. One of the first
victims is productivity/devtodo:
ld: error: undefined symbol: std:
Christian Weisgerber:
> > This update is a bit more then just upstream fixes from u202 though u212.
> > In addition to those upstream fixes, it includes a bunch of FreeBSD port
> > patches that were merged into the bsd-port upstream repo. I don't
> > anticipate an
Kurt Miller:
> > I have started an amd64 one with this.
>
> Oh thank you but the plist files will change for all the ports that use the
> JDK due to the multipackage removal.
It's a test build. I run those with PLIST_REPOSITORY= to avoid
contaminating the plist database, and I don't upload the
k...@intricatesoftware.com:
> This update is a bit more then just upstream fixes from u202 though u212.
> In addition to those upstream fixes, it includes a bunch of FreeBSD port
> patches that were merged into the bsd-port upstream repo. I don't
> anticipate any fallout or regressions from those
li...@wrant.com:
> On amd64 latest snap, a recent w3m package installation segfaults on run:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x16d1b18988e7 in GC_mark_from () from /usr/local/lib/libgc.so.4.0
> Current language: auto; currently minimal
Fallout from changes to ld.s
Jeremie Courreges-Anglas:
> So far we only need this for one arch, maybe a cheaper approach would be
> enough? The diff below just tests whether ld.bfd exists.
On archs other than LLD_ARCHS, that diff would stat() ld.bfd every
time bsd.port.mk is parsed.
Let's do this only when USE_LLD switches
USE_LLD=No is confusing on aarch64. The setting creates a wrapper
script ${WRKDIR}/bin/ld that execs /usr/bin/ld.bfd... which does
not exist on aarch64, resulting in build errors like
configure: error: C compiler cannot create executables
See `config.log' for more details
I'm uncertain what to d
Marc Espie:
> Yep, -F will try to fetch everything.
> If you want an option to ignore BROKEN ports, that's do-able.
No, I think the lesson is not to slap BROKEN on unfetchable ports.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Marc Espie:
> > E=education/anki:anki-2.0.52-source.tgz
> >
> > What do I need to delete to get rid of this persistent fetch error?
>
> How about some actual logs ? like what's in the lock ?
locked=education/anki:anki-2.0.52-source.tgz
dpb=23845 on ariolc.mips.inka.de
> and what's in the dist/
Christian Weisgerber:
> E=education/anki:anki-2.0.52-source.tgz
>
> There is no such error on machines where dpb did not perform a fetch
> run during the brief window when anki-2.0.52 was enabled.
Actually, I think that's a misunderstanding on my part. I was
comparing dpb -F2
Marc Espie:
> > E=education/anki:anki-2.0.52-source.tgz
> > What do I need to delete to get rid of this persistent fetch error?
>
> Look in distfiles/history ?
It's not in distfiles/history or distfiles/distinfo.
There were entries in distfiles/build-stats/amd64 that I removed
to no result.
--
Solene Rapenne:
> Did you clean the distfile fetch lock in $PORTSDIR/logs/$arch/locks/?
Yes.
--
Christian "naddy" Weisgerber na...@mips.inka.de
A while back, education/anki was updated to 2.0.52. dpb -F tried to
fetch it, but failed. Shortly afterwards, the anki port was marked
BROKEN. Ever since, dpb on this machine has kept reporting this
fetch error:
E=education/anki:anki-2.0.52-source.tgz
It simply doesn't forget.
There is no such
Christian Weisgerber:
> > So i've stopped sndiod in the chroot, restarted sndiod on my main
> > install, then started audacious in the chroot: the white noise
> > issue is back.
>
> The chrooted audacious doesn't see the /tmp/sndio/sock0 socket. It
> a
Charlene Wendling:
> So i've stopped sndiod in the chroot, restarted sndiod on my main
> install, then started audacious in the chroot: the white noise
> issue is back.
The chrooted audacious doesn't see the /tmp/sndio/sock0 socket. It
acts as if there was no sndiod running. libsndio will try
Charlene Wendling:
> - It doesn't build with ports-gcc (macppc [0], sparc64 [1])
>
> The problem here is again a macro vs function issue. I've applied
> the same thing upstream still does on audacious proper [2]:
> undef'ing feof(3).
That part is fine.
> - At least on macppc, it does so
On 2019-05-12, Christian Weisgerber wrote:
> Update devel/gettext to 0.20.1.
>
> It will also require tweaking the *_DEPENDS of dependent ports and
> bumping the REVISION of all ports that have a LIB_DEPENDS/RUN_DEPENDS
> on one of the gettext components. I'll handle th
Rafael Sadowski:
> Update youtube-dl to 2019.05.11.
Required to download anything from YouTube now.
ok naddy@
--
Christian "naddy" Weisgerber na...@mips.inka.de
All shared libraries should have a SONAME:
$ readelf -d /usr/lib/libc.so.95.0 | fgrep '(SONAME)'
0x000e (SONAME) Library soname: [libc.so.95.0]
I ran a throwaway script over the packages from an amd64 bulk build,
and the libraries listed below lack a SONAME.
On 2019-05-03, Christian Weisgerber wrote:
> Would it be possible to use and __LP64__ to set these
> instead of hardcoding individual archs?
Here's the diff.
ok?
Index: Makefile
===
RCS file: /cvs/ports/games/stepmania
Marc Espie:
> All in all, it looks like the patch is in good shape.
>
> There's another important thing to do, which is to
> actually document it.
>
> I'd like a patch to bsd.port.mk(5)
I have attached an updated version of the infrastructure/mk diff,
incorporating the feedback, as well as a ma
On 2019-05-11, Christian Weisgerber wrote:
> Splitting gettext into separate ports imposes a small maintenance
> burden: The gettext-tools build needs to be tweaked to pick up
> pre-installed libintl and libtextstyle.
It also reaches into libtextstyle and wants to copy some header
f
gettextpo9.0 # 5.5
+
+SUBST_VARS=VERSION
CATEGORIES=devel
# DPB: parallel-safe, not worth it. Too much time in configure
@@ -20,21 +32,34 @@ MAINTAINER= Christian Weisgerber
Index: distinfo
===
RCS file: /cvs/p
GNU gettext consists of two fairly distinct parts:
* gettext-runtime: Runtime libraries and programs.
* gettext-tools: Tools and documentation for developers and translators.
Upstream recommends that these are packaged separately.
This looks like a sterling case for MULTI_PACKAGES. However, since
Here's a draft for CONFIGURE_STYLE=autoreconf. No man page parts
yet.
Basically it works like "autoconf" but calls autoreconf instead.
There are also example changes to two simple ports in the diff below.
ajacoutot@ has been approaching this from a slightly different angle:
He wants to call auto
Brian Callahan:
> phessler@'s latest aarch64 bulk showed that games/stepmania failed to build.
> The attach patch fixes things on it and armv7 as a bonus.
> ++/* detect arm64 and arm */
> ++#if defined(__OpenBSD__)
> ++ #if defined(__aarch64__)
> ++#define ENDIAN_LITTLE
> ++#define ENDIA
Charlene Wendling:
> TL;DR: i can't get libmp4v2 build with C++14.
I'll take your word for it.
> Thanks for this one. There are a lot of them actually: mostly
> narrowing to int errors, there is an integer overflow somewhere
> i guess, but i can't find it, for example:
>
> util/mp4art.cpp:378
Charlene Wendling:
> > > src/cmeta.cpp:1386:16: error: converting to 'bool' from
> > > 'std::nullptr_t' requires direct-initialization [-fpermissive]
> > > return NULL;
If that's the only problem, then these could just be fixed by
changing them to "return false".
> > Again, it breaks because
Charlene Wendling:
> > > http://build-failures.rhaalovely.net/powerpc/last/net/toxcore.log
> >
> > This port uses base-gcc, that doesn't recognise "-Wno-c99-extensions".
This only disables a warning.
How about simply removing the "-Wno-c99-extensions"?
--
Christian "naddy" Weisgerber
* Security update of graphics/png to 1.6.37:
CVE-2019-7317: use-after-free in png_image_free()
* Switch library soname from libpng16.so to libpng.so by changing
the primary name in the build. Bump major version.
Regression tests pass on amd64 and aarch64.
OK?
Index: Makefile
==
Leaving the bumping of dependent ports aside, here's what I have
collected so far as the required changes to actually perform the
switch from gcc4.9 to gcc8:
* switch gcc4 module to gcc/8
* register the gcc/8 subpackages as updates for their gcc/4.9 counterparts
* sync the gcc version in devel/llv
On 2019-04-27, Christian Weisgerber wrote:
> amd64, arm, i386
> These are the other clang archs. They only use gcc4 for a limited
> number of ports. The affected ports should receive an explicit
> REVISION bump. All ports that have a LIB_DEPENDS or RUN_DEPENDS
> on la
Switching ports-gcc from gcc4.9 to gcc8 causes a PLIST change in all
dependent ports. E.g.:
--- /usr/ports/plist/amd64/libcerf-1.11
+++ /usr/ports/plist/amd64/libcerf-1.11-new
@@ -5,7 +5,7 @@
@arch amd64
+DESC
@sha eJKgQhCdr8i1gVOn1LSaMv4pNozHOTosL7nNrpe6GJU=
-@depend lang/gcc/4.9,-libs:gcc-li
With everybody eager to switch ports-gcc to gcc8, I'm still a bit
hazy about which architectures gcc8 is actually known to work on.
To the best of my knowledge:
should be fine
aarch64 already switched
amd64 successful bulk build
powerpc successful partial build
sparc6
gcc 4.9's gcj package failed to own one of its directories. The result
is that lib/gcc/*-unknown-openbsd6.5/4.9.4/include/gcj will be left
after deinstalling the package.
This fixes the PLIST. OK?
Index: Makefile
===
RCS file: /cvs
Stuart Henderson:
> Oh, just register the conflict and @pkgpath. Yes that would work
> through a pkg_add -u upgrade, I'm happy with that.
I tried the patch below (@conflict, @pkgpath, gcj listed as obsolete
in quirks), but pkg_add chokes if gcj-4.9.4 is installed:
Detected loop, merging sets ok
Stuart Henderson:
> Currently the various gcc-libs subpackages (gcc-libs-4.9.4p18 and
> gcc-libs-8.3.0)
> are not set as conflicting with each other:
Are we approaching this the wrong way?
Is there a reason to keep 4.9 around and installable in parallel to 8?
(6 isn't even linked to the build.)
On 2019-04-16, Christian Weisgerber wrote:
> math/fftw3
Strike that one; it was a spurious build failure unrelated to gcc.
--
Christian "naddy" Weisgerber na...@mips.inka.de
I removed /usr/bin/gcc and ran a test build on amd64. These ports
broke because they have calls to "gcc" hardcoded somewhere:
lang/compcert
lang/nim
math/fftw3
misc/rocrail
--
Christian "naddy" Weisgerber na...@mips.inka.de
The 6.5 release package builds are running; the fast architectures
have already finished.
Time to move on. The ports tree is UNLOCKED again.
--
Christian "naddy" Weisgerber na...@mips.inka.de
By my count there remain five ports than can ONLY be built with
base-gcc:
audio/festival/core
devel/ti-msp430gcc
editors/TeXmacs
multimedia/avidemux
sysutils/firmware/vmm
These ports are living on borrowed time. base-gcc WILL go away,
and possibly sooner than you think, so they will ne
math/py-pandas,python3 failed to build in my latest amd64 bulk build.
Any idea what happened there?
>>> Building on amd64-3 under math/py-pandas,python3
BDEPENDS =
[lang/python/3.6;math/py-numpy,python3;devel/py-set
Jeremie Courreges-Anglas:
> samba-4.8.11 has just been released:
> https://www.samba.org/samba/history/samba-4.8.11.html
BTW, whatever happened to cherry-picking the relevant security fix
and only committing this before release (or in -stable), instead
of whole updates?
--
Christian "naddy" W
This week may be the last chance to test packages before they are
cast in stone for the 6.5 release. Anybody who wants to verify
rather than pray that their favorite package works as expected in
6.5 should check now.
Every release, people delay this until it is too late and then
suffer disappoint
Obviously, openvpn-auth-ldap was still picking up some obsolete objc
base header files in configure:
checking objc/objc.h usability... no
checking objc/objc.h presence... no
checking for objc/objc.h... no
configure: error: Can't locate Objective C runtime headers
*** Error 1
This fixes the build:
Stuart Henderson:
> > https://www.samba.org/samba/history/samba-4.8.11.html
>
> I think we want this for release if possible.
I agree.
> have you had chance to test on !clang?
This must be confirmed.
--
Christian "naddy" Weisgerber na...@mips.inka.de
The t2k19 hackathon has concluded and the ports tree is now locked
for the 6.5 release. Important(!) fixes are still possible for a
brief period. Committers need to ask sthen@ or me for approval.
--
Christian "naddy" Weisgerber na...@mips.inka.de
The bulk build logs show a number of warnings
Unescaped left brace in regex is deprecated here (and will be
fatal in Perl 5.32)
coming out of Texinfo/Parser.pm.
Fix below, identical to what textinfo-6.6 does.
ok?
Index: Makefile
==
This should fix another 31 instances of
Unescaped left brace in regex is deprecated here (and will be
fatal in Perl 5.32)
in a bulk build.
ok?
Index: Makefile
===
RCS file: /cvs/ports/textproc/texi2html/Makefile,v
retrieving r
The build logs show many instances of this warning:
Unescaped left brace in regex is deprecated here (and will be
fatal in Perl 5.30)
This fixes automake-1.1[0-4]. Newer versions already have the fix,
older ones don't have this code.
ok?
Index: 1.10/Makefile
===
I would like to remove the CONFIGURE_STYLE=autoupdate setting.
"Autoupdate? What?"
Straight from the gnu's mouth:
| The autoupdate program updates a configure.ac file that calls
| Autoconf macros by their old names to use the current macro names.
Why would you use this in a port? You wouldn't.
On 2019-03-30, Christian Weisgerber wrote:
> Here's the trivial graphics/png update to 1.6.36, no ABI changes,
> along with a patch to set the soname to libpng.X.Y rather than
> libpng16.X.Y.
I'm postponing this until after the 6.5 release.
--
Christian
I would like to remove CONFIGURE_STYLE="automake". This is a very
confusing setting. Crucially, it does not actually run automake.
Nobody I've talked to understands it or what its point is. Today
I have removed the few remaining uses in the tree.
There are two patches attached. One removes "au
On 2019-04-01, Christian Weisgerber wrote:
> This syncs the color code in sysutils/colorls with FreeBSD's. In
> particular, it adds a long option --color=WHEN for compatibility
> with GNU coreutils.
As Theo privately pointed out, this is getting ridiculously bloated.
Two environ
This syncs the color code in sysutils/colorls with FreeBSD's. In
particular, it adds a long option --color=WHEN for compatibility
with GNU coreutils.
People who actually use colorls may want to give this one a try.
Index: Makefile
=
Here's the trivial graphics/png update to 1.6.36, no ABI changes,
along with a patch to set the soname to libpng.X.Y rather than
libpng16.X.Y. Unfortunately the whole libpng build framework is
commited to the latter.
Hmm, does the soname change require a major bump?
Index: Makefile
=
HOMEPAGE= https://www.nano-editor.org/
MAINTAINER=Christian Weisgerber
-MASTER_SITES= https://www.nano-editor.org/dist/v3/ \
+MASTER_SITES= https://www.nano-editor.org/dist/v4/ \
${MASTER_SITE_GNU:=nano/}
PORTROACH= site:https://www.nano-editor.org/dist/latest
Maintenance update to curl 7.64.1 for numerous bug fixes.
https://curl.haxx.se/changes.html
No security vulnerabilities have been announced.
I'm posting this here because I'm delirious from jet lag due to t2k19
travel right now.
Index: Makefile
Sometimes during amd64 bulk builds, an individual port just hangs
until dpb kills off a process...
KILLED: build stuck at 13% frozen for 60mn
... although other processes related to that port continue to hang
around.
I'm starting to see a pattern. The remaining processes are a
parent-child cha
Kurt Mosiejczuk:
> Small point release. CHANGELOG does not indicate any API changes in the
> library so I didn't bump the shared library versions.
You can't really trust that. Especially for a port...
> Consumers seem to be... everything.
... like this. To verify:
* Use /usr/src/lib/check_s
Stephen Gregoratto:
> Bash 5.0 has just been released[1], and I thought I'd try and update the
> port. I'm having problems getting the `seq` builtin to compile.
> I've attached the (truncated) log, but the gist of it is this:
I have finally updated the bash port. Sorry, that should not have
tak
It looks like the libc++ 7.0.1 update on our clang archs has broken
devel/boost:
In file included from libs/log/src/syslog_backend.cpp:29:
In file included from ./boost/asio/buffer.hpp:27:
In file included from ./boost/asio/detail/string_view.hpp:23:
/usr/include/c++/v1/experimental/string_view:11
Andreas Kusalananda Kähäri:
> You'll find a patch for an update to the shells/yash port attached.
Thank you. The way upstream publishes new releases doesn't work
with portroach and, honestly, I had forgotten about the port.
> (BTW, there's an earlier srand() call in the same file, but maybe
> t
Charlene Wendling:
> + void color2(color_t color, ld part) {
> + unsigned char *c = (unsigned char*) (&color);
> + GLfloat cols[4];
> +- for(int i=0; i<4; i++) cols[i] = c[3-i] / 255.0 * part;
> ++ for(int i=0; i<4; i++)
> ++#if SDL_BYTEORDER == SDL_BIG_ENDIAN
> ++cols[3-i] = c[3-i]
George Koehler:
> - unsigned char* c = (unsigned char*) &col; return c[i];
> + unsigned char* c = (unsigned char*) &col;
> +#ifdef __BIG_ENDIAN__
> + return c[sizeof(col) - i];
> +#else
> + return c[i];
> +#endif
>}
Off by one:
return c[sizeof(col) - 1 - i];
__BIG_ENDIAN__ is nonstanda
Charlene Wendling:
> > http://build-failures.rhaalovely.net//powerpc/2019-01-01/x11/bbpager.log
>
> It fails because some headers are missing. With those patches, it
> builds [1] and runs [2] fine on macppc, and doesn't break amd64 build.
>
> Comments/feedback are welcome!
Personally, I try
Stephen Gregoratto:
> Bash 5.0 has just been released[1], and I thought I'd try and update the
> port.
I'll look at updating the bash port sometime in the next few days.
At the moment I'm busy with GNU tar, which had a new release a few
days earlier, and which is again an exercise in frustration
Remi Pointel:
> this is the diff to update Python 3.6 to latest release.
> @naddy: could you test it in a bulk build please? Thanks in advance.
Done. No problems from this.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2019-01-05, Christian Weisgerber wrote:
> The net/munin port triggers a bug in gmake. [...]
Found it (read.c):
p = value;
while ((name = find_next_token ((const char **)&p, &length)) != 0)
{
if (*p != '\0')
*p++ = '\0
The net/munin port triggers a bug in gmake. sthen@ has marked munin
as BROKEN on i386 because during the build gmake regularly segfaults,
but that's just dumb luck.
Here is a much simpler GNUmakefile that reproduces the problem:
>
DUMMY := $(shell echo "===> I'm being parsed!
On 2018-12-19, lan...@openbsd.org wrote:
> http://build-failures.rhaalovely.net//sparc64/2018-12-09/cad/qucs.log
gcc 6.4 fails even earlier with a similar ambiguity regarding pow().
This port should really be updated to the latest upstream version
based on a newer Qt before anybody bothers with
Stefan Sperling:
> Another possible fix for us would be to move the check for 'long long'
> before the one for 'long' (see below) but I don't know what upstream
> would say about that.
I considered this, but it doesn't fix the underlying problem and
just inverts the issue. It would work for us,
On 2018-12-16, Stefan Sperling wrote:
> APR's configure script figures out that off_t is 'long long' on
> OpenBSD but at the same time sets APR_OFF_T_FMT to "ld".
That sounds like a generic problem that should be fixed generically...
> I suspect we should add OS-specific overrides to APR's conf
Charlene Wendling:
> Here is a fix [1] for libaudiofile that allows building [2] with
> ports-gcc-6.4 on macppc.
What problem are you trying to fix?
The last build log I can find
http://build-failures.rhaalovely.net/powerpc/2018-11-20/devel/libaudiofile.log
shows the error I already fixed in rev
On 2018-12-03, Stuart Henderson wrote:
> # Defend against clang being used on x86-32 without SSE2 enabled. As current
> # versions of clang do not understand -fexcess-precision=standard, the use of
> # x87 floating point operations leads to problems like isinf possibly
> returning
> # false for
501 - 600 of 1995 matches
Mail list logo
