Re: lang/gcc46

[b. f.]

On 8/6/12, Doug Barton  wrote:
> On 08/06/2012 00:30, b. f. wrote:
>> On 8/6/12, Doug Barton  wrote:
>>> On 07/31/2012 08:57, Gerald Pfeifer wrote:
>>>> On Sun, 29 Jul 2012, Doug Barton wrote:

>>> Just to be clear, you compile stuff with gcc 4.6, that is linked against
>>> libgcc, and then you update to 4.7, with a new libgcc, and everything
>>> still works? If so, that's great, I'm glad to hear that it's not a
>>> problem.
>>
>> For the most part, yes.
>
> In my mind, this isn't good enough. But I'm not in charge of anything. :)

Oops: I forgot though, that partly due to this policy of not bumping
gcc shared library versions, we have some shared libraries in the base
system that conflict with the shared libraries of the various gcc
ports, and we have been enforcing the right links by inscribing hints
in the binaries to look first in the right gcc port directories.  But
if we update lang/gcc from 4.6.x to another major version (e.g.
4.7.x), the directory changes, and linking for the old binaries will
fail.  So let me qualify my earlier answer: you can keep the old
software working with minimal intervention, for example, by adding a
symlink from the old directory to the new one.

>
>> I think Gerald was referring to Bapt's plan to make it easier to make
>> multiple packages from a single port, so that those who used packages
>> exclusively could install a package consisting of only the runtime
>> support libraries, rather than the whole compiler suite.
>
> Universal support for that is years away, minimum.
>
>> I had
>> patches to do this even without pkgng, but it made things a little
>> more complicated, and didn't seem to be a high priority, so I didn't
>> pursue it.  If people feel that it is important, I could work with
>> Gerald to revive that, or use a knob like that of ports/155408 with
>> static linking to allow users to remove the runtime dependency for a
>> lot of software, at the cost of some added overhead from redundancies.
>
> Making this change now would benefit a lot of people, now.

Okay, but since I'm not in charge either, it will require (at least)
Gerald's consent.  And if you adopt the latter approach, it won't be
one size fits all: it may make sense to use static linking to the
support libraries for default packages, of which a comparatively few
are built with lang/gcc4*, but it will be less suitable for those who
routinely use lang/gcc4* for most if not all of their packages.

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

Re: lang/gcc46

[b. f.]

On 8/6/12, Doug Barton  wrote:
> On 07/31/2012 08:57, Gerald Pfeifer wrote:
>> On Sun, 29 Jul 2012, Doug Barton wrote:



> Just to be clear, you compile stuff with gcc 4.6, that is linked against
> libgcc, and then you update to 4.7, with a new libgcc, and everything
> still works? If so, that's great, I'm glad to hear that it's not a problem.

For the most part, yes.  The upstream developers have a policy of
avoiding version bumps for the runtime support libraries when
possible, and instead using symbol versioning to maintain
backward-compatibility.  Only a very few pieces of software using
libgcj or libobjc will have to be recompiled.  For default packages,
IIRC, that is only print/pdftk.  Of course, it will be to the
advantage of most users to recompile their packages with the new
version of the compiler.

>> In other words, if there is a challenge it's not GCC per se, more
>> our packaging of it (and some work Bapt is doing on the packaging
>> infrastructure should help with that).
>
> I don't know of any magic solutions in the works that will solve the
> separation of libgcc from the compiler. :)

I think Gerald was referring to Bapt's plan to make it easier to make
multiple packages from a single port, so that those who used packages
exclusively could install a package consisting of only the runtime
support libraries, rather than the whole compiler suite.  I had
patches to do this even without pkgng, but it made things a little
more complicated, and didn't seem to be a high priority, so I didn't
pursue it.  If people feel that it is important, I could work with
Gerald to revive that, or use a knob like that of ports/155408 with
static linking to allow users to remove the runtime dependency for a
lot of software, at the cost of some added overhead from redundancies.

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

Re: Mk macros & print/texinfo/distinfo variant SHA256 SIZE

[b. f.]

> Hi johans at FreeBSD.org
> & cc ports@
> A 9.0-RELEASE ports fails on
> cd print/texinfo ; make fetch
> unless one imports newer values from current,

...

> So how best to modify Makefile to not break on size & sha256 of
> some but not all files ?
>
> The question can't be unique to this port,

...

> Thoughts ?

It isn't unique to this port. We already have such a construct:
IGNOREFILES, (See ports/Mk/bsd.port.mk,  or

http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-checksum.html

.)  Its use is discouraged because of security concerns.  It would
_not_ be wise to
ignore checksums in the case of the texinfo sources -- instead, the
maintainer can simply place copies of the unversioned sources in a
separate, fully-versioned subdirectory on his mirror (e.g.,
${PORTVERSION} rather than ${PORTVERSION:E}), so that they would be
available there after they had been supplanted by newer versions on
the upstream mirrors.  The versioned sources could reside in an
unversioned or partly-versioned subdirectory, to avoid unnecessary
copies.  The maintainer probably knows how to do this; it is described
at:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#PORTING-MASTER-SITES-N

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

Re: Where's linux-mirror.org coming from?

[b. f.]

> In my port I have
>
> MASTER_SITES=   NL:slatec,blas
>
> which, according to bsd.sites.mk, does not
> include linux-mirror.org. In fact I can't
> find it in bsd.sites.mk at all.
> So where is it coming from?

I recently removed it from the Netlib master sites because of recent
failures, so you needn't worry about it.  (If service resumes and
seems stable, I'll reinstate it.)  The distilator results that you
cite are based on a slightly older ports tree.  Those entries will
probably disappear soon, when the the ports tree that the distilator
uses is updated, and the port is re-tested.

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

Re: port unmaintained since 2005? drop it? misc/gpt*

[b. f.]

