Re: manpath change for ports ?

[Baptiste Daroussin]

On Fri, Mar 10, 2017 at 10:50:39AM +0100, Dag-Erling Smørgrav wrote:
> John Baldwin  writes:
> > I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
> > so long as our default MANPATH included both if that means applying fewer
> > patches to ports.
> 
> The default MANPATH is constructed dynamically from PATH:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin: pathname/../man
>   Note: Special logic exists to make /bin and /usr/bin look in
>   /usr/share/man for manual files.
> 
> If we change this to:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin or /sbin: pathname/../man and
>   pathname/../share/man
Which I have just done :)

Bapt


signature.asc
Description: PGP signature

Re: FreeBSD Port: xf86-video-intel-2.99.917.20170228

[O. Hartmann]

Am Tue, 07 Mar 2017 13:42:02 +0900 (JST)
Masachika ISHIZUKA  schrieb:

>   My Dell XPS12 (9Q33, Corei7-4500U, haswell) is working well with
> xf86-video-intel-2.99.917.20170228 (sna) without kld_list="i915kms".
> 
>   Issue for both r435512(2.99.917.20170228) and r433863(2.99.917.20170103)
> is not showing any windows after resuming blanking screen.
> Workaround is that the switching console (ctl-alt-F1) and
> reswitching x11 (clt-alt-F9). It's shown windows again.

Same here with a Lenovo E540 notebook with a Haswell HD4200 graphics.. 
Sometimes the
black screen goes away by itself and the xdm login/X11 graphics screen pops up, 
sometimes
not and I have to switch first to console and then to the tty with the graphics 
output
back to get the GUI.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp_uH19PRPbg.pgp
Description: OpenPGP digital signature

Re: Chicken/egg problem with pkg

[Greg Byshenk]

On Fri, Mar 10, 2017 at 02:57:32PM +0100, Jan Bramkamp wrote:
> On 10/03/2017 14:47, Guido Falsi wrote:
> > On 03/10/17 14:26, Hans de Hartog wrote:

> >> I have an old web server (10.1-RELEASE-p9) which is running for years
> >> without any upgrades. Now I want to install a simple port (trafshow, to
> >> see what's going on).
> >>
> >> It first want to upgrade pkg from 1.5.1 to 1.10.0_2 but that doesn't
> >> work:
> >>
> >> [1/1] Upgrading pkg from 1.5.1 to 1.10.0_2...
> >> [1/1] Extracting pkg-1.10.0_2: 100%
> >> /usr/local/lib/libpkg.so.4: Undefined symbol "openat"
> >>
> >> Anything I try to do with pkg now gives me this error-message.
> >>
> >> /var/log/messages says: pkg: pkg upgraded: 1.5.1 -> 1.10.0_2
> >>
> >> How do I proceed from here (without upgrading everything, please)?
> >
> > Have you tried using the "pkg-static" command? It's the same as pkg, but
> > statically linked, should sidestep your issue.
> 
> The old pkg-static might work, but it would wreck his system because he 
> uses a repo with an ABI unsupported by his base + kernel system. He is 
> lucky he immediately triggered the incompatibility.

Will pkg-static install an old version of pkg?

One option might be to check if the old version of pkg is in
/var/cache/pkg, then maybe pkg-static could be used to 
reinstall the old version.

Alternatively, if ports are installed, one could rebuild the
old version of pkg from the port. Or even download the 
appropriate old ports tree to be able to build the old pkg.
That would also enable building an old(?) version of trafshow.

But I agree with others that the right answer is to upgrade the
system. Running old systems facing the Internet is a bad idea.


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

Re: Best way to cause synth to ignore rebuilding of a port??

[Chris H]

On Wed, 8 Mar 2017 16:34:45 + Matthew Seaman  wrote

> On 2017/03/08 16:04, Bob Willcox wrote:
> > Note that I haven't tried ver 52 of firefox, but from what I've read it
> > sounds like all plugins/addons other than flash are no longer supported.
I think the answer to your question can be answered by using pkg(8)'s
lock option. As memory serves; synth honors anything pkg has to offer.

HTH

--Chris
> 
> Make that: all *NPAPI* plugins other than Flash are now unsupported.
> That's stuff like the Java plugin or the OpenH264 Video Codec from Cisco
> (which I seem to have installed and can no-longer remember why.  Some
> sort of video conference thing a long time ago).
> 
> Ordinary add-ons like AddBlock-Plus or NoScript don't use NPAPI and so
> are not affected by this move.
> 
> I've been on version 52 on my Mac desktop for a while with no noticeable
> problems (well, none beyond what you normally got with FF in earlier
> versions.)
> 
> Cheers,
> 
> Matthew


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

Re: manpath change for ports ?

[Tijl Coosemans]

On Fri, 10 Mar 2017 08:38:30 -0800 Steve Kargl 
 wrote:
> On Fri, Mar 10, 2017 at 05:03:08PM +0100, Tijl Coosemans wrote:
>> On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav  wrote:  
>>> John Baldwin  writes:  
 I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
 so long as our default MANPATH included both if that means applying fewer
 patches to ports.
>>> 
>>> The default MANPATH is constructed dynamically from PATH:
>>> 
>>>  1.   From each component of the user's PATH for the first of:
>>>   -   pathname/man
>>>   -   pathname/MAN
>>>   -   If pathname ends with /bin: pathname/../man
>>>   Note: Special logic exists to make /bin and /usr/bin look in
>>>   /usr/share/man for manual files.
>>> 
>>> If we change this to:
>>> 
>>>  1.   From each component of the user's PATH for the first of:
>>>   -   pathname/man
>>>   -   pathname/MAN
>>>   -   If pathname ends with /bin or /sbin: pathname/../man and
>>>   pathname/../share/man
>>> 
>>> we wouldn't need any "special logic", but I really don't like the idea
>>> of having different ports installing man pages in different locations.  
>> 
>> I grepped the ports tree and found nearly 5700 ports.  That's a lot to
>> change all at once but it may be doable.  It depends on how much fallout
>> there is in the exp-run.  
> 
> ln -s /usr/local/share/man /usr/local/man
> 
> should cause the manpages to land where you want.  Then port
> maintainers can sweep ports/ to allow for the removal of symlink. 

Yeah, I had to deal with installing through symlinks in the Linux ports
because bin, lib and sbin have become symlinks there now.  There are
complications with that.  FreeBSD releases have a bug in libarchive that
causes problems when extracting hardlinks through symlinks.  Recent
versions of pkg have workarounds for that but not everybody runs it yet.
Before you can create the symlink you have to move the existing
directory, but what if the new directory already exists?  Will you
overwrite files?  Commands like pkg-which and pkg-delete only work
through the symlink because the new paths are not in the pkg database.
Packages that don't know about the symlink may try to create it as a
directory or remove it as a directory on uninstall.  I ended up avoiding
it at all costs in the Linux ports by moving files around in the staging
area if necessary.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Steve Kargl]

