Gary Jennejohn gljennj...@googlemail.com wrote:
IMO if you're going to make the binaries in base non-executable
you might just as well delete them.
The chmod is reversible without having to recover the base binaries
from somewhere.
___
On Thu, 24 Jun 2010 09:54:45 -0700
Ted Faber fa...@isi.edu wrote:
On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote:
On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote:
I also have this in make.conf:
CUPS_OVERWRITE_BASE=yes
WITHOUT_LPR=yes
which print/cups-base
On Wed, 23 Jun 2010 18:15:09 -0700
Ted Faber fa...@isi.edu wrote:
(/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
commands from cupsd, though it's evidently a bit of a dangerous idea.)
[trimmed Cc]
I use cupsd and have these settings to get around using the base system
lp
On Thu, 24 Jun 2010 10:30:26 +0200
Alban Hertroys dal...@solfertje.student.utwente.nl wrote:
On 24 Jun 2010, at 9:23, Gary Jennejohn wrote:
On Wed, 23 Jun 2010 18:15:09 -0700
Ted Faber fa...@isi.edu wrote:
(/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
commands
On Thu, Jun 24, 2010 at 8:23 AM, Gary Jennejohn
gljennj...@googlemail.com wrote:
On Wed, 23 Jun 2010 18:15:09 -0700
Ted Faber fa...@isi.edu wrote:
(/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
commands from cupsd, though it's evidently a bit of a dangerous idea.)
Andriy Gapon a...@icyb.net.ua writes:
Yes, you are absolutely correct. This comes from the fact that amd64 uses
simple
objects files (aka .o) as kernel modules and i386 uses full-blow dso.
The obvious question is: since, as I understand, amd64's solution is
superior, what would it take to
On Thu, Jun 24, 2010 at 10:21 AM, Andrew Reilly arei...@bigpond.net.au wrote:
On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote:
in /etc/src.conf - WITHOUT_LPR=yes
and these symbolic links in /usr/bin
lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -
Tom Evans ha scritto:
make delete-old removes old deprecated files, not files that weren't
built because of src.conf options.
I think you are wrong:
http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?rev=1.66
--
Alex Dupre
On Thu, Jun 24, 2010 at 10:45 AM, Alex Dupre a...@freebsd.org wrote:
Tom Evans ha scritto:
make delete-old removes old deprecated files, not files that weren't
built because of src.conf options.
I think you are wrong:
On 24 Jun 2010, at 9:23, Gary Jennejohn wrote:
On Wed, 23 Jun 2010 18:15:09 -0700
Ted Faber fa...@isi.edu wrote:
(/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
commands from cupsd, though it's evidently a bit of a dangerous idea.)
[trimmed Cc]
I use cupsd and have
On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote:
in /etc/src.conf - WITHOUT_LPR=yes
and these symbolic links in /usr/bin
lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -
/usr/local/bin/lp
lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions -
* Andrew Reilly arei...@bigpond.net.au wrote:
On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote:
in /etc/src.conf - WITHOUT_LPR=yes
and these symbolic links in /usr/bin
lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -
/usr/local/bin/lp
lrwxr-xr-x 1 root
* Mike Meyer m...@mired.org wrote:
Maybe it's time for /usr/sbin/lpwrapper, to do the same thing for
print systems?
In my opinion, we should just rename mailwrapper to whateverwrapper and
list the lpr programs in there as well.
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote:
I also have this in make.conf:
CUPS_OVERWRITE_BASE=yes
WITHOUT_LPR=yes
which print/cups-base uses to do make any lpr related binaries in
/usr/bin non-executable, so they are skipped over and the cups
specific ones in /usr/loca/bin
On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote:
On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote:
I also have this in make.conf:
CUPS_OVERWRITE_BASE=yes
WITHOUT_LPR=yes
which print/cups-base uses to do make any lpr related binaries in
/usr/bin non-executable, so
on 23/06/2010 03:38 Hans Petter Selasky said the following:
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw similar behaviour a couple of years ago when I switched from
using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree
On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
on 23/06/2010 03:38 Hans Petter Selasky said the following:
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw similar behaviour a couple of years ago when I switched
on 23/06/2010 09:52 Hans Petter Selasky said the following:
On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
on 23/06/2010 03:38 Hans Petter Selasky said the following:
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw
on 23/06/2010 10:02 Andriy Gapon said the following:
I don't dispute that it is found broken in particular environments, I just
think
that the analysis could be incorrect.
Which also brings the question - what arch(s) is affected?
I tested on amd64.
--
Andriy Gapon
On Wednesday 23 June 2010 09:10:59 Andriy Gapon wrote:
on 23/06/2010 10:02 Andriy Gapon said the following:
I don't dispute that it is found broken in particular environments, I
just think that the analysis could be incorrect.
Ok.
Which also brings the question - what arch(s) is
On Wed, Jun 23, 2010 at 10:10:59AM +0300, Andriy Gapon wrote:
on 23/06/2010 10:02 Andriy Gapon said the following:
I don't dispute that it is found broken in particular environments, I just
think
that the analysis could be incorrect.
Which also brings the question - what arch(s) is
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon a...@icyb.net.ua wrote:
Which also brings the question - what arch(s) is affected?
I tested on amd64.
This should explain it. It looks to me like i386 uses kern/link_elf.c
as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can
only
on 23/06/2010 18:03 Ryan Stone said the following:
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon a...@icyb.net.ua wrote:
Which also brings the question - what arch(s) is affected?
I tested on amd64.
This should explain it. It looks to me like i386 uses kern/link_elf.c
as its linker, while
On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote:
I have to admit that I'm more than a little surprised that this
problem does not affect modules that in src, but maybe that's because
I don't know all that much about FreeBSD's build infrastructure. Are
the src modules being linked
On Wed, Jun 23, 2010 at 08:45:31AM -0700, Ted Faber wrote:
On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote:
I have to admit that I'm more than a little surprised that this
problem does not affect modules that in src, but maybe that's because
I don't know all that much about
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw similar behaviour a couple of years ago when I switched from
using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules.
The problem ended up being a change in the linker
On Wed, Jun 23, 2010 at 02:38:06AM +0200, Hans Petter Selasky wrote:
It appears many kmods are broken because the linker is stripping away static
data declared with the section attribute in FreeBSD 8.1-RC1.
cite
I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port
27 matches
Mail list logo