On 6/11/12, Michael Scheidell  wrote:
>
>
> On 6/10/12 11:14 PM, b. f. wrote:
>> The distribution files are at:
>>
>> ftp://ftp.ncsa.uiuc.edu/aces/gpt/releases
>>
>> and the homepage is:
>>
>> http://grid.ncsa.illinois.edu/gpt/
>>
>> (And Globus is at:
>>
>> http://www.globus.org/toolkit/)
>>
>> Time to determine this:<  1 min.
>>
>> b.
> glad to know you are volunteering to maintain these ports.
> I will resurrect globus from the archives (where it has been since 2008,
> see /usr/ports/MOVED),
> which email address do you want in the MAINTAINER= line?
>

Heh, not so fast.  I've got other things to do first.  I was just
pointing out that it is not so hard to correct some of the stale
information, and it is useful to do this as a pointer to those who may
wish to more actively maintain the port later, even if it is moved to
the attic in a few months.

I should add that globus comes with a bundled version of gpt, and I
think the Debian port is based upon this -- it's at 3.6.x.  Also, that
brooks@, who was involved in adding this port and other related
software, could probably tell you more about grid software.

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

Re: port unmaintained since 2005? drop it? misc/gpt*

[b. f.]

> On Mon, Jun 11, 2012 at 4:31 AM,   wrote:
> > Michael Scheidell  wrote:
> >
> >> Two unmaintained ports, nothing depends on them, and upstream has
> >> not updated source since 2004, ftp server unresponsive.
> >>
> >> 
> >> (gpt32: misc/gpt also unmaintained since 2005.
> >>
> >> 
> >> ftp server mentioned doesn't respond (ftp.freebsd.org has distfile),
> >> upstream unmaintained since 2004, and upstream points to a different
> >> distfile (with different checksum and same version number), mentions
> >> an alpha version 4.0.
> >
> > These are originally from NCSA, but the website mentioned in
> > the pkg-descr (http://www.gridpackagingtools.org/) now seems to
> > be promoting some kind of diet/nutritional approach.  The only
> > connection to "middleware" that immediately comes to mind is that
> > such sites tend to be frequented by those concerned about excessive
> > weight around their middle :)
> >
> > 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.
>
> I would have to think that that is a remnant of a project that is no
> longer running.  The current owners of that domain are squatters:

The distribution files are at:

ftp://ftp.ncsa.uiuc.edu/aces/gpt/releases

and the homepage is:

http://grid.ncsa.illinois.edu/gpt/

(And Globus is at:

http://www.globus.org/toolkit/   )

Time to determine this: < 1 min.

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

Re: Why Are You NOT Using FreeBSD?

[b. f.]

On 6/3/12, Erich  wrote:

...

> On 03 June 2012 PM 1:12:38 b. f. wrote:
>> > On 03 June 2012 PM 5:42:55 Adam Strohl wrote:
>> > > On 6/3/2012 17:24, Etienne Robillard wrote:

...

>> With regard to your request for a versioned Ports trees -- well, we
>> have had that for about 18 years, since the Ports tree is kept under
>> version control in CVS, and you are free to check out snapshots using
>> anonymous CVS or CVSup -- all you have to do is specify a tag or date
>
> I would not know for what tag I would have to go to solve a specific
> Problem.

Here we encounter a problem with your argument: it is unlikely that
your hypothetical helpless beginner would know what to do with a
versioned ports tree, even if he or she knew that it does in fact
exist.  Any such person who requires reliability should really be
using binary packages and binary base-system updates prepared by
someone else, and not compiling from source.  There have been
considerable improvements on this front, with freebsd-update and pkgng
(

http://wiki.freebsd.org/pkgng

).  If you want to help, you should become familiar with these, and
suggest concrete changes that you think would assist your beginner.

Returning to your question: a common-sense answer would be to fall
back to the last-known suitable Ports tree snapshot -- or to the
snapshot distributed with the last release, or the release that you
are using. To use the ports tree snapshot distributed with a
particular release, use the ports (not the src!) release tags as
described in:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html

(Here the description could be changed to avoid confusion -- the list
of specific release tags could be changed to indicate that they are
src release tags only, as briefly described in the first paragraph of
A.7.2, and the corresponding ports release tags could be added.)  For
example, in order to obtain the ports tree corresponding to the 8.3
release, use:

tag=RELEASE_8_3_0

instead of the usual

tag=.

in a ports sup file (a comment to that effect could be added to
src/share/examples/cvsup/ports-supfile) -- or use the corresponding
"-r" option with cvs(1).The available tags are also visible
through the pull-down "Show only files with tag" menu at the web
interface:

http://www.freebsd.org/cgi/cvsweb.cgi/ports/

and of course someone who is familiar with CVS could find them.  The
tag is one kind of "version number".

The other kind of "version number" that is available is a date spec --
for csup(1) this takes the form:

[cc]yy.mm.dd.hh.mm.ss

where the abbreviations represent the usual century. year, month, day,
hour, minute, and second. To use this, just add a date=... line in
your sup file, to replace or supersede any tag=... line.  So, for
example, to fetch the ports tree as it was immediately before the png
update, determine the time of the png update (for example, via the
cvsweb interface above, or freshports [ http://www.freshports.org ] or
freshbsd [ http://www.freshbsd.org ] or the cvs-ports mailing list [
http://lists.freebsd.org/pipermail/cvs-ports/ ], or by looking at the
revision time-stamp in ports/graphics/png/Makefile), and then
substitute:

date=2012.06.01.05.10.00

(that is, a few minutes before the png update) for the usual

tag=.

in a ports sup file -- or use the corresponding -D option with cvs(1).

If these procedures aren't explained in great detail in the handbook
or manpages, even though the tags and date specs are defined, it is
probably because we assume that people who want to build specific
revisions of ports from source, and who are able to do so, already
have some familiarity with VCS.

...

>> And you are, of course, free to use FreeBSD with other packaging
>
> They will feel to be free to use Windows.

They can feel free to use whatever they please: I was only pointing
out that using FreeBSD does not require the use of FreeBSD Ports.

...

>> As far as your example from your other message about having to combine
>> a png update with work over the course of a weekend -- I don't know
>> why you would be fooling around with an update of your Ports tree or
>> your installed ports while working under a tight deadline, but if you
>> have backups, you should be able to recover from most problems fairly
>> quickly.
>
> Because it is written in the handbook?

Because it is common-sense to have back-ups if you require
reliability.  But if you feel that this should be explicitly mentioned
in the handbook, submit some suggestions for changes or additions to
the document committers.

> At least some time ago the handbook stated to update the ports tree before
> installing new ports.
>
> The new comer will do this and then get stuck.
>
> Do not forget that I am not talking here for people who know what they are
> doing, I am ta

Re: Shared object "libpng.so.6"

[b. f.]

On 6/3/12, Kevin Oberman  wrote:
> On Sun, Jun 3, 2012 at 7:23 AM, b. f.  wrote:
>>>> Stop in /usr/ports/x11/kdelibs3.
>>
>>> removed manually, if portmaster hasn't already done so.  Here it looks
>>> like your new build of kde3libs is sloppily linking against the old
>>> version of kde3libs that you still have installed, and which still
>>
>> Obviously I meant kdelibs3 in the above -- this is starting to make me
>> dizzy, too.
>
> At this point I have to think that it is not cairo that is the issue,
> but something cairo is depending on that is referencing libpng.so.6.

cairo was involved in Leslie's earlier problem, but it is not involved
in this one -- although the nature of the problem is similar. As I
wrote, now it appears that kdelibs3 is linked with the old png
library, and needs to be removed -- ironically, in order to rebuild
kdelibs3.

> What I normally would have suggested, but failed to do in this case
> because cairo seemed like the obvious culprit, was to install
> sysutils/bsdadminscripts and run 'pkg_libchk -o | grep png" to track
> down ports that still depend on the old libpng. It will take a few
> minutes to run.

That would be one way to prevent a recurrence of this kind of problem
(although not all possible problems) during the remainder of the
update.  Or he could just remove the present offender, and continue
with update, intervening again if necessary.

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

Re: Why Are You NOT Using FreeBSD?

[b. f.]

> On 03 June 2012 PM 5:42:55 Adam Strohl wrote:
> > On 6/3/2012 17:24, Etienne Robillard wrote:
> > I feel like this thread is grossly overstating how often ports are
> > broken which is super rare in my experience. Proposing a version'd ports
> > tree seems like a bad-practice-encouraging-solution to a problem that
> > doesn't really exist [in my experience].
> >
> do a simple thing. Install a naked 8.3, 9.0 or 10.0 on a fresh hard disk. Get 
> then the ports tree and start compiling X.
>
> I did not get a running system since at least 2007 when I did this. There was 
> always at least one manual intervention needed.
>
> I did this the last time in the first week of May.
>
> Yes, I know how to fix this. Yes, I reported things like this at the 
> beginning. After getting always the answer that it is working on my machine, 
> I stopped reporting it.
>

It is difficult to know how to respond to these anecdotes -- we don't
know how many and what kind of problems you encountered, what you did
when you performed these builds, and how you went about reporting the
problems -- all of which can make a big difference in the outcome.  I
will only say that, apart from occasional disruptions, it is usually
possible now to build commonly-used ports with default options on
amd64 and i386 in controlled builds without incident.  And the numbers
from the FreeBSD package-building cluster support this:

http://pointyhat.freebsd.org/errorlogs/packagestats.html
http://portsmon.FreeBSD.org/chartsandgraphs/brokenpercents.html

On a live system, or for a custom build, I have had to make occasional
changes (or have chosen to) -- but again I have found that it is
usually possible to keep several hundred ports in reasonably good
working order, even with weekly updates, without intervening too
often.  Someone who was more conservative -- avoids frequent updates,
especially during major changes; backs-up packages; checks the mailing
lists before updating; etc. -- shouldn't encounter too many problems.
But if you are not prepared to make occasional changes, then I do not
know why you are building from source, especially on a live system,
instead of using binary packages.  If you don't wish to use packages
produced on the FreeBSD cluster, then it is not too hard to use a
tinderbox or pkgng to produce your own, or get someone to do it for
you.

With regard to your request for a versioned Ports trees -- well, we
have had that for about 18 years, since the Ports tree is kept under
version control in CVS, and you are free to check out snapshots using
anonymous CVS or CVSup -- all you have to do is specify a tag or date
spec, as described in several places -- csup(1), cvs(1), the FreeBSD
Handbook, etc. You can even get per-delta granularity via ctm(1), and
I'd guess that there is a way to do it using rsync, too.   And if you
don't like CVS, then you can import the repository into another VCS.
So it has always been possible to roll back to earlier versions of the
ports tree without too much trouble.  What is more difficult, and what
is unlikely to happen soon, because we don't have enough manpower and
computing resources, is to maintain multiple versions of the tree that
are selectively updated.  But I suspect that it would be less trouble
for you to just work to solve problems with the current Ports tree
than to try to do this yourself.

And you are, of course, free to use FreeBSD with other packaging
systems, like pkgsrc.  Or to use one of the FreeBSD hybrids produced
by Gentoo, Debian, et al., with their respective packaging systems.
Using FreeBSD does not mean that you have to use FreeBSD Ports,
although this may be a good choice for you.

As far as your example from your other message about having to combine
a png update with work over the course of a weekend -- I don't know
why you would be fooling around with an update of your Ports tree or
your installed ports while working under a tight deadline, but if you
have backups, you should be able to recover from most problems fairly
quickly.

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

Re: portmaster -r png- Stop in /usr/ports/devel/gobject-introspection

[b. f.]

> > /usr/bin/ld: warning: libpng.so.6, needed by /usr/local/lib/libcairo.so, not
> > found (try using -rpath or -rpath-link)
> > /libexec/ld-elf.so.1: Shared object "libpng.so.6" not found, required by
> > "libcairo.so.2"
> > Command
> > '['/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8/tests/scanner/tmp-introspectyVPLgw/Regress-1.0',
> > '--introspect-dump=/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8/tests/scanner/tmp-introspectyVPLgw/types.txt,/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8/tests/scanner/tmp-introspectyVPLgw/dump.xml']'
> > returned non-zero exit status 1
> > gmake[4]: *** [Regress-1.0.gir] Fel 1
> > gmake[4]: Lämnar katalogen
> > "/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8/tests/scanner"
> > gmake[3]: *** [all-recursive] Fel 1
> > gmake[3]: Lämnar katalogen
> > "/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8/tests"
> > gmake[2]: *** [all] Fel 2
> > gmake[2]: Lämnar katalogen
> > "/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8/tests"
> > gmake[1]: *** [all-recursive] Fel 1
> > gmake[1]: Lämnar katalogen
> > "/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8"
> > gmake: *** [all] Fel 2
> > *** Error code 1
>
> According to the message, libcairo.so.s is linked to libpng.so.6 which
> is now obsolete. Looks like cairo has not been rebuilt for some
> reason. Do you have /var/db/pkg/cairo-*/+IGNOREME? The problem with
> cairo 1.10.2 appears to now be fixed, so you should be able to upgrade
> it if that is why it did not get updated.

If he used the commands as he described, then portmaster should
ultimately have updated cairo.  But since the gobject-introspection
port doesn't depend upon cairo, at least according to the makefiles in
Ports, there was no reason for portmaster to update cairo _before_
updating gobject-introspection.  portmaster cannot anticipate that the
gobject-introspection build can be affected by the presence of another
port that is supposedly unrelated, and many such problems are not
uncovered by the routine testing that is conducted with sandboxed
builds. That is why one-port-at-a-time, un-sandboxed, "in-place"
updates are risky, especially for major updates (that is mentioned
near the bottom of the portmaster manpage, although not in so many
words), even though many people find them to be convenient.

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

Re: Shared object "libpng.so.6"

[b. f.]

>> Stop in /usr/ports/x11/kdelibs3.

> removed manually, if portmaster hasn't already done so.  Here it looks
> like your new build of kde3libs is sloppily linking against the old
> version of kde3libs that you still have installed, and which still

Obviously I meant kdelibs3 in the above -- this is starting to make me
dizzy, too.

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

Re: Shared object "libpng.so.6"

[b. f.]

> /libexec/ld-elf.so.1: Shared object "libpng.so.6" not found, required by
> "libkdefx.so.6"
> /usr/local/bin/moc ./domainbrowser.h -o domainbrowser.moc
> gmake[2]: *** [settings.h] Fel 1
> gmake[2]: *** Inväntar oavslutade jobb...
> gmake[2]: Lämnar katalogen
> "/usr/ports/x11/kdelibs3/work/kdelibs-3.5.10/dnssd"
> gmake[1]: *** [all-recursive] Fel 1
> gmake[1]: Lämnar katalogen "/usr/ports/x11/kdelibs3/work/kdelibs-3.5.10"
> gmake: *** [all] Fel 2
> *** Error code 1
>
> Stop in /usr/ports/x11/kdelibs3.

[top-posting reshuffled]

> I keep getting this error :-(

... and the answer is still essentially the same:  remove the package
that has the dependency upon the old png library that you have removed
('ldconfig -vr' and 'pkg_info -W' can help here) and proceed with your
update. After your update is done, rebuild the ports that you have
removed manually, if portmaster hasn't already done so.  Here it looks
like your new build of kde3libs is sloppily linking against the old
version of kde3libs that you still have installed, and which still
depends upon the old png libraries.  That's not good, but it happens
sometimes with normal builds on live systems, because the library
search paths in a lot of ports are not handled carefully.  (And it
happens with ports that are more actively used than kdelibs3, which is
deprecated.) Remember that these updates are tested in sandboxed
builds, with a default base system, and where only the software that
is necessary for the build is installed -- so the maintainers won't
encounter every problem that can arise during a normal build on a live
system, where there could be customizations and other installed
software that can unexpectedly interact with the build.  And thus
portmaster can't avoid all of these problems, even if you follow some
of the procedures mentioned in UPDATING,  because it orders the
updates only according to the dependency information that is hardcoded
in the port Makefiles or in packages, and doesn't deinstall ports
before updating.  If you want to be safe, then use packages, or build
your ports in a sandbox.  Or remove all of the software that you
intend to update _before_ beginning a major update, instead of trying
to take shortcuts just to avoid some downtime. (You could follow a
procedure similar to that described in the portmaster manpage for
"Using portmaster to do a complete reinstallation of all your ports",
but limit yourself to the subset of ports that are directly _and_
indirectly dependent upon the port that you are updating.) Some people
use the "-w" flag with portmaster, which keeps the old shared
libraries around, but that can't solve all of these problems, and can
sometimes lead to more subtle problems that are harder to solve.


> I just wrote in another post that on one of my machines where I
> successfully have done the same png- update I can't find libpng.so.6
> anywhere!

And neither can the loader, which is why you are seeing the error -- because you
removed that library when updating png, as I tried to explain to you earlier.

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

Re: Please rebuild all ports that depend on PNG

[b. f.]

> > Realy no other possibility?!
>
> You need to rebuild all the ports that install binaries that link
> against libpngNN.so.NN.  That is actually a subset of the ports that
> depend on graphics/png -- unfortunately it takes some effort to identify
> precisely what does need rebuilding.  There is the pkg_libchk script
> (which is part of sysutils/bsdadminscripts) that can help.
...
> Use pkg_libchk to prioritise the ports that really need to be rebuilt.

Lawrence Stewart's convenient script can be used with portmaster to
perform this kind of update:

https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh

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

Re: make failed for graphics/gdk-pixbuf2

[b. f.]

Leslie Jensen wrote:

...

> ImportError:
> /usr/local/lib/gobject-introspection/giscanner/_giscanner.so: Undef
> ined symbol "PyUnicodeUCS4_AsUTF8String"
> gmake[4]: *** [GdkPixbuf-2.0.gir] Fel 1
> gmake[4]: Lämnar katalogen

It's difficult to determine the source of the problem without more
information -- are you using python26-2.6.8_1 or python27-2.7.3_1?  If
so, try updating to the latest revision ( _2, in each case) of your
python port,  with UCS4 support enabled, and then rebuild the ports
that depend upon it. There were problems in the penultimate revisions
of those ports, which have since been corrected.

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

graphics/djvulibre

[b. f.]

Are there many users of the QT3 djvulibre GUI in
ports/graphics/djvulibre who would have difficulties switching to one
of the other GUIs?  The upstream developers have removed it from the
latest versions of the djvulibre distribution, and I am wondering
whether it is worth some special effort to retain it when I update the
djvulibre ports.

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

Re: checksum mismatch in print/texinfo

[b. f.]

>
>
> On Sat, May 19, 2012 at 5:13 AM, Henry Miller  wrote:
>
> >
> > subject says it all, I'm trying to update texinfo, and getting a checksum
> > mismatch.  I deleted the distfiles in questions, so I'm not sure what else
> > to
> > try.
> >
> > shairia# uname -a
> > FreeBSD shairia.millerfarm.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu
> > Feb 17
> > 02:41:51 UTC 2011 root at mason.cse.buffalo.edu:
> > /usr/obj/usr/src/sys/GENERIC
> > amd64
> > shairia# rm ../../distfiles/tex*
> > shairia# make
> > ===>  License check disabled, port has not defined LICENSE
> > => texinfo-4.13.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
> > => Attempting to fetch http://ftp.gnu.org/gnu/texinfo/texinfo-4.13.tar.gz
> > texinfo-4.13.tar.gz   100% of 2686 kB  785 kBps
> > => texinfo.tex doesn't seem to exist in /usr/ports/distfiles/.
> > => Attempting to fetch http://ftp.gnu.org/gnu/texinfo/texinfo.tex
> > fetch: http://ftp.gnu.org/gnu/texinfo/texinfo.tex: size mismatch: expected
> > 321229, actual 321252
> > => Attempting to fetch ftp://ftp.gnu.org/gnu/texinfo/texinfo.tex
> > fetch: ftp://ftp.gnu.org/gnu/texinfo/texinfo.tex: size mismatch: expected
> > 321229, actual 321252
> > => Attempting to fetch
> > http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texinfo.tex
> > fetch: http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texinfo.tex:
> > size
> > unknown
> > fetch: http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texinfo.tex:
> > size of
> > remote file is not known
> > texinfo.tex340  B 2460 kBps
> > => texi2dvi doesn't seem to exist in /usr/ports/distfiles/.
> > => Attempting to fetch http://ftp.gnu.org/gnu/texinfo/texi2dvi
> > fetch: http://ftp.gnu.org/gnu/texinfo/texi2dvi: size mismatch: expected
> > 57940,
> > actual 58102
> > => Attempting to fetch ftp://ftp.gnu.org/gnu/texinfo/texi2dvi
> > fetch: ftp://ftp.gnu.org/gnu/texinfo/texi2dvi: size mismatch: expected
> > 57940,
> > actual 58102
> > => Attempting to fetch
> > http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texi2dvi
> > fetch: http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texi2dvi: size
> > unknown
> > fetch: http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texi2dvi: size
> > of
> > remote file is not known
> > texi2dvi   337  B 2438 kBps
> > ===>  Extracting for texinfo-4.13.20120406
> > => SHA256 Checksum OK for texinfo-4.13.tar.gz.
> > => SHA256 Checksum mismatch for texinfo.tex.
> > => SHA256 Checksum mismatch for texi2dvi.
> > ===>  Refetch for 1 more times files: texinfo.tex texi2dvi
> > ===>  License check disabled, port has not defined LICENSE
> > => texinfo.tex doesn't seem to exist in /usr/ports/distfiles/.
> > => Attempting to fetch http://ftp.gnu.org/gnu/texinfo/texinfo.tex
> > fetch: http://ftp.gnu.org/gnu/texinfo/texinfo.tex: size mismatch: expected
> > 321229, actual 321252
> > => Attempting to fetch ftp://ftp.gnu.org/gnu/texinfo/texinfo.tex
> > fetch: ftp://ftp.gnu.org/gnu/texinfo/texinfo.tex: size mismatch: expected
> > 321229, actual 321252
> > => Attempting to fetch
> > http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texinfo.tex
> > fetch: http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texinfo.tex:
> > size
> > unknown
> > fetch: http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texinfo.tex:
> > size of
> > remote file is not known
> > texinfo.tex340  B 2443 kBps
> > => texi2dvi doesn't seem to exist in /usr/ports/distfiles/.
> > => Attempting to fetch http://ftp.gnu.org/gnu/texinfo/texi2dvi
> > fetch: http://ftp.gnu.org/gnu/texinfo/texi2dvi: size mismatch: expected
> > 57940,
> > actual 58102
> > => Attempting to fetch ftp://ftp.gnu.org/gnu/texinfo/texi2dvi
> > fetch: ftp://ftp.gnu.org/gnu/texinfo/texi2dvi: size mismatch: expected
> > 57940,
> > actual 58102
> > => Attempting to fetch
> > http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texi2dvi
> > fetch: http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texi2dvi: size
> > unknown
> > fetch: http://www.gtlib.cc.gatech.edu/pub/gnu/gnu/texinfo/texi2dvi: size
> > of
> > remote file is not known
> > texi2dvi   337  B 2570 kBps
> > ===>  License check disabled, port has not defined LICENSE
> > => SHA256 Checksum OK for texinfo-4.13.tar.gz.
> > => SHA256 Checksum mismatch for texinfo.tex.
> > => SHA256 Checksum mismatch for texi2dvi.
> > ===>  Giving up on fetching files: texinfo.tex texi2dvi
> > Make sure the Makefile and distinfo file
> > (/usr/ports/print/texinfo/distinfo)
> > are up to date.  If you are absolutely sure you want to override this
> > check, type "make NO_CHECKSUM=yes [other args]".
> > *** Error code 1
> >
> > Stop in /usr/ports/print/texinfo.
> > *** Error code 1
> >
> > Stop in /usr/ports/print/texinfo.
> >
> > Please apply the following diff, and let me know if that works for you:
>
> Index: distinfo
> =

Re: BUILD_DEPENDS= RUN_DEPENDS=

[b. f.]

> Hi,
>
> I was trying to append to these in my /etc/make.conf and found that a
> large (thousands) number of ports are using = instead of +=, thus
> destroying any user-supplied depends.
>
> The use case for wanting to do this is to force devel/ccache to be a
> build dependency on all ports, for package building. Or to force in a
> particular library along with LDFLAGS into particular ports. This is
> achievable by modifying bsd.local.mk, but is not ideal.
>
> This goes along with updating all CLFAGS/LDFLAGS to use += instead of =.
>
> If there is no objection to this route, I will follow-up with a patch/PR
> to update the ports and handbook.

Only those user-supplied depends that are added in makefiles included
before those lines are parsed (like make.conf) can be affected. But
there are a number of other makefiles that exist solely for
customizations like you describe -- you mentioned one of them,
bsd.local.mk.  It is safer and more efficient to move as many of your
customizations as possible out of make.conf, and into these other
makefiles, as was intended.  "+=" was used for a few other variables
because these few were often already defined in make.conf for other
reasons -- but we are trying to discourage abuse of make.conf, so
making a large number of unnecessary changes to make it possible for
further additions to make.conf is a bad idea.

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

Re: lang/lua: It does need gmake.

[b. f.]

On 3/16/12, Jeremy Messenger  wrote:
> On Fri, Mar 16, 2012 at 5:49 AM, b. f.  wrote:
>> Jeremy Messenger wrote:
>>> On Thu, Mar 15, 2012 at 6:23 PM, Chuck Swiger  wrote:
>>> > On Mar 15, 2012, at 4:18 PM, Jeremy Messenger wrote:
>>> >> Figured out. Add custom CFLAGS in the make.conf and you will get a
>>> >> build failure with make but not gmake. Here's what I have in my
>>> >> make.conf:
>>> >>
>>> >> CFLAGS= -O2 -fno-strict-aliasing -pipe -g
>>> >> STRIP=
>>> >
>>> > Does it work properly if you use "CFLAGS+=" instead?
>>>
>>> It will, but you do not need to put '+' in make.conf. I have same
>>> CFLAGS for years and years, btw.
>>
>> If you have been making these assignments unconditionally, then for
>> years and years you have been in danger of breaking or damaging the
>> builds for many ports that explicitly invoke make(1) more than once
>> (and thus read make.conf more than once), by clobbering prior changes
>> to CFLAGS or STRIP that are made in port makefiles.  Despite the
>> misleading examples in the base-system example make.conf, this kind of
>> customization is not supported for Ports, and not encouraged.  You
>> should take steps to ensure that your custom values are set only once,
>> before any top-level port Makefile is parsed.  You can define them
>> conditionally, or move them to another makefile that is included only
>> once, or disable multiple inclusions of make.conf for Ports by using
>> something like "__MAKE_CONF=/dev/null" in the right place.
>
> Any ports have to respect the CFLAGS, see the porter handbook. If it
> fails to do then it needs to be fixed. Add '+' in the make.conf is not
> right way to do it as it's merely add in exists CFLAGS.

What we actually require is that if you pass a reasonable set of
CFLAGS to the top-level of a port build, in the environment or an
included makefile, then the port uses those flags, *with as few
additions or changes as may be necessary to successfully build the
port*.  It does *not* necessarily mean that the port will only use the
user-defined CFLAGS, and very few ports do so -- most ports make
reasonable and necessary changes to the flags for parts of the port,
either in the port Makefile, the included makefiles in ports/Mk, or
the distribution makefiles.  These changes may be contained in CFLAGS
or another variable, or they may be explicit.  They typically include
aliasing switches, rpath instructions, changes to the search
directories for headers and libraries, parameter definitions,
PIC-related flags, etc.  The fact that ports can alter CFLAGS itself
is explicitly mentioned in the Porter's Handbook, and is evident in
the ports infrastructure: ports/Mk makefiles routinely alter CFLAGS;
CFLAGS are typically passed to distribution makefiles in MAKE_ENV, not
in MAKE_ARGS, so that they will be mutable in those makefiles; etc.  I
think that this should be clear to a committer of your experience.

As I wrote before, your unconditional assignment of CFLAGS in
make.conf can break or damage many ports, and you should not ask or
expect port maintainers to add unnecessary patches to ports in order
to support this unsafe practice.  I already mentioned several ways in
which you can safely customize the CFLAGS (without "+=") in my
previous message.

>
> mandree, thanks for took care of it!
>

On the contrary, the port is now damaged.  This is a good example of
the harmful consequences of make.conf abuse.  lang/lua now confusingly
and unnecessarily passes CFLAGS to the distribution makefiles both in
the environment and on the command-line.  More importantly, the

CFLAGS+=  -Wall $(MYCFLAGS)

in ${WRKSRC}/src/Makefile no longer works, because adding CFLAGS to
MAKE_ARGS has made CFLAGS immutable in the distribution makefiles.
This means that the components are built without -DLUA_USE_LINUX, so
functionality has been removed from the port.  This change should be
reverted.

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

Re: lang/lua: It does need gmake.

[b. f.]

Jeremy Messenger wrote:
> On Thu, Mar 15, 2012 at 6:23 PM, Chuck Swiger  wrote:
> > On Mar 15, 2012, at 4:18 PM, Jeremy Messenger wrote:
> >> Figured out. Add custom CFLAGS in the make.conf and you will get a
> >> build failure with make but not gmake. Here's what I have in my
> >> make.conf:
> >>
> >> CFLAGS= -O2 -fno-strict-aliasing -pipe -g
> >> STRIP=
> >
> > Does it work properly if you use "CFLAGS+=" instead?
>
> It will, but you do not need to put '+' in make.conf. I have same
> CFLAGS for years and years, btw.

If you have been making these assignments unconditionally, then for
years and years you have been in danger of breaking or damaging the
builds for many ports that explicitly invoke make(1) more than once
(and thus read make.conf more than once), by clobbering prior changes
to CFLAGS or STRIP that are made in port makefiles.  Despite the
misleading examples in the base-system example make.conf, this kind of
customization is not supported for Ports, and not encouraged.  You
should take steps to ensure that your custom values are set only once,
before any top-level port Makefile is parsed.  You can define them
conditionally, or move them to another makefile that is included only
once, or disable multiple inclusions of make.conf for Ports by using
something like "__MAKE_CONF=/dev/null" in the right place.

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

Re: graphics/png does not build with lang/gcc

[b. f.]

On 3/8/12, Tijl Coosemans  wrote:
> On Thursday 08 March 2012 11:10:42 Gautam wrote:
>> On Thu, Mar 8, 2012 at 3:39 PM, Gautam  wrote:
>>> On Wed, Mar 7, 2012 at 5:41 PM, b. f.  wrote:
>>>>> On Mon, Feb 27, 2012 at 9:51 PM, Gautam  wrote:
>>>>> Should I file a PR for this?
>>>>
>>>> There are some unresolved problems with stack protection, but you
>>>> should not have to encounter them when building this port.  The custom
>>>> gcc article that you are attempting to use was written at a time when
>>>> some of the related port Makefiles had some shortcomings that no
>>>> longer exist, and is not the recommended way to use lang/gcc* for
>>>> ports.  For all but a handful of ports that lang/gcc* depends upon, or
>>>> those that don't respect the toolchain-related variables, you can just
>>>> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
>>>> environment, an included Makefile, or on the command line. I have been
>>>> building graphics/png in this way for years.  You can and should
>>>> dispense with the libmap.conf additions, the hardcoded CC, CXX, and
>>>> CPP in make.conf, etc.
>>>
>>> Thanks for your comments. I now tried this on the fresh 9.0-REL system I
>>> created, -- I cleared out make.conf, deleted libmap.conf. The problem
>>> still
>>> exists. Any pointers?
>>>
>>> Here is the log:
>>>
>>> uname -a
>>>
>>> FreeBSD vmboX 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:15:25 UTC
>>> 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>>> vmboX# pkg_version -0v [K [Kv
>>>
>>> binutils-2.22   <   needs updating (port has 2.22_1)
>>> gcc-4.6.2   <   needs updating (port has 4.6.2_1)
>>> gmp-5.0.2   <   needs updating (port has 5.0.3)
>>> libiconv-1.13.1_1   =   up-to-date with port
>>> mpc-0.9 =   up-to-date with port
>>> mpfr-3.1.0_2=   up-to-date with port
>>> vmboX# cd /etc
>>>
>>>  vmboX# cat /etc/make.conf
>>>
>>> vmboX# cat /etc/liba [Kmap.conf
>>>
>>> cat: /etc/libmap.conf: No such file or directory
>>>
>>> vmboX# cd /usr/ports/graphics/png
>>>
>>> vmboX# make clean
>>>
>>> ===>  Cleaning for png-1.4.8_1
>>>
>>> vmboX# env USE_GCC=4.6 make
>>>
>>> ===>  Vulnerability check disabled, database not found
>>>
>>> ===>  License check disabled, port has not defined LICENSE
>>> ===>  Found saved configuration for png-1.4.8_1
>>> ===>  Extracting for png-1.4.8_1
>>>
>>> => SHA256 Checksum OK for libpng-1.4.8.tar.xz.
>>> => SHA256 Checksum OK for libpng-1.4.8-apng.patch.gz.
>>> /bin/cp /usr/ports/distfiles//libpng-1.4.8-apng.patch.gz
>>> /usr/ports/graphics/png/work/libpng-1.4.8/
>>> /usr/bin/gzip -nf -9 -d
>>> /usr/ports/graphics/png/work/libpng-1.4.8/libpng-1.4.8-apng.patch.gz
>>> ===>  Patching for png-1.4.8_1
>>> ===>  Applying extra patch
>>> /usr/ports/graphics/png/work/libpng-1.4.8/libpng-1.4.8-apng.patch
>>> ===>  Applying FreeBSD patches for png-1.4.8_1
>>> ===>   png-1.4.8_1 depends on executable: gcc46 - found
>>> ===>   png-1.4.8_1 depends on file: /usr/local/bin/as - found
>>> ===>  Configuring for png-1.4.8_1
>>> ===>  Building for png-1.4.8_1
>>> ( cat scripts/libpng-config-head.in;  echo prefix=\"/usr/local\";  echo
>>> libdir=\"/usr/local/lib\";  echo ccopts=\"-O2 -pipe
>>> -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing\";  echo
>>> cppflags=\"\";  echo I_opts=\"-I/usr/local/include/libpng\";  echo
>>> L_opts=\"-L/usr/local/lib\";  echo libs=\"-lpng -lz -lm\";  echo
>>> ldopts=\"-Wl,-rpath=/usr/local/lib/gcc46\";  cat scripts/
>>> libpng-config-body.in ) > libpng-config
>>> chmod +x libpng-config
>>> gcc46 -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing  -I.
>>> -std=gnu99 -fstack-protector  -c png.c
>>> gcc46 -fpic -DPIC -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc46
>>> -fno-strict-aliasing  -I. -std=gnu99 -fstack-protector  -c png.c -o
>>> png.So
>>> gcc46 -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing  -I.
>>> -st

Re: graphics/png does not build with lang/gcc

[b. f.]

On 3/8/12, Mark Linimon  wrote:
> On Wed, Mar 07, 2012 at 12:11:52PM +0000, b. f. wrote:
>> The custom gcc article that you are attempting to use was written at
>> a time when some of the related port Makefiles had some shortcomings
>> that no longer exist, and is not the recommended way to use lang/gcc*
>> for ports.
>
> Would you be interested in helping to update it?

If you like, I can suggest a few changes.  But I thought that it was
primarily Martin's article, which he wrote when he was benchmarking
perl with different toolchains.

>
>> For all but a handful of ports that lang/gcc* depends upon, or
>> those that don't respect the toolchain-related variables, you can just
>> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
>> environment, an included Makefile, or on the command line.
>
> Setting USE_* in e.g. /etc/make.conf is always incorrect, see:
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-depend.html#USE-VARS
>
> You can wind up in the degenerate case maknig gcc46 depend upon itself.

That is why I wrote: "... all but a handful of ports that lang/gcc*
depends upon ...".

The OP wanted to find a way to use lang/gcc* in a custom build of a
port -- which, as you know from your own work, isn't well-supported in
Ports right now. (We make an attempt to be flexible, and there is some
infrastructure to do so, but many ports aren't tested with different
toolchains.  Some tinkering is inevitably involved if any substantial
number of ports are built in this way.) The OP was willing to use
invasive changes suggested by the custom gcc article.  Therefore, I
assumed that he wasn't interested in strictly adhering to our
guidelines, and just wanted a pragmatic solution, which is what I
offered to him.  Setting USE_GCC in this case is safer and easier than
what he was doing.  I didn't intend to suggest that anyone make
unqualified use of it in make.conf.  There is already far too much
abuse of that special file.

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

Re: graphics/png does not build with lang/gcc

[b. f.]

On 3/7/12, Andriy Gapon  wrote:
> on 07/03/2012 14:11 b. f. said the following:
>> you can just
>> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
>> environment, an included Makefile, or on the command line
>
> BTW, our traditional taxonomy seems to be: "USE_XXX" is for stuff that ports
> really require, "WITH_XXX" is for user preferences.
> So it might make sense to create a WITH_GCC knob specifically for the use
> that you
> suggested above.

Yes, that is a reasonable suggestion, not only for lang/gcc*, but also
for a few other compilers.  But I think that before such a
user-configurable knob can be introduced, with an implied promise of
support for it, several outstanding problems with the widespread use
of such a knob need to be addressed -- for example, the (still)
pending fixes to USE_BINUTILS, changes to the compiler configurations
(to fix things like PIE and stack protection), changes to the use of
libtool, and introduction of periodic checks to find and fix ports
that don't respect the toolchain variables.

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

Re: graphics/png does not build with lang/gcc

[b. f.]

> Adding dinoex (Maintainer of graphics/png).
>
> On Mon, Feb 27, 2012 at 9:51 PM, Gautam  wrote:
>
> >
> >
> >> Still didnt work for me -- did another buildworld and retried to check if
> > there was something else messed up.
> >
> > I am moving back to base gcc for now. Waiting for redports lang/gcc
> > backend to come up ;) and will check this again on 8-stable as well.
> >
> >
> >
>
> I have tested this on three systems now -- 8.2-REL (fresh), 9.0-REL(fresh)
> and 9.0-STABLE (original system). The problem is visible on all of these
> releases. I have now root-caused this problem (that graphics/png does not
> build with lang/gcc on 8.2 or 9.0), proposed solution solves it on all
> three systems.
>
> Similar PRs were found: 155334 and 141238.
>
> Solution is to add -lssp_nonshared to LDADD in
> work/libpng-1.4.8/scripts/makefile.freebsd.
>
> LDADD+= -lm -lz -lssp_nonshared
>
> However, I suppose this be conditional on OSVERSION >= 80 so that it
> doesnt break older FreeBSD releases but I am not sure of the final solution
> to this -- maybe add a conditional patch ? How is that usually done?
>
> Should I file a PR for this?

There are some unresolved problems with stack protection, but you
should not have to encounter them when building this port.  The custom
gcc article that you are attempting to use was written at a time when
some of the related port Makefiles had some shortcomings that no
longer exist, and is not the recommended way to use lang/gcc* for
ports.  For all but a handful of ports that lang/gcc* depends upon, or
those that don't respect the toolchain-related variables, you can just
install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
environment, an included Makefile, or on the command line. I have been
building graphics/png in this way for years.  You can and should
dispense with the libmap.conf additions, the hardcoded CC, CXX, and
CPP in make.conf, etc.

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

Re: Error in INDEX file

[b. f.]

"Conrad J. Sabatier"  wrote:

> While investigating the cause of sudden crashes this morning in
> mkreadmes, I discovered that my INDEX-10 file has the following as its
> first line:
>
> make: don't know how to make describe(continuing)||

ports/Tools/scripts/domakedescribe and some of the other scripts in
the same directory can help solve such problems.

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

Re: lang/gcc rumdependencies?

[b. f.]

>The main question is why this port (and everythin else with
>USE_GCC=4.6+) depend on lang/gcc46 and not lang/gcc. Most port users
>dislike building latest gcc snapshot on a weekly basis.

Indeed.  But (as discussed before on this list), they don't have to,
if they find this to be a problem: they can remove lang/gcc46 and
replace it with lang/gcc.

>Maybe it would be good to move current lang/gcc46 to lang/gcc46-devel
>and rename lang/gcc to lang/gcc46?

No, because in time lang/gcc will become a stable release of 4.7.x,
and so on ...

A switch to lang/gcc is planned, as previously mentioned on this list.
 For the timing of the changes, you will have to ask Gerald -- he is
probably waiting for the next stable release of gcc 4.6, which will
contain some bugfixes that the current version of lang/gcc does not
have, before making the switch.  So far, stable releases have been
made every 3-4 months on that branch, and the last one was at the end
of October.

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

Re: math/R vs. devel/pcre

[b. f.]

> I had a problem rebuilding math/R this morning after updating
> devel/pcre; I'm wondering if there's something obvious (to folks
> other than me) that I did incorrectly.

...

>gcc46 -std=gnu99 -export-dynamic -fopenmp -Wl,-rpath=/usr/local/lib/gcc46 -o 
>R.bin > Rmain.o -L../../lib -lR -lRblas
> ../../lib/libR.so: undefined reference to `_pcre_valid_utf8'
> collect2: ld returned 1 exit status
> *** Error code 1

I can reproduce this without portmaster.  The pcre ABI changed with
pcre 8.30, and R may need to be patched in order to use it -- or there
may be a problem with the pcre port.  I will look into this.  In the
meantime, you will probably be able to build R by selecting
WITHOUT_PCRE_PORT, so that the version of pcre that is bundled with R
is used, rather than devel/pcre.

Thank you for reporting the problem.  However, in the future, if you
believe there is a problem with R, please send a message directly to
me (the port maintainer, b...@freebsd.org), so that I will see it
sooner.

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

Re: Please test your commits

[b. f.]

> On 12.02.2012 22:43, Stephen Montgomery-Smith wrote:
> > On 02/12/2012 03:33 PM, Andriy Gapon wrote:
> >> on 12/02/2012 23:22 Stephen Montgomery-Smith said the following:
> >>> On 02/12/2012 03:15 PM, Andriy Gapon wrote:
> >>>
>  Today I became another user of redports.org.  I can definitely
>  recommend it.
> >>>
> >>> Yes, but it is not without its problems.  I tried testing math/sage
> >>> on
> >>> redports.org.  It reported an error building the dependency
> >>> math/atlas, which
> >>> built fine on mine and other people's systems.
> >>
> >> But still this is an instance of environment where the port can
> >> fail, so it
> >> warrants an investigation and fixing.  Either in the port or in the
> >> redports
> >> infrastructure.
> >
> > Yes, you are correct.  In fact, in the case of math/atlas there is
> > the following report.  It looks like people are working on it.
> >
> >
> > http://portsmon.freebsd.org/portoverview.py?category=math&portname=atlas&wildcard=
>
> I think this isn't directly related. The build on redports had status
> "dud" in
> math/atlas which means the port has set IGNORE. I have no good way of
> telling which
> IGNORE line it is yet but it can only be one of:
>
> You have set WITH_ARCHDEF, but have not defined ARCHDEF
> You must select at least one of WITH_SHARED and WITH_STATIC
>
> both sound strange.

There is nothing strange about them: they just indicate errors arising
from invalid choices of OPTIONS.  The build is more likely to be
broken by MANUAL_PACKAGE_BUILD, which uses IGNORE.

math/atlas is a port that -- except in a few cases -- must be built on
the host machine in a dedicated build.  If you have a port that has a
dependency on math/atlas, then it will not be easy to test that port
via a system like Redports.

With regard to the larger issue, ghostscript is a somewhat awkward
port to check, because: it has many dependencies; it has many options
that are used by a considerable number of people; it is maintained by
a group (although Hiroki usually works on it); and it is widely-used.
Even with a reasonable amount of testing (and Hiroki is usually
careful), it is probable that there will be some occasional problems,
at least when ghostscript is not built in a clean sandbox -- and it
isn't on the live systems of many users. So while it is reasonable to
send a message about a port like this to the list, the message should
also be dispatched directly to doceng, and those making reports or
complaints should be patient, and provide as much useful information
as possible.

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

Re: USE_GCC and CC=clang

[b. f.]

> I'm trying to fix a port which absolutely will not build with clang,
> since clang does not support the gcc extension used by this port. I set
> USE_GCC=4.2+, which is the lowest version of GCC which will work, but it
> doesn't properly override CC=clang.
>
> wxs at ack spamdyke % env CC=clang make test-gcc | grep -E "^(CC|USE_GCC)"
> USE_GCC=4.2+
> CC=clang - CXX=c++ - CPP=cpp - CFLAGS="-O2 -pipe -fno-strict-aliasing"
> wxs at ack spamdyke %
>

This problem only arises if the base compiler is gcc 4.2.x and
USE_GCC=4.2+. Otherwise CC will be set to the appropriate gcc
compiler.  Since Gerald (who maintains ports/Mk/bsd.gcc.mk) is trying
to retire lang/gcc42 anyway, it is not a good idea to set USE_GCC=4.2+
in a port.

> I understand this is probably an acceptable behavior, since if the user
> sets CC=clang they are explicitly asking to build with clang. However,
> in the case of a port known to not work with clang, and more importantly
> not able to be fixed, I was hoping there was a knob I could set that
> would forcible override any compiler related environment variables which
> may be set. I didn't find one, so I came up with this quick (and poorly
> tested) patch to do so.

The problem is due to a slight flaw in the implementation of the
USE_GCC=4.2+ case, which will be obviated soon by the removal of this
case. If in the meantime a change is made to bsd.gcc.mk, it should
address this flaw directly -- by setting CC=gcc explicitly where
needed, instead of relying upon the default setting of CC.  Another
knob is unnecessary.

Note that changes to bsd.gcc.mk, good or bad, won't address the cases
where a user sets CC on the command-line via "make  CC= ...", or
adds it to MAKE_ARGS, or sets CC in the environment, and then calls
make with "-e" or "-E CC".  So the right thing to do is to add
something like:

.if !empty(CC:M*clang*)
IGNORE= : clang cannot be used to build this port
.endif

to the port Makefile, after the inclusion of bsd.port.options.mk or
bsd.port.pre.mk (since a user may have set CC in Makefile.local,
Makefile.inc, etc).  Or, better yet, to patch the port so that it can
be built with clang (which may have to be done anyway...).

Regards,

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

Re: [PATCH] lang/gcc -- Fix build on freebsd-current

[b. f.]

> > Actually you can add a dot (.) to these matches, e.g. freebsd[123]* ->
> > freebsd[123].*, etc...  Have you contacted the maintainer
> > (gerald at FreeBSD.org) by the way?
>
> My guess?  We should rip out the [123] and [23] strings entirely.  If
> anyone is running ports on FreeBSD 1, they have more problems than they
> can count right now.
>
> I can personally guarantee that ports don't work on 4.x (I ripped out
> the compat code several years ago that dealt with gross old make(1)
> bugs, etc.) and I think that means not 3.x either.  In any case, the
> official claim is that the Ports Collection only supports 789 as first-
> class citizens right now, not anything older.

Fixes have already been implemented upstream, at Gerald's request, and
are in lang/gcc46.  But these fixes were introduced after the last
stable release of gcc 4.6, which corresponds to lang/gcc.  When a new
version of gcc 4.6 is released, and the port is updated accordingly,
it will include the fixes.  In the meantime, I think Gerald was
waiting for Martin to incorporate the patch to adjust the
run-autotools-fixup target in ports/Mk/bsd.port.mk so that the target
repairs ports like lang/gcc that use non-default *WRKSRC, by expanding
the search in that target to WRKDIR.  There hasn't been any further
word on that for about a month-and-a-half -- presumably Martin is
either busy with other work or is still trying to adjust the patch to
fix some other problems.  But you can make such a change on your own
system.

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

Re: Building ports with gcc46

[b. f.]

On 12/15/11, Andrew W. Nosenko  wrote:
> On Thu, Dec 15, 2011 at 02:05, b. f.  wrote:
>> If you are interested in applying them to a single port, use a test on
>> .CURDIR,
>> or, better yet, add the statement to any of the optional Makefiles that
>> are
>> automatically included by bsd.port.mk and were intended for that purpose
>> --
>> ${MASTERDIR}/Makefile.local, for example.
>
> Unfortunatelly, the Makefile.local included too late for have any
> positive/intended effect (e.g. define port-specific WITH/WITHOUT knob,
> modify CONFIGURE_ARGS,...) in many cases/ports.  Therefore, advise to
> use Makefile.local is unreliable.  And we left in situation, where
> make.conf is the only one reasonable working solution :-(

Certainly Makefile.local is not included as early as make.conf, and so
may not be used for every purpose for which make.conf may be used.
But with regard to the topic of this thread, Makefile.local  is
included before options-handling, and the test for inclusion of
bsd.gcc.mk.  Why did you think otherwise?  Using Makefile.local is
generally safer because of its narrower scope, and because it cannot
be included multiple times if make(1) is invoked recursively, unlike
make.conf.

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

Re: Building ports with gcc46

[b. f.]

> > Is there a way to build devel/protobuf with gcc46? Unfortunately I see
> > a compatibility issue where the software I'm linking against it
> > crashes because of the conflicting stdc++ librray versions. I've tried
> > setting CC, CXX, LDFLAGS but I seem to be missing something else?
> >
> > Thanks,
>
> Hi Ali,
>
> Have you tried adding the following to /etc/make.conf?
>
> USE_GCC=4.6
>
> Note that the directive will bring in a lot of other dependencies with
> it, so you may also want to add WITHOUT_X11=yes to make.conf, if necessary.

USE_GCC is the right statement, but one should be careful about adding such
statements to make.conf without conditions, because you can pollute every
invocation of make(1).  Here, you can cause cycles in your dependency graphs
if you set USE_GCC=4.6 for any of the ports that are required by lang/gcc46.
If you are interested in applying them to a single port, use a test on .CURDIR,
or, better yet, add the statement to any of the optional Makefiles that are
automatically included by bsd.port.mk and were intended for that purpose --
${MASTERDIR}/Makefile.local, for example.  Please be careful in what you add,
or recommend that others add, to make.conf.

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

Re: ports: clang: error: unsupported option '-dumpspecs'

[b. f.]

> > -dumpspecs is a gcc internal thing that clang will never support (it doesnt 
> > use
> > specs). It's wrong for ports to mess with the internals of the compiler and
> > this should be fixed in a clean way.
> >
> > Ie. we have to replace the -dumpspec | grep something with a saner check.
>
> The fact that gcc -dumpspecs is looked at at all is a really bad
> idea. Do you know which port in the tree is calling this?

As far as I know, in the Ports tree there are only:

editors/emacs
editors/emacs-devel
graphics/OpenEXR
multimedia/vdpau-video

which use it in an ill-conceived (and now probably unnecessary) test
for thread libraries.  However, there are many more instances within
the configuration scripts of various port distfiles, and I do not
think that all of these are protected by tests for gcc*.

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

Re: lang/gcc46

[b. f.]

> > We have lang/gcc already. This port is created for perferred gcc releases
> > (4.6.2 currently). What we're waiting for is a bsd.gcc.mk update to allow
> > users build ports with lang/gcc instead of lang/gcc46.
>
> Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does not
> seem like this should be too difficult. Just a matter of the right
> person having the time. Would ports specifying gcc46 need to be
> touched?

The solution to a great many problems is "a matter of the right person
having the time".

Gerald had planned to do this after the ports tree had been completely
unfrozen. It is likely that only a few dependent ports will have to be
changed. You can make this change now, simply by removing lang/gcc46
and installing lang/gcc, and then rebuilding all dependent ports (this
last step may not be necessary in many cases, but it is better to be
safe).  This may result in some false accounting of dependencies in
your package database, but you can alter this if you need to, or use
one of the alternative dependency accounting mechanisms in portmaster
or portupgrade.

Or you can try something like the attached patch, which will fix the
dependency accounting -- but you will then have to replace
_GCC_BUILD_DEPENDS with _GCC_PORT_DEPENDS (the latter will then be a
misnomer) in math/atlas, math/atlas-devel, math/gotoblas, math/R,
net-p2p/eiskaltdcpp-* (and soon perhaps also lang/libobjc2, if it is
altered to use USE_GCC, which seems likely).  Also, you will have to
patch the CSUFF lines in print/pdftk.  Gerald's eventual changes will
probably be similar, but cleaner.  For example, he may change the
names to more accurately reflect their new roles, and define a
variable indicating which directory contains the shared libraries
needed at runtime, for the benefit of the aforementioned ports,
french/aster, graphics/visionworkbench, etc., so that they are less
likely to require modifications if the internals of bsd.gcc.mk change
again.

b.


bsd.gcc.mk.diff
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: altivec for boinc-setiathome-enhanced on powerpc?

[b. f.]

> despite the --disable-altivec configure option in the Makefile of
> astro/boinc-setiathome-ennhanced (which should be removed because it is
> autodetected), it is enabled automatically for PowerPC but there it
> fails with cc1plus not recognizing the -faltivec option:
>
> http://pointyhat.freebsd.org/errorlogs/powerpc-errorlogs/e.9.20111009030040/boinc-setiathome-enhanced-6.12_1.log
>
> Does this mean we have no Altivec support or is something else going wrong?

"-faltivec" is only recognized by certain compilers, like Apple's
modified version of gcc.  You can try patching the port to use
"-maltivec -mabi=altivec" instead.  We don't want the presence of such
CPU extensions to be auto-detected by default, because then default
packages that are built on altivec-capable machines may fail on
machines that have the same ARCH, but either do not support altivec,
or have had their altivec support  disabled.  Instead, the
auto-detection should be turned on if !empty(MACHINE_CPU:Maltivec).
This is a little awkward, because the powerpc developers didn't add
code to src/share/mk/bsd.cpu.mk to automatically add altivec to the
MACHINE_CPU of certain variants of powerpc, as was done, for example,
with mmx and certain families of Intel and AMD processors.  But the
users can always add it themselves, in an included Makefile, like
make.conf.

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

Re: 10.0-CUR r226986 && ports (general)

[b. f.]

On 11/3/11, O. Hartmann  wrote:
> Am 11/03/11 18:42, schrieb b. f.:

>So I presume the WITH_FBSD10_FIX flag is set in /etc/make.conf, right?

You can set it in a number of  local Makefiles that are automatically
included during a port build.  That includes make.conf, and the others
mentioned in ports/Mk/bsd.port.mk.  A few days ago Martin also added
WITH_FBSD10_FIX to the Makefiles of a number of commonly-used ports
that need the fix.

>Setting this and try building ports without the masquerading will help
>those people involved in fixing more than the masquerading solution? If

Yes.  Some of the known problems with the current fix don't occur when
ports are built in tinderboxes or clean sandboxes, but on live systems
that already have other ports installed.

> On the other hand, as far as I know, there was only suggested using
> UNAME_r. When do I have to use the OSVERSION?
>

You don't have to alter OSVERSION, but if you do not, then for those
ports that have WITH_FBSD10_FIX set in their Makefiles, the fix will
be applied, and you will be subject to any problems that the fix may
cause, even though you are trying to masquerade as a version of
FreeBSD less than 10.  Look at the conditional that determine whether
any action is taken during the run-autotools-fixup target in
ports/Mk/bsd.port.mk.

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

Re: 10.0-CUR r226986 && ports (general)

[b. f.]

> > > It turns out that the problem is more general! A lot of ./configure
> > > scripts are detecting in 10-CUR that they can't or should not build
> > > shared libs; the problem is that the OS is detected now as
> >
> > As a temporary workaround, add "WITH_FBSD10_FIX=1" to /etc/make.conf.
>
> ports/UPDATING and some of the mails in the archive of -current
> recommend setting UNAME_r=9.0-CURRENT; is this the same or which method
> is prefered?

No, it is not the same.  You can either masquerade, by setting UNAME_r
and OSVERSION, or by editing the headers and scripts that define them;
or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE
(which is implied by USE_AUTOTOOLS and GNU_CONFIGURE).  Right now the
masquerading is probably safer, because there are some problems with
the fix that are still being resolved -- and a few ports that may fail
despite the fix.  But of course if you help to test without
masquerading, these problems will be resolved sooner.

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

Re: textproc/libxml2 does not install libxml2.so.5

[b. f.]

>
> This doesn't seem to do the trick for me:
>
> # echo $SHELL
> /bin/csh
> # setenv UNAME_r 9.9-CURRENT
> # echo $UNAME_r
> 9.9-CURRENT
> # cd /usr/ports/textproc/libxml2
> # make install clean
> [...]
> # pkg_info -g libxml2-2.7.8_1
> Information for libxml2-2.7.8_1:
>
> Mismatched Checksums:
> pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
> pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
> pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist
>
> Am I doing something wrong here ?
>

Yes, you are trusting us. ;) There are a few problems related to the
FreeBSD 10 fix that are still being worked out.  Whether or not the
FreeBSD 10 fix is used depends on OSVERSION, which is calculated in
bsd.port.mk, so your masquerading is incomplete:


   1192 .if !defined(OSVERSION)
   1193 .if exists(/usr/include/sys/param.h)
   1194 OSVERSION!= ${AWK}
'/^\#define[[:blank:]]__FreeBSD_version/ {print $$3}' <
/usr/include/sys/param.h
   1195 .elif exists(${SRC_BASE}/sys/sys/param.h)
   1196 OSVERSION!= ${AWK}
'/^\#define[[:blank:]]__FreeBSD_version/ {print $$3}' <
${SRC_BASE}/sys/sys/param.h
   1197 .else
   1198 OSVERSION!= ${SYSCTL} -n kern.osreldate
   1199 .endif
   1200 .endif
...
   3664 run-autotools-fixup:
   3665 # Work around an issue where FreeBSD 10.0 is detected as
FreeBSD 1.x.
   3666 .if defined(WITH_FBSD10_FIX) && ${OSVERSION} >= 100
...

You could edit the __FreeBSD_version line in param.h, or override
OSVERSION on the command-line, setting it less than 100, if you
wanted to continue to masquerade as 9.9 or some other suitable value
while the problems are being resolved.

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

Re: textproc/libxml2 does not install libxml2.so.5

[b. f.]

>> Mismatched Checksums:
>> pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
>> pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
>> pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist
>>
>>
>> Hints and/or pointers welcome.
>It works for me correctly
>
>http://tb.smeets.im/tb/index.php?action=display_markup_log&build=10-FreeBSD&id=24#1000

Yes, but in a tinderbox -- this is the same problem I used in the
example from my message to you and the others a few hours ago.  The
FreeBSD 10 fix is triggering refresh builds of the autotools-related
parts of the port after changing the modification time of libtool.m4,
and breaking the build, when some autotools ports are already
installed on the system before rebuilding. There are a number of ways
to circumvent the problem, but a full rebuild is unlikely to help by
itself.

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

Re: math/atlas not detected in many ports

[b. f.]

> The situation with $subj: many ports' Makefiles are trying to detect if
> math/atlas is to be used by looking for ${LOCALBASE}/lib/libatlas_r.so.
> Since last update math/atlas does not build the lib*_r.so* and so none of
> those ports could see and use atlas. The Makefiles affected:
> /usr/ports/math/arpack++/Makefile
> /usr/ports/math/blocksolve95/Makefile
> /usr/ports/math/freemat/Makefile
> /usr/ports/math/lapack++/Makefile
> /usr/ports/math/lapack95/Makefile
> /usr/ports/math/libtsnnls/Makefile
> /usr/ports/math/mumps/Makefile
> /usr/ports/math/octave-devel/Makefile
> /usr/ports/math/octave/Makefile
> /usr/ports/math/petsc/Makefile
> /usr/ports/math/scalapack/Makefile
> /usr/ports/math/sdpa/Makefile
> /usr/ports/math/sdpara/Makefile
> /usr/ports/math/suitesparse/Makefile
> /usr/ports/math/superlu/Makefile
> /usr/ports/math/superlu_mt/Makefile
> /usr/ports/math/taucs/Makefile
>
> This is a simplest `grep -l` in math/*/Makefile so there could be more
> Makefiles in another categories or files/patch-*.
> Fix is obious: replace all those lib*_r.so by lib*.so (and say -latlas_r
> by -latlas and so on).

Yes, I know.  But I have not yet finished updating math/atlas-devel,
which still has the old libraries.  Also, I think that not only the
detection bits, but also some of the link lines, can or should be
changed.  For the moment, you could simply use symlinks or
libmap.conf(5) to associate the new math/atlas library names with the
old ones, where needed, or use math/atlas-devel. I will work with the
maintainers of the affected ports to change all of them over a bit
later.  Two maintainers have already decided to switch to the new
names.  (This only affects non-default options.)

b.

P.S.  Please cc me next time if you have a question about atlas, so I
will see it sooner.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg_version: corrupted record (pkgdep line without argument), ignoring

[b. f.]

Jerry wrote:
> After attempting unsuccessfully to update KDE4 via "portmaster", I
> found a number of errors printed out when using "pkg_version-vIL=".
>
> I eventually used "portmanager" to update the KDE4 port successfully;
> however, I am still receiving the following error messages.
>
> These ports need updating:
> pkg_version: corrupted record (pkgdep line without argument), ignoring
> pkg_version: corrupted record (pkgdep line without argument), ignoring
> pkg_version: corrupted record (pkgdep line without argument), ignoring
> koffice-kde4-2.3.3_3<   needs updating (index has 2.3.3_5)
> postgresql-client-8.2.21<   needs updating (index has 8.2.22_1)
>
> I have not found a way to ascertain which ports contain the corrupted
> records. Originally, there were over a dozen of them but "portmanager"
> fixed most of them for me. How can I determine what ports are still
> damaged so that I might correct them.

As the others have written, you could use sed, grep, or visual
inspection to examine the pkgdb.  Alternatively, you could try testing
one port at a time, to see what ports pkg_version chokes on, by using
something like:

 pkg_info -aE | xargs -tI @ pkg_version -vIL= -s @

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

audio/cdparanoia broken on -CURRENT, and probably on 9.0

[b. f.]

Just a note to say that recent changes on -CURRENT (r225950, meaning
that it is probably broken on 9.0 after r226067) have broken
audio/cdparanoia, and it should be fixed or marked as BROKEN there.  I
haven't filed a PR, or attempted to patch it yet -- I think that it
would be worthwhile to look into moving to 10.2, which has a large
number of improvements, although suffering from some Linuxisms.

Regards,
b.


===>   cdparanoia-3.9.8_9 depends on executable: gmake - found
===>  Configuring for cdparanoia-3.9.8_9
creating cache ./config.cache
checking host system type... Invalid configuration
`amd64-portbld-freebsd9.9': machine `amd64-portbld' not recognized

checking for ranlib... ranlib
checking for ar... ar
checking for install... /usr/bin/install -c -o root -g wheel
checking how to run the C preprocessor... cpp
checking for ANSI C header files... yes
checking size of short... 2
checking size of int... 4
checking size of long... 8
checking size of long long... 8
checking for int16_t... yes
checking for int32_t... yes
checking for u_int16_t... yes
checking for u_int32_t... yes
checking for linux/sbpcd.h... no
checking for linux/ucdrom.h... no
checking whether gmake sets ${MAKE}... yes
checking for working const... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating interface/Makefile
creating paranoia/Makefile
===>  Building for cdparanoia-3.9.8_9
cd interface && gmake all
gmake[1]: Entering directory
`/tmp/home/u1/pwrk/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface'
gmake libcdda_interface.a CFLAGS="-O -O2 -pipe -march=athlon64
-fno-strict-aliasing"
gmake[2]: Entering directory
`/tmp/home/u1/pwrk/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface'
cc -O -O2 -pipe -march=athlon64 -fno-strict-aliasing -c scan_devices.c
cc -O -O2 -pipe -march=athlon64 -fno-strict-aliasing -c common_interface.c
cc -O -O2 -pipe -march=athlon64 -fno-strict-aliasing -c cooked_interface.c
cc -O -O2 -pipe -march=athlon64 -fno-strict-aliasing -c interface.c
cc -O -O2 -pipe -march=athlon64 -fno-strict-aliasing -c scsi_interface.c
scsi_interface.c: In function 'handle_scsi_cmd':
scsi_interface.c:370: error: 'struct scsi_sense_data' has no member
named 'flags'
scsi_interface.c:381: error: 'struct scsi_sense_data' has no member
named 'add_sense_code'
scsi_interface.c:382: error: 'struct scsi_sense_data' has no member
named 'add_sense_code_qual'
scsi_interface.c: In function 'scsi_read_map':
scsi_interface.c:967: error: 'struct scsi_sense_data' has no member
named 'flags'
scsi_interface.c:968: error: 'struct scsi_sense_data' has no member
named 'add_sense_code'
scsi_interface.c:969: error: 'struct scsi_sense_data' has no member
named 'add_sense_code_qual'
gmake[2]: *** [scsi_interface.o] Error 1
gmake[2]: Leaving directory
`/tmp/home/u1/pwrk/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory
`/tmp/home/u1/pwrk/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface'
gmake: *** [all] Error 2
*** Error code 1

Stop in /home/u1/pwrk/ports/audio/cdparanoia.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: "math/fftw3" port broken

[b. f.]

On 9/26/11, Stephen Montgomery-Smith  wrote:
> On 09/25/2011 08:19 PM, Jerry wrote:
>> When attempting to build the "math/fftw3" port, the following error
>> message is immediately displayed and the build halted:
>>
>>  Variable CFLAGS is recursive.
...
> I am unable to reproduce this problem.  Is it possible that something is
> wrong in your /etc/make.conf file?

It only happens when the non-default option WITH_OPTIMIZED_CFLAGS is
enabled.  I am fixing it now.

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

Re: Substitute dependencies?

[b. f.]

>I s there any way to substitute dependencies, in cases where the substitute 
>would work as well or better?

As some of the others wrote, it depends on the ports involved.  Some
ports that are supposed to provide the same functionality have subtle
differences that can cause problems.

>
> First case I think of is the misc/freebsd-doc-* ports which want links1, 
> which would be redundant if I already have lynx installed, or lynx and 
> seamonkey too.
>
> I don't really like links1, prefer links with graphic capability though links 
> with graphics is still a lame horse compared to Firefox or Seamonkey.

It's not a fair comparison -- they were designed to meet different
needs.  www/links is supposed to be a lightweight browser with basic
functionality than can be used even without X, while the others are
full-featured browsers.

In this case, you can probably get away with substituting www/links
for www/links1, because they have similar output, they can both be
invoked with "-dump", and it is unlikely that the dependent port
checks version information for them.  To try and see if this works,
remove www/links1 and install www/links.  When the docproj ports test
for the existence of "links", they will find www/links and assume that
www/links1 is already installed. The dependency accounting in your
package database may be wrong, but that's usually not important, and
third-party updating tools like portmaster or portupgrade can adjust
this, or compensate for it.  (Why are you building the doc ports if
you are only interested in reading them, anyway?  Why not just use the
default packages for these, and avoid installing a lot of software?)

To substitute binary executables or static archives with different
names, you can use symlinks. Symlinks or libmap.conf(5) can be used to
substitute shared libraries.

The entity that must be substituted is the first part of the *_DEPENDS triplet.

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

Re: Circular dependency in devel/doxygen?

[b. f.]

...
> > There are several ways to break the circular dependancy:
>
> > 1. Turn the DOC option OFF for audio/jack.
> > 2. define NOPORTDOCS when installing devel/doxygen (breaks dependancy
> > on graphics/graphviz)

Turning the DOC option off, and setting NOPORTDOCS are the same for audio/jack.

...
> How do you define NOPORTDOCS, do you insert "-D NOPORTDOCS" in 'make' 
> command, like

Yes, or in the build environment, or in an included Makefile.

...
> What does NOPORTDOCS do in devel/doxygen?  Do I lose a lot of important 
> documentation?

You retain a few manpages, but lose a lot of detailed API documents
that many users don't need.  In any event, you can download them from
the jack website:

http://jackaudio.org/documentation

>What is "doxywizard"?

Read the doxygen documents:

http://www.stack.nl/~dimitri/doxygen/doxywizard_usage.html

> Having DOCS option on in audio/jack adds an intimidating load of 
> dependencies, as I found through
> make missing | more

That is why they were just removed from the default package.

...
> maybe more than the ports framework can handle?

No, but maybe more than the average person who builds audio/jack wants
to handle.

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

Re: Ports with CPPFLAGS in CONFIGURE_(ARGS|ENV)

[b. f.]

> > > Do you mean one gigantic, monolithic patch that would amend all of
> > > them, or a large set of individual patches (last I checked, there
> > > were ~1453 ports in need of this sort of revision)?  I could go
> > > either way, just need to know which would be preferred.
> >
> > One monolithic patch (preferably generated with "cvs diff -Nu")
>
> OK.  Just a few more questions:
>
> portlint -A issues no warning in the case of CPPFLAGS being added to
> CONFIGURE_ARGS.  Should I concern myself only with CONFIGURE_ENV, or
> would it be best to modify in either case?

Either case.  There are slight differences in the handling of
variables passed in the environment (as is done by default for
CPPFLAGS), and variables passed on the command-line (as is done for
variables assigned in CONFIGURE_ARGS), but they are usually
unimportant.  Most occurrences of CPPFLAGS in CONFIGURE_ARGS are
either mistakes or anachronisms.

>
> Also, is there any possibility of either CONFIGURE_ENV or
> CONFIGURE_ARGS being used in some non-standard fashion, i.e., with
> anything other than a GNU configure script, meaning they should just be
> left alone?

Of course that is possible, although such a usage would probably be rare, if
it occurs at all. You should only be concerned about the case when:

--HAS_CONFIGURE is defined (note that HAS_CONFIGURE can be implied by
other things, like GNU_CONFIGURE, XORG_CAT, USE_AUTOTOOLS, USE_PHPIZE,
and USE_PHPEXT); and
--the default "do-configure" target has not been overridden;

because that is when CPPFLAGS is passed in the environment to the configure
script.  See bsd.port.mk.

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

Re: Detecting dependencies

[b. f.]

> On 09/15/11 07:06, chukharev at mail.ru wrote:
> > Hi,
> >
> > There have been a discussion about finding interdependencies of ports.
> > I have a relatively simple Python script for that. There is a pr
> > ports/160007
> > to add its early version. Unfortunately, I missed a reply to it, so
> > there is
> > an issue which I have not yet addressed...
> >
> > Since that time, I added reverse dependencies with full ports tree scanning
> > (1 h on my 2.5GHz notebook) and saving the tree (directed graph, actually)
> > to a file, so that rescanning all ports tree is not needed.
> >
> > See http://code.google.com/p/porttree/
> >
> > If there will be interest, scanning packages interdependencies could
> > also be added.
> >
>
> On a related subtopic, we also need a tool that identifies implicit
> dependencies not captured in the ports Makefiles. I hacked the following
> together earlier this year to smooth over the updating process when key
> libraries get bumped (e.g. the gettext update at the time I wrote the
> script was a nightmare). There were a tonne of ports which needed to be
> updated even though they didn't explicitly record a dependency on gettext.
>
> https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh
>
> It's still quite rough and manually driven and is tied to portmaster at
> the moment, but I use it routinely after a "portmaster -ad" to check
> that no libs are missing dependencies. It works pretty well most of the
> time, but definitely needs more finessing. I share it mostly to prove
> the feasibility of the approach and in case anyone is curious.

What, no check to see if the libraries listed in the DT_NEEDED tags
are actually needed? And no kitchen sink?  ;)

There are scripts in ports/Tools/scripts that were intended to perform
similar tasks, although they may be rougher than your script.

>
> I haven't thought the following ideas through a great deal and welcome
> feedback, but I think the basic functionality/premise of this script
> could be integrated into the ports framework so that at package
> registration time, implicit deps are identified and marked in the
> package database. A warning could also be generated that the port is
> using deps not identified in the Makefile, and perhaps trigger a send-pr
> to the port maintainer to let them know.

...

> A script like this could also be integrated/called somehow from a tool
> like portmaster during an update to ensure ports with implicit
> dependencies on another port which has been updated are identified and
> recompiled too so that we avoid the nasty problems that crop up with
> missing library dependencies.

Just as in the other *_DEPENDS lists, it was a conscious policy
decision, for the sake of brevity and efficiency, that if port B
requires port C, and port A requires port B,
then libraries from port C will not be listed in the LIB_DEPENDS of
port A, even if port A links directly to those libraries.  But because
of recurring problems with partial port updates, this policy has been
criticized.  I think that the last time the matter was raised, the
consensus seemed to lean toward listing all needed libraries, but the
amount of work involved in, and the likely disruption arising from,
refactoring all LIB_DEPENDS in the tree dissuaded anyone doing so.

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

Re: Building caire and $PATH order

[b. f.]

> A couple of weeks ago, after installing openssl from ports, I changed
> PATH order in my .bash_login, in order to use /usr/local before /usr an
> so on.
>
> Today, I upgraded icu, and its dependants, including cairo. The build
> was successful until reaching cairo :
>
> ---
> checking how to allow undefined symbols in shared libraries used by test
> suite... checking whether cc supports -Wl,--allow-shlib-undefined... yes
> -Wl,--allow-shlib-undefined
> checking whether byte ordering is bigendian... no
> checking whether float word ordering is bigendian... fopen: No such file
> or directory
> fopen: No such file or directory
> unknown
> configure: error:
>
> Unknown float word ordering. You need to manually preset
> ax_cv_c_float_words_bigendian=no (or yes) according to your system.
> ---
>
> Setting PATH with /usr/local *after*, on the command line fixed the
> problem.
>
> Is this a known behavior ? A mess with two include files with the same
> name in /usr/include and /usr/local/include ?

It is difficult to figure out what went wrong, because you have not
isolated the point of failure, or provided a full listing of your
environment, the config.log, and a build transcript.  The error
message is of the kind that would be issued if the conftest.o file for
the configure script test were deleted before the test was concluded,
which could happen if there were hardware problems, or if the parts of
the work directory were removed during the build, so I wonder if this
problem is consistently reproducible.

Header interposition can occur, but usually happens when you change
compilers or tinker with the compiler flags, and not the system path.
If your failure wasn't transient, or due to hardware problems, it is
more likely that you are using different binary executables with the
changed system path, because some of them are called in system
Makefiles or configure scripts by their basenames.  For instance, in
the test that failed:

17786:  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether
float word ordering is bigendian" >&5
17787:$as_echo_n "checking whether float word ordering is bigendian... " >&6; }
17788-if test "${ax_cv_c_float_words_bigendian+set}" = set; then :
17789-  $as_echo_n "(cached) " >&6
17790-else
17791-
17792-
17793-# The endianess is detected by first compiling C code that
contains a special
17794-# double float value, then grepping the resulting object file for certain
17795-# strings of ascii values. The double is specially crafted to have a
17796-# binary representation that corresponds with a simple string. In this
17797-# implementation, the string "noonsees" was selected because the
individual
17798-# word values ("noon" and "sees") are palindromes, thus making this test
17799-# byte-order agnostic. If grep finds the string "noonsees" in the object
17800-# file, the target platform stores float words in big-endian
order. If grep
17801-# finds "seesnoon", float words are in little-endian order. If
neither value
17802-# is found, the user is instructed to specify the ordering.
17803-
17804-ax_cv_c_float_words_bigendian=unknown
17805-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
17806-/* end confdefs.h.  */
17807-
17808-
17809-double d =
9090423496703681033747047890550501147621169273561563201479712084405348886581669527372346909785805625751702019124748742951693213050356065000232756451757077848023672452514052012137173920149654013264010999420565776568942592.0;
17810-
17811-
17812-_ACEOF
17813-if ac_fn_c_try_compile "$LINENO"; then :
17814-
17815-
17816-if strings - conftest.$ac_objext | grep noonsees >/dev/null ; then
17817-  ax_cv_c_float_words_bigendian=yes
17818-fi
17819-if strings - conftest.$ac_objext | grep seesnoon >/dev/null ; then
17820-  if test "$ax_cv_c_float_words_bigendian" = unknown; then
17821-ax_cv_c_float_words_bigendian=no
17822-  else
17823-ax_cv_c_float_words_bigendian=unknown
17824-  fi
17825-fi

, without even examining the configure script functions that are
called, one can see that 'strings'  and 'grep' are called by their
basenames, and that changing the path could affect the binary
executables used by the test, and thus the test outcome.  This isn't
desirable, but is common in a lot of configure scripts and Makefiles,
so it is not a good idea to change the path arbitrarily.

It would be safer to just call the security/openssl utilities by their
full pathnames, or at least to only override the basenames of the
security/openssl utilities, and not others, by doing something like:

mkdir /usr/local/opensslbin
ln -s /usr/local/bin/openssl /usr/local/opensslbin/openssl
ln -s /usr/local/bin/c_rehash /usr/local/opensslbin/c_rehash

and adding /usr/local/opensslbin to your path before /usr/bin.

But if you want to learn why the path change caused this failure, or
even if it did, then you will have to dig a bit deeper.

b.
___

Re: USE_GCC and unnesessary RUN_DENEDS on gcc port (Was: Print +REQUIRED_BY as tree?)

[b. f.]

> >  For example, x264 DEPENDS on gcc, (has USE_GCC=4.4+ in Makefile),
> >  but no x264 files are linked with libgcc_s.so or other libraries from
> >  gcc44. It seems, that we need separate USE_GCC_BUILD and USE_GCC_RUN,
> >  as with PERL or PYTHON.
>   Or, maybe automate this, as now port system warns user about
> "possible network servers" -- check all installed binaries and
> libraries for linkage with non-system-gcc libraries and add "run"
> dependency. But I'm not sure it is easy to do, as it should be done
> after installation, when, I afraid, adding RUN_DEPEND at this stage
> doesn't help, so this automatic should make all depends-related work
> (+REQUIRED_BY / +CONTENT) "by hands".

The type of dependency should be established by the maintainer of the
port that relies upon gcc, or by the user who sets USE_GCC in a custom
build.  It does not seem convenient or efficient to conduct a test of
the sort you describe, and there are cases -- such as  a script
calling a gcc binary, or a binary using dlopen to load a gcc library
-- that would complicate matters. There is already a proposal to add
some more flexibility to the USE_GCC construct:

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/155408

, an effort to create lighter runtime-only gcc ports, and some other
simplifications:

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/160507

that will make changes like you describe less of a problem.

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

Re: devel/git new update des not fetch

[b. f.]

>
> Since my new update of ports tree :
>
> ===>  Vulnerability check disabled, database not found
> ===>  License check disabled, port has not defined LICENSE
> ===>  Found saved configuration for git-1.7.4.3
> => git-1.7.6.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles//.
> => Attempting to fetch
> http://kernel.org/pub/software/scm/git/git-1.7.6.1.tar.bz2
> fetch: http://kernel.org/pub/software/scm/git/git-1.7.6.1.tar.bz2:
> Service Unavailable

It looks like you do not have the latest revision of devel/git:

$FreeBSD: ports/devel/git/Makefile,v 1.112 2011/09/10 01:56:16 wxs Exp $

which adds some alternative mirrors while kernel.org conduct an audit
following the recent security breach there.

Cf.

http://lists.freebsd.org/pipermail/freebsd-ports/2011-September/070052.html
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.

[b. f.]

> >  ... gzip, for example, has "timestamp" field in header.
> >  Try this locally, without any [D]VCS:
> >
> > % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt
> > % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test
> > % md5 test1.tar.gz test2.tar.gz
> > MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec
> > MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9
> > % gzip -d test1.tar.gz test2.tar.gz
> > % md5 test1.tar test2.tar
> > MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85
> > MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85
>
> That is arguably a bug in "tar czf" :)  but it is easy enough to
> work around; we just need a checksum method -- e.g. SHA256_UNGZ --
> that pipes the distfile through gunzip when computing its checksum.
>

The problem goes beyond that: different standard tar formats can
include mutable data like major and minor device numbers, and the
atimes, uids, and gids of files.  See, for example, tar(5). We would
have to continually monitor whether each site generates tarballs with
invariant checksums from the "same" files, or check the integrity of
archive members after extraction.

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

git distfiles on the local mirror

[b. f.]

Could someone please place the latest devel/git distfiles on the local
mirrors, so that they are available while kernel.org is recovering
from being hacked?  The github mirror only has gzipped development
tarballs, that don't work with the current ports Makefile.

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

Re: PREFIX is not honored for dependencies

[b. f.]

>Yes you are right gperf and vigra-config dependencies are wrong in that
>case.
>
>I didn't see it because it is fixed in the short coming 3.4.2.
>
>I'm focus on it sorry

It is just a minor detail that I mentioned in passing, perhaps
something the maintainers could adjust together with their next
update, if they want to: I don't think that you need to worry about
it.  It may help to use just the basename if someone wants to provide
an alternative dependency, but that is not very common with these two
ports, and someone can do this by other means if they so desire.  In
any event, changes like this won't solve all of our problems with
correctly registering alternative dependencies, and it won't allow the
OP to use multiple PREFIXes/LOCALBASEs without trouble if he has
conflicting registered shared libraries in both.

I think the others are right in saying that LOCALBASE should be
mentioned in the manpage, together with the pitfalls of PREFIX !=
LOCALBASE, and of trying to use more than one PREFIX or LOCALBASE
simultaneously.

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

Re: PREFIX is not honored for dependencies

[b. f.]

> There is nothing to fix, this is the way ports are expected to work.
>
> Are you sure? IMHO if PREFIX is defined before installing any port
> and never gets changed than all ports should respect PREFIX.
>
> > Playing with PREFIX != LOCALBASE has to be done with care because it
> > can lead to some breakage as this one.
>
> Steve, did you define a new PREFIX before installing *any* port at the
> system in question? There should be the fore-mentioned problem if one
> *change* PREFIX after installing some ports.

They may be respecting PREFIX, but may also be honoring LOCALBASE?=
/usr/local, != PREFIX, during dependency checks:

 98 BUILD_DEPENDS=  zip:${PORTSDIR}/archivers/zip \
...
105
${LOCALBASE}/lib/libcppunit.so:${PORTSDIR}/devel/cppunit \

, so problems may arise.  If you're going to define a non-default
PREFIX, you must set LOCALBASE to match.  And even if you do, if you
have an alternative, non-empty LOCALBASE that is in your path, or that
contains shared libraries visible to the loader, then you may still
encounter problems.  I think that PC-BSD uses something corresponding
to multiple PREFIXes in their approach to fat packages, and they had
to make a number of changes to the base system as well as to ports in
order to do so.

By the way, I guess some of the shared libraries in this port's
BUILD_DEPENDS have to use a fully-qualified path (and were placed
there instead of in LIB_DEPENDS to avoid registering a run-time
dependency?), but I don't know why that was thought to be necessary
for the binary executables gperf and vigra-config.

b.


>
> BTW, QAT was used to do experimental runs with non-default PREFIX.
> Those reports were very useful.
>
> --
> WBR, bsam
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ghostscript8 vs. ghostscrip9 conflict during portupgrade

[b. f.]

> Seems like some ports depend on ghostscript8 whereas other depend on
> ghostscript9. Unfortunately both ghostscript variants can't coexist on
> the same system. To be specific:
>
> I've got ghostscript8 installed (ghostscript8-8.71_8) which is
> required by a bunch of ports as per "pkg_info -Rx ghostscript8". When
> running "pkgdb -F" it wants to install ghostscript9 since ImageMagick
> depens on ghostscript9:

The only ports that really need ghostscript8 will have a
GHOSTSCRIPT_PORT entry pointing to print/ghostscript8 (I don't think
there are any such ports at this time) -- otherwise they just happen
to depend upon it because they were built with a non-default,
user-defined WITH_GHOSTSCRIPT_VER value, or were built before the
default ghostscript port was changed to print/ghostscript9.

Problems like this are what the "-o" switches are for, in portmaster
and portupgrade --read the manpage of the utility that you prefer,
including the examples sections.  Also, you should get in the habit of
reading the recent additions to ports/UPDATING.

If you are using portupgrade, you should probably do something like:

portupgrade -o print/ghostscript9 print/ghostscript8
portupgrade -rfx ghostscript9 ghostscript

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

Re: portupgrades fail because of missing /usr/local/lib/liblzma.la

[b. f.]

> On my 8.2-System (amd64, kernel & system updated two days ago) I run
> into a nasty problem updating my ports:
>
> Ports that depend on "liblzma" fail to build with the following error:
>
> "/usr/local/lib/liblzma.la: No such file or directory"
>
> AFAIK, the xz-libraries are not part of the base system; there is
> indeed a /usr/lib/liblzma*, but why doesn't the build process for the
> ports recognize it and insists on having the libraries in
> /usr/local/lib?
>
> When installing the xz-libraries from the ports, i.e.
>
> pkg_add -r -f xz
> and
> portupgrade -o archivers/xz lzmautils\*
>
> upgrading my ports works, but this truly can't be the correct
> solution, esp. since building xz out of the ports tree ins't
> supported:
>
> # pwd
> /usr/ports/archivers/xz
> # make
> ===>  xz-5.0.3 is already in the base system.
> *** Error code 1
>
> Stop in /usr/ports/archivers/xz.
> #
>
> So here are my questions?
>
> o) Why doesn't the build process of ports recognize the xz-libraries
> in /usr/lib? (BTW, not even "make deinstall && make clean && make
> install" helps)

It is difficult to diagnose the problem when we do not know _which_
ports are failing, and we have no transcripts and config.logs from the
failed builds.

Your ports should recognize and use the lzma libraries from the base
system, but It seems that one of your builds is polluted.  When you
build ports on a system that already has many packages installed, you
are not replicating the conditions under which packages are built on
the FreeBSD package-building and test cluster, because those machines
start builds in a clean sandbox, with only the registered build
dependencies present.  So occasionally a problem like yours occurs,
where a build fails locally when it succeeds on the test machines.
Usually, but not always, such failures can be prevented by following a
procedure like that described in the portmaster(1) page, under the
heading: "Using portmaster to do a complete reinstallation of all your
ports", that involves deinstalling _all_ ports _before_ rebuilding
them.  However, many people aren't this thorough in their updating,
and even when they are, there are a few problems that can still occur.

> o) What can I do to get ports recognize the correct location of the
> xz-libraries?

