FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, 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"
Re: Google Code as an upstream is gone
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"
Re: dependency explosions
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: What is SONAME in port builds?
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&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: LICENSE questions
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: LICENSE questions
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: dependency explosions
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: dependency explosions
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: LICENSE questions
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
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: dependency explosions
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
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
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
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
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
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"
FreeBSD Port: lang/phantomjs
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
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
Re: dependency explosions
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 /usr/ports/security/p
Re: dependency explosions
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
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: LICENSE questions
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
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"
math/R slave ports and shared library
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
Will 10.3 clobber my ports area?
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"
Re: Will 10.3 clobber my ports area?
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"
Re: dependency explosions
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"
looking for a committer
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
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"
Re: dependency explosions
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: math/R slave ports and shared library
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"
