Re: no hyperthreading in FreeBSD 9?

[b. f.]

>
> > Hi,
> >
> > I just upgraded from 8-STABLE to 9-STABLE on my dual Xeon (nocona). Now I 
> > have in my boot messages:
> > ...
> > root: /etc/rc.d/sysctl: WARNING: sysctl machdep.hlt_logical_cpus does not 
> > exist.
> > root: /etc/rc.d/sysctl: WARNING: sysctl machdep.hyperthreading_allowed does 
> > not exist.
> > ...
> >
> > So isn't hyperthreading not available anymore in FreeBSD 9?

I'm not sure what you mean by this double negative.  If you mean "Is
hyperthreading still available on FreeBSD?", the answer is yes.  If
you mean "Can hyperthreading still be disabled on FreeBSD?" the answer
is still yes-- only some problematic and redundant means of disabling
it that were present in earlier versions of FreeBSD have been removed.
 (The primary commit is:

http://svnweb.freebsd.org/base?view=revision&revision=222853

.)  You can still use machdep.hyperthreading_allowed, but it is now
only a (loader) tunable, and not also a sysctl, so you can only set it
at boot time (via loader.conf(5), or by using "set ..." on the
loader(8) command line), and you cannot change it on the fly after the
system is up and running.

>
> http://svnweb.freebsd.org/base/release/9.0.0/UPDATING?r1=222852&r2=222853&;
>
> Seems to imply HT is enabled by default and new sysctls are used to take
> logical CPUs offline.
>

Yes -- although that has been the case for a while, and the OIDs are
not all sysctls (some are (loader) tunables or device hints (cf.
device.hints(5)), and they are not new.

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

Re: AHCI driver and static device names

[b. f.]

>  I was getting ready to install the latest FreeBSD 9-RCs image, and I
> found that 9 now defaults to using the ahci driver for sata disks.  This
> would be great if it weren't for the fact that the ahci driver seems to
> do dynamic device name assignment as opposed to the static ones used
> with the older drivers.
>
> I've looked around on google and while this is mentioned (in old
> threads), the "solution" is to use labels or elaborate mapping via hints
> which really aren't solutions imo.  If I have 15 disks in an array, I
> want to be able to label them and know which bay is which device name.
> If I have to replace a drive, I have no idea what dynamic device name it
> will have when it comes time to partition (and label, if I were using
> that).  I could probably figure it out by looking at what disks are used
> on the system, but that's more work that it really should be.
>
> Is there a way to use the ahci driver and get static device names?

cam(4) gives examples of how you can do this by using device hints in
loader.conf(5) or device.hints(5).  Another example:

http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html

You may need the workaround from:

http://svn.freebsd.org/changeset/base/227635

for some problematic BIOS.  I'm not sure if this is what you meant by
"hints which aren't really solutions", but they seem to be a practical
method for fixing device names with ahci(4).

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

Re: "options atapicam" and/or "device ATA_CAM" in kernel config?

[b. f.]

> Now I think I'll try to rebuild the kernel with "options ATA_CAM" and drop
> "device atapicam".
>
> This question needs to be better resolved in time for FreeBSD 9.0-RELEASE.
>
> I cross-post this message to freebsd-curr...@freebsd.org so the developers
> will see it.  FreeBSD users want to be able to burn CDs and DVDs, and since
> SCSI hardware has fallen out of style, I can say very few if any FreeBSD 9.0
> users will have an actual SCSI CD or DVD drive.

The new CAM(4) is not just for SCSI devices (and SCSI, as it is
usually used now, does not deal only with the old parallel SCSI
devices). Despite the fact that most CD and DVD drives will now appear
as cdX devices, and cd(4) is full of references to SCSI, most CD and
DVD drives should be supported.  And while burncd(8) will not work
with the new interface, other software in ports should -- for example,
sysutils/cdrtools and sysutils/cdrtools-devel, as was mentioned
before.

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

Re: "options atapicam" and/or "device ATA_CAM" in kernel config?

[b. f.]

On 11/27/11, Lowell Gilbert  wrote:
> "b. f."  writes:
>
>>> > > What is the role of "options atapicam" and "device ATA_CAM" in kernel
>>> > > config file?
>>>
>>> > > Are they redundant?  Kernel will build with both these options, but
>>> > > will it make things go awry?  Is ATA_CAM deprecated?
>>
>> They are redundant and incompatible.  atapicam is deprecated, and
>> ATA_CAM is the new default on FreeBSD 9 and 10. Unless you have some
>> special requirements, you should use ATA_CAM on recent versions of
>> FreeBSD, because it usually performs better than the old ATA code, and
>> has added functionality.
>
> Ah. My apologies to anyone I confused with my incorrect comments.
>
> I must say that I'm thoroughly disappointed that my searches through the
> official documentation didn't turn up anything related to this. Even the
> Handbook, with extensive practical descriptions of how to use this
> functionality, doesn't mention that its advice is irrelevant to anything
> past 8.x.

The handbook does contain some oblique and scattered references to the
new code, or at least to constructs that are common to both the old
and the new code, but the addition of a brief discussion of the
differences between the new and old ATA code in the handbook -- i.e.,
the kernel and userland components that are now obsolete, and their
replacements -- might be of some help to users.  The primary author of
the new code did add some material to various notes and manpages, but
he has been very busy writing and debugging code, and English is not
his first language, so others will have to supplement his efforts.
Perhaps you could ask for some additions on the freebsd-doc mailing
list?

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

Re: "options atapicam" and/or "device ATA_CAM" in kernel config?

[b. f.]

> > > What is the role of "options atapicam" and "device ATA_CAM" in kernel 
> > > config file?
>
> > > Are they redundant?  Kernel will build with both these options, but will 
> > > it make things go awry?  Is ATA_CAM deprecated?

They are redundant and incompatible.  atapicam is deprecated, and
ATA_CAM is the new default on FreeBSD 9 and 10. Unless you have some
special requirements, you should use ATA_CAM on recent versions of
FreeBSD, because it usually performs better than the old ATA code, and
has added functionality.

>
> Lowell Gilbert  responds:
>
> > As far as I can see, ATA_CAM isn't currently documented.
> > Just ignore it.

This is bad advice, for the reasons mentioned above.  It is briefly
documented in /usr/src/sys/conf/NOTES, and you can find more
information about it in the commit logs of the source repository, and
the mailing lists. For example:

http://svnweb.FreeBSD.org/base?view=revision&revision=195534
...
http://svnweb.FreeBSD.org/base?view=revision&revision=200171
http://svnweb.FreeBSD.org/base?view=revision&revision=220982
http://svnweb.FreeBSD.org/base?view=revision&revision=216088
http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008574.html
http://lists.freebsd.org/pipermail/freebsd-current/2011-April/024110.html
...

>
> So I can say good riddance to ATA_CAM.  According to burncd man page, ATA_CAM 
> is incompatible with burncd, also burncd was deprecated in FreeBSD 9.0.

As I wrote above, you probably do _not_ want to discard ATA_CAM on
recent versions of FreeBSD.  burncd is deprecated because it does not
work with ATA_CAM, and no one has volunteered to rewrite it yet.  You
can use a port like sysutils/cdrtools or sysutils/cdrtools-devel
instead.

> > > I am trying to burn a CD (or DVD) on a SATA DVD-RW drive, but cdrtools 
> > > don't work.

Why not? Specifically, what fails?  Does your kernel include the
necessary bits, like ATA_CAM?  Have you asked the cdrtools port
maintainer for help, and sent him a verbose listing of any errors you
encounter?  There were some recent CAM changes that broke some ports
like audio/cdparanoia, but these ports will probably be fixed soon.

...

> > > Also, how do I build and install a kernel to some name other than 
> > > /boot/kernel, and not build all modules in duplicate?

I think we answered these questions in the other recent thread.

...

> I don't want to upgrade FreeBSD on older computer because of shortage of disk 
> space and only 256 MB RAM.  Portupgrading everything would be too gruesomely 
> slow, in addition to likely running short of disk space.

You can use a faster computer to build packages for your slower
computer, or use packages from the FreeBSD mirrors.  You can also use
tools like devel/ccache to speed builds, although this requires more
disk space.  Building ports in a swap-backed memory file system like
mdmfs or tmpfs can also help, although you have to be careful when RAM
is limited.  You could work around your disk space limitations by
using a removable drive for builds, or a network-based files system
like nfs.  And if you have a number of slower computers of the same
type, you can speed up builds by having the computers work together,
with something like devel/distcc.

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

Re: Quick build of stripped-down kernel

[b. f.]

On 11/25/11, Thomas Mueller  wrote:
> from "b. f." :
>
>> If you are going to build most of the modules, but only want to
>> exclude a few, then add the directories of the modules to be excluded
>> (relative to /usr/src/sys/modules) to WITHOUT_MODULES, for example in
>> /etc/make.conf. If you are only going to build a few modules, and want
>> to exclude the majority of the modules, then add the directories of
>> the modules that are to be built to MODULES_OVERRIDE.  For no modules
>> at all, set NO_MODULES.  See /usr/src/sys/modules/Makefile and
>> /usr/src/sys/conf/kern.post.mk for details. You may also save some
>> time by using one of your faster machines to build the OS for the
>> slower machines.
>
> Suppose you want to build more than one kernel so as to be able to choose at
> boot time.
>
> Then you might not want to build modules redundantly.  So how would you make
> the modules from /boot/kernel accessible when booting /boot/kernel2?
>

If the kernel versions were compatible, and the set of modules were
the same, I suppose you could set MODULES_WITH_WORLD and
KODIR=/boot/modules during buildworld and installworld, to build the
modules as part of buildworld and install them in /boot/modules during
installworld, rather than in /boot/kernel or /boot/kernel2.  Then you
could build and install both of your kernels with NO_MODULES, as
previously discussed, and with your  different choices of KODIR for
each kernel.  Because /boot/modules is part of the default module_path
defined in /boot/defaults/loader.conf, the modules ought to load as
usual for either kernel.  If you wanted to place them in a different
directory, you could alter KODIR during buildworld and installworld,
and add the directory to module_path in /boot/loader.conf.  I haven't
tested this, but I think that it will work, and I'd be interested to
hear whether it does. There are of course alternative methods.

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

Re: Quick build of stripped-down kernel

[b. f.]

> Happy Thanksgiving! This week, I've been building FreeBSD 9.0-RC2

And to you, too.

> kernels for various machines, and on some of the older and slower
> ones it's been taking quite a long time. One of the reasons for
> this is that even if you strip 98% of the drivers out of the
> kernel, they are all still built as loadable modules. The machines
> in question will NEVER use those modules, so it's a waste of time
> and disk space.
>
> How hard would it be to create a build target for "make" that would
> avoid building the loadable modules and just leave them out of the
> directory where the new kernel is placed after installation? I am
> not intimately familiar with the cascade of makefiles that does the
> build I could probably figure out what to tweak, but if someone
> who is expert in this can help it would be appreciated. It would
> save me countless hours.

If you are going to build most of the modules, but only want to
exclude a few, then add the directories of the modules to be excluded
(relative to /usr/src/sys/modules) to WITHOUT_MODULES, for example in
/etc/make.conf. If you are only going to build a few modules, and want
to exclude the majority of the modules, then add the directories of
the modules that are to be built to MODULES_OVERRIDE.  For no modules
at all, set NO_MODULES.  See /usr/src/sys/modules/Makefile and
/usr/src/sys/conf/kern.post.mk for details. You may also save some
time by using one of your faster machines to build the OS for the
slower machines.

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

Re: (8.2) share lib and ldconfig problem.

[b. f.]

> Hello,
>
> 8.2 STABLE/i386
>
> I'm hit by something strange.
>
> Basically ldconfig does not take care of some libs
> in /usr/local/lib/compat/pkg
>
> By sample I've updated icu (via portupgrade) and libreoffice does not
> start anymore.
>
> $ libreoffice
> /libexec/ld-elf.so.1: Shared object "libicuuc.so.46" not found,
> required by "libsvtfi.so"
>
> Portgrade did a copy of the lib into /usr/local/lib/compat/pkg and run
> ldconfig. But the lib does not appear in the listing of the ldconfig
> cache :

You mean portupgrade, probably?

>
> # cd /usr/local/lib/compat/pkg/
> # ls -m *icu*
> libicudata.so.46*, libicudata.so.46.1*, libicui18n.so.46.1*,
> libicuio.so.46.1*, libicule.so.46.1*, libiculx.so.46.1*,
> libicutest.so.46.1*, libicutu.so.46.1*, libicuuc.so.46.1*
>
> # ldconfig -r | grep pkg | grep icu
> 664:-licudata.46 => /usr/local/lib/compat/pkg/libicudata.so.46
>
> Note that there is only one icu lib in the ldconfig's cache. The one
> named libicudata.so.46 (which is a copy of libicudata.so.46.1).
>
> Questions are :
>
> - Why theses libs are not in the ldconfig cache ?
> - Why a copy named libicudata.so.46 is in the cache and not
>   libicudata.so.46.1?

Unlike the hints for the old aout format, there aren't any filename
hashes in the elf hints file, just a header and a list of search
directories.  The 'ldconfig -r' output is faked, and displays (see
list_elf_hints() in src/sbin/ldconfig/elfhints.c) what it thinks
rtld(1) will look for: shared libraries in the search directories with
filenames of the form lib*.so., followed by a string of numbers
corresponding to the major version of the shared library. *.so.46.1
don't fit this pattern, because of the extra dots separating the major
and minor version numbers in those filenames.

Since your broken binary seems to need *.so.46, you can try adding
symlinks between the corresponding *.so.46 and *.so.46.1, or you can
rebuild the dependent port.

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

Re: pkg_version: corrupted record (pkgdep line without argument), ignoring

[b. f.]

On 10/22/11, b. f.  wrote:
> Jerry wrote:
>> After attempting unsuccessfully to update KDE4 via "portmaster", I
>> found a number of errors printed out when using "pkg_version-vIL=".
>>
>> I eventually used "portmanager" to update the KDE4 port successfully;
>> however, I am still receiving the following error messages.
>>
>> These ports need updating:
>> pkg_version: corrupted record (pkgdep line without argument), ignoring
>> pkg_version: corrupted record (pkgdep line without argument), ignoring
>> pkg_version: corrupted record (pkgdep line without argument), ignoring
>> koffice-kde4-2.3.3_3<   needs updating (index has
>> 2.3.3_5)
>> postgresql-client-8.2.21<   needs updating (index has
>> 8.2.22_1)
>>
>> I have not found a way to ascertain which ports contain the corrupted
>> records. Originally, there were over a dozen of them but "portmanager"
>> fixed most of them for me. How can I determine what ports are still
>> damaged so that I might correct them.
>
> As the others have written, you could use sed, grep, or visual
> inspection to examine the pkgdb.  Alternatively, you could try testing
> one port at a time, to see what ports pkg_version chokes on, by using
> something like:
>
>  pkg_info -aE | xargs -tI @ pkg_version -vIL= -s @


Bah, sent this to freebsd-ports by mistake.  Sorry.

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

Re: Download manpages

[b. f.]

> Hello Matthew,
> I'm trying to download section 2 and section 1 for freebsd commands and
> system calls

? Is there a specific manpage that you are missing?  A cursory glance
shows that these sections are populated:

 sh -c 'cd /tmp ; for i in a b c d e f g ; do  fetch -ampv
"http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.2-RELEASE/manpages/manpages.a${i}";
; done ; cat manpages.?? > manpages.tar.gz ; mkdir manpages82 ; tar -C
manpages82 -xvf manpages.tar.gz; ls manpages82/usr/share/man/man[12]'

...

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

Re: How can I disable hyperthreads, but NOT smp ?

[b. f.]

> On 20/09/2011 21:34, Jason Usher wrote:
> > FreeBSD 6.4-RELEASE system with two physical CPUs, each of which are HT 
> > capable.  From dmesg:
> >
> > cpu0 (BSP): APIC ID: 0
> > cpu1 (AP): APIC ID: 1
> > cpu2 (AP): APIC ID: 6
> > cpu3 (AP): APIC ID: 7
> >
> > I also see this:
> >
> > machdep.hyperthreading_allowed: 0
> >
> > The problem is, I have reason to believe that my workload benefits greatly 
> > from SMP, but is not playing nicely with hyperthreading.  That is, it is 
> > trying to farm out 4 things at a time to a cpu setup that really is only 
> > able to do two things at a time.
> >
> > How can I disable HT completely, but still retain ALL the benefits of SMP ?

