Re: Giving Up Maintainership

2014-12-16 Thread Lars Engels 
On Mon, Dec 15, 2014 at 11:22:17PM +0200, Raphael Kubo da Costa wrote:
> Guido Falsi  writes:
> 
> > Unluckily upgrading it will be a problem since new version depends on
> > Python QT5 libraries.
> >
> > So I take a chance to ask:
> >
> > Is there any active work on creating ports for these?
> >
> > Who should I talk about this to?
> 
> I don't think anyone is working on this at the moment. If you're willing
> to do it, please keep kde@ in the loop, as we maintain the existing
> PyQt4 ports and will probably end up either maintaining or touching the
> Qt5 ports a lot.

The PC-BSD guys (cc'ed) are switching their tools to Qt5.


pgp77R2STKLjA.pgp
Description: PGP signature

x11/libxfce4util with unset option NLS results in GNU gettext tools not found

2014-12-16 Thread Kamil Szczesny 

Hello,

I'm applying devel/poudriere on a 10.1-RELEASE to build packages for my 
desktop.
Important for this is that I have unset the option NLS in my 
corresponding /etc/make.conf.
During package build I noticed the following configure error in 
x11/libxfce4util, which is required by x11-fm/thunar:


checking for xgettext... no
checking for msgmerge... no
checking for msgfmt... no
checking for gmsgfmt... no
configure: error: GNU gettext tools not found; required for intltool
===>  Script "configure" failed unexpectedly.

Is there a clean way to fix this, when NLS is unset?
Currently, I can fix this with
 USES+= gettext-tools

Any help is appreciated.
Oh, this configure error also happens for example in devel/geany.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

2014-12-16 Thread portscout 
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
+-+
biology/tinker  | 6.2.6   | 7.0.1
+-+
science/gromacs | 5.0.2   | 5.0.4
+-+


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
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Discrepancy in postgresql entry in UPDATING

2014-12-16 Thread Francois Tigeot 
On Mon, Dec 15, 2014 at 05:41:30PM -0800, Darren Pilgrim wrote:
> The entry reads:
> 
> 20141208:
[...]
>When using binary packages, if you only use the client port, you can
>issue the following command to follow the default version:
> 
># pkg set -o databases/postgresql92-client:databases/postgresql93-client
> 
> The problem is pg_upgrade requires both the old and new versions be 
> installed concurrently--something pkg/ports can't do.  So how are we 
> supposed to upgrade?

With pg_upgrade, I found the best method to be:

- locally build the two postgres versions you're interested in from the
  Postgres distfiles.
- run pg_upgrade from one of them

and don't bother with the packages.

The Postgres packages are fine for regular operation but like you said,
not really adapted for this kind of one shot operation IMHO.

-- 
Francois Tigeot
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Discrepancy in postgresql entry in UPDATING

2014-12-16 Thread Mathieu Arnold 
+--On 15 décembre 2014 17:41:30 -0800 Darren Pilgrim
 wrote:
| The entry reads:
| 
| 20141208:
|AFFECTS: users of databases/postgresql??-(server|client)
|AUTHOR: mar...@freebsd.org
| 
|PostgreSQL version 9.3 is now the default. To upgrade from a version
|lower than 9.3, follow the instructions on the PostgreSQL.org website.
|http://www.postgresql.org/docs/9.3/interactive/upgrading.html
|Please note that the pg_upgrade program is installed by the
|databases/postgresql93-contrib port
| 
|When using binary packages, if you only use the client port, you can
|issue the following command to follow the default version:
| 
|# pkg set -o
| databases/postgresql92-client:databases/postgresql93-client
| 
| The problem is pg_upgrade requires both the old and new versions be
| installed concurrently--something pkg/ports can't do.  So how are we
| supposed to upgrade?

You don't *need* both to be installed, you only really need the postgres
binary for the old version.  What I usually do is:

pkg fetch postgresqlOLD-server
cd /tmp
tar xf /var/cache/pkg/postgresqlOLD-server* -s ,^,pg/,

and run pg_upgrade with the old postgresql being in /tmp/pg/usr/local/bin.

-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: x11/libxfce4util with unset option NLS results in GNU gettext tools not found

2014-12-16 Thread Mark Martinec 

Looks like the same problem as in math/libqalculate,
which is still holding back builds of KDE:

[Bug 195857] math/libqalculate fails to build under poudriere
  (missing dependency on gettext tools?)

Also the same problem is in net/mediastreamer, audio/easytag,
multimedia/audacious, and possibly elsewhere.

  Mark


2014-12-16 09:52, Kamil Szczesny wrote:

Hello,

I'm applying devel/poudriere on a 10.1-RELEASE to build packages for my 
desktop.

Important for this is that I have unset the option NLS in my
corresponding /etc/make.conf.
During package build I noticed the following configure error in
x11/libxfce4util, which is required by x11-fm/thunar:

checking for xgettext... no
checking for msgmerge... no
checking for msgfmt... no
checking for gmsgfmt... no
configure: error: GNU gettext tools not found; required for intltool
===>  Script "configure" failed unexpectedly.

Is there a clean way to fix this, when NLS is unset?
Currently, I can fix this with
 USES+= gettext-tools

Any help is appreciated.
Oh, this configure error also happens for example in devel/geany.


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

emulators/pipelight, BUILD_DEPENDS, and gpg2

2014-12-16 Thread David Wolfskill 
On my laptop, I try to keep things fairly up-to-date: I perform source
updates daily on stable/10, and then update the installed ports (using
portmaster); I keep a local private mirror of the FreeBSD SVN repo
(which I update automagically overnight) locally on the laptop.

Back on 20 Nov, one of the ports that was updated was security/gnupg --
updating that port from gnupg-2.0 to -2.1.  I then discovered
(empirically) that gnupg-2.1 would not decrypt some rather important
information that I had stored, though at the time, I didn't know what
caused this (and I wasn't expecting such a silent POLA-contravening
change merely from a revision number bump).

After a bit of flailing about (on my part), I found that:

portmaster -o security/gnupg20 gnupg-2.1\*

(thus forcing a reversion to gnupg-2.0) resolved the problem in a way
that preserved my access to the information in question.


This morning, one of the ports for which an update was attempted was
emulators/pipelight:

===>>> The following actions will be taken if you choose to proceed:
...
Upgrade pipelight-0.2.7.3_5 to pipelight-0.2.7.3_6
Install security/gnupg


Now, I plead "guilty as charged" to failing to note the stated intent to
try to "Install security/gnupg".  (That attempt failed, by the way:

...
===>  Installing for gnupg-2.1.0_1
===>   Registering installation for gnupg-2.1.0_1 as automatic
Installing gnupg-2.1.0_1...
pkg-static: gnupg-2.1.0_1 conflicts with gnupg20-2.0.26_2 (installs files into 
the same place).  Problematic file: /usr/local/bin/gpg-agent


But that's not the focus of this note.)

Apparently "gpg2 is a BUILD_DEPENDS for emulators/pipelight:

# Created by: Kris Moore 
# $FreeBSD: head/emulators/pipelight/Makefile 374755 2014-12-15 17:00:22Z 
kmoore $

PORTNAME=   pipelight
DISTVERSION=0.2.7.3
PORTREVISION=   6
CATEGORIES= emulators
...
BUILD_DEPENDS=  ${LOCALBASE}/bin/gpg2:${PORTSDIR}/security/gnupg \
${LOCALBASE}/bin/bash:${PORTSDIR}/shells/bash
LIB_DEPENDS=libxml2.so:${PORTSDIR}/textproc/libxml2



And I have "gpg2" available:

g1-253(11.0-C)[19] ls -lToi `which gpg2`
16133409 -r-xr-xr-x  1 root  wheel  - 652956 Nov 22 05:00:32 2014 
/usr/local/bin/gpg2


But I have it from security/gnupg20:

g1-253(11.0-C)[23] pkg-static which `which gpg2`
pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static 
install -f pkg" recommended
/usr/local/bin/gpg2 was installed by package gnupg20-2.0.26_2


Is there, perhaps, a way to construct the BUILD_DEPENDS for pipelight
so that it can use gpg2 from ... well, wherever it was installed
from, and revert to bringing in a new port only if gpg2 isn't
already available?

[PS: Don't let the above-quoted whines about "Major OS version
upgrade detected..." distract you: I had attempted the emulators/pipelight
update under stable/10, as described above.  At the time of this
writing, I had flipped the laptop to boot from a different slice,
where I am performing my daily update of head.]

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Actions have consequences ... as do inactions.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpos53apNtj0.pgp
Description: PGP signature

Re: Discrepancy in postgresql entry in UPDATING

2014-12-16 Thread Darren Pilgrim 

On 12/16/2014 2:51 AM, Francois Tigeot wrote:

With pg_upgrade, I found the best method to be:

- locally build the two postgres versions you're interested in from the
   Postgres distfiles.
- run pg_upgrade from one of them

and don't bother with the packages.


I hadn't thought about that.  I could just build them in the ports tree 
and leave them staged.  Thanks!



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

[Differential] [Request, 136 lines] D1318: Remove BSDPAN.

2014-12-16 Thread mat (Mathieu Arnold) 
mat created this revision.
mat added a reviewer: perl.
mat added subscribers: portmgr, freebsd-perl.

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D1318

AFFECTED FILES
  lang/perl5.14/Makefile
  lang/perl5.14/pkg-plist
  lang/perl5.16/Makefile
  lang/perl5.16/pkg-plist
  lang/perl5.18/Makefile
  lang/perl5.18/pkg-plist
  lang/perl5.20/Makefile
  lang/perl5.20/pkg-plist

To: mat, jadawin, culot, sunpoet, swills, bapt
Cc: freebsd-perl, swills, miwi, mat, antoine, bdrewery, erwin, bapt
___
freebsd-p...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-perl
To unsubscribe, send any mail to "freebsd-perl-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

[HEADSUP]: Remove BSDPAN. (fwd)

2014-12-16 Thread Mathieu Arnold 
Hi,

BSDPAN Since pkg_install support was removed from the ports tree, BSDPAN
has been useless.  As it's no longer working, and more to the point, it now
gives warning people are complaining about, I'm planning to remove it
before x-mas.  I opened a code review:

+ Forwarded Message 
| Date: 15 décembre 2014 17:12:16 +
| From: "mat (Mathieu Arnold)" 
| To: freebsd-p...@freebsd.org
| Subject: [Differential] [Request, 136 lines] D1318: Remove BSDPAN.
| 
| mat created this revision.
| mat added a reviewer: perl.
| mat added subscribers: portmgr, freebsd-perl.
| 
| BRANCH
|   /head
| 
| REVISION DETAIL
|   https://reviews.freebsd.org/D1318
| 
| AFFECTED FILES
|   lang/perl5.14/Makefile
|   lang/perl5.14/pkg-plist
|   lang/perl5.16/Makefile
|   lang/perl5.16/pkg-plist
|   lang/perl5.18/Makefile
|   lang/perl5.18/pkg-plist
|   lang/perl5.20/Makefile
|   lang/perl5.20/pkg-plist
| 
| To: mat, jadawin, culot, sunpoet, swills, bapt
| Cc: freebsd-perl, swills, miwi, mat, antoine, bdrewery, erwin, bapt
| ___
| freebsd-p...@freebsd.org mailing list
| http://lists.freebsd.org/mailman/listinfo/freebsd-perl
| To unsubscribe, send any mail to "freebsd-perl-unsubscr...@freebsd.org"
| 

+-- End Forwarded Message --



-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: emulators/pipelight, BUILD_DEPENDS, and gpg2

2014-12-16 Thread Henry Hu 
On Tue, Dec 16, 2014 at 9:07 AM, David Wolfskill 
wrote:
>
> On my laptop, I try to keep things fairly up-to-date: I perform source
> updates daily on stable/10, and then update the installed ports (using
> portmaster); I keep a local private mirror of the FreeBSD SVN repo
> (which I update automagically overnight) locally on the laptop.
>
> Back on 20 Nov, one of the ports that was updated was security/gnupg --
> updating that port from gnupg-2.0 to -2.1.  I then discovered
> (empirically) that gnupg-2.1 would not decrypt some rather important
> information that I had stored, though at the time, I didn't know what
> caused this (and I wasn't expecting such a silent POLA-contravening
> change merely from a revision number bump).
>
> After a bit of flailing about (on my part), I found that:
>
> portmaster -o security/gnupg20 gnupg-2.1\*
>
> (thus forcing a reversion to gnupg-2.0) resolved the problem in a way
> that preserved my access to the information in question.
>
>
> This morning, one of the ports for which an update was attempted was
> emulators/pipelight:
>
> ===>>> The following actions will be taken if you choose to proceed:
> ...
> Upgrade pipelight-0.2.7.3_5 to pipelight-0.2.7.3_6
> Install security/gnupg
>
>
> Now, I plead "guilty as charged" to failing to note the stated intent to
> try to "Install security/gnupg".  (That attempt failed, by the way:
>
> ...
> ===>  Installing for gnupg-2.1.0_1
> ===>   Registering installation for gnupg-2.1.0_1 as automatic
> Installing gnupg-2.1.0_1...
> pkg-static: gnupg-2.1.0_1 conflicts with gnupg20-2.0.26_2 (installs files
> into the same place).  Problematic file: /usr/local/bin/gpg-agent
> 
>
> But that's not the focus of this note.)
>
> Apparently "gpg2 is a BUILD_DEPENDS for emulators/pipelight:
>
> # Created by: Kris Moore 
> # $FreeBSD: head/emulators/pipelight/Makefile 374755 2014-12-15 17:00:22Z
> kmoore $
>
> PORTNAME=   pipelight
> DISTVERSION=0.2.7.3
> PORTREVISION=   6
> CATEGORIES= emulators
> ...
> BUILD_DEPENDS=  ${LOCALBASE}/bin/gpg2:${PORTSDIR}/security/gnupg \
> ${LOCALBASE}/bin/bash:${PORTSDIR}/shells/bash
> LIB_DEPENDS=libxml2.so:${PORTSDIR}/textproc/libxml2
> 
>
>
> And I have "gpg2" available:
>
> g1-253(11.0-C)[19] ls -lToi `which gpg2`
> 16133409 -r-xr-xr-x  1 root  wheel  - 652956 Nov 22 05:00:32 2014
> /usr/local/bin/gpg2
>
>
> But I have it from security/gnupg20:
>
> g1-253(11.0-C)[23] pkg-static which `which gpg2`
> pkg-static: Warning: Major OS version upgrade detected.  Running
> "pkg-static install -f pkg" recommended
> /usr/local/bin/gpg2 was installed by package gnupg20-2.0.26_2
>
>
> Is there, perhaps, a way to construct the BUILD_DEPENDS for pipelight
> so that it can use gpg2 from ... well, wherever it was installed
> from, and revert to bringing in a new port only if gpg2 isn't
> already available?
>

Have you tried to do "make && make install" in the pipelight port directory?
I think that the port system would consider the dependency resolved if it
finds the file.


>
> [PS: Don't let the above-quoted whines about "Major OS version
> upgrade detected..." distract you: I had attempted the emulators/pipelight
> update under stable/10, as described above.  At the time of this
> writing, I had flipped the laptop to boot from a different slice,
> where I am performing my daily update of head.]
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Actions have consequences ... as do inactions.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>


-- 
Cheers,
Henry
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: emulators/pipelight, BUILD_DEPENDS, and gpg2

2014-12-16 Thread David Wolfskill 
On Tue, Dec 16, 2014 at 10:29:34AM -0500, Henry Hu wrote:
> ...
> > This morning, one of the ports for which an update was attempted was
> > emulators/pipelight:
> >
> > ===>>> The following actions will be taken if you choose to proceed:
> > ...
> > Upgrade pipelight-0.2.7.3_5 to pipelight-0.2.7.3_6
> > Install security/gnupg
> ...
> > Is there, perhaps, a way to construct the BUILD_DEPENDS for pipelight
> > so that it can use gpg2 from ... well, wherever it was installed
> > from, and revert to bringing in a new port only if gpg2 isn't
> > already available?
> >
> 
> Have you tried to do "make && make install" in the pipelight port directory?
> I think that the port system would consider the dependency resolved if it
> finds the file.
> 

I had not; per your suggestion, though, I tried it:

Script started on Tue Dec 16 07:34:37 2014
root@g1-253:/common/home/david # pushd /usr/ports/emulators/pipelight/^M
/usr/ports/emulators/pipelight /common/home/david 
root@g1-253:/usr/ports/emulators/pipelight # make clean install clean^M
===>  Cleaning for gnupg-2.1.0_1
===>  Cleaning for gmake-4.1_1
===>  Cleaning for wget-1.16
===>  Cleaning for pipelight-0.2.7.3_6
===>  License LGPL21 accepted by the user
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/sbin/pkg - found
...
===>  Building for pipelight-0.2.7.3_6
gmake[1]: Entering directory 
'/common/ports/emulators/pipelight/work/mmueller2012-pipelight-79b1b7ba0032'
CXX="g++48" CXXFLAGS="-O2 -pipe -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing  -nostdinc++ -isystem 
/usr/local/include/c++/v1 -Wl,-rpath=/usr/local/lib/gcc48" gmake -C src/linux
...
gmake[1]: Leaving directory 
'/common/ports/emulators/pipelight/work/mmueller2012-pipelight-79b1b7ba0032'
===>  Staging for pipelight-0.2.7.3_6
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/bin/bash - found
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/bin/wget - found
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/bin/zenity - found
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/bin/cabextract - found
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/bin/flock - found
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/bin/gpg2 - found
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/bin/wine - found
===>   pipelight-0.2.7.3_6 depends on executable: gcc48 - found
===>   pipelight-0.2.7.3_6 depends on file: /usr/local/libdata/pkgconfig/x11.pc 
- found
===>   Generating temporary packing list
gmake[1]: Entering directory 
'/common/ports/emulators/pipelight/work/mmueller2012-pipelight-79b1b7ba0032'
...
gmake[1]: Leaving directory 
'/common/ports/emulators/pipelight/work/mmueller2012-pipelight-79b1b7ba0032'
> Compressing man pages (compress-man)
===>  Installing for pipelight-0.2.7.3_6
===>   Registering installation for pipelight-0.2.7.3_6
Installing pipelight-0.2.7.3_6...
...
root@g1-253:/usr/ports/emulators/pipelight # echo $?^M
0
root@g1-253:/usr/ports/emulators/pipelight # exit

Script done on Tue Dec 16 07:37:30 2014

And it appears to have worked:

g1-253(10.1-S)[3] pkg info pipelight-\* gnupg\* pkg-\*
pipelight-0.2.7.3_6
gnupg20-2.0.26_2
pkg-1.4.0
g1-253(10.1-S)[4] 

(without disturbing the gnupg20 installation).

Thanks; that should shed a bit of light on what might have gone wrong.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Actions have consequences ... as do inactions.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpYKa94WnJ0o.pgp
Description: PGP signature

Re: RFT: Please help testing the llvm/clang 3.5.0 import

2014-12-16 Thread Dimitry Andric 
On 28 Nov 2014, at 22:03, Dimitry Andric  wrote:
> 
> We're working on updating llvm, clang and lldb to 3.5.0 in head.  This
> is quite a big update again, and any help with testing is appreciated.
> 
> To try this out, ensure you have good backups or snapshots, then build
> world and kernel from the projects/clang350-import branch [1].  Please
> use a Subversion mirror [2], if you are able to.

Here are some updates about the status of the 3.5.0 import.

* i386 and amd64 have been tested through make universe, and everything
  should compile and run.
* Little-endian ARM builds should now compile and run, thanks to Andrew
  Turner for putting in lots of work.
* Big-endian ARM is apparently supposed to work, but I'm not sure if
  Andrew managed to test it on real hardware.
* PowerPC64 should mostly work, thanks to Justin Hibbits.
* PowerPC32 might start working soon; it really needs some backporting
  of fixes to clang 3.4.1, which is now in head, so there is an easier
  upgrade path for PowerPC users.
* Sparc64 still does not work, and I don't see any quick solutions to it
  for now.  It should probably stay with gcc.
* Mips will only have a chance with the upcoming clang 3.6.0, but that
  is way too late for this import.  It will probably require external
  toolchain support to get it working.
* Another ports exp-run was done [3], after fixing the problem with
  lang/gcc, which lead to many skipped dependent ports.
* The second exp-run had much better results: the failure with the
  highest number of dependencies is devel/mingw32-gcc, but this seems
  to be due to a problem with makeinfo, not clang.  The next highest on
  the list is java/openjdk6, for which ports r374780 [4] was very
  recently committed.

I would really like to merge this branch to head in about a week,
pending portmgr approvall; I don't expect the base system (outside of
llvm/clang) to need any further updates.

Lastly, to clear things up about the requirements for this branch (and
thus for head, in a while); to build it, you need to have:
* A C++11 capable "host" compiler, e.g. clang >= 3.3 or later, or gcc
  >= 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome)
* A C++11 standard library, e.g. libc++, or libstdc++ from gcc >= 4.8.

So from any earlier standard 10.x or 11.x installation, you should be
good, unless you explicitly disabled clang or libc++.  In that case,
you must build and install both of those first.

On a 9.x installation, you will have clang by default, but not libc++,
so libc++ should be built and installed first, before attempting to
build the clang350-import branch.

On 8.x an earlier, you need to upgrade to at least 9.x first, follow
the previous instruction.

As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while
(roughly a month), but this will cause upgrades from 9.x to 10.x to
start requiring the build of libc++, as described above.  I don't think
we can merge clang 3.5.x to 9.x, unless clang becomes the default
compiler there (but that is very unlikely).

-Dimitry

[1] svn://svn.freebsd.org/base/projects/clang350-import
[2] 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn.html#svn-mirrors
[3] 
http://pb2.nyi.freebsd.org/build.html?mastername=head-amd64-PR195480-default&build=2014-12-12_23h17m02s
[4] https://svnweb.freebsd.org/changeset/ports/374780



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [HEADSUP]: Remove BSDPAN. (fwd)

2014-12-16 Thread Torfinn Ingolfsen 
Your mail provided very little reasoning why it should be removed
(instead of fixing it).
Some reasons here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187111

HTH

On Tue, Dec 16, 2014 at 4:19 PM, Mathieu Arnold  wrote:
> Hi,
>
> BSDPAN Since pkg_install support was removed from the ports tree, BSDPAN
> has been useless.  As it's no longer working, and more to the point, it now
> gives warning people are complaining about, I'm planning to remove it
> before x-mas.  I opened a code review:
>
> + Forwarded Message 
> | Date: 15 décembre 2014 17:12:16 +
> | From: "mat (Mathieu Arnold)" 
> | To: freebsd-p...@freebsd.org
> | Subject: [Differential] [Request, 136 lines] D1318: Remove BSDPAN.
> |
> | mat created this revision.
> | mat added a reviewer: perl.
> | mat added subscribers: portmgr, freebsd-perl.
> |
> | BRANCH
> |   /head
> |
> | REVISION DETAIL
> |   https://reviews.freebsd.org/D1318
> |
> | AFFECTED FILES
> |   lang/perl5.14/Makefile
> |   lang/perl5.14/pkg-plist
> |   lang/perl5.16/Makefile
> |   lang/perl5.16/pkg-plist
> |   lang/perl5.18/Makefile
> |   lang/perl5.18/pkg-plist
> |   lang/perl5.20/Makefile
> |   lang/perl5.20/pkg-plist
> |
> | To: mat, jadawin, culot, sunpoet, swills, bapt
> | Cc: freebsd-perl, swills, miwi, mat, antoine, bdrewery, erwin, bapt
> | ___
> | freebsd-p...@freebsd.org mailing list
> | http://lists.freebsd.org/mailman/listinfo/freebsd-perl
> | To unsubscribe, send any mail to "freebsd-perl-unsubscr...@freebsd.org"
> |
>
> +-- End Forwarded Message --
>
>
>
> --
> Mathieu Arnold
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



-- 
mvh
Torfinn
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: RFT: Please help testing the llvm/clang 3.5.0 import

2014-12-16 Thread Jung-uk Kim 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/16/2014 14:36, Dimitry Andric wrote:
> * The second exp-run had much better results: the failure with the 
> highest number of dependencies is devel/mingw32-gcc, but this
> seems to be due to a problem with makeinfo, not clang.  The next
> highest on the list is java/openjdk6, for which ports r374780 [4]
> was very recently committed.

Unfortunately, r374780 was not enough.  Instead, I just turned off
"-Werror" for now (r374824).

https://svnweb.freebsd.org/changeset/ports/374824

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUkKgGAAoJEHyflib82/FGGtAH/jyK3fVhWeXlgID5MKov0+vq
34BwE98ppJWreu4LdkXGqCUZeciyMmcw4ROfEPo6IthIxcHsRleh+O+BnmA5wFce
gMczWBO1R+uEzcSH75UhyaVJVMKy8BJ2vRU2s90GANUnMhcMvNjN0Y89+8PdCHWF
zaR8oy/GlVpJ13RTbyeaMf8K0T6MyQp58VQYP1gmlhjafEjVOLO9IVZyLWVx/nsI
+DtjLj1DdNrPKrV1jrVRmZ+bJqOLaLgL4FUV/vruSduA1U8E1BZgnklXqRPowXqN
jmFbLYE4kiygcEmUnpVbLQeB2EWXbQq7g4pijh90qDrhCSX1rUN3gz2DxY/Mub4=
=reYk
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADSUP]: Remove BSDPAN. (fwd)