On Fri, Mar 10, 2017 at 05:03:08PM +0100, Tijl Coosemans wrote:
> On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav  wrote:
> > John Baldwin  writes:
> >> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
> >> so long as our default MANPATH included both if that means applying fewer
> >> patches to ports.  
> > 
> > The default MANPATH is constructed dynamically from PATH:
> > 
> >  1.   From each component of the user's PATH for the first of:
> >   -   pathname/man
> >   -   pathname/MAN
> >   -   If pathname ends with /bin: pathname/../man
> >   Note: Special logic exists to make /bin and /usr/bin look in
> >   /usr/share/man for manual files.
> > 
> > If we change this to:
> > 
> >  1.   From each component of the user's PATH for the first of:
> >   -   pathname/man
> >   -   pathname/MAN
> >   -   If pathname ends with /bin or /sbin: pathname/../man and
> >   pathname/../share/man
> > 
> > we wouldn't need any "special logic", but I really don't like the idea
> > of having different ports installing man pages in different locations.
> 
> I grepped the ports tree and found nearly 5700 ports.  That's a lot to
> change all at once but it may be doable.  It depends on how much fallout
> there is in the exp-run.

ln -s /usr/local/share/man /usr/local/man

should cause the manpages to land where you want.  Then port
maintainers can sweep ports/ to allow for the removal of symlink. 

On a side note, it is unfortunate that one cannot set the
environmental variable MANPATH as documented without either
a mysterious vanishing of man pages or an idiotic warning
appear with each invocation of man, apropos, ... 

-- 
Steve
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Tue, 7 Mar 2017 00:56:10 +0100 Baptiste Daroussin  wrote:
> My proposal is to add to the manpath /usr/local/share/man in default
> man(1) command in FreeBSD 12 (MFCed to 11-STABLE)
> 
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that
> for those two, what do you think?

I don't think we can expect users to install the latest errata or to
run the latest head or stable, so a port would be needed.  Could the
pkg port be used for this?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Chicken/egg problem with pkg

[Jan Bramkamp]

On 10/03/2017 17:04, Kurt Jaeger wrote:

Hi!


