what on earth and how do I fix:

[Aryeh Friedman]

I maintain a port (not officially a part of the ports collection yet) that
compiled just fine before "staging" support was added now I get:

chown -R www:www /usr/local/etc/petitecloud
> Compressing man pages
===> Correct pkg-plist sequence to create group(s) and user(s)
===>  Installing for petitecloud-0.1.9
===>   Registering installation for petitecloud-0.1.9
pkg-static:
lstat(/usr/ports/emulators/petitecloud/work/stage/usr/local/apache-tomcat-7.0/webapps/petitecloud-0.1.9-aryeh.war):
No such file or directory


How do I fix this?
___
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: NEED_ROOT

[Freddie Cash]

On Fri, Oct 4, 2013 at 2:45 PM, Paul Schmehl wrote:

> From my reading it appears that one of the goals of STAGE is to allow
>> users
>>
> to build and install ports under their UID.  Are the perms in /usr/ports
> changing?
>

​You've always been able to build ports as non-root, so long as you set
WRKDIRPREFIX and DISTDIR to something you can write to.

You've never been able to install ports as non-root.

What the STAGE support stuff does is allow you to build _packages_ as
non-root.

Previously, to build a package, you first had to install the port (as
root), then build the package (as non-root), then uninstall the port (as
root).

Now, you build the port (as non-root), install into the staging directory
(as non-root), and make the package based on that (as non-root).

​IOW, root is only needed to install the package onto the destination
system.​  It's not needed on the build system.


-- 
Freddie Cash
fjwc...@gmail.com
___
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: NEED_ROOT

[Julien Laffaye]

On 10/4/2013 11:45 PM, Paul Schmehl wrote:
From my reading it appears that one of the goals of STAGE is to allow 
users 
to build and install ports under their UID.  Are the perms in 
/usr/ports changing?


In testing the port that I'm working on, I find that I do not have 
rights to write to /usr/ports/distfiles and I do not have rights to 
write to ${WORKDIR}.  That pretty much precludes building the port 
unless your root. No surprise there since the files in /usr/ports are 
owned by root:wheel.


So are the perms going to change?  Is port building going to run 
setuid? Or is this a vaporware?




Well... set WRKDIRPREFIX and DISTDIR to point somewhere writable by your 
user.

___
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: NEED_ROOT

[Peter Jeremy]

On 2013-Oct-04 16:45:34 -0500, Paul Schmehl  wrote:
>From my reading it appears that one of the goals of STAGE is to allow users 
>to build and install ports under their UID.  Are the perms in /usr/ports 
>changing?

I hope not.  There's nothing wrong with the current permissions.

>In testing the port that I'm working on, I find that I do not have rights 
>to write to /usr/ports/distfiles and I do not have rights to write to 
>${WORKDIR}.  That pretty much precludes building the port unless your root. 
>No surprise there since the files in /usr/ports are owned by root:wheel.

I've built ports as non-root, with a read-mostly /usr/ports for many
years.  All you need to do is override the defaults:
WRKDIRPREFIX=/tmp
PACKAGES=/where/you/want/packages
DISTDIR=/where/you/want/distfiles

Alternatively, I "chmod 1777 /usr/ports/distfiles" to allow a common
ports tree to be shared amongst multiple systems.  And you can also
use symlinks.

-- 
Peter Jeremy


pgpBxCwC_XcAn.pgp
Description: PGP signature

NEED_ROOT

[Paul Schmehl]

From my reading it appears that one of the goals of STAGE is to allow users 
to build and install ports under their UID.  Are the perms in /usr/ports 
changing?


In testing the port that I'm working on, I find that I do not have rights 
to write to /usr/ports/distfiles and I do not have rights to write to 
${WORKDIR}.  That pretty much precludes building the port unless your root. 
No surprise there since the files in /usr/ports are owned by root:wheel.


So are the perms going to change?  Is port building going to run setuid? 
Or is this a vaporware?


--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

___
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"

INDEX now builds successfully on 8.x

[Ports Index build]

___
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"

porting question (rubygem related)

[Loïc BLOT]

Hello @ports,
i'm trying to port gitlab to FreeBSD ports (and also to train to build a
complex port).

At this time, i have done installation tasks but now i'm checking
dependencies. Gitlab uses bundler to install its dependencies but i want
to use FreeBSD ports too.
Then i have install all ports i can install but there is some missing
ports.

What are the conditions for rubygems to be added to FreeBSD port tree ?
Must I add all missing dependencies to FreeBSD ports tree or can i use a
patched gemfile for bundler to add only the missing deps ?

Have you got suggestions about a so big port ?

Thanks in advance.
-- 
-- 
Best regards,
Loïc BLOT, 
UNIX systems, security and network engineer
http://www.unix-experience.fr





signature.asc
Description: This is a digitally signed message part

Re: Port build failure -- security/hydra

[Ronald F. Guilmette]

Oh geeezzz!  Things are even more screwed up with the hydra port
that I thought!

I mentioned in my prior e-mail that the size of the hydra-7.5.tar.gz
file being reported by essentially all of the mirrors that are coded
into the current hydra port is in fact 681552... *not* 681784 bytes,
which is apparently what the port is expecting and demanding.

However it appears that there is *one* and *only one* source for
the hydra-7.5.tar.gz distribution file where the size of the file
*is* in fact 681784 bytes, and that is:

   https://www.thc.org/releases/hydra-7.5.tar.gz

but this is the site that apparently has its SSL certificates screwed up!

G!  How worrisome is it to be fetching a piece of "security"
software from a site that can't even manage to get its own SSL certs
set up or maintained properly??

How worrisome is it to be doing that when *every* other copy of the
relevant source tarball *everywhere* else on the net has a different
size??

OK, so being curious, I got *both* one of the 681552 sized copies
of this file and also one of the 681784 sized copies, and I unpacked
them both and ran "diff -rc2".  The results are attached below.
Clearly, the bizzare and unexpected size differences are *not* due
to any any sneeky corruption of the source tarball.  However it is
equally apparent that _somebody_ has been fiddling with the contents
of the source tarball *without* bothering to change the version number
on that.

(I don't generally believe in castration as a punishment for crimes
against humanity, but I make an exception in such cases, because there
is no excuse for this kind of shoddy workmanship.  Even if the only
change is a single comma, different versions need different numbers.)

So, um, will the real hydra-7.5.tar.gz file please stand up?



diff -rc2 tmp0/hydra-7.5/LICENSE tmp1/hydra-7.5/LICENSE
*** tmp0/hydra-7.5/LICENSE  2013-08-02 04:35:56.0 -0700
--- tmp1/hydra-7.5/LICENSE  2013-08-06 07:42:44.0 -0700
***
*** 1,2 
--- 1,7 
+ [see the end of the file for the special exception for linking with OpenSSL
+  - debian people need this]
+ 
+ 
+ 
  GNU AFFERO GENERAL PUBLIC LICENSE
 Version 3, 19 November 2007
***
*** 660,661 
--- 665,683 
  For more information on this, and how to apply and follow the GNU AGPL, see
  .
+ 
+ 
+ Special Exception
+ 
+  * In addition, as a special exception, the copyright holders give
+  * permission to link the code of portions of this program with the
+  * OpenSSL library under certain conditions as described in each
+  * individual source file, and distribute linked combinations
+  * including the two.
+  * You must obey the GNU Affero General Public License in all respects
+  * for all of the code used other than OpenSSL.  If you modify
+  * file(s) with this exception, you may extend this exception to your
+  * version of the file(s), but you are not obligated to do so.  If you
+  * do not wish to do so, delete this exception statement from your
+  * version.  If you delete this exception statement from all source
+  * files in the program, then also delete it here.
+ 
diff -rc2 tmp0/hydra-7.5/hydra.1 tmp1/hydra-7.5/hydra.1
*** tmp0/hydra-7.5/hydra.1  2013-08-02 04:35:56.0 -0700
--- tmp1/hydra-7.5/hydra.1  2013-08-06 00:27:33.0 -0700
***
*** 94,98 
  defines the max wait time in seconds for responses (default: 32)
  .TP
! .B \-w TIME
  defines a wait time between each connection a task performs. This usually
  only makes sense if a low task number is used, .e.g \-t 1
--- 94,98 
  defines the max wait time in seconds for responses (default: 32)
  .TP
! .B \-W TIME
  defines a wait time between each connection a task performs. This usually
  only makes sense if a low task number is used, .e.g \-t 1
Files tmp0/hydra-7.5.tar.gz and tmp1/hydra-7.5.tar.gz differ
___
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"

[QAT] r329319: 1x leftovers, 3x success

[Ports-QAT]

Fix the build when WP option is enabled. The old libwpg and libwpd where
removed [1]. Update COMMENT, use new LIB_DEPEND syntax, Stageify
USE_GNOME=desktopfileutils -> USES=desktop-file-utils

Pointyhat to:   bapt@ [1]
Obtained from:  gentoo [1]
-

  Build ID:  20131004145200-3986
  Job owner: k...@freebsd.org
  Buildtime: 5 hours
  Enddate:   Fri, 04 Oct 2013 20:03:03 GMT

  Revision:  r329319
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329319

-

Port:editors/abiword 2.8.6

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20131004145200-3986-202108/abiword-2.8.6.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20131004145200-3986-202109/abiword-2.8.6.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20131004145200-3986-202110/abiword-2.8.6.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20131004145200-3986-202111/abiword-2.8.6.log


--
Buildarchive URL: 
redports 
___
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: Port build failure -- security/hydra

[Ronald F. Guilmette]

In message <524f179d.8030...@yandex.ru>, 
Ruslan Makhmatkhanov  wrote:

>Ronald F. Guilmette wrote on 04.10.2013 23:11:
>> At the end of my effort to do "portupgrade -a", I got this:
>>
>>  ! security/hydra (hydra-7.4.2)  (fetch error)
>>
>> Apparently, the source tarball for the current hydra port seems to be
>> nowhere to be found.  How come?  Shouldn't there _always_ be at least one
>> copy of the source tarball, somewhere on one or another of the FreeBSD
>> distribution servers, for each and every port in the ports tree?
>
>I can't reproduce this problem, it's fetching fine to me:
>
>root@smeshariki4:/usr/ports/security/hydra # make distclean
>===>  Cleaning for hydra-7.5
>===>  Deleting distfiles for hydra-7.5
>root@smeshariki4:/usr/ports/security/hydra # make fetch
>===>  License AGPLv3 accepted by the user
>===>  Found saved configuration for hydra-7.5
>===>   hydra-7.5 depends on file: /usr/local/sbin/pkg - found
>=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>=> Attempting to fetch http://freeworld.thc.org/releases/hydra-7.5.tar.gz
>hydra-7.5.tar.gz  100% of  665 kB  348 kBps 
>00m02s
>===> Fetching all distfiles required by hydra-7.5 for building
>
>But I updated the download url to avoid redirect in r329365. Please 
>update your ports tree and try again.
>
>PS. Packetstorm seems changed the way they handle downloads. Will check 
>later how to deal with it.


OK, first question:  What the devil is "r329365" ?

Anyway, I did what you suggested.  I just now re-did this step:

   portsnap fetch update

and then I tried again:

  portupgrade security/hydra

but I am _still_ getting the exact same error.  From where I am sitting,
the hydra-7.5.tar.gz file is *not* available from freeworld.thc.org, and
indeed I am wondering how you managed to get it from there.  From where I
am sitting, even trying to fetch it from there using wget indicates that
there is a "Moved Permanently" HTTP error encountered when trying to
fetch the file from this URL, which is currently coded into the port:

   http://freeworld.thc.org/releases/hydra-7.5.tar.gz

How are you not seeing this "Moved Permanently" HTTP error??

Anyway, if I try to fetch the file from the above URL using wget, even
after being redirected (automagically) to the new URL, there is still a
very evident problem... the real source site (www.thc.org) has its
security certs screwed up:

==
% wget 'http://freeworld.thc.org/releases/hydra-7.5.tar.gz'
--2013-10-04 12:38:31--  http://freeworld.thc.org/releases/hydra-7.5.tar.gz
Resolving freeworld.thc.org (freeworld.thc.org)... 199.58.210.16
Connecting to freeworld.thc.org (freeworld.thc.org)|199.58.210.16|:80... 
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.thc.org/releases/hydra-7.5.tar.gz [following]
--2013-10-04 12:38:31--  https://www.thc.org/releases/hydra-7.5.tar.gz
Resolving www.thc.org (www.thc.org)... 199.58.210.16
Connecting to www.thc.org (www.thc.org)|199.58.210.16|:443... connected.
ERROR: cannot verify www.thc.org's certificate, issued by ‘/C=US/O=GeoTrust, 
Inc./CN=RapidSSL CA’:
  Unable to locally verify the issuer's authority.
