Re: Will 10.3 clobber my ports area?

[Dave Horsfall]

On Tue, 4 Oct 2016, Kevin Oberman wrote:

[ Reloading ports ]

> Of course. You can use portsnap(8) to do this. See 4.5 - Using the Ports 
> Collection 
>  
> for details. It's quite trivial. This also will give you the latest 
> versions of all ports.

Many thanks!  Now to pick a time to gird my loins...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Will 10.3 clobber my ports area?

[Kevin Oberman]

On Tue, Oct 4, 2016 at 8:04 PM, Dave Horsfall  wrote:

> On Mon, 3 Oct 2016, Kevin Oberman wrote:
>
> > The ports will not be touched, but some will not run on 10.3 because of
> > ABI changes in some shareable libraries. Most of the base system uses
> > versioned symbols, so will work fine, but some, usually contributed
> > code, don't. Ports that use them will need to be re-installed/rebuilt.
>
> [...]
>
> Many thanks; I'm a bit nervous, as this is my only FreeBSD server :-)
>
> I know I'm going to have trouble with the ports area anyway, because I
> seem to have corrupted it somehow (during the switch between pkg* etc),
> and I cannot seem to reload it from the CD (disc1).  Is there a way to
> fetch the entire ports tree online?
>
> Oh, this is for Joseph Mingrove: my mail log shows a message from you
> (relayed via FreeBSD.org) but there's nothing in my mailbox about it (and
> it certainly wasn't rejected).  I guess I accidentally deleted it, so
> could you please send it again?
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>

Of course. You can use portsnap(8) to do this. See 4.5 - Using the Ports
Collection

for details. It's quite trivial. This also will give you the latest
versions of all ports.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Will 10.3 clobber my ports area?

[Dave Horsfall]

On Wed, 5 Oct 2016, Dave Horsfall wrote:

> Oh, this is for Joseph Mingrove: my mail log shows a message from you 
> (relayed via FreeBSD.org) but there's nothing in my mailbox about it 
> (and it certainly wasn't rejected).  I guess I accidentally deleted it, 
> so could you please send it again?

Skip it; it would've been some unassociated message on the list...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: dependency explosions

[Mark Linimon]

On Tue, Oct 04, 2016 at 10:21:30AM +1100, Greg 'groggy' Lehey wrote:
> Is there a way to display these dependencies in a tree structure?

http://portsmon.freebsd.org/portdependencytree.py?category=x11=kde4

It's slow because I do not store dependencies in the database, so it
recalculates it on the fly.

(disclaimer: I had to go fix it because it had bitrroted due to some kind
of change in the make -V output somewhere.)

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

Re: Will 10.3 clobber my ports area?

[Dave Horsfall]

On Mon, 3 Oct 2016, Kevin Oberman wrote:

> The ports will not be touched, but some will not run on 10.3 because of 
> ABI changes in some shareable libraries. Most of the base system uses 
> versioned symbols, so will work fine, but some, usually contributed 
> code, don't. Ports that use them will need to be re-installed/rebuilt.

[...]

Many thanks; I'm a bit nervous, as this is my only FreeBSD server :-)

I know I'm going to have trouble with the ports area anyway, because I 
seem to have corrupted it somehow (during the switch between pkg* etc), 
and I cannot seem to reload it from the CD (disc1).  Is there a way to 
fetch the entire ports tree online?

Oh, this is for Joseph Mingrove: my mail log shows a message from you 
(relayed via FreeBSD.org) but there's nothing in my mailbox about it (and 
it certainly wasn't rejected).  I guess I accidentally deleted it, so 
could you please send it again?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: dependency explosions

[Julian Elischer]

On 3/10/2016 5:14 AM, Mathieu Arnold wrote:

Le 01/10/2016 à 04:35, Julian Elischer a écrit :

There is a need for a "minimum" install of a lot of packages.

Some dependencies are often optional, and can be unchecked by running
make config.


Such a 'minimum' install should probably be the default when coming in
as a dependency, as
there is an increasing tendency to configure things with all the bells
and whistles.

The bare minimum will never be the default.  The default is what will
fit most people, so that they can use our packages out of the box.

I didn't say it should be the default, I said it should be an easy to 
request option,

(without using the config screen on each of 25000 ports)
e.g. setting PORTS_CONFIG_MINIMUM before making everything.
Most ports and packages are installed not because people want them,
but because they are forced to do so by dependencies.
Giving a way to reduce the number of unrequested packages, in a simple 
way would be of great use to many many people

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

usage of openssl command in ports

[Koichiro IWAO]

Hi,

I have a question about usage of openssl command in ports.

If a port uses openssl command for example in pkg-install, how can I 
determine which openssl to use?
I think if ssl=base, /usr/bin/openssl should be used.  If ssl=openssl, 
${PREFIX}/bin/openssl should be used.

And other ssl ports.

Is there something like ${OPENSSL_CMD} or do I have to do manually like 
this?


.if ${SSL_DEFAULT} == base
OPENSSL_CMD= /usr/bin/openssl
.endif

.if ${SSL_DEFAULT} == openssl
OPENSSL_CMD= ${PREFIX}/bin/openssl
.endif

.if ${SSL_DEFAULT} == libressl
OPENSSL_CMD= "i don't know"
.endif

--
`whois vmeta.jp | nkf -w`
meta 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

multimedia/zoneminder - a message from pkg-fallout with linker error

[abi]

Hello,
I received the pkg-fallout message for port I'm maintaning, however
error is rather strange
http://beefy3.nyi.freebsd.org/data/93i386-quarterly/423181/logs/errors/zoneminder-1.30.0_3.log

/usr/local/lib/libopencv_core.so.2: undefined reference to
`std::ctype::_M_widen_init() const@GLIBCXX_3.4.11'


My poudriere system is outdated and it will compile stuff for whole
night to get to this point, maybe more experienced folks can give me
suggestion? Issue with build infrastructure itself, like glibc was
updated in the middle of the process ?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

New 2016Q4 branch

[René Ladan]

Hi,

The 2016Q4 branch has been created. It means that the next update on the
quarterly packages will be on the 2016Q4 branch.

A lot of things happened in the last three months:
- pkg 1.8.7
- New USES: grantlee kde linux
- Removed USES: (none)
- New keywords: javavm
- Removed keywords: (none)
- Default version of linux added as c6
New versions of some important ports:
- Firefox 49.0
- Firefox-esr 45.4.0esr
- Chromium 52.0.2743.116
- gcc 4.8.5
Some major behind-the-scene changes:
- PHP extensions now install their own .ini in /usr/local/etc/php
- new GH_SUBDIR variable for USE_GITHUB
- NONE license and full support for Creative Commons licenses added

Next quarterly package builds will start on Tuesday, October 4th and
should be available on your closest mirrors few days later.

For those stat nerds out there, here's what happened during the last 3
months on head:
Number of commits: 5018
Number of committers:  159
Most active committers:
 459  amdmi3
 428  marino
 263  pawel
 216  pi
 213  olgeni
 204  mat
 152  jbeich
 146  antoine
 138  wen
 133  feld
Diffstat: 15202 files changed, 233780 insertions(+), 205572 deletions(-)

and on the 2016Q3 branch:
Number of commits: 277
Number of committers:   56
Most active committers:
  36  feld
  32  jbeich
  16  brnrd
  15  mat
  15  junovitch
  12  tz
  10  rakuco
  10  pi
   9  koobs
   8  riggs
Diffstat: 866 files changed, 13781 insertions(+), 6368 deletions(-)

Regards,
René



signature.asc
Description: OpenPGP digital signature

Firefox 49.0_7,1 crashes on YouTube video and certain web pages

[Zach Metzinger]

Hello,

First off:

FreeBSD igor 9.3-RELEASE-p43 FreeBSD 9.3-RELEASE-p43 #0: Sat May 28
00:19:32 UTC 2016
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

/usr/ports/www/firefox/Makefile:
 $FreeBSD: head/www/firefox/Makefile 422956 2016-09-30 01:15:10Z
jbeich $

Normally, I'd use the defaults of DBUS and FFMPEG, but for this build
I've unchecked all configuration options except OPTIMIZE_CFLAGS, which
is enabled.

How to reproduce:

% firefox
Bus error (core dumped)

URL loaded which crashed it:

https://www.youtube.com/watch?v=HbRsWJaT4Go

Any YouTube video will work to generate the crash. I have all extensions
disabled. A fresh profile makes no difference in the behavior.

Recompiling with OPTIMIZE_CFLAGS _disabled_ and DEBUG enabled produces
an immediate crash. Logs attached.

% gdb -c firefox.core /usr/local/lib/firefox/firefox
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as
"amd64-marcel-freebsd".../home/zmetzing/.gdbinit:1: Error in sourced
command file:
Undefined command: "add-auto-load-safe-path".  Try "help".
Dwarf Error: wrong version in compilation unit header (is 4, should be
2) [in module /usr/local/lib/firefox/firefox]

Core was generated by `firefox'.
Program terminated with signal 11, Segmentation fault.
#0  0x0008020f564c in ?? ()
(gdb) bt
#0  0x0008020f564c in ?? ()
#1  0x000807dd3e71 in ?? ()
#2  0x in ?? ()
(gdb)

--- Zach
% firefox 
++DOCSHELL 0x821360b00 == 1 [pid = 51531] [id = 1]
++DOMWINDOW == 1 (0x8213ee000) [pid = 51531] [serial = 1] [outer = 0x0]
++DOMWINDOW == 2 (0x8213ee800) [pid = 51531] [serial = 2] [outer = 0x8213ee000]
++DOCSHELL 0x8225d8e00 == 2 [pid = 51531] [id = 2]
++DOMWINDOW == 3 (0x8213b5c00) [pid = 51531] [serial = 3] [outer = 0x0]
++DOMWINDOW == 4 (0x8225fec00) [pid = 51531] [serial = 4] [outer = 0x8213b5c00]
++DOMWINDOW == 5 (0x8213a0400) [pid = 51531] [serial = 5] [outer = 0x8213ee000]
[51531] WARNING: Hardware Vsync support not yet implemented. Falling back to 
software timers: file 
/export/outbox/build/usr/ports/www/firefox/work/firefox-49.0/gfx/thebes/gfxPlatform.cpp,
 line 2251
++DOCSHELL 0x824299300 == 3 [pid = 51531] [id = 3]
++DOMWINDOW == 6 (0x82426bc00) [pid = 51531] [serial = 6] [outer = 0x0]
++DOCSHELL 0x824299800 == 4 [pid = 51531] [id = 4]
++DOMWINDOW == 7 (0x823df9100) [pid = 51531] [serial = 7] [outer = 0x0]
++DOCSHELL 0x824c24a00 == 5 [pid = 51531] [id = 5]
++DOMWINDOW == 8 (0x824b20280) [pid = 51531] [serial = 8] [outer = 0x0]
++DOMWINDOW == 9 (0x824b21b00) [pid = 51531] [serial = 9] [outer = 0x824b20280]
++DOMWINDOW == 10 (0x824debc00) [pid = 51531] [serial = 10] [outer = 
0x82426bc00]
++DOMWINDOW == 11 (0x82502a600) [pid = 51531] [serial = 11] [outer = 
0x823df9100]
++DOMWINDOW == 12 (0x82502b080) [pid = 51531] [serial = 12] [outer = 
0x824b20280]

(firefox:51531): Gdk-WARNING **: gdkproperty-x11.c:325 invalid X atom: 386
[51531] ###!!! ABORT: X_ShmDetach: BadShmSeg (invalid shared segment 
parameter); 7 requests ago; id=0x3c000a9
Re-running with MOZ_X_SYNC=1 in the environment may give a more helpful 
backtrace.: file 
/export/outbox/build/usr/ports/www/firefox/work/firefox-49.0/toolkit/xre/nsX11ErrorHandler.cpp,
 line 157