If you are sure about your machine's hardware, and that
machdep.hyperthreading_allowed is really set to 0 in loader.conf(5),
then you may want to glance at:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/mp_machdep.c?annotate=1.252.2.16

to see where the enforcement of this tunable is failing, and file a
PR.  Although I have not tried to use them, there are supposed to be
alternative mechanisms to disable cpus, or at least to ignore them in
certain circumstances:

--on recent versions of FreeBSD (> 6) you could use cpuset(1) to
ignore some of them in certain circumstances;
--on older versions of FreeBSD (< 9) you could use the sysctl
machdep.hlt_logical_cpus=1 (see smp(4));
--on older versions of FreeBSD (< 9) you could use the sysctl
machdep.hlt_cpus to add a bitmap of the logical cpus that you want to
disable (see smp(4));
--you can use the loader hint hint.lapic.X.disable=1 to disable a cpu
with APIC ID X.

But note the warnings in the Andriy Gapon's commit message and
UPDATING entry for:

http://svnweb.FreeBSD.org/base?view=revision&revision=222853



> It's usually a setting in the BIOS to disable Hyperthreading then
> reconfigure the kernel to only use 2 cores (which it might do
> automatically).
>
> Hyperthreading is outside the world of FreeBSD. As far as it knows there
> is still 4 "logical processors". Disabling hyperthreading it should see
> 2 LPs.

This isn't completely true.  Yes, many systems have a BIOS setting to
toggle hyperthreading on and off.  The loader tunable can be used for
those machines that don't have such a setting, or for remote machines
for which it is not convenient to change the setting.  But FreeBSD
attempts to determine if any of the logical cpus are hyperthreads, so
that the loader tunable machdep.hyperthreading_allowed can be enforced
(it was introduced a long time ago when a security hole was discovered
with some early hyperthread implementations), and also because
hyperthreads are treated differently from physical cpus with regard to
interrupt handling, scheduling (with ULE), ACPI, PMC, etc.  So FreeBSD
is supposed to be "hyperthread-aware".

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

Re: Negative ping times with FreeBSD 8.1-RELEASE on older Celeron system

[b. f.]

> I just put FreeBSD 8.1 up on an old (but good) 500 MHz Celeron with
> half a gig of RAM. Interfaces are classic xl (3Com) and dc (DEC
> tulip). Works quite nicely except for one quirk: ping times that
> ought to be positive (no more than 200 ms worst case) are coming
> out negative! Can't figure out what might be causing this. dmesg
> output is as follows:

If you are just upgrading now, why not use 9 BETA?  I think that your
older machine will be much happier -- the new timer code in 9 has a
bunch of bugfixes, allows for a wider choice of alternative timers, in
case some are broken, and places lighter loads on the system, by
allowing some (formerly periodic) timer use to be deferred.  And then
there is the host of other improvements...

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

Re: port build breaks at xmlto

[b. f.]

On Fri, Aug 12, 2011 at 01:18:07PM +1000, Daryl Sayers wrote:
>
>
> FreeBSD 7.4
> I am having trouble building the xmlto port on FreeBSD 7.4. I am getting an
> error:
>
> ===>  Building for xmlto-0.0.24
> make  all-am
> for xml in xmlif.xml xmlto.xml; do  FORMAT_DIR=./format  /usr/local/bin/bash 
> ./xmlto -o man/man1 man ./doc/$xml ;  done || ( RC=$?; exit $RC )
> xmlto: /usr/ports/textproc/xmlto/work/xmlto-0.0.24/./doc/xmlif.xml does not 
> validate (status 3)
> xmlto: Fix document syntax or use --skip-validation option
> I/O error : Attempt to load network entity 
> http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
> /usr/ports/textproc/xmlto/work/xmlto-0.0.24/./doc/xmlif.xml:4: warning: 
> failed to load external entity 
> "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";
>"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
> 

xmlto should be using /usr/local/share/xml/docbook/4.2/docbookx.dtd,
which should be installed by the build dependency
textproc/docbook-xml, but instead is trying to fetch this file from a
remote location, and failing.  Check to see if this file is present,
and intact.  If it isn't, then reinstall textproc/docbook-xml. You
could look at the file (and compare it to the reference file from the
remote location), and the output of "pkg_info -ag", to see if anything
is corrupted.


>
> After alot of frustration I decided to throw everything away and start again:
>
> # pkg_delete -a

Okay, you've instructed the system to delete the registered files and
directories in the step above -- but is any garbage left in /usr/local
afterward?  After the above step, you should check to see that
/usr/local only contains files that you have placed there, and that
won't interfere with new port installations.


> # cd /usr/ports; rm -fr *
> # csup -h cvsup.au.FreeBSD.org /usr/share/examples/cvsup/ports-supfile
> # cd /usr/ports/textproc/xmlto
> # make

Usually, it's a good idea to perform "make deinstall-all clean all"
(in that order), although in this case it should not have made a
difference for the first build, if you had succeeded in cleaning
/usr/local and /usr/ports.

>
> Using the defaults when the config screens appear. As there are now no 
> packages
> installed and the ports tree is brand new there should be no problems but in
> the end it still fails with the same message. My /etc/make.conf is empty also.
>
> Why cant I build this package.

This port was built on July 17 on the build cluster with 7.3-RELEASE-p4:

http://pointyhat.freebsd.org/errorlogs/amd64-7-latest-logs/xmlto-0.0.24.log

so while there may be a bug in the port, or in one of its
dependencies, it is more probable that your build is polluted.  If you
don't want to use a binary package downloaded from the server, then
you'll have to be patient, and break down the build until you find the
precise location where it is failing, even though that is a nuisance.
A complete build transcript and config.log would help.

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

Re: High interrupt rate

[b. f.]

On 8/7/11, Mario Lobo  wrote:
> On Sunday 07 August 2011 18:34:27 b. f. wrote:
>> > I know 75% idle is not bad but this machine, when not under load on a
>> > saturday night like today, used to be at around 98% idle 99% of the
>> > time. Now its is at 72% idle 99.9% of the time. It has been like this
>> > all day.
>> >
>> > The only things with a high interrupt rate are
>> >
>> > cpu0: timer 46922025   2000
>> > cpu1: timer 46918117   1999
>> >
>> > What could be causing this?
>>
>> I don't know that 2 timer interrupts per-cpu, per kern.hz, is
>> altogether unexpected for some configurations, under some conditions.
>> What happens if you boot with kern.hz="100" in /boot/loader.conf, or
>> set via the loader command line?  What happens if you remove the
>> DEVICE_POLLING option from your kernel (and _not_ just disable polling
>> per-device)?  What is the output from "sysctl kern.timecounter
>> kern.eventtimer"?
>>
>> b.
>
> Thanks b. !
>
> [~]>sysctl kern.timecounter
> kern.timecounter.tick: 1
> kern.timecounter.choice: TSC(-100) ACPI-safe(850) i8254(0) dummy(-100)
> kern.timecounter.hardware: ACPI-safe
> kern.timecounter.stepwarnings: 0
> kern.timecounter.tc.i8254.mask: 65535
> kern.timecounter.tc.i8254.counter: 39201
> kern.timecounter.tc.i8254.frequency: 1193182
> kern.timecounter.tc.i8254.quality: 0
> kern.timecounter.tc.ACPI-safe.mask: 16777215
>
>
> kern.timecounter.tc.ACPI-safe.counter: 1055460
>
>
> kern.timecounter.tc.ACPI-safe.frequency: 3579545
>
>
> kern.timecounter.tc.ACPI-safe.quality: 850
>
>
> kern.timecounter.tc.TSC.mask: 4294967295
>
>
> kern.timecounter.tc.TSC.counter: 1200011080
>
>
> kern.timecounter.tc.TSC.frequency: 1995401152
>
>
> kern.timecounter.tc.TSC.quality: -100
>
>
> kern.timecounter.smp_tsc: 0
>
>
> kern.timecounter.invariant_tsc: 1
>
> [~]>sysctl kern.hz
> kern.hz: 1000
>
> [~]>sysctl kern.eventtimer
> sysctl: unknown oid 'kern.eventtimer'
>
> I'll wait for your views on those before disabling polling on the kernel and
> hz=100.

It looks like your interrupt rate, while probably higher than needed,
is not unexpectedly high for your configuration.  But you can lower it
if you want to do so.

You are using a system before the introduction of the new eventtimer
code.  If you use 9.x, that has the new code and some other
timer-related improvements, and you are not performing polling, then
you can achieve a large reduction in the number of timer interrupts
when the system isn't busy. You can still achieve a reduction on 8.x,
but the reduction usually won't be as large as on 9.x under similar
conditions.

To reduce timer interrupts on an idle system running 8.x or 9.x, if
you do not need to poll (most systems do not), remove  DEVICE_POLLING
from your kernel, and lower kern.hz to a suitable value -- 100 or 250,
for example. For many workloads, a lower value is not only adequate,
but may also be better in some ways.

Also, you may want to consider using your TSC as the system
timecounter, because it is usually more efficient to do so.  This may
not work for SMP, because if there are multiple TSCs on your system,
they may not be synchronized.  In 9.x, there is a test for
synchronization, and the TSCs are preferred to the ACPI-safe timer if
they satisfy this test and meet some other requirements.  In 8.x, the
user has to tell the system that it is safe to use the TSCs by adding:

kern.timecounter.smp_tsc="1"

to /boot/loader.conf.  If you are not putting your cores into the C3
state, then you could try setting this via the loader command line,
booting, and then seeing if the kern.timecounter.tc.TSC.quality is
positive, kern.timecounter.hardware is TSC, and everything is working
as expected.  If the results are satisfactory, then you could add the
above entry to /boot/loader.conf.  But it would be better to do this
on 9.x, where there are some added safeguards.

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

Re: High interrupt rate

[b. f.]

>
> I know 75% idle is not bad but this machine, when not under load on a saturday
> night like today, used to be at around 98% idle 99% of the time. Now its is at
> 72% idle 99.9% of the time. It has been like this all day.
>
> The only things with a high interrupt rate are
>
> cpu0: timer 46922025   2000
> cpu1: timer 46918117   1999
>
> What could be causing this?

I don't know that 2 timer interrupts per-cpu, per kern.hz, is
altogether unexpected for some configurations, under some conditions.
What happens if you boot with kern.hz="100" in /boot/loader.conf, or
set via the loader command line?  What happens if you remove the
DEVICE_POLLING option from your kernel (and _not_ just disable polling
per-device)?  What is the output from "sysctl kern.timecounter
kern.eventtimer"?

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

Re: how do i find a file in all directories 7 to 9 days old?

[b. f.]

On 7/28/11, b. f.  wrote:
>>  how can i use find or whatever to find a file, say 6 levels deep
>>  that is <= 9 days old?   i'm looking fo something i had to jt down
>>  [[ASCII]].  can't remembr te file name, nor when i was when i had
>>  the idea flash into my mind
>
> Try something like:
>
> find / -type f -mtime -10d -mindepth 5 -maxdepth 7
>
> See find(1) for variations.

Hmm. I'm not sure owing to the difference between the body and the
subject of the message, what criteria are really wanted, but for the
criteria in the subject you might use something like:

find / -type f -mtime -10d -mtime +6d


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

Re: how do i find a file in all directories 7 to 9 days old?

[b. f.]

>  how can i use find or whatever to find a file, say 6 levels deep
>  that is <= 9 days old?   i'm looking fo something i had to jt down
>  [[ASCII]].  can't remembr te file name, nor when i was when i had
>  the idea flash into my mind

Try something like:

find / -type f -mtime -10d -mindepth 5 -maxdepth 7

See find(1) for variations.

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

Re: pkg_delete yields 'no such package'

[b. f.]

> Matthew Seaman wrote:
> On 24/07/2011 08:48, Toan H. Le wrote:
> > Either I use 'pkg_delete xorg-docs' or 'pkg_delete xorg-docs-1.4.1',
> > pkg_delete yields the error of 'no such package'. Checking via 'pkg_info'
> > and 'pkg_version' confirms the packages xorg-docs-1.4.1 installed. I think I
> > did not use the wrong command.
>
> Hmmm...  That's a typo.  The package name is:
>
> lucid-nonsense:...ports/x11/xorg-docs:% make -V PKGNAME
> xorg-docs-1.4,1
>
> Note the comma -- that's part of the version number, and needs to be
> copied down verbatim for pkg_delete(1)

It is often convenient to use the -x or -X switches with these
utilities, or to use a glob, so that you only have to type part of the
full PKGNAME, e.g.:

pkg_delete xorg-docs\*
pkg_delete -x xorg-docs

Just make sure that the glob or regex that you use only applies to the
packages that you want the utilities to act upon, e.g.:

pkg_info -I xorg-docs\*
pkg_info -Ix xorg-docs

See the manpages of the utilities for details.

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

Re: Using csup and -i switch

[b. f.]

> Hello,
>
> I updated all my ports recently but I have submitted a PR for
> audio/musicpd for a simple patch. I would like to update only my
> audio/musicpd on all my machines so I tried the following:
>
> markand at Groseille ~ $ sudo csup -i audio/musicpd /etc/ports-supfile
> Connected to 193.51.24.2
> Updating collection ports-all/cvs
> Finished successfully
>
> According to man csup(1) -i should update only files or directory
> matching the pattern but as you can see here nothing is updated ..
>

According to csup(1), the patterns used with -i are "interpreted
relative to the collection's prefix directory".  Probably, then, you
need to use "ports/audio/musicpd" as your pattern.

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

Re: options used to compile packages

[b. f.]

On 7/17/11, David Arendt  wrote:
> When I did the test, I used FreeBSD 8.2 amd64 using the ports collection
> delivered with this distribution.
>

I see.  Since that time, there have been very few changes to the
version of the base system used to build the packages for 8, but more
to some of the ports that you mentioned, so probably the difference
that you observed is due to the latter, if it isn't caused by some
local change on your own system.


> Yesterday I did a checkout of the latest ports tree. I compiled bash,
> xorg, xfce and gdm using the default options. When trying to login using
> gdm, it still complains about a missing keyring pam module. When I
> disable keyring support in gdm, gdm runs flawlessly. Therefore I thought
> that options used to compile the offical packages might be different. If
> default options are used to compile them, it should be a some other
> problem. To ensure that my build environment is not polluted, I did this
> test on a fresh installation. But anyway it doesn't matter as I have a
> workaround.

If you believe that the error arises from a problem other than your
particular configuration of gdm and its dependencies, or at least is
likely to affect others, then it would be helpful if you submitted a
problem report:

http://www.freebsd.org/send-pr.html

after having first looked to see if a similar problem has already been
reported, via:

http://www.FreeBSD.org/cgi/query-pr-summary.cgi?category=&severity=&priority=&class=&state=&sort=none&text=&responsible=&multitext=pam&originator=&release=

or other searches of your own.

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

Re: options used to compile packages

[b. f.]

> well I don't actually now which package it was, but I compiled gdm (so
> it should be one of it's dependencies). A compilation resulted in a non
> working gdm (something with pam support not found on execution). Upon
> installing gdm and is dependencies from packages, everything worked
> correctly. Therefore I thought there might be other default options. I
> am sorry that I cannot be more precise, but I tried it 2 months ago, so
> I do not remember exactly. I think I will try it again from scratch with
> latest ports tree and give you more precise information.

In addition to the obvious possibilities that your test was faulty, or
that you somehow polluted your build environment, It is also possible
that:

-at least one of your ports was a different version than used in the
default packages, and had a bug;

-there was a transient build error;

or

-you were using a different version of FreeBSD than that used to build
the default packages that you used, and there is a problem with one of
the ports on that version of FreeBSD.

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

Re: gcc 4.4.7

[b. f.]