To connect to www.thc.org insecurely, use `--no-check-certificate'.
==

OK, yes, I can bypass this, if necessary, using --no-check-certificate,
but I am telling you that the port, the way it sits now is *BROKEN*.

Furthermore, for all of the other possible sources where the file could
be gotten from, apparently the port believes that the size of the file
should be 681784, but that is *wrong* and the size of the file on _all_
the mirrors is actually 681552, so all attempts by the port to grab the
sources from any & all of the other mirrors is failing also.

Could you be kind and fix both problems, please?


==
--->  Upgrading 'hydra-7.4.2' to 'hydra-7.5' (security/hydra)
--->  Building '/usr/ports/security/hydra'
===>  Cleaning for hydra-7.5
===>  License AGPLv3 accepted by the user
===>  Found saved configuration for hydra-7.5
=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://freeworld.thc.org/releases/hydra-7.5.tar.gz
fetch: http://freeworld.thc.org/releases/hydra-7.5.tar.gz: Moved Permanently
=> Attempting to fetch 
http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz
fetch: http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.codar.com.br/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.codar.com.br/groups/thc/hydra-7.5.tar.gz: No address 
record
=> Attempting to fetch 
http://packetstorm.igor.onlinedirect.bg/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.igor.onlinedirect.bg/grou

Re: Port build failure -- security/hydra

[Ruslan Makhmatkhanov]

Ronald F. Guilmette wrote on 04.10.2013 23:11:

At the end of my effort to do "portupgrade -a", I got this:

 ! security/hydra (hydra-7.4.2)  (fetch error)

Apparently, the source tarball for the current hydra port seems to be
nowhere to be found.  How come?  Shouldn't there _always_ be at least one
copy of the source tarball, somewhere on one or another of the FreeBSD
distribution servers, for each and every port in the ports tree?


I can't reproduce this problem, it's fetching fine to me:

root@smeshariki4:/usr/ports/security/hydra # make distclean
===>  Cleaning for hydra-7.5
===>  Deleting distfiles for hydra-7.5
root@smeshariki4:/usr/ports/security/hydra # make fetch
===>  License AGPLv3 accepted by the user
===>  Found saved configuration for hydra-7.5
===>   hydra-7.5 depends on file: /usr/local/sbin/pkg - found
=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://freeworld.thc.org/releases/hydra-7.5.tar.gz
hydra-7.5.tar.gz  100% of  665 kB  348 kBps 
00m02s

===> Fetching all distfiles required by hydra-7.5 for building

But I updated the download url to avoid redirect in r329365. Please 
update your ports tree and try again.


PS. Packetstorm seems changed the way they handle downloads. Will check 
later how to deal with it.


--
Regards,
Ruslan

T.O.S. Of Reality
___
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"

[QAT] r329359: 1x leftovers, 3x success

[Ports-QAT]

- Add stage support
- Fix build with Perl 5.16

Makefile.PL is using auto_set_homepage which included inside
Module::Install::Homepage and required URI::Escape.

With hat:   perl@
-

  Build ID:  20131004190400-7813
  Job owner: a...@freebsd.org
  Buildtime: 26 minutes
  Enddate:   Fri, 04 Oct 2013 19:29:44 GMT

  Revision:  r329359
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329359

-

Port:devel/p5-Dist-Joseki 0.20

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20131004190400-7813-202276/p5-Dist-Joseki-0.20.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20131004190400-7813-202277/p5-Dist-Joseki-0.20.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20131004190400-7813-202278/p5-Dist-Joseki-0.20.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20131004190400-7813-202279/p5-Dist-Joseki-0.20.log


--
Buildarchive URL: 
redports 
___
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"

[QAT] r329361: 1x leftovers, 3x success

[Ports-QAT]

- Support staging
- Use new PORT_OPTIONS syntax for DOCS and EXAMPLES
- Use a single space for WWW in pkg-descr
- Break lines at 80 chars
-

  Build ID:  20131004191400-53717
  Job owner: l...@freebsd.org
  Buildtime: 8 minutes
  Enddate:   Fri, 04 Oct 2013 19:21:31 GMT

  Revision:  r329361
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329361

-

Port:devel/lasi 1.1.1_1

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~l...@freebsd.org/20131004191400-53717-202284/lasi-1.1.1_1.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~l...@freebsd.org/20131004191400-53717-202285/lasi-1.1.1_1.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~l...@freebsd.org/20131004191400-53717-202286/lasi-1.1.1_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~l...@freebsd.org/20131004191400-53717-202287/lasi-1.1.1_1.log


--
Buildarchive URL: 
redports 
___
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"

Port build failure -- graphics/clutter-gtk

[Ronald F. Guilmette]

At the end of my recent attempt to do "portupgrade -a" I got this error:

! graphics/clutter-gtk (clutter-gtk-0.10.8_2)   (unknown build error)

Aapparently, clutter-gtk configures OK, but then compiling it generates
a whole boat load of compile time errors.  I tried the Makefile fix
suggested here:

http://www.freebsd.org/cgi/query-pr.cgi?pr=177813

but that did not help in the slightest.  According to a suggestion made
within the build error messages, I also tried setting MAKE_JOBS_UNSAFE
to "yes" in the environment (and also on the make command line) and those
actions didn't materially help the situation either.  Logs of the build
failures, both before and after this step, are attached.

Help resolving this problem would be appreciated.


P.S.  I just checked, and there is no mention whatsoever of clutter-gtk
AT ALL in the UPDATING file.  But clearly, *something* is broken.


logs:

root@segfault:/usr/ports/graphics/clutter-gtk # make
===> Fetching all distfiles required by clutter-gtk-0.10.8_3 for building
===>  Extracting for clutter-gtk-0.10.8_3
=> SHA256 Checksum OK for clutter-gtk-0.10.8.tar.bz2.
===>  Patching for clutter-gtk-0.10.8_3
===>   clutter-gtk-0.10.8_3 depends on package: libtool>=2.4 - found
===>  Applying FreeBSD patches for clutter-gtk-0.10.8_3
===>   clutter-gtk-0.10.8_3 depends on executable: gmake - found
===>   clutter-gtk-0.10.8_3 depends on executable: pkgconf - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/dri2proto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: /usr/local/libdata/pkgconfig/xp.pc 
- found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/x11.pc - found
===>   clutter-gtk-0.10.8_3 depends on package: libtool>=2.4 - found
===>   clutter-gtk-0.10.8_3 depends on file: /usr/local/bin/intltool-extract - 
found
===>   clutter-gtk-0.10.8_3 depends on shared library: libGL.so - found
===>   clutter-gtk-0.10.8_3 depends on shared library: clutter-glx-1.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: intl - found
===>   clutter-gtk-0.10.8_3 depends on shared library: atk-1.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: glib-2.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: pcre - found
===>   clutter-gtk-0.10.8_3 depends on shared library: gtk-x11-2.0.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: pango-1.0 - found
===>  Configuring for clutter-gtk-0.10.8_3
configure: WARNING: unrecognized options: --with-gconf-source
configure: loading site script /usr/ports/Templates/config.site
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for gawk... (cached) /usr/bin/awk
checking whether gmake sets $(MAKE)... yes
checking for style of include used by gmake... GNU
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking dependency style of cc... gcc3
checking whether cc understands -c and -o together... yes
checking how to run the C preprocessor... cpp
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for ANSI C header files... (cached) yes
checking build system type... amd64-portbld-freebsd9.1
checking host system type... amd64-portbld-freebsd9.1
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for fgrep... (cached) /usr/bin/fgrep
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... (cached) 262144
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... no
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from cc object... ok
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for s

Port build failure -- security/hydra

[Ronald F. Guilmette]

At the end of my effort to do "portupgrade -a", I got this:

! security/hydra (hydra-7.4.2)  (fetch error)

Apparently, the source tarball for the current hydra port seems to be
nowhere to be found.  How come?  Shouldn't there _always_ be at least one
copy of the source tarball, somewhere on one or another of the FreeBSD
distribution servers, for each and every port in the ports tree?


===
# cd /usr/ports/security/hydra
# make
===>  License AGPLv3 accepted by the user
===>  Found saved configuration for hydra-7.5
=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://freeworld.thc.org/releases/hydra-7.5.tar.gz
fetch: http://freeworld.thc.org/releases/hydra-7.5.tar.gz: Moved Permanently
=> Attempting to fetch 
http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz
fetch: http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.codar.com.br/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.codar.com.br/groups/thc/hydra-7.5.tar.gz: No address 
record
=> Attempting to fetch 
http://packetstorm.igor.onlinedirect.bg/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.igor.onlinedirect.bg/groups/thc/hydra-7.5.tar.gz: 
size mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.interhost.co.il/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.interhost.co.il/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch http://packetstorm.foofus.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.foofus.com/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.tacticalflex.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.tacticalflex.com/groups/thc/hydra-7.5.tar.gz: Not 
Found
=> Attempting to fetch 
http://packetstorm.unixteacher.org/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.unixteacher.org/groups/thc/hydra-7.5.tar.gz: No 
address record
=> Attempting to fetch 
http://packetstorm.wowhacker.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.wowhacker.com/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/hydra-7.5.tar.gz
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/hydra-7.5.tar.gz: File 
unavailable (e.g., file not found, no access)
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/ports/distfiles/ and try again.
*** [do-fetch] Error code 1

Stop in /usr/ports/security/hydra.
*** [build] Error code 1

Stop in /usr/ports/security/hydra.

___
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: multimedia/libbluray -- IGNORE... Why?

[Ronald F. Guilmette]

In message <20131004113101.GB42900@oldfaithful.bebik.local>, you wrote:

>Hi,
>
>I Made a check in the SVN and libbluray was never
>marked IGNORE, at least BROKEN for some java reasons.

Well, I'm just showing you what "portupgrade -a" reported...

- multimedia/libbluray (marked as IGNORE)

>Are you sure isn't a dependencie problem ?

No, but I have no reason whatsoever to believe that is.

>Which version are you trying to install ?

Here is the info from the relevant Makefile:

PORTNAME=   libbluray
PORTVERSION=0.3.0
PORTEPOCH=  1

___
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"

[QAT] r329350: 3x leftovers, 5x success

[Ports-QAT]

enable stage.
-

  Build ID:  20131004175601-6851
  Job owner: u...@freebsd.org
  Buildtime: 63 minutes
  Enddate:   Fri, 04 Oct 2013 18:58:54 GMT

  Revision:  r329350
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329350

-

Port:japanese/gedy 0.9.0

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004175601-6851-202240/ja-gedy-0.9.0.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004175601-6851-202241/ja-gedy-0.9.0.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004175601-6851-202242/ja-gedy-0.9.0.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004175601-6851-202243/ja-gedy-0.9.0.log

-

Port:japanese/gsuica 0.9.1

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004175601-6851-202244/ja-gsuica-0.9.1.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004175601-6851-202245/ja-gsuica-0.9.1.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004175601-6851-202246/ja-gsuica-0.9.1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004175601-6851-202247/ja-gsuica-0.9.1.log


--
Buildarchive URL: 
redports 
___
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"

[QAT] r329356: 1x leftovers, 3x success

[Ports-QAT]

enable stage.
-

  Build ID:  20131004183400-5640
  Job owner: u...@freebsd.org
  Buildtime: 8 minutes
  Enddate:   Fri, 04 Oct 2013 18:41:48 GMT

  Revision:  r329356
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329356

-

Port:net/p5-Net-INET6Glue 0.6

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004183400-5640-202264/p5-Net-INET6Glue-0.6.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004183400-5640-202265/p5-Net-INET6Glue-0.6.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004183400-5640-202266/p5-Net-INET6Glue-0.6.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004183400-5640-202267/p5-Net-INET6Glue-0.6.log


--
Buildarchive URL: 
redports 
___
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"

[QAT] r329341: 1x leftovers, 3x success

[Ports-QAT]

enable stage.
-

  Build ID:  2013100417-42305
  Job owner: u...@freebsd.org
  Buildtime: 73 minutes
  Enddate:   Fri, 04 Oct 2013 18:12:41 GMT

  Revision:  r329341
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329341

-

Port:textproc/ibus-el 0.3.2_1

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/2013100417-42305-202180/ibus-el-emacs24-0.3.2_1.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/2013100417-42305-202181/ibus-el-emacs24-0.3.2_1.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/2013100417-42305-202182/ibus-el-emacs24-0.3.2_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~u...@freebsd.org/2013100417-42305-202183/ibus-el-emacs24-0.3.2_1.log


--
Buildarchive URL: 
redports 
___
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"

INDEX build failed for 8.x

[Ports Index build]

INDEX build failed with errors:
Generating INDEX-8 - please wait.."Makefile", line 202: warning: junk after 
.else ignored 'if exists(${LOCALBASE}/include/execinfo.h)'
 Done.
make_index: mupen64plus-2.0: no entry for 
/usr/ports/emulators/mupen64plus-video-glide64mk2

Committers on the hook:
 acm az bapt naddy rene se sunpoet ume 

Most recent SVN update was:
Updating '.':
Umath/calcoo/Makefile
Umath/galculator/pkg-plist
Umath/galculator/Makefile
UU   devel/p5-Devel-Profiler/pkg-plist
Udevel/p5-Devel-Profiler/Makefile
Udevel/p5-Bread-Board-Declare/Makefile
Udevel/p5-Bread-Board-Declare/distinfo
Udevel/libpafe-ruby/Makefile
Udevel/p5-Bread-Board/pkg-plist
Udevel/p5-Bread-Board/Makefile
UU   devel/p5-Bread-Board/distinfo
Uaudio/gkrellmms2/Makefile
Uaudio/fluidsynth/pkg-plist
Uaudio/fluidsynth/Makefile
Uaudio/flac123/Makefile
Uaudio/flac123/pkg-descr
Uaudio/gkrellmvolume2/Makefile
UMk/bsd.stage.mk
UMk/bsd.linux-rpm.mk
Umultimedia/dvbcut/Makefile
Dmultimedia/dvbcut/files/patch-src_Makefile.in
Umultimedia/dvbcut/files/use-qt4.diff.bz2
Umultimedia/dvbcut/files/patch-src_playaudio.cpp
Amultimedia/dvbcut/files/patch-avframe.cpp
Amultimedia/dvbcut/files/patch-main.cpp
Uaccessibility/linux-f10-atk/Makefile
Asysutils/moreutils/pkg-plist
Usysutils/moreutils/Makefile
Usysutils/moreutils/files/patch-Makefile
UU   textproc/p5-Text-Aligner/pkg-plist
UU   textproc/p5-Text-Aligner/Makefile
UU   textproc/p5-Text-Aligner/distinfo
Utextproc/ibus-el/Makefile
Unet/p5-Socket6/Makefile
UU   net/p5-Net-MAC-Vendor/pkg-plist
Unet/p5-Net-MAC-Vendor/Makefile
UU   net/p5-Net-MAC-Vendor/distinfo
Unet/dtcp/Makefile
Anet/dtcp/files/patch-Makefile
Unet/openntpd/Makefile
Unet/openntpd/pkg-plist
Unet/dtcpclient/pkg-plist
Unet/dtcpclient/Makefile
Anet/dtcpclient/files/patch-Makefile
Ujapanese/gsuica/Makefile
Ujapanese/gedy/Makefile
Ugraphics/gdal/Makefile
Aemulators/mupen64plus-video-glide64mk2
Aemulators/mupen64plus-video-glide64mk2/Makefile
Aemulators/mupen64plus-video-glide64mk2/files
A
emulators/mupen64plus-video-glide64mk2/files/patch-source-mupen64plus-video-glide64mk2-src-Glide64_Util.h
A
emulators/mupen64plus-video-glide64mk2/files/patch-source-mupen64plus-video-glide64mk2-projects-unix_Makefile
A
emulators/mupen64plus-video-glide64mk2/files/patch-source-mupen64plus-video-glide64mk2-src-GlideHQ_TxDbg.cpp
Uemulators/mupen64plus/Makefile
Aemulators/mupen64plus-video-glide64/files
A
emulators/mupen64plus-video-glide64/files/patch-mupen64plus-video-glide64-src_rdp.cpp
A
emulators/mupen64plus-video-glide64/files/patch-mupen64plus-video-glide64-src_Util.h
A
emulators/mupen64plus-video-glide64/files/patch-mupen64plus-video-glide64-src_Main.cpp
Uemulators/mupen64plus-video-glide64/Makefile
Uemulators/mupen64plus-plugins/Makefile
Uemulators/Makefile
Uemulators/mupen64plus-video-arachnoid/Makefile
Uemulators/linux_base-f10/pkg-plist
Uemulators/linux_base-f10/Makefile
Uemulators/mupen64plus-rsp-z64/Makefile
Uemulators/mupen64plus-core/Makefile
Uemulators/mupen64plus-core/distinfo
U
emulators/mupen64plus-core/files/patch-source_mupen64plus-core_projects_unix_Makefile
Uemulators/mupen64plus-core/Makefile.common
Demulators/mupen64plus-video-rice/files
Uemulators/mupen64plus-video-z64/Makefile
Updated to revision 329350.
___
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"

[QAT] r329307: 1x leftovers, 3x success

[Ports-QAT]

This port is already stage ready
Modernize LIB_DEPENDS
-

  Build ID:  20131004134800-15076
  Job owner: b...@freebsd.org
  Buildtime: 4 hours
  Enddate:   Fri, 04 Oct 2013 18:08:26 GMT

  Revision:  r329307
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329307

-

Port:graphics/libcdr 0.0.14

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004134800-15076-202064/libcdr-0.0.14.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004134800-15076-202065/libcdr-0.0.14.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004134800-15076-202066/libcdr-0.0.14.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004134800-15076-202067/libcdr-0.0.14.log


--
Buildarchive URL: 
redports 
___
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"

[QAT] r329305: 4x depend (??? in graphics/opencv-core), 3x leftovers, 2x plist, 15x success

[Ports-QAT]

- Update finance/libofx to 0.9.9
- Support staging
- Remove USE_GCC= any; port seems to build fine with clang
- Move LICENSE to proper location
- Modernize LIB_DEPENDS
- USE_GMAKE -> USES= gmake
- Update pkg-descr to reflect current capabilities
- Bump PORTREVISION on dependent ports due to so version bump
-

  Build ID:  20131004132800-26943
  Job owner: jh...@freebsd.org
  Buildtime: 4 hours
  Enddate:   Fri, 04 Oct 2013 17:49:13 GMT

  Revision:  r329305
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329305

-

Port:finance/gnucash 2.4.13_1

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202036/gnucash-2.4.13_1.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202037/gnucash-2.4.13_1.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202038/gnucash-2.4.13_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202039/gnucash-2.4.13_1.log

-

Port:finance/grisbi 0.8.9_2

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202040/grisbi-0.8.9_2.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202041/grisbi-0.8.9_2.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202042/grisbi-0.8.9_2.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202043/grisbi-0.8.9_2.log

-

Port:finance/homebank 4.5.4_1

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202044/homebank-4.5.4_1.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202045/homebank-4.5.4_1.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202046/homebank-4.5.4_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202047/homebank-4.5.4_1.log

-

Port:finance/kmymoney-kde4 4.6.3_3

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   PLIST
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202048/kmymoney-4.6.3_3.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   PLIST
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202049/kmymoney-4.6.3_3.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   DEPEND (??? IN GRAPHICS/OPENCV-CORE)
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202050/opencv-core-2.3.1_7.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DEPEND (??? IN GRAPHICS/OPENCV-CORE)
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202051/opencv-core-2.3.1_7.log

-

Port:finance/libofx 0.9.9

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202052/libofx-0.9.9.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202053/libofx-0.9.9.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202054/libofx-0.9.9.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202055/libofx-0.9.9.log

-

Port:finance/skrooge 1.7.1_1

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~jh...@freebsd.org/20131004132800-26943-202056/skrooge-1.7.1_1

Re: Suddenly STAGE appeared

[olli hauer]

On 2013-10-04 18:03, Paul Schmehl wrote:
> --On October 4, 2013 4:35:57 PM +0200 Michael Gmelin  wrote:
> 
>> On Fri, 04 Oct 2013 09:22:25 -0500
>> Paul Schmehl  wrote:
>>
>>> Or did I miss the announcement?
>>>
>>> Is there a doc that explains STAGE and how to convert a port to the
>>> new system?  Why STAGE was created?  What it's purpose is?
>>>
>>> This is all very new to me, and I have 23 ports to worry about.
>>>
>>
>>
>> See
>> http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-October/00
>> 0067.html
>>
>> and the discussion here
>> http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html
> 
> Now it make sense.  I have a port that is failing to build on 10.0 because of 
> CLANG.  I don't have a 10.0 install, and it builds fine with GCC.  So I 
> updated the port to use USE_GCC= yes, and I was asked to convert the port to 
> use STAGE.  Left me scratching my head, because this was all before the 
> announcement.
> 
> And I'm having problems building the port now - and wondering if I should 
> just abandon my ports because the new system is confusing to me.  All this 
> transitional stuff is a lot to grasp when you've been building ports 
> successfully for a while and suddenly nothing works.
> 
> For example, make makeplist doesn't actually make a pkg-plist file on my 
> system.

The command `make makeplist' creates no absolute pkg-plist, but can be used to 
get a quick summary for pkg-plist
redirect the output to a file and compare it with your pkg-plist


