Re: pkg_version confused by architecutre in package name
On Thu, Jul 06, 2006 at 02:45:45AM +0200, [LoN]Kamikaze wrote: > I normally run the command > # pkg_version -Iv | grep \< > before running 'portupgrade -a', to see what's going to happen. This time I > got the following output: > > diablo-jdk-freebsd6.i386.1.5.0.07.00 < needs updating (index has > 1.5.0.07.00) > > It seems that the tool is confused by the i386 in the package name. Actually I think it's confused by the fact that the package name is "diablo-jdk" and the version is "freebsd6.i386.1.5.0.07.00". That's just plain bogus. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpkVCCvThRPg.pgp Description: PGP signature
Re: pkg_version confused by architecutre in package name
On Thu, Jul 06, 2006 at 11:01:43AM +0200, [LoN]Kamikaze wrote: > Brooks Davis wrote: > > On Thu, Jul 06, 2006 at 02:45:45AM +0200, [LoN]Kamikaze wrote: > >> I normally run the command > >> # pkg_version -Iv | grep \< > >> before running 'portupgrade -a', to see what's going to happen. This time > >> I got the following output: > >> > >> diablo-jdk-freebsd6.i386.1.5.0.07.00 < needs updating (index has > >> 1.5.0.07.00) > >> > >> It seems that the tool is confused by the i386 in the package name. > > > > Actually I think it's confused by the fact that the package name is > > "diablo-jdk" and the version is "freebsd6.i386.1.5.0.07.00". That's > > just plain bogus. > > > So who is at fault? The ports infrastructure or the FreeBSD foundation? I don't know. How did you install it? -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgps3bn4aLXgi.pgp Description: PGP signature
Re: pkg_version confused by architecutre in package name
On Thu, Jul 06, 2006 at 06:04:37PM +0200, [LoN]Kamikaze wrote: > > Brooks Davis wrote: > > On Thu, Jul 06, 2006 at 11:01:43AM +0200, [LoN]Kamikaze wrote: > >> Brooks Davis wrote: > >>> On Thu, Jul 06, 2006 at 02:45:45AM +0200, [LoN]Kamikaze wrote: > >>>> I normally run the command > >>>> # pkg_version -Iv | grep \< > >>>> before running 'portupgrade -a', to see what's going to happen. This > >>>> time I got the following output: > >>>> > >>>> diablo-jdk-freebsd6.i386.1.5.0.07.00 < needs updating (index has > >>>> 1.5.0.07.00) > >>>> > >>>> It seems that the tool is confused by the i386 in the package name. > >>> Actually I think it's confused by the fact that the package name is > >>> "diablo-jdk" and the version is "freebsd6.i386.1.5.0.07.00". That's > >>> just plain bogus. > >>> > >> So who is at fault? The ports infrastructure or the FreeBSD foundation? > > > > I don't know. How did you install it? > > # pkg_add diablo-jdk-freebsd6.i386.1.5.0.07.00.tbz It definitly installs correctly if you use the port instead of the package. It looks like the package is incorrect. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgplx56G4loyc.pgp Description: PGP signature
Re: RFC: Merging X11BASE to LOCALBASE
On Wed, Jul 12, 2006 at 05:34:22PM -0500, John Merryweather Cooper wrote:
> Dejan Lesjak wrote:
> >Hello,
> >
> >There were a couple of debates already concerning /usr/X11R6 as prefix for
> >X11 ports and a bunch of other ports that currently by default install
> >there. Quite some people were, when creating a new port that depends on
> >X11, wandering whether to put it in X11BASE or LOCALBASE. More than once a
> >question of whether the prefix /usr/X11R6 should be just dropped or at
> >least only retained for core X11 distribution. With the upcoming X.org 7.x
> >ports there is perhaps the opportunity to do the prefix merger along that.
> >Moving X11 prefix to LOCALBASE would simplify above dilemma. It would be
> >also more similar to where linux distributions are going (at least Gentoo,
> >Debian and Fedora deprecated /usr/X11R6 in favour of /usr which, while
> >not /usr/local is the location of where all packages install - depending
> >on X11 or not). If I remember correctly from previous discussions, it
> >would be more convenient to people with separate mounts for installed
> >packages as well. /usr/local is also the default value for --prefix
> >configure option for X.org packages.
> >So it is general intention to go with /usr/local or rather ${LOCALBASE} as
> >prefix for X11 ports. If anyone feels that this is horribly wrong, please
> >speak up.
> >
> >On behalf of x11 team,
> >Dejan
> >
> What impact (if any) would the doubling or tripling of the number of
> files in ./bin have on searching along PATH? Would we be shooting
> ourselves in the foot if we did this?
Since /usr/X11R6/bin is already in the default path I don't see how
it would make any difference.
-- Brooks
pgpVpVna4LYuM.pgp
Description: PGP signature
Re: RFC: Merging X11BASE to LOCALBASE
On Wed, Jul 12, 2006 at 04:48:39PM -0700, Fred Cox wrote: > Those man pages for whatis are pretty radically > different in size. Maybe they are mergeable, but > there's going to be a fair amount of work doing that > for all possible conflicts. They are generated files see makewhatis(1). There will probably be a few real conflicts, but it's unlikely to be a serious issue. -- Brooks pgp3OrQHEhYmY.pgp Description: PGP signature
Re: RFC: Merging X11BASE to LOCALBASE
On Wed, Jul 12, 2006 at 08:59:08PM -0400, Joe Marcus Clarke wrote: > On Wed, 2006-07-12 at 19:56 -0500, Brooks Davis wrote: > > On Wed, Jul 12, 2006 at 04:48:39PM -0700, Fred Cox wrote: > > > Those man pages for whatis are pretty radically > > > different in size. Maybe they are mergeable, but > > > there's going to be a fair amount of work doing that > > > for all possible conflicts. > > > > They are generated files see makewhatis(1). There will probably be a > > few real conflicts, but it's unlikely to be a serious issue. > > It may be more serious than you think. Currently, GNOME and KDE will > conflict with each other if this move happens. We will have to either > come up with a new pseudo-port to handle common files, or find some > other way of consolidating things. That should be a pretty easy thing to check out. Just installing GNOME and KDE on the same machine and then running: "cat /var/db/pkg/*/+CONTENTS | sort | uniq -d" would give a list of all potential duplicate files. Running pkg_which on those with both prefixes would give you all the conflicts after screening out generated files. It's certainly a real issue, but i double it's all that bad. It's not as though other projects haven't solved some version of this. -- Brooks pgp4zait5RHqa.pgp Description: PGP signature
Re: What the hell is going on with mplayer?
On Thu, Jul 13, 2006 at 04:35:15PM +0200, Alexander Leidinger wrote: > Quoting Heino Tiedemann <[EMAIL PROTECTED]> (from Thu, 13 Jul > 2006 15:23:07 +0200): > > >I just wanted to so a simple ??portupgrade mplayer-gtk??, and see what > >habens: > > > > > >** Detected a package name change: mplayer-gtk (multimedia/mplayer) > >-> 'mplayer-gtk2-esound' (multimedia/mplayer) > >^^^ > >What a surprise, name change. Not mentioned in UPDATING > > Does it needs to be mentioned? portupgrade is able to handle it > without *special* instructions in UPDATING. This port should not set its name based on configured (or in this case automagicaly detected and thus ever changing) features unless it does so as part of a slave port. This has been a minor annoyance for ages. The port should be named mplayer, always. -- Brooks pgpejLjUa2cfQ.pgp Description: PGP signature
Re: Installation directory best practices
On Thu, Jul 13, 2006 at 07:36:19PM +0100, Shaun Amott wrote:
> On Thu, Jul 13, 2006 at 01:27:20PM +0330, Babak Farrokhi wrote:
> > I wonder if there is any particular guideline for installation of web based
> > application (the ports which install web pages, like www/wordpress,
> > www/serendipity or databases/phpmyadmin).
>
> The guidelines we have now are that most ports should install into
> www/${PORTNAME}; this means default/unsecured scripts are not visible
> until they have been configured, and also avoids using a directory which
> is server (apache?) specific.
>
> I think www/data/${PORTNAME} is probably acceptable if the script is
> simple and/or needs no configuration.
Since www/data is usually www/data-dist this would also be wrong.
-- Brooks
pgpq0EuGSP0pV.pgp
Description: PGP signature
Re: RFC: Merging X11BASE to LOCALBASE
On Fri, Jul 14, 2006 at 12:33:22PM -0700, Doug Barton wrote: > Dejan Lesjak wrote: > > On Friday 14 July 2006 08:58, Maxim Sobolev wrote: > >> What's the gain? > > > > I believe I mentioned some of gains in first mail. There is also the > > benefit > > of less divergence to upstreams as ./configure scripts of various ports > > use /usr/local as default prefix, but more importantly as modular X.org is > > becoming more widespread there is tendency of various packagers (for > > example > > Linux distributions already mentioned) to install all packages under same > > prefix. We expect that if we follow that trend, we would make maintainers > > and > > users' lives a bit easier in the long run. > > Note, I am still making up my mind about whether what you're proposing is a > good idea or not, so I'm not intending this as a criticism. However, the > argument you propose above as a benefit for the move is completely specious. > Our ports are supposed to be prefix-clean no matter what the defaults in the > distributed software are, and no matter what prefix the user chooses. Thus > (other than ports which are broken now which need fixing anyway), the only > thing this move will do is ADD work for maintainers (at least in the short > run), it will not make anyone's life easier in this area. > > I would also like to reinforce Maxim's point here, since I think it's > getting lost in the shuffle. The burden to the users is NOT just > reinstalling, which with modern tools like portmaster or portupgrade should > be pretty painless, if not time consuming. There is also the burden to our > users of editing config files, firefox app preferences, etc. etc. Some of > these can be handled automatically by the ports, many of them cannot. Assuming we deal with all the conflicting ports in the first round I don't fully buy this argument. If most people can simply upgrade the ports in question then "rm -rf /usr/X11RC && ln -s /usr/local /usr/X11R6" will take care of config files. That's admittedly a large assumption, but I don't think it's all that unreasonable. I think the argument for this change is that the use of X11BASE is pretty much random so it's no longer serving any useful purpose and the lack of consistency is a minor negative since you never know where an X related port will end up without reading the Makefile. -- Brooks pgpMApltmypaI.pgp Description: PGP signature
Re: makewhatis from ports
On Wed, Jul 19, 2006 at 11:52:26AM +0200, [LoN]Kamikaze wrote: > Sergey Matveychuk wrote: > > [LoN]Kamikaze wrote: > >> I've got a Makefile where I install man pages int PREFIX/man/man1 and the > >> ports system nicely compresses them, but it does not make them available > >> for whatis. Should I run makewhatis PREFIX/man manually or is there a way > >> this is supposed to be done? The Porter's Handbook chapter 5.9 does not > >> mention whatis. > > > > It will be done with weekly script 320.whatis. > > I think we have no practice to do it when a port is installed. > > > > Thanks for the reply. > > That means I don't have to take care of it, still it would make more > sense to let the ports take care of it. If we're going to do it, setting MAN variables should cause it to happen in bsd.port.mk rather than having it done adhoc. -- Brooks pgpoHk3bpONic.pgp Description: PGP signature
Re: Checksum mismatch for print/teTeX-texmf
On Wed, Jul 26, 2006 at 10:24:17AM -0500, Paul Schmehl wrote: > Running portupgrade with current ports from cvs, I got this failure - > print/teTeX-texmf (teTeX-texmf-3.0_3) (checksum mismatch). I also had > checksum mismatchs for multimedia/mplayer-skins, but I was able to get > past that by rm'ing the config and using only the default skin. > > Anyone know anything about these two problems? Have the maintainers > been informed? I've often had problems with the teTeX-texmf dist files. Deleting and redownloading them usually works (as annoying as that is.) -- Brooks pgpqmRiwgBLYi.pgp Description: PGP signature
Re: extract both bz2 and gz files from distfiles
On Mon, Aug 07, 2006 at 03:12:06AM +0400, Boris Samorodov wrote: > Hi! > > > We have got a port (lang/gnat-gcc34) which has both bz2 and gz > distfiles. As for 5.x+ extracting is gone automagically. But not at > 4.x. Well, at 4.x extracting may be done for example, by using > USE_BZIP2 knob and doing gunzipping at after-extract:. > > Does someone know a better solution? > Does we have examples at our ports? You could replicated the 4.x behavior with a dependancy on bsdtar from archivers/libarchive and set TAR=bsdtar. -- Brooks pgpVScNeVinrd.pgp Description: PGP signature
Re: extract both bz2 and gz files from distfiles
On Mon, Aug 07, 2006 at 11:56:46PM +0400, Boris Samorodov wrote:
> On Mon, 7 Aug 2006 14:37:25 -0400 Kris Kennaway wrote:
> > On Mon, Aug 07, 2006 at 03:12:06AM +0400, Boris Samorodov wrote:
>
> > > We have got a port (lang/gnat-gcc34) which has both bz2 and gz
> > > distfiles. As for 5.x+ extracting is gone automagically. But not at
> > > 4.x. Well, at 4.x extracting may be done for example, by using
> > > USE_BZIP2 knob and doing gunzipping at after-extract:.
> > >
> > > Does someone know a better solution?
> > > Does we have examples at our ports?
>
> > Use a do-extract that extracts all distfiles or EXTRACT_ONLY with
> > post-extract that extracts the other ones.
>
> Thanks, Kris. I'm trying to test (actually, to find an 4.x system)
> some broken ports with a patch(es) which includes (thanks Brooks):
> -
> .if ${OSVERSION} < 50
> EXTRACT_DEPENDS+= bsdtar:${PORTSDIR}/archivers/libarchive
> TAR=/usr/local/bin/bsdtar
> .endif
> -
>
> To me that seems a good solution.
I'd suggest using not using an absolute path in the TAR definition
since the dependency check doesn't and using 502111 as the version since
that's the first version bump after the initial bsdtar import. Not that
we really need to worry about such early 5.x release, but it's more
correct.
-- Brooks
pgp6G10vXe5fT.pgp
Description: PGP signature
Re: extract both bz2 and gz files from distfiles
On Mon, Aug 07, 2006 at 10:56:18PM +0200, Pav Lucistnik wrote:
> Boris Samorodov p??e v ?t 08. 08. 2006 v 00:24 +0400:
> > On Mon, 7 Aug 2006 15:12:03 -0500 Brooks Davis wrote:
> > > On Mon, Aug 07, 2006 at 11:56:46PM +0400, Boris Samorodov wrote:
> > > > On Mon, 7 Aug 2006 14:37:25 -0400 Kris Kennaway wrote:
> > > > > On Mon, Aug 07, 2006 at 03:12:06AM +0400, Boris Samorodov wrote:
> > > >
> > > > > > We have got a port (lang/gnat-gcc34) which has both bz2 and gz
> > > > > > distfiles. As for 5.x+ extracting is gone automagically. But not at
> > > > > > 4.x. Well, at 4.x extracting may be done for example, by using
> > > > > > USE_BZIP2 knob and doing gunzipping at after-extract:.
> > > > > >
> > > > > > Does someone know a better solution?
> > > > > > Does we have examples at our ports?
> > > >
> > > > > Use a do-extract that extracts all distfiles or EXTRACT_ONLY with
> > > > > post-extract that extracts the other ones.
> > > >
> > > > Thanks, Kris. I'm trying to test (actually, to find an 4.x system)
> > > > some broken ports with a patch(es) which includes (thanks Brooks):
> > > > -
> > > > .if ${OSVERSION} < 50
> > > > EXTRACT_DEPENDS+= bsdtar:${PORTSDIR}/archivers/libarchive
> > > > TAR=/usr/local/bin/bsdtar
> > > > .endif
> > > > -
> > > >
> > > > To me that seems a good solution.
> >
> > > I'd suggest using not using an absolute path in the TAR definition
> > > since the dependency check doesn't and using 502111 as the version since
> > > that's the first version bump after the initial bsdtar import. Not that
> > > we really need to worry about such early 5.x release, but it's more
> > > correct.
> >
> > Thanks again, Brooks. The patch will include (if Kris won't complain):
> > -
> > .if ${OSVERSION} < 502111
> > EXTRACT_DEPENDS+= bsdtar:${PORTSDIR}/archivers/libarchive
> > TAR=bsdtar
> > .endif
> > -
>
> Would writing own do-extract: target be better alternative?
It seems list unnecessicary work to me. The nice thing about setting to
TAR bsdtar is that you get the same behavior on all releases. Obviously
a do-extract target would work, but this way we can get rid of the
compatability code at some point in the future. In some ways I think
we should consider alwasy depending on bsdtar in older versions just to
eliminate the differences and to reduce cross branch compatability
issues now that less and less people can test on 4.x systems.
-- Brooks
pgpvq3yEzcTer.pgp
Description: PGP signature
Re: extract both bz2 and gz files from distfiles
On Mon, Aug 07, 2006 at 05:03:57PM -0400, Kris Kennaway wrote:
> On Tue, Aug 08, 2006 at 12:24:49AM +0400, Boris Samorodov wrote:
> > On Mon, 7 Aug 2006 15:12:03 -0500 Brooks Davis wrote:
> > > On Mon, Aug 07, 2006 at 11:56:46PM +0400, Boris Samorodov wrote:
> > > > On Mon, 7 Aug 2006 14:37:25 -0400 Kris Kennaway wrote:
> > > > > On Mon, Aug 07, 2006 at 03:12:06AM +0400, Boris Samorodov wrote:
> > > >
> > > > > > We have got a port (lang/gnat-gcc34) which has both bz2 and gz
> > > > > > distfiles. As for 5.x+ extracting is gone automagically. But not at
> > > > > > 4.x. Well, at 4.x extracting may be done for example, by using
> > > > > > USE_BZIP2 knob and doing gunzipping at after-extract:.
> > > > > >
> > > > > > Does someone know a better solution?
> > > > > > Does we have examples at our ports?
> > > >
> > > > > Use a do-extract that extracts all distfiles or EXTRACT_ONLY with
> > > > > post-extract that extracts the other ones.
> > > >
> > > > Thanks, Kris. I'm trying to test (actually, to find an 4.x system)
> > > > some broken ports with a patch(es) which includes (thanks Brooks):
> > > > -
> > > > .if ${OSVERSION} < 50
> > > > EXTRACT_DEPENDS+= bsdtar:${PORTSDIR}/archivers/libarchive
> > > > TAR=/usr/local/bin/bsdtar
> > > > .endif
> > > > -
> > > >
> > > > To me that seems a good solution.
> >
> > > I'd suggest using not using an absolute path in the TAR definition
> > > since the dependency check doesn't and using 502111 as the version since
> > > that's the first version bump after the initial bsdtar import. Not that
> > > we really need to worry about such early 5.x release, but it's more
> > > correct.
> >
> > Thanks again, Brooks. The patch will include (if Kris won't complain):
> > -
> > .if ${OSVERSION} < 502111
> > EXTRACT_DEPENDS+= bsdtar:${PORTSDIR}/archivers/libarchive
> > TAR=bsdtar
> > .endif
> > -
>
> Actually I think you do need the absolute path, since it wont always
> be set in the environment (think crontabs, etc). The correct
> specification would be ${LOCALBASE}/bin/bsdtar.
My thought was that the dependency check will fail if it's not in the
path so there's no point in having the absolute path in the TAR part.
-- Brooks
pgpBasjbeN2yu.pgp
Description: PGP signature
Re: extract both bz2 and gz files from distfiles
On Mon, Aug 07, 2006 at 11:20:55PM +0200, Pav Lucistnik wrote:
> Brooks Davis p??e v po 07. 08. 2006 v 16:06 -0500:
> > On Mon, Aug 07, 2006 at 10:56:18PM +0200, Pav Lucistnik wrote:
> > > Boris Samorodov p??e v ?t 08. 08. 2006 v 00:24 +0400:
> > > > On Mon, 7 Aug 2006 15:12:03 -0500 Brooks Davis wrote:
> > > > > On Mon, Aug 07, 2006 at 11:56:46PM +0400, Boris Samorodov wrote:
> > > > > > On Mon, 7 Aug 2006 14:37:25 -0400 Kris Kennaway wrote:
> > > > > > > On Mon, Aug 07, 2006 at 03:12:06AM +0400, Boris Samorodov wrote:
> > > > > >
> > > > > > > > We have got a port (lang/gnat-gcc34) which has both bz2 and gz
> > > > > > > > distfiles. As for 5.x+ extracting is gone automagically. But
> > > > > > > > not at
> > > > > > > > 4.x. Well, at 4.x extracting may be done for example, by using
> > > > > > > > USE_BZIP2 knob and doing gunzipping at after-extract:.
> > > > > > > >
> > > > > > > > Does someone know a better solution?
> > > > > > > > Does we have examples at our ports?
> > > > > >
> > > > > > > Use a do-extract that extracts all distfiles or EXTRACT_ONLY with
> > > > > > > post-extract that extracts the other ones.
> > > > > >
> > > > > > Thanks, Kris. I'm trying to test (actually, to find an 4.x system)
> > > > > > some broken ports with a patch(es) which includes (thanks Brooks):
> > > > > > -
> > > > > > .if ${OSVERSION} < 50
> > > > > > EXTRACT_DEPENDS+= bsdtar:${PORTSDIR}/archivers/libarchive
> > > > > > TAR=/usr/local/bin/bsdtar
> > > > > > .endif
> > > > > > -
> > > > > >
> > > > > > To me that seems a good solution.
> > > >
> > > > > I'd suggest using not using an absolute path in the TAR definition
> > > > > since the dependency check doesn't and using 502111 as the version
> > > > > since
> > > > > that's the first version bump after the initial bsdtar import. Not
> > > > > that
> > > > > we really need to worry about such early 5.x release, but it's more
> > > > > correct.
> > > >
> > > > Thanks again, Brooks. The patch will include (if Kris won't complain):
> > > > -
> > > > .if ${OSVERSION} < 502111
> > > > EXTRACT_DEPENDS+= bsdtar:${PORTSDIR}/archivers/libarchive
> > > > TAR=bsdtar
> > > > .endif
> > > > -
> > >
> > > Would writing own do-extract: target be better alternative?
> >
> > It seems list unnecessicary work to me. The nice thing about setting to
> > TAR bsdtar is that you get the same behavior on all releases. Obviously
> > a do-extract target would work, but this way we can get rid of the
> > compatability code at some point in the future. In some ways I think
> > we should consider alwasy depending on bsdtar in older versions just to
> > eliminate the differences and to reduce cross branch compatability
> > issues now that less and less people can test on 4.x systems.
>
> So you prefer imposing yet another dependency on the user is less evil
> than adding few lines of extra code in port Makefile?
Since we're talking about rather small dependency and supporting a
branch porters are not required support, absolutely. I think it's
much better to keep the Makefile smaller than to worry about a minor
dependency on a barely supported branch. At this point in 4.x's life
we should give making maintenance reasonable much more weight than making
the lives of people who can't or won't upgrade easy. If we were talking
about a bigger dependency or a supported branch my view would likely be
different.
-- Brooks
pgpYzdGwawQ99.pgp
Description: PGP signature
Re: using svn to fetch for ports (yet again!)
On Wed, Nov 04, 2009 at 08:23:02PM +0200, Eitan Adler wrote: > I have a small patch to bsd.port.mk which would allow a port to > replace its do-fetch with a svn export of a /specific revision/ of a > remote repo. > > I know there have been some attempts at trying this before and from > what I've been reading I addressed some of the major concerns: > 1) Past attempts didn't include a basic implementation. > 2) Past attempts didn't allow for a specific revision number and thus > possibly causing security issues > 3) Subversion does not have to be part of the base system for my patch to work > > Allowing the port to fetch from svn is beneficial for a number of > reasons some of which are listed below > 1) Many project's only or main means of distribution is svn (I'm > thinking of mplayer) > 2) It is easier for the port maintainer to update the port > 3) It is easy for a user to quickly switch versions (outside of the > ports system) without the need for lots o knowledge about the ports > system > > Some of the problems: > 1) Its harder if not impossible for freeBSD to mirror the port's > source (I'm sure I could easily code a svn-to-tarball script but who > knows if the svn build servers want svn) > 2) Many users may want the program they are installing but not svn > 3) What about SCM's other than svn? I'd much rather see this used as something that reduced the amount of code required for maintainers to build tarballs from SVN. For example something similar in spirit to what I've done in devel/llvm-devel. That means mirroring or otherwise transfering the source around is possible. There will likely be some objections to putting maintainer functionality in bsd.port.mk, but I think it would be useful enough in this case. Alternativly we could formalize the process a bit and put something Tools/scripts. -- Brooks pgpjc0sHXsmth.pgp Description: PGP signature
Re: using svn to fetch for ports (yet again!)
On Thu, Nov 05, 2009 at 10:17:10PM +0200, Eitan Adler wrote: > > I'd much rather see this used as something that reduced the amount of > > code required for maintainers to build tarballs from SVN. ?For example > > something similar in spirit to what I've done in devel/llvm-devel. ?That > > means mirroring or otherwise transfering the source around is possible. > Would a patch like the one below be what you are looking for? > (Note that I didn't test this patch that much...) Not quite. What I like about overriding do-fetch is that you can do: make -DBOOTSTRAP makesum to both generate the tarball and generate the checksum. You can then go on and build the port like you would otherwise. I also find the auto determination of the latest revision to be very useful. I probably would't include the scp to freefall bit. That's excessivly evil. :) > > There will likely be some objections to putting maintainer functionality > > in bsd.port.mk, but I think it would be useful enough in this case. > > Alternativly we could formalize the process a bit and put something > > Tools/scripts. > > While I have no trouble writing a script to perform these tasks this > is something that I'd like to see available to end users. > I think it would useful to allow users to do something like > SVN_REV=1436 make install clean > and thus fetch from svn and install newer/older versions. I think the users would rather build a tarball in that case so they don't have to download everything again when they start tweaking and testing patches. One option might be to set NO_CHECKSUM if the user overrides the revision. You'd need another switch so the maintainer can use makesum in that case, but that should be easy enough. -- Brooks pgpWz9xyDICJp.pgp Description: PGP signature
Re: RFC: svn for make fetch
On Sun, Nov 08, 2009 at 07:07:25PM +, Marcin Wisnicki wrote:
> On Sun, 08 Nov 2009 17:31:57 +0200, Eitan Adler wrote:
>
> > I was hoping to get a bit more of a response to a recent posting of mine
> > with regard to using svn to fetch files for ports My proposal:
> > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html A
> > summary of what has been going on:
> > http://wiki.freebsd.org/EitanAdler/ports-svn
> >
> > This is something that more than 2 people should have an input on
>
> Unless you solve plist problem (and completely automated plist generation
> would be a fantastic thing to have!), such functionality should not be
> available (or at least advertised) to end-users.
> You may also consider moving it to separate file (bsd.maintainer.mk).
>
> I don't quite get the logic behind ${USER} == ${SVN_USER} conditional.
> Why do you assume that if my username is the same as username for svn
> checkout then I want to upload snapshot to freefall ? In addition not
> every maintainer has @freebsd.org account. Uploading should be
> customizable (maybe UPLOAD_CMD - like FETCH_CMD).
It's a generalization of an ugly hack I put in my llvm-devel port. I
don't really think it should be part of the base.
-- Brooks
pgp9vsVWHpiAN.pgp
Description: PGP signature
Re: RFC: svn for make fetch
On Mon, Nov 09, 2009 at 02:28:52PM -0800, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Eitan Adler wrote: > > I was hoping to get a bit more of a response to a recent posting of > > mine with regard to using svn to fetch files for ports > > My proposal: > > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html > > A summary of what has been going on: > > http://wiki.freebsd.org/EitanAdler/ports-svn > > > > This is something that more than 2 people should have an input on > > Just my $0.02 but I think it would be great if we can do: > > - "make fetch" would prefer using a pre-packaged tarball, but fallback > to a svn/whatever checkout with a specific revision number, then > generate a tarball from the export. > - "make checksum" would check the tarball's checksum. It's probalby not practical to generate an archive with consistently identical checksums due to the various timestamps (at least without adding a tar writer to svn which would be kind of cool. :) > Maybe we can also have some variables to control that we actually want > the 'HEAD' revision without checking any checksum. However, I think it > would be nice if we can do a checksum'ed checkout for specific SCM > revision, especially if we want to have ports to work not only for > *-devel ports where we would prefer signed source code. While this wasn't the intent of the -DBOOTSTRAP stuff I added to the llvm port, people are finding it useful so if we can find I clean way to support this I think it would be cool. -- Brooks pgpJG8wxgpti5.pgp Description: PGP signature
Re: squeezecenter 7.3.2 no longer starts with latest ports
On Thu, Dec 03, 2009 at 12:24:55AM +, Mark Knight wrote: > In message <91b92520912021328j34373653r838ba135a41f5...@mail.gmail.com>, > Sandra Kachelmann writes > >I even removed the whole database and performed a complete rebuild: > > > >$ portupgrade -rf squeezeboxserver > > > >This port is broken... > > Hi, > > Back out to: > > p5-Class-XSAccessor-1.03,1 > p5-DBIx-Class-0.08112 > > ...and I think it'll work. > > Alternatively there are some PRs that may help when brooks@ gets a > chance to look at them: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/140662 > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/141106 I think I've got it fixed. Sorry for the delay, I've been traveling. -- Brooks pgpYfrHXoH80B.pgp Description: PGP signature
Re: [RFC] Tools/ script for automatically making a tar out of svn sources
On Wed, Dec 09, 2009 at 10:27:58PM +0200, Eitan Adler wrote: > The attached script is designed to work with the 20+ ports that > currently have to resort to hacks to automatically figure out the head > version, checkout from svn, make a tar file, and then upload the file > to freefall. > > It is based on some my earlier work/proposals > (http://wiki.freebsd.org/EitanAdler/ports-svn) to put this directly > into ports.*.mk. While that proposal was rejected by a large part of > the community making a simple standard script to put into Tools was > suggested by a few people as a better solution and one more likely to > get accepted by the community and portmgr. > > This port requires that three values be defined in the ports Makefile. > Of these two are already defined for most of the ports that use the > hacks mentioned above. > USE_SCM="svn" is required as I plan on including support for other > common SCMs that might be used in the ports collection already (git > and cvs come to mind) > SVN_REV=12345 is required unless you use the "-h" option which gets > the version from head > SVN_URL=svn://goo.com/svn_repo - this is where the source is fetched from. > > If I could get any comments (1) on the script in particular and (2) if > the approach I'm taking now is better than the one I tried a few weeks > ago (see wiki page) it would be really good. I don't see the script. -- Brooks pgpJl4ba9ho32.pgp Description: PGP signature
Re: audio/squeezeboxserver still broken
On Sat, Jul 03, 2010 at 12:45:49PM -0700, George Hartzell wrote: > Emanuel Haupt writes: > > George Hartzell wrote: > > > Emanuel Haupt writes: > > > > Hi > > > > > > > > The current audio/squeezeboxserver port is still broken for me. I > > > > just built a package set with an up to date ports tree and > > > > installed them in a vanilla jail to make sure that there is no > > > > previous cruft which could possibly be a problem. > > > > > > > > After installing the package set I started the server and > > > > configured it over the webinterface - just basic stuff, file > > > > location, playlist location, that's it. Then I run > > > > > > > > $ /usr/local/squeezeboxserver/scanner.pl --wipe --rescan > > > > > > > > And I get: > > > > > > > > # /usr/local/squeezeboxserver/scanner.pl --rescan --wipe > > > > Your locale was detected as C, you may have problems with > > > > non-Latin filenames. Consider changing your LANG variable to the > > > > correct locale, i.e. en_US.utf8 [10-07-03 14:38:04.1610] > > > > main::main (180) Starting Squeezebox Server scanner (v7.5.1, > > > > r30836, Tue Jun 1 07:00:00 MDT 2010) perl 5.010001 [10-07-03 > > > > 14:38:04.2226] Carp::Clan::__ANON__ (227) Warning: > > > > Class::C3::Componentised::load_components(): Use of > > > > DBIx::Class::UTF8Columns is strongly discouraged. See > > > > documentation of DBIx::Class::UTF8Columns for more info [10-07-03 > > > > 14:38:04.3794] main::main (271) Removing artwork cache... > > > > [10-07-03 14:38:04.3823] Slim::Music::Import::runImporter (566) > > > > Starting Slim::Music::MusicFolderScan scan [10-07-03 > > > > 14:38:04.3945] Slim::Utils::Scanner::scanDirectory (320) Found 49 > > > > files in /mp3 [10-07-03 14:38:04.3956] > > > > Slim::Utils::Scanner::scanDirectory (333) Scanning: /mp3/foo.mp3 > > > > [10-07-03 14:38:04.4332] Slim::Schema::Storage::throw_exception > > > > (82) Error: DBI Exception: DBD::mysql::db begin_work failed: > > > > Already in a transaction [10-07-03 14:38:04.4336] > > > > Slim::Schema::Storage::throw_exception (82) Backtrace: > > > > > > > >frame 0: Slim::Utils::Log::logBacktrace > > > > (/usr/local/squeezeboxserver/Slim/Schema/Storage.pm line 82) frame > > > > 1: Slim::Schema::Storage::throw_exception > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 1187) frame 2: DBIx::Class::Storage::DBI::__ANON__ > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 1329) frame 3: DBIx::Class::Storage::DBI::__ANON__ > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 738) frame 4: DBIx::Class::Storage::DBI::__ANON__ > > > > (/usr/local/lib/perl5/site_perl/5.10.1/Try/Tiny.pm line 76) frame > > > > 5: (eval) (/usr/local/lib/perl5/site_perl/5.10.1/Try/Tiny.pm line > > > > 67) frame 6: Try::Tiny::try > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 749) frame 7: DBIx::Class::Storage::DBI::dbh_do > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 1329) frame 8: DBIx::Class::Storage::DBI::_dbh_begin_work > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 1310) frame 9: DBIx::Class::Storage::DBI::txn_begin > > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/TxnScopeGuard.pm > > > > line 12) frame 10: DBIx::Class::Storage::TxnScopeGuard::new > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage.pm line > > > > 333) frame 11: DBIx::Class::Storage::txn_scope_guard > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Schema.pm line > > > > 672) frame 12: DBIx::Class::Schema::txn_scope_guard > > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Relationship/CascadeActions.pm > > > > line 49) frame 13: > > > > DBIx::Class::Relationship::CascadeActions::update > > > > (/usr/local/squeezeboxserver/Slim/Schema/DBI.pm line 39) frame 14: > > > > Slim::Schema::DBI::update > > > > (/usr/local/squeezeboxserver/Slim/Schema.pm line 2766) frame 15: > > > > Slim::Schema::_postCheckAttributes > > > > (/usr/local/squeezeboxserver/Slim/Schema.pm line 1079) frame 16: > > > > Slim::Schema::newTrack > > > > (/usr/local/squeezeboxserver/Slim/Utils/Scanner.pm line 347) frame > > > > 17: Slim::Utils::Scanner::scanDirectory > > > > (/usr/local/squeezeboxserver/Slim/Music/MusicFolderScan.pm line > > > > 79) frame 18: Slim::Music::MusicFolderScan::startScan > > > > (/usr/local/squeezeboxserver/Slim/Music/Import.pm line 568) frame > > > > 19: Slim::Music::Import::runImporter > > > > (/usr/local/squeezeboxserver/Slim/Music/Import.pm line 373) frame > > > > 20: Slim::Music::Import::runScan > > > > (/usr/local/squeezeboxserver/scanner.pl line 305) frame 21: (eval) > > > > (/usr/local/squeezeboxserver/scanner.pl line 299) frame 22: > > > > mai
Re: sysutils/sge6[012]: Sun Grid Engine - still broklen due to utmpx?
On Fri, Sep 23, 2011 at 09:04:49AM +0200, Hartmann, O. wrote: > I was wondering if the SUN Grid Engine, located in port > sysutils/sge6[012] is still broken due to utmpx. > > My department uses this GRID engine on Linux and since a long time I > wish to use it also on FreeBSD. I've not had a decent 9.0 system available until quite recently and haven't had as much time as I'd like for FreeBSD HPC stuff lately. I'm taking a look at it today. It looks like I should be able to get it fixed, but ancient version of tcsh that is failing to compile is really annoying to patch for utmpx. -- Brooks pgpHjF5pFb1jp.pgp Description: PGP signature
Re: sysutils/sge6[012]: Sun Grid Engine - still broklen due to utmpx?
On Fri, Sep 23, 2011 at 10:58:33AM -0500, Brooks Davis wrote: > On Fri, Sep 23, 2011 at 09:04:49AM +0200, Hartmann, O. wrote: > > I was wondering if the SUN Grid Engine, located in port > > sysutils/sge6[012] is still broken due to utmpx. > > > > My department uses this GRID engine on Linux and since a long time I > > wish to use it also on FreeBSD. > > I've not had a decent 9.0 system available until quite recently and haven't > had as much time as I'd like for FreeBSD HPC stuff lately. I'm taking a > look at it today. It looks like I should be able to get it fixed, but > ancient version of tcsh that is failing to compile is really annoying to > patch for utmpx. I've committed a fix to the sge62 port. Assuming the change makes it through some testing without me acquiring more pointyhats I'll add it to the older ones next week. -- Brooks pgpu6AnMperBX.pgp Description: PGP signature
Re: Plan to add a bsd.pure.mk
On Mon, Dec 05, 2011 at 01:28:33AM -0600, Mark Linimon wrote: > I would like to hold off on any more disruptive changes to the tree > until we can get this release out the door. If that means devel/clang > needs to stay at its current value (and only clang-devel updated), then > that's fine. We don't actually need to add a bsd.pure.mk to upgrade llvm. We would need to complete the repocopy in ports/163030 and change the build and run depends in lang/pure which would change the depends of the 12ish ports involved. Similar changes are needed in a couple other ports. I'll leave it up to portmgr to decide if that's too disruptive. IMO if any change of this scope (an upgrade triggering less than dozen rebuilds, mostly of ports that aren't widely used) should be approved, it should be this one given our general toolchain focus. -- Brooks pgpU7Cr8Ql124.pgp Description: PGP signature
Re: Creation of users in ports
On Wed, Dec 07, 2011 at 07:54:07PM +, Chris Rees wrote:
> Hi all,
>
> I'm at a loss as to how to restore functionality for creating (or
> using) customised users in ports. For example, using the old method
> (pkg-install scripts) many ports allowed the user to change the
> username used for the port.
>
> With the new functionality, if the username isn't found in
> /usr/ports/UIDs it's rejected, and the port can't use it.
>
> Can anyone explain to me why it would be a bad idea to include the
> system's passwd and group files in the search? This would allow the
> ports system to accept any user that already exists, as well as
> creating the correct code in the plist.
>
> For example; someone wants to install postgresql as username Fred, so
> s/he sets PG_USER=Fred in /etc/make.conf. Currently this causes an
> error on build, because Fred is not in /usr/ports/UIDs. Were
> /etc/master.passwd and /etc/group searched too, that wouldn't cause a
> problem.
>
> Any obvious oversights?
It seems like a better (but more complicatd) solution would use "getent
passwd ${USER}" to check for existing users. (You need to check
explicitly rather than treating the output without /etc/passwd because
some nss modules don't enumerate to avoid listing the thousands or tens
of thousands of users in a corporate AD or LDAP installation).
-- Brooks
pgp1v1sjlbwRG.pgp
Description: PGP signature
Re: update of security/pssh
On Thu, Dec 02, 2010 at 12:24:27PM +0100, Olivier Smedts wrote: > Hello, > > According to : > http://www.theether.org/pssh/ > > parallel-ssh (pssh) is now maintained on > http://code.google.com/p/parallel-ssh/ by Andrew McNabb. Current > version is 2.1.1. > > Would you have time to look into a maintainer-update ? Thanks for the pointer. Added to my todo list. -- Brooks pgpA2PjbzOXUf.pgp Description: PGP signature
Re: Proposal moving *spell dicts to ports/textproc/*spell/dicts
On Sun, Dec 05, 2010 at 03:16:05PM +0100, Julian H. Stacey wrote:
> > > Hello,
> > >
> > >> As I said some weeks ago I personally don't like much the use of
> > >> ports/{french,chinese,whatever}/ directories. I saw that openbsd
> > >> created sub directories in the aspell port. I think this is a really
> > >> good idea, it's really easier to find.
> > >>
> > >> I don't think german/ispell french/aspell textproc/gu-aspell are
> > >> really easy to find.
> > >>
> > >> I propose creating a ports/textproc/aspell/dicts and same for
> > >> textproc/ispell and textproc/hunspell and moving every spellings ports
> > >> to these directories.
> > >
> > > I don't know about hunspell and ispell, but aspell's dictionaries are
> > > maintained and updated independently, at different dates: its why these
> > > are separate ports.
> > >
> > > Regards,
> > > --
> > > Th. Thomas.
> > >
> >
> > Yes but I don't want to make one big dict/ port. I would like to move
> > all aspell languages ports into aspell/dicts/ and then you go under
> > ports/textproc/aspell/dicts/fr && make install for example :)
>
> Problem:
> Scripts assuming 2 levels for all ports.
> Paths such as */*/pkg-plist would no longer be complete.
Including the package registration code in bsd.port.mk
-- Brooks
pgpUODmEOUnGg.pgp
Description: PGP signature
Re: FreeBSD Port: squeezeboxserver-7.5.3, build okay but fails to start.
On Wed, Apr 27, 2011 at 07:15:07AM -0700, spotter wrote: > I am having the exact same problem with a brand new FreeBSD 8.1-RELEASE > install and a fresh squeezeboxserver (v7.5.3) port build. > (Slimserver was working fine under FreeBSD 6.2, until I tried to get > miniDLNA working, as well, for a BluRay player access to same music library. > sigh) > Any solutions worked out for squeezeboxserver v7.5.3 under FreeBSD > 8.1-RELEASE? Assuming you aren't using mysql for anything else, you might try manually installing an older version and then reinstalling the port. My squeezeboxserver is running with 5.0. If that works we should be able to restrict the allowed versions of mysql to ones that work. -- Brooks > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/FreeBSD-Port-squeezeboxserver-7-5-3-build-okay-but-fails-to-start-tp3861984p4343776.html > Sent from the freebsd-ports mailing list archive at Nabble.com. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > pgpntJVefKeex.pgp Description: PGP signature
Re: build failure of ganglia-monitor-core-3.1.7
On Tue, May 24, 2011 at 10:19:40AM +0100, Anton Shterenlikht wrote: > On ia64 and sparc64, both current, I get > a build failure of ganglia-monitor-core-3.1.7 > when updating from 3.1.1_6: > > ===> Building for ganglia-monitor-core-3.1.7 > make: cannot open Makefile. > *** Error code 1 > > Stop in /usr/ports/sysutils/ganglia-monitor-core. Does it work for you on any other platforms? If so, there is probably a configure failure above that needs to be analyzed. The output these commands after a failed build might also be helpful: cd /usr/ports/sysutils/ganglia-monitor-core ls -l `make -V WRKSRC` > I contacted the maintainer, but haven't heard > anything back. I'm writing to the list in > case I missed something about this update. Sorry I missed your message, the only messages I saw that obviously related to ganglia were about the broken fetch URL. -- Brooks pgpnR19ZcUKYi.pgp Description: PGP signature
Re: build failure of ganglia-monitor-core-3.1.7
On Tue, May 24, 2011 at 09:14:54PM +0100, Anton Shterenlikht wrote: > On Tue, May 24, 2011 at 02:37:42AM -0500, Brooks Davis wrote: > > On Tue, May 24, 2011 at 10:19:40AM +0100, Anton Shterenlikht wrote: > > > On ia64 and sparc64, both current, I get > > > a build failure of ganglia-monitor-core-3.1.7 > > > when updating from 3.1.1_6: > > > > > > ===> Building for ganglia-monitor-core-3.1.7 > > > make: cannot open Makefile. > > > *** Error code 1 > > > > > > Stop in /usr/ports/sysutils/ganglia-monitor-core. > > > > Does it work for you on any other platforms? > > yes, builds on amd64. I should've checked, just > I don't need ganglia on amd64. Good, my testing was amd64. > > If so, there is probably a > > configure failure above that needs to be analyzed. > > http://seis.bris.ac.uk/~mexas/sparc64-ganglia-3.1.7-config.log > http://seis.bris.ac.uk/~mexas/ia64-ganglia-3.1.7-config.log Looking at the log I think I'm missing a dependency on pcre. Could you try installing devel/pcre and seeing if that fixes it? It's rather bizarre that configure exits with 0 when this happens, it should report an error. That's certainly a bug upstream? Thanks, Brooks pgp2In81insOD.pgp Description: PGP signature
Re: build failure of ganglia-monitor-core-3.1.7
On Wed, May 25, 2011 at 12:33:10PM +0100, Anton Shterenlikht wrote: > On Tue, May 24, 2011 at 08:46:42AM -0500, Brooks Davis wrote: > > On Tue, May 24, 2011 at 09:14:54PM +0100, Anton Shterenlikht wrote: > > > On Tue, May 24, 2011 at 02:37:42AM -0500, Brooks Davis wrote: > > > > On Tue, May 24, 2011 at 10:19:40AM +0100, Anton Shterenlikht wrote: > > > > > On ia64 and sparc64, both current, I get > > > > > a build failure of ganglia-monitor-core-3.1.7 > > > > > when updating from 3.1.1_6: > > > > > > > > > > ===> Building for ganglia-monitor-core-3.1.7 > > > > > make: cannot open Makefile. > > > > > *** Error code 1 > > > > > > > > > > Stop in /usr/ports/sysutils/ganglia-monitor-core. > > > > > > > > Does it work for you on any other platforms? > > > > > > yes, builds on amd64. I should've checked, just > > > I don't need ganglia on amd64. > > > > Good, my testing was amd64. > > > > > > If so, there is probably a > > > > configure failure above that needs to be analyzed. > > > > > > http://seis.bris.ac.uk/~mexas/sparc64-ganglia-3.1.7-config.log > > > http://seis.bris.ac.uk/~mexas/ia64-ganglia-3.1.7-config.log > > > > Looking at the log I think I'm missing a dependency on pcre. Could you > > try installing devel/pcre and seeing if that fixes it? > > yes, this fixed it, thanks. Great, I'll add the dependancy to the port. > > It's rather bizarre that configure exits with 0 when this happens, it > > should report an error. That's certainly a bug upstream? > > Do you want me to do anything about it? Nope, I'll see if I can spot anything obvious in the autoconf code and pester the devs about it. -- Brooks pgp0PWPPCnBpU.pgp Description: PGP signature
Re: Lightspark port and LLVM bug
On Wed, Jun 15, 2011 at 10:58:30AM -0500, Rusty Nejdl wrote: > I might be interested in taking over maintainership of this port but at > present, this will not compile. I have submitted a PR for an updated > version of libxml++26 but also, the versions of LLVM (including -devel) > both contain a bug that prevents this from compiling: > > http://llvm.org/bugs/show_bug.cgi?id=9869 > > This suggests that I might be able to get it to compile using LLVM > r131062. It's been a while since I update the -devel ports, I'll kick off an update cycle today. -- Brooks pgp2XYGaHNmAu.pgp Description: PGP signature
Re: Lightspark port and LLVM bug
On Wed, Jun 15, 2011 at 04:52:10AM -0500, Brooks Davis wrote: > On Wed, Jun 15, 2011 at 10:58:30AM -0500, Rusty Nejdl wrote: > > I might be interested in taking over maintainership of this port but at > > present, this will not compile. I have submitted a PR for an updated > > version of libxml++26 but also, the versions of LLVM (including -devel) > > both contain a bug that prevents this from compiling: > > > > http://llvm.org/bugs/show_bug.cgi?id=9869 > > > > This suggests that I might be able to get it to compile using LLVM > > r131062. > > It's been a while since I update the -devel ports, I'll kick off an > update cycle today. I've updated the -devel port to r133062. -- Brooks pgpYAUPe23gZh.pgp Description: PGP signature
Re: [CFT] Likewise-open preliminary port
On Tue, Jun 21, 2011 at 10:09:23AM +0200, Ganael Laplanche wrote: > Hi everyone, > > Over the past few weeks, I've been working on a Likewise-open [1] port and am > starting to get something useable. > > Technically speaking, the port builds fine on x86 and amd64 platforms (gcc- > only ATM) and is able to use libraries from the ports tree instead of the > ones > bundled in the source tarball. > > Basic functionality has been tested : with a local account database (SQLite), > I was able to retrieve account information through nsswitch as well as > authenticate a user on sshd through PAM. The CIFS server also works : a local > Likewise user is able to connect to it. > > Anyway, I am not a Likewise expert and there are still several -important- > tests to perform : > - Try to join an Active Directory server and use it as an authentication > source, instead of the local SQLite DB > - Play with client-side commands (lwio-copy, lwio-fuse-mount) ; I could not > get them work (see below) but I may have missed something > - Try advanced CIFS server configurations > > Here are also remaining tasks that have to be done before the port can hit > the > tree : > - Write a rc.d startup script (probably a wrapper to the provided init.d > scripts) > - Fix build with clang > - Try to build with Heimdal (?) > > I would be pleased to get feedback from you... any help or comment is welcome > ! Have you tried asking Likewise for the ports they appear to be using internally to build packages for FreeBSD? While the normal Likewise install location in /opt/likewise is non-standard, I suspect most likewise users hardcode it in their scripts. I know I do. It seems generally useful to ease the upgrade path from a likewise-open port to likewise-enterprise. -- Brooks pgpfHGuHWeErA.pgp Description: PGP signature
Re: HELP needed by experienced porter for simple review
On Thu, Dec 06, 2007 at 10:22:06PM +0100, GP wrote: >>> rc.conf >>> It's a shame that I can't use a script placed in /files to change rc.conf >>> during install/ >>> deinstall. I really liked that. But i guess I will settle with a dull >>> pkg-message at the >>> end, like the rest of you... >>> >> Well, no, it's not a shame. The last thing we want to do as a community >> is enable all sorts of daemons that users don't know they have enabled. >> It's up to the owner of a box to enable a daemon **in the way** that they >> want it enabled. For example, *none* of the daemons on my workstation >> listen for connections on its IP address - only on localhost. If you >> enabled the daemon by default while installing the script, and I didn't >> have time to config it the way I wanted, and it got started (either by >> accident or by reboot) I would be pissed (not to mention possibly hacked.) >> >> As porters our job is to make the software available for install *not* >> decide how or when it will be used. > > I principal I agree. My script asked if you wanted the lines added to > rc.conf or not. > That can ofcause be a problem i you want to make install world or > something... > But the current way is not very userfrendly - especially for non tech > desktop users. If you really want to change this it would need to be done in a way that all ports can use central infrastructure. I'd probably be opposed to having the prompting be part of the ports makefiles and propose putting it in the various ports managment tools. If we changed things so we installed per-port defaults files those could serve as a template for general tools to do automatic editing. -- Brooks pgpGO8dHlSD3g.pgp Description: PGP signature
Re: Renaming a Port
On Thu, Dec 13, 2007 at 10:31:01AM -0500, Steven Kreuzer wrote: > Greetings- > > I am the maintainer of the mysqltoolkit port. Recently, the project > underwent a name change and is now maatkit. > The application has also undergone some updates so I would like to update > the port to the latest version. > > While I am sure I am not the first person to ever have this problem, its a > new one for me so I figured I would ping the > list and see what people have to say. > > Is this the best way to go about this? > > 1) Have someone mark mysqltoolkit as DEPRECATED > 2) Take my port, rename it to maatkit and make the changes necessary to the > Makefile, etc > 3) Submit the port and have it checked in. > > However, do I need to provide some sort of migration path for existing > users of mysqltoolkit? Is that even possible? > If so, how do I go about doing it. > > Any advice or guidance is greatly appreciated. The MOVED file exists for this very reason. You will need to submit an update that changes the current port to the new name and adds an entry to MOVED. A repocopy will be performed to copy the history of the port to the new location. Once that's done, the changes will be applied to the new copy, the entry added to MOVED, and the old port removed. -- Brooks pgpMLYcFltS3J.pgp Description: PGP signature
Re: sysutils/lsof cannot fetch distfile ;;
On Fri, Jan 25, 2008 at 02:39:21PM -0500, Wesley Shields wrote: > On Fri, Jan 25, 2008 at 12:56:20PM -0600, Larry Rosenman wrote: > > I was talking about GETTING the distfile onto the freebsd.org mirrors. > > I'm working on this now. I've never had to do something like this > before but from what I can gather placing it in ~/distfiles on freefall > will eventually get it placed in > ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/. I've done exactly > this so it should be mirrored out eventually. If I'm wrong in this I'll > have to ask my mentor what the correct procedure is. For now, you can > fetch it manually from the location Larry provided. The correct directory is ~/public_distfiles. See: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#SLOW-SOURCES -- Brooks pgpLGtlR1tT1C.pgp Description: PGP signature
Re: Weird portlint errors
On Thu, Feb 21, 2008 at 07:43:32AM -0800, comperr wrote: > I am working on a new port for pastebinit (command line pastebin) and > when I run portlint I get a weird error that my portname and such > don't exist and there are nion comments in the comment part - but I > know these error are wrong. Please provide at least the actual errors and preferably the port skeleton as well. -- Brooks pgpCjfxroHO6S.pgp Description: PGP signature
Re: Weird portlint errors
On Thu, Feb 21, 2008 at 02:19:14PM -0800, comperr wrote: > http://groups.google.com/group/ml-freebsd-ports/files > tmp is portlint >tmp 2>&1 > Makefile is the makefile I'm having errors with. The file contains bogus carrage returns, probably due to being exiting on a windows box. Please run dos2unix on it or recreate it in an appropriate editor. Then it will work. Also, please don't top-post when posting to freebsd-lists. -- Brooks > > On Feb 21, 11:00 am, Brooks Davis <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 21, 2008 at 07:43:32AM -0800, comperr wrote: > > > I am working on a new port for pastebinit (command line pastebin) and > > > when I run portlint I get a weird error that my portname and such > > > don't exist and there are nion comments in the comment part - but I > > > know these error are wrong. > > > > Please provide at least the actual errors and preferably the port > > skeleton as well. > > > > -- Brooks > > > > application_pgp-signature_part > > 1KDownload > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > pgpEhARNcVRlI.pgp Description: PGP signature
Re: FreeBSD Port: slimserver-6.5.4
On Wed, Mar 19, 2008 at 10:03:47AM -0400, Andy Rossmeissl wrote: > Hi Brooks, > > Are you planning on doing a port of SqueezeCenter (f/k/a SlimServer 7)? Yes. I've started work on it, but a lot has changed and I've been on vacation and will be traveling next week so I don't currently have an ETA. -- Brooks pgpAtWJ0Q1NgF.pgp Description: PGP signature
Re: lzma (Re: HEADS UP: upgrading ImageMagick to 6.4.0-6)
On Tue, Apr 15, 2008 at 10:35:30PM -0400, Mikhail Teterin wrote: > 15 ??? 2008 10:21 ??, Brooks Davis ?? : > > Sadly, the author's licensing terms will limit the adoption of lzma. > > The BSD license is well established as the most restrictive acceptable > > license for successful, widely adopted compression schemes. > > Ever seen the inside of gzip.c (the original)? General Public License is > certainly more restrictive than BSD's and yet we (and just about everyone > else under the sun) had it in the tree until very recently, when a direct > client of libz was imported. The fact that a licensing compromsise was once made in the face of an extremely poor competitor (compress not only performs badly on text, it significantly expands files gzip and bzip are perfectly capable of compressing) is largely irrelevent. The reality is that the significant improvements provided by lzma will be relegated to a niche until an implementation under a BSD-like license is available. Even RMS acknoledges this effect http://lwn.net/2001/0301/a/rms-ov-license.php3 I wouldn't necessicairly be opposed to seeing support for tar.lzma files in bsd.port.mk, but I don't think lzma has a signficant future if the licensing policy remains as is (i.e. complex and not clearly defined in the source files). -- Brooks pgptTES63WXOg.pgp Description: PGP signature
Re: lzma (Re: HEADS UP: upgrading ImageMagick to 6.4.0-6)
On Mon, Apr 21, 2008 at 11:05:42PM +0400, Andrew Pantyukhin wrote: > On Tue, Apr 15, 2008 at 10:07:54PM -0500, Brooks Davis wrote: > > On Tue, Apr 15, 2008 at 10:35:30PM -0400, Mikhail Teterin wrote: > > > 15 ??? 2008 10:21 ??, Brooks Davis ?? : > > > > Sadly, the author's licensing terms will limit the adoption of lzma. > > > > The BSD license is well established as the most restrictive acceptable > > > > license for successful, widely adopted compression schemes. > > > > I wouldn't necessicairly be opposed to seeing support for tar.lzma files > > in bsd.port.mk, but I don't think lzma has a signficant future if the > > licensing policy remains as is (i.e. complex and not clearly defined in > > the source files). > > == qouth lzma.txt == > SPECIAL EXCEPTION #3: Igor Pavlov, as the author of this code, > expressly permits > > you to use code of the following files: > BranchTypes.h, LzmaTypes.h, LzmaTest.c, LzmaStateTest.c, > LzmaAlone.cpp, > LzmaAlone.cs, LzmaAlone.java > as public domain code. > > > Without a more careful look, it sounds like enough to integrate > lzma in libarchive. That's well hidden (DOC/lzam.txt in the tarball). Someone should produce some sort of lzma-lite distribution that only does the basics. Then this could be a practical option. -- Brooks pgp7kKWQWNrpm.pgp Description: PGP signature
Re: lzma (Re: HEADS UP: upgrading ImageMagick to 6.4.0-6)
On Tue, Apr 22, 2008 at 02:34:39PM +0400, Andrew Pantyukhin wrote: > On Mon, Apr 21, 2008 at 02:42:24PM -0500, Brooks Davis wrote: > > That's well hidden (DOC/lzam.txt in the tarball). Someone > > should produce some sort of lzma-lite distribution that only > > does the basics. Then this could be a practical option. > > Unfortunately, a closer look dispelled the hope. The > public-domained files only show how to use the GPL'ed ones. I had > a conversation with the author, who is worried about incompatible > formats being spawned if he releases lzma from under LGPL. He > might change his mind in the future, though. Too bad. :( FWIW, I don't see any significant, incompatible competitors to bzip2 or ogg vorbis (for example). -- Brooks pgpS3zmRzUk8r.pgp Description: PGP signature
Re: Building new port, don't want to run as root
On Mon, Apr 28, 2008 at 07:27:44PM +0300, Walter Venable wrote: > Matthew Seaman wrote: >> I take it you're talking about a daemon process and you want to have the >> rc.subr scripts start it as another user than root? That's fairly simple. >> >> To make rc.subr start a process using a different UserID, all you need to >> do is define variables >> >>name = foo<-- standard rc script thing to >>setup the namespace >>foo_user = someone >>foo_group = somegroup > Ok, silly question, but I looked around again and hit another brick wall -- > how do I make the port add a user that doesn't already exist? http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-uid-and-gids.html -- Brooks pgpE8oWyqsQ0y.pgp Description: PGP signature
Re: Problem with recent MOVED file and portupgrade
On Wed, Apr 30, 2008 at 04:36:52PM -0400, Mike Jakubik wrote: > I get a MOVED file error when i try to use any of the portupgrade apps > with a recently cvsed ports tree. Try again. I committed an error earlier today and fixed it about an hour ago. IMO, portupgrade should make some attempt to ignore totally bogus lines. -- Brooks > FreeBSD 7.0-STABLE #0: Fri Mar 7 16:47:03 EST 2008 > > --- > [EMAIL PROTECTED]:/var/db/pkg# portversion -v > /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:119:in `fill': MOVED file > format error (PortsDB::MOVEDError) > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:113:in `each' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:113:in `fill' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:112:in `open' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:112:in `fill' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:107:in `initialize' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:182:in `new' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:182:in `setup' > from /usr/local/lib/ruby/site_ruby/1.8/pkgtools.rb:256:in > `init_pkgtools_global' > from /usr/local/sbin/portversion:175:in `main' > from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize' > from /usr/local/sbin/portversion:80:in `new' > from /usr/local/sbin/portversion:80:in `main' > from /usr/local/sbin/portversion:364 > > [EMAIL PROTECTED]:~# pkgdb -Ff > MOVED file format error > --- > > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > pgp5189qSlas4.pgp Description: PGP signature
Re: rc.d startup script problem
On Tue, May 13, 2008 at 02:35:54PM -0500, Paul Schmehl wrote:
> This script will not start if you change the name or location of the conf
> file in /etc/rc.conf. For some reason it's not parsing /etc/rc.conf.
> Anyone know why?
>
> #!/bin/sh
>
> # PROVIDE: sancp_agent
> # REQUIRE: DAEMON
> # KEYWORD: shutdown
>
> # Add the following line to /etc/sguil-sensor/rc.conf to enable sancp_agent:
> # sancp_agent_enable (bool):Set to YES to enable sancp_agent
> # Default: NO
> # sancp_agent_conf (str): Sensor_agent configuration file
> # Default:
> /usr/local/etc/sguil-sensor/sancp_agent.conf
> #
>
> . /etc/rc.subr
>
> name="sancp_agent"
> rcvar=`set_rcvar`
> command="/usr/local/bin/sguil-sensor/sancp_agent.tcl"
> procname="/usr/local/bin/tclsh8.4"
> pidfile="/var/run/${name}.pid"
> check_pidfile="${pidfile} ${procname} /bin/sh"
>
> [ -z "$sancp_agent_enable" ]&& sancp_agent_enable="NO"
> [ -z "$sancp_agent_conf" ] &&
> sancp_agent_conf="/usr/local/etc/sguil-sensor/sancp_agent.conf"
> [ -z "$sancp_agent_flags" ] && sancp_agent_flags="-D"
>
> [ -n "$sancp_agent_conf" ] && sancp_agent_flags="$sancp_agent_flags -c
> $sancp_agent_conf"
This section needs to go below load_rc_conf so the variables are
reliably defined. Also, command_args should generally be used instead
of ${name}_flags.
-- Brooks
> load_rc_config $name
> run_rc_command "$1"
>
> # grep sancp /etc/rc.conf
> sancp_agent_enable="YES"
> sancp_agent_conf="/usr/local/etc/sguil-sensor/sancp_agent-ANYSERVER.conf"
>
> What's the problem?
>
> --
> Paul Schmehl ([EMAIL PROTECTED])
> Senior Information Security Analyst
> The University of Texas at Dallas
> http://www.utdallas.edu/ir/security/
>
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
pgphtlzGSZeW9.pgp
Description: PGP signature
Re: porting of SVN-only software
On Fri, May 16, 2008 at 09:08:25PM +0200, Gabor Kovesdan wrote: > Wesley Shields escribi?: >> On Fri, May 16, 2008 at 09:54:09PM +0300, Andriy Gapon wrote: >> >>> Suppose there is a project that does not produce any official snapshots >>> or releases of its source-code, keeps all sources in SVN and the best it >>> does - declares a certain revision as stable or something similar. >>> What would be the best way to create a FreeBSD port for such software? >>> Any examples? >>> >> >> My approach would be to produce a tarball of the checkout and work with >> that. > Agreed. The date of the checkout should be the PORTVERSION, for example > 20080516. Alternativly, the global version number for the tree might be appropriate for subversion source. -- Brooks pgpCuIyXerVlD.pgp Description: PGP signature
Re: hier 7 question
On Sun, May 18, 2008 at 08:20:03PM -0400, Marc Spitzer wrote:
> Hello,
>
> I am porting ATF, http://www.netbsd.org/~jmmv/atf/, a unit testing
> framework for C, C++ and Shell. The thing is is that it installs a
> bunch of self tests in ${PREFIX}/tests/atf. Is this the right place
> for it? From Hier(7) binaries should not go under share/. Otherwise
> I think it is done. Personally I think the tests/port could be a
> handy thing to have. What is your opinion/advice on this?
libexec/ seems like it might be the right place.
-- Brooks
pgppufsuf5P5n.pgp
Description: PGP signature
Re: audio/squeezecenter: .tgz not on Freebsd.org (is on slimdevices.com); perl probs
On Fri, Jun 13, 2008 at 02:50:51PM -0400, Chris Shenton wrote:
> The port tries to find the .tgz on FreeBSD.org only, but it does not
> exist. I found it on slimdevices -- same MD5, SHA256, SIZE:
>
> http://www.slimdevices.com/downloads/SqueezeCenter_v7.0.0/squeezecenter-7.0-noCPAN.tgz
There's apparently something non-standard to your ports config because the
only master site is:
MASTER_SITES=
http://www.slimdevices.com/downloads/SqueezeCenter_v${PORTVERSION}/
The file is not on freebsd.org or any mirrors because Slim Devices
forbids redistribution.
> After building successfully, it fails to start with some problems in Perl:
>
> [EMAIL PROTECTED]:squeezecenter<130# /usr/local/etc/rc.d/squeezecenter start
> Starting squeezecenter.
> Use of uninitialized value in join or string at
> /usr/local/lib/perl5/site_perl/5.8.8/mach/File/Spec/Unix.pm line 82.
> Use of uninitialized value in subroutine entry at
> /usr/local/lib/perl5/site_perl/5.8.8/mach/YAML/Syck.pm line 75.
> Use of uninitialized value in pattern match (m//) at
> /usr/local/squeezecenter/Slim/Utils/Prefs.pm line 265.
>
> [EMAIL PROTECTED]:squeezecenter<131# telnet localhost 9000
> Trying 127.0.0.1...
> telnet: connect to address 127.0.0.1: Connection refused
>
> The first file value is @_, the second is $_, and I can't see the issue
> with the third file.
>
> My perl-fu is pretty rusty so I can't be much use tracking this down.
You've got an out of date port version. I wasn't deleteing enough
of the included YAML/Syck installation and after a recent update in
ports, the two versions started to conflict in strange ways. The latest
version of the of squeezecenter is 7.0.1.
-- Brooks
pgp8LxtArKeE1.pgp
Description: PGP signature
Re: audio/squeezecenter: .tgz not on Freebsd.org (is on slimdevices.com); perl probs
On Fri, Jun 13, 2008 at 09:19:35PM +0100, Rob MacGregor wrote: > Chris Shenton unleashed the infinite monkeys on 13/06/2008 19:50 producing: >> The port tries to find the .tgz on FreeBSD.org only, but it does not >> exist. I found it on slimdevices -- same MD5, SHA256, SIZE: >> >> http://www.slimdevices.com/downloads/SqueezeCenter_v7.0.0/squeezecenter-7.0-noCPAN.tgz > > I saw the same thing, but grabbed the 7.0.1 version instead (as the port is > supposedly 7.0.1). I had to change the variable WRKSRC to reflect the new > directory. I suspect you have an outdated port. What is the $FreeBSD*$ string in the comment at the top of the Makefile? It should be: # $FreeBSD: ports/audio/squeezecenter/Makefile,v 1.46 2008/06/12 00:56:51 brooks Exp $ > I instead get: > > Starting squeezecenter. > The following CPAN modules were found but cannot work with SqueezeCenter: > JSON::XS::VersionOneAndTwo (loaded , need 0.31) > > The JSON package is installed: > > p5-JSON-XS-2.20 JSON serialising/deserialising, done... This is almost certainly caused be an outdated port. The JSON::XS version in ports used to match the one in the ports system. As a result, the fact that I'd failed to remove all of the pieces from the CPAN directory in the distribution didn't hurt. Once the ports version was updated that caused things to break. I suspect that's the problem here, though it could be something else. -- Brooks pgp3gOpoUIc5F.pgp Description: PGP signature
Re: audio/squeezecenter: .tgz not on Freebsd.org (is on slimdevices.com); perl probs
On Sun, Jun 15, 2008 at 05:46:59PM -0500, Brooks Davis wrote: > On Fri, Jun 13, 2008 at 09:19:35PM +0100, Rob MacGregor wrote: > > Chris Shenton unleashed the infinite monkeys on 13/06/2008 19:50 producing: > >> The port tries to find the .tgz on FreeBSD.org only, but it does not > >> exist. I found it on slimdevices -- same MD5, SHA256, SIZE: > >> > >> http://www.slimdevices.com/downloads/SqueezeCenter_v7.0.0/squeezecenter-7.0-noCPAN.tgz > > > > I saw the same thing, but grabbed the 7.0.1 version instead (as the port is > > supposedly 7.0.1). I had to change the variable WRKSRC to reflect the new > > directory. > > I suspect you have an outdated port. What is the $FreeBSD*$ string in the > comment at the top of the Makefile? It should be: > > # $FreeBSD: ports/audio/squeezecenter/Makefile,v 1.46 2008/06/12 00:56:51 > brooks Exp $ > > > I instead get: > > > > Starting squeezecenter. > > The following CPAN modules were found but cannot work with SqueezeCenter: > > JSON::XS::VersionOneAndTwo (loaded , need 0.31) > > > > The JSON package is installed: > > > > p5-JSON-XS-2.20 JSON serialising/deserialising, done... > > This is almost certainly caused be an outdated port. The JSON::XS > version in ports used to match the one in the ports system. As a > result, the fact that I'd failed to remove all of the pieces from the > CPAN directory in the distribution didn't hurt. Once the ports version > was updated that caused things to break. I suspect that's the problem > here, though it could be something else. OK, I've got to take most of this back. This could be correct, but probably isn't. It looks like I botched the 7.0.1 upgrade fairly badly by not checking the downloads thuroughly and as a result the URL was bogus. It only appears to work if you already had the old distfile around. I'm currently packing for a trip, but will try to get the port upgraded correctly in the next day or two. Sorry for the confusion. -- Brooks pgpMZCniIqeYY.pgp Description: PGP signature
Re: audio/squeezecenter: .tgz not on Freebsd.org (is on slimdevices.com); perl probs
On Sun, Jun 15, 2008 at 10:05:31PM -0500, Brooks Davis wrote: > On Sun, Jun 15, 2008 at 05:46:59PM -0500, Brooks Davis wrote: > > On Fri, Jun 13, 2008 at 09:19:35PM +0100, Rob MacGregor wrote: > > > Chris Shenton unleashed the infinite monkeys on 13/06/2008 19:50 > > > producing: > > >> The port tries to find the .tgz on FreeBSD.org only, but it does not > > >> exist. I found it on slimdevices -- same MD5, SHA256, SIZE: > > >> > > >> http://www.slimdevices.com/downloads/SqueezeCenter_v7.0.0/squeezecenter-7.0-noCPAN.tgz > > > > > > I saw the same thing, but grabbed the 7.0.1 version instead (as the port > > > is > > > supposedly 7.0.1). I had to change the variable WRKSRC to reflect the > > > new > > > directory. > > > > I suspect you have an outdated port. What is the $FreeBSD*$ string in the > > comment at the top of the Makefile? It should be: > > > > # $FreeBSD: ports/audio/squeezecenter/Makefile,v 1.46 2008/06/12 00:56:51 > > brooks Exp $ > > > > > I instead get: > > > > > > Starting squeezecenter. > > > The following CPAN modules were found but cannot work with SqueezeCenter: > > > JSON::XS::VersionOneAndTwo (loaded , need 0.31) > > > > > > The JSON package is installed: > > > > > > p5-JSON-XS-2.20 JSON serialising/deserialising, done... > > > > This is almost certainly caused be an outdated port. The JSON::XS > > version in ports used to match the one in the ports system. As a > > result, the fact that I'd failed to remove all of the pieces from the > > CPAN directory in the distribution didn't hurt. Once the ports version > > was updated that caused things to break. I suspect that's the problem > > here, though it could be something else. > > OK, I've got to take most of this back. This could be correct, but > probably isn't. > > It looks like I botched the 7.0.1 upgrade fairly badly by not checking > the downloads thuroughly and as a result the URL was bogus. It only > appears to work if you already had the old distfile around. I'm > currently packing for a trip, but will try to get the port upgraded > correctly in the next day or two. > > Sorry for the confusion. I belive the port is now correctly updated. The previous version (7.0.1) was wrong in several ways. -- Brooks pgpVW884OnMcc.pgp Description: PGP signature
Re: port unmaintained since 2005? drop it? misc/gpt*
On Mon, Jun 11, 2012 at 01:45:40AM -0400, Michael Scheidell wrote: > > > On 6/11/12 4:31 AM, per...@pluto.rain.com wrote: > > Dunno what (if anything) they are currently good for, but it seems > > that, at a minimum, the PORTVERSION and/or MASTER_SITES -- and the > > pkg-descr -- need to be updated. > They still don't build. > And, they still aren't need by anything in ports tree (again, globus was > deleted from ports tree in 2008) > > anyone want to maintain them? I'll tag your name on the ports for you. As the person who originally ported and committed them, I say they should be taken out and shot. They were unmaintainable from the start without a significant number of users to drive the upstream to stop making bad decisions. -- Brooks pgpwlwIKa9BIq.pgp Description: PGP signature
Re: Can we please just remove the old Makefile headers?
On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote: > The old Makefile headers, ala: > > # New ports collection makefile for:BIND 9.9.x > # Date created: 27 January 2012 > # Whom: dougb > # > # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ > > have not served a purpose for longer than almost anyone who has a ports > commit bit has been around. My proposal is simple, let's remove > everything before the # $FreeBSD$. > > In the past when this has been proposed the objection was that it would > cause too much churn. If we had done this back when we had 5,000 ports > then we would have solved the problem with less churn, and no drama for > the 15,000 ports that followed. Every day we don't do this we make the > "churn" problem worse, and deepen the roots of something that has no > relevance. > > Can we please just deal with this now and be done with it? ... and yes, > I am volunteering to help with and/or do the work myself. Yes please! We've got a nice repository that stores all the data in question much more accurately than a silly header. -- Brooks pgppCJv0YgbyO.pgp Description: PGP signature
Re: www/libxul: fails to compile with CLANG and fails to install with GCC
On Wed, Sep 19, 2012 at 03:50:45PM +0200, O. Hartmann wrote: > I already filed a PR (ports/171566) regarding the CLANG compilation > issue, but since CLANG is a troublemaker for several ports, I also used > USE_GCC=4.6 to compile the port www/libxul and this works - but fails > then installing with > > [...] > adding: hyphenation/hyph_hu.dic (deflated 62%) > /usr/ports/www/libxul/work/mozilla-esr10/dist/bin/xpcshell: Undefined > symbol "JSVAL_NULL" > gmake[1]: *** [install] Error 1 > gmake[1]: Leaving directory > `/usr/ports/www/libxul/work/mozilla-esr10/xulrunner/installer' > gmake: *** [install] Error 2 > *** [gecko-pre-install] Error code 2 > > Stop in /usr/ports/www/libxul. > *** [install] Error code 1 Hmm. Sounds like a miscompile. If you're up for an experiment, I'd be interested in the results of applying the linked patch and building with USE_GCC=4.2. http://people.freebsd.org/~brooks/patches/really-use-gcc.diff It turns out that USE_GCC incorrectly assumes that CC/CPP/CXX don't need to be changed when the requested version of gcc is in the base system. -- Brooks pgpILvFJySm9F.pgp Description: PGP signature
Re: something had broken in *.mk?
On Wed, Oct 17, 2012 at 02:52:05PM +0200, John Marino wrote: > On 10/17/2012 14:30, Baptiste Daroussin wrote: > > > I don't know much about this, I just know that current is going to use > > bmake, > > and the only incompatibility I have spotted so far from our make to bmake > > is the > > :L becoming :tl and :U becoming :tu > > > > Once 8.3 and 9.0 are EOLed all version of freebsd make support both syntax, > > so > > the ports could safely use both bmake and make (once we change in the ports > > tree > > all the :U and :L occurence.) > > > > which means everything should just continue working ootb for everyone on > > supported version of FreeBSD :) > > > > regards, > > Bapt > > The incompatible "-V" switch causes problems too. There is quite a few > uses of -V in bsd.*.mk. This has been fixed. The behavior of -V is configurable based on a variable in the most recent release and this will be set in sys.mk to preserve the more sensible FreeBSD behavior. -- Brooks pgpSleZqLA7uZ.pgp Description: PGP signature
Re: git checkout branch in makefile
On Mon, Jul 09, 2018 at 08:19:13PM +0200, Michael Gmelin wrote: > > > > On 9. Jul 2018, at 19:34, blubee blubeeme wrote: > > > > Is it possible to do a git checkout of a specific branch in a ports > > makefile? > > > > How would I go about checking out a particular branch from a github project. > > As branches aren???t stable this won???t buy you anything, that???s why you > should always go for a tag or commit (which is branch agnostic). If you want to make it easy to update to the latest commit on a branch, take a look at devel/llvm-devel/files/gen-Makefile.snapshot.sh for an example of automatically extracting that information from the github API. -- Brooks signature.asc Description: PGP signature
Re: sphinx-build not found
On Fri, Jan 18, 2019 at 05:03:54PM -0700, Russell L. Carter wrote: > Greetings, > > Quite a few ports are now being skipped by the not unheard of > problem with "sphinx-build not found". Including llvm6 and 7. > I've checked UPDATING and google, but no hints, other than this > problem has happened in the past. > > Is there something I can do or should I just be patient? NBD > if I need to be patient. Hmm, textproc/py-sphinx should be installing sphinx-build. I wonder if there's an edge case your config is triggering where the flavor that gets installed isn't the one with the unversioned script. I'd rather not depend on a fixed flavor in llvm[67]0, but if there's someting I'm not understanding about python port flavors, I could follow what I did in llvm-devel to allow py-recommonmark to work reliably. -- Brooks signature.asc Description: PGP signature
LLVM 7.1.0: how to proceed?
LLVM 7.1.0 will be release shortly and contains a single fix which breaks the LLVM Libra ABI in order to fix an incompatibility with GCC 8.2. A bug describing the issue is at https://bugs.llvm.org/show_bug.cgi?id=39427. My current plan is: - Copy devel/llvm70 to devel/llvm71 and update. - Perform a coordinated switch of all dependencies, to llvm71 (e.g. do an exp-run with the switch made and llvm70 removed). All ports with library dependencies would get PORT_REVISION bumps. - DEPRECATE llvm70 and set a short expiration. Does this sound like a reasonable plan? -- Brooks signature.asc Description: PGP signature
Re: devel/llvm80 requires many python 2.7 ports?
On Thu, Jul 25, 2019 at 02:57:29PM -0700, Kevin Oberman wrote: > I just went to build llvm80 after discovering that I could not install the > package without moving from the drfault samba48 back to the deprecated > samba47. > > When I try to build the port, I get: > Upgrade llvm80-8.0.0_2 to llvm80-8.0.1 > Install textproc/py-recommonmark@py27 > Install textproc/py-docutils@py27 > Install textproc/py-sphinx@py27 > Install devel/py-Jinja2@py27 > Install devel/py-babel@py27 > Install devel/py-pytz@py27 > Install textproc/py-MarkupSafe@py27 > Install devel/py-typing@py27 > Install graphics/py-imagesize@py27 > Install textproc/py-alabaster@py27 > Install textproc/py-pygments@py27 > Install textproc/py-snowballstemmer@py27 > Install textproc/py-pystemmer@py27 > Install textproc/py-sphinx_rtd_theme@py27 > Install textproc/py-sphinxcontrib-websupport@py27 > Install www/py-requests@py27 > Install dns/py-idna@py27 > Install net/py-urllib3@py27 > Install net/py-ipaddress@py27 > Install net/py-pysocks@py27 > Install security/py-certifi@py27 > Install security/py-cryptography@py27 > Install devel/py-asn1crypto@py27 > Install devel/py-cffi@py27 > Install devel/py-pycparser@py27 > Install security/py-openssl@py27 > Install textproc/py-chardet@py27 > Install devel/py-pytest-runner@py27 > Install devel/py-setuptools_scm@py27 > > Is llvm80 really still stuck using v2 Python? I looked at the very complex > Makefile, and it's very clear: _USES_PYTHON?= python:2.7,build > > Will this going away some day soon? I know that end of 2.7 support is > approaching and I have only a handfull of python 2.7 ports left, mostly to > support print/hplip (HP printer drivers for CUPS) and hope to get rid of > them soime day soon. Historically LLVM has required Python v2. I've not checked if 8.0.1 can be pinned to 3.6 like I've done with llvm-devel. llvm90 (coming soon) will use python 3.6. I'll keep switching llvm80 in mind, but given that such a change will require everyone to rebuild it I'll probably wait and combine it with other changes. -- Brooks signature.asc Description: PGP signature
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
I'd prefer to disable this dependency. There's a knob that worked in the 8.0 timeframe, but the lit build now autodetects z3 when it is present and I've failed to find a knob to disable it. For now, the easy workaround is probably to disable options LIT. We could make that the default on non-LLVM platforms is that makes sense. -- Brooks On Mon, Aug 05, 2019 at 08:45:31PM -0700, Mark Millard via freebsd-toolchain wrote: > Building math/z3 involves: > > # grep compiler /usr/ports/math/z3/Makefile > USES= compiler:c++11-lang python:2.7,build > > But devel/llvm90 requires math/z3 to have been built before > devel/llvm90 is built: > > # pkg info -d llvm90 > llvm90-9.0.0.r1: > libxml2-2.9.9 > z3-4.8.5_1 > python36-3.6.9 > perl5-5.28.2 > libedit-3.1.20190324,1 > # pkg info -B llvm90 > llvm90-9.0.0.r1: > libpython3.6m.so.1.0 > libedit.so.0 > libz3.so.0 > libxml2.so.2 > > > Hopefully this cycle can be avoided for system > clang to eventually have progressed to clang 9. > (I do not know the details.) > > For architectures still at gcc/g++ 4.2.1, some > alternate c++ tool chain needs to be used to > build libz3.so but the result needs to be > compatible with llvm90 later using the libz3.so's > content. (I do not know the details.) > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > freebsd-toolch...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" > signature.asc Description: PGP signature
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote: > > > On 2019-Aug-6, at 09:55, Brooks Davis wrote: > > > I'd prefer to disable this dependency. There's a knob that worked in > > the 8.0 timeframe, but the lit build now autodetects z3 when it is > > present and I've failed to find a knob to disable it. For now, the easy > > workaround is probably to disable options LIT. We could make that the > > default on non-LLVM platforms is that makes sense. > > > > -- Brooks > > Okay. > > poudriere-devel automatically built math/z3 because > I'd indicated to build devel/llvm90 . math/z3 was not > previously built: I've never had other use of it. So > my context was not one of an implicit autodetect. The dependency is there because if z3 is installed then the package that is built depends on z3. Thus I had not choice but to add a z3 dependency until I find a way to turn it off. You can either help find a way to disable z3 detection in the cmake infrastructure or turn off LIT. I don't have any use for reports on the effects of commenting out the DEPENDS line. I know what that does. -- Brooks signature.asc Description: PGP signature
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> [I found something known to be missing in the
> in at least some versions of
> llvm/cmake/modules/CrossCompile.cmake that messes
> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
>
> On 2019-Aug-6, at 20:23, Mark Millard wrote:
>
>
>
> > On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> >
> >> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> >>>
> >>>
> >>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> >>>
> >>>> I'd prefer to disable this dependency. There's a knob that worked in
> >>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> >>>> present and I've failed to find a knob to disable it. For now, the easy
> >>>> workaround is probably to disable options LIT. We could make that the
> >>>> default on non-LLVM platforms is that makes sense.
> >>>>
> >>>> -- Brooks
> >>>
> >>> Okay.
> >>>
> >>> poudriere-devel automatically built math/z3 because
> >>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>> previously built: I've never had other use of it. So
> >>> my context was not one of an implicit autodetect.
> >>
> >> The dependency is there because if z3 is installed then the package
> >> that is built depends on z3. Thus I had not choice but to add a z3
> >> dependency until I find a way to turn it off. You can either help find
> >> a way to disable z3 detection in the cmake infrastructure or turn off
> >> LIT. I don't have any use for reports on the effects of commenting out
> >> the DEPENDS line. I know what that does.
> >
> >
> > I hope this helps. (I'm not a cmake expert.)
> >
> > llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >
> > #if LLVM_WITH_Z3
> >
> > #include
> >
> > namespace {
> > . . .
> > } // end anonymous namespace
> >
> > #endif
> >
> > llvm::SMTSolverRef llvm::CreateZ3Solver() {
> > #if LLVM_WITH_Z3
> > return llvm::make_unique();
> > #else
> > llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild "
> > "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> > false);
> > return nullptr;
> > #endif
> > }
> >
> > (There are other places LLVM_WITH_Z3 is used but the
> > above is suggestive.)
> >
> > Working backwards finds that:
> >
> > /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> >
> > shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> >
> > set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> > solver.")
> >
> > find_package(Z3 4.7.1)
> >
> > if (LLVM_Z3_INSTALL_DIR)
> > if (NOT Z3_FOUND)
> >message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> > LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> > endif()
> > endif()
> >
> > set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> >
> > option(LLVM_ENABLE_Z3_SOLVER
> > "Enable Support for the Z3 constraint solver in LLVM."
> > ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
> > )
> >
> > if (LLVM_ENABLE_Z3_SOLVER)
> > if (NOT Z3_FOUND)
> >message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is
> > not available.")
> > endif()
> >
> > set(LLVM_WITH_Z3 1)
> > endif()
> >
> > if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
> > set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
> > endif()
> >
> >
> > If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
> > appears to override the default (that tracks if z3 was found).
>
> I saw a reference to:
>
> diff --git a/llvm/cmake/modules/CrossCompile.cmake
> b/llvm/cmake/modules/CrossCompile.cmake
> index bc3b210f018..0c30b88f80f 100644
> --- a/llvm/cmake/modules/CrossCompile.cmake
> +++ b/llvm/cmake/modules/CrossCompile.cmake
> @@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal target_name
> toolchain buildtype)
> -DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
> -DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
>
> -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="${LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN}"
> +-DLLVM_ENABLE_
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> > [I found something known to be missing in the
> > in at least some versions of
> > llvm/cmake/modules/CrossCompile.cmake that messes
> > up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >
> > On 2019-Aug-6, at 20:23, Mark Millard wrote:
> >
> >
> >
> > > On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> > >
> > >> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> > >>>
> > >>>
> > >>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> > >>>
> > >>>> I'd prefer to disable this dependency. There's a knob that worked in
> > >>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> > >>>> present and I've failed to find a knob to disable it. For now, the
> > >>>> easy
> > >>>> workaround is probably to disable options LIT. We could make that the
> > >>>> default on non-LLVM platforms is that makes sense.
> > >>>>
> > >>>> -- Brooks
> > >>>
> > >>> Okay.
> > >>>
> > >>> poudriere-devel automatically built math/z3 because
> > >>> I'd indicated to build devel/llvm90 . math/z3 was not
> > >>> previously built: I've never had other use of it. So
> > >>> my context was not one of an implicit autodetect.
> > >>
> > >> The dependency is there because if z3 is installed then the package
> > >> that is built depends on z3. Thus I had not choice but to add a z3
> > >> dependency until I find a way to turn it off. You can either help find
> > >> a way to disable z3 detection in the cmake infrastructure or turn off
> > >> LIT. I don't have any use for reports on the effects of commenting out
> > >> the DEPENDS line. I know what that does.
> > >
> > >
> > > I hope this helps. (I'm not a cmake expert.)
> > >
> > > llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> > >
> > > #if LLVM_WITH_Z3
> > >
> > > #include
> > >
> > > namespace {
> > > . . .
> > > } // end anonymous namespace
> > >
> > > #endif
> > >
> > > llvm::SMTSolverRef llvm::CreateZ3Solver() {
> > > #if LLVM_WITH_Z3
> > > return llvm::make_unique();
> > > #else
> > > llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild
> > > "
> > > "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> > > false);
> > > return nullptr;
> > > #endif
> > > }
> > >
> > > (There are other places LLVM_WITH_Z3 is used but the
> > > above is suggestive.)
> > >
> > > Working backwards finds that:
> > >
> > > /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> > >
> > > shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> > >
> > > set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> > > solver.")
> > >
> > > find_package(Z3 4.7.1)
> > >
> > > if (LLVM_Z3_INSTALL_DIR)
> > > if (NOT Z3_FOUND)
> > >message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> > > LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> > > endif()
> > > endif()
> > >
> > > set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> > >
> > > option(LLVM_ENABLE_Z3_SOLVER
> > > "Enable Support for the Z3 constraint solver in LLVM."
> > > ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
> > > )
> > >
> > > if (LLVM_ENABLE_Z3_SOLVER)
> > > if (NOT Z3_FOUND)
> > >message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3
> > > is not available.")
> > > endif()
> > >
> > > set(LLVM_WITH_Z3 1)
> > > endif()
> > >
> > > if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
> > > set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
> > > endif()
> > >
> > >
> > > If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
> > > appears to override the default (that tracks if z3 was found
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
>
>
> On 2019-Aug-7, at 11:02, Brooks Davis wrote:
>
> > On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
> >> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> >>> [I found something known to be missing in the
> >>> in at least some versions of
> >>> llvm/cmake/modules/CrossCompile.cmake that messes
> >>> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >>>
> >>> On 2019-Aug-6, at 20:23, Mark Millard wrote:
> >>>
> >>>
> >>>
> >>>> On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> >>>>
> >>>>> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> >>>>>>
> >>>>>>> I'd prefer to disable this dependency. There's a knob that worked in
> >>>>>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> >>>>>>> present and I've failed to find a knob to disable it. For now, the
> >>>>>>> easy
> >>>>>>> workaround is probably to disable options LIT. We could make that the
> >>>>>>> default on non-LLVM platforms is that makes sense.
> >>>>>>>
> >>>>>>> -- Brooks
> >>>>>>
> >>>>>> Okay.
> >>>>>>
> >>>>>> poudriere-devel automatically built math/z3 because
> >>>>>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>>>>> previously built: I've never had other use of it. So
> >>>>>> my context was not one of an implicit autodetect.
> >>>>>
> >>>>> The dependency is there because if z3 is installed then the package
> >>>>> that is built depends on z3. Thus I had not choice but to add a z3
> >>>>> dependency until I find a way to turn it off. You can either help find
> >>>>> a way to disable z3 detection in the cmake infrastructure or turn off
> >>>>> LIT. I don't have any use for reports on the effects of commenting out
> >>>>> the DEPENDS line. I know what that does.
> >>>>
> >>>>
> >>>> I hope this helps. (I'm not a cmake expert.)
> >>>>
> >>>> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >>>>
> >>>> #if LLVM_WITH_Z3
> >>>>
> >>>> #include
> >>>>
> >>>> namespace {
> >>>> . . .
> >>>> } // end anonymous namespace
> >>>>
> >>>> #endif
> >>>>
> >>>> llvm::SMTSolverRef llvm::CreateZ3Solver() {
> >>>> #if LLVM_WITH_Z3
> >>>> return llvm::make_unique();
> >>>> #else
> >>>> llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild
> >>>> "
> >>>> "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> >>>> false);
> >>>> return nullptr;
> >>>> #endif
> >>>> }
> >>>>
> >>>> (There are other places LLVM_WITH_Z3 is used but the
> >>>> above is suggestive.)
> >>>>
> >>>> Working backwards finds that:
> >>>>
> >>>> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> >>>>
> >>>> shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> >>>>
> >>>> set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> >>>> solver.")
> >>>>
> >>>> find_package(Z3 4.7.1)
> >>>>
> >>>> if (LLVM_Z3_INSTALL_DIR)
> >>>> if (NOT Z3_FOUND)
> >>>> message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> >>>> LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> >>>> endif()
> >>>> endif()
> >>>>
> >>>> set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> >>>>
> >>>> option(LLVM_ENABLE_Z3_SOLVER
> >>>> "Enable Support for the Z3 con
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Wed, Aug 07, 2019 at 01:42:26PM -0700, Mark Millard wrote:
>
>
> On 2019-Aug-7, at 12:56, Brooks Davis wrote:
>
> > On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
> >>
> >>
> >> On 2019-Aug-7, at 11:02, Brooks Davis wrote:
> >>
> >>> On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
> >>>> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> >>>>> [I found something known to be missing in the
> >>>>> in at least some versions of
> >>>>> llvm/cmake/modules/CrossCompile.cmake that messes
> >>>>> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >>>>>
> >>>>> On 2019-Aug-6, at 20:23, Mark Millard wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> >>>>>>
> >>>>>>> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> >>>>>>>>
> >>>>>>>>> I'd prefer to disable this dependency. There's a knob that worked
> >>>>>>>>> in
> >>>>>>>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> >>>>>>>>> present and I've failed to find a knob to disable it. For now, the
> >>>>>>>>> easy
> >>>>>>>>> workaround is probably to disable options LIT. We could make that
> >>>>>>>>> the
> >>>>>>>>> default on non-LLVM platforms is that makes sense.
> >>>>>>>>>
> >>>>>>>>> -- Brooks
> >>>>>>>>
> >>>>>>>> Okay.
> >>>>>>>>
> >>>>>>>> poudriere-devel automatically built math/z3 because
> >>>>>>>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>>>>>>> previously built: I've never had other use of it. So
> >>>>>>>> my context was not one of an implicit autodetect.
> >>>>>>>
> >>>>>>> The dependency is there because if z3 is installed then the package
> >>>>>>> that is built depends on z3. Thus I had not choice but to add a z3
> >>>>>>> dependency until I find a way to turn it off. You can either help
> >>>>>>> find
> >>>>>>> a way to disable z3 detection in the cmake infrastructure or turn off
> >>>>>>> LIT. I don't have any use for reports on the effects of commenting
> >>>>>>> out
> >>>>>>> the DEPENDS line. I know what that does.
> >>>>>>
> >>>>>>
> >>>>>> I hope this helps. (I'm not a cmake expert.)
> >>>>>>
> >>>>>> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >>>>>>
> >>>>>> #if LLVM_WITH_Z3
> >>>>>>
> >>>>>> #include
> >>>>>>
> >>>>>> namespace {
> >>>>>> . . .
> >>>>>> } // end anonymous namespace
> >>>>>>
> >>>>>> #endif
> >>>>>>
> >>>>>> llvm::SMTSolverRef llvm::CreateZ3Solver() {
> >>>>>> #if LLVM_WITH_Z3
> >>>>>> return llvm::make_unique();
> >>>>>> #else
> >>>>>> llvm::report_fatal_error("LLVM was not compiled with Z3 support,
> >>>>>> rebuild "
> >>>>>> "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> >>>>>> false);
> >>>>>> return nullptr;
> >>>>>> #endif
> >>>>>> }
> >>>>>>
> >>>>>> (There are other places LLVM_WITH_Z3 is used but the
> >>>>>> above is suggestive.)
> >>>>>>
> >>>>>> Working backwards finds that:
> >>>>>>
> >>>>>> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMa
Re: Checking you the maintainer of a port?
On Wed, Nov 27, 2019 at 02:05:56PM -0700, Janky Jay, III wrote: > Hello, > > On 11/27/19 2:03 PM, @lbutlr wrote: > > I thought that the maintainer of a port was listed somewhere in the files > > at user/ports//portbase/ but evidently not. What is the easiest way > > to find out, sitting in console on a server without a GUI, to find out who > > the maintainer is? (On my desktop I can just google and launch a browser, > > but that is not possible on most of the servers which do not have web > > clients installed. > > > > (Right now I am looking for the maintainer of roundcube, but this is a > > general question.) > > > > Please see the "MAINTAINER=" line in the port's "Makefile". A slightly more general answer is: cd /usr/ports//; make -V MAINTAINER -- Brooks signature.asc Description: PGP signature
Re: devel/llvm80 port on 12.1
On Thu, Dec 12, 2019 at 04:42:07PM +0100, Lars Engels wrote: > I'm trying reduce the size of the NomadBSD image and the biggest > installed package is devel/llvm80 with 848 MiB. > llvm80 is a dependency of graphics/mesa-dri which is needed for > x11-servers/xorg-server. > > Looking at the llvm version of 12.1-RELEASE in base I see that it is the > same version like the installed port: > > $ /usr/bin/clang --version > FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM > 8.0.1) > Target: x86_64-unknown-freebsd12.1 > Thread model: posix > InstalledDir: /usr/bin > > $ /usr/local/llvm80/bin/clang --version > clang version 8.0.1 (tags/RELEASE_801/final) > Target: x86_64-portbld-freebsd12.0 > Thread model: posix > InstalledDir: /usr/local/llvm80/bin > > So it looks like on 12.1 the mesa-dri port can use the base llvm instead > of the one from ports and save all people running Xorg almost 1 GB of > disk space? Nope. Mesa uses LLVM library ABIs which provide NO stability guarantees so we can not publish them as part of the release without locking the branch to a single LLVM version for the 5-year life (we effectively tried that with 10.x, it was terrible with many ports requiring workarounds for the increasingly obsolete base compiler). If you want to save space here, help out on the subpackage work so you only need to depend on the libraries. https://reviews.freebsd.org/D16457 -- Brooks signature.asc Description: PGP signature
Re: amd64->{armv7,aarc64} cross builds of devel/llvm10 (via poudriere-devel): failed in package stage for missing libarcher* files
Fixed in r526532. Thanks for the hint that it was in OPENMP. -- Brooks On Mon, Feb 17, 2020 at 08:19:26PM -0800, Mark Millard wrote: > On 2020-Feb-17, at 09:56, Mark Millard wrote: > > > On 2020-Feb-17, at 09:53, Mark Millard wrote: > > > >> [The native arm64 build worked fine. But the cross builds > >> got . . .] > >> > >> The builds failed with: > >> > >> > Compressing man pages (compress-man) > >> ===> Installing ldconfig configuration file > >> === > >> === > >> ===> Building package for llvm10-10.0.0.r1_1 > >> pkg-static: Unable to access file > >> /wrkdirs/usr/ports/devel/llvm10/work/stageusr/local/llvm10/lib/libarcher.so:No > >> such file or directory > >> pkg-static: Unable to access file > >> /wrkdirs/usr/ports/devel/llvm10/work/stageusr/local/llvm10/lib/libarcher_static.a:No > >> such file or directory > >> *** Error code 1 > >> > >> Stop. > >> make: stopped in /usr/ports/devel/llvm10 > >> =>> Cleaning up wrkdir > >> ===> Cleaning for llvm10-10.0.0.r1_1 > >> > >> > >> head -r3577979 based system source; head -r536339 based ports tree. > >> > > > > I forgot to list: > > > > ===> The following configuration options are available for > > llvm10-10.0.0.r1_1: > > BE_AMDGPU=on: AMD GPU backend (required by mesa) > > CLANG=on: Build clang > > DOCS=on: Build and/or install documentation > > EXTRAS=on: Extra clang tools > > LIT=on: Install lit and FileCheck test tools > > LLD=on: Install lld, the LLVM linker > > LLDB=on: Install lldb, the LLVM debugger > > LLD_LINK=on: Link ld.lld as ld to clang uses it > > PYCLANG=off: Install python bindings to libclang > > > Options available for the single BACKENDS: you have to select exactly > > one of them > > BE_FREEBSD=off: Backends for FreeBSD architectures > > BE_NATIVE=on: Backend(s) for this architecture (ARM) > > BE_STANDARD=off: All non-experimental backends > > > > > llvm10-10.0.0.r2 gets the same. > > I was curious what the libarcher* files would be tied to > and found that libarcher is a tool library for an llvm > openmp tool. > > But openmp does not seem to be available for armv7 or > aarch64 so the file is not expected to be present for > installation, much like libgomp.so , liniomp5.so , > libomp.so , and libomptarget.so . Looks like a > %%OPENMP%% prefix is needed in llvm10/pkg-plist for > each of the two libarcher lines. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > signature.asc Description: PGP signature
Re: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote: > I'm testing modifications of ports I maintain in > a jail. I have nothing in make.conf(5) except > DEVELOPER=true > But I get messages regarding python versions like: > llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. > But I make no demands on versions. > What causes this, and how can I stop it. :) Is your set of packages fully up to date? IIRC other have had issues when they tried to install LLVM with out of date dependencies. -- Brooks signature.asc Description: PGP signature
Re: Poudriere make.conf documentation question
On Fri, Apr 17, 2020 at 09:42:51AM -0700, Jose Quinteiro wrote: > Hello, > > The Handbook says: > "The system make.conf and this new file are combined at build time to > create the make.conf used by the build jail." > https://www.freebsd.org/doc/handbook/ports-poudriere.html > > The poudriere man page and Porter's Handbook do not mention > /etc/make.conf as a file that will get used. > > My simple test did not work with /etc/make.conf, but I also suspect I > screwed something else up. > > Does /etc/make.conf get "combined" into the effective make.conf for > Poudriere? I think that documentation is confusing as is the manpage. I think that the webpage is refering to the first one in the list below not /etc/make.conf, but I could be wrong. Here's the relevent bit of the manpage: Create optional make.conf You can also specify a global make.conf which will be used for all the jails. Any of the following are allowed and will all be used in the order shown: /usr/local/etc/poudriere.d/make.conf /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/--make.conf /usr/local/etc/poudriere.d/--make.conf /usr/local/etc/poudriere.d/--make.conf /usr/local/etc/poudriere.d/---make.conf /usr/local/etc/poudriere.d/hooks/plugins//make.conf -- Brooks signature.asc Description: PGP signature
Re: Fwd: AFFECTS: users of devel/kuya
Thanks for the report, I make that typo all the time. Thanks also to bapt@ for fixing. -- Brooks On Thu, Apr 23, 2020 at 08:16:59AM +0200, Andrea Venturoli wrote: > Hello. > > Should that be devel/kyua? > > Not to be nitpicking, but someone might try grep on UPDATING :) > > bye > av. > > > Forwarded Message > Subject: AFFECTS: users of devel/kuya > Date: Wed, 22 Apr 2020 00:00:00 GMT > From: Alexander Kojevnikov > > > > AFFECTS: users of devel/kuya > > 20200422: > AFFECTS: users of devel/kuya > AUTHOR: bro...@freebsd.org > > A tests group has been added and the tests user should be a member > of it by default rather than nobody. You should update your password > database to match (change the group from 65534 to 977 after updating). > > ___ > 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" > signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Fri, Aug 07, 2020 at 11:48:34AM -0400, Greg Veldman wrote: > On Fri, Aug 07, 2020 at 03:43:38PM +0200, Michael Gmelin wrote: > > The real question is: Will we design things in a way that we expect ports > > tree users to always install git and its dependencies on their system or > > not (long term)? > > > > For developers it???s a no-brainer (obviously yes), but ports tree users > > aren???t developers. > > Or alternatively, will there be a git/gitlite or similar utility > included in base that can be used to bootstrap one's ports tree? We'd love to have something, but we aren't going to hold up progress indefinitely waiting for one to be implemented in an acceptable language with an acceptable license. -- Brooks signature.asc Description: PGP signature
Re: devel/llvm11 failed to build
On Wed, Dec 02, 2020 at 09:20:00AM +0900, KIRIYAMA Kazuhiko wrote:
> Hi, all
>
> I've changed Makefile so as to include *mmintrin.h as
> follows:
>
> --- /home/kiri/work/ports/head/devel/llvm11/Makefile 2020-11-09
> 12:30:07.0 +0900
> +++ llvm11/Makefile 2020-11-29 17:12:58.544495000 +0900
> @@ -59,8 +59,8 @@
>
> # Disable assertions. They should be disabled by cmake, but USES=cmake
> # overrides -DCMAKE_*_FLAGS_RELEASE.
> -CFLAGS+= -DNDEBUG
> -CXXFLAGS+= -DNDEBUG
> +CFLAGS+= -DNDEBUG -DNO_WARN_X86_INTRINSICS
> -I${WRKSRC}/tools/clang/lib/Headers/ppc_wrappers
> +CXXFLAGS+= -DNDEBUG -DNO_WARN_X86_INTRINSICS
> -I${WRKSRC}/tools/clang/lib/Headers/ppc_wrappers
>
> OPTIONS_DEFINE= BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLD_LINK LLDB
> PYCLANG
> OPTIONS_DEFINE_aarch64= OPENMP
>
> and `make install' devel/llvm11, but failed to build:
...
> May circumstances are as follows:
>
> root@jdtpkxb:~ # uname -a
> FreeBSD jdtpkxb 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r367712M: Tue Nov 17
> 01:35:26 JST 2020 root@msrvkxb:/usr/obj/usr/src/amd64.amd64/sys/XIJ amd64
> root@jdtpkxb:~ # svnlite info /usr/ports
> Path: /usr/ports
> Working Copy Root Path: /usr/ports
> URL: http://svn.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: http://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 555444
> Node Kind: directory
> Schedule: normal
> Last Changed Author: lwhsu
> Last Changed Rev: 555444
> Last Changed Date: 2020-11-16 11:44:38 +0900 (Mon, 16 Nov 2020)
>
> root@jdtpkxb:~ #
>
> What should I do ?
I can't understand what you think this patch will do. You're causing
PowerPC intrinsic headers to be included while building for amd64. I
don't see how that could work.
-- Brooks
signature.asc
Description: PGP signature
Re: Any plan to fix ports git main history compatibility with old GitHub master?
On Mon, Apr 05, 2021 at 05:33:08PM -0300, Eric Turgeon wrote: > Today when trying to sync the GhostBSD ports tree with the FreeBSD ports > tree, I found out the main branch history is not compatible with the old > GitHub master. > > Any plan to migrate to main with hold git history as we had with > freebsd-src? The main branch will contain a commit which is identical to the last commit of the old master branch (except for the hash). If the GhostBSD repo is merged up to that point, you can then merge the matching commit from main and proceed with using main as the source for future merges. If you have outstanding WIPs the process of updating them to the new history should be about the same as the one for source: https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/articles/committers-guide/_index.adoc#562-migrating-from-github-fork -- Brooks signature.asc Description: PGP signature
Re: Large builds with poudriere
On Thu, May 20, 2021 at 03:09:32PM -0700, Mark Millard wrote:
> Kevin Oberman rkoberman at gmail.com wrote on
> Thu May 20 21:37:28 UTC 2021 :
>
> > On Thu, May 20, 2021 at 12:48 PM Mark Millard wrote:
> >
> > > Kevin Oberman rkoberman at gmail.com wrote on
> > > Thu May 20 19:21:24 UTC 2021 :
> > >
> > > > You can greatly reduce the build-time for devel/llvm* by changing the
> > > > config to BE_NATIVE to avoid building backends for all FreeBSD supported
> > > > platforms. Obviously this is not acceptable for many cases, but if you
> > > > never cross-compile for other platforms, it's a really big win.
> > >
> > >
> > > Unfortunately, using something like (llvm10 is just one example,
> > > llvm11 showed the same sort of problem at the time):
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU
> > > CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD
> > > BE_NATIVE
> > > BE_STANDARD
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD
> > >
> > > does not work for all platforms/targets. On a Cortex-A57
> > > this lead to:
> > >
> > > Registered Targets:
> > > amdgcn - AMD GCN GPUs
> > > r600 - AMD GPUs HD2XXX-HD6XXX
> > >
> > > In other words, aarch64 was missing. I had to pick
> > > BE_STANDARD or BE_FREEBSD to get something that
> > > would target aarch64 on aarch64.
> > >
> > > ===
> > > Mark Millard
> > > marklmi at yahoo.com
> > > ( dsl-only.net went
> > > away in early 2018-Mar)
> > >
> > Looks like the Makefile might need some work. I see stuff for handling
> > aach64/arm64, so it SHOULD work, but there are things I don't understand
> > about AARCH64 to figure it all out. Still, it should be detected.
> >
> > Out of curiosity, if you do a "make -C /usr/ports/devel/llvm10 config",
> > the line for BE_NATIVE should show the architecture you are running on. If
> > it's missing/something else, maybe you should ask brooks@ about it.
>
>
> On two types of Cortex-A72 context
> # make -C /usr/ports/devel/llvm10 config
>
> produced:
>
> BE_NATIVE Backend(s) for this architecture ()
>
> The same for each of:
>
> # make -C /usr/ports/devel/llvm80 config
> # make -C /usr/ports/devel/llvm90 config
> # make -C /usr/ports/devel/llvm11 config
> # make -C /usr/ports/devel/llvm12 config
>
> But this turns out to be because:
>
> # make -C /usr/ports/devel/llvm10 -V ARCH
> aarch64
>
> yet the Makefiles have a test for arm64 instead:
>
> .elif ${ARCH} == arm64
> _NATIVE_BACKENDS= AAarch64
Ah, that's the key point. I've fixed the ARCH value and fixed the
spelling of AArch64 in older ports where it was wrong.
-- Brooks
signature.asc
Description: PGP signature
Re: Dropbox on FreeBSD
On Thu, Dec 20, 2012 at 10:07:05AM -0500, Jerry wrote: > On Thu, 20 Dec 2012 13:45:13 + > Chris Rees articulated: > > > It needs porting to kevent. > > > > Someone may do it for payment, some may do it for fun, but no-one > > will do it for you until you learn some manners. > > > > Or you could do it yourself. > > I have suggested several times that FreeBSD create a fund specifically > for the hiring of professional programmers to take care of these edge > problems. There is such a fund. http://www.freebsdfoundation.org/donate/ -- Brooks pgpz9vDVPXLPH.pgp Description: PGP signature
Re: llvm-3.2 tarball rerolled?
On Mon, Jan 14, 2013 at 11:26:40AM +0100, Per olof Ljungmark wrote: > On 2013-01-13 16:00, Dimitry Andric wrote: > > On 2013-01-12 22:54, Ion-Mihai Tetcu wrote: > >> I'm seeing this size mismatch, any idea what it is about? > >> > >> root(itetcu)@it/SU >-SSH-> /usr/ports/devel/llvm [23:50:47] 0 > >> # make > >> ===> Found saved configuration for llvm-3.1 > >> => llvm-3.2.src.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > >> => Attempting to fetch http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz > >> fetch: http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz: size > >> mismatch: expected 12275252, actual 12275082 > >> => Attempting to fetch > >> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/llvm-3.2.src.tar.gz > >> fetch: > >> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/llvm-3.2.src.tar.gz: > >> File unavailable (e.g., file not found, no access) > >> => Couldn't fetch it - please try to retrieve this > > > > See the (rather long) thread starting here: > > > >http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/057964.html > > > > Short version: the tarball got re-rolled because somebody noticed an > > obsolete directory in it. Stupid, but probably just a mistake. > > > > The complete difference of the old and new tarballs, extracted: > > > > $ diff -upr llvm-3.2.src-2012-12-21 llvm-3.2.src-2013-01-11 > > Only in llvm-3.2.src-2012-12-21/lib/Target: PTX > > Would it be possible for someone to put the old tarball back? Or are we > going to live with this for the moment? The LLVM project has restored the file after a fair bit of debate. Hopefully this won't happen again. -- Brooks pgpzrk4oRomZh.pgp Description: PGP signature
dropping maintainership of some ports
Due to a change of jobs I'm planning to drop maintainership of a number of ports I no longer use or have test systems for. If you would like to maintain them, please let me know: databases/nagios-check_postgres_replication net/openmpi net/pypvm net/vncreflector www/trac-addcomment www/trac-discussion www/trac-downloads www/trac-email2trac www/trac-email2trac-postfix www/trac-fivestarvote www/trac-fullblog www/trac-fullblognotification www/trac-graphviz www/trac-iniadmin www/trac-math www/trac-mercurial www/trac-navadd www/trac-pydotorgtheme www/trac-tags www/trac-themeengine www/trac-ticketimport www/trac-vote www/trac-wikitopdf Thanks, Brooks pgpAlLb3i_LzW.pgp Description: PGP signature
Re: CLANG 3.3/LLVM 3.3 question regarding devel/llvm vs. devel/llvm33
On Wed, Jul 10, 2013 at 09:32:36AM +0200, O. Hartmann wrote: > > No is 9.1-STABLE en route also equipted with CLANG 3.3, as it is with > CURRENT. The ports system still differs between the "standard" > devel/llvm, which is in fact LLVM 3.2 and devel/llvm33, which is then > LLVM 3.3. > > devel/llvm installs some tools not in the standard manner, like > llvm-config, which is then llvm-config33. This introduces some trouble > and it seems a bit "out of sync". > > Is there a chance that devel/llvm becomes llvm 3.3 in a short time? I'm in the process of moving to devel/llvm## + devel/llvm-devel and removing devel/llvm. As with the lang/gcc* ports all llvm and clang programs will be installed with a ## suffix. This rearrangement is a low priority at work and I needed to set up some internal infrastructure to make testing practical so I've not finished it up yet. -- Brooks pgpz851ML7ISf.pgp Description: PGP signature
Re: llvm33 update
On Thu, Oct 17, 2013 at 05:57:02AM -0400, Ajtim wrote: > Hi! > > I tried to update llvm33-3.3_4 to llvm33-3.3_5 on FreeBSD 10.0-BETA1 but > I got an error: > > Compressing man pages > ===> Installing ldconfig configuration file > ===> Installing for llvm33-3.3_5 > ===> Checking if devel/llvm33 already installed > ===> Registering installation for llvm33-3.3_5 as automatic > pkg-static: lstat(/usr/ports/devel/llvm33/work/stage/llvm33bin/lit): No > such file or directory pkg-static: > lstat(/usr/ports/devel/llvm33/work/stage/llvm33bin/llvm-lit): No such > file or directory pkg-static: > lstat(/usr/ports/devel/llvm33/work/stage/llvm33bin/FileCheck): No such > file or directory *** Error code 74 Fixed, please try again. I'm still getting the hang of testing with stage. It's much better that before, but my brain hadn't fully registerd the fact that plist changes have no effect until you restage. -- Brooks pgpJQ2YxxoJFd.pgp Description: PGP signature
Re: devel/llvm33 Makefile
I've committed a fix. If you don't need the extra asserts you probably
want to turn them off as they slow things down and break serveral llvm
consumers.
-- Brooks
On Tue, Oct 29, 2013 at 10:15:16PM +, Cary wrote:
> Hello,
>
> On 9.2-RELEASE llvm33-3.3_7 installation failed here:
>
> install -s -o root -g wheel -m 555
> /usr/ports/devel/llvm33/work/llvm-3.3.src/Release/bin/FileCheck
> / /usr/ports/devel/llvm33/work/stage/usr/local/llvm33/bin/
> install: /usr/ports/devel/llvm33/work/llvm-3.3.src/Release/bin/FileCheck: No
> such file or directory
>
> *** [post-install] Error code 71
>
> Stop in /usr/ports/devel/llvm33.
> *** [install] Error code 1
>
> Stop in /usr/ports/devel/llvm33.
>
>
>
> The file to be installed was:
> /usr/ports/devel/llvm33/work/llvm-3.3src/Release+Asserts/bin/FileCheck
>
> After patching Makefile installation succeeded.
> --
> c...@sdf.org
> SDF Public Access UNIX System - http://sdf.org
> 214c214
> < ${INSTALL_PROGRAM} ${WRKSRC}/Release/bin/FileCheck \
> ---
> > ${INSTALL_PROGRAM} ${WRKSRC}/Release+Asserts/bin/FileCheck \
> 226c226
> < TEST_CMD= '(cd ${WRKSRC}/test; ${SETENV} ${MAKE_ENV}
> LD_LIBRARY_PATH=${WRKSRC}/Release/lib ${GMAKE} check-local-lit)'
> ---
> > TEST_CMD= '(cd ${WRKSRC}/test; ${SETENV} ${MAKE_ENV}
> > LD_LIBRARY_PATH=${WRKSRC}/Release+Asserts/lib ${GMAKE} check-local-lit)'
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
pgpbxPP8MSOEY.pgp
Description: PGP signature
Re: Integrating Custom Ports
On Tue, Dec 10, 2013 at 12:03:46PM -0500, Rick Miller wrote: > On Tue, Dec 10, 2013 at 11:44 AM, Kris Moore wrote: > > > On 12/10/2013 09:37, Rick Miller wrote: > > > > > > This is my first foray into Ports beyond just installing what is > > available. > > > So, just looking for some feedback from others doing similar. Is there > > > someone that can provide a few pointers in putting together and managing > > > such a system? > > > > > > > Rick, > > > > So the way we've been doing it is with git. > > > > I started by forking the ports tree from here: > > > > https://github.com/freebsd/freebsd-ports/ > > > > After cloning the fork to disk, I added a new "remote" for the original > > ports tree: > > > > % git remote add freebsd https://github.com/freebsd/freebsd-ports.git > > > > I then added any custom ports / patches to our fork. When I want to > > import changes from upstream I just go to my fork and do a new pull: > > > > % git pull freebsd master > > > > Merge any conflicts and commit. > > > > Haha. Thanks, Kris! I was making this harder than it needed to be :) I > appreciate the simple solution! A couple more options: If you won't be modifying the upstream tree, it's quite plausible to merge a local directory into a portsnap managed ports tree using the -l option. For another option, portshaker lets you build custom port's tree from multiple sources. -- Brooks pgpswUVU463te.pgp Description: PGP signature
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)
It appears that I added powerpc64 (and several others) to the devel/llvm* ports version of this patch, but didn't do it for lang/clang*. I'll sync them up. -- Brooks On Tue, Mar 17, 2015 at 08:02:47PM -0700, Mark Millard wrote: > patch-utils_llvm-build_llvmbuild_main.py is missing a powerpc64 entry, such > as illustrated below. > > $ svnlite diff /usr/ports/lang/clang36 > Index: /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > === > --- /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > (revision 381120) > +++ /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > (working copy) > @@ -3,7 +3,7 @@ > > --- utils/llvm-build/llvmbuild/main.py.orig > +++ utils/llvm-build/llvmbuild/main.py > -@@ -633,7 +633,13 @@ > +@@ -633,7 +633,14 @@ > > # We handle a few special cases of target names here for historical > # reasons, as these are the names configure currently comes up with. > @@ -13,6 +13,7 @@ > + 'i386' : 'X86', > + 'mips' : 'Mips', > + 'powerpc' : 'PowerPC', > ++ 'powerpc64' : 'PowerPC', > + 'sparc64' : 'Sparc', > + 'x86' : 'X86', > 'x86_64' : 'X86', > > > === > Mark Millard > markmi at dsl-only.net > > On 2015-Mar-16, at 11:00 PM, Mark Millard wrote: > > The 2 powerpc (non-64) build attempts for clang 3.6 did not get this problem. > > So this specific problem is powerpc64 specific. > > Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current lang/gcc) > works fine. (In absence of any c++ port lang/clang36 automatically installed > lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.) > > Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 > already installed first) still reports an error for not declaring ::sscanf, > just like powerpc64 based on gcc5 for bootstrapping did. > > (This might be llvm/clang making use of only where an include of > would be required to be involved in order to guarantee the :: > (global) declaration/definition. The way the C++ standard (all vintages) is > written gcc 4.8.4 and gcc5 could be this different and both be > valid/conforming.) > > > === > Mark Millard > markmi at dsl-only.net > > On 2015-Mar-16, at 05:04 PM, Mark Millard wrote: > > Basic context (more context details listed later): > > # freebsd-version -ku; uname -ap > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 > 19:23:14 PDT 2015 > root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG > powerpc powerpc64 > > > The problem: > > portmaster -tDK --no-confirm lang/clang36 is how I started the build. > > The error report was after it reported entering the directory: > > /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/lib/Driver/ > > The report was: > > llvm-build: error: invalid native target: 'powerpc64' (not in project) > > > I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 > likely does. I've not yet tried from a powerpc (non-64) FreeBSD build. > > I'll note that with top -PaSCHopid I watched it compile the PowerPc code > generator software: it shoudl be able to handle PowerPCs fine. > > My guess is a conversion of naming conventions is required someplace: > > FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) > > This likely would matter for little endian naming as well (ppc64le on the > clang end of things I expect). > > > > > Context details: > > # svnlite info /usr/ports/lang/clang36 > Path: lang/clang36 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 > Relative URL: ^/head/lang/clang36 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: brooks > Last Changed Rev: 380295 > Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) > > It used gcc5 to bootstrap as there was no clang present and that is the only > gcc port installed: > > # svnlite info /usr/ports/lang/gcc5 > Path: lang/gcc5 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 > Relative URL: ^/head/lang/gcc5 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: gerald > Last Changed Rev: 380943 > Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > #WITH_DEBUG= > MALLOC_PRODUCTION= >
Re: mail/postfix default build options request: SASL
On Tue, Jul 07, 2015 at 03:45:53PM +1000, Kubilay Kocak wrote: > On 7/07/2015 3:31 PM, Gregory Orange wrote: > > Hi Olli and ports@, > > > > I don't know if this is a helpful forum to raise it, but I would like to > > request that SASL be enabled in the default build options for > > mail/postfix. I am attempting to use binary-only packages wherever > > possible, and so far this is the first where I currently have to build > > it myself. > > > > I would have thought SASL is in use across many Postfix installations, > > but of course I could be wrong. I was tempted to try out > > SMTP-after-IMAP, but since Postfix has the support, I think SASL is far > > cleaner. > > > > Would any responders please include me in the CC? I am not subscribed to > > the list. > > > > Thanks, > > Greg. > > > > If consensus can't be achieved or there is a good reason not to enable > this by default, then postfix-sasl as a slave port may be a desirable > alternative, which I believe has existed in the past. > > I'm generally: > > +1 on security related options enabled by default > +1 on OPTIONS_DEFAULT matching upstream defaults > -1 on OPTIONS_DEFAULT introducing large dependency sets We need a port that allows dovecot2 SASL by default. There are a bunch of turorials on setting up such systems and all of the have to start with "build everything by hand" which makes us look bad. I've been somewhat tempted to adding a slave port mail/postfix-useful with SASL, TLS, and DANE turned on. A less trollish name might be better though. :) -- Brooks pgpoAoPowNjRp.pgp Description: PGP signature
Re: Does OpenMP (iomp5) work for clang-devel?
On Mon, Jul 20, 2015 at 05:48:58PM -0700, Dennis Glatting wrote: > I can't seem to get this working and it appears not to emit code. I have > libiomp5 installed and I compile specifying: > > clang++-devel -fopenmp=libiomp5 ... > > And the compiler says: > > clang: warning: argument unused during compilation: '-fopenmp=libiomp5' The most recent clang-devel port doesn't include the bits to make iomp support automatic (it came not long after the update). I'm working on a update, but the ability to build clang and llvm separately appears to have been broken quite badly so it's taking a while and the only port to install will be devel/llvm-devel. Simple programs to work if you link with -liomp5 manually. > Is there a compile-time test involved somewhere, perhaps in llvm build? Assuming I manage to include the openmp runtime in the next update, I think it will work and I plan to configure the > Should /usr/local/llvm-devel/lib/ be in /etc/ld.so.conf? (That doesn't > seem to help). ldconfig should be handled correctly by the ports infrastructure. -- Brooks pgpmrEZx_NKOU.pgp Description: PGP signature
Re: svn commit: r392851 - in head: . devel devel/libiomp5-devel devel/llvm-devel devel/llvm-devel/files lang/clang-devel lang/clang-devel/files
On Fri, Jul 24, 2015 at 11:40:10PM +, Brooks Davis wrote: > Author: brooks > Date: Fri Jul 24 23:40:09 2015 > New Revision: 392851 > URL: https://svnweb.freebsd.org/changeset/ports/392851 > > Log: > Mostly complete redo to the build of -devel LLVM ports: >- Switch to cmake. >- Combine all builds into devel/llvm-devel. > - Remove devel/libiomp5-devel > - Make lang/clang-devel a metaport so people can still find it. > > Upgrade a snapshot shortly after the 3.7 branch point. I'm aiming to introduce a devel/llvm37 port next week based on this framework so please test if you anticipate wanting to use 3.7. -- Brooks pgp3mo4NjgjcZ.pgp Description: PGP signature
Re: Does OpenMP (iomp5) work for clang-devel?
On Wed, Aug 05, 2015 at 10:21:26PM +0930, Shane Ambler wrote:
> On 21/07/2015 18:06, Shane Ambler wrote:
> > On 21/07/2015 10:59, Dennis Glatting wrote:
> >> On Tue, 2015-07-21 at 01:07 +, Brooks Davis wrote:
> >>> On Mon, Jul 20, 2015 at 05:48:58PM -0700, Dennis Glatting wrote:
> >>>> I can't seem to get this working and it appears not to emit code. I
> >>>> have
> >>>> libiomp5 installed and I compile specifying:
> >>>>
> >>>> clang++-devel -fopenmp=libiomp5 ...
> >>>>
> >>>> And the compiler says:
> >>>>
> >>>> clang: warning: argument unused during compilation:
> >>>> '-fopenmp=libiomp5'
> >
> > That should be just -fopenmp
> >
> > From http://blog.llvm.org/2015/05/openmp-support_22.html
> >
> > To enable OpenMP, just add ???-fopenmp to the command line and
> > provide
> > paths to OpenMP headers and library with ???-I -L > OpenMP library path>.
>
> Having just installed devel/llvm37 and done a few tests, this doesn't
> appear to happen, for a single file test I also need to add -lomp
>
> clang37 -fopenmp -I/usr/local/llvm37/include -L/usr/local/llvm37/lib
> -lomp omp.c -o omp-test
Hmm, I hadn't tested openmp yet. I had hoped that setting the cmake variable
to default to libomp has sufficient but apparently it isn't. I'd like to get
-fopenmp working on it's own, but probably won't have a whole lot of time to
push this forward.
> One issue is that lldb breaks qtcreator. Sounds odd but I get -
>
> [leader:~] shane% qtcreator
> QProcess: Destroyed while process ("/usr/local/bin/lldb-mi-devel") is
> still running.
> QProcess: Destroyed while process ("/usr/local/bin/lldb-mi37") is still
> running.
> Broken pipe
> [leader:~] shane%
>
> If I rename the two binaries reported qtcreator runs fine.
> qtcreator-3.4.0 - rebuilt while llvm37 was installed without change.
This looks like qtcreator is being too smart for it's own good and is using
two versions of lldb at the same time. That seems likely to not work.
> My main interest in openmp is for compiling graphics/blender.
> This breaks llvm37 -
>
> I am running 10-stable -
> FreeBSD leader.local 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #16
> r285937: Tue Jul 28 20:58:13 ACST 2015
> root@leader.local:/usr/obj/usr/src/sys/GENERIC amd64
>
> % pkg info -ox llvm37
> llvm37-3.7.0.r1devel/llvm37
>
> Adding to make.conf -
> .if ${.CURDIR:M*/graphics/blender*}
> CC=clang37
> CXX=clang++37
> CPP=clang-cpp37
> .endif
>
> The build ends with -
>
> [ 42%] Building C object
> source/blender/editors/datafiles/CMakeFiles/bf_editor_datafiles.dir/__/__/__/__/release/datafiles/matcaps/mc04.jpg.c.o
> Assertion failed: (!DMEntry && "Decl already exists in localdeclmap!"),
> function EmitAutoVarAlloca, file
> /wrkdirs/usr/ports/devel/llvm37/work/llvm-3.7.0rc1.src/tools/clang/lib/CodeGen/CGDecl.cpp,
>
> line 1016.
> [ 42%] Building C object
> source/blender/bmesh/CMakeFiles/bf_bmesh.dir/operators/bmo_create.c.o
> clang-3.7: error: unable to execute command: Abort trap
> clang-3.7: error: clang frontend command failed due to signal (use -v to
> see invocation)
> clang version 3.7.0 (tags/RELEASE_370/rc1)
> Target: x86_64-unknown-freebsd10.2
> Thread model: posix
> clang-3.7: note: diagnostic msg: PLEASE submit a bug report to
> http://llvm.org/bugs/ and include the crash backtrace, preprocessed
> source, and associated run script.
> clang-3.7: note: diagnostic msg:
>
>
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang-3.7: note: diagnostic msg: /tmp/BLI_kdopbvh-8090d7.c
> clang-3.7: note: diagnostic msg: /tmp/BLI_kdopbvh-8090d7.sh
> clang-3.7: note: diagnostic msg:
>
>
>
> Full build log and debug files are available at
> http://shaneware.biz/freebsddebugdata/clang37/
>
> Brooks, I haven't submitted this upstream but can if you want.
You might test with clang-devel first, but submitting this upstream
is a good idea. I don't develop llvm myself so can't do anything
particularly useful with crash reports.
-- Brooks
pgpsVPYbrf3Wl.pgp
Description: PGP signature
Re: devel/llvm36/plist has 2 non existant files
On Mon, Sep 21, 2015 at 01:30:54AM +0200, Julian H. Stacey wrote: > Hi bro...@freebsd.org, > cc: po...@freebsd.org > > with current devel/llvm36 > FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12135: Thu Sep > 17 14:54:15 CEST 2015 > j...@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64 > > make install > ===> Installing for llvm36-3.6.2_2 > ===> llvm36-3.6.2_2 depends on file: /usr/local/bin/python2.7 - found > ===> llvm36-3.6.2_2 depends on file: /usr/local/bin/perl5.20.2 - found > ===> llvm36-3.6.2_2 depends on shared library: libedit.so.0 - found > (/usr/local/lib/libedit.so.0) > actual-package-depends: dependency on /usr/local/bin/perl5.20.2 not > registered (normal if it belongs to base) > ===> Registering installation for llvm36-3.6.2_2 > pkg-static: Unable to access file > /data/release/11.0-CURRENT/usr/ports/devel/llvm36/work/stage/usr/local/share/doc/llvm36/html/jquery-1.11.1.js: > No such file or directory > pkg-static: Unable to access file > /data/release/11.0-CURRENT/usr/ports/devel/llvm36/work/stage/usr/local/share/doc/llvm36/html/underscore-1.3.1.js: > No such file or directory > *** Error code 74 > > I've started a remake with this: > - > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/jhs/devel/llvm36/pkg-plist.REL=11.0-CURRENT.diff > > Mon Sep 21 00:41:55 CEST 2015 > > There is no jquery-1.11.1.js underscore-1.3.1.js > > *** 11.0-CURRENT/ports/devel/llvm36/pkg-plist Mon Sep 21 00:27:44 2015 > --- new-generic/ports/devel/llvm36/pkg-plist Mon Sep 21 00:29:40 2015 > *** > *** 1052,1058 > %%PORTDOCSDOCSDIR%%/html/genindex.html > %%PORTDOCSDOCSDIR%%/html/index.html > %%PORTDOCSDOCSDIR%%/html/index.txt > - %%PORTDOCSDOCSDIR%%/html/jquery-1.11.1.js > %%PORTDOCSDOCSDIR%%/html/jquery.js > %%PORTDOCSDOCSDIR%%/html/lines.gif > %%PORTDOCSDOCSDIR%%/html/linpack-pc.png > --- 1052,1057 > *** > *** 1109,1115 > %%PORTDOCSDOCSDIR%%/html/searchtools.js > %%PORTDOCSDOCSDIR%%/html/tblgen.html > %%PORTDOCSDOCSDIR%%/html/tblgen.txt > - %%PORTDOCSDOCSDIR%%/html/underscore-1.3.1.js > %%PORTDOCSDOCSDIR%%/html/underscore.js > %%PORTDOCSDOCSDIR%%/html/up-pressed.png > %%PORTDOCSDOCSDIR%%/html/up.png > --- 1108,1113 These appeared at some point on package builders. At the time it didn't appear on my build systems unless I used poudriere. Now they always appear. I suspect this is due to a change in the upstream sphinx version, but I've not investigated sufficiently to add an appropriate version dependency. -- Brooks pgpHnf1QleR7_.pgp Description: PGP signature
Re: devel/llvm36/plist has 2 non existant files
On Tue, Sep 22, 2015 at 05:10:06PM +0200, Julian H. Stacey wrote: > > Brooks Davis wrote: Mon, 21 Sep 2015 21:21:30 + > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Sep 21, 2015 at 01:30:54AM +0200, Julian H. Stacey wrote: > > > Hi bro...@freebsd.org, > > > cc: po...@freebsd.org > > >=20 > > > with current devel/llvm36 > > > FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12135: Thu= > > Sep 17 14:54:15 CEST 2015 > > j...@lapr.js.berklix.net:/usr/src/sys/amd64/c= > > ompile/LAPR.small amd64 > > >=20 > > > make install > > > =3D=3D=3D> Installing for llvm36-3.6.2_2 > > > =3D=3D=3D> llvm36-3.6.2_2 depends on file: /usr/local/bin/python2.7 - f= > > ound > > > =3D=3D=3D> llvm36-3.6.2_2 depends on file: /usr/local/bin/perl5.20.2 - = > > found > > > =3D=3D=3D> llvm36-3.6.2_2 depends on shared library: libedit.so.0 - fou= > > nd (/usr/local/lib/libedit.so.0) > > > actual-package-depends: dependency on /usr/local/bin/perl5.20.2 not regis= > > tered (normal if it belongs to base) > > > =3D=3D=3D> Registering installation for llvm36-3.6.2_2 > > > pkg-static: Unable to access file /data/release/11.0-CURRENT/usr/ports/de= > > vel/llvm36/work/stage/usr/local/share/doc/llvm36/html/jquery-1.11.1.js: No = > > such file or directory > > > pkg-static: Unable to access file /data/release/11.0-CURRENT/usr/ports/de= > > vel/llvm36/work/stage/usr/local/share/doc/llvm36/html/underscore-1.3.1.js: = > > No such file or directory > > > *** Error code 74 > > >=20 > > > I've started a remake with this: > > > - > > > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/jhs/devel/llvm36/pkg-= > > plist.REL=3D11.0-CURRENT.diff > > >=20 > > > Mon Sep 21 00:41:55 CEST 2015 > > >=20 > > > There is no jquery-1.11.1.js underscore-1.3.1.js > > >=20 > > > *** 11.0-CURRENT/ports/devel/llvm36/pkg-plist Mon Sep 21 00:27:44 2015 > > > --- new-generic/ports/devel/llvm36/pkg-plist Mon Sep 21 00:29:40 2015 > > > *** > > > *** 1052,1058 > > > %%PORTDOCSDOCSDIR%%/html/genindex.html > > > %%PORTDOCSDOCSDIR%%/html/index.html > > > %%PORTDOCSDOCSDIR%%/html/index.txt > > > - %%PORTDOCSDOCSDIR%%/html/jquery-1.11.1.js > > > %%PORTDOCSDOCSDIR%%/html/jquery.js > > > %%PORTDOCSDOCSDIR%%/html/lines.gif > > > %%PORTDOCSDOCSDIR%%/html/linpack-pc.png > > > --- 1052,1057 > > > *** > > > *** 1109,1115 > > > %%PORTDOCSDOCSDIR%%/html/searchtools.js > > > %%PORTDOCSDOCSDIR%%/html/tblgen.html > > > %%PORTDOCSDOCSDIR%%/html/tblgen.txt > > > - %%PORTDOCSDOCSDIR%%/html/underscore-1.3.1.js > > > %%PORTDOCSDOCSDIR%%/html/underscore.js > > > %%PORTDOCSDOCSDIR%%/html/up-pressed.png > > > %%PORTDOCSDOCSDIR%%/html/up.png > > > --- 1108,1113 > > > > These appeared at some point on package builders. At the time it didn't > > appear on my build systems unless I used poudriere. Now they always > > appear. I suspect this is due to a change in the upstream sphinx > > version, but I've not investigated sufficiently to add an appropriate > > version dependency. > > > > -- Brooks > > They break the build on my non poudriere system. Patched out, the make works. > I'd suggest/request you comment them out until its resolved if needed, > & if so, why not generated. Given the choice between working package builds and working in arbitrary ports configuraiton I'll choose packages. I had hope the issues was transient, but apparently not so I'll try to find a solution. Could you tell me what version of textproc/py-sphinx you have installed? -- Brooks pgpJDs7CCO8zv.pgp Description: PGP signature
Re: devel/llvm36/plist has 2 non existant files
On Wed, Sep 23, 2015 at 12:18:48AM +0200, Julian H. Stacey wrote: > Brooks Davis wrote: > > Content-Transfer-Encoding: quoted-printable > > > > On Tue, Sep 22, 2015 at 05:10:06PM +0200, Julian H. Stacey wrote: > > >=20 > > > Brooks Davis wrote: Mon, 21 Sep 2015 21:21:30 + > > > > Content-Transfer-Encoding: quoted-printable > > > >=20 > > > > On Mon, Sep 21, 2015 at 01:30:54AM +0200, Julian H. Stacey wrote: > > > > > Hi bro...@freebsd.org, > > > > > cc: po...@freebsd.org > > > > >=3D20 > > > > > with current devel/llvm36 > > > > > FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12135:= > > Thu=3D > > > > Sep 17 14:54:15 CEST 2015 > > > > j...@lapr.js.berklix.net:/usr/src/sys/amd= > > 64/c=3D > > > > ompile/LAPR.small amd64 > > > > >=3D20 > > > > > make install > > > > > =3D3D=3D3D=3D3D> Installing for llvm36-3.6.2_2 > > > > > =3D3D=3D3D=3D3D> llvm36-3.6.2_2 depends on file: /usr/local/bin/pyt= > > hon2.7 - f=3D > > > > ound > > > > > =3D3D=3D3D=3D3D> llvm36-3.6.2_2 depends on file: /usr/local/bin/per= > > l5.20.2 - =3D > > > > found > > > > > =3D3D=3D3D=3D3D> llvm36-3.6.2_2 depends on shared library: libedit.= > > so.0 - fou=3D > > > > nd (/usr/local/lib/libedit.so.0) > > > > > actual-package-depends: dependency on /usr/local/bin/perl5.20.2 not r= > > egis=3D > > > > tered (normal if it belongs to base) > > > > > =3D3D=3D3D=3D3D> Registering installation for llvm36-3.6.2_2 > > > > > pkg-static: Unable to access file /data/release/11.0-CURRENT/usr/port= > > s/de=3D > > > > vel/llvm36/work/stage/usr/local/share/doc/llvm36/html/jquery-1.11.1.js:= > > No =3D > > > > such file or directory > > > > > pkg-static: Unable to access file /data/release/11.0-CURRENT/usr/port= > > s/de=3D > > > > vel/llvm36/work/stage/usr/local/share/doc/llvm36/html/underscore-1.3.1.= > > js: =3D > > > > No such file or directory > > > > > *** Error code 74 > > > > >=3D20 > > > > > I've started a remake with this: > > > > > - > > > > > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/jhs/devel/llvm36/= > > pkg-=3D > > > > plist.REL=3D3D11.0-CURRENT.diff > > > > >=3D20 > > > > > Mon Sep 21 00:41:55 CEST 2015 > > > > >=3D20 > > > > > There is no jquery-1.11.1.js underscore-1.3.1.js > > > > >=3D20 > > > > > *** 11.0-CURRENT/ports/devel/llvm36/pkg-plist Mon Sep 21 00:27:44 2015 > > > > > --- new-generic/ports/devel/llvm36/pkg-plist Mon Sep 21 00:29:40 2015 > > > > > *** > > > > > *** 1052,1058 > > > > > %%PORTDOCSDOCSDIR%%/html/genindex.html > > > > > %%PORTDOCSDOCSDIR%%/html/index.html > > > > > %%PORTDOCSDOCSDIR%%/html/index.txt > > > > > - %%PORTDOCSDOCSDIR%%/html/jquery-1.11.1.js > > > > > %%PORTDOCSDOCSDIR%%/html/jquery.js > > > > > %%PORTDOCSDOCSDIR%%/html/lines.gif > > > > > %%PORTDOCSDOCSDIR%%/html/linpack-pc.png > > > > > --- 1052,1057 > > > > > *** > > > > > *** 1109,1115 > > > > > %%PORTDOCSDOCSDIR%%/html/searchtools.js > > > > > %%PORTDOCSDOCSDIR%%/html/tblgen.html > > > > > %%PORTDOCSDOCSDIR%%/html/tblgen.txt > > > > > - %%PORTDOCSDOCSDIR%%/html/underscore-1.3.1.js > > > > > %%PORTDOCSDOCSDIR%%/html/underscore.js > > > > > %%PORTDOCSDOCSDIR%%/html/up-pressed.png > > > > > %%PORTDOCSDOCSDIR%%/html/up.png > > > > > --- 1108,1113 > > > >=20 > > > > These appeared at some point on package builders. At the time it didn't > > > > appear on my build systems unless I used poudriere. Now they always > > > > appear. I suspect this is due to a change in the upstream sphinx > > > > version, but I've not investigated sufficiently to add an appropriate > > > > version dependency. > > > >=20 > > > > -- Brooks > > >=20 > > > They break the build on my non poudriere system. Patched out, the make w= > > orks. > > > I'd suggest/request yo
Re: llvm37 python3 problem
On Fri, Oct 09, 2015 at 04:38:57PM +0200, Walter Schwarzenfeld wrote: > Can't test the patch in the above link, cause the port ignores python > 3.4 and I don't want deinstall python 2.7. I've figured out how to reconfigure poudriere to be able to test this. Several other files need this sort of fix. I've managed to fix some with patches from upstream, but it appears that lldb is incompatible with python 3. The C code is using obsolete interfaces and doesn't compile. -- Brooks signature.asc Description: PGP signature
Re: 9.3 to 10.2 migration, determining if clang is used
On Tue, Oct 13, 2015 at 11:13:11AM -0700, Patrick Powell wrote: > I just started doing a 9.3 to 10.2 migration of a bunch of applications > and discovered that some of the options used > to generate the applications were slightly different. I just know that > this has been covered before, but I could not > find a definitive method or set of methods to use to determine if the > old GCC compiler or the new CLANG compiler > is being used. Could the ports wizards (and/or autoconf experts) help > me a bit? > > (Aside: the clang compiler diagnostics and warnings are very thorough > and quite clear. Nicely done, especially > the addition of the information about the flag to turn this warning > off. I also like the pragmas to > control warnings and the push/pop pragma facility. This may have been > in the GCC compiler but I missed it.) > > 1. If the application is to be generated via the PORT infrastructure, > what do you > put in the port Makefile to determine if CLANG (10.2) or GCC (9.3) > is being used? > > > Something like below. Note: the examples below are a bit contrived, > but the idea is to set > some MAKE variable to different values depending on CLANG or GCC in use. > > .if defined(CC_IS_CLANG) > MYFLAGS+= -Wall -Werror -Wno-error=unused > .else > .if defined(CC_IS_GCC) > MYFLAGS+= -Wall -Werror -Wno-unused > .endif > .endif For ports, I think you are looking for USES=compiler:features (see ports/Mk/Uses/compiler.mk). I don't know the answer for autoconf. -- Brooks signature.asc Description: PGP signature
Re: llvm37 python3 problem
On Tue, Oct 27, 2015 at 11:03:07AM +, loic.b...@unix-experience.fr wrote: > Any news for this problem ? Upstream does not yet support python 3 so it remain broken. I've not yet had time to see if I can force the use of 2.7 when building. Simple changes haven't worked. You can work around this by disabling the LLDB option when building. -- Brooks > 12 octobre 2015 19:50 "Brooks Davis" a ??crit: > > On Fri, Oct 09, 2015 at 04:38:57PM +0200, Walter Schwarzenfeld wrote: > > > >> Can't test the patch in the above link, cause the port ignores python > >> 3.4 and I don't want deinstall python 2.7. > > > > I've figured out how to reconfigure poudriere to be able to test this. > > Several other files need this sort of fix. I've managed to fix some > > with patches from upstream, but it appears that lldb is incompatible > > with python 3. The C code is using obsolete interfaces and doesn't > > compile. > > > > -- Brooks > signature.asc Description: PGP signature
Re: error upgrading graphics/dri port "/usr/local/llvm36/bin/clang: not found"
On Sun, Jan 17, 2016 at 07:08:14PM +1100, Graham Menhennitt wrote: > Does anybody have any clues, please? > > Thanks, > Graham > > root@starker# uname -a > FreeBSD starker 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r294103: Sun Jan > 17 13:26:05 AEDT 2016 > gfm@starker:/usr/obj/usr/data/FreeBSD/src_11-Current/sys/starker amd64 > root@starker# ll /usr/local/llvm36/bin > total 22384 > -rwxr-xr-x 1 root wheel277720 Jan 6 19:54 bugpoint > -rwxr-xr-x 1 root wheel 18292472 Sep 25 07:49 clang-cpp > -rwxr-xr-x 1 root wheel 7288 Jan 6 19:53 count > -r-xr-xr-x 2 root wheel220280 Jan 6 19:54 FileCheck > -r-xr-xr-x 4 root wheel82 Jan 6 19:54 lit > -rwxr-xr-x 1 root wheel117368 Jan 6 19:54 llc > -rwxr-xr-x 1 root wheel 96128 Jan 6 19:54 lli > -rwxr-xr-x 1 root wheel 14648 Jan 6 19:54 lli-child-target > -rwxr-xr-x 1 root wheel 58200 Jan 6 19:54 llvm-ar > -rwxr-xr-x 1 root wheel 16960 Jan 6 19:54 llvm-as > -rwxr-xr-x 1 root wheel 46088 Jan 6 19:54 llvm-bcanalyzer > -rwxr-xr-x 1 root wheel 91416 Jan 6 19:54 llvm-config > -rwxr-xr-x 1 root wheel 92552 Jan 6 19:54 llvm-cov > -rwxr-xr-x 1 root wheel 49200 Jan 6 19:54 llvm-diff > -rwxr-xr-x 1 root wheel 20432 Jan 6 19:54 llvm-dis > -rwxr-xr-x 1 root wheel 32992 Jan 6 19:54 llvm-dsymutil > -rwxr-xr-x 1 root wheel 24888 Jan 6 19:54 llvm-dwarfdump > -rwxr-xr-x 1 root wheel 33008 Jan 6 19:54 llvm-extract > -rwxr-xr-x 1 root wheel 24904 Jan 6 19:54 llvm-link > -r-xr-xr-x 4 root wheel82 Jan 6 19:54 llvm-lit > -rwxr-xr-x 1 root wheel 74560 Jan 6 19:54 llvm-mc > -rwxr-xr-x 1 root wheel 18072 Jan 6 19:54 llvm-mcmarkup > -rwxr-xr-x 1 root wheel 79432 Jan 6 19:54 llvm-nm > -rwxr-xr-x 1 root wheel244848 Jan 6 19:54 llvm-objdump > -rwxr-xr-x 1 root wheel 46400 Jan 6 19:54 llvm-profdata > lrwxr-xr-x 1 root wheel 7 Jan 6 19:54 llvm-ranlib -> llvm-ar > -rwxr-xr-x 1 root wheel314824 Jan 6 19:54 llvm-readobj > -rwxr-xr-x 1 root wheel 52520 Jan 6 19:54 llvm-rtdyld > -rwxr-xr-x 1 root wheel 64744 Jan 6 19:54 llvm-size > -rwxr-xr-x 1 root wheel 64640 Jan 6 19:54 llvm-stress > -rwxr-xr-x 1 root wheel 64736 Jan 6 19:54 llvm-symbolizer > -rwxr-xr-x 1 root wheel 1622424 Jan 6 19:53 llvm-tblgen > -rwxr-xr-x 1 root wheel 39064 Jan 6 19:54 llvm-vtabledump > -rwxr-xr-x 1 root wheel 36944 Jan 6 19:54 macho-dump > -rwxr-xr-x 1 root wheel 41112 Jan 6 19:53 not > -rwxr-xr-x 1 root wheel 47168 Jan 6 19:54 obj2yaml > -rwxr-xr-x 1 root wheel302320 Jan 6 19:54 opt > -rwxr-xr-x 1 root wheel 34264 Jan 6 19:54 verify-uselistorder > -rwxr-xr-x 1 root wheel 66032 Jan 6 19:54 yaml2obj > root@starker# pkg info|grep llvm > llvm36-3.6.2_2 Low Level Virtual Machine > root@starker# portupgrade -aWw > [Reading data from pkg(8) ... - 854 packages found - done] > ---> Upgrading 'dri-11.0.7_1,2' to 'dri-11.0.8,2' (graphics/dri) > ---> Building '/usr/ports/graphics/dri' > ===> dri-11.0.8,2 depends on executable: makedepend - found > ===> dri-11.0.8,2 depends on package: libclc>=0.0.r222830 - not found > ===> Building for libclc-0.1.0.20150710 > [8/979] LLVM-CC r600--/lib/math/mad.cl.cedar.bc > FAILED: /usr/local/llvm36/bin/clang -MMD -MF > r600--/lib/math/mad.cl.cedar.bc.d -target r600-- -I`dirname > generic/lib/math/mad.cl` -Igeneric/include -fno-builtin > -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 > -D__CLC_INTERNAL -emit-llvm -mcpu=cedar -c -o > r600--/lib/math/mad.cl.cedar.bc generic/lib/math/mad.cl > /bin/sh: /usr/local/llvm36/bin/clang: not found > [8/979] LLVM-CC r600--/lib/math/tables.cl.cedar.bc > FAILED: /usr/local/llvm36/bin/clang -MMD -MF > r600--/lib/math/tables.cl.cedar.bc.d -target r600-- -I`dirname > generic/lib/math/tables.cl` -Igeneric/include -fno-builtin > -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 > -D__CLC_INTERNAL -emit-llvm -mcpu=cedar -c -o > r600--/lib/math/tables.cl.cedar.bc generic/lib/math/tables.cl > /bin/sh: /usr/local/llvm36/bin/clang: not found > ... You appear not to have lang/clang36 installed. I don't know why portupgrade isn't installing it since it is a BUILD_DEPEND of graphics/dri, but installing it by hand should work around the problem. -- Brooks signature.asc Description: PGP signature
Re: Pulling from github as a vendorized dependency in poudriere
On Fri, Feb 19, 2016 at 07:13:04AM -0500, Derek (freebsd lists) wrote: > Hi, > > I'm attempting to port a project over, and it is dependent on a > "vendorizing" program, which then pulls in the source of the > dependencies to build. (The final artifact is statically linked, > so there shouldn't be a problem as far as installing unversioned > libraries outside of the package/ports framework, for example.) > > My port works fine in my local ports tree, and also I can build > the project by hand without the port no problem. > > When I try to use poudriere testport, and it's time to pull in > the dependencies (as part of a build step), I get: > > fatal: unable to access 'https://github.com/foo/bar': Couldn't > connect to server > > Is there something in poudriere that makes the network special? > i.e. do build scripts not have network access in that context? > > I can provide more specifics on my project: > > - The vendorizing program is "gb vendor" > - I have PATCH_DEPENDS on gb, and git > - The pre-patch step runs `make deps`, a target which ultimately > runs `gb vendor restore`, the step that gives the error message, > and the build fails > > I can provide more detail, but would like to know if I'm doing > something horribly wrong first (i.e. trying to access the network > with gb as a make target, versus some other way to do this). When you run "gb vendor", what stage does that happen in? IIRC poudriere only configures network access during the fetch stage so you must find a way to run it as part of the fetch process or capture and emulate its result. -- Brooks signature.asc Description: PGP signature
Re: [ports] cvs commit: ports/emulators/p-interp Makefile
On Tue, Jul 29, 2008 at 05:17:38PM +, Brooks Davis wrote: > brooks 2008-07-29 17:17:30 UTC > > FreeBSD ports repository > > Modified files: > emulators/p-interp Makefile > Log: > Fix the disk image MASTER_SITES. >- ftp.apple.asimov.net was reorganized at some point so the path was > wrong. >- ftp1.au.apple.asimov.net is reliably non-functional with multiple > different symptoms including hangs and asking for username/passwords. >- I found www.kdbarto.org via google. Given that I first noticed these issues a few months ago, it's pretty clear noone actually cares about this port so we should probably take it out back and shoot it. -- Brooks pgpxw9gOOHGdx.pgp Description: PGP signature
Re: FreeBSD Port: squeezecenter-7.0.1_4
On Thu, Aug 07, 2008 at 10:59:06PM +0200, Kenny Lasse Hoff Levinsen wrote: > Hi! > > I'm sorry to bother, but i just wanted to ask when this port is gonna be > updated (it's 7.1 now)? > Know it's a simple app and i can just install it from sources (which is > perl, to make it even simpler), but i just like having it in the package > database, so it's easier to handle... > Just wondering Thanks for the reminder. I did the work last week, but was away my computer for a long weekend and thus didn't commit it. I'll finish the last of the cleanup and commit it shortly. -- Brooks pgpIAFTfklWL6.pgp Description: PGP signature