I have an old web server (10.1-RELEASE-p9) which is running for years


I had one with 9.3 something, and upgrading it from the pkg repo
took not a huge amount of time, yesterday evening...

So maybe upgrading is a good thing, if not too many fancy things
are active.


You can use pkg upgrade -F to prefetch the packages if you connection 
and/or mirror is slow.

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

Re: Chicken/egg problem with pkg

[Kurt Jaeger]

Hi!

> I have an old web server (10.1-RELEASE-p9) which is running for years

I had one with 9.3 something, and upgrading it from the pkg repo
took not a huge amount of time, yesterday evening...

So maybe upgrading is a good thing, if not too many fancy things
are active.

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

Re: manpath change for ports ?

[Tijl Coosemans]

On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav  wrote:
> John Baldwin  writes:
>> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
>> so long as our default MANPATH included both if that means applying fewer
>> patches to ports.  
> 
> The default MANPATH is constructed dynamically from PATH:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin: pathname/../man
>   Note: Special logic exists to make /bin and /usr/bin look in
>   /usr/share/man for manual files.
> 
> If we change this to:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin or /sbin: pathname/../man and
>   pathname/../share/man
> 
> we wouldn't need any "special logic", but I really don't like the idea
> of having different ports installing man pages in different locations.

I grepped the ports tree and found nearly 5700 ports.  That's a lot to
change all at once but it may be doable.  It depends on how much fallout
there is in the exp-run.

Ports are installed into a staging area now where files can be moved to
another location.  So a post-install make target could be added that
moves the man pages to share/man if necessary (and prints a warning to
maintainers in that case).  Then all pkg-plist and PLIST_FILES need to
be modified (with sed) and PORTREVISION needs to be bumped (also
scripted).

The same could be done to move info and pkgconfig files.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Chicken/egg problem with pkg

[Guido Falsi]

