Re: chromium-58.0.3029.110_1 fails to build with cllang40

El d�a Saturday, May 20, 2017 a las 08:27:24PM -0700, Kevin Oberman escribi�: > > The full log is here > > > > http://www.unixarea.de/chromium-58.0.3029.110_1.log.gz > > > > matthias > > > Mathias, what platform and version? I had no problem building with clang40 > on 11-STABLE on

Re: chromium-58.0.3029.110_1 fails to build with cllang40

On Sat, May 20, 2017 at 12:47 PM, Matthias Apitz wrote: > Hi, > > In a very recent head (May 19) chromium-58.0.3029.110_1: fails to build > with clang40 in poudriere always with the same meesage: > > ... > 14322/25418] clang++40 -MMD -MF obj/services/ui/ws/lib/server_window.o.d

Re: devel/flang can't link static images

Dear Steve, thanks for your comments! As you noticed, the port is in a very early stage (so is flang itself, I think). The wrapper script is really more of a hack at the moment b/c the actual flang executable is unaware of the location of it's libraries and module files. So ideally I'd like

Re: Portmaster: How to build vulnerable ports?

On Sat, May 20, 2017 at 06:15:09PM +0200, Herbert J. Skuhra wrote: > > No, > > r441132 | kwm | 2017-05-18 10:46:06 +0200 (Thu, 18 May 2017) | 14 lines > > >

Re: devel/flang can't link static images

On Sat, May 20, 2017 at 05:57:42PM -0400, Johannes M Dieterich wrote: > Dear Steve, > > thanks for your comments! As you noticed, the port is in a very early > stage (so is flang itself, I think). Yes, I know it new. Thanks for packaging it up. My attempt at building flang did not go to well.

chromium-58.0.3029.110_1 fails to build with cllang40

Hi, In a very recent head (May 19) chromium-58.0.3029.110_1: fails to build with clang40 in poudriere always with the same meesage: ... 14322/25418] clang++40 -MMD -MF obj/services/ui/ws/lib/server_window.o.d -DV8_DEPRECATION_WARNINGS -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1

Advisory: Delete old libGL packages from poudriere repo before building new port vers

If you have your own poudriere repo and try to do a run based on a list of upgraded packages only, you are likely to encounter several build errors stating that "libglapi conflicts with mesa-libs" or such. To solve this either a) Delete from your repo the packages: freeglut, libGL, libGLE,

Re: port head/x11/kde4-runtime not buildable due to missing distfile

Hi Matthias It seems 16.12.3 was moved to Attic on kde's mirrors. See: http://www.mirrorservice.org/sites/download.kde.org/ls-lR I will fix ports to point to the new location shortly. Thanks for the headsup :) You can fetch it from here in the meantime:

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,

devel/flang can't link static images

Testing the new devel/flang port shows a number of issues with the /usr/local/bin/flang wrapper routine. The contents of the wrapper are #!/bin/sh /usr/local/flang/bin/flang -L/usr/local/flang/lib -lflang -lflangmain \ -lflangrti -lexecinfo $@ where I have wrapped the long line. 1) Compile

Re: Portmaster: How to build vulnerable ports?

bob prohaska skrev: > > In playing with portmaster to compile epiphany the compile stops with > ===>>> www/epiphany 1/1 >> cairo-1.14.6,2 >> freetype2-2.7.1 (2/75) > > ===> Cleaning for freetype2-2.7.1 > ===> freetype2-2.7.1 has known vulnerabilities: > freetype2-2.7.1 is vulnerable: >

Portmaster: How to build vulnerable ports?

In playing with portmaster to compile epiphany the compile stops with ===>>> www/epiphany 1/1 >> cairo-1.14.6,2 >> freetype2-2.7.1 (2/75) ===> Cleaning for freetype2-2.7.1 ===> freetype2-2.7.1 has known vulnerabilities: freetype2-2.7.1 is vulnerable: freetype2 -- buffer overflows CVE:

audio/rosegarden

Still broken, still unable to build due to file mismatch ===>  Staging for rosegarden-17.04 ===>   rosegarden-17.04 depends on executable: dssi_osc_update - found ===>   rosegarden-17.04 depends on executable: flac - found ===>   rosegarden-17.04 depends on executable: wavpack - found ===>  

Re: graphics/mesa-libs ... issues

On Sat, May 13, 2017 at 10:20:41AM -0700, David Wolfskill wrote: > In my Saturday poudriere run, I encountered a failure in > graphics/mesa-libs that I'm not understanding how to fix (or evade) > after updating the ports working copy to r440771: > > ... > [00:00:00] >> Creating the reference

port head/x11/kde4-runtime not buildable due to missing distfile

Hello, I'm building ports in head (last svn update May 19) and the above port fails in poudriere due to missing distfile: # cat distinfo TIMESTAMP = 1490531914 SHA256 (KDE/applications/16.12.3/kde-runtime-16.12.3.tar.xz) = 7e6406b9d85594fdedb2bd424316159f5633fbe8b28970338e4d81418f4017eb SIZE

FreeBSD Port: hs-pandoc-1.15.0.6_1

Port out of date. Current version is: 1.19.2.1 (31 Jan 2017) -- Best regards, Jennifer Mack ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to

Re: How should we name node-js ports ?

On 20/05/2017 07:56, Julian Elischer wrote: > this brings up the whole question of whether we should package these > things ourselves anyhow. > python and perl have their own schemes (pip et al.) and with npm (and > others) node is no exception. > it seems that to chase these packages down

Re: How should we name node-js ports ?

On 14/5/17 8:16 pm, Rodrigo Osorio wrote: Hi, I have a bunch of nodejs ports to add, most of them as dependencies, and I wonder if we can find a naming standard like adding 'node' or 'node-js' prefix in the name ; I personally prefer 'node'. As a result a port who install the node package xxx