As I wrote above, some more information would help.  I'm guessing that
you have a port that (unfortunately) uses libtool to perform linking,
and has an erroneous /usr/local/lib/lzma.la entry in a libtool archive
file (*.la), or is using some combination of uncommon  linker flags
and sloppy use of -L/usr/local/lib.  Does a search like:

fgrep -e lzma -nHr /usr/local/lib --include='*.la'

yield any results?  If you see any references in a libtool archive to
the nonexistent "/usr/local/lib/liblzma.la", try removing and then
rebuilding the port that owns that libtool archive -- you should be
able to determine the port by running "pkg_info -W" with the full path
of the libtool archive as an argument.

Also, do you have any garbage in /usr/local?:

--Does "pkg_info -ga" reveal any corrupted or missing files?
--Is there any output that you cannot account for from a shell script
like the following?:

#!/bin/sh
l=${LOCALBASE-/usr/local}
t=${TMPDIR-/tmp}
lf=`mktemp ${t}/lf.XX` || exit 1
lpf=`mktemp ${t}/lpf.XX` || exit 1
find ${l} -type f | sort > ${lf}
pkg_info -qaL | sort -u > ${lpf}
echo "the following files in ${l} not claimed by any installed package:"
comm -23 ${lf} ${lpf}
rm ${lf} ${lpf}