> I decided to switch from portmaster to portupgrade and pkddb -F show many
> stale dependencies on gcc-4.4.5.20110503 (lang/gcc44).
>
> Do I need to put new dependencies to gcc-4.5.4.20110630 or something else,
> please?
> For portmaster I put IGNOREMI+ line and it works but I don't know how to do
> with portupgrade.

I am not sure what you mean by using +IGNOREME here.  Unless you have
a good reason to use lang/gcc44, you should replace lang/gcc44 with
lang/gcc45, and rebuild or otherwise obtain newer versions of the
packages that formerly used lang/gcc44 at runtime, so that the newer
packages use the libraries from lang/gcc45 at runtime.  The
bookkeeping in the portupgrade database and in /var/db/pkg, and the
updating tool(s) that you choose to use, are relatively minor details.
 If you choose to use portupgrade to do this, you should probably do
something like:

portupgrade -o lang/gcc45 lang/gcc44
portupgrade -rfx lang/gcc45 lang/gcc45

(although it has been a while since I used portupgrade). You may want
to first try the steps with an added -n.

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

Re: options used to compile packages

[b. f.]

> I want to compile packages from the ports collections with exactly the
> same options that have been used to compile the official packages from
> the official freebsd package collection. Is the var/db/ports directory
> used to compile the official freebsd package collection available
> somewhere ? If not, it would be very good to make it available as ports
> default options seem to be different from options used to compile
> official packages.

As far as I know, the default options are used to compile the standard
packages.  Where did you think that there were differences?  The
official builds use a vanilla ports tree, and the scripts at
http://svnweb.FreeBSD.org/base/projects/portbuild/ .

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

Re: Portupgrade Package Question

[b. f.]

On 7/10/11, b. f.  wrote:
> On 7/9/11, Thomas D. Dean  wrote:
>> On Sat, 2011-07-09 at 19:54 -0400, b. f. wrote:

> You could cheat, and neither upgrade your base system nor make the
> changes I mentioned in my last message, but instead fool portupgrade
> into thinking that you have a newer base system, by setting UNAME_R to

Sorry, that should be "UNAME_r", with a lower-case "r", above.  But,
as I wrote, using that workaround is probably not a good idea.

> something like "8.2-STABLE" in your environment when you call
> portupgrade, but you are bound to run into problems eventually by
> lying in that way.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Portupgrade Package Question

[b. f.]

On 7/9/11, Thomas D. Dean  wrote:
> On Sat, 2011-07-09 at 19:54 -0400, b. f. wrote:
>
>> occasionally trip over problems that will require intervention.  (Note
>> that in the section of the csup file that you reproduced in an earlier
>> message, 'release-cvs' should be 'release=cvs'.)
>
> The '-' was a typo on my part.  The machine I used for email is not the
> machine I am updating.
>
> I am updating that machine, now.  The supfile contains
> *default release=cvs tag=RELENG_8
>
> This should track 8-stable.  Correct?

This is the tag that you would use on src collections to update your
base system sources (usually in /usr/src) to 8-STABLE.  You would use
RELENG_8_2 for the 8.2-STABLE security branch, RELENG_8_2_RELEASE for
8.2-RELEASE, and so on.

But src tags are not the same as ports tags.  That is why they have
separate example supfiles for the base system sources, and for ports.
And that is also why they have the prominent warning in the base
system example supfiles:

###
#
# DANGER!  WARNING!  LOOK OUT!  VORSICHT!
#
# If you add any of the ports or doc collections to this file, be sure to
# specify them with a "tag" value set to ".", like this:
#
#   ports-all tag=.
#   doc-all tag=.
#
# If you leave out the "tag=." portion, CVSup will delete all of
# the files in your ports or doc tree.  That is because the ports and doc
# collections do not use the same tags as the main part of the FreeBSD
# source tree.
#
###



As far as I know, the ports collection has no tags for any stable
branches, only tags made at the time of releases.  So for ports, if
you are running 8.2-RELEASE, you have three choices: (1) use
RELEASE_8_2_0 if you want to stick with a snapshot of the ports tree
taken at the time of the release, or (2) use "." if you want
up-to-date ports, or (3) choose a specific snapshot of ports via date=
instead of tag= (for details, see, for example, the csup(1) manpage.)


>
> After the build finishes, portupgrade should fetch from 8-stable.

I'm not sure what you mean here.  As I wrote before, you need to make
some additional changes to ensure that portupgrade uses 8-stable
packages if you have an 8.2-RELEASE base system.  Just having a
up-to-date ports tree and index isn't sufficient.  However, if you
replace your 8.2-RELEASE base system with a newer 8.2-STABLE or
8-STABLE base system, then portupgrade should fetch the 8-stable
packages by default, without any additional changes.

You could cheat, and neither upgrade your base system nor make the
changes I mentioned in my last message, but instead fool portupgrade
into thinking that you have a newer base system, by setting UNAME_R to
something like "8.2-STABLE" in your environment when you call
portupgrade, but you are bound to run into problems eventually by
lying in that way.

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

Re: Portupgrade Package Question

[b. f.]

Thomas D. Dean wrote:
...
> For the most recent try, I have
>
> ...
> #   OS_PATCHLEVEL:  ""  "-p8"
> #   OS_PLATFORM:"i386"  "amd64"
> #   OS_PKGBRANCH:   "7-current" "6.1-release"
> OS_RELEASE="8-STABLE"
> OS_BRANCH="STABLE"
> OS_PKGBRANCH="8-stable"

The comments above were not intended as an invitation to try to define
these constants here, but merely describe typical values that the
constants may have.  The constants are computed from parsing your
'uname -rm' output in $LOCALBASE/$RUBY_SITELIBDIR/pkgtools.rb (usually
/usr/local/lib/ruby/site_ruby/1.8/pkgtools.rb), so you cannot set them
in pkgtools.conf.  They were only mentioned so that users would know
that they were available for defining other procedures and variables
(for an example, see below).

>
> # Useful predefined functions:
> #
> #  localbase()
> #Returns LOCALBASE.
> ...
>
> But, portupgrade still tries to fetch from 8.2-release.

If you are running 8.2-RELEASE, and yet wish to obtain "8-stable"
packages (which are actually built on recent versions of 8.1-STABLE,
with recent versions of the ports tree), then set PKG_SITES
appropriately in pkgtools.conf.  In this case, I think (untested) that
you could substitute

sprintf('%s/pub/FreeBSD/ports/%s/packages-%s-stable/',
ENV['PACKAGEROOT'] || 'ftp://ftp.FreeBSD.org', OS_PLATFORM, OS_MAJOR)

for the default

pkg_site_mirror(root)

in PKG_SITES.  (It might be better to upgrade your base system to
8-STABLE, in which case the defaults will be correct without any need
for these changes, and other problems will also be fixed).

>
> If I want to use binary ports it looks like I need to zap the ports tree
> and recreate it with portsnap.

This should not be necessary.  You should be able to use any method to
update the tree (anonymous cvs, csup/cvsup, portsnap, http/ftp, rsync,
ctm, etc.).  Of course, if your tree and index file do not correspond
to the version of the binary packages that you want to use, you will
occasionally trip over problems that will require intervention.  (Note
that in the section of the csup file that you reproduced in an earlier
message, 'release-cvs' should be 'release=cvs'.)

PKG_SITES will only be used by the ports-mgmt/portupgrade scripts; if
you want to use pkg_add(1) manually, and obtain the 8-stable packages,
then you should define PACKAGESITE in your environment, or provide a
full URL.  The ports-mgmt/portupgrade scripts also respect
PACKAGESITE, which will override PACKAGEROOT and PKG_SITES in those
scripts.

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

Re: What is xz ?

[b. f.]

On 7/2/11, Robert Huff  wrote:
>
> b. f. writes:
>
>>  > It is part of  '7.2-RELEASE',   Dunno about 7.1
>>
>>  Hmm.  Are you sure?  If this is true, the archivers/xz port needs
>>  to be patched to IGNORE those branches of 7 that have xz.
>
>   Is that necessarily true?
>   For comparison: the default system compiler is gcc-4.2.1 (I
> believe).  There are several higher numbered versions in ports.


You mean, if xz is actually in FreeBSD 7, which doesn't seem to be the
case, is it absolutely necessary to disable builds of archivers/xz on
7?  Or, for that matter, on 8 and 9? -- well, no, it isn't strictly
necessary, but what's the point of not disabling the port when the
same version of xz is in both the base system and the port, and rtld's
default search pattern will favor the former over the latter?  With
the different versions of gcc, you are at least getting some
functional differences.  If naddy updates the port to 5.1.1 or 5.0.3,
the case might be different.

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

Re: What is xz ?

[b. f.]

> > From owner-freebsd-questions at freebsd.org  Sat Jul  2 06:45:00 2011
> > Date: Sat, 2 Jul 2011 13:43:55 +0200
> > From: Polytropon 
> > To: Chris Whitehouse 
> > Cc: freebsd-questions at freebsd.org
> > Subject: Re: What is xz ?
> >
> > On Sat, 02 Jul 2011 12:26:14 +0100, Chris Whitehouse wrote:
> > > On 02/07/2011 07:38, Polytropon wrote:
>
> >
> > Correct. I'm currently on 7-STABLE where it's "not yet" part of
> > the base system, but my new 8.2-STABLE also has it in /usr/bin.
> > I believe it has been introduced with version 8...
>
> It is part of  '7.2-RELEASE',   Dunno about 7.1

Hmm.  Are you sure?  If this is true, the archivers/xz port needs to
be patched to IGNORE those branches of 7 that have xz.  But I don't
see any mention of it at:

http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/xz/ChangeLog

or

http://svnweb.FreeBSD.org/base/stable/7/contrib/

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

Re: I486_CPU or I586_CPU in kernel config

[b. f.]

Warren Block wrote:
> On Mon, 30 May 2011, Adam Vande More wrote:
>
> > Perhaps this is the one you meant?
> >
> > http://lists.freebsd.org/pipermail/freebsd-questions/2009-January/190568.html
>
> That's the one!  Thanks!
>
> > Actually the two threads touch on the same subject, and it seems
> > removal of those options is still desirable on newer CPU's.
>
> sys/i386/i386/support.s is mentioned, but doesn't seem to have anything
> explicitly specific for 586.  There are some i686 entries.
>
> A test for cpu_class==CPUCLASS_586 in /sys/i386/isa/npx.c is mentioned
> in the thread, but that check isn't in the current code.

Removed:

http://svnweb.FreeBSD.org/base?view=revision&revision=209460

There was a discussion about the implications for performance,
although I don't remember when it took place, and whether it was on
the mailing lists or in a PR audit trail.  If you're interested you
can track down the details.

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

Re: UDF and DVD's

[b. f.]

grarpamp wrote:
...
> I'm guessing the current state within FreeBSD means that I can
> neither read, nor create, or write, readable (compatible) images
> at this, or any given, UDF level?
...
>
> Is this a blocker for FreeBSD?
>
> For me, at least, minimally, that seems to be the case... as I now
> have no way to rip, mount and add the files to this DVD that I would
> like to add. Except to use Windows, which I consider to be unreliable
> at best.

Obviously, the base system UDF support is minimal and needs some work.
 But you may find that ports like sysutils/cdrtools[-devel] or
sysutils/udfclient will allow you to do much of what you want to do.

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

Re: Comparing two lists [SOLVED (at least it looks like that)]

[b. f.]

> 2011-05-07 02:09, Rolf Nielsen skrev:
> > Hello all,
> >
> > I have two text files, quite extensive ones. They have some lines in
> > common and some lines are unique to one of the files. The lines that do
> > exist in both files are not necessarily in the same location. Now I need
> > to compare the files and output a list of lines that exist in both
> > files. Is there a simple way to do this? diff? awk? sed? cmp? Or a
> > combination of two or more of them?
...
> sort file1 file2 | uniq -d

If the lines aren't repeated in only one file...

For future reference, comm(1) exists to handle problems like this,
although (of course) TIMTOWTDI.

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

Re: Piping find into tar...

[b. f.]

> Dne 4.5.2011 11:42, Modulok napsal(a):
> >>> By the way, in reference to the commands above the -j option is for
> > bzip2, so the extension should be .tbz o_O
> >
> > Thanks everyone! I went with the following, because it works regardless of
> > space characters in filenames. (Thanks for the correction on the extenion. 
> > It
> > should indeed be 'tbz' when using the 'j' flag.)
> >
> > find -E . -regex '.*\.txt$' -print0 | xargs -0 tar -cjf result.tbz
>
> When the amount of files is huge then tar will be invoked twice
> or more. Thus result.tbz will contain just files from the last invocation.
>
> I consider cpio a better option here.

The use of simple patterns permitted by tar(1) or cpio(1) may be a
good choice in some cases, but we were responding to the OP's wish to
use find(1), which is a bit more flexible.  If there were a large
number of files, one could still use find and tar in many cases by
appending to the archive rather than (re)creating it with each tar
invocation, e.g.:

 find . -type f -name '*.txt' -print0 | xargs -0 tar -rvf archive.tar
; bzip2 archive.tar

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

Re: Piping find into tar...

[b. f.]

On 5/4/11, Modulok  wrote:

>
> As for pax, I thought tar could create pax archives too, via the --format
> pax
> option?

Yes, although I haven't tested it thoroughly.  pax(1) should also be
able to create a number of different archive formats via the -x flag.
I prefer tar(1) (bsdtar/libarchive), because it has more features.

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

Re: Piping find into tar...

[b. f.]

On 5/4/11, Chris Rees  wrote:
> On 4 May 2011 08:44, b. f.  wrote:
>>> I've been playing with the find command lately. Is there a way I can pipe
>>> the
>>> putput list of files from find, into the tar command to create an archive
>>> which
>>> contains the files which find lists? I tried the following, but it didn't
>>> work
>>> (obviously).
>>>
>>> find -E . '.*\.txt$' -print | tar -cjf result.tgz
>>
>> You could use something like:
>>
>> find -X . -name '*.txt' | xargs tar -cjf result.tgz
>>
>> or
>>
>> find . -name '*.txt' -print0 | xargs -0 tar -cjf result.tgz
>>
>> b.
>
> How about using pax?
>
> find . -depth -print | pax -wd | gzip > archive.tgz
>
> or
>
> find . -depth -print | pax -wd | bzip2 > archive.tbz
>
>
> By the way, in reference to the commands above the -j option is for
> bzip2, so the extension should be .tbz o_O

True.  I just reproduced what the OP had.  The archive will still use
bzip2 compression, and bsdtar won't have a problem handling it, but
the name will be misleading.

As you wrote, pax(1) is an option, as are cpio(1) and many others...
You should be able to use -z with pax to avoid the extra pipe and
explicit invocation of gzip in the first case.

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

Re: Piping find into tar...

[b. f.]

> I've been playing with the find command lately. Is there a way I can pipe the
> putput list of files from find, into the tar command to create an archive 
> which
> contains the files which find lists? I tried the following, but it didn't work
> (obviously).
>
> find -E . '.*\.txt$' -print | tar -cjf result.tgz

You could use something like:

find -X . -name '*.txt' | xargs tar -cjf result.tgz

or

find . -name '*.txt' -print0 | xargs -0 tar -cjf result.tgz

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

Re: Port dependencies

[b. f.]

Chris Telting wrote:
> See above.  What I want to see is minimal installs with all features
> being usable once you install the optional components.  And run time
> detection for programs shouldn't be all that difficult or computation
> intensive.  The program would just consult pkg_info or another similar
> but faster database (and maybe somewhat platform independent) of what's
> installed on the system.

It's not a "minimal install" if binaries are bloated with extra code
to selectively enable _all_ functionality depending upon run-time
configuration options and dependency detection, rather than just the
functionality that is going to be used.  And build times would be
longer, usually much longer, because all functionality in the software
and all possible dependencies would have be built. And of course a lot
of software would have to be rewritten.  And I think that the added
overhead would not always be negligible. So while your idea has
certain advantages, it also has disadvantages.  It does not seem
practical to implement it, even if it were desirable to do so, for
most software at the present time.

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

Re: Booting from firmware RAID

[b. f.]