> # make makeplist
> bin/sancp
> etc/rc.d/sancp
> etc/sancp.conf.dist
> 
> But no pkg-plist file is created.
> 
> WTH???
> 
> DOCS no longer build properly, and I have no clue why?
> 
> # make install
> ===>  Building package for sancp-1.6.1_5
> Creating package /usr/ports/security/sancp-update/sancp/work/sancp-1.6.1_5.tbz
> Registering depends:.
> Creating bzip'd tar ball in 
> '/usr/ports/security/sancp-update/sancp/work/sancp-1.6.1_5.tbz'
> tar: share/doc/sancp/CHANGES: Cannot stat: No such file or directory
> tar: share/doc/sancp/INSTALL: Cannot stat: No such file or directory
> tar: share/doc/sancp/ISSUES: Cannot stat: No such file or directory
> tar: share/doc/sancp/README: Cannot stat: No such file or directory
> tar: share/doc/sancp/SETUP: Cannot stat: No such file or directory
> tar: share/doc/sancp/fields.LIST: Cannot stat: No such file or directory
> tar: Error exit delayed from previous errors.
> pkg_create: make_dist: tar command failed with code 256
> *** [do-package] Error code 1
> 
> Stop in /usr/ports/security/sancp-update/sancp.
> 
> The Makefile has this:
> PORTDOCS=CHANGES INSTALL ISSUES \
> README SETUP fields.LIST
> 
> The docs are actually in ${WRKSRC}/doc, so I tried adding doc/ and 
> ${WRKSRC}/doc, but neither worked.  I tried adding %%PORTDOCS%%/docname to 
> pkg-plist, but that failed as well.  So now I'm at a complete loss to know 
> how to get the DOCS to work.

Not requred, your DOCS are already listed in PORTDOCS and PORTDOCS is used in 
Makefile to install the DOCS.
Install the docs this way '${INSTALL_DATA} ${PORTDOCS:S|^|${WRKSRC}/docs/|} 
${STAGEDIR}${DOCSDIR}'

> If you're going to make changes to the ports system and expect us 
> non-programmers to successfully grasp how all the changes get implemented, it 
> would be very helpful to have a HOWTO page the explains the changes required 
> in understandable detail.  The current page - 
>  - is rather cryptic and open to 
> interpretation.


> How do I list PORTDOCS so the build nows where to find them?  Previously we 
> used .if !${NOPORTDOCS} and told INSTALL to descend into the doc directory to 
> fetch the docs.  Then we changed to .if ${OPTIONS:MDOCS} and did the same.  
> Now I"m told I don't need that section at all, but obviously, without out, 
> the build can't figure out where the docs are so it fails.

No longer required, for a simple check add NOPORTDOCS=yes to your makefile, 
fire a make package and look with 'tar tf $package'.

> All of this should be anticipated and documented BEFORE these changes are 
> rolled out and we're required to implement them or you can expect lots of 
> frustration and people dropping ports.
> 
> I get that you're trying to do things in a better, more robust way, but 
> communication is key, and that communication has to be detailed and 
> understandable so us dummies can implement it.
> 


If created and tested a patch for you.
http://people.freebsd.org/~ohauer/diffs/stage/stage_sancp.diff

give the pach a go and add your clang fixes

-- 
olli
___
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"

[QAT] r329343: 1x leftovers, 3x success

[Ports-QAT]

- Add stage support
- Mark as IGNORE with perl > 5.16

devel/p5-Devel-Profiler need dprofpp utility which part of Devel::DProf
which has been removed from the Perl core since Perl 5.16 and Devel::DProf also
is deprecated in favor of Devel::NYTProf

So it's normal for this port to suicide after perl 5.16 as default Perl version
in tree.
-

  Build ID:  20131004171400-55479
  Job owner: a...@freebsd.org
  Buildtime: 9 minutes
  Enddate:   Fri, 04 Oct 2013 17:23:04 GMT

  Revision:  r329343
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329343

-

Port:devel/p5-Devel-Profiler 0.04

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20131004171400-55479-202188/p5-Devel-Profiler-0.04.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20131004171400-55479-202189/p5-Devel-Profiler-0.04.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20131004171400-55479-202190/p5-Devel-Profiler-0.04.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20131004171400-55479-202191/p5-Devel-Profiler-0.04.log


--
Buildarchive URL: 
redports 
___
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: [QAT] r329339: 4x leftovers

[Hajimu UMEMOTO]

Hi,

> On Fri, 04 Oct 2013 17:02:33 -
> "Ports-QAT"  said:

qat> - enable stage.
qat> - use opt_LIB_DEPENDS.
qat> -

qat>   Build ID:  20131004164800-923
qat>   Job owner: u...@freebsd.org
qat>   Buildtime: 14 minutes
qat>   Enddate:   Fri, 04 Oct 2013 17:02:29 GMT

qat>   Revision:  r329339
qat>   Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329339

qat> -

qat> Port:audio/gkrellmms2 2.1.22_9

qat>   Buildgroup: 9.1-QAT/amd64
qat>   Buildstatus:   LEFTOVERS
qat>   Log: 
https://qat.redports.org//~u...@freebsd.org/20131004164800-923-202172/gkrellmms-2.1.22_9.log

> === Checking filesystem state after all packages deleted
> 
> list of extra files and directories in / (not present on clean system but 
> present after everything was deinstalled)
>  170348 drwxr-xr-x4 root wheel  80 
> Oct  4 16:48 usr/local/lib/perl5
>  170350 drwxr-xr-x2 root wheel   0 
> Oct  4 16:49 usr/local/lib/perl5/5.14
>  200998 drwxr-xr-x3 root wheel  40 
> Oct  4 16:48 usr/local/lib/perl5/site_perl
>  201008 drwxr-xr-x3 root wheel  40 
> Oct  4 16:49 usr/local/lib/perl5/site_perl/5.14
>  201018 drwxr-xr-x4 root wheel  80 
> Oct  4 16:49 usr/local/lib/perl5/site_perl/5.14/mach
>  203370 drwxr-xr-x2 root wheel   0 
> Oct  4 16:49 usr/local/lib/perl5/site_perl/5.14/mach/machine
>  204100 drwxr-xr-x2 root wheel   0 
> Oct  4 16:49 usr/local/lib/perl5/site_perl/5.14/mach/sys
> 

audio/gkrellmms2 itself doesn't touch perl at all.  So, I'm not sure
why this leftovers is happen.

Sincerely,

--
Hajimu UMEMOTO
u...@mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
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"

[QAT] r329340: 1x leftovers, 3x success

[Ports-QAT]

Stagify
Use options helpers
-

  Build ID:  20131004165800-51220
  Job owner: b...@freebsd.org
  Buildtime: 10 minutes
  Enddate:   Fri, 04 Oct 2013 17:07:40 GMT

  Revision:  r329340
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329340

-

Port:audio/fluidsynth 1.1.6

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004165800-51220-202176/fluidsynth-1.1.6.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004165800-51220-202177/fluidsynth-1.1.6.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004165800-51220-202178/fluidsynth-1.1.6.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004165800-51220-202179/fluidsynth-1.1.6.log


--
Buildarchive URL: 
redports 
___
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"

[QAT] r329339: 4x leftovers

[Ports-QAT]

- enable stage.
- use opt_LIB_DEPENDS.
-

  Build ID:  20131004164800-923
  Job owner: u...@freebsd.org
  Buildtime: 14 minutes
  Enddate:   Fri, 04 Oct 2013 17:02:29 GMT

  Revision:  r329339
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329339

-

Port:audio/gkrellmms2 2.1.22_9

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004164800-923-202172/gkrellmms-2.1.22_9.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004164800-923-202173/gkrellmms-2.1.22_9.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004164800-923-202174/gkrellmms-2.1.22_9.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~u...@freebsd.org/20131004164800-923-202175/gkrellmms-2.1.22_9.log


--
Buildarchive URL: 
redports 
___
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"

make: stopped in /usr/ports/math/coinmp

[iZEN]

# cd /usr/ports/math/coinmp/ && make MAKE_JOBS_UNSAFE=yes
...
...
...
In file included from CglLandPSimplex.cpp:11:
In file included from ./CglLandPSimplex.hpp:14:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:434:
/usr/include/c++/v1/algorithm:678:97: error: invalid operands to binary
  expression ('const LAP::reducedCost' and 'const LAP::reducedCost')
  ...operator()(const _T1& __x, const _T1& __y) const {return __x < __y;}
  ~~~ ^ ~~~
/usr/include/c++/v1/algorithm:4763:13: note: in instantiation of member 
function

  'std::__1::__less::operator()'
  requested here
if (__comp(*__ptr, *--__last))
^
/usr/include/c++/v1/algorithm:4854:13: note: in instantiation of function
  template specialization
'std::__1::__push_heap_back &, LAP::reducedCost *>' requested here
__push_heap_back<_Compare>(__first, ++__last, __comp, ++__i);
^
/usr/include/c++/v1/algorithm:4869:5: note: in instantiation of function
  template specialization
'std::__1::__make_heap &, LAP::reducedCost *>' requested here
__make_heap<_Comp_ref>(__first, __last, __comp);
^
/usr/include/c++/v1/algorithm:4878:12: note: in instantiation of function
  template specialization 'std::__1::make_heap  std::__1::__less >' requested 
here

