FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ emulators/mame | 0.200 | mame0207 +-+ emulators/mess | 0.200 | mame0207 +-+ x11/lxpanel | 0.9.3 | 0.10.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
poudriere 3.3.0: sed RE error
Now that poudriere has been upgraded from 3.2.8 to 3.3.0, when I press ^T during interactive bulk build, I see: sed: 1: "s,^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator operand invalid with many (but not all) build jobs. For example: [00:19:10] [01] [00:00:00] Building devel/dee | dee-1.2.7_11 [00:20:32] [07] [00:07:21] Finished x11-toolkits/gtk20 | gtk2-2.24.32: Success [00:20:34] [07] [00:00:00] Building net/mtr | mtr-0.92_1 [00:20:53] [15] [00:01:51] Finished devel/dconf | dconf-0.28.0: Success [00:20:55] [15] [00:00:00] Building devel/gconf2 | gconf2-3.2.6_5 [00:21:01] [16] [00:03:35] Finished sysutils/bareos-traymonitor | bareos-traymonitor-17.2.7_1: Success [00:21:01] [16] [00:00:00] Building sysutils/sysadm-client | sysadm-client-1.1_1 load: 63.30 cmd: sh 15186 [nanslp] 1281.32r 0.71u 3.78s 0% 3796k [112amd64-srv-default] [2019-02-27_18h22m27s] [parallel_build:] Queued: 216 Built: 143 Failed: 4 Skipped: 0 Ignored: 1 Tobuild: 68 Time: 00:21:21 [01]: devel/dee | dee-1.2.7_11 configure(00:00:37 / 00:02:13) sed: 1: "s,^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator operand invalid tail: stdout [02]: x11-toolkits/open-motif | open-motif-2.3.8 build(00:12:51 / 00:16:04) [03]: lang/mono | mono-5.10.1.57_1 build-depends(00:00:04 / 00:02:38) [04]: java/openjdk8 | openjdk8-8.202.8 package (00:02:40 / 00:14:41) sed: 1: "s,^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator operand invalid [05]: print/texlive-base| texlive-base-20150521_32 build(00:08:52 / 00:11:06) sed: 1: "s,^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator operand invalid tail: stdout [06]: x11-servers/xorg-server | xorg-server-1.18.4_11,1 build(00:04:00 / 00:07:25) [07]: net/mtr | mtr-0.92_1 lib-depends (00:00:25 / 00:00:49) [08]: graphics/qt5-opengl | qt5-opengl-5.12.1 configure(00:01:37 / 00:03:12) [09]: x11-themes/adwaita-icon-theme | adwaita-icon-theme-3.28.0 stage(00:06:30 / 00:07:37) sed: 1: "s,^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator operand invalid tail: stdout [10]: x11-toolkits/qt5-declarative | qt5-declarative-5.12.1 build(00:02:41 / 00:03:50) [11]: graphics/ImageMagick6-nox11 | ImageMagick6-nox11-6.9.10.22,1 stage(00:02:19 / 00:05:55) [12]: graphics/opencv | opencv-3.4.1_13 configure(00:00:17 / 00:03:19) sed: 1: "s,^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator operand invalid [13]: www/qt4-webkit| qt4-webkit-4.8.7_3 build(00:02:11 / 00:05:27) [14]: graphics/librsvg2 | librsvg2-2.40.20 configure(00:01:00 / 00:02:19) [15]: devel/gconf2 | gconf2-3.2.6_5 build-depends(00:00:19 / 00:00:28) [16]: sysutils/sysadm-client| sysadm-client-1.1_1 lib-depends (00:00:04 / 00:00:22) Mark ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Config inconsistency for firefox-esr on rpi2
On Tue, Feb 26, 2019 at 12:54:23AM +0100, Miroslav Lachman wrote: > > Take a look at a dependencies of firefox-esr > https://www.freshports.org/www/firefox-esr/ > > in build dependencies: > gtk3>=3.14.6 : x11-toolkits/gtk30 > > in library dependencies: > libgtk-x11-2.0.so : x11-toolkits/gtk20 > libgtk-3.so : x11-toolkits/gtk30 > > quite confusing gtk20 vs gtk30... > > gtk20 has not option WAYLAND so you need to rebuild gtk30 with option > WAYLAND enabled. > For some reason gtk30 stops with root@www:/usr/ports/x11-toolkits/gtk30 # gdkkeys-wayland.c:34:10: fatal error: 'fribidi.h' file not found #include I tried compiling gtk20 in the hopes it might provide the missing file, but it completed successfully and fribidi.h remains absent. Last resort was to remake wayland, but that didn't help, gtk30 still stops with missing fribidi.h Is there a way out of this box? Thanks for reading, bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Config inconsistency for firefox-esr on rpi2
Install converters/fribidi. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Config inconsistency for firefox-esr on rpi2
On Wed, Feb 27, 2019 at 07:42:57PM +0100, Walter Schwarzenfeld wrote: > Install converters/fribidi. > Already present, and reinstalled to see if it helps. No luck. The file is in /usr/local/include/fribidi/fribidi.h so there must be some sort of path issue. Thanks for reading! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
Hi Tijl, hi everyone,
and let me add Andreas who has been helping on the GCC side (both
ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
And first of all, let me apologize. Clearly the experience both Tijl
as a contributor made, as well as the one some of our users including
some of you was not what I'd like to experience myself as a contributor
and user, nor what I want to provide to others.
There were some personal reasons, not related to Tijl or FreeBSD at all,
but that does not change a thing about those experiences, and I am truely
sorry for those and will work hard to avoid such a case in the future.
On Sun, 24 Feb 2019, Tijl Coosemans wrote:
> GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this
> doesn't explain why this was done, but we'll have to make the same
> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
> part of the ABI). This isn't a blocker for the patch.
>
> I emailed the patch to gerald on 2017-02-21. He responded in the usual
> way that he prefers patches submitted upstream and because I thought the
> patch would not be accepted upstream he proposed an alternative solution
> where gcc would always add -rpath on FreeBSD so you didn't have to
> specify it on the command line. I responded this wouldn't fix the case
> where clang was used as a linker (e.g. to combine fortran and c++ code
> in one program) and that the FAQ on the gcc website said it was a bad
> idea for other reasons. I also said upstream might accept my patch if
> it was a configure option but that the gcc configure scripts are
> complicated and I didn't know where to add it exactly. Then silence.
To move this forward, let me include an updated version of the patch
Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for
consideration for our ports collection, initially for lang/gcc8 given
that this is the default in the ports collection.
(The lang/gcc* ports actually do carry local patches, e.g. for arm or
powerpc or -fuse-ld=lld, but you are right that I usually try to get
things upstream first, fixing things upstream myself when I can, or
asking for help. The problem in this specific case was/is that I'm
quite not enough into this area so cannot really assess and clearly
stalling over that was not good.)
Find patch-gfortran-libgcc attached which should simply plug into
lang/gcc8/files and lang/gcc8-devel/files.
Feedback very welcome!
GeraldGCC has two runtime libraries: The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s). Both implement many of the
same functions but they also each have their unique functions. When
gcc links programs and libraries there are three possibilities:
1. gcc -static-libgcc or gcc -static: -lgcc
=> Just use libgcc.a.
2. gcc -shared-libgcc: -lgcc_s -lgcc
=> Link with libgcc_s first, so libgcc.a is only used for its unique
functions.
3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
=> Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).
Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.
This patch make 3 the default for gfortran. It significantly reduces
the use of libgcc_s. The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran. Consider a dependency tree like this:
prog -> libA -> libgcc_s (old base system libgcc_s is fine)
-> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)
Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang. Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB. With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.
Upstream is unlikely accept a patch like this because libgfortran calls
some _Unwind_* functions and so always needs libgcc_s. Also because
every Fortran program and library links to libgfortran it makes sense
that option 2 above is the default. On FreeBSD where clang and GCC
compiled code can be mixed and where multiple libgcc_s may be installed,
option 3 is just a lot easier to deal with.
The bug that sparked this is PR 208120 (but note there's a lot of
misleading information in that bug. CMake is not actually doing
anything wrong.)
--- UTC
--- gcc/fortran/gfortranspec.c.orig 2015-06-26 17:47:23 UTC
+++ gcc/fortran/gfortranspec.c
@@ -404,7 +404,7 @@ For more information about these matters
}
}
-#ifdef ENABLE_SHARED_LIBGCC
+#if 0
if (library)
{
unsigned int i;
--- libgfortran/Makefile.in.orig2019-02-22 14:22:13.0 +
Re: poudriere 3.3.0: sed RE error
On 27/02/2019 12:51, Mark Martinec wrote: > Now that poudriere has been upgraded from 3.2.8 to 3.3.0, > when I press ^T during interactive bulk build, I see: > > sed: 1: "s,^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator > operand invalid > > with many (but not all) build jobs. For example: > This was caught and just fixed: https://github.com/freebsd/poudriere/pull/658 You will need to patch poudriere yourself if you want the fix before it hits the ports tree, though. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use; replace local-part with vishwin for off-list communication if possible) signature.asc Description: OpenPGP digital signature