#01: XRE_FreeAppData[/usr/local/lib/firefox/libxul.so +0x5335748]
#02: _XError[/usr/local/lib/libX11.so.6 +0x461b4]
#03: _XReadPad[/usr/local/lib/libX11.so.6 +0x43f04]
#04: _XReadPad[/usr/local/lib/libX11.so.6 +0x43f36]
#05: _XEventsQueued[/usr/local/lib/libX11.so.6 +0x44b51]
#06: XFlush[/usr/local/lib/libX11.so.6 +0x2652a]
#07: gdk_window_process_all_updates[/usr/local/lib/libgdk-x11-2.0.so.0 +0x43a18]
#08: gtk_container_check_resize[/usr/local/lib/libgtk-x11-2.0.so.0 +0xd1081]
#09: gdk_threads_add_timeout_seconds[/usr/local/lib/libgdk-x11-2.0.so.0 
+0x204ae]
#10: g_main_context_dispatch[/usr/local/lib/libglib-2.0.so.0 +0x48b94]
#11: g_main_context_acquire[/usr/local/lib/libglib-2.0.so.0 +0x4aba7]
#12: g_main_context_iteration[/usr/local/lib/libglib-2.0.so.0 +0x4ac67]
#13: bool __gnu_cxx::__ops::_Iter_less_val::operator()(CharRange const*, CharRange const&) 
const[/usr/local/lib/firefox/libxul.so +0x43ced17]
#14: bool __gnu_cxx::__ops::_Iter_less_val::operator()(CharRange const*, CharRange const&) 
const[/usr/local/lib/firefox/libxul.so +0x43881ff]
#15: bool __gnu_cxx::__ops::_Iter_less_val::operator()(CharRange const*, CharRange const&) 
const[/usr/local/lib/firefox/libxul.so +0x438858d]
#16: std::atomic::store(PRThread*, 
std::memory_order)[/usr/local/lib/firefox/libxul.so +0xda439e]
#17: unsigned long* std::__copy_move::__copy_m(unsigned long const*, 
unsigned long const*, unsigned 

Re: FreeBSD Port: lang/phantomjs

[Miroslav Lachman]

Mark Felder wrote on 10/04/2016 17:23:



On Mon, Oct 3, 2016, at 16:33, Miroslav Lachman wrote:

Hi,
I noticed hand full of new dependencies after PORTREVISION bump to 4
because there is a new USE_XORG=   x11

Is this really needed? Phantomjs worked for me for a long time without
any X11 libraries. We are always trying to keep our servers with minimum
ports installed. We have OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS
but now we have 7 X11 libs installed on each machine just because of
USE_XORG in Phantomjs.

Is there a way to avoid this pollution?

Kind regards

Miroslav Lachman


Per your request I have made this an option "X11" disabled by default.


Thank you Mark. I really appreciate your work and quick response!

Miroslav Lachman

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

Re: FreeBSD Port: lang/phantomjs

[Mark Felder]

On Mon, Oct 3, 2016, at 16:33, Miroslav Lachman wrote:
> Hi,
> I noticed hand full of new dependencies after PORTREVISION bump to 4 
> because there is a new USE_XORG=   x11
> 
> Is this really needed? Phantomjs worked for me for a long time without 
> any X11 libraries. We are always trying to keep our servers with minimum 
> ports installed. We have OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS 
> but now we have 7 X11 libs installed on each machine just because of 
> USE_XORG in Phantomjs.
> 
> Is there a way to avoid this pollution?
> 
> Kind regards
> 
> Miroslav Lachman

Per your request I have made this an option "X11" disabled by default.


-- 
  Mark Felder
  ports-secteam member
  f...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make clean failes to cleanup everything

[Tijl Coosemans]

On Tue, 4 Oct 2016 14:18:51 +0200 Gerhard Schmidt  wrote:
> Am 04.10.2016 um 14:03 schrieb Tijl Coosemans:
>> On Tue, 4 Oct 2016 13:36:29 +0200 Gerhard Schmidt  wrote: 
>>  
>>> Am 04.10.2016 um 12:48 schrieb Tijl Coosemans:  
 On Tue, 4 Oct 2016 09:52:23 +0200 Gerhard Schmidt  
 wrote:
> make clean fails to clean autoconf and automake.
>
> If a port uses autoconf and autoconf isn't installed on the system, it
> will be build and installed.
>
> if you run make clean after installing the port, every dependency is
> cleaned as well but not autoconf.

 Can you give an example of such a port, because we have two mechanisms
 that can pull in autoconf.