_VSTD::make_heap(__first, __last, __less  specialization 'std::__1::make_heap' 
requested here

std::make_heap(rc, rc + k);
 ^
CglLandPSimplex.cpp:2093:10: note: candidate function not viable: 'this'
  argument has type 'const LAP::reducedCost', but method is not 
marked const

bool operator<(const reducedCost & other)
 ^
/usr/include/c++/v1/utility:397:1: note: candidate template ignored: 
could not

  match 'pair' against
  'const LAP::reducedCost'
operator< (const pair<_T1,_T2>& __x, const pair<_T1,_T2>& __y)
^
/usr/include/c++/v1/iterator:566:1: note: candidate template ignored: 
could not

  match 'reverse_iterator' against
  'const LAP::reducedCost'
operator<(const reverse_iterator<_Iter1>& __x, const reverse_iterator<_I...
^
/usr/include/c++/v1/iterator:961:1: note: candidate template ignored: 
could not
  match 'move_iterator' against 'const 
LAP::reducedCost'
operator<(const move_iterator<_Iter1>& __x, const move_iterator<_Iter2>& 
__y)

^
/usr/include/c++/v1/iterator:1277:1: note: candidate template ignored: 
could not
  match '__wrap_iter' against 'const 
LAP::reducedCost'

operator<(const __wrap_iter<_Iter1>& __x, const __wrap_iter<_Iter2>& __y...
^
/usr/include/c++/v1/memory:2953:1: note: candidate template ignored: 
could not

  match 'unique_ptr' against
  'const LAP::reducedCost'
operator< (const unique_ptr<_T1, _D1>& __x, const unique_ptr<_T2, _D2>& __y)
^
/usr/include/c++/v1/memory:3011:1: note: candidate template ignored: 
could not

  match 'unique_ptr' against
  'const LAP::reducedCost'
operator<(const unique_ptr<_T1, _D1>& __x, nullptr_t)
^
/usr/include/c++/v1/memory:3020:1: note: candidate template ignored: 
could not

  match 'unique_ptr' against
  'const LAP::reducedCost'
operator<(nullptr_t, const unique_ptr<_T1, _D1>& __x)
^
/usr/include/c++/v1/memory:4799:1: note: candidate template ignored: 
could not
  match 'shared_ptr' against 'const 
LAP::reducedCost'

operator<(const shared_ptr<_Tp>& __x, const shared_ptr<_Up>& __y) _NOEXCEPT
^
/usr/include/c++/v1/memory:4864:1: note: candidate template ignored: 
could not
  match 'shared_ptr' against 'const 
LAP::reducedCost'

operator<(const shared_ptr<_Tp>& __x, nullptr_t) _NOEXCEPT
^
/usr/include/c++/v1/memory:4872:1: note: candidate template ignored: 
could not
  match 'shared_ptr' against 'const 
LAP::reducedCost'

operator<(nullptr_t, const shared_ptr<_Tp>& __x) _NOEXCEPT
^
1 error generated.
*** Error code 1

Stop.
make[6]: stopped in 
/portsobj/usr/ports/math/coinmp/work/CoinMP-1.7.0/Cgl/src/CglLandP

*** Error code 1

Stop.
make[5]: stopped in 
/portsobj/usr/ports/math/coinmp/work/CoinMP-1.7.0/Cgl/src

*** Error code 1

Stop.
make[4]: stopped in 
/portsobj/usr/ports/math/coinmp/work/CoinMP-1.7.0/Cgl/src

*** Error code 1

Stop.
make[3]: stopped in /portsobj/usr/ports/math/coinmp/work/CoinMP-1.7.0/Cgl
*** Error code 1

Stop.
make[2]: stopped in /portsobj/usr/ports/math/coinmp/work/CoinMP-1.7.0
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/math/coinmp
*** Error code 1

Stop.
make: stopped in /usr/ports/math/coinmp


# cat /var/db/ports/math_coinmp/options
# This file is auto-generated by 'make config'.
# Options for CoinMP-1.7.0
_OPTIONS_READ=CoinMP-1.7.0
_FILE_COMPLETE_OPTIONS_LIST=DEBUG DOCS
OPTIONS_FILE_UNSET+=DEBUG
OPTIONS_FILE_UNSET+=DOCS

___
freebsd-ports@freebsd.org mailing list
http://lists.

Re: Suddenly STAGE appeared

[Michael Gmelin]

On Fri, 04 Oct 2013 11:03:29 -0500
Paul Schmehl  wrote:

> --On October 4, 2013 4:35:57 PM +0200 Michael Gmelin
>  wrote:
> 
> > On Fri, 04 Oct 2013 09:22:25 -0500
> > Paul Schmehl  wrote:
> >
> >> Or did I miss the announcement?
> >>
> >> Is there a doc that explains STAGE and how to convert a port to the
> >> new system?  Why STAGE was created?  What it's purpose is?
> >>
> >> This is all very new to me, and I have 23 ports to worry about.
> >>
> >
> >
> > See
> > http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-October/00
> > 0067.html
> >
> > and the discussion here
> > http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html
> 
> Now it make sense.  I have a port that is failing to build on 10.0
> because of CLANG.  I don't have a 10.0 install, and it builds fine
> with GCC.  So I updated the port to use USE_GCC= yes, and I was asked
> to convert the port to use STAGE.  Left me scratching my head,
> because this was all before the announcement.
> 
> And I'm having problems building the port now - and wondering if I
> should just abandon my ports because the new system is confusing to
> me.  All this transitional stuff is a lot to grasp when you've been
> building ports successfully for a while and suddenly nothing works.
> 
> For example, make makeplist doesn't actually make a pkg-plist file on
> my system.
> 
> # make makeplist
> bin/sancp
> etc/rc.d/sancp
> etc/sancp.conf.dist
> 
> But no pkg-plist file is created.
> 
> WTH???
> 
> DOCS no longer build properly, and I have no clue why?
> 
> # make install
> ===>  Building package for sancp-1.6.1_5
> Creating package 
> /usr/ports/security/sancp-update/sancp/work/sancp-1.6.1_5.tbz
> Registering depends:.
> Creating bzip'd tar ball in 
> '/usr/ports/security/sancp-update/sancp/work/sancp-1.6.1_5.tbz'
> tar: share/doc/sancp/CHANGES: Cannot stat: No such file or directory
> tar: share/doc/sancp/INSTALL: Cannot stat: No such file or directory
> tar: share/doc/sancp/ISSUES: Cannot stat: No such file or directory
> tar: share/doc/sancp/README: Cannot stat: No such file or directory
> tar: share/doc/sancp/SETUP: Cannot stat: No such file or directory
> tar: share/doc/sancp/fields.LIST: Cannot stat: No such file or
> directory tar: Error exit delayed from previous errors.
> pkg_create: make_dist: tar command failed with code 256
> *** [do-package] Error code 1
> 
> Stop in /usr/ports/security/sancp-update/sancp.
> 
> The Makefile has this:
> PORTDOCS= CHANGES INSTALL ISSUES \
>   README SETUP fields.LIST
> 
> The docs are actually in ${WRKSRC}/doc, so I tried adding doc/ and 
> ${WRKSRC}/doc, but neither worked.  I tried adding
> %%PORTDOCS%%/docname to pkg-plist, but that failed as well.  So now
> I'm at a complete loss to know how to get the DOCS to work.
> 
> If you're going to make changes to the ports system and expect us 
> non-programmers to successfully grasp how all the changes get
> implemented, it would be very helpful to have a HOWTO page the
> explains the changes required in understandable detail.  The current
> page -  - is rather cryptic
> and open to interpretation.
> 
> How do I list PORTDOCS so the build nows where to find them?
> Previously we used .if !${NOPORTDOCS} and told INSTALL to descend
> into the doc directory to fetch the docs.  Then we changed to .if
> ${OPTIONS:MDOCS} and did the same.  Now I"m told I don't need that
> section at all, but obviously, without out, the build can't figure
> out where the docs are so it fails.
> 
> All of this should be anticipated and documented BEFORE these changes
> are rolled out and we're required to implement them or you can expect
> lots of frustration and people dropping ports.
> 
> I get that you're trying to do things in a better, more robust way,
> but communication is key, and that communication has to be detailed
> and understandable so us dummies can implement it.
> 

I have to agree. I love the new features in the ports system, after
extreme stability (almost stagnation) for almost a decade and most of
these things make a lot of sense to me. Especially staging is a must
have feature and I'm happy we finally got that.

That said, it would be good if documentation could keep up to give
port maintainers a chance to convert their ports in a time efficient
and non-frustrating manner.

Not contributing any of this myself, I would suggest:

 1. For every change, have a conversion howto in the FreeBSD wiki
 2. Only roll out changes if they're covered in the English version of
the Porter's Handbook

Cheers,
Michael

-- 
Michael Gmelin
___
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"

[QAT] r329318: 1x leftovers, 3x success

[Ports-QAT]

Reintroduced badly removed PKGNAMESUFFIX
-

  Build ID:  20131004145000-57009
  Job owner: b...@freebsd.org
  Buildtime: 83 minutes
  Enddate:   Fri, 04 Oct 2013 16:12:38 GMT

  Revision:  r329318
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=329318

-

Port:x11/avant-window-navigator 0.3.2.1_9

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004145000-57009-202104/avant-window-navigator-0.3.2.1_9.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004145000-57009-202105/avant-window-navigator-0.3.2.1_9.log

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004145000-57009-202106/avant-window-navigator-0.3.2.1_9.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   SUCCESS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20131004145000-57009-202107/avant-window-navigator-0.3.2.1_9.log


--
Buildarchive URL: 
redports 
___
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: Suddenly STAGE appeared

[Paul Schmehl]

--On October 4, 2013 4:35:57 PM +0200 Michael Gmelin  
wrote:



On Fri, 04 Oct 2013 09:22:25 -0500
Paul Schmehl  wrote:


Or did I miss the announcement?

Is there a doc that explains STAGE and how to convert a port to the
new system?  Why STAGE was created?  What it's purpose is?

This is all very new to me, and I have 23 ports to worry about.




See
http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-October/00
0067.html

and the discussion here
http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html


Now it make sense.  I have a port that is failing to build on 10.0 because 
of CLANG.  I don't have a 10.0 install, and it builds fine with GCC.  So I 
updated the port to use USE_GCC= yes, and I was asked to convert the port 
to use STAGE.  Left me scratching my head, because this was all before the 
announcement.


And I'm having problems building the port now - and wondering if I should 
just abandon my ports because the new system is confusing to me.  All this 
transitional stuff is a lot to grasp when you've been building ports 
successfully for a while and suddenly nothing works.


For example, make makeplist doesn't actually make a pkg-plist file on my 
system.


# make makeplist
bin/sancp
etc/rc.d/sancp
etc/sancp.conf.dist

But no pkg-plist file is created.

WTH???

DOCS no longer build properly, and I have no clue why?

# make install
===>  Building package for sancp-1.6.1_5
Creating package 
/usr/ports/security/sancp-update/sancp/work/sancp-1.6.1_5.tbz

Registering depends:.
Creating bzip'd tar ball in 
'/usr/ports/security/sancp-update/sancp/work/sancp-1.6.1_5.tbz'

tar: share/doc/sancp/CHANGES: Cannot stat: No such file or directory
tar: share/doc/sancp/INSTALL: Cannot stat: No such file or directory
tar: share/doc/sancp/ISSUES: Cannot stat: No such file or directory
tar: share/doc/sancp/README: Cannot stat: No such file or directory
tar: share/doc/sancp/SETUP: Cannot stat: No such file or directory
tar: share/doc/sancp/fields.LIST: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256
*** [do-package] Error code 1

Stop in /usr/ports/security/sancp-update/sancp.

The Makefile has this:
PORTDOCS=   CHANGES INSTALL ISSUES \
README SETUP fields.LIST

The docs are actually in ${WRKSRC}/doc, so I tried adding doc/ and 
${WRKSRC}/doc, but neither worked.  I tried adding %%PORTDOCS%%/docname to 
pkg-plist, but that failed as well.  So now I'm at a complete loss to know 
how to get the DOCS to work.


If you're going to make changes to the ports system and expect us 
non-programmers to successfully grasp how all the changes get implemented, 
it would be very helpful to have a HOWTO page the explains the changes 
required in understandable detail.  The current page - 
 - is rather cryptic and open to 
interpretation.


How do I list PORTDOCS so the build nows where to find them?  Previously we 
used .if !${NOPORTDOCS} and told INSTALL to descend into the doc directory 
to fetch the docs.  Then we changed to .if ${OPTIONS:MDOCS} and did the 
same.  Now I"m told I don't need that section at all, but obviously, 
without out, the build can't figure out where the docs are so it fails.


All of this should be anticipated and documented BEFORE these changes are 
rolled out and we're required to implement them or you can expect lots of 
frustration and people dropping ports.


I get that you're trying to do things in a better, more robust way, but 
communication is key, and that communication has to be detailed and 
understandable so us dummies can implement it.


--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

___
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: Suddenly STAGE appeared

[Mike Brown]

Paul Schmehl wrote:
> Or did I miss the announcement?

On this list, there are two ongoing threads about it,
started in the last couple days. 

Look for subject lines "Explain staging" and
"[HEADSUP] Staging, packaging and more" here:

http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086339.html
 
> Is there a doc that explains STAGE and how to convert a port to the new 
> system?  Why STAGE was created?  What it's purpose is?

General overviews:
http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086341.html
http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html

Conversion details:
https://wiki.freebsd.org/ports/StageDir

IMHO the overviews need to be incorporated into the wiki.
___
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: Suddenly STAGE appeared

[Michael Gmelin]

On Fri, 04 Oct 2013 09:22:25 -0500
Paul Schmehl  wrote:

> Or did I miss the announcement?
> 
> Is there a doc that explains STAGE and how to convert a port to the
> new system?  Why STAGE was created?  What it's purpose is?
> 
> This is all very new to me, and I have 23 ports to worry about.
> 


See
http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-October/67.html

and the discussion here
http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html

-- 
Michael Gmelin
___
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] Staging, packaging and more

[Daniel Nebdal]

On Fri, Oct 4, 2013 at 3:16 PM, Mathias Picker
 wrote:
> Am Freitag, den 04.10.2013, 06:12 -0500 schrieb Bryan Drewery:
>> On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote:
>> > On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote:
>> > > On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote:
>> > > > > > > >
>> > > > > > > > Please no devel packages.
>> > > > > > >
>> > > > > > > Seconded.
>> > > > > >
>> > > > > > What's wrong with devel packages?
>> > > > >
>> > > > > It complicates things for developers and custom software on
>> > > > > FreeBSD. The typical situation that I see on most Linux platforms is 
>> > > > > a
>> > > > > lot of confusion by people, why their custom software XYZ does not
>> > > > > properly build - the most common answer: they forgot to install a
>> > > > > tremendous amount of dev packages, containing headers, build tools 
>> > > > > and
>> > > > > whatnot.
>> > > > > On FreeBSD, you can rely on the fact that if you installed e.g. 
>> > > > > libGL,
>> > > > > you can start building your own GL applications without the need to
>> > > > > install several libGL-dev, libX11-dev, ... packages first.
>> > > > > This is something, which I personally see as a big plus of the 
>> > > > > FreeBSD
>> > > > > ports system and which makes FreeBSD attractive as a development 
>> > > > > platform.
>> > > > >
>> > > >
>> > > > On the other ends, that makes the package fat for embedded systems, 
>> > > > that also
>> > > > makes some arbitrary runtime conflicts between packages (because they 
>> > > > both
>> > > > provide the same symlink on the .so, while we could live with 2 
>> > > > version at
>> > > > runtime), that leads to tons of potential issue while building 
>> > > > locally, and
>> > > > that makes having sometime insane issues with dependency tracking. Why 
>> > > > having
>> > > > .a, .la, .h etc in production servers? It could greatly reduce PBI 
>> > > > size, etc.
>> > > >
>> > > > Personnaly I do have no strong opinion in one or another direction. 
>> > > > Should we be
>> > > > nicer with developers? with end users? with embedded world? That is 
>> > > > the question
>> > > > to face to decide if -devel packages is where we want to go or not.
>> > > >
>> > >
>> > > If we chose to go down that path, at least we should chose a different
>> > > name as we've used the -devel suffix for many years for developmental
>> > > versions.
>> > >
>> > > I must agree that it is one of the things high on my list of things that
>> > > irritate me with several Linux distributions but I can see the point for
>> > > for embedded systems as well.  But can't we have both?  Create three
>> > > packages, a default full package and split packages of -bin, -lib,
>> > > and even -doc.  My first though twas to make the full package a
>> > > meta-package that would install the split packages in the background,
>> > > but that would probably be confusing for users at the end of the day, so
>> > > rather just have it be a real package.
>> > >
>> > I do like that idea very much, and it is easily doable with stage :)
>>
>> +1 to splitting packages for embedded usage.
>
> For me, the full packages of FreeBSD where allways one big plus. I
> *hate* trying to compile anything and having to (find and) blow up my
> package count. Just more things to keep track of.
>
> Disk space is cheap, and it's getting cheaper, even on embedded systems.
> Is this really the time to optimize for a special case that might even
> (slowly) fade away as storage even in tiny system grows and grows?
>
>
> Regards, Mathias
>
>
>
>
>>
>> >
>> > regards,
>> > Bapt
>>
>>
>

Given that pkgng has feature flags, it could perhaps be doable to have
a "WITH_DEV_FILES" (or whatever) flag, and defaulting to "yes". The
embedded people could then set it to "no" and do a poudriere bulk
build (or whatever they prefer) and get a nice slim set of packages
with very little extra work. Ports could build-depend on a version
with the appropriate flag set, and run-depend on versions without ...
so if you try to compile something, it might be possible to drag the
appropriate dev-enabled package versions in automatically. Depending
on how feature flags actually work, of course; I might be optimistic
here. :)

