graphics/gd marked as broken?
It's the second week when I am trying to compile ports and poudriere still complains that graphics/gd is broken. Over a hundred or so ports doesn't compile because of that as they all depend on graphics/gd. Is this expected? [00:01:21] >> [04][00:00:00] Starting build of graphics/gd [00:01:21] >> [04][00:00:00] Finished build of graphics/gd: Ignored: is marked as broken: circular dependencies [00:01:22] >> [04][00:00:01] Skipping build of graphics/ImageMagick: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of x11-fm/thunar: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of editors/abiword: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of audio/alsa-plugins: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of editors/openoffice-4: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of archivers/ark: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of sysutils/baloo: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of sysutils/baloo-widgets: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/blender: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of editors/calligra: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of audio/chromaprint: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of www/chromium: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of audio/clementine-player: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/clutter: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of multimedia/clutter-gst: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/clutter-gtk3: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/colord: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of devel/cppunit: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of print/cups-filters: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of textproc/docbook-utils: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of devel/doxygen: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of java/eclipse: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/eog: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/epdfview: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of www/epiphany: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of audio/espeak: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/evince: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of audio/festival-freebsoft-utils: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of multimedia/ffmpeg: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of multimedia/ffmpegthumbnailer: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of sysutils/filelight-kde4: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of www/firefox: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of audio/fluidsynth: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of sysutils/ftwin: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of sysutils/garcon: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of security/gcr: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/geeqie: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of graphics/gegl: Dependent port graphics/gd ignored [00:01:22] >> [04][00:00:01] Skipping build of sysutils/gigolo: Dependent port graphics/gd ignored (... and so on) Greb ___ 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: graphics/gd marked as broken?
Hi! > It's the second week when I am trying to compile ports and poudriere > still complains that graphics/gd is broken. Over a hundred or so ports > doesn't compile because of that as they all depend on graphics/gd. Is > this expected? I think this has to do with WEBP in gd. I just testbuild gd with this: FONTCONFIG=on: X11 font configuration support ICONV=on: Encoding conversion support via iconv VPX=on: VP8/VP9 video codec support XPM=on: XPM pixmap image format support WEBP=off: WebP image format support and had no circular dependencies. Do you need WEBP in gd ? > [00:01:21] >> [04][00:00:00] Starting build of graphics/gd > [00:01:21] >> [04][00:00:00] Finished build of graphics/gd: Ignored: > is marked as broken: circular dependencies -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ 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: graphics/gd marked as broken?
Only WEBP is broken, make sure the option is set to off. ___ 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: graphics/gd marked as broken?
On 20/08/2016 9:17 PM, Walter Schwarzenfeld wrote: > Only WEBP is broken, make sure the option is set to off. Do you think the (error) messaging be improved to make it more obvious to users what's the fail condition is, but more importantly, also what they should/could do about it? The current message does neither. ./koobs ___ 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: Problems with out libgcc_s.so in base
On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote: > On 19/08/2016 10:13, Steven G. Kargl wrote: ... > You should find that all newer copies of libgcc_s contain compatibility > support for binaries that were linked to earlier versions. > Indeed. And the version masquerading as a GNU libgcc_s in base does the same thing. Two problems: our base libgcc_s only covers version up to GCC_4.2.0 and there is a name conflict on the library name with libgcc_s from the gnu compiler. Hence if a program links against base libgcc_s first then requires libgfortran which itself requires support for above GCC_4.2.0, the program fails. OR Whenever a program requires support that is missing on the platform it is running on from our libgcc_s, it will fail. There are numerous PR's on this which all have the common problem of linking with a libgcc_s that does not support > GCC_4.2.0 Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Perl upgrade - 5.20.x vulnerable
Someone posted it in the FreeBSD Forum (in the moment I don't find it). but: http://www.cpan.org/src/ 5.20 5.20.3 End of life 2015-09-12 Nearly, just a year ago. and we have it as default version. (It seems all overlooked it, and I wonder about). ___ 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"
Magnificent! Le guide de la Provence
Magnificent, fascinating journeys and bright unforgettable impressions experienced during these travels are luxury nowadays. Guide to Provence Provence – the Alpes – Cote d’Azur Alpes-Maritimes Vaucluse Alpes-de-Haute-Provence TOP 10 largest yachts at the Côte d'Azur Bouches-du-Rhone Hautes-Alpes Var The guide to Provence with unique proposals that represent a terrific mix of art, fashion, architecture, gastronomy, with an abundance of things and attention to detail that characterize an exceptional journey. On the pages of our guide to Provence you will find a guidebook consisting of short inspirational stories that offer you to discover the abundant life of the Provence region. Cote d'Azur is one of the most prestigious tourist destinations in the world. Provence as before is a favorite place for recreation and residence. Old cities with monuments of architecture and art, exclusive beach resorts, golf courses, picturesque villages of Provence, high class day spa, majestic and grand Alps. All this luxury and comfort
Re: Problems with out libgcc_s.so in base
On Fri, Aug 19, 2016 at 09:50:28PM +0200, Tijl Coosemans wrote:
> On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov
> wrote:
> > The option which would fix all this mess is:
> > 1. add rpath for gcc lib/ directory into spec file
> > and
> > 2. make ports collection use its own compiler instead of fighting with
> >the base.
>
> That still doesn't cover all cases, e.g.:
>
> port exec -> base lib -> libgcc_s.so.1
> -> port lib -> recent libgcc_s.so.1
>
> An example is:
>
> % echo 'int main(void){}' > test.c
> % clang37 -o test test.c -lexecinfo -lgfortran -L/usr/local/lib/gcc5
> -Wl,-rpath,/usr/local/lib/gcc5
> % ./test
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by
> /usr/local/lib/gcc5/libgfortran.so.3 not found
>
> The base library (libexecinfo) doesn't have DT_RPATH or DT_RUNPATH so the
> only way rtld can find the right libgcc_s.so is if the executable (test)
> has DT_RPATH and no DT_RUNPATH. Clang runs ld with --enable-new-dtags
> so the executable has DT_RUNPATH. DT_RPATH is deprecated in the Linux
> world so there are probably more ports that use --enable-new-dtags.
> Another example seems to be Rust.
Indeed, and I rechecked the find_library() code against the latest gABI
once more.
So base libraries linked against libgcc_s are
/lib/libcxxrt.so.1
/usr/lib/libc++.so.1
/usr/lib/libexecinfo.so.1
/usr/lib/libprivatedevdctl.so.0
and only libexecinfo would be somewhat problematic. libcxxrt and libc++
come from C++ runtime, which must be provided by the port's compiler,
the private library should not be linked to by behaving applications.
I suppose that libexecinfo pull unwinder from libgcc_s. It might be
possible just dlopen() libgcc_s for _Unwind_Backtrace, it seems.
___
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: graphics/gd marked as broken?
On 20/08/2016 11:40, Kubilay Kocak wrote: On 20/08/2016 9:17 PM, Walter Schwarzenfeld wrote: Only WEBP is broken, make sure the option is set to off. Do you think the (error) messaging be improved to make it more obvious to users what's the fail condition is, but more importantly, also what they should/could do about it? The current message does neither. ./koobs ___ 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" Wait, so what it actually means that the port is marked as broken? I understood that the maintainer marked the port as broken because it discovered that the port doesn't compile because of circular dependency? Who then actually marked the port as broken? Greg ___ 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: graphics/gd marked as broken?
The port is not broken, it compiles in port and with poudriere. Only if option WEBP is set to on it is broken. look with poudriere options -C -jhailname graphics/gd how is it set, and change it if is to on. ___ 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: graphics/gd marked as broken?
I am not sure. But ImageMagick is depend on graphviz via option.. ImageMagick has an option webp. Graphviz in depend via LIB_CEPENDS on gd. And gd has the webp option. Maybe it is this. ___ 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: Perl upgrade - 5.20.x vulnerable
+--On 20 août 2016 16:25:24 +0200 Walter Schwarzenfeld wrote: | Someone posted it in the FreeBSD Forum (in the moment I don't find it). | but: | http://www.cpan.org/src/ | 5.20 5.20.3 End of life 2015-09-12 | | Nearly, just a year ago. It is not really true. perlpolicy says: o We "officially" support the two most recent stable release series. 5.14.x and earlier are now out of support. As of the release of 5.20.0, we will "officially" end support for Perl 5.16.x, other than providing security updates as described below. o To the best of our ability, we will attempt to fix critical issues in the two most recent stable 5.x release series. Fixes for the current release series take precedence over fixes for the previous release series. o To the best of our ability, we will provide "critical" security patches / releases for any major version of Perl whose 5.x.0 release was within the past three years. We can only commit to providing these for the most recent .y release in any 5.x.y series. So, it is more or less still supported. | and we have it as default version. | | (It seems all overlooked it, and I wonder about). It is not overlooked. As soon as mod_perl supports anything after 5.20, I'll change the default to 5.24. The current rate of Perl releases is a new major release each May, my goal is to switch to it on the next September. Right now, the only thing holding back is mod_perl. -- Mathieu Arnold pgpPDAoxhkOq4.pgp Description: PGP signature
Re: graphics/gd marked as broken?
On 20/08/2016 16:23, Walter Schwarzenfeld wrote: The port is not broken, it compiles in port and with poudriere. Only if option WEBP is set to on it is broken. look with poudriere options -C -jhailname graphics/gd how is it set, and change it if is to on. ___ 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" So, poudriere lies then, it says it's broken: [00:01:21] >> [04][00:00:00] Starting build of graphics/gd [00:01:21] >> [04][00:00:00] Finished build of graphics/gd: Ignored: is marked as broken: circular dependencies Greg ___ 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: graphics/gd marked as broken?
On 20/08/2016 19:11, Grzegorz Junka wrote: On 20/08/2016 16:23, Walter Schwarzenfeld wrote: The port is not broken, it compiles in port and with poudriere. Only if option WEBP is set to on it is broken. look with poudriere options -C -jhailname graphics/gd how is it set, and change it if is to on. ___ 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" So, poudriere lies then, it says it's broken: [00:01:21] >> [04][00:00:00] Starting build of graphics/gd [00:01:21] >> [04][00:00:00] Finished build of graphics/gd: Ignored: is marked as broken: circular dependencies Greg Sorry, I should have been clearer. I know the port isn't broken, I just don't understand why poudriere says it's marked as broken if, according to you, it's a circular dependency and the port isn't marked in any way? Greg ___ 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"
mail/rainloop needs a committer
Hello I validated a good diff for mail/rainloop, can a commiter push it to ports tree ? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211870 Thanks ! -- Best regards, Loïc BLOT, UNIX systems, security and network engineer http://www.unix-experience.fr ___ 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: graphics/gd marked as broken?
On 21/08/2016 04:46, Grzegorz Junka wrote: On 20/08/2016 19:11, Grzegorz Junka wrote: On 20/08/2016 16:23, Walter Schwarzenfeld wrote: The port is not broken, it compiles in port and with poudriere. Only if option WEBP is set to on it is broken. look with poudriere options -C -jhailname graphics/gd how is it set, and change it if is to on. So, poudriere lies then, it says it's broken: [00:01:21] >> [04][00:00:00] Starting build of graphics/gd [00:01:21] >> [04][00:00:00] Finished build of graphics/gd: Ignored: is marked as broken: circular dependencies Greg Sorry, I should have been clearer. I know the port isn't broken, I just don't understand why poudriere says it's marked as broken if, according to you, it's a circular dependency and the port isn't marked in any way? Greg Actually it isn't poudriere - the port itself says it's broken when the WEBP option is enabled. WEBP_BROKEN=circular dependencies So the new version of gd added support for webp, the maintainer added the option to enable it, then marked the option as broken. gd doesn't have WEBP enabled by default so you have settings somewhere to enable it. If you aren't specifically enabling the WEBP option for gd then check that you aren't enabling it globally in OPTIONS_SET In the make.conf for your build add - graphics_gd_UNSET= WEBP If that doesn't work some others to try. graphics_gd_UNSET_FORCE= WEBP OPTIONS_UNSET=WEBP OPTIONS_UNSET_FORCE=WEBP -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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: Problems with out libgcc_s.so in base
On 20/08/2016 21:30, Diane Bruce wrote: On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote: On 19/08/2016 10:13, Steven G. Kargl wrote: ... You should find that all newer copies of libgcc_s contain compatibility support for binaries that were linked to earlier versions. Indeed. And the version masquerading as a GNU libgcc_s in base does the same thing. Two problems: our base libgcc_s only covers version up to GCC_4.2.0 and there is a name conflict on the library name with libgcc_s from the gnu compiler. Hence if a program links against base libgcc_s first then requires libgfortran which itself requires support for above GCC_4.2.0, the program fails. OR Whenever a program requires support that is missing on the platform it is running on from our libgcc_s, it will fail. There are numerous PR's on this which all have the common problem of linking with a libgcc_s that does not support > GCC_4.2.0 Actually the problem is going the other way. A port gets compiled and linked against the newer libs but at run time it finds the base system lib first and loads that which doesn't support the binary that is being run. If the gcc6 libgcc_s was always installed and found first then we wouldn't have this problem. I first found this issue trying to import numpy into blender. As blender had started and was using the base libgcc_s, when I tried to import numpy that needed the newer libgcc_s for it's fortran code it failed. I discovered that setting LD_LIBRARY_PATH in the environment when starting blender got it to load the newer libgcc_s which then worked when importing numpy, so I've been happy doing that for a couple of years. I have seen the same thing were a python module has brought in the base libgcc_s before numpy which needed the newer one. The dynamic loading of python modules seems to be the only time I have seen this. Either changing the import order or LD_LIBRARY_PATH to get the newer lib loaded the first time has solved the issue. So one solution could be to copy the newer libgcc_s into /lib but the newer library won't get added to base as it contains GPLv3 code. Maybe remove /lib/libgcc_s.so to force the search for a newer version. While bug reports have lead to other things, I think the solution might be to configure/patch ld to get it searching paths to find the newer version first. libgcc_s would be such a common case that we could have a permanent ld setting in base to always find a newer libgcc_s before the base version. I haven't been bitten enough to have looked at this. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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"
Can a commiter look at devel/godot
After several changes over the last few months it would be nice if the update to devel/godot and the new devel/godot-tools could get committed. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209742 Thanks -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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"
