Gary Jennejohn 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.
___
freebsd-current@freebsd.org mailing li
On Thu, 24 Jun 2010 09:54:45 -0700
Ted Faber 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-ba
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-exec
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/loc
* Mike Meyer 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
WWW: http://80386.nl/
pgpzwgJfIGCWZ.pgp
Description: PGP s
* Andrew Reilly 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 wheel
On Thu, Jun 24, 2010 at 10:45 AM, Alex Dupre 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:
> http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?
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:21 AM, Andrew Reilly 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-
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 ->
Andriy Gapon 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 switch to .o on
On Thu, Jun 24, 2010 at 8:23 AM, Gary Jennejohn
wrote:
> On Wed, 23 Jun 2010 18:15:09 -0700
> Ted Faber 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 ha
On Thu, 24 Jun 2010 10:30:26 +0200
Alban Hertroys wrote:
> On 24 Jun 2010, at 9:23, Gary Jennejohn wrote:
>
> > On Wed, 23 Jun 2010 18:15:09 -0700
> > Ted Faber wrote:
> >
> >> (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
> >> commands from cupsd, though it's evidently a
On 24 Jun 2010, at 9:23, Gary Jennejohn wrote:
> On Wed, 23 Jun 2010 18:15:09 -0700
> Ted Faber 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 th
On Wed, 23 Jun 2010 18:15:09 -0700
Ted Faber 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 stuff:
in
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
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 linke
on 23/06/2010 18:03 Ryan Stone said the following:
> On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon 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 use
On 06/23/2010 10:55, Hans Petter Selasky wrote:
Hi,
Not unless there is a bug in my module. I'm a little bit busy right now,
though I think that other modules like "fuse.ko" might be affected aswell.
Could you try to make a cuse4bsd build on a stock 8-stable and compare the
resulting cuse4bsd.
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon 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 find the sectio
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)
On Wednesday 23 June 2010 16:43:31 Kris Moore wrote:
> On 06/23/2010 02:52, Hans Petter Selasky wrote:
> > 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 06/23/2010 02:52, Hans Petter Selasky wrote:
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 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 af
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 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 w
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
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-
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.
>
>
>
> I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port
> m
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
30 matches
Mail list logo