On 03/10/17 14:57, Jan Bramkamp wrote:
> On 10/03/2017 14:47, Guido Falsi wrote:
>> On 03/10/17 14:26, Hans de Hartog wrote:
>>> I have an old web server (10.1-RELEASE-p9) which is running for years
>>>
>>> without any upgrades. Now I want to install a simple port (trafshow, to
>>>
>>> see what's going on).
>>>
>>> It first want to upgrade pkg from 1.5.1 to 1.10.0_2 but that doesn't
>>> work:
>>>
>>> [1/1] Upgrading pkg from 1.5.1 to 1.10.0_2...
>>> [1/1] Extracting pkg-1.10.0_2: 100%
>>> /usr/local/lib/libpkg.so.4: Undefined symbol "openat"
>>>
>>> Anything I try to do with pkg now gives me this error-message.
>>>
>>> /var/log/messages says: pkg: pkg upgraded: 1.5.1 -> 1.10.0_2
>>>
>>> How do I proceed from here (without upgrading everything, please)?
>>>
>>
>> Have you tried using the "pkg-static" command? It's the same as pkg, but
>> statically linked, should sidestep your issue.
> 
> The old pkg-static might work, but it would wreck his system because he
> uses a repo with an ABI unsupported by his base + kernel system. He is
> lucky he immediately triggered the incompatibility.

You are right. I interpreted the OP email as in that he was going to
upgrade the Base OS too. He should do that first thing, then upgrade the
ports, most probably by forcing them all.

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

Re: Chicken/egg problem with pkg

[Jan Bramkamp]

On 10/03/2017 15:08, Konstantin Belousov wrote:

On Fri, Mar 10, 2017 at 02:55:13PM +0100, Jan Bramkamp wrote:

Among other
things FreeBSD 10.3 added a bunch of new *at() system calls like openat.
These *at() system calls are useful inside (capsicum) sandboxes. Your
old 10.1 kernel lacks those systems calls and your old 10.1 libc lacks
the stubs to call them anyways. It is this missing stub that causes the
new libpkg.so to fail to link.


Although (removed) rest of your mail is mostly accurate, the cited part
is explicitely false. The openat(2) syscall and friends exist even in
FreeBSD 8.x.  What has changed in 10.2->10.3 is that the version for
openat symbol in libc has to be bumped due to some issue with libthr. As
result, newer binaries require a symbol version which does not exist in
older libc.


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

Re: Chicken/egg problem with pkg

[Konstantin Belousov]

On Fri, Mar 10, 2017 at 02:55:13PM +0100, Jan Bramkamp wrote:
> Among other 
> things FreeBSD 10.3 added a bunch of new *at() system calls like openat. 
> These *at() system calls are useful inside (capsicum) sandboxes. Your 
> old 10.1 kernel lacks those systems calls and your old 10.1 libc lacks 
> the stubs to call them anyways. It is this missing stub that causes the 
> new libpkg.so to fail to link.

Although (removed) rest of your mail is mostly accurate, the cited part
is explicitely false. The openat(2) syscall and friends exist even in
FreeBSD 8.x.  What has changed in 10.2->10.3 is that the version for
openat symbol in libc has to be bumped due to some issue with libthr. As
result, newer binaries require a symbol version which does not exist in
older libc.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Chicken/egg problem with pkg

[Jan Bramkamp]

On 10/03/2017 14:47, Guido Falsi wrote:

On 03/10/17 14:26, Hans de Hartog wrote:

I have an old web server (10.1-RELEASE-p9) which is running for years

without any upgrades. Now I want to install a simple port (trafshow, to

see what's going on).

It first want to upgrade pkg from 1.5.1 to 1.10.0_2 but that doesn't
work:

[1/1] Upgrading pkg from 1.5.1 to 1.10.0_2...
[1/1] Extracting pkg-1.10.0_2: 100%
/usr/local/lib/libpkg.so.4: Undefined symbol "openat"

Anything I try to do with pkg now gives me this error-message.

/var/log/messages says: pkg: pkg upgraded: 1.5.1 -> 1.10.0_2

How do I proceed from here (without upgrading everything, please)?



Have you tried using the "pkg-static" command? It's the same as pkg, but
statically linked, should sidestep your issue.


The old pkg-static might work, but it would wreck his system because he 
uses a repo with an ABI unsupported by his base + kernel system. He is 
lucky he immediately triggered the incompatibility.

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

Re: Chicken/egg problem with pkg

[Jan Bramkamp]

On 10/03/2017 14:26, Hans de Hartog wrote:

I have an old web server (10.1-RELEASE-p9) which is running for years

without any upgrades. Now I want to install a simple port (trafshow, to

see what's going on).

It first want to upgrade pkg from 1.5.1 to 1.10.0_2 but that doesn't work:

[1/1] Upgrading pkg from 1.5.1 to 1.10.0_2...
[1/1] Extracting pkg-1.10.0_2: 100%
/usr/local/lib/libpkg.so.4: Undefined symbol "openat"

Anything I try to do with pkg now gives me this error-message.

/var/log/messages says: pkg: pkg upgraded: 1.5.1 -> 1.10.0_2

How do I proceed from here (without upgrading everything, please)?


You dug yourself a deep hole by letting your system fall that far 
behind. Both FreeBSD 10.1 and 10.2 are EoL since 2016-12-31 
(https://www.freebsd.org/security/unsupported.html). While FreeBSD is 
backward compatible (e.g. you can run binaries for 10.1 on 10.3) it 
isn't forward compatible (e.g. you can't run FreeBSD 10.3 binaries on 10.1).


In your case the problem is that the official package build jails run 
the oldest supported minor release inside each major release. After 
2016-12-31 the build jails migrated from 10.1 to 10.3. Among other 
things FreeBSD 10.3 added a bunch of new *at() system calls like openat. 
These *at() system calls are useful inside (capsicum) sandboxes. Your 
old 10.1 kernel lacks those systems calls and your old 10.1 libc lacks 
the stubs to call them anyways. It is this missing stub that causes the 
new libpkg.so to fail to link.


Running unpatched networked systems is a bad habit in most cases, but it 
is reckless to run an unpatched webserver, because webservers offer a 
large attack surface to the network.


Your simplest way forward is to update to the latest patchlevel and than 
migrate to a supported release (at least 10.3 as of writing). Afterward 
you can upgrade your packages from the default repos.


Upgrading to a newer minor release of the same major release is fast and 
painless with freebsd-update. Upgrading to the next major release 
shouldn't cause any problems, but you have to reinstall all packages. 
This was a major annoyance before pkgng, but these days changing the 
repo ABI and a single `pkg upgrade` does that in a few minutes.


Or you write this system off as probably compromised and rebuild it from 
scratch ;-).

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

Re: Chicken/egg problem with pkg

[Guido Falsi]

On 03/10/17 14:26, Hans de Hartog wrote:

I have an old web server (10.1-RELEASE-p9) which is running for years

without any upgrades. Now I want to install a simple port (trafshow, to

see what's going on).

It first want to upgrade pkg from 1.5.1 to 1.10.0_2 but that doesn't work:

[1/1] Upgrading pkg from 1.5.1 to 1.10.0_2...
[1/1] Extracting pkg-1.10.0_2: 100%
/usr/local/lib/libpkg.so.4: Undefined symbol "openat"

Anything I try to do with pkg now gives me this error-message.

/var/log/messages says: pkg: pkg upgraded: 1.5.1 -> 1.10.0_2

How do I proceed from here (without upgrading everything, please)?



Have you tried using the "pkg-static" command? It's the same as pkg, but 
statically linked, should sidestep your issue.


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

Chicken/egg problem with pkg

[Hans de Hartog]

I have an old web server (10.1-RELEASE-p9) which is running for years

without any upgrades. Now I want to install a simple port (trafshow, to

see what's going on).

It first want to upgrade pkg from 1.5.1 to 1.10.0_2 but that doesn't work:

[1/1] Upgrading pkg from 1.5.1 to 1.10.0_2...
[1/1] Extracting pkg-1.10.0_2: 100%
/usr/local/lib/libpkg.so.4: Undefined symbol "openat"

Anything I try to do with pkg now gives me this error-message.

/var/log/messages says: pkg: pkg upgraded: 1.5.1 -> 1.10.0_2

How do I proceed from here (without upgrading everything, please)?

Thanks in advance,

Hans

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

INDEX now builds successfully on 10.x

[Ports Index build]

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

Re: manpath change for ports ?

[Tijl Coosemans]

On Thu, 9 Mar 2017 19:43:05 -0600 Benjamin Kaduk  wrote:
> On Thu, Mar 09, 2017 at 12:35:32PM +0100, Tijl Coosemans wrote:
>> Note that -rpath /usr/local/lib isn't added by gcc but by libtool
>> because it assumes rtld will not search that directory automatically.
>> If you run './configure CC=gcc --prefix=/usr && make check' the tests
>> should succeed (without --enable-new-dtags) because -rpath isn't used
>> then.  
> 
> Sounds like a bug in the libtool packaging, then?

Rtld only searches /lib and /usr/lib.  It also searches the ldconfig
hints file and /usr/local/lib is there by default (ldconfig_paths in
/etc/defaults/rc.conf), but users are allowed to change that, for
instance when they install ports in another location than /usr/local.

Arguably, because our default compiler links with --enable-new-dtags,
gcc should as well, but because of the different run-time semantics of
DT_RPATH and DT_RUNPATH this is a potential minefield.  Upstream
binutils changed the default in ld once and this was quickly reverted.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Dag-Erling Smørgrav]

John Baldwin  writes:
> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
> so long as our default MANPATH included both if that means applying fewer
> patches to ports.

The default MANPATH is constructed dynamically from PATH:

 1.   From each component of the user's PATH for the first of:
  -   pathname/man
  -   pathname/MAN
  -   If pathname ends with /bin: pathname/../man
  Note: Special logic exists to make /bin and /usr/bin look in
  /usr/share/man for manual files.

If we change this to:

 1.   From each component of the user's PATH for the first of:
  -   pathname/man
  -   pathname/MAN
  -   If pathname ends with /bin or /sbin: pathname/../man and
  pathname/../share/man

we wouldn't need any "special logic", but I really don't like the idea
of having different ports installing man pages in different locations.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

INDEX build failed for 10.x

[Ports Index build]

INDEX build failed with errors:
Generating INDEX-10 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---
--- describe.astro ---
--- describe.audio ---
--- describe.benchmarks ---
--- describe.biology ---
--- describe.cad ---
--- describe.chinese ---
--- describe.comms ---
--- describe.converters ---
--- describe.databases ---
--- describe.deskutils ---
--- describe.devel ---
--- describe.dns ---
--- describe.editors ---
--- describe.emulators ---
--- describe.finance ---
--- describe.french ---
--- describe.ftp ---
[...]
--- describe.print ---
--- describe.russian ---
--- describe.science ---
--- describe.security ---
--- describe.shells ---
--- describe.sysutils ---
--- describe.textproc ---
--- describe.ukrainian ---
--- describe.vietnamese ---
--- describe.www ---
--- describe.x11 ---
--- describe.x11-clocks ---
--- describe.x11-drivers ---
--- describe.x11-fm ---
--- describe.x11-fonts ---
--- describe.x11-servers ---
--- describe.x11-themes ---
--- describe.x11-toolkits ---
--- describe.x11-wm ---
 Done.
make_index: /home/indexbuild/tindex/ports/math/vtk6: no entry for 
/home/indexbuild/tindex/ports/devel/libc++

Committers on the hook:
 bjk stephen 

Most recent SVN update was:
Updating '.':
At revision 435820.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"