Also, I wouldn't bet on embedded people getting unlimited amounts of
space just yet. It's weird how slowly some fields move.


-- 
Daniel Nebdal
___
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 porting question (rubygem related)

[Loïc BLOT]

Hello @ports,
i'm trying to port gitlab to FreeBSD ports (and also to train to build a
complex port).

At this time, i have done installation tasks but now i'm checking
dependencies. Gitlab uses bundler to install its dependencies but i want
to use FreeBSD ports too.
Then i have install all ports i can install but there is some missing
ports.

What are the conditions for rubygems to be added to FreeBSD port tree ?
Must I add all missing dependencies to FreeBSD ports tree or can i use a
patched gemfile for bundler to add only the missing deps ?

Have you got suggestions about a so big port ?

Thanks in advance.
-- 
Best regards,
Loïc BLOT, 
UNIX systems, security and network engineer
http://www.unix-experience.fr





signature.asc
Description: This is a digitally signed message part

Suddenly STAGE appeared

[Paul Schmehl]

Or did I miss the announcement?

Is there a doc that explains STAGE and how to convert a port to the new 
system?  Why STAGE was created?  What it's purpose is?


This is all very new to me, and I have 23 ports to worry about.

--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

___
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: anyone else using WITH_MYSQL_VER=55m and having problems?

[Vincent Hoffman]

On 04/10/2013 14:29, Florian Smeets wrote:
> On 04.10.13 13:45, Vincent Hoffman wrote:
>> I've opened a PR for apr1 but i'm thinking maybe it should be for
mariadb55?
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=182565
>>
>> a working build (against mysql55) has
>>
>
>>   setting LDADD_dbd_mysql to "-L/usr/local/lib/mysql -lmysqlclient_r 
-pthread -lz -lm -lmysqlclient_r -L/usr/local/lib/mysql -lmysqlclient_r 
-pthread -lz -lm"
>>
>
>>
>> The failed build (with mariadb55)
>>
>>   setting LIBS to "-L/usr/local/lib/mysql -lmysqlclient_r  -pthread
-lz -lm -lexecinfo"
>
> I see the error, it's a typo
>
> -LIB_DEPENDS=libexecinfo.so:${PORTSDIR}/devel/libexecinfo
> +LIB_DEPENDS+=libexecinfo.so:${PORTSDIR}/devel/libexecinfo
>
> I'll test this and commit the fix shortly.
Thanks for the quick reply/fix
Vince
>
> Florian
>


___
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] Staging, packaging and more

[Mathias Picker]

Am Freitag, den 04.10.2013, 06:12 -0500 schrieb Bryan Drewery:
> On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote:
> > On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote:
> > > On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote:
> > > > > > > >
> > > > > > > > Please no devel packages.
> > > > > > >
> > > > > > > Seconded.
> > > > > >
> > > > > > What's wrong with devel packages?
> > > > > 
> > > > > It complicates things for developers and custom software on
> > > > > FreeBSD. The typical situation that I see on most Linux platforms is a
> > > > > lot of confusion by people, why their custom software XYZ does not
> > > > > properly build - the most common answer: they forgot to install a
> > > > > tremendous amount of dev packages, containing headers, build tools and
> > > > > whatnot.
> > > > > On FreeBSD, you can rely on the fact that if you installed e.g. libGL,
> > > > > you can start building your own GL applications without the need to
> > > > > install several libGL-dev, libX11-dev, ... packages first.
> > > > > This is something, which I personally see as a big plus of the FreeBSD
> > > > > ports system and which makes FreeBSD attractive as a development 
> > > > > platform.
> > > > > 
> > > > 
> > > > On the other ends, that makes the package fat for embedded systems, 
> > > > that also
> > > > makes some arbitrary runtime conflicts between packages (because they 
> > > > both
> > > > provide the same symlink on the .so, while we could live with 2 version 
> > > > at
> > > > runtime), that leads to tons of potential issue while building locally, 
> > > > and
> > > > that makes having sometime insane issues with dependency tracking. Why 
> > > > having
> > > > .a, .la, .h etc in production servers? It could greatly reduce PBI 
> > > > size, etc.
> > > > 
> > > > Personnaly I do have no strong opinion in one or another direction. 
> > > > Should we be
> > > > nicer with developers? with end users? with embedded world? That is the 
> > > > question
> > > > to face to decide if -devel packages is where we want to go or not.
> > > > 
> > > 
> > > If we chose to go down that path, at least we should chose a different
> > > name as we've used the -devel suffix for many years for developmental
> > > versions.
> > > 
> > > I must agree that it is one of the things high on my list of things that
> > > irritate me with several Linux distributions but I can see the point for
> > > for embedded systems as well.  But can't we have both?  Create three
> > > packages, a default full package and split packages of -bin, -lib,
> > > and even -doc.  My first though twas to make the full package a
> > > meta-package that would install the split packages in the background,
> > > but that would probably be confusing for users at the end of the day, so
> > > rather just have it be a real package.
> > > 
> > I do like that idea very much, and it is easily doable with stage :)
> 
> +1 to splitting packages for embedded usage.

For me, the full packages of FreeBSD where allways one big plus. I
*hate* trying to compile anything and having to (find and) blow up my
package count. Just more things to keep track of. 

Disk space is cheap, and it's getting cheaper, even on embedded systems.
Is this really the time to optimize for a special case that might even
(slowly) fade away as storage even in tiny system grows and grows? 


Regards, Mathias




> 
> > 
> > regards,
> > Bapt
> 
> 


___
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] Staging, packaging and more

[Baptiste Daroussin]

On Fri, Oct 04, 2013 at 02:22:52PM +0200, Miroslav Lachman wrote:
> Baptiste Daroussin wrote:
> > On Fri, Oct 04, 2013 at 08:00:43AM +0100, Matthew Seaman wrote:
> >> On 04/10/2013 07:32, Baptiste Daroussin wrote:
> >>> On the other ends, that makes the package fat for embedded systems, that 
> >>> also
> >>> makes some arbitrary runtime conflicts between packages (because they both
> >>> provide the same symlink on the .so, while we could live with 2 version at
> >>> runtime), that leads to tons of potential issue while building locally, 
> >>> and
> >>> that makes having sometime insane issues with dependency tracking. Why 
> >>> having
> >>> .a, .la, .h etc in production servers? It could greatly reduce PBI size, 
> >>> etc.
> >>>
> >>> Personnaly I do have no strong opinion in one or another direction. 
> >>> Should we be
> >>> nicer with developers? with end users? with embedded world? That is the 
> >>> question
> >>> to face to decide if -devel packages is where we want to go or not.
> >>
> >> Can't we have the best of both worlds?
> >>
> >> We're already planning on creating sub-packages for eg. docs and
> >> examples.  The default will be to install docs etc. sub-packages
> >> automatically unless the user opts out in some way.  I imagine there
> >> will be a global switch somewhere -- in pkg.conf or similar[*].
> >>
> >> Couldn't we work devel packages in the same way? Install by default
> >> alongside the main package unless explicitly requested not to.
> >>
> >> I think having the capability to selectively install parts of packages
> >> like this is important and useful functionality and something that will
> >> be indispensible for eg. embedded platforms.  But not an option that the
> >> vast majority of ordinary users will need to exercise.
> >>
> >>Cheers,
> >>
> >>Matthew
> >>
> >> [*] The precise mechanism for choosing which sub-package bits to install
> >> has not yet been written.  If anyone has any bright ideas about how this
> >> should all work, then I'd be interested to hear them.
> >>
> >
> > That is another possiblity, I do prefer Erwin's idea about the -full, but 
> > this
> > also makes a lot of sense.
> 
> I really like the current state with full packages. Disk space is cheap, 
> full packages is default for whole FreeBSD existence and it is easy to 
> maintain the system with it. If I want portA and portB, I just install 
> portA and portB and if I want to see installed ports, I see two ports 
> installed and not a bunch of lines like:
> portA-bin
> portA-doc
> portA-dev
> portB-bin
> portB-doc
> portB-dev
> 
> When I need to update those ports, I will update two ports, not six or 
> more ports / sub ports.
> 
> Embedded systems are corner case, where many things need to be tweaked 
> anyway.
> 
> So I like the idea of default full packages with possibility to 
> optionally select and install sub parts for those who really need the 
> fine grained list of packages.

That is because you keep thinking you have to build those ports yourself, we are
here speaking of binary packages.

regards,
Bapt


pgp_uMwU6KX2k.pgp
Description: PGP signature

Re: anyone else using WITH_MYSQL_VER=55m and having problems?

[Florian Smeets]

On 04.10.13 13:45, Vincent Hoffman wrote:
> I've opened a PR for apr1 but i'm thinking maybe it should be for mariadb55?
> http://www.freebsd.org/cgi/query-pr.cgi?pr=182565
> 
> a working build (against mysql55) has
> 

>   setting LDADD_dbd_mysql to "-L/usr/local/lib/mysql -lmysqlclient_r  
> -pthread -lz -lm -lmysqlclient_r -L/usr/local/lib/mysql -lmysqlclient_r  
> -pthread -lz -lm"
>

> 
> The failed build (with mariadb55)
> 
>   setting LIBS to "-L/usr/local/lib/mysql -lmysqlclient_r  -pthread -lz -lm 
> -lexecinfo"

I see the error, it's a typo

-LIB_DEPENDS=   libexecinfo.so:${PORTSDIR}/devel/libexecinfo
+LIB_DEPENDS+=  libexecinfo.so:${PORTSDIR}/devel/libexecinfo

I'll test this and commit the fix shortly.

Florian



signature.asc
Description: OpenPGP digital signature

Re: PostgreSQL server bus error with uuid-ossp extension

[Bill Moran]

On Fri, 4 Oct 2013 15:44:51 +0800
Christopher Hall  wrote:

> When running PostgreSQL with the uuid-ossp extension the server fails
> with signal 10 (bus error).

http://pgfoundry.org/projects/uuid-freebsd/

-- 
Bill Moran 
___
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"

Ports with duplicate LATEST_LINKs

[Ports Index build]

Dear port maintainers,

The following list includes ports maintained by you that have duplicate
LATEST_LINK values.  They should either be modified to use a unique
LATEST_LINK or suppressed using NO_LATEST_LINK, to avoid overwriting
each other in the packages/Latest directory.  If your ports conflict with
ports maintained by another person, please coordinate your efforts with
them.


Thanks,
Erwin "Annoying Reminder Guy III" Lansing


LATEST_LINK  PORTNAME   MAINTAINER  
==
avant-window-navigator x11/avant-window-navigator po...@freebsd.org   
avant-window-navigator x11/avant-window-navigator-gnome po...@freebsd.org   

Total: 2 ports
___
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"

net-im/telepathy-glib problem

[Joerg Surmann]

Hi all,

i can't install port net-im telepathy-glib.
In Attachements a .txt file with the error messages.

Thanks for help

In file included from account-manager.c:42:
../telepathy-glib/_gen/tp-cli-account-manager-body.h:48:3: error: use of 
undeclared identifier 'tp_cli_account_manager_signal_callback_account_removed'; 
did you mean
  '_tp_cli_account_manager_invoke_callback_for_account_removed'?
  tp_cli_account_manager_signal_callback_account_removed callback =
  ^~
  _tp_cli_account_manager_invoke_callback_for_account_removed