2014-12-16 Thread Mathieu Arnold 
+--On 16 décembre 2014 20:41:36 +0100 Torfinn Ingolfsen 
wrote:
| Your mail provided very little reasoning why it should be removed
| (instead of fixing it).
| Some reasons here:
| https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187111

My email provides the only reason to remove it "it does not work with pkg"
and I should have removed it in September when pkg_install was removed but
have been procrastinating about it in case someone came and fixed it.

Now, pkg has been here for 15 months, in that time, nobody fixed it, *I* am
not going to fix it myself, so, I'm removing it.

The source files are around, I'll do the removal in a separate commit than
other things so that it can be backed out easily if it ever comes around
that someone makes it work with pkg.

-- 
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Pkg 1.4.0 and packaging base system

2014-12-16 Thread Cassiano Peixoto 
Hi guys,

Some weeks ago i read an email sent by bapt about new features to pkg 1.4.0
release. One of them was about packaging base system. As 1.4.0 has
been releases i'd like know if this feature is already available.

Thanks
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Pkg 1.4.0 and packaging base system

2014-12-16 Thread Bryan Drewery 
On 12/16/2014 5:41 PM, Cassiano Peixoto wrote:
> Hi guys,
> 
> Some weeks ago i read an email sent by bapt about new features to pkg 1.4.0
> release. One of them was about packaging base system. As 1.4.0 has
> been releases i'd like know if this feature is already available.
> 