--Do you have any libraries in compat directories that you really don't need?
--Do you have any installed root or leaf ports that you don't need?

If so, consider removing all of the above.

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

Re: devel/icu... help... ?

[b. f.]

> Thanks for the quick reply and I certainly appreciate your viewpoint.
>
> Are these undefined references defined by FREEBSD? If so, why would you
> introduce an OS dependency in a library intended to provide unicode support?
>

It is difficult to say, from the limited information, whether the
failure is due to the use of an older toolchain ( gcc 3.4.x , etc.),
or some difference in other parts of the base system.  It is
inevitable that icu will depend upon some features of the base system,
on almost any platform.


> c++ -O2 -fno-strict-aliasing -pipe -W -Wall -ansi -pedantic -Wpointer-arith
> -Wwrite-strings -Wno-long-long   -o intltest aliastst.o allcoll.o apic\
> oll.o astrotst.o callimts.o calregts.o caltest.o caltztst.o canittst.o
> citrtest.o cntabcol.o convtest.o currcoll.o fldset.o dadrfmt.o dadrcal.o
> da\drcoll.o dcfmapts.o decoll.o dtfmapts.o dtfmrgts.o dtfmtrtts.o dtfmttst.o
> dtptngts.o encoll.o escoll.o ficoll.o frcoll.o g7coll.o intltest.o iterc\
> oll.o itformat.o itmajor.o itutil.o jacoll.o lcukocol.o loctest.o miscdtfm.o
> mnkytst.o msfmrgts.o nmfmapts.o nmfmtrt.o numfmtst.o numrgts.o plurul\
> ts.o plurfmts.o pptest.o regcoll.o restest.o restsnew.o sdtfmtts.o svccoll.o
> tchcfmt.o selfmts.o tfsmalls.o tmsgfmt.o trcoll.o tscoll.o tsdate.o t\
> sdcfmsy.o tsdtfmsy.o tsmthred.o tsnmfmt.o tsputil.o tstnrapi.o tstnorm.o
> tzbdtest.o tzregts.o tztest.o ucdtest.o usettest.o ustrtest.o strcase.o t\
> ranstst.o strtest.o thcoll.o bytestrietest.o ucharstrietest.o itrbbi.o
> rbbiapts.o dicttest.o rbbitst.o ittrans.o transapi.o cpdtrtst.o testutil.o \
> transrt.o trnserr.o normconf.o sfwdchit.o jamotest.o srchtest.o reptest.o
> regextst.o itrbnf.o itrbnfrt.o itrbnfp.o ucaconf.o icusvtst.o uobjtest.o\
>  idnaref.o idnaconf.o nptrans.o punyref.o testidn.o testidna.o uts46test.o
> incaltst.o calcasts.o v32test.o uvectest.o textfile.o tokiter.o utxttes\
> t.o windttst.o winnmtst.o winutil.o csdetest.o tzrulets.o tzoffloc.o
> tzfmttst.o ssearch.o dtifmtts.o tufmtts.o itspoof.o simplethread.o
> bidiconf.o\
>  locnmtst.o dcfmtest.o alphaindextst.o -L../../tools/ctestfw -licutest
> -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata -licudata -L../.\
> ./lib -licutu -lm   -lpthread
> numfmtst.o(.data+0x30c): undefined reference to `.LC3163'
> numfmtst.o(.data+0x314): undefined reference to `.LC3164'
> numfmtst.o(.data+0x324): undefined reference to `.LC3165'
> numfmtst.o(.data+0x39c): undefined reference to `.LC3171'
> gmake[1]: *** [intltest] Error 1
> gmake[1]: Leaving directory
> `/usr/ports/devel/icu/work/icu/source/test/intltest'
> gmake: *** [all-recursive] Error 2
> gmake: Leaving directory `/usr/ports/devel/icu/work/icu/source/test'
> *** Error code 2 (ignored)
> cd /usr/ports/devel/icu/work/icu/source/test/iotest && /usr/bin/env
> LD_LIBRARY_PATH=/usr/ports/devel/icu/work/icu/source/lib:/usr/ports/devel/icu\
> /work/icu/source/tools/ctestfw  ./iotest
> env: ./iotest: No such file or directory
> *** Error code 127
>
> Stop in /usr/ports/devel/icu.
> *** Error code 1
>
> Stop in /usr/ports/devel/icu.
>
> If I ignore the bad refs, then the error looks like a shell syntax problem.