> This is probably more PC-specific than freebsd-specific question. I have
> intel firmware raid. OS needs drivers to work with it. FreeBSD sees it as
> ar0, so it has drivers.
> But I want my OS to be installed on this drive and boot from it. It is not
> good idea, but I really want to do it:)
> Is it possible?
>
> boot0 and boot1 both work with HDD via BIOS interrupts and CHS, right? So,
> how do they know how to access RAID? They has no drivers.
> Or BIOS supports interrupts to access RAID with out of drivers? If so --
> what for drivers are needed? To access drive via ATA interface?
>
> Is it possible to boot freebsd from "firmware raid"?

Sometimes: it depends on the firmware, and your bios.  I had a add-in
PCIe SATA RAID controller based on a Marvell SE9128 chipset, and using
a Marvell firmware.  The bios and the FreeBSD 9-CURRENT bootloader
were able to boot from a JBOD drive attached to the controller, up
until the point where the ahci driver tried to take control of the
drive.  Then the Marvell firmware presented a fictitious configuration
to the ahci driver and returned invalid device signatures, so the boot
process failed.  On the same machine, however, I was able to boot
without problems from a JBOD drive attached to a PCI-X SATA RAID
controller based on the Silicon Image SiI3124 chipset, using a Silicon
Image firmware.

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

Re: DTrace in RELEASE?

[b. f.]

>Does anyone know if it's likely DTrace will ever make it into the generic
> RELEASEs?

Maybe, at least in part.  One of the developers has asked that the
hooks needed for dtrace be included by default in upcoming releases:

http://lists.freebsd.org/pipermail/freebsd-arch/2011-March/011157.html

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

Re: python27 update-py-psyco

[b. f.]

On 3/8/11, ajtiM  wrote:
> On Monday March 7 2011 08:37:46 b. f. wrote:
>> On 3/7/11, ajtiM  wrote:
>> > On Sunday March 6 2011 12:01:47 b. f. wrote:
>> >
>> > Thank you. I am reading /usr/ports/UPDATING special like now but there
>> > are problems. And I have a problem again with /usr/ports/devel/py-psyco
>> > I get:
>> > c/mergepoints.c:242: error 'JUMP_IF_FALSE' undeclared here
>> > *** Error code 1
...
> Thank you very much for reply but I see that is not possible to build it (I
> red about psyco on mailing list).
> For now everything works but I have more ports to rebuild but psyco is the
> big
> problem.

Well, I'm not sure what list you are referring to here, but you should
still be able to build it, if you set PYTHON_VERSION to python2.5 or
python2.6 in your build environment, on the command-line, or in any
included Makefile (like, for example, /etc/make.conf or
$PORTSDIR/devel/py-psyco/Makefile.local).  Of course, if you are using
psyco with some other software, then you may have to do the same for
that software. You can do that conditionally if you are doing it in
some common Makefile like /etc/make.conf, and still want to use other
software with another version of python. For example:

.if${.CURDIR:M*/ports/devel/py-psyco}
PYTHON_VERSION=python2.6
.endif

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

Re: Coldfusion, Postgres and Java under FreeBSD

[b. f.]

...
> I'm running Java on FreeBSD right now, but I must say I'd probably
> stick to Linux nowadays if I had any say, at least until there comes a
> day when I'll be able to "pkg_add -r openjdk7".
...

Why not now? (Or anytime this past year or more?):

http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/java/openjdk-7.0.86.tbz
http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.2-release/java/openjdk-7.0.122.tbz
http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/java/openjdk-7.0.122_1.tbz

http://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.1-release/java/openjdk-7.0.86.tbz
http://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.2-release/java/openjdk-7.0.122.tbz
http://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/java/openjdk-7.0.122_1.tbz

etc.

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

Re: python27 update-py-psyco

[b. f.]

On 3/7/11, ajtiM  wrote:
> On Sunday March 6 2011 12:01:47 b. f. wrote:

> Thank you. I am reading /usr/ports/UPDATING special like now but there are
> problems. And I have a problem again with /usr/ports/devel/py-psyco
> I get:
> c/mergepoints.c:242: error 'JUMP_IF_FALSE' undeclared here
> *** Error code 1
>


There is not enough context here to learn much, but this is the kind
of error that could occur if this port is built with python 2.7.x.  It
may be that your ports tree is still not up-to-date, because this is
one of the few ports that doesn't work with python 2.7.x [The upstream
maintainer was working on a new version (see the port website), but
hasn't finished it yet], so Martin modified the port:

http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/devel/py-psyco/Makefile.diff?r1=1.17;r2=1.18

Do you have those changes? Is py-psyco using python 2.5.x or 2.6.x
during the build?  If not, update your ports tree (and make sure that
it really _is_ up-to-date, by looking at the file afterward, because
some mirrors have been having problems lately), then (for safety)
rebuild whatever version of python (2.5.x or 2.6.x) you are using with
py-psyco, and then try again. If it still doesn't work, post your full
build log to the freebsd-python mailing list.

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

Re: python27 update

[b. f.]

>I am using portmaster all the time more or less without problems.
>I like to switch to portupgrade but I don't know if is good to mix them. I
>think I will wait to FreeBSD 9 and than install evrything from scratch.

You would have encountered the problem that you mentioned regardless
of whether you used portupgrade or portmaster, and the results would
have been the same.  It was a flaw in the ports tree itself, not in
the updating tool.

I think that portmaster is probably a better choice for most people,
since it implements most if not all of the features that portupgrade
does, the maintainer is more active, and it doesn't need ruby and bdb
to work, or require extra databases.  Mixing portupgrade and
portmaster shouldn't cause any problems, as long as you take care to
keep your portupgrade port and package databases up-to-date,  but it
probably isn't necessary to use both.

Whatever you decide, I urge you to take a few minutes to read the
manpage of your updating tool.  It can save you a lot of time and
frustration later.  Also, if you want to avoid problems, after major
changes to the ports tree, it is safer to wait for a few days before
updating your own ports.  Usually there are a few problems that are
uncovered and fixed after major changes are made, and it takes a few
days or a week for this to happen.

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

Re: python27 update

[b. f.]

...
> I tried to update python26 to python27. I did as I red in /usr/ports/UPDATING:
>
> portmaster -o lang/python27 lang/python26 and than
>
>  cd /usr/ports/lang/python && make upgrade-site-packages -DUSE_PORTMASTER
>
> and after one day and a half of pressing yes for deleting old files I got:

Has it been a day and a half already?  ;)  Seriously, though, read the
portmaster manpage and learn how you can take some shortcuts, like
running 'portmaster  -y --clean-distfiles', or using other flags to
lower the amount of interaction required.

> -
> error: Comand" cc - shared -pthread -02 -pipe -WI, -rpath
> -/usr/local/lib/gcc45 -fno -strict -aliasing build/temp. freebsd-8.2-RELEASE-
> i386-2.7/build/src.freebsd-8.2-RELEASE-i386-2.7/numpy/core/src/-sortmudele.o -
> Lbuild/temp.freebsd-8.2-RELEASE-i386-2.7-lm -o build/lib-freebsd-8.2-RELEASE-
> i386-2.7/numpy/core/-sortss"
> failed with exit status 1
> ***Error code 1
>
>
> Stop in /usr/ports/math/py-numpy
> =>>>make failed for math/py-numpy
> =>> Aborting update
> =>> Update fpr py26-numpy-1.5.1,1 failled
> Aborting update
> Update for opencv-2.1.0 failed
> aborting update
>
> Terminated
> ***Error code 143
> Stop in /usr/ports/lang/python
>

You need to update your ports tree to make sure that you pick up:

http://lists.freebsd.org/pipermail/cvs-ports/2011-March/213081.html

which should fix the above problem.


> Is it possible to save this problem, please? Do I need run again cd
> /usr/ports/lang/python && make upgrade-site-packages -DUSE_PORTMASTER and wait
> one day more or will portmaster continue where it stopped?

Try:

... make upgrade-site-packages -DUSE_PORTMASTER PORTUPGRADE_ARGS="-R"

Even if that doesn't work, you won't have to repeat all of your
previous work, because those ports that were successfully updated in
the last run will no longer have files in the old python26 library
directories, and so won't be rebuilt by re-running upgrade
site-packages, unless you were to run portmaster with additional
flags.

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

Re: optical driver with ahci bios mode but ata(4) driver

[b. f.]

On Mon, Feb 28, 2011 at 8:31 PM, David Demelier
 wrote:
> Hello,
>
> My bios can be set to use IDE emulation or ahci mode, I prefere the ahci
> mode because it's a bit faster.
>
> It's probably stupid to stay with ata(4) driver with the ahci mode, isn't
> it? But with ahci(4) driver you can't burn with burncd(8) and cdrecord just
> fail and break an blank cd for nothing.
>
> I guess this is the correct behavior when trying to use burncd(8) /
> cdcontrol(1) :
>
> markand at Melon ~ $ burncd msinfo
> burncd: ioctl(CDIOREADTOCHEADER): Input/output error
>
> markand at Melon ~ $ cdcontrol info
> cdcontrol: getting toc header: Input/output error
> cdcontrol: Input/output error
>
> But why the optical drive is only affected? If I use ata(4) driver even with
> ahci mode set in the bios, why the hard drive works pretty well?

You may still be using AHCI, via the ataahci part of ata(4), which is
not as good as the newer driver ahci(4). (Or your BIOS may be lying,
or have some legacy work-around.)

I've had occasional trouble with cdrecord and cd(4), too, and I found
that some of the errors are innocuous, and can be overcome by using
the -immed and -force flags with cdrecord.  There are also some
patches available to improve compatibility between the two, that the
submitter has not had time to commit:

http://lists.freebsd.org/pipermail/freebsd-current/2010-November/020944.html

Those may solve some problems.  Also, there are various settings that
one can tweak.  But we would know more if you provided verbose
listings of the errors that you encounter.  The upstream developer of
cdrtools is occasionally willing to help diagnose some problems, if
you ask politely and give him the necessary information.  You might
try asking him.

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

Re: Kernel compiling problems

[b. f.]

>Heya!
>
>Anybody know what's wrong with this?
>
>## make buildworld buildkernel KERNCONF=NINJA

...

>/usr/src/sys/kern/sysv_msg.c:163: error: invalid application of 'sizeof' to
>incomplete type 'struct freebsd7_msgctl_args

This error message is suggestive. ;)


>options COMPAT_FREEBSD4
>
>options COMPAT_FREEBSD5
>
>options COMPAT_FREEBSD6

Upgrading from 7.x to 8.x, eh?  But I think you forgot to update parts
of your kernel config.  From
src/sys/conf/NOTES:

"Note that as a general rule, COMPAT_FREEBSD depends on
COMPAT_FREEBSD, COMPAT_FREEBSD, etc."