The short answer is "no".

The longer answer is that it is almost trivial to package the base
system. There are issues with upgrading though with handling config
files (1.4.0 addresses this). However, even with that, there is no work
available that you can test for a comprehensive build+install+upgrade
packaged base. There remains a lot to do this "right" and consider the
whole picture. There's the issue of splitting up base into components,
conflicting packages between base and ports, freebsd-update, Security
Advisories, etc. There's a lot more work to be done IMHO.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

pkgconf and /usr/local/lib/gcc48/libstdc++.so

2014-12-16 Thread Don Lewis 
I'm trying to get x11-fm/sushi and mail/evolution to build on FreeBSD 8.
I've applied the patch from
 to build
www/webkit-gtk3 with gcc and libstdc++ from ports.  When I try to build
either sushi or evolution, I get errors like this:

  GISCAN   Sushi-1.0.gir
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZSt25__throw_bad_function_callv@GLIBCXX_3.4.14'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11'
/usr/local/lib/libjavascriptcoregtk-3.0.so: undefined reference to 
`_ZNSt6chrono3_V212system_clock3nowEv@GLIBCXX_3.4.19'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZSt15__once_callable@GLIBCXX_3.4.11'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZNSt8__detail15_List_node_base7_M_hookEPS0_@GLIBCXX_3.4.15'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZSt11__once_call@GLIBCXX_3.4.11'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZNSt18condition_variableD1Ev@GLIBCXX_3.4.11'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZSt20__throw_system_errori@GLIBCXX_3.4.11'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZNSt18condition_variable10notify_oneEv@GLIBCXX_3.4.11'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZNSt18condition_variableC1Ev@GLIBCXX_3.4.11'
/usr/local/lib/libjavascriptcoregtk-3.0.so: undefined reference to 
`_ZNSt18condition_variable10notify_allEv@GLIBCXX_3.4.11'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`_ZNSt6chrono3_V212steady_clock3nowEv@GLIBCXX_3.4.19'
/usr/local/lib/libwebkitgtk-3.0.so: undefined reference to 
`__once_proxy@GLIBCXX_3.4.11'
Makefile:672: recipe for target 'sushi-start' failed

My suspicion is that this is caused by using binutils from base instead
of the newer version from ports.  I tried getting around this by
applying a big hammer and adding USES=compiler:c++11-lib to the Makefile
and got this error:

  GISCAN   Sushi-1.0.gir
/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.14 required b
y /usr/local/lib/libwebkitgtk-3.0.so.0 not found
Command '['/wrkdirs/usr/ports/x11-fm/sushi/work/sushi-3.12.0/src/tmp-introspectj
KttWB/Sushi-1.0', '--introspect-dump=/wrkdirs/usr/ports/x11-fm/sushi/work/sushi-
3.12.0/src/tmp-introspectjKttWB/functions.txt,/wrkdirs/usr/ports/x11-fm/sushi/wo
rk/sushi-3.12.0/src/tmp-introspectjKttWB/dump.xml']' returned non-zero exit stat
us 1
/usr/local/share/gobject-introspection-1.0/Makefile.introspection:153: recipe fo
r target 'Sushi-1.0.gir' failed
gmake[2]: *** [Sushi-1.0.gir] Error 1

The problem now appears to be that the older version of libstdc++ from
base is being used instead of the newer version from the gcc port.  That
his happening because -L/usr/local/lib/gcc48 is not present in the
linker flags.  The proper value of LDFLAGS is getting passed to
configure via CONFIGURE_ENV.  From config.log:

ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value=' -L/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc48 -L/us
r/local/lib/gcc48'

Unfortunately configure ends up ignoring it and using pkgconf to
generate the linker command line:

pkg_cv_SUSHI_LIBS='-lfreetype -lgirepository-1.0 -lgjs -lclutter-gtk-1.0 -lclutt
er-gst-2.0 -lclutter-1.0 -lcogl-path -lcogl-pango -lcogl -lgmodule-2.0 -lEGL -lX
randr -ljson-glib-1.0 -lX11 -lXext -lXdamage -lXfixes -lXcomposite -lXi -lgstbas
e-1.0 -lgstpbutils-1.0 -lgsttag-1.0 -lgstreamer-1.0 -lmusicbrainz5 -levview3 -le
vdocument3 -lgthread-2.0 -lgtksourceview-3.0 -lwebkitgtk-3.0 -lgtk-3 -lgdk-3 -lp
angocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -pthread -lgdk_pixbu
f-2.0 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -ljavascriptcoregtk-3.0 -L/usr/local/li
b -lglib-2.0 -lintl  '
SUSHI_LIBS='-lfreetype -lgirepository-1.0 -lgjs -lclutter-gtk-1.0 -lclutter-gst-
2.0 -lclutter-1.0 -lcogl-path -lcogl-pango -lcogl -lgmodule-2.0 -lEGL -lXrandr -
ljson-glib-1.0 -lX11 -lXext -lXdamage -lXfixes -lXcomposite -lXi -lgstbase-1.0 -
lgstpbutils-1.0 -lgsttag-1.0 -lgstreamer-1.0 -lmusicbrainz5 -levview3 -levdocume
nt3 -lgthread-2.0 -lgtksourceview-3.0 -lwebkitgtk-3.0 -lgtk-3 -lgdk-3 -lpangocai
ro-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -pthread -lgdk_pixbuf-2.0 -
lsoup-2.4 -lgio-2.0 -lgobject-2.0 -ljavascriptcoregtk-3.0 -L/usr/local/lib -lgli
b-2.0 -lintl  '

What is the proper way to fix this?  Should the .pc file for webkit-gtk3
record the extra library path because it was compiled with gcc from
ports?  Should configure concatenate the value of $LDFLAGS with the
output of pkgconf?

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

hs-git-annex vs. git-subversion

2014-12-16 Thread Russell L. Carter 

Hi porters,

It seems that devel/hs-git-annex and devel/git-subversion don't like
each other, to the extent that installing one requires removing the
other.  Is this something fundamental?  If not, what would be the
required change, locally?

I once looked inyto the haskell hive-brain and ended up a couple of
hours later retching, with tattered clothes, in a freezing ditch,
which I was lucky to be able to climb out of, mind only slightly
damaged.  So I am a bit reluctant to look further down that path.
hs-pandoc seems to be working though, so we let the monster roam the
house, still.

This is on stable/10, pkg builds maintained by poudriere nightly.

Thanks,
Russell
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"