>>>
>>> It's seams to be quite a complex problem.
>>>
>>> To find out which ports causes this problem tried to build lang/php56
>>> which uses autoconf. But when I do a make clean autoconf is cleaned as
>>> well.
>>>
>>> [root@etustar /usr/ports/lang/php56]# make clean  
>>> ===>  Cleaning for autoconf-2.69_1
>>> ===>  Cleaning for php56-5.6.25_1
>>>
>>> But it also installs help2man, gmake, p5-Locale-gettext-1.06 and
>>> autoconf-wrapper-20131203 and these are not cleaned.
>>>
>>> The transcript is attached as typescript_clean
>>>
>>> now do a pkg autoremove which removes autoconf and the missed ports form
>>> the system.
>>>
>>> now try again to compile php56 and it fails
>>>
>>> the transcript is attached as typescript_unclean
>>>
>>> It seams that dependencies of dependencies are not clean. It seams that
>>> autoconf was only the most memorable one.  
>> 
>> This seems to be intended.  Make clean runs make limited-clean-depends
>> which cleans direct dependencies only.  If you want to do full recursive
>> clean you have to run make clean-depends.
> 
> I use FreeBSD since FreeBSD 2.2.5. When did this change in semantics
> happen? Why do the first layer. This is something nobody can understand.
> Either make clean should only clean the actual port. So everybody sees
> that dependencies are not cleaned (maybe a message "You should run make
> clean-depens to clean dependencies as well" should be printed if
> dependencies are touched) or do it right and clean all touched.
> 
> make clean-depends doesn't take that much more time than make clean, so
> why the change?

I've filed a bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213188
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: LICENSE questions

[Bob Eager]

On Tue, 4 Oct 2016 14:15:28 +0200
Mathieu Arnold  wrote:

> Le 04/10/2016 à 14:03, Montgomery-Smith, Stephen a écrit :
> > On 10/04/2016 06:47 AM, Mathieu Arnold wrote:  
> >> Le 04/10/2016 à 09:29, Eitan Adler a écrit :  
> >>> On 4 October 2016 at 00:25, Mathieu Arnold 
> >>> wrote:  
>  Le 04/10/2016 à 03:58, Montgomery-Smith, Stephen a écrit :  
> > Could we use USES=metaport to suppress these messages?  
>  Suppress what messages ?  
> >>> 115 .if defined(LICENSE)
> >>> 119 .else
> >>> 120 DEV_WARNING+=   "Please set LICENSE for this port"
> >>> 121 .endif  
> >> Mmmm, this is a warning, not an error, it tells you "dude, maybe
> >> you need to do this".
> >> I don't see a good reason to complicate the logic more.
> >>  
> > Because naive port maintainers like myself might think they should
> > add a LICENSE to any metaport they happen to own.
> >
> > One of the issues I have with LICENSE is that I don't see anything
> > about it in the porters handbook.  Otherwise that would be an
> > excellent place to tell maintainers of metaports not to license
> > them.  
> 
> Nobody stepped up to write a LICENSE section. I started writing
> https://reviews.freebsd.org/D56 but it is crappy.
> 
> > Also the tone is quite commanding.  If it said "Consider setting
> > LICENSE for this port", that would be more acceptable.  Really, I
> > think it should say "Please set LICENSE for this port, unless this
> > is a metaport".  
> 
> Feel free to make the message better, it is in Mk/bsd.sanity.mk.

I believe portlint uses 'Consider'. On the other hand, I had a new port
and the committer insisted I had LICENSE in there.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make clean failes to cleanup everything

[Gerhard Schmidt]

Am 04.10.2016 um 14:03 schrieb Tijl Coosemans:
> On Tue, 4 Oct 2016 13:36:29 +0200 Gerhard Schmidt  wrote:
>> Am 04.10.2016 um 12:48 schrieb Tijl Coosemans:
>>> On Tue, 4 Oct 2016 09:52:23 +0200 Gerhard Schmidt  
>>> wrote:  
 make clean fails to clean autoconf and automake.

 If a port uses autoconf and autoconf isn't installed on the system, it
 will be build and installed.

 if you run make clean after installing the port, every dependency is
 cleaned as well but not autoconf.  
>>>
>>> Can you give an example of such a port, because we have two mechanisms
>>> that can pull in autoconf.  
>>
>> It's seams to be quite a complex problem.
>>
>> To find out which ports causes this problem tried to build lang/php56
>> which uses autoconf. But when I do a make clean autoconf is cleaned as
>> well.
>>
>> [root@etustar /usr/ports/lang/php56]# make clean
>> ===>  Cleaning for autoconf-2.69_1
>> ===>  Cleaning for php56-5.6.25_1  
>>
>> But it also installs help2man, gmake, p5-Locale-gettext-1.06 and
>> autoconf-wrapper-20131203 and these are not cleaned.
>>
>> The transcript is attached as typescript_clean
>>
>> now do a pkg autoremove which removes autoconf and the missed ports form
>> the system.
>>
>> now try again to compile php56 and it fails
>>
>> the transcript is attached as typescript_unclean
>>
>> It seams that dependencies of dependencies are not clean. It seams that
>> autoconf was only the most memorable one.
> 
> This seems to be intended.  Make clean runs make limited-clean-depends
> which cleans direct dependencies only.  If you want to do full recursive
> clean you have to run make clean-depends.
> 