... up until m-1, where m is the FreeBSD version you are building.  So
if you have COMPAT_FREEBSD[456], you need COMPAT_FREEBSD7 as well.
(When running 7.x, you didn't need it, of course.)


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

Re: SIL Fonts

[b. f.]

On 3/3/11, Jason C. Wells  wrote:
> On 03/03/11 05:01, b. f. wrote:

> I don't _need_ ports but I do like to use them because they include
> management tools.  thanks for the response.

Right, then, I will add some ports.

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

Re: SIL Fonts

[b. f.]

>I was unable to find a port with Charis or Doulos typefaces.  Perhaps
>someone can tell me that these typefaces are part of some meta-port.  Which?

Hmm. I don't see any port with them, either, although bundling of them
is permitted, under certain circumstances, and I didn't look into the
innards of every font port.  Of course, you could always get them from
SIL and add them manually.  And I imagine that they may be accessible
via third-party texlive packages. Do you need ports for these fonts?

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

Re: GNU make doesn't understand .for? suffix rules obsolete?

[b. f.]

> In particular I was surprised
> to find out that GNU make considers
> suffix rules obsolete:
> http://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html#Suffix-Rules
>
> I didn't think the suffix rules are
> obsolete in BSD make, are they?
>

No (Although maybe some people will argue that BSD make itself is obsolete...).
But what does it matter -- gnu make still understands them, doesn't it?

> The GNU replacement for suffix rules
> are "pattern rules". Now these don't
> seem to be supported by BSD make, are they?
>

There are some implicit rules, and variable expansions can be used,
but many of the GNU constructs are not supported. See make(1), and:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/pmake/index.html

> Also, since ".for .endfor"
> construct doesn't seem to be supported
> by GNU make (please confirm or correct if I'm wrong),
> what is an alternative in GNU make?

Patterns and the foreach function:

http://www.gnu.org/software/make/manual/html_node/Foreach-Function.html#Foreach-Function


> My aim, of course, is to have
> a makefile, which would work
> on both GNU and BSD make.
> The project is comparatively simple,
> just a collection of fortran files,
> which need to be compiled and several
> executables need to be linked
> against a number of libraries.

You can limit yourself to constructs common to both makes, but if you
prefer gnu make, then why not just write makefiles accordingly and use
gmake from devel/gmake?

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

Re: Is CTM still being offered for updating FreeBSD?

[b. f.]

>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 being added every few hours.

>
>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 it
>nonetheless. If CTM is no longer an option for updating FreeBSD is
>there any reason to leave it in base? Is it still being used by a
>sufficient number of people to maintain it?

I can't answer for the maintainer, and I don't have usage statistics,
which you could probably obtain from the mailing list and WWW admins.
But the fact that it works, without requiring a lot of resources or
the need for extensive maintenance, and has the benefits that are
clearly described in the Handbook, suggest that you should leave it
alone.  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?

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

Re: Accessing a GPT drive

[b. f.]

> Os: FreeBSD amd64 w/ options GEOM_PART_GPT

What version of FreeBSD?

> I added a drive to my system which I installed win7 64. The drive is 500G.
> I gave 100G to win7. Then I created an ext2 partition with the unallocated
> space with a gparted cd.
> fdisk shows the MBR of the drive with the win7 system and data partitions
> and the ext2 partition created.

This is a bit confusing.  You didn't tell us exactly what you did with
gparted (by the way, you should be able to do this with gpart(8) in
recent versions of FreeBSD), what version of fdisk you used, or what
MBR you are referring to here (maybe a protective MBR?),  since you
claim that Win7 only installs in a GPT scheme.  Are you sure about
that? Did you try to layout a disk first, and then install Win7 into
an existing partition?  I don't have a copy of Win7 to check this, but
I've seen other accounts that didn't mention this problem, e.g.,

http://bastian.rieck.ru/howtos/windows_boot_manager/
http://forums.freebsd.org/showthread.php?t=14222

But maybe you have an EFI-based system?

> I need to access both the NTFS win7 and ext2 partitions from freeBSD. FBSD
> "sees" the drive (ada2) but does not "see" the partitions. I need to access
> the ext2 partition
> from both FBSD and win7. I have another ext2 on the other drive that both
> OSs see fine but that drive
> has MBR scheme.  Win7 only installs in a GPT partition.

How exactly did you determine that FreeBSD doesn't "see" the
partitions? By using "gpart show"?

In the past, I've found:

http://www.rodsbooks.com/gdisk/

a useful source of information about using GPT with FreeBSD and Win*,
although some of the OS-specific material is dated.

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

Re: Debian GNU/kFreeBSD

[b. f.]

> I have heard that Debian project has replaced the Linux kernel in
> their distribution with FreeBSD kernel and have released Debian
> GNU/kFreeBSD. Since this version, they will release Debian
> GNU/kFreeBSD as a "stable" port.
> What is this all about?

As you can see from their webpages, they replaced the Linux kernel
with a patched FreeBSD 8.1 kernel, but kept most of the rest of the
Debian base system and packaging system.  It's for users who prefer a
FreeBSD kernel, but want a Debian userland and packages, and don't
have a problem with the different licenses. Gentoo has a similar
project:

http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/

There are also some NetBSD-base derivatives.

>What will be consequences for FreeBSD? Will a
> lot of FreeBSD users move to that distribution?

Well, only time will tell, but I doubt that either will completely
replace the other in the near future.  There has already been some
interaction between the two projects -- I remember a few recent
changes made in FreeBSD because of feedback from Debian users and
developers.

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

Re: nedit problem

[b. f.]

Fred Boatwright wrote:
> On 02/06/11 00:53, b. f. wrote:
> > Fred Boatwright wrote:
> >
> >> After updating all ports on 8.1-RELEASE, nedit has a problem.  The right
> >> mouse button works ok in the toolbar but if it is pressed in the text
> >> area, for example to copy a block of text, the cursor changes shape and
> >> the X session becomes completely locked up.  I have to stop X and
> >> restart it.  I have tried to deinstall nedit and rebuild it but this
> >> didn't help.  It is nedit-5.5 with Motif 2.2.3.
> > This is a known problem with many Motif-based applications, arising
> > from a bug in recent versions of Xorg.  It has been corrected
> > upstream, and it is likely that this problem will be fixed when the
> > ports freeze ends shortly after the release of FreeBSD 7.4 and 8.2, if
> > not before.  If you can't wait, you can try using the patches from:
> >
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=154510
> >

> I have tried several editors that are horrible.  Axe installed from
> packages dumps core.  There were a lot of warnings that later versions
> of libraries were installed than axe was expecting.  Does the maintainer
> need to know this?

Sadly, there is no maintainer for that port.  But yes, you should file
a Problem Report (PR), so that people will know that there may be a
problem:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/index.html

> Can you tell me how to install the Xorg patch to make nedit work?  I
> have not worked with getting source code or compiling from source.  I
> can do the edit on another computer.

Get an up-to-date ports tree.  (If you don't know what that means,
read the relevant portions of the FreeBSD Handbook.)

Place the attached patch (or a trimmed version of the patch from the
PR that I cited earlier) in  ports/x11-servers/xorg-server/files under
a name like 'patch-dix__events.c', that begins with 'patch-', and
doesn't overwrite any of the existing patches.

In the ports/x11-servers/xorg-server directory, run 'make deinstall
clean install && make clean', or use your favorite third-party port
updating tool to force an update of that port.

(If you want to create a backup package of your patched version of
xorg-server, and you are not using a port updating tool with this
feature, then either 'make package' in that directory before running
the final 'make clean', or use 'pkg_create -b "xorg-server-*"'.)

I'm assuming that you are already using the latest version of
x11-servers/xorg-server; if instead you are using an earlier version,
and packages that depend on it, you will probably need to update them
as well.

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

Re: Set tty resolution using hint.sc.0.flags with VESA

[b. f.]

David Demelier wrote:
>> hint.sc.0.vesa_mode=0x1f0
...
>absolutely great! But where did you find these vesa_mode setting? It's
>not documented anywhere.

Look again: syscons(4), in the Synopsis and the "Driver Flags" section.

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

Re: nedit problem

[b. f.]

Fred Boatwright wrote:

> After updating all ports on 8.1-RELEASE, nedit has a problem.  The right
> mouse button works ok in the toolbar but if it is pressed in the text
> area, for example to copy a block of text, the cursor changes shape and
> the X session becomes completely locked up.  I have to stop X and
> restart it.  I have tried to deinstall nedit and rebuild it but this
> didn't help.  It is nedit-5.5 with Motif 2.2.3.

This is a known problem with many Motif-based applications, arising
from a bug in recent versions of Xorg.  It has been corrected
upstream, and it is likely that this problem will be fixed when the
ports freeze ends shortly after the release of FreeBSD 7.4 and 8.2, if
not before.  If you can't wait, you can try using the patches from:

http://www.freebsd.org/cgi/query-pr.cgi?pr=154510

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

Re: Why can't I install icu?

[b. f.]

> Icu is a necessary dependency for Gimp, but I can't get it to install.
> I checked UPDATING and it states that icu4 is now deprecated, and one
> should install /devel/icu.  But when I try to do that the file that is
> downloaded is icu4c, and the install goes along until it chokes with
> this error message:
>
> SUMMARY:
> *** [Total error count: 1]
>   Errors in
> [/tsformat/ccaltst/TestCalendar]
> Elapsed Time: 00:00:48.205
> *** Error code 1
> Stop in /usr/ports/devel/icu.
>
> Very frustrating.  I need to get Gimp onto my computer, and I can
> install it as a package, but if I try to upgrade the program the upgrade
> always chokes on icu at the same place, and with the same error message.
>
> Anyone?

Try again, with a clean build, after having made sure that you've
removed all remnants of the earlier icu versions; and make a
transcript of the build:

pkg_delete -fv "icu2-*" "icu-*"
script /tmp/icu.log
make -C /usr/ports/devel/icu deinstall clean install
exit

If the problem still occurs, then you should file a problem report:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html

Make sure you attach the config.log from the failed build (look for it
in the work directory of the port before cleaning up), as well as the
transcript (/tmp/icu.log) of the failed build.

If there aren't any pre-built binary packages of the latest versions
of icu and gimp available, and you don't want to wait for them to be
produced, or for the problem to be fixed; and (as apparently is the
case) the build is working, but only the post-build tests are failing;
then first disable the tests and then try to build and install icu.
You can do that by editing the port Makefile and commenting-out the
following line:

post-build test regression-test: iotest cintltst intltest

(Of course, this change will probably be wiped out each time you
update your ports tree.)

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

Re: linux PF_PACKET compatibility

[b. f.]

Da Rock wrote:
...
> I've been chasing the answer to a FreeBSD version of this (approx.
> anyway), but I needed to find out what exactly PF_PACKET was first.
> Finally found this answer here: http://www.linuxjournal.com/article/4659
>
> I looked up man socket and I can see possibilities (in my mind anyway),
> but I thought I'd be best to check if the gurus here might have a better
> idea. My reason for this is I'm attempting to build l2tpns (which
> supposedly builds on 7.2?! with no trouble), and I'm chasing the errors
> which appear to be linuxisms mostly.
>
> So in man socket simply looking at the list of protocol families I'd say
> network driver level would be PF_LINK link layer interface? Is there
> another man page I should be looking at as well?

In the past, those wishing to use similar functionality on FreeBSD
have turned to pcap(3), bpf(4), or ng_etf(4), and the underlying code.
 This kind of question is better directed to the freebsd-hackers and
freebsd-net lists.

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

Re: include file not found

[b. f.]

Da Rock wrote:
> gcc -Wall -Wformat-security -Wno-format-zero-length  -g -O3 -I.
> -I/usr/include -I/usr/local/include  -DLIBDIR='"/lib/l2tpns"'
> -DETCDIR='"/etc/l2tpns"' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER
> -DHAVE_EPOLL -DBGP -c -o arp.o arp.c
> In file included from arp.c:8:
> /usr/include/net/if_arp.h:88: error: field 'arp_pa' has incomplete type
> /usr/include/net/if_arp.h:89: error: field 'arp_ha' has incomplete type

You seem to be missing definitions of struct sockaddr, so probably
sys/socket.h is needed.

> In file included from arp.c:9:
> /usr/include/netinet/if_ether.h:96: error: field 'sin_addr' has
> incomplete type
> /usr/include/netinet/if_ether.h:97: error: field 'sin_srcaddr' has
> incomplete type

Here it looks like you're missing struct in_addr, which is in
sys/netinet/in.h (and also arpa/inet.h).

> arp.c:20: error: 'ETH_ALEN' undeclared here (not in a function)
> arp.c: In function 'sendarp':
> arp.c:29: error: storage size of 'sll' isn't known
> arp.c:54: error: 'PF_PACKET' undeclared (first use in this function)
> arp.c:54: error: (Each undeclared identifier is reported only once
> arp.c:54: error: for each function it appears in.)
> arp.c:54: error: 'ETH_P_RARP' undeclared (first use in this function)
> arp.c:57: error: 'AF_PACKET' undeclared (first use in this function)

Some of these missing parameters are Linux-specific.

> arp.c:29: warning: unused variable 'sll'
> gmake: *** [arp.o] Error 1

As you can see, porting requires some care.  It's not only a matter of
including different headers; there are some other differences that may
require patches, and we won't be able to go through this step-by-step
on the list.  You can see what FreeBSD headers a similar FreeBSD
application needs by looking at src/usr.sbin/arp, and you can get some
help with the Linux->FreeBSD part by looking at /sys/compat/linux,

http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/ofed/include/

and

http://fxr.watson.org/

; and you might be able to cheat a bit by using a compatibility layer
like devel/gnulib, but you're going to have to go through this
carefully on your own.

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

Re: Implications of missing this step?

[b. f.]

> Good Day;
>
> Running PC-BSD 8.1 with a custom kernel and new world.  I just finished
> another custom kernel and rebuilt world according to the FreeBSD
> handbook.  While reading the docs again to find an answer to a question
> about how upgraded ports are handled, I came across the following in 24.2.3;
>
> "If a custom kernel is in use, the upgrade process is slightly more
> involved. A copy of the GENERIC kernel is needed, and it should be
> placed in /boot/GENERIC. If the GENERIC kernel is not already present in
> the system, it may be obtained using one of the following methods:"
>
> I am in the process of doing #>portupgrade -af with a new custom kernel
> and stock (rebuilt) world i.e. buildkernel KERNCONF=KERNEL_011911, and
> buildworld... (after upgrading src and ports with csup).  Things seem to
> be going ok but the statements about 'old object files and libraries'
> being out of date for third party applications, make me feel as if I
> have done something wrong.  I blew away the GENERIC kernel several
> iterations of kernel builds ago.  I always start a build with #>make
> clean.  What can go wrong by not following the above step?  Is a GENERIC
> kernel always needed?

No.  The handbook is a bit misleading here.  First it starts to
mention that, after updating your base system, you will probably need
to update any ports and/or packages, too.  Then, without any warning,
it jumps abruptly into a discussion of how to update the base system
with the 'freebsd-update' method.  That method seemingly requires a
GENERIC kernel to be present, which is what the paragraph you quoted
mentions.  But you're already past that point -- you've already
updated your base system, and it seems that you built from source, so
that paragraph isn't relevant, anyway.  Just proceed with updating
your ports.  (And bear in mind that PC-BSD has some issues with using
both FreeBSD ports and the PC-BSD packaging system, so you may want to
consult their documentation as well as that of the FreeBSD project, if
you plan to use PBIs, too.)

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

Re: Which network driver for RTL8211 or 8201 NIC's?

[b. f.]

Mike Clarke wrote:
> I need to replace a failing motherboard. I'm aiming to keep the existing
> Athlon CPU so I'm tied down to to a socket AM2(+) board and the
> majority of those available seem to have nForce 630a chipsets and
> RTL8211CL or 8201EL NIC's which aren't explicitly mentioned in the
> release notes
> . I see
> that the strings RTL8211C(L) and RTL8201L (but not EL) appear
> in /usr/src/sys/dev/rgephy.c and rlphy.c but the man page for the rl
> driver only mentions RealTek 8129/8139 and I'm not sure which driver is
> built from rgephy.c.
>
> Am I going to have problems if I get a motherboard with one of these
> NIC's?

It's a bit confusing, because there are product numbers associated
with NICs, and with different individual component chipsets, and some
code is shared.  Pyun YongHyeon, who has been working on the re(4) and
rl(4) drivers in -CURRENT and -STABLE recently, could probably tell
you more (I've cc'ed him).

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

Re: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating

[b. f.]

On 12/28/10, David Southwell  wrote:
>> On 12/27/10, David Southwell  wrote:
>> >> On 12/27/10, David Southwell  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 definition from any
>> locally-modified Makefiles, and provide the same information that was
>> requested from Da Rock? (Why do I feel like a WWE announcer when I
>> type that? ...)
>>
>> b.
> I do not want to rebuild WITHOUT_IMAGEMAGICK_PERL on a running system with
> active user access which needs perl.

Oh, I didn't intend for you to do that.  (This particular problem
shouldn't arise if perl support is disabled.)  I meant to show the
output of 'make -C $PORTSDIR/graphics/ImageMagick -V PERL_THREADED',
'make -C $PORTSDIR/graphics/ImageMagick showconfig', and 'perl
--version' on a system where the build failed if you didn't define
PERL_THREADED manually. (A transcript of a failed build would also be
helpful.)  You needn't (de)install anything.

> Have you got the replies from Da Rock?

Not yet.

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

Re: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating

[b. f.]

On 12/27/10, David Southwell  wrote:
>> On 12/27/10, David Southwell  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 definition from any
locally-modified Makefiles, and provide the same information that was
requested from Da Rock? (Why do I feel like a WWE announcer when I
type that? ...)

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

Re: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating

[b. f.]

On 12/27/10, David Southwell  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 that it will build
>> > > correctly? It _does not_ actually look at what perl is installed?
>> > >
>> > > IF that is the case, then wtf? Either ImageMagick should be checking
>> > > the actual pkg installed, or the perl port should be defining this in
>> > > the make.conf, right? Seeing as perl already makes a define in
>> > > make.conf...
>> > >
>> > > Meanwhile I'll check it out. Cheers
>> >
>> > Yep you need that line in make.conf
>>
>> Who made this claim?  This is not some standard, user-configurable
>> knob -- it is only used by 5 ports, and each of them assigns a value
>> to it in the port Makefile.  It shouldn't be set in make.conf.  As for
>> why it isn't working in Da Rock's case, he hasn't answered any of the
>> questions I asked him earlier.

> I suggest you see an earlier thread on same topic [ImageMagick Upgrade
> Problem].

That thread (I'm assuming you're referring to the one in Nov. on
FreeBSD-ports) is no longer relevant after Doug's commit (which was
announced in that thread):

http://www.freebsd.org/cgi/cvsweb.cgi/ports/graphics/ImageMagick/Makefile.diff?r1=1.313;r2=1.314

The suggestion that users set that variable was a temporary hack that
should never have been needed, were it not for the earlier problems
with the port, which have since been resolved (in part, anyway).
PERL_THREADED should only be defined when it is used, and should
record whether the perl port being used is threaded, and not some
user-selected value.

The questions I originally asked were in:

http://lists.freebsd.org/pipermail/freebsd-questions/2010-December/225501.html

(This thread is a little hard to follow because it's spread between
two lists, -questions and -ports, with some replies not being sent to
-ports.)

> I also wonder if the OP's ports tree is up to date.

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.

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

Re: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating

[b. f.]

> 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 (*) built for amd64-freebsd-thread-multi
>
> And pkg_version -v:
>
> perl-threaded-5.10.1_3
>
> So its there.  Unfortunately I'm still running various updates so I

Well, it's registered in PKG_DBDIR, anyway. In general, it's possible
for the package database or the installed package to be corrupt,
although neither of these seem to be your problem. When you get a
chance, show us the output of 'make -V PERL_THREADED' and 'make
showconfig' for this port. Both of those do little more than parse the
Makefiles, so they shouldn't disrupt your other builds.

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

Re: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating

[b. f.]

> > > > 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? It _does not_ actually look at what perl is installed?
> >
> > IF that is the case, then wtf? Either ImageMagick should be checking the
> > actual pkg installed, or the perl port should be defining this in the
> > make.conf, right? Seeing as perl already makes a define in make.conf...
> >
> > Meanwhile I'll check it out. Cheers
> Yep you need that line in make.conf


Who made this claim?  This is not some standard, user-configurable
knob -- it is only used by 5 ports, and each of them assigns a value
to it in the port Makefile.  It shouldn't be set in make.conf.  As for
why it isn't working in Da Rock's case, he hasn't answered any of the
questions I asked him earlier.

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

Re: Portmaster general questions and problems

[b. f.]

> I had been using portupgrade for several years and never had any
> problems and upgrading ports was quick and simple process every week.
> But, due to portupgrade no longer being maintained and failing to work
> anymore, I have switched to using portmaster and am having nothing but
> problems, so much so that I dread updating my ports.

It isn't that portupgrade is completely unmaintained, just that the
former author and other contributors are busy, and don't spend as much
time on it.  And there isn't as much pressure for them to do so,
because portmaster can now serve as a replacement for most purposes.

>
> I'm trying to figure out what I'm doing wrong or what I don't
> understand about portmaster.  I've looked on google and can't find any
> documentation that isn't just basic stuff or rehashes of the man pages
> (which are fine for reference, but not helpful in understanding how to
> use it).

