Hi people,
I can't use my maxtor basic 640gb external harddrive on Freebsd amd64 running
7.0 because when I try to load fusefs with this command, kldload
/usr/local/modules/fuse.ko I get the following error:
kldload: can't load /usr/local/modules/fuse.ko: Exec format error
Adding
On 12/3/08, Dino Vliet [EMAIL PROTECTED] wrote:
Hi people,
I can't use my maxtor basic 640gb external harddrive on Freebsd amd64
running 7.0 because when I try to load fusefs with this command, kldload
/usr/local/modules/fuse.ko I get the following error:
kldload: can't load
On 12/3/08, Scot Hetzel [EMAIL PROTECTED] wrote:
On 12/3/08, Dino Vliet [EMAIL PROTECTED] wrote:
Hi people,
I can't use my maxtor basic 640gb external harddrive on Freebsd amd64
running 7.0 because when I try to load fusefs with this command, kldload
/usr/local/modules/fuse.ko I get
* Wesley Shields ([EMAIL PROTECTED]) wrote:
I like you're idea here, but unfortunately directory names are not
unique. For example there is japanese/xchat and irc/xchat. This means
you'll have to go with the dual-level layout.
As it was suggested, there's UNIQUENAME, but I'd prefer
* G. Paul Ziemba ([EMAIL PROTECTED]) wrote:
I, too, am happy with the idea of an administrator-specifiable parallel
tree that would have the same structure as /usr/ports. So this approach
involves, for the administrator (I am restating Dmitry's comments):
1. in /etc/make.conf, define
On Wed, Dec 03, 2008 at 04:12:34PM +0300, Dmitry Marakasov wrote:
* G. Paul Ziemba ([EMAIL PROTECTED]) wrote:
I, too, am happy with the idea of an administrator-specifiable parallel
tree that would have the same structure as /usr/ports. So this approach
involves, for the administrator (I
RW wrote:
On Tue, 2 Dec 2008 21:07:43 +0300
Dmitry Marakasov [EMAIL PROTECTED] wrote:
I am not aware of any mechanism for this. But I agree that it's
really needed. Before (in cvsup times) we could just place patches
under files/ and be happy, but now when more people use portsnap
we need
--- On Wed, 12/3/08, Scot Hetzel [EMAIL PROTECTED] wrote:
From: Scot Hetzel [EMAIL PROTECTED]
Subject: Re: kldload: can't load /usr/local/modules/fuse.ko: Exec format error
fusefs-ntfs-1.253
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], freebsd-ports@freebsd.org
Date:
On Wed, Dec 03, 2008 at 02:10:40AM +, G. Paul Ziemba wrote:
[EMAIL PROTECTED] (Scott Lambert) writes:
How about something like WRKDIRPREFIX?
Presumably the logic for dealing with that structure is already in
the system. Maybe you could have USE_LOCAL_PATCHES boolean which
uses
Hello,
I have been in a perpetual multi-year struggle to sort out package
building in a way which is practical for me. For the past half year or
so I have ended up using a hacked together shell script which does
approximately what I need, which is:
To build deterministically as a function of
consistently. tinderbox I presume works, being used for official bulk
Scratch the bit about tindexbox; brain lapse.
But I also wanted to clarify that I specifically do not want to
perform in-place upgrading from source, because the intent is to have
a minimal time window during which the system
Hello all,
I have handbrake building successfully on FreeBSD 7 32bit and it seems
to run fine. I would appreciate it if anyone interested could test this
out before I file a PR to have it committed to the tree as this is my
first significant port update.
The distfiles can be found at [1] and
Peter Schuller wrote:
consistently. tinderbox I presume works, being used for official bulk
Scratch the bit about tindexbox; brain lapse.
But I also wanted to clarify that I specifically do not want to
perform in-place upgrading from source, because the intent is to have
a minimal time window
--- On Wed, 12/3/08, Scot Hetzel [EMAIL PROTECTED] wrote:
From: Scot Hetzel [EMAIL PROTECTED]
Subject: Re: kldload: can't load /usr/local/modules/fuse.ko: Exec format error
fusefs-ntfs-1.253
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], freebsd-ports@freebsd.org
Date:
Hallo Peter Schuller,
I have been in a perpetual multi-year struggle to sort out package
building in a way which is practical for me. For the past half year or
so I have ended up using a hacked together shell script which does
approximately what I need, which is:
To build
On the donor system:
1. portupgrade -a
2. for a in `pkg_info -ao | awk '{ print $1 }'` ; do pkg_create -b $a ; done
3. Push packages up to NFS'ed ports tree host's /usr/ports/packages
On the remaining systems, it's just a matter of running portupgrade -aPP.
Thanks! It helps to know what
Peter Schuller wrote:
Hello,
I have been in a perpetual multi-year struggle to sort out package
building in a way which is practical for me.
One thing I'm confused about here, what are your goals? You don't
mention why you need to build the packages. The answer to this might
inform the rest
It may be not the silver bullet.
Please take a look at:
http://www.dinoex.net/training/package2.html
Thanks! I will.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]'
Key retrieval: Send an E-Mail to [EMAIL PROTECTED]
E-Mail: [EMAIL PROTECTED] Web:
On Tue, 2 Dec 2008 22:03:08 -0500
Jim Trigg [EMAIL PROTECTED] wrote:
On Tue, Dec 2, 2008 at 9:08 PM, RW [EMAIL PROTECTED] wrote:
directory is deleted. I wonder why, if an update can decompress
over the top of a port, an extract need to delete it first. I
can't think of any good reason
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically notify users of ports
that are marked as broken in their Makefiles. In many cases
these ports are failing to compile on some subset of the FreeBSD
build environments. The most common
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically notify users of ports
that are marked as broken in their Makefiles. In many cases
these ports are failing to compile on some subset of the FreeBSD
build environments. The most common
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically schedule removal of ports
that have been judged to have outlived their usefulness. Often,
this is due to a better alternative having become available and/or
the cessation of development on
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically schedule removal of ports
that have been judged to have outlived their usefulness. Often,
this is due to a better alternative having become available and/or
the cessation of development on
As part of an ongoing effort to reduce the number of problems in the
FreeBSD ports system, we periodically notify users about
ports that are marked as forbidden in their Makefiles. Often,
these ports are so marked due to security concerns, such as known
exploits.
An overview of each port,
As part of an ongoing effort to reduce the number of problems in the
FreeBSD ports system, we periodically notify users about
ports that are marked as forbidden in their Makefiles. Often,
these ports are so marked due to security concerns, such as known
exploits.
An overview of each port,
Hi
I wondering what's the difference between these two ports?
Thanks
/Leslie
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
26 matches
Mail list logo