../telepathy-glib/_gen/tp-cli-account-manager-body.h:41:1: note: 
'_tp_cli_account_manager_invoke_callback_for_account_removed' declared here
_tp_cli_account_manager_invoke_callback_for_account_removed (TpProxy *tpproxy,
^
../telepathy-glib/_gen/tp-cli-account-manager-body.h:48:57: error: expected ';' 
after expression
  tp_cli_account_manager_signal_callback_account_removed callback =
^
;
../telepathy-glib/_gen/tp-cli-account-manager-body.h:48:58: error: use of 
undeclared identifier 'callback'
  tp_cli_account_manager_signal_callback_account_removed callback =
 ^
../telepathy-glib/_gen/tp-cli-account-manager-body.h:49:8: error: use of 
undeclared identifier 'tp_cli_account_manager_signal_callback_account_removed'; 
did you mean
  '_tp_cli_account_manager_invoke_callback_for_account_removed'?
  (tp_cli_account_manager_signal_callback_account_removed) generic_callback;
   ^~
   _tp_cli_account_manager_invoke_callback_for_account_removed
../telepathy-glib/_gen/tp-cli-account-manager-body.h:41:1: note: 
'_tp_cli_account_manager_invoke_callback_for_account_removed' declared here
_tp_cli_account_manager_invoke_callback_for_account_removed (TpProxy *tpproxy,
^
../telepathy-glib/_gen/tp-cli-account-manager-body.h:51:7: error: use of 
undeclared identifier 'callback'
  if (callback != NULL)
  ^
../telepathy-glib/_gen/tp-cli-account-manager-body.h:52:5: warning: implicit 
declaration of function 'callback' is invalid in C99 
[-Wimplicit-function-declaration]
callback (g_object_ref (tpproxy),
^
../telepathy-glib/_gen/tp-cli-account-manager-body.h:48:3: warning: expression 
result unused [-Wunused-value]
  tp_cli_account_manager_signal_callback_account_removed callback =
  ^~
../telepathy-glib/_gen/tp-cli-account-manager-body.h:62:5: error: unknown type 
name 'tp_cli_account_manager_signal_callback_account_removed'; did you mean 
'tp_cli_account_signal_callback_removed'?
tp_cli_account_manager_signal_callback_account_removed callback,
^~
tp_cli_account_signal_callback_removed
../telepathy-glib/_gen/tp-cli-account.h:6:16: note: 
'tp_cli_account_signal_callback_removed' declared here
typedef void (*tp_cli_account_signal_callback_removed) (TpAccount *proxy,
   ^
In file included from account-manager.c:42:
../telepathy-glib/_gen/tp-cli-account-manager-body.h:61:1: warning: no previous 
prototype for function 'tp_cli_account_manager_connect_to_account_removed' 
[-Wmissing-prototypes]
tp_cli_account_manager_connect_to_account_removed (TpAccountManager *proxy,
^
../telepathy-glib/_gen/tp-cli-account-manager-body.h:117:3: error: use of 
undeclared identifier 
'tp_cli_account_manager_signal_callback_account_validity_changed'; did you mean
  '_tp_cli_account_manager_invoke_callback_for_account_validity_changed'?
  tp_cli_account_manager_signal_callback_account_validity_changed callback =
  ^~~
  _tp_cli_account_manager_invoke_callback_for_account_validity_changed
../telepathy-glib/_gen/tp-cli-account-manager-body.h:110:1: note: 
'_tp_cli_account_manager_invoke_callback_for_account_validity_changed' declared 
here
_tp_cli_account_manager_invoke_callback_for_account_validity_changed (TpProxy 
*tpproxy,
^
../telepathy-glib/_gen/tp-cli-account-manager-body.h:117:66: error: expected 
';' after expression
  tp_cli_account_manager_signal_callback_account_validity_changed callback =
 ^
 ;
../telepathy-glib/_gen/tp-cli-account-manager-body.h:118:8: error: use of 
undeclared identifier 
'tp_cli_account_manager_signal_callback_account_validity_changed'; did you mean
  '_tp_cli_account_manager_invoke_callback_for_account_validity_changed'?
  (tp_cli_account_manager_signal_callback_account_validity_changed) 
generic_callback;
   ^~~
   _tp_cli_account_manager_invoke_callback_for_account_validity_changed
../telepathy-glib/_gen/

Re: [HEADSUP] Staging, packaging and more

[Miroslav Lachman]

Baptiste Daroussin wrote:

On Fri, Oct 04, 2013 at 08:00:43AM +0100, Matthew Seaman wrote:

On 04/10/2013 07:32, Baptiste Daroussin wrote:

On the other ends, that makes the package fat for embedded systems, that also
makes some arbitrary runtime conflicts between packages (because they both
provide the same symlink on the .so, while we could live with 2 version at
runtime), that leads to tons of potential issue while building locally, and
that makes having sometime insane issues with dependency tracking. Why having
.a, .la, .h etc in production servers? It could greatly reduce PBI size, etc.

Personnaly I do have no strong opinion in one or another direction. Should we be
nicer with developers? with end users? with embedded world? That is the question
to face to decide if -devel packages is where we want to go or not.


Can't we have the best of both worlds?

We're already planning on creating sub-packages for eg. docs and
examples.  The default will be to install docs etc. sub-packages
automatically unless the user opts out in some way.  I imagine there
will be a global switch somewhere -- in pkg.conf or similar[*].

Couldn't we work devel packages in the same way? Install by default
alongside the main package unless explicitly requested not to.

I think having the capability to selectively install parts of packages
like this is important and useful functionality and something that will
be indispensible for eg. embedded platforms.  But not an option that the
vast majority of ordinary users will need to exercise.

Cheers,

Matthew

[*] The precise mechanism for choosing which sub-package bits to install
has not yet been written.  If anyone has any bright ideas about how this
should all work, then I'd be interested to hear them.



That is another possiblity, I do prefer Erwin's idea about the -full, but this
also makes a lot of sense.


I really like the current state with full packages. Disk space is cheap, 
full packages is default for whole FreeBSD existence and it is easy to 
maintain the system with it. If I want portA and portB, I just install 
portA and portB and if I want to see installed ports, I see two ports 
installed and not a bunch of lines like:

portA-bin
portA-doc
portA-dev
portB-bin
portB-doc
portB-dev

When I need to update those ports, I will update two ports, not six or 
more ports / sub ports.


Embedded systems are corner case, where many things need to be tweaked 
anyway.


So I like the idea of default full packages with possibility to 
optionally select and install sub parts for those who really need the 
fine grained list of packages.


Miroslav Lachman
___
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"

INDEX now builds successfully on 8.x

[Ports Index build]

___
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: multimedia/libbluray -- IGNORE... Why?

[RW]

On Fri, 04 Oct 2013 04:17:12 -0700
Ronald F. Guilmette wrote:

> 
> 
> Why is the multimedia/libbluray port marked as IGNORE in the current
> ports tree?

If you try to build it, it will tell you why.

> More to the point, why didn't whoever marked it as IGNORE have the
> simple courtesy to put at least some explanitory note about the
> marking of this port (as IGNORE) into the UPDATING file?

That's not what UPDATING is for. 


___
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"

anyone else using WITH_MYSQL_VER=55m and having problems?

[Vincent Hoffman]

I've opened a PR for apr1 but i'm thinking maybe it should be for mariadb55?
http://www.freebsd.org/cgi/query-pr.cgi?pr=182565

a working build (against mysql55) has

checking for mysql_config... /usr/local/bin/mysql_config
  adding "-lmysqlclient_r" to LDFLAGS
  adding "-pthread" to LDFLAGS
  adding "-lz" to LDFLAGS
  adding "-lm" to LDFLAGS
  setting LIBS to "-L/usr/local/lib/mysql -lmysqlclient_r  -pthread -lz -lm"
configure: checking for mysql in /usr/local
checking for mysql.h... yes
checking for mysql_init in -lmysqlclient_r... yes
checking for my_global.h... yes
checking for mysql_init in -lmysqlclient_r... (cached) yes
checking for my_sys.h... yes
checking for mysql_init in -lmysqlclient_r... (cached) yes
  adding "-I/usr/local/include/mysql" to APRUTIL_PRIV_INCLUDES
  setting LDADD_dbd_mysql to "-L/usr/local/lib/mysql -lmysqlclient_r  -pthread 
-lz -lm -lmysqlclient_r -L/usr/local/lib/mysql -lmysqlclient_r  -pthread -lz 
-lm"


The failed build (with mariadb55)

checking for mysql_config... /usr/local/bin/mysql_config
  adding "-I/usr/local/include/mysql/.." to CPPFLAGS
  adding "-lmysqlclient_r" to LDFLAGS
  adding "-pthread" to LDFLAGS
  adding "-lz" to LDFLAGS
  adding "-lm" to LDFLAGS
  adding "-lexecinfo" to LDFLAGS
  setting LIBS to "-L/usr/local/lib/mysql -lmysqlclient_r  -pthread -lz -lm 
-lexecinfo"
configure: checking for mysql in /usr/local
checking for mysql.h... yes
checking for mysql_init in -lmysqlclient_r... no
checking for my_global.h... yes
checking for mysql_init in -lmysqlclient_r... (cached) no
checking for my_sys.h... yes
checking for mysql_init in -lmysqlclient_r... (cached) no
checking for mysql/mysql.h... yes
checking for mysql_init in -lmysqlclient_r... (cached) no
checking for mysql/my_global.h... yes
checking for mysql_init in -lmysqlclient_r... (cached) no
checking for mysql/my_sys.h... yes
checking for mysql_init in -lmysqlclient_r... (cached) no

Thanks,
Vince
___
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: multimedia/libbluray -- IGNORE... Why?

[Rodrigo Osorio]

Hi,

I Made a check in the SVN and libbluray was never
marked IGNORE, at least BROKEN for some java reasons.

Are you sure isn't a dependencie problem ?
Which version are you trying to install ?

Regards,
- rodrigo

On 04/10/13 04:17 -0700, Ronald F. Guilmette wrote:
> 
> 
> Why is the multimedia/libbluray port marked as IGNORE in the current ports
> tree?
> 
> More to the point, why didn't whoever marked it as IGNORE have the simple
> courtesy to put at least some explanitory note about the marking of this
> port (as IGNORE) into the UPDATING file?
> ___
> 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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Explain staging

[Alexander Yerenkow]

I'd recommend to
1) take excerpts from this topic and expand wiki - since here was a lot of
info
2) When port fails due to staging,add there link to wiki, so user / port
developer will see immediately where to dig.
Thanks.


2013/10/4 Baptiste Daroussin 

> On Thu, Oct 03, 2013 at 08:21:19PM -0500, Stephen Montgomery-Smith wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 10/03/2013 07:22 AM, Stephen Montgomery-Smith wrote:
> > > On 10/03/2013 04:54 AM, Baptiste Daroussin wrote:
> > >> On Thu, Oct 03, 2013 at 10:58:56AM +0200, Alex Dupre wrote:
> > >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> > >>>
> > >>> Baptiste Daroussin ha scritto:
> >  Here you are:
> > 
> http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html
> > >>>
> > >>>
> > 
> > >
> > 
> > I
> > 
> > >>> was referring the the previous one: "[HEADSUP] Stage support
> > >>> for the ports tree". Dunno if it had additional info or this
> > >>> second one is enough.
> > >>>
> > >> I mixed both in one :)
> > >
> > > I do appreciate the explanations very much.
> > >
> > > I am having a problem with a port in which if NO_STAGE is not set,
> > > then the build part of the process fails.  As far as I can tell,
> > > staging should not effect the build part of the process in any
> > > way. So two questions: 1.  If I set NO_STAGE=yes in that port, is
> > > this going to be a big problem?  It will have to be a work around
> > > until I can get the next question answered: 2.  Any ideas on why
> > > staging would effect the build process?  The port includes
> > > subpackages that use "./configure; make; make install" and are
> > > supposed to install into $WRKSRC/local, but instead sometimes
> > > installs into $WRKDIR/stage/portname/work/pkgname/local.
> >
> > FYI
> >
> > So when NO_STAGE is not set, MAKE_ARGS includes
> > DESTDIR=$WRKDIR/work/stage.
> >
> > This messes up the build process on this port.
> >
> > This is probably something to be fixed way down the road, and perhaps
> > it is my port that needs fixing.
>
> If for your port DESTDIR means something else, and STAGEDIR is expecting
> to be
> exposed though another variable then change DESTDIRNAME which is DESTDIR by
> default.
>
> regards,
> Bapt
>



-- 
Regards,
Alexander Yerenkow
___
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"

Xorg core dump after update xorg-server and xf86-video-intel

[Ivan Klymenko]

Hello.

I have FreeBSD 10.0-ALPHA4 #0 r255945

ports revision: 329226

xf86-video-intel-2.21.15
xorg-server-1.12.4_3,1

I use the SNA acceleration: Option "AccelMethod" "SNA"

Xorg behaves very unstable after upgrade
ls -l /var/coredumps/ | grep Xorg
-rw---  1 root  wheel  50524160  4 окт 13:39 0.3157.Xorg.core
-rw---  1 root  wheel  63332352  4 окт 14:00 0.32702.Xorg.core
-rw---  1 root  wheel  66543616  4 окт 14:01 0.32844.Xorg.core
-rw---  1 root  wheel  72032256  4 окт 14:03 0.32988.Xorg.core
-rw---  1 root  wheel  56549376  4 окт 14:03 0.33350.Xorg.core
-rw---  1 root  wheel  62160896  4 окт 14:04 0.33543.Xorg.core
-rw---  1 root  wheel  53837824  4 окт 14:04 0.33736.Xorg.core
-rw---  1 root  wheel  53751808  4 окт 14:04 0.33905.Xorg.core
-rw---  1 root  wheel  53747712  4 окт 14:05 0.34043.Xorg.core
-rw---  1 root  wheel  42508288  4 окт 13:39 0.3407.Xorg.core
-rw---  1 root  wheel  22478848  4 окт 14:05 0.34189.Xorg.core

I rebuilt intel driver and xorg-server ports with -g option
gdb backtrace's full:
http://privatepaste.com/f81e7457bc
http://privatepaste.com/a8bd87908f
http://privatepaste.com/6bdea215fd
it's just three typical output bt full

I do not even know what to suggest.

I have not signed for x11 maillist - please
indicate the CC on me.

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: poudriere feature suggestion: retry with gcc

[Kimmo Paasiala]

On Fri, Oct 4, 2013 at 1:15 PM, Beeblebrox  wrote:
> I have a pure clang world and no GCC from base (WITHOUT_GCC= yes). The same
> goes for the poudriere build environment.
>
> When doing massive updates (like the recent pixman-dependent ports), I get a
> number of ports that fail to build. The number of failed + skipped was about
> 150 for this run for example. I also have gnome3 merged ports tree. When I
> tried to build the failed ports on host, the compile broke just as it had in
> the poudriere run, but when I re-tried with USE_GCC=4.6, most failed ports
> got built. So it looks like many of the compile breakage is related to not
> having base GCC42 on the system.
>
> While the gcc -> clang shift is on-going, it would be very helpful if
> poudriere.conf had an option to retry only once to compile a failed port
> with the USE_GCC (or several user-defined) flags. So something like:
> RETRY_ONFAIL=yes
> RETRY_FLAGS="USE_GCC NOCCACHE"
>
> Regards.
>
>
>
Why have this only on poudriere? This kind of features belong in the
ports(7) infrastructure if anywhere.

-Kimmo
___
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"

multimedia/libbluray -- IGNORE... Why?

[Ronald F. Guilmette]

Why is the multimedia/libbluray port marked as IGNORE in the current ports
tree?

More to the point, why didn't whoever marked it as IGNORE have the simple
courtesy to put at least some explanitory note about the marking of this
port (as IGNORE) into the UPDATING file?
___
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] Staging, packaging and more

[Bryan Drewery]

On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote:
> On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote:
> > On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote:
> > > > > > >
> > > > > > > Please no devel packages.
> > > > > >
> > > > > > Seconded.
> > > > >
> > > > > What's wrong with devel packages?
> > > > 
> > > > It complicates things for developers and custom software on
> > > > FreeBSD. The typical situation that I see on most Linux platforms is a
> > > > lot of confusion by people, why their custom software XYZ does not
> > > > properly build - the most common answer: they forgot to install a
> > > > tremendous amount of dev packages, containing headers, build tools and
> > > > whatnot.
> > > > On FreeBSD, you can rely on the fact that if you installed e.g. libGL,
> > > > you can start building your own GL applications without the need to
> > > > install several libGL-dev, libX11-dev, ... packages first.
> > > > This is something, which I personally see as a big plus of the FreeBSD
> > > > ports system and which makes FreeBSD attractive as a development 
> > > > platform.
> > > > 
> > > 
> > > On the other ends, that makes the package fat for embedded systems, that 
> > > also
> > > makes some arbitrary runtime conflicts between packages (because they both
> > > provide the same symlink on the .so, while we could live with 2 version at
> > > runtime), that leads to tons of potential issue while building locally, 
> > > and
> > > that makes having sometime insane issues with dependency tracking. Why 
> > > having
> > > .a, .la, .h etc in production servers? It could greatly reduce PBI size, 
> > > etc.
> > > 
> > > Personnaly I do have no strong opinion in one or another direction. 
> > > Should we be
> > > nicer with developers? with end users? with embedded world? That is the 
> > > question
> > > to face to decide if -devel packages is where we want to go or not.
> > > 
> > 
> > If we chose to go down that path, at least we should chose a different
> > name as we've used the -devel suffix for many years for developmental
> > versions.
> > 
> > I must agree that it is one of the things high on my list of things that
> > irritate me with several Linux distributions but I can see the point for
> > for embedded systems as well.  But can't we have both?  Create three
> > packages, a default full package and split packages of -bin, -lib,
> > and even -doc.  My first though twas to make the full package a
> > meta-package that would install the split packages in the background,
> > but that would probably be confusing for users at the end of the day, so
> > rather just have it be a real package.
> > 
> I do like that idea very much, and it is easily doable with stage :)

+1 to splitting packages for embedded usage.

> 
> regards,
> Bapt




pgpCc9dCAhaXl.pgp
Description: PGP signature

Port build failures -- graphics/clutter-gtk & security/hydra

[Ronald F. Guilmette]

I've been updating all of my ports, which I confess I have not done
for some long time now, and I've managed to work past most of the
easy build problems, but I'm still stuck with two things that just
refuse to build, based on what's in the current ports tree:

! security/hydra (hydra-7.4.2)  (fetch error)
! graphics/clutter-gtk (clutter-gtk-0.10.8_2)   (unknown build error)

The source tarball for the current hydra port seems to be nowhere to be
found.  How come?  Shouldn't there ALWAYS be at least one copy of the
source tarball for _every_ port on one of the FreeBSD distribution servers??

In the case of clutter-gtk, it configures OK, but then compiling generates
a whole boat load of compile time errors.  I tried the Makefile fix
suggested here:

http://www.freebsd.org/cgi/query-pr.cgi?pr=177813

but that did not help in the slightest.  According to a suggestion made
within the build error messages, I also tried setting MAKE_JOBS_UNSAFE
to "yes" in the environment (and also on the make command line) and those
actions didn't materially help the situation either.  Logs of the build
failures, both before and after this step, are attached.

Does anybody test this stuff, you know, before it goes into the ports
tree?


P.S.  I just checked, and there is no mention whatsoever of clutter-gtk
AT ALL in the UPDATING file.
Script started on Fri Oct  4 03:51:54 2013

root@segfault:/usr/ports/graphics/clutter-gtk # make
===> Fetching all distfiles required by clutter-gtk-0.10.8_3 for building
===>  Extracting for clutter-gtk-0.10.8_3
=> SHA256 Checksum OK for clutter-gtk-0.10.8.tar.bz2.
===>  Patching for clutter-gtk-0.10.8_3
===>   clutter-gtk-0.10.8_3 depends on package: libtool>=2.4 - found
===>  Applying FreeBSD patches for clutter-gtk-0.10.8_3
===>   clutter-gtk-0.10.8_3 depends on executable: gmake - found
===>   clutter-gtk-0.10.8_3 depends on executable: pkgconf - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/dri2proto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: /usr/local/libdata/pkgconfig/xp.pc 
- found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/x11.pc - found
===>   clutter-gtk-0.10.8_3 depends on package: libtool>=2.4 - found
===>   clutter-gtk-0.10.8_3 depends on file: /usr/local/bin/intltool-extract - 
found
===>   clutter-gtk-0.10.8_3 depends on shared library: libGL.so - found
===>   clutter-gtk-0.10.8_3 depends on shared library: clutter-glx-1.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: intl - found
===>   clutter-gtk-0.10.8_3 depends on shared library: atk-1.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: glib-2.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: pcre - found
===>   clutter-gtk-0.10.8_3 depends on shared library: gtk-x11-2.0.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: pango-1.0 - found
===>  Configuring for clutter-gtk-0.10.8_3
configure: WARNING: unrecognized options: --with-gconf-source
configure: loading site script /usr/ports/Templates/config.site
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for gawk... (cached) /usr/bin/awk
checking whether gmake sets $(MAKE)... yes
checking for style of include used by gmake... GNU
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking dependency style of cc... gcc3
checking whether cc understands -c and -o together... yes
checking how to run the C preprocessor... cpp
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for ANSI C header files... (cached) yes
checking build system type... amd64-portbld-freebsd9.1
checking host system type... amd64-portbld-freebsd9.1
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for fgrep... (cached) /usr/bin/fgrep
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... (cached) 262144
checking whether the shell understands some XSI constructs... yes
checking whether the shell understa

poudriere feature suggestion: retry with gcc

[Beeblebrox]

I have a pure clang world and no GCC from base (WITHOUT_GCC= yes). The same
goes for the poudriere build environment.

When doing massive updates (like the recent pixman-dependent ports), I get a
number of ports that fail to build. The number of failed + skipped was about
150 for this run for example. I also have gnome3 merged ports tree. When I
tried to build the failed ports on host, the compile broke just as it had in
the poudriere run, but when I re-tried with USE_GCC=4.6, most failed ports
got built. So it looks like many of the compile breakage is related to not
having base GCC42 on the system.

While the gcc -> clang shift is on-going, it would be very helpful if
poudriere.conf had an option to retry only once to compile a failed port
with the USE_GCC (or several user-defined) flags. So something like:
RETRY_ONFAIL=yes
RETRY_FLAGS="USE_GCC NOCCACHE"

Regards.



-
FreeBSD-9.2-stable_amd64_root-on-zfs_clang-only-world
--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/poudriere-feature-suggestion-retry-with-gcc-tp5848725.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
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

[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
+-+
audio/pd| 0.44-3  | 0.45-3
+-+


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

If wish to stop receiving portscout reminders, please contact
portsc...@freebsd.org

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"

INDEX build failed for 8.x

[Ports Index build]

INDEX build failed with errors:
Generating INDEX-8 - please wait.. Done.
Warning: Duplicate INDEX entry: dumb-0.9.3_3
Warning: Duplicate INDEX entry: freeciv-2.3.4
Warning: Duplicate INDEX entry: ImageMagick-6.8.0.7_1

Committers on the hook:
 bapt sunpoet wen 

Most recent SVN update was:
Updating '.':
Udatabases/sqsh/Makefile
Udatabases/p5-Rose-DB/Makefile
Ugraphics/gifsicle/Makefile
Ugraphics/GraphicsMagick/Makefile
Ugraphics/imlib2/Makefile
Ugraphics/GraphicsMagick12/Makefile
Ugraphics/GraphicsMagick13/Makefile
Ugraphics/xpdf/Makefile
Ugraphics/ImageMagick/Makefile
Ux11/avant-window-navigator/Makefile
Uemulators/zsnes/Makefile
Uwww/ump/Makefile
Uwww/p5-Dancer2/pkg-plist
Uwww/p5-Dancer2/Makefile
Uastro/xtide/Makefile
Udevel/sdl12/Makefile
Uaudio/gqmpeg/Makefile
Uaudio/boodler/Makefile
Uaudio/xmixer/Makefile
Uaudio/taglib/Makefile
Uaudio/mp3info/Makefile
Uaudio/libmikmod/Makefile
Uaudio/aumix/Makefile
Uaudio/dumb/Makefile
Uaudio/muse/Makefile
Ubiology/pyfasta/Makefile
Ubiology/pyfasta/distinfo
Ubiology/pyfasta/pkg-descr
Ueditors/hte/Makefile
Ueditors/elvis/Makefile
Uftp/gftp/Makefile
Uftp/pavuk/Makefile
Ugames/freeciv/Makefile
Updated to revision 329271.
___
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] Staging, packaging and more

[Dewayne Geraghty]

> -Original Message-
> From: owner-freebsd-po...@freebsd.org 
> [mailto:owner-freebsd-po...@freebsd.org] On Behalf Of Erwin Lansing
> Sent: Friday, 4 October 2013 4:58 PM
> To: Baptiste Daroussin
> Cc: po...@freebsd.org; Fernando Apesteguía
> Subject: Re: [HEADSUP] Staging, packaging and more
> 
> On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote:
> > > > > >
> > > > > > Please no devel packages.
> > > > >
> > > > > Seconded.
> > > >
> > > > What's wrong with devel packages?
> > > 
> > > It complicates things for developers and custom software 
> on FreeBSD. 
> > > The typical situation that I see on most Linux platforms 
> is a lot of 
> > > confusion by people, why their custom software XYZ does 
> not properly 
> > > build - the most common answer: they forgot to install a 
> tremendous 
> > > amount of dev packages, containing headers, build tools 
> and whatnot.
> > > On FreeBSD, you can rely on the fact that if you installed e.g. 
> > > libGL, you can start building your own GL applications 
> without the 
> > > need to install several libGL-dev, libX11-dev, ... packages first.
> > > This is something, which I personally see as a big plus of the 
> > > FreeBSD ports system and which makes FreeBSD attractive 
> as a development platform.
> > > 
> > 
> > On the other ends, that makes the package fat for embedded systems, 
> > that also makes some arbitrary runtime conflicts between packages 
> > (because they both provide the same symlink on the .so, 
> while we could 
> > live with 2 version at runtime), that leads to tons of 
> potential issue 
> > while building locally, and that makes having sometime 
> insane issues 
> > with dependency tracking. Why having .a, .la, .h etc in 
> production servers? It could greatly reduce PBI size, etc.
> > 
> > Personnaly I do have no strong opinion in one or another direction. 
> > Should we be nicer with developers? with end users? with embedded 
> > world? That is the question to face to decide if -devel 
> packages is where we want to go or not.
> > 
> 
> If we chose to go down that path, at least we should chose a 
> different name as we've used the -devel suffix for many years 
> for developmental versions.
> 
> I must agree that it is one of the things high on my list of 
> things that irritate me with several Linux distributions but 
> I can see the point for for embedded systems as well.  But 
> can't we have both?  Create three packages, a default full 
> package and split packages of -bin, -lib, and even -doc.  My 
> first though twas to make the full package a meta-package 
> that would install the split packages in the background, but 
> that would probably be confusing for users at the end of the 
> day, so rather just have it be a real package.
> 
> Erwin
> 
> 
> -- 
> Erwin Lansinghttp://droso.dk
> er...@freebsd.orghttp:// www.FreeBSD.org
> 

We develop embedded systems - we build a minimal FreeBSD base, stripping out 
named, ntpd, heimdal, openssl, etc. We then build a
complete suite of packages for each CPU type of interest: Pentium3, Prescott, 
Core2, K8. The package is then "repackaged" stripping
out doc, examples etc.  Before client equipment is updated, the entire package 
suite is rebuilt, thoroughly tested and made
available for client's updating process.

If a development version is required and sometimes new options are tested, then 
the package suite is rebuilt for development access.
But this is getting into workflow/processes, a different topic.

No multiple versions of anything, if we can avoid it.  Simplicity is paramount, 
and the integrity of the package suite is vital for
support.

Regards, Dewayne.
PS We've been doing this a long time, we started stripping out heimdal when 
FreeBSD was at 0.6.3 and the port was 1.0.1. We've
maintained the paradigm and rely upon ports, over the FreeBSD base applications 
- and yes, we do loose out on somethings, like gssd.


___
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] Staging, packaging and more