This shouldn't be difficult:  portmaster isn't a clone of portupgrade,
but the command-line options and behavior of the two are similar.
Portmaster is actually somewhat easier to use because you don't have
to worry about the extra databases that portupgrade uses. The
portmaster manpage is fairly well written, and the EXAMPLES section
demonstrates most of what the average user will need.

>
> Here is an example of a problem I run into all the time:
>
> I went to update php and I got this:
>
> ===>>> Starting check for runtime dependencies
> ===>>> Gathering dependency list for devel/libltdl from ports
> ===>>> No dependencies for devel/libltdl
> ===>  Installing for libltdl-2.2.10
> ===>   Generating temporary packing list
> ===>  Checking if devel/libltdl already installed
> ===>   libltdl-2.2.10 is already installed
>   You may wish to ``make deinstall'' and install this port again
>   by ``make reinstall'' to upgrade it properly.
>   If you really wish to overwrite the old port of devel/libltdl
>   without deleting it first, set the variable "FORCE_PKG_REGISTER"
>   in your environment or the "make install" command line.
> *** Error code 1
>
> Stop in /usr/ports/devel/libltdl.
>
> ok, so libltdl-2.2.10 is already installed?  Why is that an issue?
> Why doesn't portmaster just happily skip it since it's already
> installed?  What am I not understanding here?  Or am I using portmaster
> wrong?

Remember that portmaster is just a helper script, and that it relies
on the ports infrastructure to perform many tasks, just as portupgrade
does.  So problems like this may occasionally arise from a problem
with portmaster, but more often they are a problem within the ports
tree itself.  Here you are probably running afoul of the recent
autotools changes.  Make sure that your entire ports tree is
up-to-date, and then read the 20101208 entry in ports/UPDATING and
follow the instructions there (or just deinstall all of the old
autotools -- the new versions should be automatically installed as
needed).  You should routinely read the latest entries in
ports/UPDATING before updates, as recommended, to avoid these kinds of
problems.

>
> Portmaster also doesn't seem to understand when ports are already
> up-to-date, so doing this:
>
> portmaster php5-*
>
> To update all the php5 ports causes portmaster to re-install things
> that are already up to date.  Is this expected behavior?  if so, how
> can I upgrade ports without typing each one my hand.  I'd rather not
> run portmaster with -a since I don't want to blindly update everything.

This is not the expected behavior, and portmaster is designed to avoid
the need for most individual updates, and to update as few ports as
possible by default.  In fact, it's default settings are more
conservative in this regard than are those of portupgrade. Are you
sure that it is actually doing more than is needed?  If you provide
build transcripts, and lists of what ports/packages are installed on
your machine, then we may be able to see if this is the case.

>
> Is there a good tutorial on portmaster somewhere that can help an some
> get started with it?  Is portmaster the best tool for updating ports?

Read the portmaster manpage, particularly the EXAMPLES section.  Yes,
right now portmaster is probably the best choice of updating software
for the average user in the Ports tree.  I use my own scripts, but
then I just want speed, and not all of the portmaster features, and I
can fix things when there are problems.

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

Re: pkg_info and an active /usr/ports is slow

[b. f.]

> Just wondering about the interaction of pkg_info (no args) and having a
> ports directory.
>
> Without it it's blazing fast, with it it is just slow and sometimes just
> breaks during the listing.
>
> There is nothing in the man page about it reading the ports directory or
> why it would want or need to.