You can't ignore the bad refs.  The port can't run iotest, because
iotest was not built: the port terminated the building of the tests
after it failed to build intltest, but continued, and attempted to run
the tests, because the commands that build the tests are preceded by a
"-" in the port Makefile.

>
> Of course, I only ask because I do not have the time to wade through all
> your stuff to figure out what is going on. But ICU is required for the
> latest glib20 build which QT uses.
>
> This stuff has worked fine on my FREEBSD6.2 system until this week. And if I
> read these msgs correctly, this problem also occurs on FREEBSD8.
>

This doesn't help unless you provide specific information about the
last working versions of the central ports Makefiles, icu, and all
ports that icu depends upon.  I don't know what message(s) you're
referring to about failures on 8.x.

You could try building the port with a newer toolchain by setting
USE_GCC to an appropriate value in your build environment or an
included Makefile.  Or you could disable the tests (e.g., by removing
"post-build" from the following port Makefile line:

 84 post-build test regression-test: iotest cintltst intltest

), or at least ignore the test outcomes (e.g., by adding a leading "-"
to the group of commands that run the tests).  If those two
alternatives fail, or aren't acceptable, then you will have to debug
the build.

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

Re: Problem building math/R: texi2dvi needed but missing on your system

[b. f.]

> I'm trying to build math/R. Compilation went fine, but when I try to
> 'make install' I get the following error:
>
> > ERROR: 'texi2dvi' needed but missing on your system.
> > *** Error code 1
> >
> > Stop in /usr/ports/math/R/work/R-2.13.1/doc/manual.
> > *** Error code 1 (ignored)
> > cd: can't cd to /usr/local/lib/R/lib
> > *** Error code 2
> >
> > Stop in /usr/ports/math/R.
>
> I have a texi2dvi4a2ps binary as you can see here.
>
> > # where texi2dvi4a2ps
> > /usr/local/bin/texi2dvi4a2ps
> > # pkg_info -W /usr/local/bin/texi2dvi4a2ps
> > /usr/local/bin/texi2dvi4a2ps was installed by package a2ps-a4-4.13b_4
>
> Has anyone else seen this problem before and can give me some tipps?

As I told Anton a bit earlier, upstream changed the method of building
the dvi manuals (yet again), and I missed this during the update.
This should only affect users who build math/R with the (non-default)
option WITH_DVI_MANUALS.  I hope to fix this soon.  In the meantime,
you can disable this option, build and install R, and either read the
manuals in info format, or build them manually, or grab them from:

http://cran.r-project.org/manuals.html

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

Re: porter handbook MASTER_SITES section outdated?

[b. f.]

> In sec 5.4.2 MASTER_SITES in the porter handbook:
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#AEN1512
>
> the example given is:
>
> MASTER_SITES= ${MASTER_SITE_GNU}
>
> However, sunpoet@ has just committed my patch
> changing my ${IGNORE_MASTER_SITE_XCONTRIB} and
> ${MASTER_SITE_LOCAL} to:
>
> MASTER_SITES=   XCONTRIB/applications \
> http://seis.bris.ac.uk/~mexas/ \
> LOCAL/simon
>
> Are both forms acceptable? Or is the form
> given in the porters handbook outdated?

Yes. No.  He is just making use of an abbreviation that is translated
into the full urls by the macros at the end of ports/Mk/bsd.sites.mk.
You can do the same in your own submissions, but you should check that
they actually work by using "make fetch-urlall-list" or the like.

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

Re: Any software tools known for XBRL & PDF V1.6 & 1.7 ?

[b. f.]

On 7/2/11, b. f.  wrote:
ved PDF 1.6 & 1.7 files from companieshouse.gov.uk (that I
>> suppose relate to, or contain XBRL), that contain financial data
>> I'm supposed to edit & return.
...
>> The only tool I know to do that is, a free download of latest binary
>> Acrobat for Linux or MS-Windows, (so emulator needed too).
>>
>> I've found no source in FreeBSD ports that can handle 1.6 & 7 PDFs,
>> Anyone know of source, whether ported to FreeBSD yet or not ?
>
> Which version of ghostscript did you use with some of the tools that
> you mentioned? print/ghostscript9 claims to support PDF <= 1.7,
> although it almost probably doesn't support every option/extension.
> Could you use it to transform the pdf to a format that could be edited
> or at least annotated (postscript, perhaps?) by one of the other
> tools, at least as an intermediate step? Or, have you tried a recent
> version of devel/itext?:

So, just as an experiment, I downloaded a random selection of PDF forms from:

http://search2.hmrc.gov.uk/kb5/hmrc/forms/corporationtaxforms.page
http://www.companieshouse.gov.uk/forms/formsOnline.shtml

including some issued for 2011 (AA01, AD04, AR01, CH01, IN01, CT600,
CT600b, CT600 Budget Insert of 2011, etc.).   The sites advertise that
Adobe Acrobat Reader 4.0 and up can be used, and all of the forms were
PDF 1.3-1.6.  I didn't have any trouble filling in the forms manually
with print/flpsed (an fltk2 GUI for print/ghostscript9), using the
flpsed's import/export pdf functions.  I was also able to annotate PDF
1.7 forms from other sources using the same method.  All of these were
simple text forms.
.
b.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Any software tools known for XBRL & PDF V1.6 & 1.7 ?

[b. f.]

> Anyone know of public domain source that does XBRL format (&/or iXBRL) ?
> & PDF V1.6 & 1.7 ?

XBRL:

http://arelle.org (python-based)
http://www.xbrlapi.org/ (java-based)
http://code.google.com/p/xbrlware/ (community edition; ruby-based)
http://sourceforge.net/projects/inlinexbrl/

> I received PDF 1.6 & 1.7 files from companieshouse.gov.uk (that I
> suppose relate to, or contain XBRL), that contain financial data
> I'm supposed to edit & return.
>

What do your compatriots have to say about open-source options?

> The only tool I know to do that is, a free download of latest binary
> Acrobat for Linux or MS-Windows, (so emulator needed too).
>
> I've found no source in FreeBSD ports that can handle 1.6 & 7 PDFs,
> Anyone know of source, whether ported to FreeBSD yet or not ?

Which version of ghostscript did you use with some of the tools that
you mentioned? print/ghostscript9 claims to support PDF <= 1.7,
although it almost probably doesn't support every option/extension.
Could you use it to transform the pdf to a format that could be edited
or at least annotated (postscript, perhaps?) by one of the other
tools, at least as an intermediate step? Or, have you tried a recent
version of devel/itext?:

http://sourceforge.net/projects/itext/files/

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

Re: [Adopting a port..or contributing... and a patch included for java on most recent of all jdk/jre)

[b. f.]

> Am 30.06.2011 04:23, schrieb xD 0x41:

> *For your next submission*, please keep the information below in mind so
> we can actually use your contribution:
>
> In a common work flow, you'd usually first update the ports tree (for
> instance, running "portsnap fetch update", or for the first time,
> "portsnap fetch extract"),

Some alternative updating methods (anonymous cvs, cvsup/csup, rsync,
ctm, ftp) are in:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors.html

>do "make checksums" on the old port before

a typo, the target is "checksum", no trailing s

(for reference, the targets are documented in the Makefiles in
ports/Mk, and in the PORTS(7) manpage)

> touching the Makefile so that the other and/or old files are there and
> properly downloaded (except if all distfiles change, even if "all" means
> just one)
>
> To generate the sha256 for the files, all it takes is to download the
> new files, verify it's properly downloaded and untampered (best with
> GnuPG signatures if available), put it in /usr/ports/distfiles (or a
> subdirectory, if specified in the Makefile), and then "make makesums"

a typo, the target is "makesum", no trailing s

> will do the job. That also works outside the ports directory tree, if
> you copy the original port and work on the copy.
>
> Finally, to ease tracking of your contribution, and make sure it isn't
> lost, it's useful if you
>
> A. either use the port-tools to submit the patches with the "port
> submit" command as a "PR",

Note that "port" is a utility from the ports-mgmt/porttools port,
which must be installed -- it is not in the base system or in
ports/Tools.  If you are going to use this, consider running "port
test" on your patched port before proposing changes.

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

Re: [ANNOUNCE]: clang compiling ports

[b. f.]

Mark Linimon wrote:
> On Mon, Jun 20, 2011 at 06:21:26PM -0500, Mark Linimon wrote:
> > A permanent URL to this run is:
> >
> > 
> > http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/
> >
> > That will stick around even if we use amd64-9-exp for something else.
>
> I have updated the errorlog-classifier script and re-run the analysis.
> Most of the false positives for "process failed" being actually "inability
> to find C compiler" are now flagged as "assumes_gcc".  The "linker_error"
> case has been expanded (again, while these can happen in regular runs,
> they are much more prevalent in the clang runs.)  A few other cases have
> been tightened up as well.

Is there a new link for the new results? Or did you use the link above?

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

Re: GHC Port on 9-CURRENT

[b. f.]

>In any case, the port builds fine with GCC.  Perhaps it would be prudent
>to set CC=gcc and CXX=g++ in the makefile for the time being and mark
>the port as working again?

Please don't hardcode the compilers: users may be using other
compilers, or may still wish to experiment with clang, without having
to patch the port or override the Makefile.  Instead, if you feel it
is necessary, print a warning, or set IGNORE=... if clang or another
known bad compiler is chosen.

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

Re: libtool issues

[b. f.]