[Fernando Apesteguía]

On Fri, Oct 4, 2013 at 9:01 AM, Baptiste Daroussin  wrote:

> On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote:
> > On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote:
> > > > > > >
> > > > > > > Please no devel packages.
> > > > > >
> > > > > > Seconded.
> > > > >
> > > > > What's wrong with devel packages?
> > > >
> > > > It complicates things for developers and custom software on
> > > > FreeBSD. The typical situation that I see on most Linux platforms is
> a
> > > > lot of confusion by people, why their custom software XYZ does not
> > > > properly build - the most common answer: they forgot to install a
> > > > tremendous amount of dev packages, containing headers, build tools
> and
> > > > whatnot.
> > > > On FreeBSD, you can rely on the fact that if you installed e.g.
> libGL,
> > > > you can start building your own GL applications without the need to
> > > > install several libGL-dev, libX11-dev, ... packages first.
> > > > This is something, which I personally see as a big plus of the
> FreeBSD
> > > > ports system and which makes FreeBSD attractive as a development
> platform.
> > > >
> > >
> > > On the other ends, that makes the package fat for embedded systems,
> that also
> > > makes some arbitrary runtime conflicts between packages (because they
> both
> > > provide the same symlink on the .so, while we could live with 2
> version at
> > > runtime), that leads to tons of potential issue while building
> locally, and
> > > that makes having sometime insane issues with dependency tracking. Why
> having
> > > .a, .la, .h etc in production servers? It could greatly reduce PBI
> size, etc.
> > >
> > > Personnaly I do have no strong opinion in one or another direction.
> Should we be
> > > nicer with developers? with end users? with embedded world? That is
> the question
> > > to face to decide if -devel packages is where we want to go or not.
> > >
> >
> > If we chose to go down that path, at least we should chose a different
> > name as we've used the -devel suffix for many years for developmental
> > versions.
> >
> > I must agree that it is one of the things high on my list of things that
> > irritate me with several Linux distributions but I can see the point for
> > for embedded systems as well.  But can't we have both?  Create three
> > packages, a default full package and split packages of -bin, -lib,
> > and even -doc.  My first though twas to make the full package a
> > meta-package that would install the split packages in the background,
> > but that would probably be confusing for users at the end of the day, so
> > rather just have it be a real package.
> >
> I do like that idea very much, and it is easily doable with stage :)
>