Are you sure that this is actually the case?  From a cursory look at
the source code
( /usr/src/usr.sbin/pkg_install/info/* ), I don't see how the mere
presence of a populated PORTSDIR could affect "pkg_info", at least for
the most recent version (

# pkg_info --version
Package tools revision: 20101012

).  Of course, if by "active" you mean that you are in the process of
building, installing, or removing a port or package while running
"pkg_info" at the same time, then this obviously would slow down both,
because, apart from the usual delays involved in time-sharing, both
may be attempting to simultaneously read and/or write to PKG_DBDIR, or
other parts of the same disk. It is best to avoid such a situation.

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

Re: randomising tracks: scripting question

[b. f.]

Frank Shute wrote:
>I generally play my tracks of an album like so:
>
>for track in $(cat trombone_shorty-backatown.m3u); do
>mplayer $track
>done
>
>They then play in the correct order.
>
>How would I go about randomising the order of play using
>sh (preferably) or perl?

cat trombone_shorty-backatown.m3u | xargs mplayer ... -shuffle

or

mplayer ... -playlist trombone_shorty-backatown.m3u -shuffle

if they are in a uncommented, one-absolute-path-per-line format
without extended directives?

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

Re: ImageMagick, Djvu, and Perl-threaded - marked as IGNORE when updating

[b. f.]

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 the port WITHOUT_IMAGEMAGICK_PERL, if
you don't need perl support; or fix the checks that are failing.  What
precisely is the message displayed when you've explicitly selected
WITH_THREADS, WITH_IMAGEMAGICK_PERL, and WITH_IMAGEMAGICK_DJVU?  Is it
a message generated by the ImageMagick Makefile, or by portupgrade?
If it is generated by the Makefile ( "... Perl is non-threaded.
Reinstall Perl with threads or undefine WITH_IMAGEMAGICK_PERL."), and
you've selected the above three options, then what is the output of
"perl --version" and "make -C $PORTSDIR/*/ImageMagick -V
PERL_THREADED"?

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

Re: where can i download freebsd4.4?i need it ,thanks

[b. f.]

yuan huajie wrote:
>where can i download freebsd4.4?i need it ,thanks

ftp://ftp-archive.FreeBSD.org/pub/FreeBSD-Archive/old-releases/

in the subdirectories corresponding to the architectures and versions
of your choice.

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

Re: Well, I broke it! FreeBSD V8.1 release

[b. f.]

dave wrote:
...
>I was trying to disable the console screensaver, and found that in
>sysinstall, there is no way to select "none" as an option.
>
>So I went and edited /etc/rc.conf to comment out the line:-
>Saver="fire" (or whatever it is)
>
>I put a ; at the beginning of the line, and now FreeBSD wont come up,
>showing an error (unexpected ;) and leaving me with a # prompt.
>
>How do I get to re-edit rc.conf, to correct the problem, as all command
>line commands result in a "not found" error.

You didn't provide much information, but probably what happened is
that your defective rc.conf caused an error when booting, and your
normal boot aborted and dropped into "single-user". This typically
means that some partitions that are mounted by default during a normal
boot and that contain editors and other programs are not initially
mounted.  So probably if you did something like:

fsck -p /
mount -uw /
swapon -a
mount -a

you could then edit /etc/rc.conf with your favorite editor. Or you
could just use sed, ed, or vi from /rescue, or from the release media,
to make the necessary changes, rather than attempting to mount all
partitions.

>
>Also.  What's the "Correct" way to disable a console screensaver?
>
>Sysinstall alows you to select and enable one, but not remove it!

On the fly, you can use vidcontrol -t ...

To change the default setting, comment out or delete the  "saver=..."
line, or change it to

saver="NO"

which is what is originally in /etc/defaults/rc.conf.

Sysinstall is only one tool you can use to install or configure the
system.  It's not necessary, and for minor changes like this, it's not
the method of choice.

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

Re: 'Broadcom Wireless b/g (BCM4315/BCM22062000)'

[b. f.]

On 11/16/10, b. f.  wrote:
...
>
> ttp://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/144724

The above should be http://...  , of course.

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

Re: 'Broadcom Wireless b/g (BCM4315/BCM22062000)'

[b. f.]

On 11/16/10, Chris Brennan  wrote:
> On Mon, Nov 15, 2010 at 11:17 PM, b. f.  wrote:
>
>> Chris Brennan wrote:
>> ...
>> >My Hiccup as the subject suggests is about my Wireless Card.
>> >I have been following the handbook (
>> >http://www.freebsd.org/doc/handbook/config-network-setup.html) on how to
>> use
>> >64-bit Windows drivers coupled w/ ndisgen to get my wireless card
>> > working.
>> I
>> >got ndisgen to generate a kernel module but it immediately caused my
>> laptop
>> >to reboot when the kernel was loaded. This left me scratching my head. I
>> >think I might need firmware (I remember having to extract firmware from
>> the
>> >driver for linux).
>> >
>> >pciconf shows the following:
>> >
>> >[root at BlackDragon [~]# pciconf -lv | grep -A3 0x4315
>> >none8 at pci0:8:0:0:   class=0x028000 card=0x137c103c chip=0x431514e4
>> >rev=0x01 hdr=0x00
>> >vendor = 'Broadcom Corporation'
>> >device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)'
>> >class  = network
>> >[root at BlackDragon [~]#
>> >
>> >The laptop is an HP dv2845SE and it's running FreebSD64-8.1. Let me know
>> if
>> >I missed anything.
>>
>> I'm assuming that by "FreebSD64", you mean the amd64 version of
>> FreeBSD.  Have you tried using a recent version of the native bwn(4)
>> driver, together with the net/bwn-firmware-kmod port, rather than
>> ndis(4)?
>>
>>
>> b.
>>
>
> Yes, by FreeBSD64 I am implying amd64, an oversight on my part. I was told
> the native bwn/bwn-firmware-kmod non-functional currently. Was I misinformed
> about this?
>

I don't use it myself, but I have seen exchanges on the mailing lists
from time to time that would suggest that it is working, at least for
some hardware.  The only PR that I can see in the database from
someone using a card similar to yours was a report of a problem that
only arose in a specific configuration, and that problem seems to have
been solved:

ttp://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/144724

However, you could ask weongyo@ (the developer who has done most of
the work on it) directly.  If you are feeling bold, you could try
9-CURRENT, where you will be able to use the latest versions of the
driver and associated wireless infrastructure.

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

Re: 'Broadcom Wireless b/g (BCM4315/BCM22062000)'

[b. f.]

Chris Brennan wrote:
...
>My Hiccup as the subject suggests is about my Wireless Card.
>I have been following the handbook (
>http://www.freebsd.org/doc/handbook/config-network-setup.html) on how to use
>64-bit Windows drivers coupled w/ ndisgen to get my wireless card working. I
>got ndisgen to generate a kernel module but it immediately caused my laptop
>to reboot when the kernel was loaded. This left me scratching my head. I
>think I might need firmware (I remember having to extract firmware from the
>driver for linux).
>
>pciconf shows the following:
>
>[root at BlackDragon [~]# pciconf -lv | grep -A3 0x4315
>none8 at pci0:8:0:0:   class=0x028000 card=0x137c103c chip=0x431514e4
>rev=0x01 hdr=0x00
>vendor = 'Broadcom Corporation'
>device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)'
>class  = network
>[root at BlackDragon [~]#
>
>The laptop is an HP dv2845SE and it's running FreebSD64-8.1. Let me know if
>I missed anything.

I'm assuming that by "FreebSD64", you mean the amd64 version of
FreeBSD.  Have you tried using a recent version of the native bwn(4)
driver, together with the net/bwn-firmware-kmod port, rather than
ndis(4)?


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

Re: Too many binary packages are missing

[b. f.]

On 10/17/10, Ian Smith  wrote:
> On Fri, 15 Oct 2010, b. f. wrote:
>  > On 10/15/10, Ian Smith  wrote:
...
> Just to check that I get it .. for packages-8-stable, an 8.0-RELEASE-p2
> kernel + world is used to _build_ these, is that right?

Yes, on i386, although this will change as some stable branches reach
their end-of-life.

>So they should
> then install fine on any later 8.x system too?

Yes, most of the time, although there may be uncommon cases in which
they will not work as expected.

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

Re: Too many binary packages are missing

[b. f.]

On 10/15/10, Yuri  wrote:
> On 10/15/2010 11:54, b. f. wrote:

> That's quite a delay. This makes it very visible to users.

Well, yes, to some.  As to whether it's an unreasonably long delay,
I'm not sure, considering the amount of work and resources required.
After all, we're talking about lag of less than three weeks.  You can
always talk to the committers doing the work, to get a better idea of
the schedule, and if it can be accelerated.

>> http://pointyhat.freebsd.org/errorlogs/i386-8-packages-latest/misc/kdeutils-4.5.2.tbz
>>
>> or, better yet, build your own.
>>
>
> See, this is a problem. I only have one very slow i386 and it takes forever.

Well, I have similar problems.  I go to the trouble of building from
source during periods of low use, after having chosen and configured
my software so that I am installing as little as possible, but it
still takes longer than I would like on my older i386s.  You could
configure pointyhat as a secondary source for new packages, and look
into whether you could get access to a faster i386/amd64 machine that
could be used to make packages for your slower computer.  Or you could
try to speed builds using devel/ccache and/or, if you can set up a
cluster, devel/distcc.

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

Re: Too many binary packages are missing

[b. f.]

On 10/15/10, Yuri  wrote:
> On 10/15/10 09:39, b. f. wrote:
>> On 10/15/10, Ian Smith  wrote:
>> ...
>>
>>
>>> http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable works,
>>> it's what portupgrade looks at on an 8.1-STABLE system, but it's a bit
>>> sad finding the last directory updated at 1st October.  I checked just
>>> one subdir, sysutils, and the newest file there is 30th September.
>>>
>> http://pointyhat.freebsd.org/errorlogs/packagestats.html
>> http://portsmon.FreeBSD.org/portsuploadstatus.py
>>
>> ...
>>
>>
>>> Er, 8-STABLE (packages) is for currently 8.1-STABLE (world/kernel), no?
>>>
>> No.  I thought the 8-STABLE packages were from a recent snapshot of
>> 8-STABLE, because that's the way that tinderboxes are set up.
>> However, I checked, and actually a version of the last supported
>> stable branch of 6.*, and some versions of the _oldest_ supported
>> stable branches of 7,8 are used. Right now, for i386 it's:
>>
>> 6.x-stable -->  6.4-RELEASE-p9
>> 7.x-stable -->  7.1-RELEASE-p12
>> 8.x-stable -->  8.0-RELEASE-p2
>> 9.x-current -->  a snaphot of 9-CURRENT
>>
>
> For example I am watching the update process of one i386 system.
> portupgrade just failed to find one more package:
> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8-stable/All/kdeutils-4.5.2.tgz
>
> Is it misconfigured, wrong path? I didn't touch this part of
> configuration at all.

Right now I only see:

ftp://ftp.freebsd.org:21/pub/FreeBSD/ports/i386/packages-8-stable/All/kdeutils-4.5.1.tbz

from 29 Sept. 2010. The port, misc/kdeutils4, was updated on 5 Oct.
2010, and the latest 8.x-stable i386 has not yet been placed on the
servers.  But this is one of those cases I mentioned, where it seems
that pointyhat has a package that the ftp servers do not. (I don't
know why.)  So you could try:

http://pointyhat.freebsd.org/errorlogs/i386-8-packages-latest/misc/kdeutils-4.5.2.tbz

or, better yet, build your own.

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

Re: Too many binary packages are missing

[b. f.]

On 10/15/10, Ian Smith  wrote:
...

>
> http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable works,
> it's what portupgrade looks at on an 8.1-STABLE system, but it's a bit
> sad finding the last directory updated at 1st October.  I checked just
> one subdir, sysutils, and the newest file there is 30th September.

http://pointyhat.freebsd.org/errorlogs/packagestats.html
http://portsmon.FreeBSD.org/portsuploadstatus.py

...

> Er, 8-STABLE (packages) is for currently 8.1-STABLE (world/kernel), no?

No.  I thought the 8-STABLE packages were from a recent snapshot of
8-STABLE, because that's the way that tinderboxes are set up.
However, I checked, and actually a version of the last supported
stable branch of 6.*, and some versions of the _oldest_ supported
stable branches of 7,8 are used. Right now, for i386 it's:

6.x-stable --> 6.4-RELEASE-p9
7.x-stable --> 7.1-RELEASE-p12
8.x-stable --> 8.0-RELEASE-p2
9.x-current --> a snaphot of 9-CURRENT

Other architectures may use slightly different versions.  This is an
attempt to build packages that work on the all stable branches of all
supported releases, although obviously this may occasionally fail.

...

> There does seem to be more delay in building Latest/ packages lately,
> compared to a couple of years ago.  I did a huge portupgrade -aFPP back
> on Sep 13 (about 450 packages since 8.0-R, 850MB incl xorg etc) but
> didn't get to upgrading then (record wettest September, solar power,
> broken backup generator, long story :) but did another to catch up on
> Sep 19, which found some more packages updated between those dates,
> however looking at the (preserved by fetch) dates these packages were
> built, it's clear that building (eg here for 8-stable i386) is done in
> batches that run for several hours, but are only done several times per
> month, at best.

On some architectures, the building seems to be done more often than
the uploading to the ftp server.  (Perhaps some of these are
incomplete builds.) So in some cases you can actually get more recent
packages directly from pointyhat, but I think that they are only
intended for testing purposes, and not for mass distribution.  Pav
told me that he uploads amd64 packages within 24 hours of the
completion of a build, although it takes further time for them to
propagate to the mirrors.

> eg, I got large batches all dated:
>
>  May 27-28 (about 40)
>  Jun 13 (plus a few Jun 14 and 15, couple on Jul 9, then not till ..)
>  Jul 23, 24, 25 (about a dozen)
>  Jul 28 (about 120)
>  Jul 29, Aug 9, 10 (half a dozen)
>  Aug 15, 16 (about 80)
>  Aug 21, plus a few more Aug 22, 24 (about 100, then none till ..)
>  Sep 8, 9, 10 (about 60)
>
> And as mentioned above, some on Sep 30 I haven't got yet, nothing since.
>
> So it's a bit spasmodic and irregular, and there are gaps of up to
> several weeks between, leading to potential for quite a few out of date
> major packages (in my case including php5 and all of kde3)
>
> The last time I noticed such big delays between updated ports and their
> packages (IIRC, 2007) Kris Kennaway put in a successful word to someone
> .. who should we be bugging these days?

portmgr@ -- I think linimon@, pav@, and a few others are in charge of
the package-building machines.  On some architectures (e.g., ia64,
powerpc and sparc64), I think that the paucity of available hardware
limits the frequency of the builds, but I'm not sure about i386.  The
available logs show that the last builds for 8.x-stable i386 were on:

20100804
20100808
20100815
20100820
20100821
20100823
20100908
20100927
20101007

I don't know the rationale behind the schedule, although I heard that
some work was recently being done on parts of the cluster, and that
some exp-runs were made.

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

Re: VIA EPIA 5000 and ACPI Cx levels

[b. f.]

On 10/10/10, Bruce Cran  wrote:
> On Sunday 10 October 2010 21:49:30 b. f. wrote:
>
>> If it has an i8254, that can also be used in one-shot mode if
>> hint.attimer.0.timecounter=0 is used, since r212778.
>
> Thanks, I didn't know about that. After enabling it things are quite
> different: kern.eventtimer.periodic is now 1, and setting
> hw.acpi.cpu.cx_lowest=C2 results in 100% time being reported as being spent
> in
> C2 mode according to dev.cpu.0.cx_usage - using C3 causes the system to
> hang.
> Shouldn't a fully loaded CPU spent more time in C1 state though? When I run
> a
> program that results in 0% idle time cx_usage still reports that no time was
> spent in C1 state.

I'm not sure what is going on here: if you set
hint.attimer.0.timecounter="0" and kern.eventtimer.timer="i8254" in
/boot/loader.conf, then the system should try to use the i8254 in
one-shot mode, unless you've specifically set periodic mode.  If
kern.eventtimer.periodic=1, then you are _not_ using one-shot mode.
If it was 0 before your latest changes, then you were previously using
one-shot mode.  But, as I wrote earlier, for kern.hz<128 and
kern.eventtimer.singlemul=1, periodic mode may result in more sleeping
than one-shot mode, though at a price.  This may be what you are
seeing.

The C-state used is determined in acpi_cpu_idle() in
src/sys/dev/acpica/acpi_cpu.c, if you are using ACPI.  I think that if
the latency for the C2 state is low enough, the number of callouts and
interrupts sufficiently low, and the scheduler quanta large enough,
it's possible for your machine to mostly use C2 rather than C1.  You
can take a look at the algorithm, and make some experiments.  Note
that bus mastering activity, which can include routine USB polling,
may prevent the use of C3.  This or the high latency of C3 may account
for your machine not using it. Also note that you shouldn't use a
LAPIC timer if you are using C3 or deeper sleep states.

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

Re: Too many binary packages are missing

[b. f.]

On 10/14/10, b. f.  wrote:
> On 10/14/10, Yuri  wrote:
>> On 10/13/2010 17:24, b. f. wrote:
> ...
>> My system is 8.1-stable and portupgrade looks at
>> http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-stable
>> No sure what is packages-8-stable, shouldn't it be the same?
>
> As far as I know, there are no packages for 8.1-STABLE on the project
> servers, although probably both the packages for 8.1-RELEASE and
> 8-STABLE will work in your case.

I should mention that some third-party servers have packages that
aren't on the project servers; for example, you can find packages for
some versions of 8.1-STABLE on:

http://freebsd-custom.wikidot.com

And of course there may be other sources, too.

b.





8.1-STABLE is closer to 8.1-RELEASE
> than it is to 8-STABLE at this point (the release engineering team is
> hoping to release 8.2 around the end of the year), so if you want to
> be conservative, use the (older) packages for 8.1-RELEASE.  Of course,
> you can also build your own packages via Ports.
>
>> System should at least have binaries of all packages that are required
>> to install kde4/gnome/firefox/thunderbird -- major x11 environments and
>> programs people use.
>
> There are, at least for the supported releases, and for snapshots of
> 9-CURRENT and 6,7,8-STABLE.  Occasionally the latest version of a
> commonly-used package breaks on -STABLE, but it is usually fixed
> fairly quickly.
>
> b.
>
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Re: Too many binary packages are missing

[b. f.]

On 10/14/10, Yuri  wrote:
> On 10/13/2010 17:24, b. f. wrote:
...
> My system is 8.1-stable and portupgrade looks at
> http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-stable
> No sure what is packages-8-stable, shouldn't it be the same?

As far as I know, there are no packages for 8.1-STABLE on the project
servers, although probably both the packages for 8.1-RELEASE and
8-STABLE will work in your case.  8.1-STABLE is closer to 8.1-RELEASE
than it is to 8-STABLE at this point (the release engineering team is
hoping to release 8.2 around the end of the year), so if you want to
be conservative, use the (older) packages for 8.1-RELEASE.  Of course,
you can also build your own packages via Ports.

> System should at least have binaries of all packages that are required
> to install kde4/gnome/firefox/thunderbird -- major x11 environments and
> programs people use.

There are, at least for the supported releases, and for snapshots of
9-CURRENT and 6,7,8-STABLE.  Occasionally the latest version of a
commonly-used package breaks on -STABLE, but it is usually fixed
fairly quickly.

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

Re: Too many binary packages are missing

[b. f.]

>I am updating i386 system (portupgrade -aP) and whole lot of binary
>packages are missing.
>For example, gcc-4.5.0, qt4-corelib are examples of large packages that
>are missing that don't require too many dependencies and are very basic.
>
>I know, it may be caused by failed dependencies, copyright restrictions,
>etc. But it's hard to imagive why they are missing for these two: no
>copyright restrictions, and almost no dependencies.
>
>This unfortunately slows down many people.
>Is there any solution to this problem? Maybe people just forget about
>this build server and some minor fix wil help?

Maybe some other ports have licenses that prevent the distribution of
packages, but not lang/gcc45 and devel/qt4-corelib.  Where did you
instruct portupgrade and the base system package tools to look for
them?   Is your ports tree up-to-date?  I see, on the ftp servers:

http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/lang/gcc-4.5.2.20100923.tbz

http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-7-stable/lang/gcc-4.5.2.20100923.tbz

http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/lang/gcc-4.5.0.20090924.tbz

http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/lang/gcc-4.5.1.20100701.tbz

ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/lang/gcc-4.5.2.20100923.tbz

http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9-current/lang/gcc-4.5.2.20100923.tbz

Also:

http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/devel/qt4-corelib-4.6.3.tbz

...

etc.  Why did you think that they were missing?  Incidentally, the
latest version of lang/gcc45 is a snapshot of gcc 4.5.2, so ports or
packages that want gcc 4.5.0 are outdated.

There are localized versions of the stable OpenOffice port available
for FreeBSD 8-* (and some older ones for FreeBSD 7-* ) available at:

http://ooopackages.good-day.net/pub/OpenOffice.org/FreeBSD/

although the latest snapshots appear only to be built for U.S. English
and Japanese at that server.

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

Re: How to obtain which interrupts cause system to hang?

[b. f.]

>  PID USERNAMETHR PRI NICE   SIZERES STATETIME   WCPU COMMAND
>   11 root  1 171 ki31 0K16K RUN 24.9H 86.47% idle: cpu0
>   14 root  1 -44- 0K16K WAIT   689:52 10.25% swi1: net
>2 root  1 -68- 0K16K sleep  207:35  4.69% ng_queue0
>   40 root  1 -68- 0K16K -  101:37  1.46% dummynet


It looks like there's a bit going on here: you're using dummynet and
netgraph, too?  If this setup is unstable, or otherwise problematic,
I'd suggest asking on the freebsd-net mailing list.  I don't have much
experience with some of these utilities, and I've haven't been running
FreeBSD 7-* for a long time, so I've lost track of what problems have
been fixed and back-ported.  You may also want to look at your network
and polling MIB and debugging variables, to see if they indicate any
problems.

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

Re: VIA EPIA 5000 and ACPI Cx levels

[b. f.]

>I recently upgraded to HEAD on my VIA EPIA C3 box, and had thought about
>trying out the new one-shot timer mode. Reading mav@'s email it seems that
>since it doesn't have LAPIC or HPET timers it won't work. However I thought I
>should still get power savings by using higher Cx levels, but setting
>hw.acpi.cpu.cx_lowest to C3 I'm only seeing 0.8% time spent in C2 mode, the
>rest being in C1. The CPU's idle so I don't understand why it's not going into
>deeper sleep modes. Is this likely to just be an ACPI bug?

If it has an i8254, that can also be used in one-shot mode if
hint.attimer.0.timecounter=0 is used, since r212778.  But for low
values of kern.hz, I've found that periodic mode can result in fewer
interrupts (albeit increased latencies and lower accuracy in
accounting) than one-shot mode, if kern.eventtimer.singlemul=1.  As
for the power-saving states, are you using a simple 'sysctl
dev.cpu.0.cx_usage' to find the percentages?  If you're doing
something more involved, you may be affecting the measurements.  Also,
does the system think that the deeper sleep states are available on
your machine?  If so, what are their latencies?  If they are high,
they may be used less often, or not at all.  Did you follow some of
the other recommendations to allow more sleeping, like at:

http://wiki.freebsd.org/TuningPowerConsumption

? Or apply mav's extra patch to further reduce interrupts:

http://people.freebsd.org/~mav/tm6292_idle.patch

?

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

Re: How to obtain which interrupts cause system to hang?

[b. f.]

> How to obtain what nasty happen, which process take 36-50% of CPU
> resource?

It partly depends upon the version of the OS that you are running,
your hardware, and your configuration. 2008 interrupts/sec is high,
but not improbably so, for kern.hz>=1000, and not beyond the
capabilities of today's average computer, although it may not be
optimal for your workloads.  So it may not actually be a problem with
too many interrupts, but rather with some erroneous system accounting.
 This can happen, for example, if your computer is using some of the
deeper power-saving C-states, but using them poorly, as for example
in:

http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019383.html

So you may want to examine, and perhaps adjust, your choice of kernel
timers, kern.hz, and power-saving settings.  Device polling can also
be a factor, if you are using it.

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

Re: Like it or not, Theo is having a good laugh ..

[b. f.]

>"Surrilous" isn't an English word, nor an obvious typo of one, so I
>have no idea what you mean here.

He probably meant "scurrilous", which seems obvious to me.  Look, can
we move on now?  Yes, export restrictions will apply, in the U.S. and
-- what seems to have been overlooked in this thread -- _elsewhere_,
regardless of the license text.  The Canadians who were commenting
unfavorably on U.S. laws may want to look over their own controls,

http://www.international.gc.ca/controls-controles/assets/pdfs/documents/exportcontrols2007-en.pdf

which leave them open to prosecution if they are exporting some
software that might appear innocuous.  The same can be said for many
other countries.  We're not going to resolve these problems in this
thread.


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

Re: Upgrading to higher major version directly or via small steps?

[b. f.]

>I can't understand why should I use this "adm" tool instead of
>standard method, described in /usr/src/Makefile.

List subscribers generally ask that those sending messages to the list
place their replies below quoted material, rather than above it.

If you read /usr/src/UPDATING, you will see:

"To rebuild everything and install it on the current system.
---
 # Note: sometimes if you are running current you gotta do more than
# is listed here if you are upgrading from a really old current."

This same statement is valid with regard to releases, and the -STABLE
branches.  Engelschall's adm toolkit and associated scripts attempt to
"do more than is listed here," as Engelschall described clearly at the
link that Washington gave you,

http://people.freebsd.org/~rse/upgrade/

'for upgrading from X-STABLE to (X+1)-STABLE ... the usual "build and
install everything from source" does not work or at least requires
additional preparations.'  I would qualify that "does not work" with a
"sometimes".  Of course you don't have to use this stuff, but you may
want to at least look through his scripts, to see if some of the steps
are applicable to your machines.  In any event, before you attempt a
major upgrade, you should back up your data, so that it will not be
lost if something goes wrong.  Also, you may want to consider simply
wiping your disks and starting afresh with new binary installation,
rather than attempting to upgrade directly.  Sometimes that is easier.
 You can always customize it later.

>And it's not an answer to this question:
>6.2 to 7.3 is which one of the folowing:
>- 6.2->6.4->7.0->7.3
>or
>- 6.2->7.3 directly?

See below.

>2010/10/4 Odhiambo Washington :
>>
>>
>> On Mon, Oct 4, 2010 at 4:47 PM, c0re  wrote:
...
>>> I'm interested in 2 updates:
>>> - from 6.2 to 7.3
>>> and
>>> - from 6.2 to 8.1
>>>
>>> Can I update directly from 6.2 to 7.3? like set RELENG_7_3 in supfile and
>>> make csup. Or I should update to 6.4, then to 7.0, and then to 7.3?
>>>
>>> And same question about upgrading from 6.2 to 8.1 - can i csup directly to
>>> 8.1? If not - why is it so?
>>>

You might as well do both updates in just one step.  You probably
won't gain much by breaking it up into smaller steps, and that will
take longer.  It may be quicker and safer just to start with a new src
collection, obtained via csup, svn, release media, or tarballs, rather
than attempting to bring a very old src collection up to date.

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

Re: Massive portupgrade without being interrupted by configuration screens?

[b. f.]

 > Are there any adverse side effects if I use portupgrade some of the
> time, and postmaster other times?

Probably not, if you keep your portupgrade portsdb and pkgdb
up-to-date, and you are not doing anything special with pkgtools.conf,
portmaster.rc, or environment variables.  But you don't really need
both, or, for that matter, either of them.  For instance, you could
just use the base system utilities and do something like:

pkg_version -qol '<' | cut -f 1 -d ' ' | xargs -o -t -I % make -C
/usr/ports/% config-recursive

(For a speed-up, if you are sure your INDEX is synchronized with the
rest of your ports tree, you could add the -I flag to the above
pkg_version call.)

> Reason for wanting to do all "make config"s beforehand is not only
> efficiency and ability to run unattended, but the ability to recover
> from a typo at the config dialog interface, which can be confusing,
> on when to press spacebar, tab, enter, up- and down-arrows.

This is what the portupgrade -C/-c flags are for.  if you want to do
the configuration as a completely separate step from the updating, for
whatever reason, you could run 'portupgrade -can', for example.

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

Re: PDF to HTML translations

[b. f.]

On 9/5/10, b. f.  wrote:
>>What PDF to HTML translators, other than pdftohtml, am I likely to be
>>able to find in ports?  I went looking for pdf2html, expecting to find
>>that there, but no luck.
>
> Off the top of my head:
>
> OpenOffice
> graphics/xpdf (via pdftotext -htmlmeta, simplistic)
> graphics/poppler-utils (pdftohtml)
>

I guess that you could also use converters/pdf2djvu + djvutoxml from
graphics/djvulibre[-nox11].

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

Re: PDF to HTML translations

[b. f.]

>What PDF to HTML translators, other than pdftohtml, am I likely to be
>able to find in ports?  I went looking for pdf2html, expecting to find
>that there, but no luck.

Off the top of my head:

OpenOffice
graphics/xpdf (via pdftotext -htmlmeta, simplistic)
graphics/poppler-utils (pdftohtml)

I'm guessing there are others, too.  Or maybe, you could use Adobe's
service.  From:

http://www.adobe.com/products/acrobat/access_onlinetools.html

"Adobe PDF Conversion by Email Attachment
If the Adobe PDF file is on local media, such as a hard drive, CD-ROM,
or internal server, it can be submitted as a MIME attachment to an
e-mail message. All converted Adobe PDF documents will be sent back to
the sender as MIME attachments. For plain text, mail the attached PDF
to pdf2...@adobe.com. For HTML, mail the attached PDF to
pdf2h...@adobe.com."

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

Re: FreeBSD, GPGPU and OpenCL/CUDA

[b. f.]

On 8/20/10, Eduardo  wrote:
> On Fri, 20 Aug 2010 13:24:16 +
> "b. f."  wrote:

> Reading documentation, thanks b. f. I'm already on freebsd-hackers
> list. Is that the correct list for this topic?

If you have a specific technical question about FreeBSD internals,
then freebsd-hackers is probably a good place to ask.  -hackers is a
low-volume list, and the subscribers will not be happy if there are a
flood of very general inquiries or chat, or if the person who is
asking questions hasn't thought about them beforehand.  -arch is even
more conservative, and solely for questions about the direction of the
base system, especially the kernel.  -ports may also be a good place
to ask about porting software.

> Not only compilers for Fortran or other languages but for new
> architetures, Cluster of SMP CPUs with GPU attached.

Okay.  Maybe we'll see a convergence of the two in the medium/long
term.  Right now, interested parties need to look at the available
hardware, and then talk to the vendors about whether they would be
willing to support a port of their software to FreeBSD, and
_specifically_, what is needed.  For example, we faced a similar
situation with the newer Nvidia GPUs not so long ago.  Some key
developers like John Baldwin got involved, and determined what changes
needed to be made in the FreeBSD base system in order to support the
newer hardware and graphics drivers.  It would have been nice to get
an open-source driver, but since Nvidia wasn't willing to do that,
FreeBSD  chose to meet them half-way.  Probably a similar effort will
be needed for CUDA.  Someone should look at the requirements, and have
a _detailed_, _sustained_ discussion with Nvidia and the FreeBSD
Foundation.  If, for example, KMS is needed, then the Foundation may
be willing to invest in that, because it will probably also be needed
for new graphics drivers and Xorg, anyway.  Robert Noland was working
on it, but he was doing it largely by himself in his spare time, and
then he got a new job and had to slow down considerably, if not stop
altogether.
...

> For now i'm going to port my hpc app to FreeBSD.

Good.  You may want to consider discussing any substantial effort
first on -ports, to avoid duplication of effort, and to see if there
are any better alternatives available.

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

Re: FreeBSD, GPGPU and OpenCL/CUDA

[b. f.]

...

> MPI is typically dependent on the network not OpenMP.  OpenMP 3.0 can
> be made more scalable if there's tasks built-into the kernel that can
> be cleanly exposed to userland.  (Like OpenSolaris + libtask from
> Moinak is a good example)

If you have a specific set of modifications in mind, then you should
bring them up on freebsd-hackers, for example.  There are active users
of OpenMPI around ( e.g.,

http://www.bsdcan.org/2010/schedule/events/169.en.html

, and I'm sure they would be willing to discuss improvements.

>> 2) HPC ready compiler.. (Sorry guys, but LLVM is just
>> not production ready for this task and is missing Fortran)
>

Not ready now, perhaps -- but development there is fairly rapid, and
the switch to llvm, if there is to be one, is still some time off.
However, later versions of gcc are in ports, there are some
discussions regarding the revival of the icc port, and there is work
underway to allow users to more easily use alternative compilers and
toolchains for the base system as well as for ports:

http://www.freebsd.org/news/status/report-2010-01-2010-03.html#Out-of-Tree-Toolchain

>
>> 3) IB network drivers
>
>Don't know the status of Infiniband drivers, are there drivers?

There is a port of of the Open Fabrics Enterprise Distribution underway:

http://svn.freebsd.org/viewvc/base/projects/ofed/

And there is:

http://svn.freebsd.org/viewvc/base/head/sys/contrib/rdma/

>> 4) Hardware vendor to deliver a complete solution + support
>> (iXsystems?)

Well, that's not up to us. All we can do is port more software and
encourage people to use it.  And "we" includes "you".

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

Re: Xorg Problems

[b. f.]

Warren Block wrote:
>On Thu, 19 Aug 2010, Ondrej Majerech wrote:
>> On 08/19/2010 15:02, Warren Block wrote:
>>>
>>> Don't need it in FreeBSD, either. In fact, using it in FreeBSD often
>>> causes hesitant input characters that only show up when you move the
>>> mouse. Or a draggy mouse. Or both.
>
>Finally got motivated to put together a little writeup on this:
>
>http://www.wonkity.com/~wblock/docs/html/aei.html

Isn't your summary (and your last section, despite it being
tongue-in-cheek) misleading, because it says that "AllowEmptyInput" is
bad, when you actually mean that it is _good_, and that _disabling_ it
in Xorg.conf is bad? Or am I missing something?

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

Re: Documentation on how to build 32bit applications on amd64?

[b. f.]

 On 08/14/2010 04:05, Tijl Coosemans wrote:
> > There are patches for CURRENT here:
> > http://lists.freebsd.org/pipermail/freebsd-arch/2010-July/010470.html
> >
>
> Thank you Tijl,
>
> cc-m32-2.diff has some failures:
> --
> |diff --git a/include/Makefile b/include/Makefile
> |index 0ba8b17..e01d0a6 100644
> |--- include/Makefile.orig
> |+++ include/Makefile
> --
> Patching file include/Makefile using Plan A...
> Hunk #1 succeeded at 114.
> Hunk #2 succeeded at 136.
> Hunk #3 succeeded at 147.
> Hunk #4 failed at 186.
> Hunk #5 failed at 263.
> 2 out of 5 hunks failed--saving rejects to include/Makefile.rej
>
> Also file sys/amd64/include/_align.h referred from cc-m32-3.diff is
> missing on my system.
> Maybe your patch isn't up-to-date?

As Tijl mentioned, his patches are for -CURRENT, and you are using
8.0-STABLE, right? STABLE-8, from which 8.0-RELEASE and 8.0-STABLE
were derived, was branched from -CURRENT on 3 Aug. 2009:

http://svn.freebsd.org/viewvc/base?view=revision&revision=196045

while src/sys/amd64/include/_align.h was added to -CURRENT later, on 8
Sept. 2009:

http://svn.freebsd.org/viewvc/base?view=revision&revision=196994

You'll need to use -CURRENT, or rework the patches.

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

Re: ts_to_ct flood on 8.1-STABLE

[b. f.]

>Since installing 8.1-RC2 and now on up-to-date RELENG_8 I am frequently
>getting kern.crit messages like
>
>ts_to_ct(1281661818.743348859) = [2010-08-13 01:10:18]
>
>and have been unable so far to determine their origin or purpose. I saw
>no such messages while running 7.x or earlier releases.

This occurs when the rtc is set, via:

atrtc_settime-->clock_ts_to_ct

after a verbose boot.  I think that someone changed some of the
timekeeping code to periodically adjust the value of the rtc if ntp is
used to update the system time, machdep.disable_rtc_set=0, and the rtc
driver hasn't been disabled:

http://svnweb.freebsd.org/viewvc/base?view=revision&revision=208297

This is probably what you are seeing.  It should occur every
machdep.rtc_save_period seconds. It's probably harmless, unless the
adjustments are big or erratic, in which case you may want to check
your rtc's battery, or the results of your ntp usage.

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

Re: Is there a way to rebuild 32-bit libraries under amd64?

[b. f.]

>I have 8.0-STABLE amd64 machine, and I need to run some 32-bit FreeBSD
>process which runs fine on 8.0-STABLE i386.
>
>So I copied all shared libs needed by it from i386 into there respective
>locations on amd64, but under lib32/ folder.
> libexecinfo.so.1 => /usr/local/lib32/libexecinfo.so.1 (0x289ca000)
> libffi.so.5 => /usr/local/lib32/libffi.so.5 (0x289d5000)
> libstdc++.so.6 => /usr/local/lib32/libstdc++.so.6 (0x289da000)
> libm.so.5 => /usr/lib32/libm.so.5 (0x28ac4000)
> libgcc_s.so.1 => /usr/local/gcc/4.5.0-32bit/lib/libgcc_s.so.1
>(0x28add000)
> libthr.so.3 => /usr/lib32/libthr.so.3 (0x28ae9000)
> libc.so.7 => /usr/lib32/libc.so.7 (0x28afe000)
>
>But the process crashes. After debugging I found that regexec returns
>result different from what it returns on i386 with the same input.
>
>So my question is: is there a way to rebuild for example
>/usr/lib32/libc.so.7 and /usr/lib32/libthr.so.3 on amd64? Or what may
>cause such incompatibility?

Did you install the 32-bit compatibility libraries and utilities on
amd64, by selecting the lib32 option with sysinstall(8), or by running
../lib32/install.sh from the FreeBSD media, or by rebuilding and
reinstalling world without a WITHOUT_LIB32 defined in src.conf(5) or
make.conf(5)?  Then did you make sure that rtld(1) has the proper
hints to find any needed 32-bit libraries that are not in the lib32
part of the base system, by defining the right values for
ldconfig32_paths and/or ldconfig_local32_dirs in rc.conf(5)?

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

Re: AHCI driver

[b. f.]

>Is it really better to enable AHCI driver?

Almost certainly, yes.  If your BIOS and SATA controller use AHCI, and
are recognized by the ahci(4), mvs(4),  or siis(4) drivers (I think
that these drivers are built as kernel modules by default in the
recent versions of FreeBSD, and don't require the use of a custom
kernel with the non-default ATA_CAM option -- all you have to do is
load them at boot time, either manually or via loader.conf(5)), then
you will be able to use features like NCQ and better power management
with disk drives that support those features.  This can give you
substantial benefits.

If your BIOS and/or SATA controller don't support AHCI, in order to
use cam(4) you must build a custom kernel with the ATA_CAM option.  In
that case you may still see some benefits, but they won't be as
dramatic as in the AHCI case.  If I recall correctly, the only
disadvantage to this option is that it prevents the use of ataraid(4)
-- everything else has a (usually slightly better) counterpart with
the option, and it is only a matter of configuring your system to use
it and learning how to use the new management tools (like
camcontrol(8)), rather than the old tools (like atacontrol(8)).

And yes, if you use the new drivers or the ATA_CAM option, some of
your disks will probably show up as /dev/adaX, rather than the old
/dev/adX. So make sure that you adjust fstab(5) and device.hints(5) as
necessary before rebooting.

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

Re: amd64

[b. f.]

>On 8/9/2010 4:14 PM, Robert Huff wrote:
>> Polytropon writes:
>>
>>
>>>   >I've installed FreeBSD-amd64. It runs very well. The packages I fetch
>>>   >  are amd64 too, but what about the ports I compile myself? Are those
>>>   >  amd64 too?
>>>
>>>   Yes, as your compiler infrastructure and target platform
>>>   is amd64, and so is the resulting binary code.
>>>
>
>How does it know your are on amd64?  gcc auto detect of CPU?

As the other person wrote, the base system compiler suite and other
base system utilities are configured and compiled to build and use
"amd64" binaries by default.  There is only limited support for
cross-building:  on amd64, for example, there are some provisions for
building and using 32-bit, "i386" binaries; and the base system
sources have some limited support for cross-building for other
architectures, by setting certain variables in the build environment.
In general, one cannot just build and use any binaries on a given
architecture.

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

Re: popt-1.50 or better??

[b. f.]

>On Sat, Jul 24, 2010 at 10:53:03PM +0000, b. f. wrote:
>> >here are the last few lines of output from configure, ots-0.5.0:
>> >
>> >checking for pkg-config... /usr/X11R6/bin/pkg-config
>> >checking for glib-2.0 >= 2.0 libxml-2.0 >= 2.4.23... yes
>> >checking OTS_CFLAGS... -I/usr/local/include/glib-2.0
>> >-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
>> >-I/usr/local/include
>> >checking OTS_LIBS... -L/usr/local/lib -lglib-2.0 -lxml2
>> >checking for poptParseArgvString in -lpopt... no
>> >configure: error: popt 1.5 or newer is required to build ots.
>> >You can download the latest version from
>> >ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x/
>>
>>
>> poptParseArgvString is in the $PREFIX/lib/libpopt.so.0 library from
>> our devel/popt port. The latest available version of this software is
>> 1.16, in the Red Hat repos.  Look at the configure script to determine
>> why it can't find the symbol. Maybe you need to reinstall devel/popt,
>> or patch the configure script.
>>
>
>
>can anybody tell me how to upgrade just this one file:
>   devel/popt?  i tried various forms up portupgrade.  zip.

I'm at a loss here.  First of all, you mean "upgrade this port",
right?  Because devel/popt is a port, not a file.  If you have an old
version of devel/popt, it would seem that any of the standard updating
tools would work.  If you just want to reinstall it, you could simply:

cd /usr/ports/devel/popt && make deinstall clean install && make clean

Then you could check your libpopt.so.0:

ldconfig -vr | fgrep popt
objdump -T /usr/local/lib/libpopt.so.0 | fgrep poptParseArgvString

Of course, I've assumed that PREFIX=LOCALBASE=/usr/local and
PORTSDIR=/usr/ports.  Make the proper substitutions if they aren't.

I don't see any error logs or an IGNORE for textproc/ots, so I'm
assuming that it builds properly on the package-building cluster.  If
that's the case, then there is something wrong with _your_ build: a
corrupted file, polluted environment, error after autodetection, etc.
But we won't know what is wrong until you show the corresponding part
of the configure script and errors in the config.log.

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

Re: apps update from ports

[b. f.]

>I was wondering about your update strategy. Do you update your apps as soon
>as a new version is available in the ports ? Or do you follow the "if it
>works, don't touch it" strategy ?
>

There is no one strategy that pleases everyone.  You'll have to
consider the time required  to perform updates (including some time
for configuring and learning how to use the new software, and for
recovering from occasional problems), and weigh that against the
benefits (if any) of having new software.  Some people prefer to use
the latest software, and others may use a snapshot of the ports tree
that coincides with a stable release, updating only those ports with
known critical security problems in between releases.  Sometimes, you
may wish to make this decision on a port-by-port basis.

>I'm guessing "portupgrade" is your preferred way of doing this hence, do you
>also choose -P or -PP ?

If you don't need to build from source, in order to use non-default
options or flags, or get the very latest versions of the port, then
packages are a good choice.  In addition to portupgrade, the
comparatively lightweight ports-mgmt/portmaster port also has this
functionality.

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

Re: I donot like using mergemaster ?

[b. f.]

On Monday 26 July 2010, zaxis wrote:
> I want to upgrade my freebsd 8.0  to 8.1.  I have read all the steps
> about upgrading freebsd. I feel mergemaster  is difficult to use e.g.
> which parameters should i use ?   (you may wish to use -U or -ai or
> -Fi)

Well, obviously you will get more out of mergemaster if you read the
manpage and take the time to decide which options will work best for
you.  But if you can't be bothered to do that, the suggested usage in
/usr/src/UPDATING works for most people.  Also, there is an
alternative to mergemaster that is supposed to be easier to use in
some ways: John Baldwin's new port, sysutils/etcupdate.  You may want
to take a look at that.


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