I'm planning to install FreeBSD alongside a whole range of Windows
builds for testing. In 8.x it's possible to tell the installer not to
bother updating the MBR so you can use something like EasyBCD to boot it
via the Windows bootloader instead. Is it still possible on 9.0-RC2
using bsdinstall
It sounds to me like the right thing to do is to fix emacs' configuration
so it always uses the base system ncurses whether or not the package
version is there. Right?
maybe/maybe not. It depends on what emacs needs - whether it only works
with either its own termcap module or a conventional
On Mon, Oct 24, 2011 at 08:32:30AM +0200, John R. Levine wrote:
It sounds to me like the right thing to do is to fix emacs' configuration
so it always uses the base system ncurses whether or not the package
version is there. Right?
maybe/maybe not. It depends on what emacs needs - whether
There's enough in the emacs sources to make it pretty clear that a
failure to have emacs find the termcap functions would be a problem
in the emacs port - emacs prefers -lncurses to -ltermcap unless it's
being overridden.
Well, OK. Now we know that on FreeBSD that doesn't work, since there's
John R. Levine jo...@iecc.com writes:
On 23/10/2011 09:03, John R. Levine wrote:
checking for tparm in -lncurses... no
but that's not correct. libncurses should certainly contain that
symbol. I get a 'yes' there on my stable/8 machine. As -lncurses is
part of your LDFLAGS ... hmmm...
Yes, that's just what I did, and I got an emacs that was linked against
the port version of ncurses. It worked fine. I then deleted the
ncurses port to make sure emacs *really* was using ncurses from the
port, and, indeed, emacs stopped working.
That is bizarre. I got the linker errors you
Yes, that's just what I did, and I got an emacs that was linked against
the port version of ncurses. It worked fine.
I deinstalled and rebuilt and reinstalled the ncurses port, and now emacs
builds fine. Gaaah. I think the former version was the package that gets
installed with 8.2, but
anything useful that might help you to fix the problem. We'd need to see
* Your choice of options for the port (ie. 'make showconfig' output)
* A complete build log showing the problem occurring. (ie 'make
clean build' output)
* The config.log from $WRKSRC showing what autoconf
On 23/10/2011 08:11, John Levine wrote:
anything useful that might help you to fix the problem. We'd need to see
* Your choice of options for the port (ie. 'make showconfig' output)
* A complete build log showing the problem occurring. (ie 'make
clean build' output)
* The
On 23/10/2011 09:03, John R. Levine wrote:
checking for tparm in -lncurses... no
but that's not correct. libncurses should certainly contain that
symbol. I get a 'yes' there on my stable/8 machine. As -lncurses is
part of your LDFLAGS ... hmmm... do you have libncurses on your system
John R. Levine jo...@iecc.com writes:
On 23/10/2011 09:03, John R. Levine wrote:
checking for tparm in -lncurses... no
but that's not correct. libncurses should certainly contain that
symbol. I get a 'yes' there on my stable/8 machine. As -lncurses is
part of your LDFLAGS ... hmmm...
On 23/10/2011 09:03, John R. Levine wrote:
checking for tparm in -lncurses... no
but that's not correct. libncurses should certainly contain that
symbol. I get a 'yes' there on my stable/8 machine. As -lncurses is
part of your LDFLAGS ... hmmm... do you have libncurses on your system
On Sun, Oct 23, 2011 at 06:03:10PM +0200, John R. Levine wrote:
On 23/10/2011 09:03, John R. Levine wrote:
checking for tparm in -lncurses... no
but that's not correct. libncurses should certainly contain that
symbol. I get a 'yes' there on my stable/8 machine. As -lncurses is
part of
ncurses is already in the base system - with different options. ...
Did you try installing the ncurses port and then rebuilding emacs? For
some reason the library in the ncurses port doesn't define the termcap
routines, leading to the problem.
Whether or not the termcap routines are
On Sun, Oct 23, 2011 at 11:23:36PM -, John Levine wrote:
ncurses is already in the base system - with different options. ...
Did you try installing the ncurses port and then rebuilding emacs? For
some reason the library in the ncurses port doesn't define the termcap
routines,
For at least several weeks, attempts to rebuild emacs from ports fails
with an odd linker error saying it can't find symbols in the termcap
library. I poked around a little, the makefile does include the
appropriate library and adding it again at the end of the line in
the makefile didn't help.
On 22/10/2011 17:24, John Levine wrote:
For at least several weeks, attempts to rebuild emacs from ports fails
with an odd linker error saying it can't find symbols in the termcap
library. I poked around a little, the makefile does include the
appropriate library and adding it again at the
I have had numerous problems after updating to the latest KDE
version. For starters, I lost my desktop and only had a blank (black)
screen when starting up. I did manage to figure out how to correct
that, but numerous other problems exist.
For starters:
1) The (ALT)+(TAB) key no longer works
Carmel schreef:
I have had numerous problems after updating to the latest KDE
version. For starters, I lost my desktop and only had a blank (black)
screen when starting up. I did manage to figure out how to correct
that, but numerous other problems exist.
For starters:
1) The (ALT)+(TAB) key
Johan Hendriks schreef:
So you could say ortp has merged into ortp.
should read So you could say ortp has merged into linphone
Sorry for any confusion caused.
regards
Johan
___
freebsd-questions@freebsd.org mailing list
On 3 October 2011 10:28, Michael Powell nightre...@hotmail.com wrote:
wayne mitchell wrote:
hey
just tried to update a system using 'csup'
current system is: 8.1 RELEASE on a amd machine (amd64 GENERIC kernel)
tried downloading the CURRENT branch ( tag=. )
when running make buildworld
hey
just tried to update a system using 'csup'
current system is: 8.1 RELEASE on a amd machine (amd64 GENERIC kernel)
tried downloading the CURRENT branch ( tag=. )
when running make buildworld
get an exit with error at /usr/lib/libmagic
system gives various warnings about unknown file types and
wayne mitchell wrote:
hey
just tried to update a system using 'csup'
current system is: 8.1 RELEASE on a amd machine (amd64 GENERIC kernel)
tried downloading the CURRENT branch ( tag=. )
when running make buildworld
get an exit with error at /usr/lib/libmagic
system gives various warnings
Dear all,
I have been wondering how I can check current options of a port before I update
it. The port in question (apache22) has a number of options and I would like to
look at the current ones so that I do not install options that I may not need.
I'd appreciate if you can point me to a
Yes, make config shows saved options.
You can find them in the file /var/db/ports/portname/options as well.
On Tue, Aug 30, 2011 at 10:36:16PM -0700, zszal...@ovi.com wrote:
Dear all,
I have been wondering how I can check current options of a port before I
update it. The port in question
On Tue, 30 Aug 2011, zszal...@ovi.com wrote:
I have been wondering how I can check current options of a port before I
update it. The port in question (apache22) has a number of options and I
would like to look at the current ones so that I do not install options
that I may not need. I'd
Kaspars Bankovskis writes:
Yes, make config shows saved options.
For clarity: do this in portgroup/portname.
make showconfig is the read-only alternative.
You can find them in the file /var/db/ports/portname/options as
well.
That works too.
On Wed, Aug 31, 2011 at 8:36 AM, zszal...@ovi.com wrote:
Dear all,
I have been wondering how I can check current options of a port before I
update it. The port in question (apache22) has a number of options and I
would like to look at the current ones so that I do not install options that
.
No updates needed.
Ports tree is already up to date.
=== New version available: gtk-2.24.5_1
=== 537 total installed ports
=== 1 has a new version available
ran
# portmaster -a
Always (yes, always) check /usr/ports/UPDATING before throwing any
automatic
update
Dear folks,
In an effort to keep up to date, I checked updates that are available
and tried to apply them. Encountered a problem with gtk :
/* Commands run */
quadcore# .
Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found.
Fetching snapshot tag from portsnap5.FreeBSD.org... done.
Latest
) check /usr/ports/UPDATING before throwing any
automatic update tool at it. See the 20110730 entry.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd
ports
=== 1 has a new version available
ran
# portmaster -a
Always (yes, always) check /usr/ports/UPDATING before throwing any automatic
update tool at it. See the 20110730 entry.
Yes I see it, but it does not make a difference :(
20110730:
AFFECTS: users of x11-toolkits/gtk20
to date.
=== New version available: gtk-2.24.5_1
=== 537 total installed ports
=== 1 has a new version available
ran
# portmaster -a
Always (yes, always) check /usr/ports/UPDATING before throwing any automatic
update tool at it. See the 20110730 entry.
Yes I see
version available: gtk-2.24.5_1
=== 537 total installed ports
=== 1 has a new version available
ran
# portmaster -a
Always (yes, always) check /usr/ports/UPDATING before throwing any automatic
update tool at it. See the 20110730 entry.
Yes I see it, but it does not make
On Fri, Jul 29, 2011 at 10:29 PM, Antonio Olivares
olivares14...@gmail.com wrote:
@All
I have solved the problem with TeTeX. I had to remove symlinks to
files created by texlive manually and reinstall the ports one at a
time and I am back. Sorry for the noise.
BTW,
I figured out that I
Dear folks,
I have successfully updated most ports, but having problems with mplayer:
/usr/local/live/BasicUsageEnvironment/libBasicUsageEnvironment.a
-L/usr/local/lib -rpath=/usr/lib:/usr/local/lib
-liconv -lncurses -lpng -lz -ljpeg -lungif -lcdda_interface
On Fri, Jul 29, 2011 at 3:55 PM, Antonio Olivares
olivares14...@gmail.com wrote:
Dear folks,
I have successfully updated most ports, but having problems with mplayer:
/usr/local/live/BasicUsageEnvironment/libBasicUsageEnvironment.a
-L/usr/local/lib
@all
I could not get tlgmr to remove texlive
/*** try to removal of texlive */
tricorehome# tlmgr --uninstall
Useless use of log in void context at /usr/local/bin/tlmgr line 536.
Useless use of log in void context at /usr/local/bin/tlmgr line 636.
Useless use of log in void context at
@All
I have solved the problem with TeTeX. I had to remove symlinks to
files created by texlive manually and reinstall the ports one at a
time and I am back. Sorry for the noise.
BTW,
I figured out that I needed /usr/ports/print/latex-pgf/ for the
diffyqs.tar.gz (Differential Equations Book
Can confirm that this problem still exists.
same log as described.
latex-cjk-4.8.2_4
# be compatible with Debian
find: /usr/ports/print/latex-cjk/work/ccmap: No such file or directory
rgrds
Rafal
___
freebsd-questions@freebsd.org mailing list
Hello,
I ran into a problem when updating ports on 8.1-RELEASE (i386).
~/print/latex-cjk doesn't want to build.
=== Patching for latex-cjk-4.8.2_4
=== Applying FreeBSD patches for latex-cjk-4.8.2_4
Ignoring previously applied (or reversed) patch.
1 out of 1 hunks ignored--saving rejects
Hello Fred,
Fred f...@blakemfg.com writes:
I ran into a problem when updating ports on 8.1-RELEASE (i386).
~/print/latex-cjk doesn't want to build.
=== Patching for latex-cjk-4.8.2_4
=== Applying FreeBSD patches for latex-cjk-4.8.2_4
Ignoring previously applied (or reversed) patch.
1 out
no more time to work on it
tonight. I will try again tomorrow.
Best regards,
Fred
On 04/25/11 07:29, Frédéric Perrin wrote:
Hello Fred,
Fredf...@blakemfg.com writes:
I ran into a problem when updating ports on 8.1-RELEASE (i386).
~/print/latex-cjk doesn't want to build.
=== Patching
On 17 March 2011 11:52, Robert Huff roberth...@rcn.com wrote:
Carmel writes:
It is part of the base system. I don't know if it has a true
maintainer. In any case, I would need commit privileges which I
don't and never expect to have and have no desire to acquire..
I do not
On 16 March 2011 19:47, Carmel carmel...@hotmail.com wrote:
On Wed, 16 Mar 2011 11:32:48 -0700
Chuck Swiger cswi...@mac.com articulated:
On Mar 16, 2011, at 11:24 AM, Carmel wrote:
OK, then does that mean that the latest version will be used in the
still not released 9 version of
On Thu, 17 Mar 2011 10:46:44 +
krad kra...@gmail.com articulated:
[snip]
a combination of time and limited resources I guess. If it bugs you
that much why dont you volunteer yourself to maintain it, i'm sure
that if you dont feel competent enough at present, people will help
and mentor
Carmel writes:
It is part of the base system. I don't know if it has a true
maintainer. In any case, I would need commit privileges which I
don't and never expect to have and have no desire to acquire..
I do not believe that is correct; a fair number of people
contribute
I was just wondering about the version of SSH used on FreeBSD.
According to the OpenSSH page:
OpenSSH 5.8/5.8p1 released February 4, 2011 [contains security fix]
Now, according to my system, FreeBSD-8.2, I have this version:
OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010
# openssl
On 16/03/2011 13:38, Carmel wrote:
I was just wondering about the version of SSH used on FreeBSD.
According to the OpenSSH page:
OpenSSH 5.8/5.8p1 released February 4, 2011 [contains security fix]
Now, according to my system, FreeBSD-8.2, I have this version:
OpenSSH_5.4p1
On Wed, 16 Mar 2011 14:35:09 +
Matthew Seaman m.sea...@infracaninophile.co.uk articulated:
On 16/03/2011 13:38, Carmel wrote:
I was just wondering about the version of SSH used on FreeBSD.
According to the OpenSSH page:
OpenSSH 5.8/5.8p1 released February 4, 2011 [contains
On Mar 16, 2011, at 11:24 AM, Carmel wrote:
OK, then does that mean that the latest version will be used in the
still not released 9 version of FreeBSD?
Currently, no-- TRUNK has:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/crypto/openssh/version.h
Revision 1.41: download - view:
On Wed, 16 Mar 2011 11:32:48 -0700
Chuck Swiger cswi...@mac.com articulated:
On Mar 16, 2011, at 11:24 AM, Carmel wrote:
OK, then does that mean that the latest version will be used in the
still not released 9 version of FreeBSD?
Currently, no-- TRUNK has:
argument] [Updating the portsdb format:bdb_btree in /usr/ports ... -
22601 port entries found error] Remove and try again.
[Updating the portsdb format:dbm_hash in /usr/ports ... - 22601 port
entries found .
. done]
Okay. It took 10-15 mins to rebuild.
Then I say portupgrade samba
On 25 February 2011 23:42, Eitan Adler li...@eitanadler.com wrote:
Why is this question even arising? Surely there are other
problems that need to be addressed much more than the ending of a
useful, uncontroversial service by someone who is not familiar with
it?
I am familiar with it. I
) Is it still being offered and supported as a method of updating
FreeBSD systems?
2) If not can the section in the handbook be removed? I have attached
a patch which removes references to CTM from the handbook. Should it
be applied?
3) Probably the most controversial question - but I'll ask
So I have a few questions:
1) Is it still being offered and supported as a method of updating
FreeBSD systems?
As of today, yes -- I have recent deltas in my mailbox. But you could
easily check by subscribing, and looking at:
http://ftp.freebsd.org/pub/FreeBSD/CTM
where the deltas are still
Why is this question even arising? Surely there are other
problems that need to be addressed much more than the ending of a
useful, uncontroversial service by someone who is not familiar with
it?
I am familiar with it. I just happened to notice that the mailing
lists were empty and therefore
On 10 February 2011 08:33, c0re nr1c...@gmail.com wrote:
Hello all!
I've got set of servers that uses NFS mounted /usr/ports. When I use
portupgrade samba on 1st server it says
[/usr/ports/INDEX-7.db: unexpected file type or format -- Invalid
argument] [Updating the portsdb format:bdb_btree
Hello all!
I've got set of servers that uses NFS mounted /usr/ports. When I use
portupgrade samba on 1st server it says
[/usr/ports/INDEX-7.db: unexpected file type or format -- Invalid
argument] [Updating the portsdb format:bdb_btree in /usr/ports ... -
22601 port entries found error] Remove
On Thu, Feb 10, 2011 at 04:33:17PM +0300, c0re wrote:
Hello all!
I've got set of servers that uses NFS mounted /usr/ports. When I use
portupgrade samba on 1st server it says
[/usr/ports/INDEX-7.db: unexpected file type or format -- Invalid
argument] [Updating the portsdb format:bdb_btree
] [Updating the portsdb format:bdb_btree in /usr/ports ... -
22601 port entries found error] Remove and try again.
[Updating the portsdb format:dbm_hash in /usr/ports ... - 22601 port
entries found
.1000.2000.3000.4000.5000.6000.7000.8000
depending on glib.
Someone suggested offlist to install the zlib.h from version 1.2.5, however
that didn't work either.
Am I really the only one having this problem (or using glib :-) )?
help...
Just guessing: have you missed the following entries in
/usr/ports/UPDATING and messed up your
On 18 jan 2011, at 12:45, C. P. Ghost wrote:
Just guessing: have you missed the following entries in
/usr/ports/UPDATING and messed up your environment?
No, I actually performed these. I think it's some very old stuff roaming my
machine. For instance, I have no idea how an older version
On 14 dec 2010, at 09:12, Peter Boosten wrote:
Hi all,
In an attempt to update glib on my 8.0-machine, portupgrade stops with
this message:
gnome-libtool: compile: cc -DHAVE_CONFIG_H -I. -I..
-DG_LOG_DOMAIN=\GLib-GIO\ -I.. -I../glib -I../glib -I.. -I../gmodule
Peter Boosten wrote:
On 14 dec 2010, at 09:12, Peter Boosten wrote:
Hi all,
In an attempt to update glib on my 8.0-machine, portupgrade stops with
this message:
gnome-libtool: compile: cc -DHAVE_CONFIG_H -I. -I..
-DG_LOG_DOMAIN=\GLib-GIO\ -I.. -I../glib -I../glib -I..
On 17 jan 2011, at 19:59, Michael Powell wrote:
don't think I have any magic answer here. Just did a 'make' for this port
on a 8.1-Release box and it built just fine. Only a couple of things come to
mind for me. Take out the -march=pentiumpro from your make.conf, and any
other compiler
On 17 jan 2011, at 21:07, Peter Boosten wrote:
On 17 jan 2011, at 19:59, Michael Powell wrote:
don't think I have any magic answer here. Just did a 'make' for this port
on a 8.1-Release box and it built just fine. Only a couple of things come to
mind for me. Take out the
On 12/27/10, David Southwell da...@vizion2000.net wrote:
On 12/27/10, David Southwell da...@vizion2000.net wrote:
Agreed - but following Doug's commit I can vouch that the PERL_THREADED
hack
was still needed for 7.2 p3 systems on amd64.
It shouldn't be needed. Can you remove this
On 12/27/10, David Southwell da...@vizion2000.net wrote:
On 12/27/10, David Southwell da...@vizion2000.net wrote:
Agreed - but following Doug's commit I can vouch that the PERL_THREADED
hack
was still needed for 7.2 p3 systems on amd64.
It shouldn't be needed. Can you remove this
On 12/27/10, David Southwell da...@vizion2000.net wrote:
On 12/27/10, David Southwell da...@vizion2000.net wrote:
Agreed - but following Doug's commit I can vouch that the
PERL_THREADED hack
was still needed for 7.2 p3 systems on amd64.
It shouldn't be needed. Can you remove
On 12/28/10, David Southwell da...@vizion2000.net wrote:
On 12/27/10, David Southwell da...@vizion2000.net wrote:
On 12/27/10, David Southwell da...@vizion2000.net wrote:
Agreed - but following Doug's commit I can vouch that the
PERL_THREADED
hack
was still needed for 7.2 p3 systems
On 12/27/10, David Southwell da...@vizion2000.net wrote:
On 12/27/10, David Southwell da...@vizion2000.net wrote:
Agreed - but following Doug's commit I can vouch that the
PERL_THREADED hack
was still needed for 7.2 p3 systems on amd64.
It shouldn't be needed. Can you
On 12/28/10 21:55, David Southwell wrote:
On 12/27/10, David Southwell da...@vizion2000.net wrote:
On 12/27/10, David Southwell da...@vizion2000.net wrote:
Agreed - but following Doug's commit I can vouch that the
PERL_THREADED hack
was still needed for 7.2 p3 systems on
PDF format support
│ │ │ │[ ] IMAGEMAGICK_PERL Perl support
│ │
...
Roland
ImageMagick is already installed, so getting something to work is not a
problem. Its updating it...
What concerns me is perl
│ │
...
Roland
ImageMagick is already installed, so getting something to work is not a
problem. Its updating it...
What concerns me is perl-threaded _is_ installed but it can't see it.
Do you have in:
etc/make.conf
PERL_THREADED=true
Perhaps I'm a little daft atm. Either way I want
getting something to work is not a
problem. Its updating it...
What concerns me is perl-threaded _is_ installed but it can't see it.
Do you have in:
etc/make.conf
PERL_THREADED=true
Perhaps I'm a little daft atm. Either way I want to be clear: Are you
saying
support
│ │ │ │[ ] IMAGEMAGICK_PERL Perl support
│ │
...
Roland
ImageMagick is already installed, so getting something to work is not a
problem. Its updating it...
What concerns me is perl-threaded _is_ installed but it can't see it.
Do you have in:
etc/make.conf
What concerns me is perl-threaded _is_ installed but it can't see it.
Do you have in:
etc/make.conf
PERL_THREADED=true
Perhaps I'm a little daft atm. Either way I want to be clear: Are you
saying the define needs to be in the make.conf so that it will build
correctly?
On 12/27/10 22:54, b. f. wrote:
What concerns me is perl-threaded _is_ installed but it can't see it.
Do you have in:
etc/make.conf
PERL_THREADED=true
Perhaps I'm a little daft atm. Either way I want to be clear: Are you
saying the define needs to be in the make.conf so
Well I did offer the info in the OP, albeit pkg_version style. Anyhoo
perl --version outputs:
Yes, but the output of 'perl --version' is what really matters in this
case, because it is used to determine PERL_THREADED for this port, as
you can see in the port Makefile.
This is perl, v5.10.1
What concerns me is perl-threaded _is_ installed but it can't see
it.
Do you have in:
etc/make.conf
PERL_THREADED=true
Perhaps I'm a little daft atm. Either way I want to be clear: Are you
saying the define needs to be in the make.conf so that it will
question. He mentioned that he was updating a lot of
ports, so I'm assuming that it is, but it's something that he should
check.
b.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send
.
That's a good question. He mentioned that he was updating a lot of
ports, so I'm assuming that it is, but it's something that he should
check.
His comments made me wonder :-;
Photographic Artist
Permanent Installations Design
Creative Imagery and Advanced Digital Techniques
High Dynamic Range
I'm running another set of updates, and I can't for the life of me get
rid of this erroneous behaviour.
I run portupgrade and it tells me it can't update ImageMagick because
the Djvu option requires threads, and needs perl, therefore perl needs
to be threaded. So it comes up with an IGNORE
Da Rock writes:
I'm running another set of updates, and I can't for the life of me get
rid of this erroneous behaviour.
I run portupgrade and it tells me it can't update ImageMagick because
the Djvu option requires threads, and needs perl, therefore perl needs
to be threaded. So
On 12/26/10 23:04, Robert Huff wrote:
Da Rock writes:
I'm running another set of updates, and I can't for the life of me get
rid of this erroneous behaviour.
I run portupgrade and it tells me it can't update ImageMagick because
the Djvu option requires threads, and needs perl,
On Sun, Dec 26, 2010 at 11:42:37PM +1000, Da Rock wrote:
Something I'm missing here? A fix would be nice, I should be used to it
though- ImageMagick _always_ has issues for me. I just thought it'd be
nice to get it updated for once- it looked so close :)
I'm getting
Da Rock wrote:
I run portupgrade and it tells me it can't update ImageMagick because
the Djvu option requires threads, and needs perl, therefore perl needs
to be threaded. So it comes up with an IGNORE which is nuts because I
run threaded perl.
...
Any hints guys?
So, as the others wrote, build
Hi all,
Up to this point I have always updated (within a branch), by dropping to single
user mode for everything.
After running cvsup to obtain the new source, is it generally considered OK to
run the maike buildworld in multiuser mode, or, are the dangers to doing this?
Of course, after that
On Sun, 26 Dec 2010 15:11:54 -0500, Grant Peel gp...@thenetnow.com wrote:
After running cvsup to obtain the new source, is it generally
considered OK to run the maike buildworld in multiuser mode,
or, are the dangers to doing this?
Seems to be no problem, as /usr/src/Makefile states this
as
On Sun, Dec 26, 2010 at 03:11:54PM -0500, Grant Peel wrote:
Hi all,
Up to this point I have always updated (within a branch), by dropping to
single user mode for everything.
After running cvsup to obtain the new source, is it generally considered OK
to run the maike buildworld in
buildworld in multiuser mode, or, are
the dangers to doing this?
Personally, I don't bother with single-user mode at all within
release branches. I do everything in multiuser mode and reboot
afterwards at my convenience. I've never had a problem, but I do check
UPDATING just in case there's anything
OK to run the maike buildworld in multiuser mode, or, are
the dangers to doing this?
Personally, I don't bother with single-user mode at all within
release branches. I do everything in multiuser mode and reboot
afterwards at my convenience. I've never had a problem, but I do check
UPDATING just
│ │
│ │[ ] IMAGEMAGICK_PERL Perl support │ │
...
Roland
ImageMagick is already installed, so getting something to work is not a
problem. Its updating it...
What concerns me is perl-threaded _is_ installed but it can't see
Hi all,
In an attempt to update glib on my 8.0-machine, portupgrade stops with
this message:
gnome-libtool: compile: cc -DHAVE_CONFIG_H -I. -I..
-DG_LOG_DOMAIN=\GLib-GIO\ -I.. -I../glib -I../glib -I.. -I../gmodule
-DG_DISABLE_CAST_CHECKS -DG_THREADS_MANDATORY -DG_DISABLE_DEPRECATED
Hi to All! Sorry for my bad English...
PR 152892: Not updating /etc files in installer
FreeBSD-8.2-BETA1-i386-memstick.img
This problem is observed in mode: Custom/All distributions. In mode:
Standard/Developer or Kernel Developer installation completed successfully!
---
http
On 14 dec 2010, at 18:24, Chris Brennan wrote:
t looks like you either specified to include gzip and it cant find the
headers or it's trying to find your gzip headers and can't because they are
in a different location.
gzip is in the base system, and there are, AFAICT, no header files for
On Dec 14, 2010, at 10:22 AM, Peter Boosten wrote:
gzip is in the base system, and there are, AFAICT, no header files for gzip.
I regret to disagree :-), but:
% head -2 /usr/include/zlib.h
/* zlib.h -- interface of the 'zlib' general purpose compression library
version 1.2.3, July 18th, 2005
On 14 dec 2010, at 09:12, Peter Boosten wrote:
Okay, did some source code digging, and I believe the actual error starts here:
gzlibcompressor.c:68: error: expected specifier-qualifier-list before
'gz_header'
which, if I interpret all correctly, means that gz_header is no typedef (or at
On 14 dec 2010, at 19:40, Chuck Swiger wrote:
On Dec 14, 2010, at 10:22 AM, Peter Boosten wrote:
gzip is in the base system, and there are, AFAICT, no header files for gzip.
I regret to disagree :-), but:
% head -2 /usr/include/zlib.h
/* zlib.h -- interface of the 'zlib' general
101 - 200 of 1036 matches
Mail list logo