> On 06/20/2011 04:16 AM, Kostik Belousov wrote:
> > On Mon, Jun 20, 2011 at 01:03:01AM -0500, Stephen Montgomery-Smith wrote:
> >> I am maintainer of the science/vis5d+ port.  It doesn't build on the
> >> i386 with FreeBSD-8.0-RELEASE, as is shown here:
> >>
> >> http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log
> >>
> >> I know that other ports have this problem such as science/libctl.  This
> >> port is currently marked broken for exactly this reason.
> >>
> >> I have a work around at this PR: ports/155105.  This work around was
> >> improved in ports/155655 (see the follow up comment by the maintainer,
> >> who submits a patch to libctl).
> >>
> >> I also reported the problem at ports/155546, although I don't think my
> >> solution there is very good, and my description of the bug wa very
> >> incomplete.  Furthermore, it turns out that this problem does not take
> >> place under the FreeBSD-8.2-STABLE.  This can make the problem a little
> >> bit hard to diagnose.  Nevertheless I can see this problem recurring
> >> systematically again in the future, because libtool was not designed for
> >> multiple compiler environments.
> >>
> >> It would be great to find a work around.  One way would be to put in
> >> some kind of construction like ports/155105 or ports/155655 into
> >> Mk/bsd.autotools.mk.  So whenever the port has USE_LIBTOOLS set, we have
> >> the following code
> >>
> >> LIBTOOLS_DIR=${WRKDIR}/.libtools.dir.${PORTNAME}.${PREFIX:S/\//_/g}
> >> ${LN} -s ${LOCALBASE}/bin/${CC} ${LIBTOOLS_DIR}/cc
> >> ${LN} -s ${LOCALBASE}/bin/${CXX} ${LIBTOOLS_DIR}/c++
> >> MAKE_ENV+= PATH=${LIBTOOLS_DIR}:$$PATH
> >>
> >> Or one could instead modify devel/libtools, maybe something like this.
> >> Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool
> >> script as something like:
> >>
> >> #!/bin/sh
> >> PREFIX=/usr/local
> >> TEMPCCDIR=`mktemp -d -t /tmp`
> >> export PATH=${WRKDIR}:$PATH
> >> ${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc
> >> ${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++
> >> ${PREFIX}/libexec/libtool.sh $@
> >> rm -r ${TEMPCCDIR}
> >>
> >> I know these are real hacks.  But since we are trying to patch something
> >> into libtool that it really isn't designed for, perhaps my hackish
> >> approach has advantages.  In particular, one doesn't have to redesign
> >> different patches every time there is a libtool version update.
> >>
> >> Just some ideas.  In the meantime, do you think it is OK to commit
> >> ports/155105 and the libctl part of ports/155655?  It would be nice to
> >> get these ports working again on the i386, at least on a temporary basis.
> >
> > The libtool binding to the compiler is done for the reason. Your hack
> > will cause more subtle breakage, since it causes libtool to be used with
> > compiler with different internals. In particular, libtool overrides the
> > linking stage arguments, manually providing crt* objects. This is what
> > breaks your ports, but the hack has the same undefined consequences
> > there. You are just lucky that you do not see them.
>
> I must admit that I am just "trying things out."  But based up what you
> said, I think I can now see why this would be a problem.
>
> > Wouldn't it be easier to have per-compiler libtool port ?
> > devel/libtool for the base compiler, devel/libtool-gcc45 for lang/gcc45,
> > probably devel/libtool-clang_base for clang from base and so on.
>
> That would be great if someone were willing to do the work.  To be
> honest, I don't fully comprehend how libtool really works, so I couldn't
> do it.

As I told you when this came up some months ago, and Kostik has noted
again, libtool caches more than just the name of the compiler -- there
are also other important bits of information that may need to be
preserved. Unless there are some changes upstream to accommodate
different toolchains at run-time, I think that making separate libtool
ports for each compiler that is widely-used in Ports is the best
solution, even though it is a nuisance to do so.  Another alternative
would be to alter the autotools infrastructure so that a temporary
libtool was built for each port that needed it, using the compiler
specified for the port, as is now done by some ports that use a
bundled version of libtool, but this would somewhat prolong builds.
The main problem with either of these alternatives is to uncouple the
devel/libltdl port from libtool, because this port installs shared
libraries that may be needed after some port builds, at run-time.  I
haven't looked at whether different versions of libltdl would also be
needed.  If so, the patching and renaming required to point ports to
different versions of those libraries would be the main obstacle.

Here is a rough version that I use as a workaround on my system, for
gcc46.  I didn't make the necessary changes to libltdl, because I
didn't need them.  Also, I didn't bother to save space by unifying the
separate 'plists.

b.


bsd.

Re: PR ports/155331

[b. f.]

> Some time ago (actually, it has been the beginning of March), I
> submitted a proposition to include Emacs Speaks Statistics (ESS)
> (http://ess.r-project.org/), which is an interface to the
> language/statistics package R into ports. I have also included a
> probably erroneous patch (was my first one). I have asked for inclusion
> and correction and advice on the errors I am sure I have made.
> (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155331)
>
> I have not heard of any activity since then. I would be grateful to
> hear whether there is any interest in having ESS in ports. Of course I
> myself advocate for ESS, however, there might be valid reasons for
> choosing not to. Anyway, I would be glad if any decision could be
> reached on that subject.

I've been looking after R, with wen@.  I didn't see your PR -- I'll
take a look, and try to find out what Martin had in mind.  I know that
he has been busy lately (as I have).

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

Re: 2nd deprecation campaign

[b. f.]

On 6/17/11, Baptiste Daroussin  wrote:
> 2011/6/16 b. f. :
>> bapt wrote:
>>>I am in the middle of a new deprecation campaign, to remove ports
>>>where no more distfiles are publicly available (no other OS mirrors
>>>doesn't count except if they are the upstream of course).
>>>
>>>Maybe some will be false positive (I will try to not have too much of
>>> them).
>>
>> Could you please explain how you are checking this?  Just looking at
>> some of the recent deprecations, graphics/peps, graphics/vcg, and
>> graphics/xfig are still available.  On earlier ones,
>> graphics/libconvolve exists in the jack_convolve section of the heaven
>> sourceforge project:
>>
>
> Those are not deprecated but broken, broken because they don't fetch
> and they need someone to take care of it, to send the new master_site
> line for example, I don't have time enough to update/fix all the
> master_site lines from the whole ports tree, so I I see none of the
> said master_site provide the distfiles, it is marked as broken because
> that is what it is.
>

Well, the build often isn't broken (and users don't notice that it is
"broken") because the distfile may be cached locally, or on the
project servers, so this is more a matter of policy in many cases.
But I take your point.  I saw that you began doing this soon after you
announced a deprecation campaign, so I wasn't sure if your were doing
this a preliminary step, before deprecating them in the near future.

...

>> http://packages.qa.debian.org/g/gsmlib.html
>
> Debian having the package doesn't mean that they are the upstream.
>>

No, but in this case the Debian maintainer has taken over that role in
the absence of the original authors, as described in the changelog
there.

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

Re: 2nd deprecation campaign

[b. f.]

bapt wrote:
>I am in the middle of a new deprecation campaign, to remove ports
>where no more distfiles are publicly available (no other OS mirrors
>doesn't count except if they are the upstream of course).
>
>Maybe some will be false positive (I will try to not have too much of them).

Could you please explain how you are checking this?  Just looking at
some of the recent deprecations, graphics/peps, graphics/vcg, and
graphics/xfig are still available.  On earlier ones,
graphics/libconvolve exists in the jack_convolve section of the heaven
sourceforge project:

http://sourceforge.net/projects/heaven/files/Audio%20Applications/Jack%20Related/jack_convolve/

security/libident is available via one of the main vlc developers at:

http://www.remlab.net/files/libident/

comms/gsmlib is maintained by Debian:

http://packages.qa.debian.org/g/gsmlib.html

science/bblimage has been renamed to pyvox and is available at:

http://www.med.upenn.edu/bbl/downloads/pyvox/

That's eight false positives out of eleven  deprecations that I
selected by inspection, and I didn't spend more than two minutes
checking any of them.

I will fix the above.

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

Re: Does USE_GCC= 4.5+ also set C++ and Fortran to g++45/46 and gfortran45/46?

[b. f.]

On 4/14/11, O. Hartmann  wrote:
> On 04/14/11 08:32, b. f. wrote:
>> On 4/14/11, O. Hartmann  wrote:
>>> On 04/13/11 20:59, b. f. wrote:

> We had hope for clang, but clang lacks in many aspects we desperately
> need - like OpenMP support.

That may change, if:

http://wiki.llvm.org/Polyhedral_optimization_framework

and/or some other code is further developed to work inside of or along
with llvm, and you could then use it with clang or dragonegg.  But I'm
guessing that will also take some time.

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

Re: Does USE_GCC= 4.5+ also set C++ and Fortran to g++45/46 and gfortran45/46?

[b. f.]

On 4/14/11, O. Hartmann  wrote:
> On 04/13/11 20:59, b. f. wrote:

> I looked into ports/Mk/bsd.gcc.mk and found that only gcc45 is set in
> case of using USE_FORTRAN, not gcc46. It would be nice also having gcc46
> set, since we try to optimise for AVX in the new Intel Sandy-Bridge CPUs
> and gcc46 is supoorting new facilities like that.

I think that the gcc maintainer will probably switch the default
Fortran compiler to gcc46 after gcc46 has been tested a bit longer,
and some of the remaining bugs fixed.  You could of course switch the
default on your own machines.  AVX support requires more than just a
new compiler and the proper hardware: at the moment, FreeBSD doesn't
support AVX, although some outside developers expressed an interest in
adding support for it:

http://lists.freebsd.org/pipermail/freebsd-arch/2011-March/011167.html

but this will probably take some time.

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

Re: Does USE_GCC= 4.5+ also set C++ and Fortran to g++45/46 and gfortran45/46?

[b. f.]

> Using a self brewn port of a scientific software package which is
> intended to use gcc 4.5 or higher, I use "USE_GCC= 4.5+" in the top
> level Makefile. But I get an error when starting the application:
>
> /libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11
> required by /usr/local/isis/3.2.1/bin/qview not found
>
> Building the software without the ports-framework but with explicitely
> set GCC/G++/GFORTRAN results in a working binary.
>
> My question: is USE_GCC setting C++ and Fortran compilers as desired as
> well as the C compiler?

You should be using USE_FORTRAN if a Fortran compiler is needed (this
also enforces USE_GCC=4.5), and USE_GCC if only C and/or C++ compilers
are needed.  This should set the right variables in your build
environment (see ports/Mk/bsd.gcc.mk), but a build can still fail if
your local, port, or distribution Makefiles do not respect CC, CXX,
CFLAGS, CXXFLAGS, F77, FC, FFLAGS, or LDFLAGS.  It sounds as if this
is the case, and the Wl,-rpath=... component of the flags added in
bsd.gcc.mk is not being used.

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

Re: Removing Cruft from the ports tree

[b. f.]

> Hi,
>
> I’m been working recently on a series of PRs that called “Reaper

I'm glad to see that you're helping to clean up.

>
> One of the features that has given us the most trouble has been
> the options framework for ports. We automatically test ports using the
> default options, but we are unable to perform automated using every
> combination of options. A port with just four options has sixteen
> possible configurations, and some ports have more than that. Even
> supporting one option might double the number of things to test.
>
> However some ports rely on specific configurations of options of
> other ports. In order to deal with this mess we have come up with a
> hack: slave ports. We have entire ports that are designed just to
> change the default options for other ports. This requires a
> non-trivial amount of code on the bsd.*.mk files to support.
>
> Automated configuration is not the only thing that has caused us
> trouble in the past. We routinely have to do deal with questions from
> inexperienced users on questions@ and ports@ details problems with
> non-standard configurations. Many times the solution to a ports
> related problem is flipping a bit in the options file.
>
> I propose removing the options systems entirely. While it does
> serve a small purpose of allowing customization for some end users, I
> believe the flaws outweigh the benefits. Removing the options
> framework would enable us to remove over 500 lines of expensive code
> from the ports system. Not only that but because maintainers would be
> able to choose the best possible configuration for the their port
> users would no longer have to mess around.
>
> While I understand there might some minor part of the community
> that has a sentimental attachment to the blue-on-gray-on-blue
> configuration, and still others want to prematurely optimize, a simple
> workaround could be implemented. We can allow users to add their own
> ./configure arguments to the makefile. This serves the needs of the
> community while allowing us to deal with a simpler and more reliable
> ports system.

The ports system does not exist just to build packages with fixed
configurations.  The ability to configure ports offers an important
degree of flexibility, and one that is not always "sentimental",
"minor", or "premature".  One size doesn't fit all. Your point that
"many times the solution to a ports related problem is flipping a bit
in the options file" cuts both ways.  Flexibility requires more than
just allowing user-specified arguments to a configure script.   Yes,
it adds some effort to maintenance and testing, and some judgement and
discussion is needed when deciding what options to expose.  (And no,
the port maintainer is not always the best judge, or at least not the
only judge, of port configuration.) Occasionally users may be confused
by choices,  but they are just as likely to complain about a lack of
choices.  Fixed configurations will probably lead to pressure for more
slave ports in the form of ports with alternative fixed
configurations,  and not fewer.  If you remove all flexibility from
Ports, then many users will abandon Ports for something else, or be
forced to maintain locally modified Ports trees that often won't be
available for others to use, examine, and test. I think that we should
encourage those users who would be best served by binary packages to
use them, make an attempt to address the questions and problems of
those that need non-default options, work on improving the OPTIONS
framework, and provide a better way of dealing with alternative
dependencies, like those in some other packaging systems.  But I
strongly oppose removing options altogether.


>
> Feel free to express your thoughts here. I would like to get this
> hashed out now so the process could occur on a later date(1).
>

What process?  I hope that you are asking for our opinions, and not
just assuming that you going to carry out this proposal.

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

Re: Updating multiple ports with portmaster

[b. f.]

Matthias Andree wrote:
...
> >>   Is there a way to get portmaster to behave like portupgrade did and
> >>   only upgrade what needs to be upgraded?
> >>
> >
> > This is documented in the portmaster(1) manpage.  You can use -a to
> > update all ports that need to be updated.  To update a subset of
> > those, you could  (1) use -i with -a or a glob (by the way, the *
> > isn't needed with portmaster -- see the portmaster(1) manpage), and
> > respond in the negative to prompts to update or re-install those you
> > wish to exclude; (2) use -x with -a or a glob, to exclude certain
> > ports; or (3) feed portmaster a list of globs that match only those
> > ports that you want to be updated.  In your case, for (3), if you only
> > wanted to update those p5-* ports that need to be updated, but not
> > other ports that need to be updated, you could use something like:
> >
> > pkg_version -qos p5- -l '<' | xargs portmaster
> >
> > Of course, since some new versions of p5-* ports may depend upon new
> > versions of other, non p5-* ports, updating only the p5-* ports isn't
> > guaranteed to work.
>
> portmaster takes care of that, except if there are downstream

It tries to take care of it, and usually succeeds for (1) and (3).
But not necessarily for (2), if one of the ports that should be
updated is excluded.

> dependencies that stop working with updated ports on your list -- but
> that's rather rarely observed and usually documented in
> /usr/ports/UPDATING -- but even then, portmaster -a -i would likely help.

Yes, that's something that should also be taken into consideration.
Rarely, maybe, but more often than one would like -- and sometimes
undocumented.

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

Re: Updating multiple ports with portmaster

[b. f.]

> I have a questions about the use of portmaster when upgrading multiple
>  ports and how to correctly use wildcards.
>
>  For example, I have this from pkg_version:
>
>  p5-Digest-SHA-5.50  <   needs updating (port has 5.61)
>  p5-IO-Socket-SSL-1.38   <   needs updating (port has 1.39)
>  p5-IPC-Cmd-0.68 <   needs updating (port has 0.70)
>  p5-Math-BigInt-1.99 <   needs updating (port has 1.993)
>  p5-Module-Build-0.3607_1<   needs updating (port has
>  0.3624)
>  p5-Module-CoreList-2.42 <   needs updating (port has 2.45)
>  p5-Module-Load-Conditional-0.38 <   needs updating (port has 0.44)
>  p5-Params-Check-0.26_1  <   needs updating (port has 0.28)
>  p5-Test-Harness-3.22<   needs updating (port has 3.23)
>  p5-URI-1.56 <   needs updating (port has 1.58)
>
>  When I was using portupgrade, I could type...
>
>  portupgrade p5-*
>
>  ...and it would upgrade only the ports that needed upgrading and
>  dependancies.  But if I try...
>
>  portmaster p5-*
>
>  ===>>> The following actions will be taken if you choose to proceed:
> Re-install p5-Digest-SHA1-2.13
> Re-install p5-IO-Compress-2.033
> Re-install p5-Compress-Raw-Bzip2-2.033
> Re-install p5-Compress-Raw-Zlib-2.033
> Re-install p5-HTML-Tagset-3.20
> Re-install p5-HTML-Parser-3.68
> Upgrade p5-Digest-SHA-5.50 to p5-Digest-SHA-5.61
> Re-install p5-Mail-SpamAssassin-3.3.1_3
> Re-install p5-Archive-Tar-1.76
> Re-install p5-IO-Zlib-1.10_1
> Re-install p5-IO-String-1.08
> Re-install p5-Package-Constants-0.02
> Re-install p5-Encode-Detect-1.01
> Re-install p5-ExtUtils-CBuilder-0.2802_1,1
> Upgrade p5-IPC-Cmd-0.68 to p5-IPC-Cmd-0.70
> Re-install p5-Locale-Maketext-Simple-0.21
> Upgrade p5-Module-Load-Conditional-0.38 to
>  p5-Module-Load-Conditional-0.44
> Upgrade p5-Module-CoreList-2.42 to p5-Module-CoreList-2.45
> Re-install p5-Module-Load-0.18
> Upgrade p5-Params-Check-0.26_1 to p5-Params-Check-0.28
> Re-install p5-version-0.88
> Upgrade p5-Module-Build-0.3607_1 to p5-Module-Build-0.3624
> Install devel/p5-CPAN-Meta-YAML
> Re-install p5-ExtUtils-Install-1.54
> Re-install p5-ExtUtils-ParseXS-2.22.03
> Install devel/p5-Module-Metadata
> Install devel/p5-Perl-OSType
> Upgrade p5-Test-Harness-3.22 to p5-Test-Harness-3.23
> Re-install p5-Net-DNS-0.66_1
> Re-install p5-Net-IP-1.25_2
> Re-install p5-IO-Socket-INET6-2.65
> Re-install p5-Socket6-0.23
> Re-install p5-Digest-HMAC-1.02
> Re-install p5-Mail-Tools-2.07
> Re-install p5-TimeDate-1.20,1
> Re-install p5-NetAddr-IP-4.038
> Upgrade p5-IO-Socket-SSL-1.38 to p5-IO-Socket-SSL-1.39
> Re-install p5-Net-SSLeay-1.36
> Re-install p5-libwww-5.837
> Upgrade p5-URI-1.56 to p5-URI-1.58
> Re-install p5-YAML-Tiny-1.44
> Re-install p5-Time-HiRes-1.9721,1
> Re-install p5-Locale-gettext-1.05_3
> Upgrade p5-Math-BigInt-1.99 to p5-Math-BigInt-1.993
> Re-install p5-ExtUtils-MakeMaker-6.56
> Re-install p5-MIME-Base64-3.13
> Re-install p5-YAML-0.72
> Re-install p5-Error-0.17016
> Re-install p5-Net-DNS-Resolver-Programmable-0.003
> Re-install p5-Mail-SPF-2.007
>
>  ...it wants to upgrade and reinstall every port that I have installed
>  that begins with p5-*
>
>  Is there a way to get portmaster to behave like portupgrade did and
>  only upgrade what needs to be upgraded?
>

This is documented in the portmaster(1) manpage.  You can use -a to
update all ports that need to be updated.  To update a subset of
those, you could  (1) use -i with -a or a glob (by the way, the *
isn't needed with portmaster -- see the portmaster(1) manpage), and
respond in the negative to prompts to update or re-install those you
wish to exclude; (2) use -x with -a or a glob, to exclude certain
ports; or (3) feed portmaster a list of globs that match only those
ports that you want to be updated.  In your case, for (3), if you only
wanted to update those p5-* ports that need to be updated, but not
other ports that need to be updated, you could use something like:

pkg_version -qos p5- -l '<' | xargs portmaster

Of course, since some new versions of p5-* ports may depend upon new
versions of other, non p5-* ports, updating only the p5-* ports isn't
guaranteed to work.

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

Re: deprecated ports

[b. f.]

On 3/16/11, Mark Linimon  wrote:
> On Wed, Mar 16, 2011 at 06:15:11AM +0000, b. f. wrote:
>> But it's not clear to me why, for example, some usable fonts were
>> deprecated -- fonts often don't have homepages.
>
> The deprecations are (currently) advisory-only.
>
> If people are using these ports, and want to keep them, then they need
> to step up with either hosting the distfiles, becoming the upstream
> maintainers, or in the best case, both.

Yes, I understand.  My point was only that true-type fonts are
unlikely to require much maintenance, and the distfiles will probably
be locally mirrored in any event, so it hardly seems worth the trouble
to deprecate them on the basis of the criteria that were mentioned.

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

Re: deprecated ports

[b. f.]

> That said, I think that un-deprecating these ports just because someone
> can find a distfile somewhere is the wrong approach. bapt has been very
> careful to only deprecate ports that are on the absolute bottom of the
> pile. They are unmaintained, and unfetchable.

That's not completely accurate.  Some ports were deprecated because
their distfiles had been moved, sometimes to another directory on the
same server, but this went unnoticed because the distfiles were
mirrored locally.  I see a few others, some of them standard packages,
that were caught in the net for various reasons -- one because someone
had compressed the local copies of the distfiles, and then marked the
Makefile so that only the compressed versions that were not present
upstream would be fetched; another, still fetchable and with a
reachable homepage, was deprecated presumably because it had a few bad
mirrors.  I'll fix these. There is certainly a lot that could and
should be cleaned up, and it is difficult for one person to do this
without making a few mistakes -- I'm glad that Bapt was willing to
make the attempt. But it's not clear to me why, for example, some
usable fonts were deprecated -- fonts often don't have homepages.

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

Re: [HEADS UP] GNU make 3.82

[b. f.]

On 3/13/11, Ade Lovett  wrote:
>
> On Mar 12, 2011, at 17:22 , b. f. wrote:
>
>>> On Fri, Mar 11, 2011 at 09:14:50PM -0800, Doug Barton wrote:
>>>> There are way too many things happening "in private" around here and
>>>> the only way to solve that problem is to open the doors.
>>>
>>> Would you please offer examples of decisions that you feel that way
>>> about?
>>
>> We need not look any farther than this episode to see an example of
>> how things could have been handled better.  I don't think that the
>> course of action that was ultimately adopted was unreasonable, but did
>> we have to wait from the 8 October, when I filed
>> ports/151312
>
> I quote from the PR log:
>
>   State-Changed-From-To: open->suspended
>   State-Changed-By: ade
>   State-Changed-When: Fri Oct 8 16:40:29 UTC 2010
>   State-Changed-Why:
>   gnu make 3.81 -> 3.82 is, sadly, exceptionally non-trivial.  A number of
>   features present in releases prior to 3.82 are technically "wrong", and
>   this release has corrected them.  A _lot_ of stuff breaks.  It will be
>   looked at, but don't hold your breath.
>
> Plenty of other stuff was happening in autotools-land at the time.  We had
> already run a previous preliminary analysis of gmake 3.81->3.82 and it was
> _not_ pretty.
>
> That update to the PR took just a little under 2 hours from initial
> submission.  Suggesting that it took until March 11th is disingenuous at
> _best_

Your response, though initially prompt, doesn't contain any
information, like that in Mark's recent message, that allows us to
help solve any problems.  As far as I can tell, you have not provided
any specific results throughout the course of this update, even when
repeatedly asked to do so.  I did not follow up on this matter
earlier, because I knew other, more pressing problems were being
addressed, because I was myself busy, and because I saw no particular
urgency to this update.  I filed the ports/151312 as a reminder and a
point-of-reference for progress reports on the update, probably for
the same reasons that you later filed the duplicate ports/155215.  I
don't object to the course of action you proposed, and I understand
that you and others have freely invested time and effort into this and
other updates.  But I think that the manner of your replies on this
list and elsewhere has been unfortunate, even allowing for the fact
that you may have been given some provocation.  We expect and need
more concrete information, and fewer ad hominem arguments and requests
to defer to your judgment for unspecified or vague reasons.  And now I
think that we should bring this argument to a close, because we have
spent too much time and energy on this matter, and aroused too much
rancor, when we could have been doing more useful work.

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

Re: [HEADS UP] GNU make 3.82

[b. f.]

>On Fri, Mar 11, 2011 at 09:14:50PM -0800, Doug Barton wrote:
>> There are way too many things happening "in private" around here and
>> the only way to solve that problem is to open the doors.
>
>Would you please offer examples of decisions that you feel that way about?

We need not look any farther than this episode to see an example of
how things could have been handled better.  I don't think that the
course of action that was ultimately adopted was unreasonable, but did
we have to wait from the 8 October, when I filed
ports/151312, until your forwarded message of 11 March:

http://lists.freebsd.org/pipermail/freebsd-ports/2011-March/066478.html

to learn what was actually broken by the change, so that we could
begin to fix it?  Shortly after you sent your message to the lists,
other people began to help. This could have happened a lot sooner, and
we could have avoided some of this discreditable bickering.

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

Re: science/libctl marked as BROKEN, but does build on 8.2-STABLE amd64

[b. f.]

> On Fri, Mar 11, 2011 at 10:59:02AM +, Klaus T. Aehlig wrote:
> > Can anyone shed more light on why this port is marked BROKEN?
...
>
>   libtool: link: cc -shared  .libs/ctl.o .libs/subplex.o .libs/ctl-f77-glue.o 
> .libs/integrator.o .libs/cintegrator.o   -Wl,-rpath -Wl,/usr/local/lib 
> -Wl,-rpath -Wl,/usr/local/lib -pthread -L/usr/local/lib 
> /usr/local/lib/libguile.so /usr/local/lib/libintl.so 
> /usr/local/lib/libiconv.so /usr/local/lib/libgmp.so -lcrypt -lm 
> /usr/local/lib/libltdl.so  -Wl,-rpath=/usr/local/lib/gcc45 -pthread -pthread 
> -pthread   -pthread -Wl,-soname -Wl,libctl.so.4 -o .libs/libctl.so.4
>   .libs/ctl.o(.text.__i686.get_pc_thunk.bx+0x0): In function 
> `__i686.get_pc_thunk.bx':
>   : multiple definition of `__i686.get_pc_thunk.bx'
>   /usr/lib/crtbeginS.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0): first 
> defined here
>
...

More fallout from the devel/libtool problem that led to ports/155105,
broke math/gretl, etc.: the port has USE_FORTRAN, and so is built with
lang/gcc45, but then libtool attempts to link the shared libraries
with the base system compiler and toolchain.  This still needs to be
fixed.

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

Re: FreeBSD needs fresh Blood!

[b. f.]

>portmaster -L --index-only  0.76s user 1.65s system 6% cpu 38.871 total
>
>So it takes 38s on a *very small* installation. My experience is that
>all FreeBSD ports tools are incredibly slow, be it portupgrade,
>portmaster, even the basic tools like pkg_version. Maybe it would help
>to recognize that such observations are perhaps not unrelated to the
>original poster comments.

I am only seeing ~8s for this on my 9-CURRENT amd64 system with ~400
ports, including the time to download a new index from the server.
These comparisons aren't very helpful when they're not accompanied by
enough information to reason about causes.  "Incredibly slow" is
rather subjective.  Compared to what?  What specific recommendations
do you have for improvements?  And I might add, why haven't you
submitted your own tools as a port, since you seem to think, as you
have written elsewhere, that they offer substantial improvements over
the others that are available?

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

Re: [FYI] Fwd: cvs commit: ports UPDATING ports/Mk bsd.python.mk

[b. f.]

Heino Tiedemann wrote:
>> >>> Does it rebuild all depending packages?
> >>
> >>And waht is the difference between make upgrade-site-packages and
> >>portupgrade -r python?
...
> can you tell me if libreoffice is in the list to recompile?

I don't know, I don't have it on my machine.  If you do, then see if
it installs files in a python library directory, via

pkg_info -Lx libreoffice | grep -e '/lib/python[0-9]'

or some alternative method.  Or look at the packing list of a
libreoffice package.  If it does install files in such a directory,
then it will be rebuilt by upgrade-site-packages.  If it doesn't
install files there, then it should not be rebuilt, unless you issue
non-default PORTUPGRADE_ARGS.

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

Re: FreeBSD needs fresh Blood!

[b. f.]

On 3/6/11, Grzegorz Blach  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/06/2011 18:35, b. f. wrote:
...
>>> First of all, I think it's difficult to testing ports.
...
> Multiple trees don't help me a lot, portmaster became fools.
> There is no significant difference if I use version control system or
> portshaker to merge trees.

I'm not so sure.  But in any event, maybe you can elaborate on what
you mean by portmaster becoming a "fool"?

...
>>> Another possibility is replace ports in disk, but after upgrade tree eg.
>>> with portsnap I lose my changes, and portmaster want to rebuild these
>>> ports to stable release.
...
>> system that can import CVS), which will make merging and reverting
>> changes easier. And naturally you shouldn't run updating tools until
>> you've modified your tree.
>
> But I won't resign from use updating tools, even when I use merged tree.
> Because I use merged tree all the time.

No one is asking you to.  But obviously you'll have to use the tools
at the right time, and in the right manner, if you are going to be
experimenting with different sets of ports.  It doesn't sound as if
you are doing that now, based on your reports.  If you really want to
use portmaster, and you don't want to be troubled with rebuilding the
index, then maybe you could ask the portmaster maintainer to implement
an option that ignores the index, and relies solely on the ports tree,
 if there isn't such an option already.  Or examine the various
incremental update methods I cited earlier.

...
> I known that are many different ways to merge ports from different
> sources, but none of them are simple and fast to use it for first time.
>
> Look at last calls for testers:
>
> http://lists.freebsd.org/pipermail/freebsd-ports/2011-February/065884.html
>
> http://lists.freebsd.org/pipermail/freebsd-ports/2011-February/065983.html
>
> There are only links to tarballs, without address to repository.
> I must download tarballs, commit ports to my tree and merge it with
> official ports.
>
> Another CFT:
> http://lists.freebsd.org/pipermail/freebsd-ports/2011-February/066007.html
>
> There is address for repository, but I still need merging trees
> and rebuild index for portmaster.
>
>
> I thing if testing ports will be simpler, more people can do this,
> and want to do this. I proposed stable and current trees, but maybe
> one official merge tool, which is easy to setup will be better, or
> something completely different.

Okay, so we could make a webpage that contains some recommendations
and instructions for those interested in testing.  And we could make a
central repository using a version control system that has efficient
branching, where committers could be asked to add major changes in
separate branches, so that it would be easier to test them.  (I'm not
saying one unstable branch, because I think it would be difficult to
isolate and solve problems when mixing lots of different changesets.)
Those are reasonable suggestions.  But of course, these suggestions
would require more work from committers, and won't make testing
completely painless.  They would be roughly equivalent to the case you
mention above, where there was a repository -- yet you still seemed
reluctant to test in that case.

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

Re: FreeBSD needs fresh Blood!

[b. f.]

On 3/6/11, b. f.  wrote:
...
>> First of all, I think it's difficult to testing ports.
...
>> Another possibility is replace ports in disk, but after upgrade tree eg.
>> with portsnap I lose my changes, and portmaster want to rebuild these
>> ports to stable release.
...
> It sounds like you are using the wrong tools. Although portsnap (which
> is not best suited for this purpose) has path arguments and an -l flag
> that can be used to add or preserve local changes, and both portmaster
> and portupgrade have options to ignore certain ports or to substitute
> alternative dependencies, you shouldn't have to make use of them.
...
>> Merging trees is another huge problem.
>> Portshaker do this very well, but after merge I must rebuild INDEX file,
>> which takes long time. This should be faster or even shouldn't be
>> required (hard to do).

I should mention, too, that despite the awkwardness of these tools in
this context, others who prefer to use them have found methods to
overcome some of the problems that you mention.  See, for example:

http://lists.freebsd.org/pipermail/freebsd-ports/2007-April/040366.html

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

Re: FreeBSD needs fresh Blood!

[b. f.]

> I read last post Martin Wilke's blog called "FreeBSD needs fresh Blood!"
>
> First of all, I think it's difficult to testing ports.
>
> I'm using testing release of VirtualBox,
> but for build this port I must download patches,
> apply its on my own tree and merge its with official ports
> using portshaker.
>
> It's possible to build testing ports outside tree,
> but I must build every port separately, since `Make` don't known how to
> track dependencies.

There is always going to be some added work involved in testing.  Have
you considered using multiple trees, if you have sufficient disk
space? Or using a version control system?

>
> Another possibility is replace ports in disk, but after upgrade tree eg.
> with portsnap I lose my changes, and portmaster want to rebuild these
> ports to stable release.
>

It sounds like you are using the wrong tools. Although portsnap (which
is not best suited for this purpose) has path arguments and an -l flag
that can be used to add or preserve local changes, and both portmaster
and portupgrade have options to ignore certain ports or to substitute
alternative dependencies, you shouldn't have to make use of them.
Instead, you should probably be using CVS (or another version control
system that can import CVS), which will make merging and reverting
changes easier. And naturally you shouldn't run updating tools until
you've modified your tree.

> If testing will be simpler, I think more people will do this.
> Maybe we must create two trees, eg: ports-stable and ports-current
> First we publish changes to current tree and after week or two without
> pr, we publish updates to stable tree too.

This has often been proposed, but since it would require more work
from the already-overstretched committers, and the benefits are
questionable, I don't think it is likely to happen soon.

>
> Merging trees is another huge problem.
> Portshaker do this very well, but after merge I must rebuild INDEX file,
> which takes long time. This should be faster or even shouldn't be
> required (hard to do).

Do you really need to rebuild the INDEX?  You can often avoid using
it. If you do need to modify it, you can use some improved method,
like

http://www.lpthe.jussieu.fr/~talon/build_index.py

or modify it incrementally, with something like
ports-mgmt/p5-FreeBSD-Portindex,

http://www.lpthe.jussieu.fr/~talon/portindex-18_1.tgz

, or your own script.

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

Re: [FYI] Fwd: cvs commit: ports UPDATING ports/Mk bsd.python.mk

[b. f.]

On 3/6/11, Rainer Hurling  wrote:
> On 06.03.2011 09:09 (UTC+1), b. f. wrote:
>> On 3/6/11, Rainer Hurling  wrote:
>>> On 06.03.2011 00:56 (UTC+1), b. f. wrote:

>
> Now it is more clear to me that this upgrading process depends from the
> specific installation. Perhaps it should be mentioned in ports/UPDATING,
> that eventually this upgrading is not complete?

May not be complete.  I think a brief note to that effect would have
been useful, judging from the comments of some people on the mailing
lists.

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

Re: [FYI] Fwd: cvs commit: ports UPDATING ports/Mk bsd.python.mk

[b. f.]

On 3/6/11, Rainer Hurling  wrote:
> On 06.03.2011 00:56 (UTC+1), b. f. wrote:
>>>> Does it rebuild all depending packages?
>>>
>>> And waht is the difference between make upgrade-site-packages and
>>> portupgrade -r python?
>>
>> As I explained earlier on freebsd-python@, unlike 'portupgrade -r
>> python', the upgrade-site-packages target just rebuilds ports that
>> have files in the library directories belonging to non-default
>> versions of python, and ports that in turn depend upon them, not
>> necessarily every port that lists python as a dependency.
>> upgrade-site-packages is for your convenience, to rebuild a (probably)
>> smaller collection of ports that are most likely to need rebuilding
>> after a change in default python versions.
>
> Thanks for the explanation. In principle the script works as aspected.
> As far as I can see there remain some ports like graphics/qgis without
> upgrading. QGIS defines USE_PYTHON=yes in its Makefile, but is not
> upgraded. Other examples from my installations are multimedia/xbmc,
> irc/xchat, editors/openoffice.org-3.
>
> pkg_libchk from sysutils/bsdadminscripts identifies most (all?) of them.


Sure, there are a number of ways to identify which ports actually
depend upon python. pkg_libchk will get you most, but maybe not all,
of them.  (One might be configured in a way that depends upon the
specific version of python used, but not actually link to a python
shared library, for example.)

Since rebuilding lots of ports can consume time and resources, and
some ports depend upon python only to the extent of containing
portable scripts with a /usr/local/bin/python shebang in them, and
hence don't really need to be updated, the upgrade-site-packages
target was created as a reasonable compromise, to update only those
ports that probably need to be updated when the default version of
python is changed. update-site-packages may update a few that don't
need to be updated (a port that really needs and is set up to use a
non-default version of python, for example), and it may miss others
that ought to be updated (a port that doesn't install files in a
python library directory, but nevertheless depends in an important way
upon the specific version of python used).  If you want to be
thorough, then don't use upgrade-site-packages, but rather recursively
update all ports that depend directly or indirectly upon python.

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

Re: [FYI] Fwd: cvs commit: ports UPDATING ports/Mk bsd.python.mk

[b. f.]

On 3/5/11, b. f.  wrote:
>>> Does it rebuild all depending packages?
>>
>>And waht is the difference between make upgrade-site-packages and
>>portupgrade -r python?
>
> As I explained earlier on freebsd-python@, unlike 'portupgrade -r
> python', the upgrade-site-packages target just rebuilds ports that
> have files in the library directories belonging to non-default
> versions of python, and ports that in turn depend upon them, not
> necessarily every port that lists python as a dependency.

Sorry, I should clarify this.  Above, I meant to write:

... and _not_ necessarily ports that in turn depend upon them, or
every port that lists python as a dependency.

> upgrade-site-packages is for your convenience, to rebuild a (probably)
> smaller collection of ports that are most likely to need rebuilding
> after a change in default python versions.

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

Re: [FYI] Fwd: cvs commit: ports UPDATING ports/Mk bsd.python.mk

[b. f.]

>> Does it rebuild all depending packages?
>
>And waht is the difference between make upgrade-site-packages and
>portupgrade -r python?

As I explained earlier on freebsd-python@, unlike 'portupgrade -r
python', the upgrade-site-packages target just rebuilds ports that
have files in the library directories belonging to non-default
versions of python, and ports that in turn depend upon them, not
necessarily every port that lists python as a dependency.
upgrade-site-packages is for your convenience, to rebuild a (probably)
smaller collection of ports that are most likely to need rebuilding
after a change in default python versions.

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

Re: multiple definition of `__i686.get_pc_thunk.bx'

[b. f.]

On 3/1/11, Stephen Montgomery-Smith  wrote:
> Stephen Montgomery-Smith wrote:
>> b. f. wrote:
>>>>> On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote:
...
>>>
>>> As is clear from bsd.gcc.mk, in almost every case now in use,
>>> USE_FORTRAN sets _USE_GCC, which sets CC, CPP, and CXX to the proper
>>> values.  Also, it sets USE_BINUTILS where appropriate, which sets LD,
>>> etc.  The problem is rather with libtool, particularly in the link
>>> mode, where it may not respect the choice of compiler and toolchain.
>>> This problem has been remarked, for two years or more, in the mailing
>>> lists and forums, when people discuss the use of compilers other than
>>> the base system compiler.  With the recent updates, it is more
>>> obtrusive, and several ports that were building successfully with
>>> default settings are now broken.  This needs to be fixed, and it would
>>> be better to fix libtool than to add a bunch of ad-hoc fixes to
>>> individual ports.
...
>
> OK, this problem was more subtle than I originally thought.  The error I
> pointed out doesn't occur consistently, but it does occur in the context
> of building vis5d+.
>
> But I have a patch that definitely fixes libtool enough for me.  What do
> you guys think?  This perhaps doesn't fix all the problems, but maybe it
> can act as a model to fix them all.
>
>

libtool caches more than just the compiler name.  It also stores the
path to various utilities (ar, as, ld, etc.), various compiler flags,
compiler search directories, (pre|post)dep objects, etc.  These aren't
always used, but they may sometimes be important, and they vary among
the different compilers in ports, so I think that any modifications
should take these into account. One of the problems is that the
upstream developers didn't think that (outside of cross-building,
which is handled a bit differently) more than one toolchain would be
in use on a given system.  On my system I adopted the expedient of
modifying bsd.autotools.mk and adding separate per-compiler libtool
ports.  That's not the prettiest way of handlng this problem either,
and it is awkward for the libltdl ports, so I'm not saying that this
method should be adopted.

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

Re: multiple definition of `__i686.get_pc_thunk.bx'

[b. f.]

> > On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote:
> >> I am the maintainer of the port vis5d+.  I just got this email (copied 
> >> below) saying that vis5d+ isn't building right now.
> >>
> >> The issue seems to be that some reference to __i686.get_pc_thunk.bx is 
> >> included twice at some point.  This variable seems to be part of an object 
> >> file crtbeginS.o that is created by gcc or gcc45, in what seem to me to be 
> >> very mysterious conditions.  I am rather sure that the issue has nothing 
> >> to do with vis5d+, but rather is something to do with either gcc45, or 
> >> libtools, neither of which I understand.
> >>
> >> Does anyone out there have any idea of what the problem is, or how it can 
> >> be solved?
> >>
>
> From a relatively cursory examination, this appears to be a flaw in the 
> USE_FORTRAN=yes stanza.  This will bring in gcc45 as a dependency but doesn't 
> appear to be setting CXX to g++45 though it does do CC=gcc45.  Possibly the 
> same for LD, though I haven't checked that.

As is clear from bsd.gcc.mk, in almost every case now in use,
USE_FORTRAN sets _USE_GCC, which sets CC, CPP, and CXX to the proper
values.  Also, it sets USE_BINUTILS where appropriate, which sets LD,
etc.  The problem is rather with libtool, particularly in the link
mode, where it may not respect the choice of compiler and toolchain.
This problem has been remarked, for two years or more, in the mailing
lists and forums, when people discuss the use of compilers other than
the base system compiler.  With the recent updates, it is more
obtrusive, and several ports that were building successfully with
default settings are now broken.  This needs to be fixed, and it would
be better to fix libtool than to add a bunch of ad-hoc fixes to
individual ports.

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

Re: ath9k driver

[b. f.]

>I am looking for the FreeBSD equivalent of the ath9k driver that comes with
>Linux.

>Can't find it between the ports on you're website and Google gives (as
>results) plenty of people looking for the same thing I am, just no
>(definitive) answer.

>Do you happen to know if this driver has been ported to FreeBSD?

Some, but not all, of the driver's functionality is available in
ath(4).  [Some of the earliest (partially-)open-source Atheros support
started in FreeBSD, but the Linux drivers borrowed from this, and
offer more features at the moment.] There is work being done to add
more in -CURRENT -- see, for example:

http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022467.html
http://lists.freebsd.org/pipermail/freebsd-mobile/2011-February/012243.html

The freebsd-current and freebsd-mobile mailing lists are better for this topic.

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

Re: FreeBSD Port: ppl-0.10.2_1

[b. f.]

>  Dear Sir(s)
>
>I am having trouble using your ppl package. I keep getting errors
> about undefined references, in the ppl libraries, concerning basic
>C++ input and output streams. Does a patch need to be applied,
> perhaps? Could the install not have been done correctly? I did
>not do the install my self, so I can't be absolutely sure if it
> installed without problems. Please advise.

We would need more details to attempt to deal with your problem: what
related packages are installed on your machine, what you were
attempting to do, and the error messages you encountered.

( If you're not sure about this, see, for example:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/index.html
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
http://www.catb.org/~esr/faqs/smart-questions.html

)

You should probably also contact the port maintainer, if you haven't
done so already:

grosser _at_ fim.uni-passau.de

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

Re: [HEADS UP] Python Infrastructure changes Roadmap

[b. f.]

>On that note out of every python app that I use there has only been one
>problem not really vital (ports/devel/py-psyco) does not seem to build
>against 2.7 and I assume that would be the same for ( > 2.7 )

>From the psyco homepage:

"16 July 2010

Python 2.7 is unsupported so far. Anyone interested in porting Psyco
to it is welcome. I started the work in a branch but it needs
finishing."

http://codespeak.net/svn/psyco/branch/py27

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

Re: How to not use OPTIMIZED_FLAGS properly

[b. f.]

On 2/7/11, Ruslan Mahmatkhanov  wrote:
...
> Yes. I get it wrong what Konstantin and portlint are said. Sorry.
> CFLAGS=-O0 out of CONFIGURE_ENV works just fine. Thanks.

Note that CFLAGS=-O0 is (even) more restrictive than CFLAGS+=-O0 --
the latter just overrides the -On setting for n > 0, while the former
also overrides all other user flags.  Generally speaking, the latter
should be preferred, as part of our attempt to honor user-defined
CFLAGS.
...
>> This seems pessimistic, by the way.  Have you tried adding other
>> compiler flags, like those to control the compiler's memory usage? Or
>> using another compiler via USE_GCC, or patching the source code?
...
> Yes, i tried different flags that affect gcc memory usage, but w/o any
> success. I'm actually started from patching source code - removing
> optimization flags from distribution Makefiles.

That's a start.  But I think that this needs more investigation,
beginning with the code that causes the base system compiler to become
a hog.

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

Re: How to not use OPTIMIZED_FLAGS properly

[b. f.]

> 07.02.2011 20:50, Konstantin Tokarev пишет:
> >
> >
> > 07.02.2011, 20:34, "Ruslan Mahmatkhanov":
> >> Hello.
> >>
> >> I'm working on port that doesn't builds with "-O2 -pipe", that passed to
> >> Makefile by default (it exits with message about virtual memory is
> >> exhausted). I can avoid this by setting CFLAGS="" and CXXFLAGS="" in
> >> CONFIGURE_ENV. But portlint is complaining like this:
> >>
> >> WARN: Makefile: CFLAGS/CXXFLAGS are not needed in CONFIGURE_ENV as they
> >> are already added there in bsd.port.mk.
> >> FATAL: Makefile: CFLAGS are clobbered in CONFIGURE_ENV.  Alter CFLAGS in
> >> the Makefile with CFLAGS+=... instead
> >> FATAL: Makefile: CXXFLAGS are clobbered in CONFIGURE_ENV.  Alter
> >> CXXFLAGS in the Makefile with CXXFLAGS+=... instead
> >>
> >> What is the right way to do the job?
> >>
> >> PS. If i set -O0 in CONFIGURE_ENV, it's later redefined to "-O2 -pipe".
> >
> > Have you tried CFLAGS+=-O0 as portlint suggested?
>
> As i said before i tried that. If i'm using +=-O0 then it changes to -O2
> -pipe. If i'm using =-O0, then all builds fine, but this make portlint
> complaining.

CFLAGS and CXXFLAGS are already passed by default in do-configure, as
portlint states.  Why aren't you simply defining them, by themselves
and not as a part of CONFIGURE_ENV, in the port Makefile?:

CFLAGS+=-O0

This seems pessimistic, by the way.  Have you tried adding other
compiler flags, like those to control the compiler's memory usage? Or
using another compiler via USE_GCC, or patching the source code?

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

Re: What ports require this port?

[b. f.]

On 2/6/11, Dan Langille  wrote:
> On 2/6/2011 9:03 PM, b. f. wrote:
>> On 2/6/11, b. f.  wrote:

>
> While we're here... is there anything special about PATCH_DEPENDS,
> FETCH_DEPENDS, and EXTRACT_DEPENDS that might be different than the
> depends I'm already processing?  They seem to be the same format:
>
> [dan@ngaio:/usr/ports/graphics/tifmerge] $ make -V EXTRACT_DEPENDS
> tuc:/usr/ports/converters/tuc
> /usr/local/bin/unzip:/usr/ports/archivers/unzip
>
> [dan@ngaio:/usr/ports/www/apache13-modssl] $ make -V PATCH_DEPENDS
> /usr/local/bin/perl5.8.9:/usr/ports/lang/perl5.8
> /usr/local/bin/perl5.8.9:/usr/ports/lang/perl5.8

IIRC, they are the same ordered triple format.  By the way, just
because a port is in the *_DEPENDS of another port, doesn't
necessarily mean that the first port must be installed to build the
second port: sometimes the (usually absent) third element of the
triplet can be used to override the default "install".  So some
*_DEPENDS, for example, just need to be fetched rather than installed.
 Others may just need to execute some simple target defined in the
Makefile of the dependency.  I don't know whether you want to include
that level of detail in your Freshports pages.

> However, my manual searches to find a port which outputs a value for
> 'make -V FETCH_DEPENDS' have failed so far.  But I'm sure it will turn
> up during my first few test runs.

fgrep -e FETCH_DEPENDS -nH -r $PORTSDIR --include='*Makefile':

ports/cad/kicad-devel/Makefile:83:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/cad/kicad-devel/Makefile:84:FETCH_DEPENDS+=
bzr:${PORTSDIR}/devel/bazaar-ng
ports/comms/wsjt/Makefile:66:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/devel/compiler-rt/Makefile:62:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/devel/llvm-devel/Makefile:89:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/graphics/seom/Makefile:47:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/graphics/yukon/Makefile:44:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/lang/clang-devel/Makefile:75:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/net/xorp-devel/Makefile:45:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/print/bsd_lpr/Makefile:33:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/www/trac-discussion/Makefile:31:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/www/trac-fivestarvote/Makefile:30:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/www/trac-math/Makefile:37:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/www/trac-ticketimport/Makefile:31:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion
ports/www/trac-vote/Makefile:30:FETCH_DEPENDS+=
svn:${PORTSDIR}/devel/subversion

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

Re: What ports require this port?

[b. f.]

On 2/6/11, b. f.  wrote:
>> Over the weekend, a new feature was added to FreshPorts BETA.  A port
>> now lists all ports that require it.  This code will eventually move to
>> production after it's been running on on the beta site for a while.
>>
>> Notes:
>>
>> * The code uses the output of make -V RUN_DEPENDS -V LIB_DEPENDS -V
>> BUILD_DEPENDS
>
> If you're going to include BUILD_DEPENDS, then you should also use -V
> PATCH_DEPENDS -V FETCH_DEPENDS.

And, of course, -V EXTRACT_DEPENDS.

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

Re: What ports require this port?

[b. f.]

> Over the weekend, a new feature was added to FreshPorts BETA.  A port
> now lists all ports that require it.  This code will eventually move to
> production after it's been running on on the beta site for a while.
>
> Notes:
>
> * The code uses the output of make -V RUN_DEPENDS -V LIB_DEPENDS -V
> BUILD_DEPENDS

If you're going to include BUILD_DEPENDS, then you should also use -V
PATCH_DEPENDS -V FETCH_DEPENDS.

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

Re: policy on having the same routines in different library archives?

[b. f.]

> I can see benefits and disadvantages of having same
> routines in different libraries. Advantages are
> that a user can choose to only install Slatec,
> with no Blas, and that no fine tuning of the
> distribution is required.
> Disadvantages could be extra size and potential
> for confusion, e.g. when linking against both
> libraries.
>
>Is there a FreeBSD ports policy on this?

The situation is not unique to these two ports, and there is no
blanket policy, other than a general preference for shared libraries
and arranging things so as to reuse as much code as possible, and to
retain flexibility.  The decision about which routines to include
depends upon how we want to use slatec.  I'll look at this when I add
your port, which I'm going to do now that the binutils changes have
been made. Just because these routines are present doesn't necessarily
mean that dependent ports have to use them.

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

Re: Returning with question about SELECTIVELY updating ports tree

[b. f.]

> > Protect your ports tree
> > $> cd /usr/
> > $> mv ports ports_save && mkdir ports &&
> > portsnap extract
> >
> >
> > This way you have your old and a fresh ports tree
> > available.
> > Portsnap checks the file ports/.portsnap.INDEX to see
> > which
> > ports have updates without this file portsnap extracts the
> > whole tree.
> >
> > Now you can check with diff what has changed in your
> > needed
> > ports. In most of the cases you can merge the ports in the
> > saved tree to newer versions.

> When you do that, don't you mess up the "install/uninstall" data?  The new 
> port
> may not know how to uninstall the old one correctly, or even understand that 
> the
> old one is installed.

This only happens infrequently, when a port is moved or removed, and
this is almost always recorded in ports/UPDATING, ports/MOVED, or
both. For these rare cases you can call pkg_delete(1) manually (the
'deinstall' and 'deinstall-all' targets for the port are just wrappers
around pkg_delete), or  or use portupgrade or portmaster with the -o
flag.The records of installed ports are kept in the package database
directory (usually /var/db/pkg), and are independent of the ports
tree.

>
> Or am I missing something?  I went through something like this a while ago, 
> with
> a massive set of uncontrolled rebuilds.  My shared libraries and executables
> were bolixed and after two days of trying to get X (and X apps and other 
> things)
> running again I gave up and reloaded from backup.
>
> I don't want to go that route again.
>

That's understandable, but if you do the upgrade properly, it may be
less trouble than maintaining a hybrid ports tree on your own.  If
you're willing to take the system down for a period, the instructions
for a complete upgrade in the portmaster(1) manpage from the
ports-mgmt/portmaster port are reliable.  And you could use packages,
at least as an intermediate step, which would make an upgrade much
shorter, or at least minimize the downtime.  Your version of FreeBSD
is not so old that it should cause many problems with newer ports,
since the default packages are built on 7.1-STABLE.

> Here's my point of confusion:
>
> My understanding is that portupgrade understands how to rebuild ports and 
> manage
> their dependencies.  It's not perfect, but it's far more right than wrong.  
> And
> the key to portupgrade is whatever ports-available/dependent list it uses.  So
> shouldn't The Right Thing To Do be to fetch and install just the upgrade to 
> that
> list?
>

The list is the index. Most people just download a copy of the index
from the FreeBSD package repository, which lists the ports available
in a recent snapshot of the ports tree, with dependencies based upon
the default choices for options that are used to build packages there.
 You can run into problems when your index isn't synchronized with
your ports tree and the options stored in the ports database directory
(usually /var/db/ports), or in local Makefiles.  This might happen
with your partially-updated tree.  So it would be safer to build your
own index, by  using the 'index' target in the top directory of your
ports tree, or 'portsdb -U'; or to sidestep the problem by using pkgdb
-L followed by portupgrade -O ... ; or to use portmaster with the -t
flag.  (All of these take more time than downloading and using the
index from the repository.)  Alternatively,  you could download an
index or build it once, and then modify it with
ports-mgmt/p5-FreeBSD-Portindex.

If you don't want to use cvs(1), then, in addition to the selective
use of portsnap that the others have mentioned, you can use csup(1)
with the -i flag to update single ports or categories, rather than the
whole ports tree; or you can just download individual ports in a
tarball from the Freebsd cvs web interface, for example:

http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/sysutils/cdrtools-devel/cdrtools-devel.tar.gz?tarball=1

and unpack them into your ports tree.  If you corrupt your old tree,
then you can restore it (even in the absence of a local backup) from a
tarball on old release media or in the FreeBSD ftp archive, or by
using csup with a date keyword, or a branchpoint or release tag.

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

Re: ports-mgmt/portconf , ports-mgmt/portmaster and make args

[b. f.]

On 1/1/11, Doug Barton  wrote:
> On 01/01/2011 11:44, b. f. wrote:
>> On 1/1/11, Doug Barton  wrote:
>>> On 12/31/2010 18:40, b. f. wrote:
...
>> and that
>> NO_PACKAGE may preclude your use of 'make package' with -g in
>> portmaster (at least without some workaround like FORCE_PACKAGE).
>
> Different issue, the OP was concerned about using packages to install
> all of his ports _except_ for the ones where he had defined options in
> ports.conf.

... yet the user may wish to create back-up packages for those
exceptional ports, which he is building.

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