+1

If I'm going to install a FreeBSD system for normal PC use (firefox, media
player, etc) I don't need all the .h and developing stuff.

OTOH onn my machine I would like everything.

Would this increase a lot the number of packages/the time to build a new
repository?


>
> regards,
> Bapt
>
___
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"

PostgreSQL server bus error with uuid-ossp extension

[Christopher Hall]

When running PostgreSQL with the uuid-ossp extension the server fails
with signal 10 (bus error).

A simple test program that links against the /usr/local/libuuid.a works
correctly.  It call uuid_create(), uuid_make() and prints the uuid
returned.  It was compiled/linked:
  cc -o uuid-test uuid-test.c -I/usr/local/include -L/usr/local/lib
-luuid

ldd shows only libc.so.7, so the libuuid is linked in statically.

By inserting syslog() calls in the libuuid I found that PostgreSQL does
not call the libuuid uuid_create().

My first attempt at a fix was to create a uuid_create_ossp() wrapper
function to call uuid_create() in the uuid library.  Does not work with
PostgreSQL, test was still ok.  

Renaming the uuid_create() to uuid_create_ossp() and having the wrapper
called uuid_create() allows both programs to work.

It looks like the uuid_create() that is called is the FreeBSD one in
libc.  It seems like the libc is taking priority over the 
/usr/local/lib/libuuid.a

Does anyone know of a way to force the linker to chose a symbol from a
specific library?  Or perhaps force the linker to consider all symbols 
from static libraries before proceeding to libc?

-- 
Best regards.
Christopher Hall
___
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] Staging, packaging and more

[Matthew Seaman]

On 04/10/2013 08:05, Baptiste Daroussin wrote:
> On Fri, Oct 04, 2013 at 08:00:43AM +0100, Matthew Seaman wrote:
>> On 04/10/2013 07:32, Baptiste Daroussin wrote:
>>> On the other ends, that makes the package fat for embedded systems, that 
>>> also
>>> makes some arbitrary runtime conflicts between packages (because they both
>>> provide the same symlink on the .so, while we could live with 2 version at
>>> runtime), that leads to tons of potential issue while building locally, and
>>> that makes having sometime insane issues with dependency tracking. Why 
>>> having
>>> .a, .la, .h etc in production servers? It could greatly reduce PBI size, 
>>> etc.
>>>
>>> Personnaly I do have no strong opinion in one or another direction. Should 
>>> we be
>>> nicer with developers? with end users? with embedded world? That is the 
>>> question
>>> to face to decide if -devel packages is where we want to go or not.
>>
>> Can't we have the best of both worlds?
>>
>> We're already planning on creating sub-packages for eg. docs and
>> examples.  The default will be to install docs etc. sub-packages
>> automatically unless the user opts out in some way.  I imagine there
>> will be a global switch somewhere -- in pkg.conf or similar[*].
>>
>> Couldn't we work devel packages in the same way? Install by default
>> alongside the main package unless explicitly requested not to.
>>
>> I think having the capability to selectively install parts of packages
>> like this is important and useful functionality and something that will
>> be indispensible for eg. embedded platforms.  But not an option that the
>> vast majority of ordinary users will need to exercise.
>>
>>  Cheers,
>>
>>  Matthew
>>
>> [*] The precise mechanism for choosing which sub-package bits to install
>> has not yet been written.  If anyone has any bright ideas about how this
>> should all work, then I'd be interested to hear them.
>>
> 
> That is another possiblity, I do prefer Erwin's idea about the -full, but this
> also makes a lot of sense.

I think I was sufficiently vague about mechanism that Erwin's ideas are
compatible with what I wrote.  I know what I think the eventual
functioonality should be, but I don't really have any detailed ideas on
how to implement it.  Yet.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk



signature.asc
Description: OpenPGP digital signature

Re: [HEADSUP] Staging, packaging and more

[olli hauer]

On 2013-10-04 08:18, Marcus von Appen wrote:
> On, Thu Oct 03, 2013, Fernando Apesteguía wrote:
> 
>> El 03/10/2013 22:41, "Marcus von Appen"  escribió:
>>>
>>> On, Thu Oct 03, 2013, Nathan Whitehorn wrote:
>>>
 On 10/03/13 07:17, Andriy Gapon wrote:
> on 03/10/2013 11:48 Baptiste Daroussin said the following:
>> This also allows lots of new features to come:
>> - Allow to create sub-packages
>> - Allow to create debuginfo packages.
> I'd like to mention a few other possibilities along the same lines:
> - doc packages
> - examples packages
> - "devel" packages (headers, tools and other files required for
>> compiling
> dependent software, but not generally needed for an end user)

 Please no devel packages.
>>>
>>> Seconded.
>>
>> What's wrong with devel packages?
> 
> It complicates things for developers and custom software on
> FreeBSD. The typical situation that I see on most Linux platforms is a
> lot of confusion by people, why their custom software XYZ does not
> properly build - the most common answer: they forgot to install a
> tremendous amount of dev packages, containing headers, build tools and
> whatnot.
> On FreeBSD, you can rely on the fact that if you installed e.g. libGL,
> you can start building your own GL applications without the need to
> install several libGL-dev, libX11-dev, ... packages first.
> This is something, which I personally see as a big plus of the FreeBSD
> ports system and which makes FreeBSD attractive as a development platform.
> 

I share your arguments from the developer perspective, but having the
ability to do sub-packages doesn't mean until now a port will be chopped
into binary, header, man, debug, docs, examples ...

I see also a big improvement with sub-packages, there are many ports
that are build twice at the moment because we do not have sub-packages.
For example:
- (postgresql|mysql|bacula|...)-(server|client)
- apr-util (install backend support without rebuilding everything)

So sub-packages are the right thing to do, but the default sub-packages
should be discussed.

-- 
olli
___
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] Staging, packaging and more

[Baptiste Daroussin]

On Fri, Oct 04, 2013 at 08:00:43AM +0100, Matthew Seaman wrote:
> On 04/10/2013 07:32, Baptiste Daroussin wrote:
> > On the other ends, that makes the package fat for embedded systems, that 
> > also
> > makes some arbitrary runtime conflicts between packages (because they both
> > provide the same symlink on the .so, while we could live with 2 version at
> > runtime), that leads to tons of potential issue while building locally, and
> > that makes having sometime insane issues with dependency tracking. Why 
> > having
> > .a, .la, .h etc in production servers? It could greatly reduce PBI size, 
> > etc.
> > 
> > Personnaly I do have no strong opinion in one or another direction. Should 
> > we be
> > nicer with developers? with end users? with embedded world? That is the 
> > question
> > to face to decide if -devel packages is where we want to go or not.
> 
> Can't we have the best of both worlds?
> 
> We're already planning on creating sub-packages for eg. docs and
> examples.  The default will be to install docs etc. sub-packages
> automatically unless the user opts out in some way.  I imagine there
> will be a global switch somewhere -- in pkg.conf or similar[*].
> 
> Couldn't we work devel packages in the same way? Install by default
> alongside the main package unless explicitly requested not to.
> 
> I think having the capability to selectively install parts of packages
> like this is important and useful functionality and something that will
> be indispensible for eg. embedded platforms.  But not an option that the
> vast majority of ordinary users will need to exercise.
> 
>   Cheers,
> 
>   Matthew
> 
> [*] The precise mechanism for choosing which sub-package bits to install
> has not yet been written.  If anyone has any bright ideas about how this
> should all work, then I'd be interested to hear them.
> 

That is another possiblity, I do prefer Erwin's idea about the -full, but this
also makes a lot of sense.

regards,
Bapt


pgpm7jAyrox3z.pgp
Description: PGP signature

Re: [HEADSUP] Staging, packaging and more

[Baptiste Daroussin]

On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote:
> On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote:
> > > > > >
> > > > > > Please no devel packages.
> > > > >
> > > > > Seconded.
> > > >
> > > > What's wrong with devel packages?
> > > 
> > > It complicates things for developers and custom software on
> > > FreeBSD. The typical situation that I see on most Linux platforms is a
> > > lot of confusion by people, why their custom software XYZ does not
> > > properly build - the most common answer: they forgot to install a
> > > tremendous amount of dev packages, containing headers, build tools and
> > > whatnot.
> > > On FreeBSD, you can rely on the fact that if you installed e.g. libGL,
> > > you can start building your own GL applications without the need to
> > > install several libGL-dev, libX11-dev, ... packages first.
> > > This is something, which I personally see as a big plus of the FreeBSD
> > > ports system and which makes FreeBSD attractive as a development platform.
> > > 
> > 
> > On the other ends, that makes the package fat for embedded systems, that 
> > also
> > makes some arbitrary runtime conflicts between packages (because they both
> > provide the same symlink on the .so, while we could live with 2 version at
> > runtime), that leads to tons of potential issue while building locally, and
> > that makes having sometime insane issues with dependency tracking. Why 
> > having
> > .a, .la, .h etc in production servers? It could greatly reduce PBI size, 
> > etc.
> > 
> > Personnaly I do have no strong opinion in one or another direction. Should 
> > we be
> > nicer with developers? with end users? with embedded world? That is the 
> > question
> > to face to decide if -devel packages is where we want to go or not.
> > 
> 
> If we chose to go down that path, at least we should chose a different
> name as we've used the -devel suffix for many years for developmental
> versions.
> 
> I must agree that it is one of the things high on my list of things that
> irritate me with several Linux distributions but I can see the point for
> for embedded systems as well.  But can't we have both?  Create three
> packages, a default full package and split packages of -bin, -lib,
> and even -doc.  My first though twas to make the full package a
> meta-package that would install the split packages in the background,
> but that would probably be confusing for users at the end of the day, so
> rather just have it be a real package.
> 
I do like that idea very much, and it is easily doable with stage :)

regards,
Bapt


pgpEmQGb6Ykvy.pgp
Description: PGP signature

Re: [HEADSUP] Staging, packaging and more

[Matthew Seaman]

On 04/10/2013 07:32, Baptiste Daroussin wrote:
> On the other ends, that makes the package fat for embedded systems, that also
> makes some arbitrary runtime conflicts between packages (because they both
> provide the same symlink on the .so, while we could live with 2 version at
> runtime), that leads to tons of potential issue while building locally, and
> that makes having sometime insane issues with dependency tracking. Why having
> .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc.
> 
> Personnaly I do have no strong opinion in one or another direction. Should we 
> be
> nicer with developers? with end users? with embedded world? That is the 
> question
> to face to decide if -devel packages is where we want to go or not.

Can't we have the best of both worlds?

We're already planning on creating sub-packages for eg. docs and
examples.  The default will be to install docs etc. sub-packages
automatically unless the user opts out in some way.  I imagine there
will be a global switch somewhere -- in pkg.conf or similar[*].

Couldn't we work devel packages in the same way? Install by default
alongside the main package unless explicitly requested not to.

I think having the capability to selectively install parts of packages
like this is important and useful functionality and something that will
be indispensible for eg. embedded platforms.  But not an option that the
vast majority of ordinary users will need to exercise.

Cheers,

Matthew

[*] The precise mechanism for choosing which sub-package bits to install
has not yet been written.  If anyone has any bright ideas about how this
should all work, then I'd be interested to hear them.

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk



signature.asc
Description: OpenPGP digital signature

Re: new DEFAULT_VERSIONS variable

[Baptiste Daroussin]

On Fri, Oct 04, 2013 at 01:33:52AM -0500, Scot Hetzel wrote:
> On Thu, Oct 3, 2013 at 8:52 AM, Baptiste Daroussin  wrote:
> > On Thu, Oct 03, 2013 at 09:47:43AM -0400, Jerry wrote:
> >> I just saw this in UPDATING:
> >>
> >> 20131003:
> >>   AFFECTS: users of lang/python* and ports
> >>   AUTHOR: m...@freebsd.org
> >>
> >>   The default versions of lang/python* have been changed to support the
> >>   new DEFAULT_VERSIONS variable.
> >>
> >>   PYTHON_DEFAULT_VERSION, PYTHON2_DEFAULT_VERSION and
> >>   PYTHON3_DEFAULT_VERSION are deprecated. If you have set them in your
> >>   make.conf, you should change them something like
> >>
> >>   DEFAULT_VERSIONS=python=2.7 python2=2.7 python3=3.3
> >>
> >> Does this affect BERKLEY DB or Ruby also? If not, is it a planned future
> >> implementation?
> >>
> >
> > The entry as of 20130920 stated also perl5, ruby, tcltk.
> >
> > I would be glad to see bdb, postgresql, mysql, etc also being added here :)
> >
> I have USES files for berkeleydb, sqlite and firebird.  So far their
> they can be used as:
> 
> USE+= berkeleydb
> USE+= berkeleydb:41+
> 

Oh great

> They also support DEFAULT_VERSIONS, currently the syntactic for them is:
> 
> DEFAULT_VERSIONS=berkeleydb=41+ sqlite=3 firebird=25

To be consistent here if should be berkleydb=4.1 not 41+ your are setting the
default version not a version range :)

Same goes to firebird.

Concerning sqlite, does it deserves a default version? sqlite3 and sqlite2 are
different products, sqlite4 will also be a different product.
> 
> These files also support the old WITH_*_VER variables and a per port
> variable to select the version (.i.e for berkeleydb):

Please also add a WARNING+ about the WITH_*_VER usage saying that Users might
consider switching to default version.
> 
> category_portname_BDB_VER
> 
> I still have some testing to do on these 3 USES files and creating the
> postgresql.mk and mysql.mk (unless someone beats me to them ;-).

I'm expecting to review all of that, imho let's start with the 3 you have
already written, others will come, do not forgot to CC the different maintainers
about the it (acm@ for firebird, mandree@ for berkeleydb).

regards,
Bapt


pgpAuDDvKVzWB.pgp
Description: PGP signature