looking for a committer

[Koichiro IWAO]

Can someone look at these?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212625
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213150

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

Re: dependency explosions

[Kurt Jaeger]

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.

-- 
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: Will 10.3 clobber my ports area?

[Kevin Oberman]

On Mon, Oct 3, 2016 at 7:29 PM, Dave Horsfall  wrote:

> Assuming the binary upgrade from 9.3 to 10.3 is "clean" i.e. it won't
> clobber any of my local stuff (this is my only FreeBSD server), what will
> happen to the ports area?  Left alone, saved, or overwritten with/without
> any local chnages?
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>

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.

It is recommended that, when moving between major versions, all ports be
re-installed, but most won't need it. The tricky part is finding those that
need rebuilding. While mixing ports and packages is nto generally
recommended, I would upgrade all ports that have default configurations be
re-installed from packages. Those that have custom configurations will, of
course need to be re-built.
--
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"

Will 10.3 clobber my ports area?

[Dave Horsfall]

Assuming the binary upgrade from 9.3 to 10.3 is "clean" i.e. it won't 
clobber any of my local stuff (this is my only FreeBSD server), what will 
happen to the ports area?  Left alone, saved, or overwritten with/without 
any local chnages?

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

math/R slave ports and shared library

[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.

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/
---

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.

Opinions?

Joseph

[1] "--enable-R-shlib causes the make process to build R as a dynamic (shared) 
library, typically called libR.so, and link the main R executable R.bin against 
that library. This can only be done if all the code (including system 
libraries) can be compiled into a dynamic library, and there may be a 
performance [47] penalty. So you probably only want this if you will be using 
an application which embeds R. Note that C code in packages installed on an R 
system linked with --enable-R-shlib is linked against the dynamic library and 
so such packages cannot be used from an R system built in the default way. 
Also, because packages are linked against R they are on some OSes also linked 
against the dynamic libraries R itself is linked against, and this can lead to 
symbol conflicts."

[47] We have measured 15-20% on i686 Linux and around 10% on x86_64 Linux.


signature.asc
Description: PGP signature

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.

but you can never really know the effect.
there should be a use minimum environment variable and as I said, the 
minimum is usually what is required for build dependencies.
And the minimum install may require less "other" packages thus 
reducing the explosion.





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.



___
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

[Montgomery-Smith, Stephen]

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

[Miroslav Lachman]

Greg 'groggy' Lehey wrote on 10/04/2016 01:21:

[...]


Chromium?  Opera?  Emacs?  Both OpenOffice and LibreOffice?

I don't know if this always happens, but there's an issue here.  I
have a few unfinished thoughts about how it could occur, but so far
all I can confirm is that there is an issue.

Is there a way to display these dependencies in a tree structure?


You can use ports-mgmt/pkg_tree

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: dependency explosions

[Greg 'groggy' Lehey]

On Monday,  3 October 2016 at 20:41:08 -0400, Baho Utot wrote:
>
> On 10/03/16 19:21, Greg 'groggy' Lehey wrote:
>> On Monday,  3 October 2016 at 14:14:13 +0200, Mathieu Arnold wrote:
>>> Le 01/10/2016 à 04:35, Julian Elischer a écrit :
 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.
>> Not necessarily disagreeing with you, but I recently installed a new
>> version of firefox, and I was amazed by the number and nature of the
>> dependencies.  It totalled 497 MB, including:
>>
>>Fetching chromium-52.0.2743.116_1.txz: .. done
>>Fetching opera-12.16_6.txz: .. done
>>Fetching apache-openoffice-4.1.2_9.txz: .. done
>>Fetching libreoffice-5.0.6_3.txz: .. done
>>Fetching gimp-2.8.18,2.txz: . done
>>Fetching hugin-2016.2.0.txz: .. done
>>Fetching mplayer-1.3.0.20160912_1.txz: .. done
>>Fetching samba42-4.2.14.txz: .. done
>>Fetching emacs24-24.5_3,3.txz: .. done
>>
>> Chromium?  Opera?  Emacs?  Both OpenOffice and LibreOffice?
>>
>> I don't know if this always happens, but there's an issue here.  I
>> have a few unfinished thoughts about how it could occur, but so far
>> all I can confirm is that there is an issue.
>>
>> Is there a way to display these dependencies in a tree structure?
>
> $ make -C /usr/ports/www/firefox all-depends-list
> /usr/ports/ports-mgmt/pkg
> /usr/ports/devel/nspr
> /usr/ports/devel/gmake
> ...

That isn't a tree.  It also doesn't show the dependencies I mentioned
above.  And yes, I ran it locally.  On reflection, it's probably
because firefox requires an update to a library used by other
packages, so they need to be upgraded too.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: dependency explosions

[Baho Utot]

On 10/03/16 19:21, Greg 'groggy' Lehey wrote:

On Monday,  3 October 2016 at 14:14:13 +0200, Mathieu Arnold wrote:

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

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.

Not necessarily disagreeing with you, but I recently installed a new
version of firefox, and I was amazed by the number and nature of the
dependencies.  It totalled 497 MB, including:

   Fetching chromium-52.0.2743.116_1.txz: .. done
   Fetching opera-12.16_6.txz: .. done
   Fetching apache-openoffice-4.1.2_9.txz: .. done
   Fetching libreoffice-5.0.6_3.txz: .. done
   Fetching gimp-2.8.18,2.txz: . done
   Fetching hugin-2016.2.0.txz: .. done
   Fetching mplayer-1.3.0.20160912_1.txz: .. done
   Fetching samba42-4.2.14.txz: .. done
   Fetching emacs24-24.5_3,3.txz: .. done

Chromium?  Opera?  Emacs?  Both OpenOffice and LibreOffice?

I don't know if this always happens, but there's an issue here.  I
have a few unfinished thoughts about how it could occur, but so far
all I can confirm is that there is an issue.

Is there a way to display these dependencies in a tree structure?

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

$ make -C /usr/ports/www/firefox all-depends-list
/usr/ports/ports-mgmt/pkg
/usr/ports/devel/nspr
/usr/ports/devel/gmake
/usr/ports/devel/gettext-tools
/usr/ports/converters/libiconv
/usr/ports/devel/gettext-runtime
/usr/ports/print/indexinfo
/usr/ports/security/nss
/usr/ports/archivers/zip
/usr/ports/databases/sqlite3
/usr/ports/devel/ncurses
/usr/ports/devel/pkgconf
/usr/ports/devel/binutils
/usr/ports/math/gmp
/usr/ports/math/mpfr
/usr/ports/devel/bison
/usr/ports/devel/m4
/usr/ports/lang/perl5.20
/usr/ports/devel/libevent2
/usr/ports/devel/autoconf
/usr/ports/misc/help2man
/usr/ports/devel/p5-Locale-gettext
/usr/ports/devel/autoconf-wrapper
/usr/ports/devel/automake
/usr/ports/devel/automake-wrapper
/usr/ports/devel/libtool
/usr/ports/audio/soundtouch
/usr/ports/print/harfbuzz
/usr/ports/devel/gobject-introspection
/usr/ports/graphics/cairo
/usr/ports/x11/xcb-util-renderutil
/usr/ports/devel/xorg-macros
/usr/ports/x11/libxcb
/usr/ports/devel/libcheck
/usr/ports/x11/xcb-proto
/usr/ports/lang/python27
/usr/ports/devel/libffi
/usr/ports/misc/dejagnu
/usr/ports/lang/expect
/usr/ports/lang/tcl86
/usr/ports/textproc/libxml2
/usr/ports/devel/libpthread-stubs
/usr/ports/textproc/libxslt
/usr/ports/security/libgcrypt
/usr/ports/security/libgpg-error
/usr/ports/x11/libXau
/usr/ports/x11/xproto
/usr/ports/x11/libXdmcp
/usr/ports/x11/xcb-util
/usr/ports/graphics/libGL
/usr/ports/devel/makedepend
/usr/ports/devel/libclc
/usr/ports/devel/llvm37
/usr/ports/textproc/py-sphinx
/usr/ports/devel/py-Jinja2
/usr/ports/devel/py-setuptools27
/usr/ports/textproc/py-MarkupSafe
/usr/ports/devel/py-babel
/usr/ports/devel/py-pytz
/usr/ports/textproc/py-docutils
/usr/ports/devel/py-six
/usr/ports/devel/py-pytest
/usr/ports/devel/py-py
/usr/ports/devel/py-mock
/usr/ports/devel/py-pbr
/usr/ports/devel/py-pip
/usr/ports/devel/py-pytest-capturelog
/usr/ports/devel/py-pytest-timeout
/usr/ports/devel/py-pytest-xdist
/usr/ports/devel/py-setuptools_scm
/usr/ports/sysutils/py-execnet
/usr/ports/misc/py-pexpect
/usr/ports/devel/py-virtualenv
/usr/ports/devel/py-scripttest
/usr/ports/devel/py-pretend
/usr/ports/devel/py-freezegun
/usr/ports/devel/py-dateutil
/usr/ports/devel/py-nose
/usr/ports/databases/py-sqlite3
/usr/ports/devel/git
/usr/ports/textproc/xmlto
/usr/ports/shells/bash
/usr/ports/misc/getopt
/usr/ports/textproc/docbook-xsl
/usr/ports/textproc/xmlcatmgr
/usr/ports/textproc/docbook
/usr/ports/textproc/docbook-sgml
/usr/ports/textproc/iso8879
/usr/ports/textproc/docbook-xml
/usr/ports/textproc/xmlcharent
/usr/ports/textproc/sdocbook-xml
/usr/ports/print/libpaper
/usr/ports/www/w3m
/usr/ports/devel/boehm-gc
/usr/ports/devel/libatomic_ops
/usr/ports/textproc/asciidoc
/usr/ports/lang/python2
/usr/ports/ftp/curl
/usr/ports/security/ca_root_nss
/usr/ports/lang/p5-Error
/usr/ports/textproc/expat2
/usr/ports/devel/pcre
/usr/ports/devel/cvsps
/usr/ports/mail/p5-Net-SMTP-SSL
/usr/ports/security/p5-IO-Socket-SSL
/usr/ports/security/p5-Net-SSLeay
/usr/ports/devel/p5-Test-Exception
/usr/ports/devel/p5-Sub-Uplevel
/usr/ports/devel/p5-Test-NoWarnings
/usr/ports/devel/p5-Test-Simple
/usr/ports/devel/p5-Test-Warn
/usr/ports/www/p5-Mozilla-CA
/usr/ports/net/p5-IO-Socket-IP
/usr/ports/devel/p5-Test-Pod
/usr/ports/net/p5-Socket
/usr/ports/security/p5-Authen-SASL

Re: dependency explosions

[Greg 'groggy' Lehey]

On Monday,  3 October 2016 at 14:14:13 +0200, Mathieu Arnold wrote:
> Le 01/10/2016 à 04:35, Julian Elischer a écrit :
>> 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.

Not necessarily disagreeing with you, but I recently installed a new
version of firefox, and I was amazed by the number and nature of the
dependencies.  It totalled 497 MB, including:

  Fetching chromium-52.0.2743.116_1.txz: .. done
  Fetching opera-12.16_6.txz: .. done
  Fetching apache-openoffice-4.1.2_9.txz: .. done
  Fetching libreoffice-5.0.6_3.txz: .. done
  Fetching gimp-2.8.18,2.txz: . done
  Fetching hugin-2016.2.0.txz: .. done
  Fetching mplayer-1.3.0.20160912_1.txz: .. done
  Fetching samba42-4.2.14.txz: .. done
  Fetching emacs24-24.5_3,3.txz: .. done

Chromium?  Opera?  Emacs?  Both OpenOffice and LibreOffice?

I don't know if this always happens, but there's an issue here.  I
have a few unfinished thoughts about how it could occur, but so far
all I can confirm is that there is an issue.

Is there a way to display these dependencies in a tree structure?

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

FreeBSD Port: lang/phantomjs

[Miroslav Lachman]

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

[Miroslav Lachman]

Miroslav Lachman wrote on 10/03/2016 15:29:

Grzegorz Junka wrote on 10/03/2016 15:11:


On 03/10/2016 12:14, 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.



Shouldn't all packages default to noX dependencies? If I am not mistaken
FreeBSD is predominantly a server-side system, with X running only
occasionally (I am running X but I compile all packages with poudriere).


I agree. Many ports have X and -nox11 (like ImageMagick-nox11 or
open-vm-tools-nox11) but there are still some without nox11 variant.

But X11 is not the only one dependency problem.
I think that dependency changes should be better tracked and examined
before commit changes to ports tree.


I am really tired of it. Now I realized that another port is 
unconditionally pulling hand full of new X11 dependecies which where not 
used before ant this was just PORTREVISION bump. Not new version with 
new functionality.


When this will stop?

# pkg info -r -d phantomjs-2.0.0_3
phantomjs-2.0.0_3
Depends on :
fontconfig-2.12.1,1
png-1.6.23
icu-55.1,1
freetype2-2.6.3
jpeg-turbo-1.4.2

# pkg inf -r -d phantomjs-2.0.0_5
phantomjs-2.0.0_5
Depends on :
fontconfig-2.12.1,1
png-1.6.23
libX11-1.6.3,1
freetype2-2.6.3
icu-57.1,1
jpeg-turbo-1.4.2

libX11 needs following packages

xproto-7.0.28
libXdmcp-1.1.2
libpthread-stubs-0.3_6
libXau-1.0.8_3
libxcb-1.11.1
kbproto-1.0.7


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: dependency explosions

[Grzegorz Junka]

On 03/10/2016 14:48, Mathieu Arnold wrote:

Le 03/10/2016 à 16:29, Grzegorz Junka a écrit :

On 03/10/2016 14:11, Mike Clarke wrote:

On Mon, 3 Oct 2016 13:11:43 +
Grzegorz Junka  wrote:


Shouldn't all packages default to noX dependencies? If I am not
mistaken
FreeBSD is predominantly a server-side system, with X running only
occasionally

I'd disagree with that. I don't know whether or not the majority of
FreeBSD installations are servers or personal computers but the chances
are that the majority of server installations will have relatively few
packages installed whereas most PC's are likely to make use of far
more packages and are also likely to be using X. Building from ports
to get the required options would be a much bigger task for these
installations than it would be for the servers.


I have been wondering if it would be possible to have two distinct set
of packages compiled automatically, one tailored for X and one for the
console. It seems that requirements of both environment are quite
opposite. The server-side requires small amount of packages without X
because it wants to run the system headless, as long as possible and
without interruptions and restarts. Whereas the X/PC environment
always wants to have everything latest and newest. In the Linux world
they would just create a new distribution, even in the BSD world there
is PC-BSD/TrueOS. But we have ports and can re-use the same base for
two distinctive set of packages. I don't believe we can create
pre-compiled packages for FreeBSD in such a way, that both camps are
happy (which this thread is one of many signs of).

The FreeBSD project cannot provide more than one set of packages. If we
went that way, we would end up having to provide, say, [with X, without
X]x[apache 2.2, apache 2.4]x[php56, php70]x[postgresql 9.3, 9.4, 9.5,
9.6]x[insert 5 flavors of mysql]x[openssl, libressl]... I'm sure I can
find other kind of options, and that is already 320 sets.
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. 
You can't possibly build 320 sets, even if you had enough build 
machines, because each set would need to contain incompatible packages. 
If you choose, say, php56 as the default, then you can't possibly 
install a package that depends on php70. The amount of combinations 
would expand exponentially. It would be like having 320 different 
incompatible sets of packages to test.


The same with packages that depend on X. Sure, if you install 
emacs-nox11 you can still install other packages that depend on X, but 
at some point it would start to break, e.g. you wouldn't be able to 
install ImageMagick-nox11 and ImageMagick at the same time.


What I proposed is to have two sets of packages, one for server use 
(noX, maybe other defaults) and one for desktop use (X, multimedia, 
maybe other defaults). You usually don't switch a machine that's working 
as a desktop workstation to suddenly become a rack server in some data 
center.


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"

Re: dependency explosions

[Mathieu Arnold]

Le 03/10/2016 à 16:57, Matthieu Volat a écrit :
> On Mon, 3 Oct 2016 14:29:27 +
> Grzegorz Junka  wrote:
>
>> On 03/10/2016 14:11, Mike Clarke wrote:
>>> On Mon, 3 Oct 2016 13:11:43 +
>>> Grzegorz Junka  wrote:
>>>
 Shouldn't all packages default to noX dependencies? If I am not mistaken
 FreeBSD is predominantly a server-side system, with X running only
 occasionally
>>> I'd disagree with that. I don't know whether or not the majority of
>>> FreeBSD installations are servers or personal computers but the chances
>>> are that the majority of server installations will have relatively few
>>> packages installed whereas most PC's are likely to make use of far
>>> more packages and are also likely to be using X. Building from ports
>>> to get the required options would be a much bigger task for these
>>> installations than it would be for the servers.
>>>
>> I have been wondering if it would be possible to have two distinct set 
>> of packages compiled automatically, one tailored for X and one for the 
>> console. It seems that requirements of both environment are quite 
>> opposite. The server-side requires small amount of packages without X 
>> because it wants to run the system headless, as long as possible and 
>> without interruptions and restarts. Whereas the X/PC environment always 
>> wants to have everything latest and newest. In the Linux world they 
>> would just create a new distribution, even in the BSD world there is 
>> PC-BSD/TrueOS. But we have ports and can re-use the same base for two 
>> distinctive set of packages. I don't believe we can create pre-compiled 
>> packages for FreeBSD in such a way, that both camps are happy (which 
>> this thread is one of many signs of).
>>
>> Grzegorz
> That must be somehow possible and even extensible to be something like 
> macports variants

We have works in the pipes to do variants like package builds, yes, but
the work is currently stalled because it breaks every tools we have.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: dependency explosions

[Matthieu Volat]

On Mon, 3 Oct 2016 14:29:27 +
Grzegorz Junka  wrote:

> On 03/10/2016 14:11, Mike Clarke wrote:
> > On Mon, 3 Oct 2016 13:11:43 +
> > Grzegorz Junka  wrote:
> >
> >> Shouldn't all packages default to noX dependencies? If I am not mistaken
> >> FreeBSD is predominantly a server-side system, with X running only
> >> occasionally
> > I'd disagree with that. I don't know whether or not the majority of
> > FreeBSD installations are servers or personal computers but the chances
> > are that the majority of server installations will have relatively few
> > packages installed whereas most PC's are likely to make use of far
> > more packages and are also likely to be using X. Building from ports
> > to get the required options would be a much bigger task for these
> > installations than it would be for the servers.
> >
> 
> I have been wondering if it would be possible to have two distinct set 
> of packages compiled automatically, one tailored for X and one for the 
> console. It seems that requirements of both environment are quite 
> opposite. The server-side requires small amount of packages without X 
> because it wants to run the system headless, as long as possible and 
> without interruptions and restarts. Whereas the X/PC environment always 
> wants to have everything latest and newest. In the Linux world they 
> would just create a new distribution, even in the BSD world there is 
> PC-BSD/TrueOS. But we have ports and can re-use the same base for two 
> distinctive set of packages. I don't believe we can create pre-compiled 
> packages for FreeBSD in such a way, that both camps are happy (which 
> this thread is one of many signs of).
> 
> Grzegorz

That must be somehow possible and even extensible to be something like macports 
variants, except with binary package support (macports localy build packages 
when user defined option differs from default); but this would take signifiant 
space and processing power...

On the other hand, setting OPTIONS_UNSET to include X11 is quite trivial. I 
would expect a server administrator to be more proficient in that kind of 
settings...

PS. I agree with the multiplication of dependencies, but I see them as the 
result of nowaday FOSS ecosystem practices rather than port management issues.

-- 
Matthieu Volat 


pgpE7Ij5qzGwY.pgp
Description: OpenPGP digital signature

Re: dependency explosions

[Mathieu Arnold]

Le 03/10/2016 à 16:29, Grzegorz Junka a écrit :
>
> On 03/10/2016 14:11, Mike Clarke wrote:
>> On Mon, 3 Oct 2016 13:11:43 +
>> Grzegorz Junka  wrote:
>>
>>> Shouldn't all packages default to noX dependencies? If I am not
>>> mistaken
>>> FreeBSD is predominantly a server-side system, with X running only
>>> occasionally
>> I'd disagree with that. I don't know whether or not the majority of
>> FreeBSD installations are servers or personal computers but the chances
>> are that the majority of server installations will have relatively few
>> packages installed whereas most PC's are likely to make use of far
>> more packages and are also likely to be using X. Building from ports
>> to get the required options would be a much bigger task for these
>> installations than it would be for the servers.
>>
>
> I have been wondering if it would be possible to have two distinct set
> of packages compiled automatically, one tailored for X and one for the
> console. It seems that requirements of both environment are quite
> opposite. The server-side requires small amount of packages without X
> because it wants to run the system headless, as long as possible and
> without interruptions and restarts. Whereas the X/PC environment
> always wants to have everything latest and newest. In the Linux world
> they would just create a new distribution, even in the BSD world there
> is PC-BSD/TrueOS. But we have ports and can re-use the same base for
> two distinctive set of packages. I don't believe we can create
> pre-compiled packages for FreeBSD in such a way, that both camps are
> happy (which this thread is one of many signs of).

The FreeBSD project cannot provide more than one set of packages. If we
went that way, we would end up having to provide, say, [with X, without
X]x[apache 2.2, apache 2.4]x[php56, php70]x[postgresql 9.3, 9.4, 9.5,
9.6]x[insert 5 flavors of mysql]x[openssl, libressl]... I'm sure I can
find other kind of options, and that is already 320 sets.
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.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: dependency explosions

[Grzegorz Junka]

On 03/10/2016 14:11, Mike Clarke wrote:

On Mon, 3 Oct 2016 13:11:43 +
Grzegorz Junka  wrote:


Shouldn't all packages default to noX dependencies? If I am not mistaken
FreeBSD is predominantly a server-side system, with X running only
occasionally

I'd disagree with that. I don't know whether or not the majority of
FreeBSD installations are servers or personal computers but the chances
are that the majority of server installations will have relatively few
packages installed whereas most PC's are likely to make use of far
more packages and are also likely to be using X. Building from ports
to get the required options would be a much bigger task for these
installations than it would be for the servers.



I have been wondering if it would be possible to have two distinct set 
of packages compiled automatically, one tailored for X and one for the 
console. It seems that requirements of both environment are quite 
opposite. The server-side requires small amount of packages without X 
because it wants to run the system headless, as long as possible and 
without interruptions and restarts. Whereas the X/PC environment always 
wants to have everything latest and newest. In the Linux world they 
would just create a new distribution, even in the BSD world there is 
PC-BSD/TrueOS. But we have ports and can re-use the same base for two 
distinctive set of packages. I don't believe we can create pre-compiled 
packages for FreeBSD in such a way, that both camps are happy (which 
this thread is one of many signs of).


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"

Re: dependency explosions

[Mike Clarke]

On Mon, 3 Oct 2016 13:11:43 +
Grzegorz Junka  wrote:

> Shouldn't all packages default to noX dependencies? If I am not mistaken 
> FreeBSD is predominantly a server-side system, with X running only 
> occasionally

I'd disagree with that. I don't know whether or not the majority of
FreeBSD installations are servers or personal computers but the chances
are that the majority of server installations will have relatively few
packages installed whereas most PC's are likely to make use of far
more packages and are also likely to be using X. Building from ports
to get the required options would be a much bigger task for these
installations than it would be for the servers.

-- 
Mike Clarke
___
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 03/10/2016 à 14:31, Montgomery-Smith, Stephen a écrit :
> 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 don't install files, they are empty shells, so they do not
really have a license.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: dependency explosions

[Miroslav Lachman]

Grzegorz Junka wrote on 10/03/2016 15:11:


On 03/10/2016 12:14, 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.



Shouldn't all packages default to noX dependencies? If I am not mistaken
FreeBSD is predominantly a server-side system, with X running only
occasionally (I am running X but I compile all packages with poudriere).


I agree. Many ports have X and -nox11 (like ImageMagick-nox11 or 
open-vm-tools-nox11) but there are still some without nox11 variant.


But X11 is not the only one dependency problem.
I think that dependency changes should be better tracked and examined 
before commit changes to ports tree.


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: dependency explosions

[Grzegorz Junka]

On 03/10/2016 12:14, 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.



Shouldn't all packages default to noX dependencies? If I am not mistaken 
FreeBSD is predominantly a server-side system, with X running only 
occasionally (I am running X but I compile all packages with poudriere).


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

Re: LICENSE questions

[Eitan Adler]

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.



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

[Montgomery-Smith, Stephen]

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?
___
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: What is SONAME in port builds?

[Mathieu Arnold]

Le 02/10/2016 à 21:07, Montgomery-Smith, Stephen a écrit :
> On 10/02/2016 10:29 AM, Montgomery-Smith, Stephen wrote:
>> I am trying to build the port graphics/opendx, and at the qa stage it says:
>>
>> Error: /usr/local/dx/bin_freebsd/builder is linked to
>> /usr/local/lib/libcdf.so which does not have a SONAME.
>> science/cdf needs to be fixed.
>>
>> What does this mean, and how do I fix it?
> I came up with "a" solution:
>
> https://svnweb.freebsd.org/ports?view=revision=423146

It is a good solution, yes. The check is there because pkg will not
register shlib dependencies if the .so do not have a soname. This is a
problem because if the library gets changed and is no longer
incompatible with the previous one, you do not have a soname to check,
and pkg will not know that all its dependencies need to be reinstalled.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: dependency explosions

[Mathieu Arnold]

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.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Google Code as an upstream is gone

[Julian H. Stacey]

David Demelier wrote:
> 2016-09-29 17:36 GMT+02:00 Mathieu Arnold :
> > Le 29/09/2016 à 17:03, Christian Weisgerber a écrit :
> >> On 2016-09-14, Mathieu Arnold  wrote:
> >>
> >>> Google Code has been deprecated[1] since March 2015, and read-only since
> >>> August 2015, giving time to software developers to move their
> >>> development some place else. All the distribution files that still use
> >>> solely googlecode.com as their source have been marked BROKEN today in
> >>> r422140[2], as they are not fetchable.
> >>>
> >>> Most software have moved to some other place (mostly on github), all you
> >>> have to do is figure out where and update your ports accordingly.
> >> Or you can simply replace
> >>
> >> ${PROJECT}.googlecode.com/files/
> >>
> >> with
> >>
> >> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/${PROJECT}/
> >>
> >> which could have trivially been done in bsd.sites.mk.
> >>
> >
> > No you cannot.
> >
> > Before marking all the ports BROKEN, I started by changing the
> > MASTER_SITE_GOOGLE_CODE entry to make things fetchable again. The
> > problem with that approach is that it is just hiding the fact that the
> > software have not been updated for more than a year and will never be
> > again. The goal of marking all those ports broken is that people will go
> > and look for where the software went after google code, so that it gets
> > updated when new releases go out.
> >
> > If the software has not been moved to some other place, (it takes about
> > 30 seconds to click the automatic migration to github thing, and it is
> > usually done within the hour,) since march 2015, it is most likely
> > abandoned and should not be kept in the ports tree.
> >
> 
> As many have pointed out here, abandoned does not mean it's not usable
> anymore. There are dozen of ports or software not maintained anymore
> and still work because they do not require maintenance.
> 
> Marking as broken is a bit hurried IMHO. We should provide a longer
> expiration date by keeping distfiles to our FreeBSD mirrors for a
> while until the upstream moves to somewhere else. Of course, we should
> also bulk mail the maintainer to tell that the port will expire and
> distfiles removed at the time.
> 
> Regards,
> 
> -- 
> Demelier David

BROKEN was useful when introduced, but is too crude, needs improving.
Setting BROKEN= when merely distfile is not at URLs is not true,
it's not broken & will make if distfile is in local distfiles/.

BROKEN is itself part Broken, a liability, as once someone sets it, 
it encourages others to later delete working ports.

BROKEN needs to be improved/ split.
FreeBSD should seek to _automatically_ encourage those who still have a
distfile in local distfiles/ to contribute it back to Internet.

eg create a new assert NO_DISTFILE=true that does something approx like
launch in a subshell code below, called with a - prepended to Makefile line,
so it does not break the make of next port entry from SUBDIR +=

.if !defined(DISTFILES_MISSING_CHECK_ONLY_SILENTLY)
 echo "Distfile[s] lost from Internet, Checking if you have them localy."
.endif
 make fetch # Not checksum, cos even wrong checksums can sometimes work.
 echo "Distfile[s] lost from Internet, You still have, Please give a copy to:"
 echo "`grep MAINTAINER Makefile` and or po...@freebsd.org"
 make checksum
 echo "Distfile[s] even have right checksums! Definately give us a copy!"
 echo "`pwd` has Distfile[s] lost from Internet, Please give FreeBSD a copy!" \
| mail `whoami`

Do Not turn whole block of by default as noisey, cos we need it to
run by default, so people with local distfiles see it, & return distfiles

Above is a crude. I could improve & create a patch for bsd.port.mk
but as people may likely suggest improvements + its guarded by 
FreeBSD_MAINTAINER= port...@freebsd.org
better that they do it ?.

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#stolen_votes
___
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
+-+
games/lordsawar | 0.3.0   | 0.3.1
+-+
net/wpa_gui | 2.5 | 2.6
+-+
security/wpa_supplicant | 2.5 | 2.6
+-+
textproc/dblatex| 0.3.7   | 0.3.9
+-+


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"