I use FreeBSD since FreeBSD 2.2.5. When did this change in semantics
happen? Why do the first layer. This is something nobody can understand.
Either make clean should only clean the actual port. So everybody sees
that dependencies are not cleaned (maybe a message "You should run make
clean-depens to clean dependencies as well" should be printed if
dependencies are touched) or do it right and clean all touched.

make clean-depends doesn't take that much more time than make clean, so
why the change?

Regards
Estartu



signature.asc
Description: OpenPGP digital signature

Re: LICENSE questions

[Mathieu Arnold]

Le 04/10/2016 à 14:03, Montgomery-Smith, Stephen a écrit :
> On 10/04/2016 06:47 AM, Mathieu Arnold wrote:
>> Le 04/10/2016 à 09:29, Eitan Adler a écrit :
>>> On 4 October 2016 at 00:25, Mathieu Arnold  wrote:
 Le 04/10/2016 à 03:58, Montgomery-Smith, Stephen a écrit :
> Could we use USES=metaport to suppress these messages?
 Suppress what messages ?
>>> 115 .if defined(LICENSE)
>>> 119 .else
>>> 120 DEV_WARNING+=   "Please set LICENSE for this port"
>>> 121 .endif
>> Mmmm, this is a warning, not an error, it tells you "dude, maybe you
>> need to do this".
>> I don't see a good reason to complicate the logic more.
>>
> Because naive port maintainers like myself might think they should add a
> LICENSE to any metaport they happen to own.
>
> One of the issues I have with LICENSE is that I don't see anything about
> it in the porters handbook.  Otherwise that would be an excellent place
> to tell maintainers of metaports not to license them.

Nobody stepped up to write a LICENSE section. I started writing
https://reviews.freebsd.org/D56 but it is crappy.

> Also the tone is quite commanding.  If it said "Consider setting LICENSE
> for this port", that would be more acceptable.  Really, I think it
> should say "Please set LICENSE for this port, unless this is a metaport".

Feel free to make the message better, it is in Mk/bsd.sanity.mk.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: LICENSE questions

[Montgomery-Smith, Stephen]

On 10/04/2016 06:47 AM, Mathieu Arnold wrote:
> Le 04/10/2016 à 09:29, Eitan Adler a écrit :
>> On 4 October 2016 at 00:25, Mathieu Arnold  wrote:
>>> Le 04/10/2016 à 03:58, Montgomery-Smith, Stephen a écrit :
 Could we use USES=metaport to suppress these messages?
>>> Suppress what messages ?
>> 115 .if defined(LICENSE)
>> 119 .else
>> 120 DEV_WARNING+=   "Please set LICENSE for this port"
>> 121 .endif
> 
> Mmmm, this is a warning, not an error, it tells you "dude, maybe you
> need to do this".
> I don't see a good reason to complicate the logic more.
> 

Because naive port maintainers like myself might think they should add a
LICENSE to any metaport they happen to own.

One of the issues I have with LICENSE is that I don't see anything about
it in the porters handbook.  Otherwise that would be an excellent place
to tell maintainers of metaports not to license them.

Also the tone is quite commanding.  If it said "Consider setting LICENSE
for this port", that would be more acceptable.  Really, I think it
should say "Please set LICENSE for this port, unless this is a metaport".

Stephen



signature.asc
Description: OpenPGP digital signature

Re: make clean failes to cleanup everything

[Tijl Coosemans]

On Tue, 4 Oct 2016 13:36:29 +0200 Gerhard Schmidt  wrote:
> Am 04.10.2016 um 12:48 schrieb Tijl Coosemans:
>> On Tue, 4 Oct 2016 09:52:23 +0200 Gerhard Schmidt  wrote: 
>>  
>>> make clean fails to clean autoconf and automake.
>>>
>>> If a port uses autoconf and autoconf isn't installed on the system, it
>>> will be build and installed.
>>>
>>> if you run make clean after installing the port, every dependency is
>>> cleaned as well but not autoconf.  
>> 
>> Can you give an example of such a port, because we have two mechanisms
>> that can pull in autoconf.  
> 
> It's seams to be quite a complex problem.
> 
> To find out which ports causes this problem tried to build lang/php56
> which uses autoconf. But when I do a make clean autoconf is cleaned as
> well.
> 
> [root@etustar /usr/ports/lang/php56]# make clean
> ===>  Cleaning for autoconf-2.69_1
> ===>  Cleaning for php56-5.6.25_1  
> 
> But it also installs help2man, gmake, p5-Locale-gettext-1.06 and
> autoconf-wrapper-20131203 and these are not cleaned.
> 
> The transcript is attached as typescript_clean
> 
> now do a pkg autoremove which removes autoconf and the missed ports form
> the system.
> 
> now try again to compile php56 and it fails
> 
> the transcript is attached as typescript_unclean
> 
> It seams that dependencies of dependencies are not clean. It seams that
> autoconf was only the most memorable one.

This seems to be intended.  Make clean runs make limited-clean-depends
which cleans direct dependencies only.  If you want to do full recursive
clean you have to run make clean-depends.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: LICENSE questions

[Mathieu Arnold]

Le 04/10/2016 à 09:29, Eitan Adler a écrit :
> On 4 October 2016 at 00:25, Mathieu Arnold  wrote:
>> Le 04/10/2016 à 03:58, Montgomery-Smith, Stephen a écrit :
>>> On 10/03/2016 07:34 AM, Eitan Adler wrote:
 On 3 October 2016 at 05:31, Montgomery-Smith, Stephen
  wrote:
> On 10/02/2016 05:27 PM, Eitan Adler wrote:
>> On 2 October 2016 at 14:44, Montgomery-Smith, Stephen
>>  wrote:
>>> So I have a couple of ports, science/cdf and graphics/opendx, which have
>>> licenses I can't find in Mk/bsd.licenses.db.mk.  How do I set LICENSE in
>>> those ports?
>> The other answers are correct. If the license is standard (listed
>> here: https://spdx.org/licenses/) we should add it to the main
>> database.
>>
>>> An even tougher one is math/octave-forge-optim, where each individual
>>> file has its own license.
>> A "custom" license that merely states to check the distfiles should be
>> sufficient.
> How about a meta port, whose dependencies all have different licenses?
> Something similar?
 meta-ports shouldn't define a license at all. I'm not sure we have a
 way to shut the warnings up though.
>>> Could we use USES=metaport to suppress these messages?
>> Suppress what messages ?
> 115 .if defined(LICENSE)
> 119 .else
> 120 DEV_WARNING+=   "Please set LICENSE for this port"
> 121 .endif

Mmmm, this is a warning, not an error, it tells you "dude, maybe you
need to do this".
I don't see a good reason to complicate the logic more.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: make clean failes to cleanup everything

[Gerhard Schmidt]

Am 04.10.2016 um 12:48 schrieb Tijl Coosemans:
> On Tue, 4 Oct 2016 09:52:23 +0200 Gerhard Schmidt  wrote:
>> make clean fails to clean autoconf and automake.
>>
>> If a port uses autoconf and autoconf isn't installed on the system, it
>> will be build and installed.
>>
>> if you run make clean after installing the port, every dependency is
>> cleaned as well but not autoconf.
> 
> Can you give an example of such a port, because we have two mechanisms
> that can pull in autoconf.

It's seams to be quite a complex problem.

To find out which ports causes this problem tried to build lang/php56
which uses autoconf. But when I do a make clean autoconf is cleaned as
well.

[root@etustar /usr/ports/lang/php56]# make clean
===>  Cleaning for autoconf-2.69_1
===>  Cleaning for php56-5.6.25_1

But it also installs help2man, gmake, p5-Locale-gettext-1.06 and
autoconf-wrapper-20131203 and these are not cleaned.

The transcript is attached as typescript_clean

now do a pkg autoremove which removes autoconf and the missed ports form
the system.

now try again to compile php56 and it fails

the transcript is attached as typescript_unclean

It seams that dependencies of dependencies are not clean. It seams that
autoconf was only the most memorable one.

Regards
   Estartu



typescript_clean
Description: Binary data
Script started on Tue Oct  4 13:25:51 2016
[root@etustar /usr/ports/lang/php56]# pkg autoremove 
Updating database digests format:   0%
Updating database digests format:   0%
Updating database digests format:  20%
Updating database digests format:  40%
Updating database digests format:  60%
Updating database digests format:  80%
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 5 packages:

Installed packages to be REMOVED:
autoconf-2.69_1
autoconf-wrapper-20131203
gmake-4.2.1_1
help2man-1.43.3_1
p5-Locale-gettext-1.06

Number of packages to be removed: 5

The operation will free 5 MiB.

Proceed with deinstalling packages? [y/N]: y
[1/5] Deinstalling autoconf-2.69_1...
[1/5] Deleting files for autoconf-2.69_1:   100%
[2/5] Deinstalling help2man-1.43.3_1...
[2/5] Deleting files for help2man-1.43.3_1:   100%
[3/5] Deinstalling autoconf-wrapper-20131203...
[3/5] Deleting files for autoconf-wrapper-20131203:   100%
[4/5] Deinstalling gmake-4.2.1_1...
[4/5] Deleting files for gmake-4.2.1_1:   100%
[5/5] Deinstalling p5-Locale-gettext-1.06...
[5/5] Deleting files for p5-Locale-gettext-1.06:   100%
[root@etustar /usr/ports/lang/php56]# make clean 
===>  Cleaning for php56-5.6.25_1
[root@etustar /usr/ports/lang/php56]# make 
===>  License PHP301 accepted by the user
===>  Found saved configuration for php56-5.6.25_1
===>   php56-5.6.25_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by php56-5.6.25_1 for building
===>  Extracting for php56-5.6.25_1
=> SHA256 Checksum OK for php-5.6.25.tar.xz.
===>  Patching for php56-5.6.25_1
===>  Applying FreeBSD patches for php56-5.6.25_1
===>   php56-5.6.25_1 depends on file: /usr/local/bin/autoconf-2.69 - not found
===>   autoconf-2.69_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by autoconf-2.69_1 for building
===>  Extracting for autoconf-2.69_1
=> SHA256 Checksum OK for autoconf-2.69.tar.xz.
===>  Patching for autoconf-2.69_1
===>  Applying FreeBSD patches for autoconf-2.69_1
===>   autoconf-2.69_1 depends on executable: gm4 - found
===>   autoconf-2.69_1 depends on executable: help2man - not found
===>   autoconf-2.69_1 depends on executable: help2man - not found
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/devel/autoconf
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/lang/php56
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/php56
[root@etustar /usr/ports/lang/php56]# exit 
exit

Script done on Tue Oct  4 13:26:18 2016


signature.asc
Description: OpenPGP digital signature

Re: make clean failes to cleanup everything

[Tijl Coosemans]

On Tue, 4 Oct 2016 09:52:23 +0200 Gerhard Schmidt  wrote:
> make clean fails to clean autoconf and automake.
> 
> If a port uses autoconf and autoconf isn't installed on the system, it
> will be build and installed.
> 
> if you run make clean after installing the port, every dependency is
> cleaned as well but not autoconf.

Can you give an example of such a port, because we have two mechanisms
that can pull in autoconf.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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
+-+
databases/jasperreports | 5.5.2   | 6.3.1
+-+
math/giacxcas   | 1.2.2-57| 1.2.2-89
+-+
science/psychopy| 1.83.04 | 1.84.2
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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

make clean failes to cleanup everything

[Gerhard Schmidt]

Hi

make clean fails to clean autoconf and automake.

If a port uses autoconf and autoconf isn't installed on the system, it
will be build and installed.

if you run make clean after installing the port, every dependency is
cleaned as well but not autoconf.

This should be not a problem (besides waste of discspace).

We do a pkg autoremove after installing to remove all packages that are
only build dependencies.

So the autoconf package will be removed.

Than later (days, weeks) you install another port that uses autoconf
the build brakes because autoconf is not found.

The problem is that in the autoconf ports dir everything says that
autoconf is already installed and make install does return without doing
anything an without failure (as expected).

A make clean in the autoconf dir does fix the porblem.

So why doesn't make clean of a port that uses autoconf don't do a make
clean in the autoconf port.

Regards
   Estartu



signature.asc
Description: OpenPGP digital signature

weird messages, source unidentified

[Scott Bennett]

 For many moons now, I've been seeing messages like the following, but
emitted by many programs, not just by cmake.  I've indented all example
message lines below by ">".

>cmake: environment corrupt; missing value for QT_IM_MO

I don't know what causes them or how to get rid of them.
 I've also seen many ports fail to build with sequences of messages like
the ones below, which always involve ccache.

>CMake Error at 
>/usr/local/share/cmake/Modules/CMakeSystemSpecificInformation.cmake:36 
>(include):
>  include called with wrong number of arguments.  include() only takes one
>  file.
>Call Stack (most recent call first):
>  CMakeLists.txt:68 (project)
>
>
>System is unknown to cmake, create:
>Platform/sh: environment corrupt; missing value for QT_IM_MO
>FreeBSD to use this system, please send your config file to 
>cm...@www.cmake.org so it can be added to cmake

 Another common type of message sequences looks like this.

>-- Check for working CXX compiler: /usr/local/libexec/ccache/c++ -- broken
>CMake Error at /usr/local/share/cmake/Modules/CMakeTestCXXCompiler.cmake:54 
>(message):
>  The C++ compiler "/usr/local/libexec/ccache/c++" is not able to compile a
>  simple test program.
>
>  It fails with the following output:
>
>   
>
>  
>
>  CMake will not be able to correctly generate this project.
>Call Stack (most recent call first):
>  CMakeLists.txt:68 (project)
>
 Over time, messages like the kinds shown above have led to the
need to use many "-x" options on a "portmaster -a" command.  If someone
could feed me a clue or three as to how to correct whatever these
programs are complaining about and how to fix the problem(s), I would be
grateful.  Thanks much in advance to anyone with helpful suggestions.
 Meanwhile I suppose I should see about restoring the earlier version
of graphics/opencv{,-core} from before they were renamed and broken.  Sigh.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: LICENSE questions

[Eitan Adler]

On 4 October 2016 at 00:25, Mathieu Arnold  wrote:
> Le 04/10/2016 à 03:58, Montgomery-Smith, Stephen a écrit :
>> On 10/03/2016 07:34 AM, Eitan Adler wrote:
>>> On 3 October 2016 at 05:31, Montgomery-Smith, Stephen
>>>  wrote:
 On 10/02/2016 05:27 PM, Eitan Adler wrote:
> On 2 October 2016 at 14:44, Montgomery-Smith, Stephen
>  wrote:
>> So I have a couple of ports, science/cdf and graphics/opendx, which have
>> licenses I can't find in Mk/bsd.licenses.db.mk.  How do I set LICENSE in
>> those ports?
> The other answers are correct. If the license is standard (listed
> here: https://spdx.org/licenses/) we should add it to the main
> database.
>
>> An even tougher one is math/octave-forge-optim, where each individual
>> file has its own license.
> A "custom" license that merely states to check the distfiles should be
> sufficient.
 How about a meta port, whose dependencies all have different licenses?
 Something similar?
>>> meta-ports shouldn't define a license at all. I'm not sure we have a
>>> way to shut the warnings up though.
>> Could we use USES=metaport to suppress these messages?
>
> Suppress what messages ?

115 .if defined(LICENSE)
119 .else
120 DEV_WARNING+=   "Please set LICENSE for this port"
121 .endif


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

Re: LICENSE questions

[Mathieu Arnold]

Le 04/10/2016 à 03:58, Montgomery-Smith, Stephen a écrit :
> On 10/03/2016 07:34 AM, Eitan Adler wrote:
>> On 3 October 2016 at 05:31, Montgomery-Smith, Stephen
>>  wrote:
>>> On 10/02/2016 05:27 PM, Eitan Adler wrote:
 On 2 October 2016 at 14:44, Montgomery-Smith, Stephen
  wrote:
> So I have a couple of ports, science/cdf and graphics/opendx, which have
> licenses I can't find in Mk/bsd.licenses.db.mk.  How do I set LICENSE in
> those ports?
 The other answers are correct. If the license is standard (listed
 here: https://spdx.org/licenses/) we should add it to the main
 database.

> An even tougher one is math/octave-forge-optim, where each individual
> file has its own license.
 A "custom" license that merely states to check the distfiles should be
 sufficient.
>>> How about a meta port, whose dependencies all have different licenses?
>>> Something similar?
>> meta-ports shouldn't define a license at all. I'm not sure we have a
>> way to shut the warnings up though.
> Could we use USES=metaport to suppress these messages?

Suppress what messages ?

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: math/R slave ports and shared library

[Fernando Herrero Carrón]

2016-10-04 4:59 GMT+02:00 Joseph Mingrone :

> After some surgery, math/R is in more manageable shape.  But, the surgery
> broke two slave ports, math/libR and math/libRmath.  They have each been
> marked broken since June or July and I posted to ports@ about deleting
> them, but didn't get a response.
>
>
This is great work indeed. The huge Makefile was a pain to work with,
mainly because of the slave ports, so this is greatly appreciated.


> math/libRmath
> I'm not sure how widely used math/libRmath is today, but it's still
> described in R's main installation document (https://cran.r-project.org/
> doc/manuals/r-release/R-admin.html#The-standalone-Rmath-library).  It
> *should* be straightforward to just incorporate math/libRmath's four files
> into math/R and then delete math/libRmath.  The directory for libRmath is
> under WRKSRC, but it's not included in the main Makefile, so I'd have to
> either patch the main Makefile or do something with post-build and
> post-install.  Is this palatable?
>
> ---
> post-build:
> ${SETENV} ${MAKE_ENV} ${MAKE_CMD} -C ${WRKSRC}/src/nmath/standalone
>
> post-install
> .for f in libRmath.a libRmath.so libRmath.so.${RMATH_SOVERSION}
> ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/${f}
> ${STAGEDIR}/lib/
> .endfor
> ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/Rmath.h
> ${STAGEDIR}/include/
> ---
>
>
I would be very surprised (though it cannot be excluded) to see C programs
using libRmath. There are some questions on StackOverflow about developing
and distributing libRmath, so this cannot be 100% excluded [2]. The de
facto standard for R/C++ interoperability is Rcpp [1]. I am not sure
whether Rcpp can be built standalone, but it being an R package, I suspect
it needs a full R installation. Its main use is for R to include C++ code,
no the other way around.

All in all, I don't see much use for a standalone libRmath, but it cannot
be excluded. The truth being told, I would expect newer scientific software
coming from python+scipy+numpy rather than from R embedded in C/C++.

math/libR
> Right now, unlike upstream, math/R's shared library option is turned on by
> default.  This was done only in late June because a dependency,
> math/rkward-kde4, required it.  Upstream turns it off, for the reasons
> described in [1].  I'm inclined to remove the libR option from math/R's
> OPTIONS_DEFAULT and resurrect math/libR (or maybe math/R-libR by using
> PKGNAMESUFFIX) as a very simple slave port that just installs math/R with
> that option on.  math/rkward-kde4 could then depend on math/libR.  One
> issue is that, I believe, R's installed packages (packages installed from
> within R) and many of R's dependencies would have to be rebuilt after
> turning off the libR option.
>
>
I have done some little benchmarking myself with and without dynamic libR
and have not seen any noticeable differences in performance (though I have
left it off to be safe), but don't take this as conclusive, more testing
should be done. Packages certainly do need to be rebuilt after switching
from dynamic libR to static. I can't tell what happens the other way
around. Ports-installed packages could be automatically recompiled, but
recompiling user-installed packages is a different story.

I think having two separate installations, whose packages would be mutually
exclusive is too dangerous and too easy for the user to mess up. I can
perform some more extensive benchmarks and see if having it enabled by
default really hurts.

In my opinion, performancewise I would only leave LTO and OPENMP as default
options. Even long double is not guaranteed to provide better precision
than double and it is very possible (per theory and per experience) that it
hinders performance [3].

Kind regards,
Fernando

[1] http://gallery.rcpp.org/articles/r-function-from-c++/
[2]
http://stackoverflow.com/questions/5393257/including-r-standalone-library-in-a-c-source-tree
[3] http://www.cplusplus.com/forum/beginner/34088/#msg183895
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: dependency explosions

[Kurt Jaeger]

Hi!

> > The problem is to add code to allow variants is complex and needs
> > engineering power.

> But regarding the 
> changes that would be required to only allow other variants, why do you 
> say it would be complex? Wouldn't that be only a change in pkg so that 
> it can handle dependencies per set properly?

It's my gut feeling, nothing more. I have not looked at the code
of pkg or the ports framework. It's only that I'm playing around
with dependency trees for the last quarter of a century, that's
feeding my gut feeling here 8-}

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: dependency explosions

[Grzegorz Junka]

On 04/10/2016 05:09, Kurt Jaeger wrote:

Hi!


Right now, we build packages for
[9,10,11,12]x[amd64,i386]x[head,quarterly], that's 16 different sets,
and we mostly manage to build them over and over again, every two days.
Imagine how long it would take to build 320 sets.

You are trying to take that into extreme to ridicule this as an option.

I think the scenario that "if we had variants, other users would
request other variants" is likely and the number of sets to build
really would explode like that. It's not to ridicule that option.

The problem is to add code to allow variants is complex and needs
engineering power.



OK, as I mentioned, I was wondering if that would be possible. So, 
apparently, it would, but would require changes in the code. Forget 
about other variants that users may want to propose - if they want other 
variants then they can take it on and maintain. But regarding the 
changes that would be required to only allow other variants, why do you 
say it would be complex? Wouldn't that be only a change in pkg so that 
it can handle dependencies per set properly?


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