Re: Seeing the dreaded "ZFS: i/o error - all block copies unavailable" on 9.0-CURRENT
On Tue, Feb 16, 2010 at 8:21 PM, Chris wrote: >> >> Just a wild guess... Did you copied the /boot/zfs folder to the target >> file system? >> > Xin, > > The only thing I copied over was the zpool.cache file, as per the > wiki. Should I have copied over the entire /boot/zfs folder? > The only thing in the /boot/zfs folder is the zpool.cache folder. Did your first creae the /zroot/boot/zfs folder, and then copied the zpool.cache to that folder? Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Seeing the dreaded "ZFS: i/o error - all block copies unavailable" on 9.0-CURRENT
On Tue, Feb 16, 2010 at 8:42 PM, Scot Hetzel wrote: > On Tue, Feb 16, 2010 at 8:21 PM, Chris wrote: >>> >>> Just a wild guess... Did you copied the /boot/zfs folder to the target >>> file system? >>> >> Xin, >> >> The only thing I copied over was the zpool.cache file, as per the >> wiki. Should I have copied over the entire /boot/zfs folder? >> > The only thing in the /boot/zfs folder is the zpool.cache folder. > > Did your first creae the /zroot/boot/zfs folder, and then copied the ^Create > zpool.cache to that folder? > > Scot > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Seeing the dreaded "ZFS: i/o error - all block copies unavailable" on 9.0-CURRENT
On Wed, Feb 17, 2010 at 12:40 PM, Pegasus Mc Cleaft wrote: > Hello Chris, Scott & Current > > I use gptzfsboot on my AMD64 (current) machine all the time and also on > my laptop. I am not sure if this will cause the problem you are seeing but I > know I ran into a lot of trouble depending on what type of pool I was > creating. > > I believe this is correct, and if I am not than I apologise in advance, > but > > If you are trying to boot off a linear type pool (A single disk or a > mirror) your bootable filing system has to be a zfs filing system beneath the > root pool (IE: zroot/boot). If you are trying to boot off a zraid pool, your > bootable filing system must be the root filing system of the pool (IE: zroot) > > You must also include the appropriate declaration in the > /boot/loader.conf file: > > (for a zraid pool) > zfs_load="YES" > vfs.root.mountfrom="zfs:zpool" > > (for a linear type) > zfs_load="YES" > vfs.root.mountfrom="zfs:zpool/root" > > If I try any other method, zboot explodes in a myriad of different > ways. > Not sure why your zboot explodes, but I use a single disk and only use the following in /boot/loader.conf: zfs_load="YES" vfs.root.mountfrom="zfs:zpool" it should work with either zfs:zpool or zfs:zpool/root. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem building Openoffice 3.2.0 at current
On Mon, Mar 1, 2010 at 7:29 AM, KOT MATPOCKuH wrote: > Hello! > > I'm trying to build OOo 3.2.0 on my notebook with 2Gb of memory and 4Gb swap > size. > from dmesg.boot: > real memory = 2147483648 (2048 MB) > avail memory = 2089287680 (1992 MB) > swapinfo: > Device 1K-blocks Used Avail Capacity > /dev/gpt/swap 4194304 0 4194304 0% > uname -a: > FreeBSD kot 9.0-CURRENT FreeBSD 9.0-CURRENT #40: Wed Feb 10 01:36:25 MSK > 2010 r...@kot:/usr/obj/usr/src/sys/kot i386 > > and build fails with messages: > [skipped] > Successful packaging process! > *** > ... creating log file log_OOO320_en-US.log > ... creating "follow me" info file follow_me_OOO320_en-US.log. > > ** > ... creating download installation set ... > ** > *... including installation set into > /var/ports/usr/ports/editors/openoffice.org-3/work/OOO320_m12/instsetoo_native/ > unxfbsdi.pro/OpenOffice_SDK/bsd/install/en-US_download_inprogress/OOo-SDK_3.2.0__install_en-US.sh... > * > *Out of memory during request for 788 bytes, total sbrk() is 96739328 bytes! > * > ... checking log file > /var/ports/usr/ports/editors/openoffice.org-3/work/OOO320_m12/instsetoo_native/ > unxfbsdi.pro/OpenOffice_SDK/bsd/logging/en-US/log_OOO320_en-US.log > > *** > Successful packaging process! > *** > ... creating log file log_OOO320_en-US.log > dmake: Error code 1, while making 'sdkoo_en-US.bsd' > Running processes: 0 > > 1 module(s): > instsetoo_native > need(s) to be rebuilt > > Reason(s): > > ERROR: error 65280 occurred while making > /var/ports/usr/ports/editors/openoffice.org-3/work/OOO320_m12/instsetoo_native/util > > Attention: if you build and deliver the above module(s) you may prolongue > your the build issuing command "build --from instsetoo_native" > > rmdir /tmp/fyA74vD5zg > *** Error code 1 > > Stop in /usr/ports/editors/openoffice.org-3. > > Why I have "out of memory" error and how can I fix this problem? > Building OpenOffice requires 10GB of diskspace to build: http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux How large is your /var filesystem? If it is less than 10GB, then you will need to set the WRKDIRPREFIX to the location of a filesystem that has at least 10GB. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Questions about witness reports on sparc64
On Thu, Mar 4, 2010 at 7:19 PM, Nikolai Fetissov wrote: > Folks, > > I'm pretty new here, so feel free to use the clue stick :) > > Playing with current- on Sun Fire V210 I see more or less > consistent lock reversal reports like the following: > : > > My questions are - is it worth spamming the list > with these? If so, what other info needed? > It is worth sending it to the list and sending a report as outlined here: http://sources.zabbadoz.net/freebsd/lor.html Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik wrote: > On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: >> >> As a result of importing 32-bit compatibility support for non-x86 64-bit >> platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 >> in revision 205014, so all kernel configurations including this option must >> be modified accordingly. >> > > That sounds a bit confusing, compatibility with FreeBSD 3.2? > I agree that the name COMPAT_FREEBSD32 is confusing, does it mean compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: build failures after stdlib update
On Sun, Mar 21, 2010 at 7:29 PM, jhell wrote: > Native is equal to CPUTYPE not being defined right ? > Built into GCC is the ability to auto-detect the CPUTYPE when -mtune=native, if you run this command GCC will tell ouput your processor type: gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//' > So if the above is true why would you set CPUTYPE to native in the first > place ? when you can just leave it unset and its equal to native. > Native allows one to build the sources to the current build machines cputype. There is one bug when setting the CPUTYPE to native, the FreeBSD build system fails to correctly set the MACHINE_CPU to the correct value. I had discovered this problem back in May 2007: http://www.freebsd.org/cgi/query-pr.cgi?pr=112997 Just apply the last patch to share/mk/bsd.cpu.mk and that will fix the problem. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
MACHINE_CPU not being set correctly when CPUTYPE=native.
Could someone commit the last patch in PR 112997 to share/mk/bsd.cpu.mk, as it fixes the bug where MACHINE_CPU is not set correctly when CPUTYPE is set to 'native'. On Tue, Aug 28, 2007 at 1:54 AM, Scot Hetzel wrote: > Gcc 4.2 has a new cpu_type (native) for x86 and amd64 systems. This > cpu_type is to allow gcc to automatically detect the processor type > that gcc is running on. > > The problem is that setting CPUTYPE?=native in either src.conf or > make.conf will cause MACHINE_CPU to be set to the wrong value for the > native cpu. > > For example on a system where the processor is a k8, setting CPUTYPE > to k8, shows that MACHINE_CPU is set as follows: > > hp010# make -V MACHINE_CPU -DCPUTYPE=k8 > k8 3dnow amd64 sse2 sse mmx > > But setting CPUTYPE to native on a k8 system sets MACHINE_CPU to this value: > > hp010# make -V MACHINE_CPU -DCPUTYPE=native > unknown amd64 sse2 sse mmx > > After patching share/mk/bsd.cpu.mk (see attachment) or the last patch > to PR 112997: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=112997 > > setting CPUTYPE to native now works correctly when setting the value > for MACHINE_CPU: > > hp010# make -V MACHINE_CPU -V CPUTYPE -DCPUTYPE=native > k8 3dnow amd64 sse2 sse mmx > k8 > > Could this get committed before -CURRENT is branched. > > Thanks, > > Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: build failures after stdlib update
On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best wrote: > i don't think conf/112997 and the issue where gcc segfaults are directly > related to each other: > > 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native > /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//'` to determine > gcc's idea of the appropriate -mtune value. that command however segfaults. so > this doesn't really help. The command runs correctly with a properly built gcc: # gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//' generic > > 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` > examples. for me `make` prints the same no matter what CPUTYPE is set to: > > otaku% make -V MACHINE_CPU -DCPUTYPE=native > amd64 sse2 sse > otaku% make -V MACHINE_CPU -DCPUTYPE=nocona > amd64 sse2 sse > otaku% make -V MACHINE_CPU -DCPUTYPE=i386 > amd64 sse2 sse > otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala > amd64 sse2 sse > > ..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) > If I run the same commands as above, I get similar results: # make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=k8 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=lala amd64 sse2 sse But if I run the commands without the "-D", it shows the problem correctly: # make -V MACHINE_CPU CPUTYPE=native unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=k8 k8 3dnow amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=nocona sse3 amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=i386 unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=lalala unknown amd64 sse2 sse mmx # grep CPUTYPE /etc/make.conf /etc/src.conf grep: /etc/src.conf: No such file or directory This was run under a Feb 28th -CURRENT. Now here is something strange. Defining CPUTYPE in /etc/src.conf has no effect on the output of MACHING_CPU. /etc/src.conf: 1 lines, 11 characters. # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf amd64 sse2 sse /etc/src.conf:CPUTYPE=k8 # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf k8 3dnow amd64 sse2 sse mmx /etc/make.conf:CPUTYPE=k8 Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Jail detection
From: "Julian Elischer" <[EMAIL PROTECTED]> > We have some software we'd like to behave slightly differently if it is > in a jail. > > What methods do people use to detect they are in a jail? There's a program called in.jail (/usr/ports/sysutils/jailer) that is capable of detecting if it is running in a jail. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with RC3
From: "Chris Knight" <[EMAIL PROTECTED]> > Interestingly, loader ignores my hint.acpi.0.disable=1 and > acpi_load=NO settings in /boot/loader.conf and tries loading > it anyway - even when manually setting them. Renaming the acpi > module fixed it. That should be: hint.acpi.0.disabled=1 Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adduser difference between 5.0 and earlier versions
Here's the requested changes to make it re'ask the question on an invalid input. I left the code in for the default answer, but commented out. Scot Index: adduser.sh === RCS file: /home/ncvs/src/usr.sbin/adduser/adduser.sh,v retrieving revision 1.3 diff -u -r1.3 adduser.sh --- adduser.sh 3 Dec 2002 05:41:09 - 1.3 +++ adduser.sh 22 Jan 2003 15:38:02 - @@ -871,4 +871,22 @@ fi else input_interactive + while : ; do + echo -n "Add another user? (yes/no): " + read _input +# [ -z "$_input" ] && _input="No" + case $_input in + [Yy][Ee][Ss]|[Yy][Ee]|[Yy]) + input_interactive + continue + ;; + [Nn][Oo]|[Nn]) + echo "Goodbye!" + ;; + *) + continue + ;; + esac + break + done fi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adduser difference between 5.0 and earlier versions
Use this patch, as it fixes the value of uidstart to be the next available uid, instead of the uid of the previously added user. Scot Index: adduser.sh === RCS file: /home/ncvs/src/usr.sbin/adduser/adduser.sh,v retrieving revision 1.3 diff -u -r1.3 adduser.sh --- adduser.sh 3 Dec 2002 05:41:09 - 1.3 +++ adduser.sh 22 Jan 2003 18:12:02 - @@ -871,4 +871,23 @@ fi else input_interactive + while : ; do + echo -n "Add another user? (yes/no): " + read _input +# [ -z "$_input" ] && _input="No" + case $_input in + [Yy][Ee][Ss]|[Yy][Ee]|[Yy]) + uidstart=`get_nextuid $uidstart` + input_interactive + continue + ;; + [Nn][Oo]|[Nn]) + echo "Goodbye!" + ;; + *) + continue + ;; + esac + break + done fi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broadcom BCM4310 USB Controller (Wifi)
On Wed, Oct 27, 2010 at 12:07 PM, Scot Hetzel wrote: > On Wed, Oct 27, 2010 at 8:58 AM, Alberto Villa wrote: >> On Wed, Oct 27, 2010 at 1:36 PM, Paul B Mahol wrote: >>> NDISulator does not support 6.X NDIS API. You will need to find bcmwl5 >>> driver. Note 5 vs 6 in driver name. >>> Editing inf files will give you nothing. >> >> i've tried that driver, but apparently it doesn't support my card... >> loading the .ko doesn't show anything... > > Where did you get your bcmwl5 driver? If you downloaded it from Acer, > it should work. If you downloaded it from anywhere else then this > might be why it didn't work for you. > Just noticed that you didn't specify your computer manufacture. The above would only work for Matthias Apitz. You just need to download the driver from the manufacture of your computer. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Broadcom BCM4310 USB Controller (Wifi)
On Wed, Oct 27, 2010 at 8:58 AM, Alberto Villa wrote: > On Wed, Oct 27, 2010 at 1:36 PM, Paul B Mahol wrote: >> NDISulator does not support 6.X NDIS API. You will need to find bcmwl5 >> driver. Note 5 vs 6 in driver name. >> Editing inf files will give you nothing. > > i've tried that driver, but apparently it doesn't support my card... > loading the .ko doesn't show anything... Where did you get your bcmwl5 driver? If you downloaded it from Acer, it should work. If you downloaded it from anywhere else then this might be why it didn't work for you. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Broadcom BCM4310 USB Controller (Wifi)
On Thu, Oct 28, 2010 at 1:06 AM, Matthias Apitz wrote: > El día Wednesday, October 27, 2010 a las 12:12:09PM -0500, Scot Hetzel > escribió: > >> > Where did you get your bcmwl5 driver? If you downloaded it from Acer, >> > it should work. If you downloaded it from anywhere else then this >> > might be why it didn't work for you. >> > >> >> Just noticed that you didn't specify your computer manufacture. The >> above would only work for Matthias Apitz. >> >> You just need to download the driver from the manufacture of your computer. > > Why is this? Isn't it just the Wifi chip which matters? Could you sheet > a bit light on this? Thanks > When you get the Windows NDIS driver from the computer manufacture, you are ensured that your card is supported by that version of the driver. If you download the Windows NDIS driver from another source, that driver may not include support for your card as it might be an older version. Also, some versions of the Windows NDIS driver may use functions that are not currently implemented in the FreeBSD NDIS emulator. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Broadcom BCM4310 USB Controller (Wifi)
On Fri, Oct 29, 2010 at 12:59 AM, Matthias Apitz wrote: > I booted the 8-CURRENT this morning, loaded the module with kldload(8) and > wlan0 came up by its own (I did not realized this yesterday). I have in > rc.conf: > > wlans_ndis0="wlan0" > ifconfig_wlan0="WPA DHCP" > > wpa_supplicant(8) started after kldload, and associated the > interface with my AP; had to do the DHCP by hand, don't know why? > The problem is that the Broadcom NDIS driver is generating connection events, but nothing is relaying that information to the wpa_supplicant daemon. Since the wpa_supplicant daemon doesn't see a connection event, it retries connecting I had created a patch in PR 113915 which solves this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=113915 Give it a try, if it solves your problem submit a followup to the PR. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Digital Unix (Tru64) binaries on FreeBSD-Alpha
I maintain the www/apache13-fp and www/frontpage ports, and are supposed to work on FreeBSD-Alpha as they install the Digital Unix (Tru64) Frontpage Extentions binaries. Richard is trying to install the www/apache13-fp ports on his Alpha (5.0-RELEASE w/GENERIC kernel), but he is getting errors when the fp_install.sh script attempts to install the FP root web. Will chown web to www as part of install. Will chgrp web to www as part of install. exception system: exiting due to internal error: out of memory trying to allocate exception system resources Abort trap ERROR: / installation failed. Hit enter to continue Exiting due to an error! Please fix the error and try again. His /var/log/messages shows: Mar 13 12:48:52 skunkworx kernel: pid 10961 (owsadm.exe), uid 0: exited on signal 6 His Alpha system is configured with 1G swap and 512M RAM. He did a kldstat -v and it shows that the osf1.ko module is loaded. He also has the osf1_base port installed (which may/may not be needed by the www/frontpage port). Could one of the Alpha guru's test www/apache13-fp port on their Alpha system. Thanks, Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Digital Unix (Tru64) binaries on FreeBSD-Alpha
moved to the FreeBSD-Alpha list, send all replies there. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pptp mpd under 5.0
From: "Aaron Wohl" <[EMAIL PROTECTED]> > replacement for MAKDEV to mkae them? ... and I cant seem to get truss to > run at all on any program... > bash-2.05b# truss mpd > truss: cannot open /proc/curproc/mem: No such file or directory > truss: cannot open /proc/1107/mem: No such file or directory > bash-2.05b# > The procfs isn't mounted by default on 5-CURRENT, you will need to mount it before running truss. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SOEKRIS kernel config
On Sat, Sep 27, 2014 at 9:47 PM, Tom Everett wrote: > I see there is no SOEKRIS config on the tree, here > > https://svnweb.freebsd.org/base/head/sys/i386/conf/ > > I have attached one for addition to the tree. > > Since you only appended a few configuration options to the end of the GENERIC configuration, it would be better to use the include directive in the SOEKRIS config file. This allows changes to be made to the GENERIC configuration, and the SOEKRIS kernel would automatically get those changes. Here's a shorter version of that configuration file: # # SOEKRIS -- Generic Kernel configuration file for FreeBSD/i386 on SOEKRIS # # $FREEBSD include GENERIC ident SOEKRIS # To Make a SOEKRIS Kernel, the next options are needed options CPU_SOEKRIS options CPU_ELAN #options CPU_ELAN_PPS #options CPU_ELAN_XTAL=32768000 options CPU_GEODE # Include TMPFS options TMPFS -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How exactly does the base toolchain determine WHICH language to build with?
On Fri, Nov 7, 2014 at 6:23 PM, Chris H wrote:
> Greetings,
> Sorry for the long title. I've been [needlessly] struggling
> with getting ports within the ports tree to build, on a
> fresh 11-CURRENT install from 2014-11-05. With custom
> KERNEL and WORLD built, and installed.
> Here's my situation, which has worked well since ~8.2;
> make.conf(5)
> WITHOUT_CLANG=true
> FAVORITE_COMPILER=gcc
> src.conf(5)
> WITHOUT_CLANG=true
>
> I'll neither argue, nor defend rational for w/o clang. To
> boring and out of scope for this thread. That said; I
> realize that lang/clang(33/34/35) is the default toolchain
> for 10+, and that's just fine by me. So I shouldn't be
lang/clang(33/34/35) is not the default toolchain in 10+. 10+ uses a
version of clang that is included in the FreeBSD source (/usr/src).
> terribly surprised when install kernel/world, followed by
> make delete-old removes the clang built, or provided by
> the base install from the (initial) install procedure. But
> what _does_ surprise me, is that the install of lang/gcc-48
> does _not_ become the compiler of choice with the above
> $ENV, after [seemingly] deleting clang. I understand that
FAVORITE_COMPILER is used by Mk/Uses/compiler.mk.
If you want ports to build with lang/gcc-48, then you would need to
check that the ports you are trying to compile have either
USES=compiler or USES_GCC defined in their Makefile. Otherwise the
ports will use the compiler that is provided by the FreeBSD source
(gcc 2.4.x or clang).
When WITHOUT_CLANG is defined in make.conf/src.conf. The FreeBSD
source will be built using gcc 2.4.x from the FreeBSD source.
/usr/bin/{cc,c++} will then be linked to the gcc versions. The ports
will then use this version to build if there is no USES_GCC or
USES=compiler in the ports Makefile.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: MK_ vs. WITH_/WITHOUT_ in release/Makefile
On Mon, Nov 10, 2014 at 8:38 AM, Rick Miller wrote:
> Hi all,
>
> release/Makefile in CURRENT utilizes MK_* knobs vs. the WITH_/WITHOUT_*
> knobs seen in release/Makefile in the STABLE/RELEASE branches. Merging a
> CURRENT version of the Makefile into a RELEASE branch and executing a
> release build results in an error citing "MK_KERNEL_SYMBOLS can't be set by
> a user". Comparisons of the Makefile between CURRENT and STABLE/RELEASE
> exposed the difference and changing the knobs from MK_ to WITHOUT_ resolved
> the error.
>
> I have little familiarity with these knobs, but was under the impression
> the Makefile would not differ like this. Is there documentation describing
> the use of these knobs between the varying branches and how they are
> changed from CURRENT to STABLE/RELEASE?
>
According to head/share/Mk/src.opts.mk:
# Users define WITH_FOO and WITHOUT_FOO on the command line or in /etc/src.conf
# and /etc/make.conf files. These translate in the build system to
MK_FOO={yes,no}
# with sensible (usually) defaults.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Buildworld fails due to WITHOUT_CRYPT (3 issues)
On Wed, Dec 24, 2014 at 3:45 AM, Beeblebrox wrote: > I plan on using openssl from ports and have no need for kerberos. > /etc/src.conf >> WITHOUT_CRYPT= yes > Instead of using WITHOUT_CRYPT, you could have used WITHOUT_KERBEROS. > > * I would prefer being able to use SSH from world (instead of dropbear), but > that seems impossible when openssl is disabled. > Using WITHOUT_KERBEROS would allow SSH and other programs built from world to use the base openssl. You can still install openssl from ports. Set WITH_OPENSSL_PORT=yes in /etc/make.conf to allow the ports to use the openssl port instead of the openssl from source. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: install: /usr/tests/etc/rc.d/routing_test: No such file or directory
On Sat, Jan 24, 2015 at 10:42 AM, Adrian Chadd wrote: > I just updated a box: > > ===> etc/tests/rc.d (install) > install -o root -g wheel -m 555 routing_test > /usr/tests/etc/rc.d/routing_test > install: /usr/tests/etc/rc.d/routing_test: No such file or directory > *** Error code 71 > > .. did someone forget an mtree? > > Looks like etc/rc.d needs to be added to the BSD.tests.dist. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Project geom-events
2011/10/5 Miroslav Lachman <000.f...@quip.cz>: > I am waiting years for the moment, when these GEOM problems will be fixed, > so I am really glad to see your interest! > It will be move to right direction even if changes will not be backward > compatible. > The current state is too fragile to be used in production. Gmirror alone can > be used, glabel alone can be used, GPT alone can be used... but mix it all > stacked together is way to hell. > > e.g. Using GPT on glabeled provider always ends with error message about > corrupted secondary GPT table. (But how can I use iSCSI in reliable way if I > cannot use glable on devices and iSCSI device can have different number on > each reboot? I wrote about it almost 2 years ago) > You don't need to use glabel on GPT disks, as gpart has it's own way to label GPT disks: Fixit# gpart create -s gpt ad0 Fixit# gpart add -s 4G -t freebsd-swap -l swap0 ad0 Fixit# gpart add -t freebsd-zfs -l disk0 ad0 This create the following in /dev: /dev/gpt/swap0 /dev/gpt/disk0 Glabel is not needed for GPT partitioned disks. What should happen is that glabel should fail when attempting to label a GPT disk. If you wish to add a GPT label after the fact use: gpart show geom gpart modify -i index -l label geom (i.e. geom = ad0) Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x11/nvidia-driver / Compilation has failed
On Wed, Oct 5, 2011 at 3:52 PM, Ali Mashtizadeh wrote: > Is there any reason I should still be hitting this bug when building > on 9-STABLE? With Linux compatibility disabled I can build the driver, > but the kernel refuses to load it saying it's incompatible with my > kernel version. > Was your kernel built from the same version of /usr/src, or have you updated the source (/usr/src) since you last rebuilt the kernel. If you updated the source, then you need to rebuild the kernel from those updated sources (should also build/installworld). Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x11/nvidia-driver / Compilation has failed
On Wed, Oct 5, 2011 at 4:43 PM, Ali Mashtizadeh wrote: > On Wed, Oct 5, 2011 at 2:27 PM, Scot Hetzel wrote: >> On Wed, Oct 5, 2011 at 3:52 PM, Ali Mashtizadeh >> wrote: >>> Is there any reason I should still be hitting this bug when building >>> on 9-STABLE? With Linux compatibility disabled I can build the driver, >>> but the kernel refuses to load it saying it's incompatible with my >>> kernel version. >>> >> Was your kernel built from the same version of /usr/src, or have you >> updated the source (/usr/src) since you last rebuilt the kernel. >> >> If you updated the source, then you need to rebuild the kernel from >> those updated sources (should also build/installworld). >> > Yes, I did that just before. I'll try buildkernel and installkernel > again but I know havn't updated the tree. Could there be an issue > since I built it from the directory /usr/src-9? > Do you also have a /usr/src directory? If you do, then the port is using the wrong kernel source. You'll need to set SRC_BASE to /usr/src-9 when building the port. cd /usr/ports/x11/nvida-driver make deinstall ; make clean ; make install -DSRC_BASE=/usr/src-9 Then you should be able to load the kernel module. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9
On Sat, Dec 3, 2011 at 8:46 PM, Nenhum_de_Nos wrote: > > On Sun, December 4, 2011 00:32, Adrian Chadd wrote: >> Why not just run FreeNAS? > > thanks for the tip on FreeNAS, as others said too. > > will it run some other services, as http server for some stuff (wiki for > example), edonkey and > torrent clients, and some other stuff ? (I will visit the FreeNAS site and > try to figure out) > > although it would solve the problem on configuring the box, I still have the > doubts on the port > multiplier being usefull on it, as FreeNAS will end on FreeBSD :) > > this port multiplier will work ok ? On Sil3124 and which others ? > According to this web site, it should work with the Sil3124: http://www.addonics.com/products/ad5sapm.php Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rpcbind does not honor -h flag
On Fri, Aug 31, 2012 at 3:42 AM, Борис Самородов wrote: > 31.08.2012 12:34, Maxim Konovalov пишет: > Please file a PR against rc ASAP. >>> >>> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117711 > > > I see. Thanks. > Looks like Matteo Riondato had created a patch for the problem in 2008: http://people.freebsd.org/~matteo/diff/117711rpcbind.diff but he never received any feedback from Carlos Eduardo Monti to see if the patch fixed the problem. I don't know if the patch will apply to the current FreeBSD rpcbind code, give it a try and submit a follow up to the PR. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A little question about safe mode
On Thu, Oct 18, 2012 at 2:35 AM, Alexander Yerenkow wrote:
> Hello there.
> I have problem here, and don't know if it's bug or "feature" :)
> If I prerare boot media (hdd, sd card,usb, etc) with FreeBSD, and NOT
> create there fstab, I see such behavior:
>
> 1. I need enter manually where from mount root (e.g. ufs:ada0s1a or
> ufs:ada0s1a rw)
> 2. If I enter ufs:ada0s1a rw - I have / mounted in read-only anyway. <== Is
> this bug?...
Looks to be a feature in sys/kern/vfs_mountroot.c:
997 parse_mountroot_options(struct mntarg *ma, const char *options)
:
1021if( strcmp(name, "rw") == 0 ||
1022strcmp(name, "noro") == 0) {
1023/*
1024 * The first time we mount the root file system,
1025 * we need to mount 'ro', so We need to ignore
1026 * 'rw' and 'noro' mount options.
1027 */
1028continue;
1029 }
Scot
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Do we have a CPUTYPE=native and/or generic stability problem?
On Sat, Nov 3, 2012 at 5:24 PM, Alexander Leidinger wrote: > Hi, > > while trying to update from r239708 to r242511 (amd64 arch) I tried to > compile the world with "make -j8". After a short while I got an > internal error in the clang compile (this is a gcc-compiled system, I > don't use clang). The CFLAGS/COPTFLAGS are -O2 -pipe. > > Without the -j8 it compiles just fine. > Without the CPUTYPE?=native it compiles even with -j8. > > The CPU is an Intel(R) Xeon(R) CPU (L5630) with ECC ram. > > The r239708 world runs stable since I installed it (build with > CPUTYPE=native). The r242511 world (no CPUTYPE set) doesn't run stable > (not only the watchdogd segfault I reported in another mail some minutes > ago, but also some other kind of reboot every X minutes I haven't > investigated yet). > > Does someone run -current on a similar system on a similar revision and > can comment about the stability? > Not sure if your hitting the same bug, that was found in PR 112997. When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/112997 for a patch to bsd.cpu.mk. Does your system compile correctly, if you specify the CPUTYPE? Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat
On Wed, Dec 12, 2012 at 4:07 AM, Anton Shterenlikht wrote: > I updated to r244114 on ia64 following the > standard procedure. I then get: > > # make check-old-libs Checking for old libraries > /lib/libz.so.5 > # > > while sysutils/libchk shows: > > Binaries that are linked with: /lib/libz.so.5 > /usr/sbin/dtrace > /usr/sbin/lockstat > > and indeed these two executables depend > on this library: > > # ldd /usr/sbin/dtrace > /usr/sbin/dtrace: > libdtrace.so.2 => /lib/libdtrace.so.2 (0x200020094000) > libproc.so.2 => /usr/lib/libproc.so.2 (0x200020194000) > libctf.so.2 => /lib/libctf.so.2 (0x2000201a8000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x2000201d) > libz.so.5 => /lib/libz.so.5 (0x20002021) > libthr.so.3 => /lib/libthr.so.3 (0x200020246000) > libc.so.7 => /lib/libc.so.7 (0x200020294000) > # ldd /usr/sbin/lockstat > /usr/sbin/lockstat: > libdtrace.so.2 => /lib/libdtrace.so.2 (0x200020094000) > libproc.so.2 => /usr/lib/libproc.so.2 (0x200020194000) > libctf.so.2 => /lib/libctf.so.2 (0x2000201a8000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x2000201d) > libz.so.5 => /lib/libz.so.5 (0x20002021) > librt.so.1 => /usr/lib/librt.so.1 (0x200020246000) > libthr.so.3 => /lib/libthr.so.3 (0x20002025e000) > libc.so.7 => /lib/libc.so.7 (0x2000202ac000) > # > > I see that these two executables are old: > > # ls -al /usr/sbin/dtrace /usr/sbin/lockstat > -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace > -r-xr-xr-x 1 root wheel 72832 Jul 18 2010 /usr/sbin/lockstat > # > > Does this mean that both dtrace and lockstat > are obsolete and can be removed? > These 2 programs are part of the CDDL liscensed code. Do you have WITHOUT_CDDL defined in your src.conf or make.conf? If it is defined, then you can remove them. Otherwise you'll need to determine why they are not being built/installed. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat
On Wed, Dec 12, 2012 at 10:52 AM, Scot Hetzel wrote: > On Wed, Dec 12, 2012 at 4:07 AM, Anton Shterenlikht > wrote: >> I updated to r244114 on ia64 following the >> standard procedure. I then get: >> >> # make check-old-libs >>>>> Checking for old libraries >> /lib/libz.so.5 >> # >> >> while sysutils/libchk shows: >> >> Binaries that are linked with: /lib/libz.so.5 >> /usr/sbin/dtrace >> /usr/sbin/lockstat >> >> and indeed these two executables depend >> on this library: >> >> # ldd /usr/sbin/dtrace >> /usr/sbin/dtrace: >> libdtrace.so.2 => /lib/libdtrace.so.2 (0x200020094000) >> libproc.so.2 => /usr/lib/libproc.so.2 (0x200020194000) >> libctf.so.2 => /lib/libctf.so.2 (0x2000201a8000) >> libelf.so.1 => /usr/lib/libelf.so.1 (0x2000201d) >> libz.so.5 => /lib/libz.so.5 (0x20002021) >> libthr.so.3 => /lib/libthr.so.3 (0x200020246000) >> libc.so.7 => /lib/libc.so.7 (0x200020294000) >> # ldd /usr/sbin/lockstat >> /usr/sbin/lockstat: >> libdtrace.so.2 => /lib/libdtrace.so.2 (0x200020094000) >> libproc.so.2 => /usr/lib/libproc.so.2 (0x200020194000) >> libctf.so.2 => /lib/libctf.so.2 (0x2000201a8000) >> libelf.so.1 => /usr/lib/libelf.so.1 (0x2000201d) >> libz.so.5 => /lib/libz.so.5 (0x20002021) >> librt.so.1 => /usr/lib/librt.so.1 (0x200020246000) >> libthr.so.3 => /lib/libthr.so.3 (0x20002025e000) >> libc.so.7 => /lib/libc.so.7 (0x2000202ac000) >> # >> >> I see that these two executables are old: >> >> # ls -al /usr/sbin/dtrace /usr/sbin/lockstat >> -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace >> -r-xr-xr-x 1 root wheel 72832 Jul 18 2010 /usr/sbin/lockstat >> # >> >> Does this mean that both dtrace and lockstat >> are obsolete and can be removed? >> > These 2 programs are part of the CDDL liscensed code. > > Do you have WITHOUT_CDDL defined in your src.conf or make.conf? If it > is defined, then you can remove them. Otherwise you'll need to > determine why they are not being built/installed. > I had another look at cddl/usr.sbin/Makefile, and it only builds lockstat and dtrace for i386, amd64, and powerpc. It doesn't build them for ia64. So it is safe to remove them. -- DISCLAIMER: No electrons were mamedi while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/src/lib/msun errors
On Sat, Oct 12, 2013 at 10:21 PM, Allan Jude wrote: > On 2013-10-12 21:23, Joe Nosay wrote: >> I am not top posting. >> Do not accuse me of this. >> I am upset and depressed and I do not need you to accuse me of something I >> am not doing. >> My system is shitting out on me. >> I have already told you what is happening. >> Stop accusing me of something I am not doing. >> >> : : : > Sorry, do you not know what 'top posting' is? The list just asks that > you put your reply after the quoted text that you are replying to, > instead of at the top of the email (above the quote) > Joe might not have realized it, but for us gmail users we have top posting by default. We have to hit the 3 dots (...) to expand the quoted text, delete the first line and then scroll down to the text we want to quote. It's a bit annoying. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10.0-RC3 Now Available
On Fri, Dec 27, 2013 at 10:08 AM, Warren Block wrote: > On Fri, 27 Dec 2013, Mathieu Arnold wrote: > >> +--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann >> wrote: >> | All the examples I've seen for updating bootcode assume GPT. If one has >> | MBR (as I do) and assuming the following basic scheme: >> | >> | gpart show ada0 >> | => 63 976773105 ada0 MBR (466G) >> | 63 976773105 1 freebsd [active] (466G) >> | >> | gpart show ada0s1 >> | =>0 976773105 ada0s1 BSD (466G) >> | 0 943218736 1 freebsd-zfs (450G) >> | 943218736 33554369 2 freebsd-swap (16G) >> | >> | would the equivalent bootcode statement be: >> | >> | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 > > > No, the PMBR is for GPT partitioning only. > > >> | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and >> | ada0s1 is the slice on which FreeBSD is installed? >> >> Hum, no, if you're using MBR and not GPT, you can't use gpart, > > > Why not? gpart is not GPT-specific. It handles MBR and BSDlabel bootcode > correctly. > > >> you have to >> do something aweful like this : >> # dd if=/boot/zfsboot of=/dev/ada0 count=1 > > > That will overwrite the MBR partition table. > > >> # sysctl kern.geom.debugflags=0x10 >> # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024 > > > That seems dangerous. I have not tried with zfsboot, but this should be > close: > > # gpart bootcode -b /boot/zfsboot ada0 > # gpart bootcode -b /boot/zfsboot ada0s1 > > Untested! The first one may need to use /boot/mbr. A better way to do > this, provided the system does not have a broken BIOS, would be to backup, > repartition with GPT, and restore, avoiding the complication of multiple > partitioning schemes. > The correct way to install/update ZFS Boot code on an MBR disk is: Install boot Manager (required on first install) # gpart bootcode -b /boot/boot0 ad0 Note: /boot/mbr could also be used if you are not multibooting Install ZFS boot1 stage # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0s1 count=1 or # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 Install ZFS boot2 stage # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem updating bootcode on ZFS on root system with MBR
On Tue, Jan 21, 2014 at 3:11 PM, Thomas Hoffmann wrote: > On Tue, Jan 21, 2014 at 10:47 AM, Andriy Gapon wrote: > >> on 21/01/2014 13:18 Andrey V. Elsukov said the following: >> > On 21.01.2014 14:45, Andriy Gapon wrote: >> What do I need to do to get the boot2 code written to /dev/ada0s1a? >> >>> >> # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 >> dd: /dev/ada0s1a: Operation not permitted > Thanks for the responses. My apologies for going silent, but I had to step > away from the problem for a bit. I was able to resolve my problem by doing > the following: > > After upgrading my zpools and after my aborted attempt to update the > bootcode as reported above, I copied /boot/zfsboot (or more precisely > /bootpool/boot/zfsboot) to a USB thumb drive. I attempted to reboot my > system, which failed due to unsupported zfs features. This was expected, > but I thought, hey, I might get lucky. I then booted into a Live CD, > mounted my USB thumb drive on /tmp/usb and executed: > > sysctl kern.geom.debugflags=0x10 > dd if=/tmp/usb/zfsboot of=/dev/ada0s1 count=1 > dd if=/tmp/usb/zfsboot of=/dev/ada0s1d skip=1 seek=1024 > > Then I rebooted and all is well. All zpools support all features. While > this procedure was not tedious, it would still be nice if, as Andriy > stated, FreeBSD contained a native way do this zfs bootcode update for MBR > schemes that is as simple as for the GPT schemes. > In your original message, you were trying to write the boot code to ada0s1a, but you made it work by using ada0s1d. Do you have an ada0s1a? If you do, is it your ZFS partition or is it ada0s1d? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfs boot manual pages
On Tue, Feb 4, 2014 at 7:53 AM, Andriy Gapon wrote: > > I've started working on manual pages for the zfs boot chain. > > Please [p]review my work in progress here: > https://github.com/avg-I/freebsd/compare/review;zfs-boot-man-pages > > Any additions, corrections, suggestions and other kinds of reviewing are > welcome. Patches and pull requests are very welcome! > > Many thanks to Warren Block for the initial review and many fixes. One fix for the gptzfsboot man page would be to mention that gptzfsboot is installed into a GPT partition of type freebsd-boot, and that the -i 1 refers to the GPT index for this partition. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfs boot manual pages
On Tue, Feb 4, 2014 at 2:13 PM, Warren Block wrote: > On Tue, 4 Feb 2014, Scot Hetzel wrote: > >> On Tue, Feb 4, 2014 at 7:53 AM, Andriy Gapon wrote: >>> >>> >>> I've started working on manual pages for the zfs boot chain. >>> >>> Please [p]review my work in progress here: >>> https://github.com/avg-I/freebsd/compare/review;zfs-boot-man-pages >>> >>> Any additions, corrections, suggestions and other kinds of reviewing are >>> welcome. Patches and pull requests are very welcome! >>> >>> Many thanks to Warren Block for the initial review and many fixes. >> >> >> One fix for the gptzfsboot man page would be to mention that >> gptzfsboot is installed into a GPT partition of type freebsd-boot, and >> that the -i 1 refers to the GPT index for this partition. > > > We are missing that from the gptboot.8 page also. > > gptzfsboot is installed in a freebsd-boot partition, usually the > first partition on the disk. A ``protective MBR'' (see gpart(8)) is > typically used in combination with gptzfsboot. > > To install gptzfsboot on the ada0 drive: > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 That sounds perfect for both man pages. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libinit idea
On Sat, Feb 22, 2014 at 5:54 PM, Bruno Lauzé wrote:
> https://github.com/brunolauze/libnit
>
> I know there's really big debate about init system but here's my tentative to
> propose a new model to replace rc.
>
> Let's call it libinit but the name as no significance for now.
>
> I started coding a library with the following architecture.
>
> the main idea is to rewrite rc in C language.
>
> a utility called system would act a little bit like service command does.
>
> a folder would contains libraries instead of scripts inside [target]/etc/rc.d
> so we can add as many librairies a user desire and interlink the order of
> each piece among all like in rc.
>
libraries don't belong in [target]/etc/rc.d, they would have to be in
{/usr,}/lib{exec,}/rc.d or ${PREFIX}/lib{exec,}/rc.d
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: py.sqlite3 fails to build in firefox port
On Thu, Feb 27, 2014 at 8:26 AM, buddha wrote: > cc: error: unknown argument: '-R/usr/local/lib' > > Python build finished, but the necessary bits to build these modules were not > found: > _bsddb _tkinter dl > imageoplinuxaudiodev ossaudiodev > spwd sunaudiodev > To find the necessary bits, look in setup.py in detect_modules() for the > module's name. > > > Failed to build these modules: > _sqlite3 > > running build_scripts > > > This is the output from the /py-sqlite3/work/Python-2.7.6 directory. > > In the /www/firefox port the compilation fails with: > cc: error: unknown argument: '-R/usr/local/lib' > error: command 'cc' failed with exit status 1 > *** Error code 1 > > Here is my pkg info for python utils > py27-libxml2-2.8.0 Python interface for XML parser library for > GNOME > py27-setuptools-2.0.1 Python packages installer > python-2.7_1,2 The "meta-port" for the default version of > Python interpreter > python2-2_2The "meta-port" for version 2 of the Python > interpreter > python27-2.7.6_2 Interpreted object-oriented programming > language Try the following patch to lang/python27: http://docs.freebsd.org/cgi/mid.cgi?CAALwa8m9-dpiO4fpA_BG-QeZyo9wsRpDVXHz_CTNUYeFLK7GVA If someone could commit the patch, it would fix this issue for all users that are using clang 3.4. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: importing sam leffler's libstatfoo into -HEAd
On Tue, Mar 4, 2014 at 11:16 PM, Adrian Chadd wrote: > On 4 March 2014 20:19, Rui Paulo wrote: >> On 4 Mar 2014, at 18:31, Adrian Chadd wrote: >> >>> hi, >>> >>> i'd like to import the libstatfoo code from sam into -HEAD. >>> >>> It's used by some of the wifi tools to print out periodic and global >>> statistics. It abstracts away the gathering, printing and formatting >>> bits. >>> >>> I'm hoping that we can adapt some of the other base tools to use it >>> and then teach it to print out statistics in other (machine parsable) >>> formats, so we don't have to keep hacking at the tools to do this. >>> >>> The initial import: >>> >>> http://people.freebsd.org/~adrian/patches/20140304-libbsdstatfoo.diff >> >> While there, could you please rename it? libstatfoo is a pretty bad name... > > I'm open to suggestions, but I don't want to get bogged down by sheds. > lib/libbsdstatfoo -> lib/libbsdstat[,istics] lib/libbsdstatfoo/statfoo.c -> lib/libbsdstat[,istics]/bsdstat[,istics].c lib/libbsdstatfoo/statfoo.h -> lib/libbsdstat[,istics]/bsdstat[,istics].h Then change all occurrences of statfoo/STATFOO in those files to bsdstat[,istics]/BSDSTAT[,ISTICS]. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: service doen't get started at boottime, but can start manually
On Sun, Sep 7, 2014 at 2:43 AM, O. Hartmann wrote: > Am Sun, 7 Sep 2014 15:33:42 +0800 > Erich Dollansky schrieb: > >> Hi, >> >> On Sun, 7 Sep 2014 09:03:21 +0200 >> "O. Hartmann" wrote: >> >> > >> > I use a service (textprox/refdb from ports, refdb_enable="YES" >> > in /etc/rc.conf.local) that is supposed to startup at boottime. On >> > one CURRENT system, running >> > >> > FreeBSD 11.0-CURRENT #3 r271210: Sat Sep 6 22:39:59 CEST 2014 amd64 >> > >> > the service is not started at boottime, but I can start the service >> > manually via >> > >> > service refdb start >> > >> > I tried enabling rc_debug=YES in /etc/rc.conf but I do not see any >> > failure of the start attempt of that specific service in the logs or >> > on the console. >> > >> > Is there an elegant way to debug rc.d and the startup procedure >> > without having the system reboot (I do not have jails or VM, sorry)? >> > >> could it be that the spelling in either rc.conf and the spelling in the >> actual script differ so that FreeBSD does not start it? >> >> Erich > > No. If it would be the case, I guess starting it manually wouldn't work > either. The fact > is that the port textproc/refdb uses a startup script named "refdb.sh" and by > maintaining > the port and on the way to make it more CURRENT compliant, I started with > renaming it to > "refdb" and it seems this is the culprit. > > The script textproc/refdb uses is a bit awkward since it targets both *BSD > and Linux > init/rc scripts and the initial rc.d/refddb scripts gives control to another > script > called refdbctl which seems to perform all the stuff FreeBSD's /etc/rc.subr > is providing. > > I renamed the script back to "refdb.sh" by now and the service starts again as > expected. I guess the spawning into a subshell fails somehow at that point > when booting > the box. > I had a look at scripts/refdb.in, it is not a proper rc script for FreeBSD, as it is missing several keywords: # PROVIDE: <- all scripts need this # REQUIRE: # BEFORE: # KEYWORD: <- optional Which tells rcorder where to put refdb in the startup order. Since these are missing, rcorder doesn't place it in the startup list. The following will show you the order that your startup scripts run, refdb may not be listed: rcorder /etc/rc.d/* /usr/local/etc/rc.d/* Some one will have to create a proper rc script by looking at what both scripts/refdb.in and scripts/refdbctl.in do. The reason that you are able to use service to start refdb, is due to service doesn't check the scripts header for the keywords. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: service doen't get started at boottime, but can start manually
On Sun, Sep 7, 2014 at 3:39 AM, Scot Hetzel wrote:
> I had a look at scripts/refdb.in, it is not a proper rc script for
> FreeBSD, as it is missing several keywords:
>
> # PROVIDE: <- all scripts need this
> # REQUIRE:
> # BEFORE:
> # KEYWORD: <- optional
>
> Which tells rcorder where to put refdb in the startup order. Since
> these are missing, rcorder doesn't place it in the startup list.
>
I looked again, and it is not rcorder, it's /etc/rc and /etc/rc.subr
that determine which script to run.
/etc/rc calls find_local_scripts_new from /etc/rc.subr.
find_local_scripts_new checks each rc script to make sure that they
have at least a "# PROVIDE: " keyword. If it does, then it adds that
script to ${local_rc}. Then /etc/rc runs:
files=`rcorder /etc/rc.d/* ${local_rc}`
to get the startup order for these scripts. Then /etc/rc starts the
scripts in the proper order.
Since, /usr/local/etc/rc.d/refdb{,.sh.dist} is missing the "# PROVIDE:
", the script is skipped on startup.
Since, rc.d/refdb is not a proper rc script, adding refdb_enable=YES
to /etc/rc.conf{,.local} will not control the starting of this script.
Someone should fix service, so that it checks the rc script has a "#
PROVIDE: ", and displays an error message if it doesn't.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: service doen't get started at boottime, but can start manually
On Sun, Sep 7, 2014 at 4:28 AM, O. Hartmann wrote:
> Am Sun, 7 Sep 2014 04:03:25 -0500
> Scot Hetzel schrieb:
>
>> On Sun, Sep 7, 2014 at 3:39 AM, Scot Hetzel wrote:
>> > I had a look at scripts/refdb.in, it is not a proper rc script for
>> > FreeBSD, as it is missing several keywords:
>> >
>> > # PROVIDE: <- all scripts need this
>> > # REQUIRE:
>> > # BEFORE:
>> > # KEYWORD: <- optional
>> >
>> > Which tells rcorder where to put refdb in the startup order. Since
>> > these are missing, rcorder doesn't place it in the startup list.
>> >
>> I looked again, and it is not rcorder, it's /etc/rc and /etc/rc.subr
>> that determine which script to run.
>>
>> /etc/rc calls find_local_scripts_new from /etc/rc.subr.
>> find_local_scripts_new checks each rc script to make sure that they
>> have at least a "# PROVIDE: " keyword. If it does, then it adds that
>> script to ${local_rc}. Then /etc/rc runs:
>>
>> files=`rcorder /etc/rc.d/* ${local_rc}`
>>
>> to get the startup order for these scripts. Then /etc/rc starts the
>> scripts in the proper order.
>>
>> Since, /usr/local/etc/rc.d/refdb{,.sh.dist} is missing the "# PROVIDE:
>> ", the script is skipped on startup.
>>
>> Since, rc.d/refdb is not a proper rc script, adding refdb_enable=YES
>> to /etc/rc.conf{,.local} will not control the starting of this script.
>>
>> Someone should fix service, so that it checks the rc script has a "#
>> PROVIDE: ", and displays an error message if it doesn't.
>
> Hello Scott,
>
> as the new maintainer of this port, I'm working on a solution, but first, I
> have to
> understand the way this obscure rc-script system works. Thanks for your good
> explanation.
> I tried to put PROVIDE/REQUIRE in the script, but I also changed refdb.sh ->
> refdb
> which, in the end, didn't work. The service IS started with refdb.sh in rc.d/.
>
> Since the original refdb.sh init script targets both Linux and *BSD and
> delegates the
> starting, stopping et cetera to a script called refdbctl, the latter script
> needs to be
> examinded and as far as I understand, most of its functionality is covered
> by /etc/rc.cubr, except the part where refdbctl searches for the path of the
> PID file and
> replaces the init/default path its configuration counterpart found in
> /etc/refdb/refdbdrc.
>
> I guess, at the end FreeBSD doen't need the templated refdbctl/refdb.in (to
> be found in
> the sources in scripts/).
>
> If you'd like to have a look at it, I can send you the sekelton I've already
> prepared for
> the refurbishment of the port.
>
I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a
few minor changes.
This script (untested) should do what the scripts/refdb.in and
scripts/refdbctl.in were doing:
#!/bin/sh
#
# $FreeBSD$
#
# PROVIDE: refdbd
# REQUIRE: LOGIN
# KEYWORD: shutdown
. /etc/rc.subr
name="refdbd"
rcvar="refdbd_enable"
command="%%PREFIX%%/bin/${name}"
pidfile="/var/run/${name}.pid"
required_files="/etc/${name}.conf"
extra_commands="reload"
load_rc_config $name
run_rc_command "$1"
Place the above in textproc/refdb/files/refdb.in, then add:
USE_RC_SUBR= refdbd
in textproc/refdb/Makefile.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: service doen't get started at boottime, but can start manually
On Sun, Sep 7, 2014 at 10:44 AM, Scot Hetzel wrote:
> I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a
> few minor changes.
> This script (untested) should do what the scripts/refdb.in and
> scripts/refdbctl.in were doing:
>
> #!/bin/sh
> #
> # $FreeBSD$
> #
>
> # PROVIDE: refdbd
> # REQUIRE: LOGIN
> # KEYWORD: shutdown
>
> . /etc/rc.subr
>
> name="refdbd"
> rcvar="refdbd_enable"
> command="%%PREFIX%%/bin/${name}"
> pidfile="/var/run/${name}.pid"
> required_files="/etc/${name}.conf"
I missed required_files in my editing of the original script.
If refdbd does have a configuration file, changes this to point to the
correct file, otherwise this can be removed.
> extra_commands="reload"
>
> load_rc_config $name
> run_rc_command "$1"
>
> Place the above in textproc/refdb/files/refdb.in, then add:
>
> USE_RC_SUBR= refdbd
>
> in textproc/refdb/Makefile.
>
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots
On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk wrote: > Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working > SLOW . FreeBSD A > Computer B : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working > FAST . FreeBSD B > > Interchange memory chips : > > Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working > FAST . FreeBSD A > Computer B : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working > SLOW . FreeBSD B > > What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB )? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: control of order of inet devices
On Wed, Apr 17, 2013 at 4:14 AM, Willy Offermans wrote: > Hello Brooks, > > On Tue, Apr 16, 2013 at 10:44:23AM -0500, Brooks Davis wrote: > > On Tue, Apr 16, 2013 at 03:56:21PM +0200, Willy Offermans wrote: > > > Dear FreeBSD friends, > > > > > > How can I control the order of the network devices in FreeBSD. > > > > > > For example, the command ifconfig lists the network devices: > > > > > > pcn0: flags=8802 metric 0 mtu 1500 > > > options=8 > > > ether 00:0c:46:ea:2b:32 > > > nd6 options=29 > > > media: Ethernet 100baseFX > > > status: no carrier > > > rl0: flags=8843 metric 0 mtu > 1500 > > > options=2008 > > > ether 00:11:6b:99:7c:5a > > > inet XXX.XXX.24.4 netmask 0xff80 broadcast 137.226.24.127 > > > inet6 fe80::211:6bff:fe99:7c5a%rl0 prefixlen 64 scopeid 0x4 > > > nd6 options=29 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > nfe0: flags=8802 metric 0 mtu 1500 > > > options=82008 > > > ether 00:1b:fc:df:a1:33 > > > nd6 options=29 > > > media: Ethernet autoselect (none) > > > status: no carrier > > > plip0: flags=8810 metric 0 mtu 1500 > > > nd6 options=29 > > > lo0: flags=8049 metric 0 mtu 16384 > > > options=63 > > > inet6 ::1 prefixlen 128 > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 > > > inet 127.0.0.1 netmask 0xff00 > > > nd6 options=21 > > > tap0: flags=8843 metric 0 mtu > 1500 > > > options=8 > > > ether 00:22:19:10:8d:bb > > > inet XXX.XXX.24.19 netmask 0x broadcast 137.226.24.19 > > > inet6 fe80::2bd:83ff:fe68:7200%tap0 prefixlen 64 scopeid 0x8 > > > nd6 options=21 > > > media: Ethernet autoselect > > > status: no carrier > > > > > > pcn0 being first. However, I would like tap0 being first and of course > > > without any output ordering trick. > > > > The order is dictated by the order the drivers are probed by the kernel. > > When the devices are created they are added to a linked list. There is > > no practical way to control the order and it has little or no effect. > > > > -- Brooks > > This is what I read in some of the articles or handbook as well. Can I > reorder this linked list? Can I control the order by creating the kernel > and reordering the inclusion of the device drivers? > > I am aware that the request sounds silly, but I have a third party program > which checks its licence against the first inet device. Since I have added > a new inet controller, the sequence has changed. Of course I ask for a new > licence, but they want to charge me for that and I do not see any reason > for that. > What information did you give them when you registered that software? Was it just the MAC address of tap0? If it was just the MAC address of tap0, you could try changing the MAC address of pcn0 to the MAC address of tap0: echo 'ifconfig pcn0 ether 00:22:19:10:8d:bb' >/etc/start_if.pcn0 echo 'ifconfig tap0 ether 00:22:19:10:8d:bc' >/etc/start_if.tap0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: swapon(8) vnode-backed md and gbde/geli encryption support
On Sat, Jun 22, 2013 at 1:53 PM, Hiroki Sato wrote: > Hi, > > I created a patchset to add support of automatic generation of > vnode-backed md(4) devices and gbde/geli geom providers to swapon(8) > via /etc/fstab. We already have equivalent functionality by using > rc.d scripts. This simplifies rc.d scripts and fixes a race between > mdconfig/gbde/geli and swapon/swapoff by using /etc/fstab. > > More specifically, the following specification will be supported: > > /dev/ada1p1.bdenoneswapsw 0 0 > /dev/ada1p2.elinoneswapsw 0 0 > md noneswapsw,file=/swap.bin 0 0 > md10 noneswapsw,file=/swap10.bin 0 0 > md12 noneswapsw,file=/usr/swap12.bin,late0 0 > > Currently, rc.d/swap1, rc.d/encswap handles entries with FSTAB_SW and > then rc.d/addswap for additional swap space specified in rc.conf. > The rc.d/addswap script runs before NETWORKING, so it is difficult to > add a swap space by using a file via NFS on a diskless client. The > "late" keyword in /etc/fstab will give more flexibility in such a > case. > > So, the changes to rc.d scripts are the following: > > rc.d/encswap -> (removed) > rc.d/swap1 -> rc.d/swap > rc.d/swaplate -> (added) > > rc.d/addswap is not removed in the patchset, but is it still > necessary? I do not think using combination of rc.d scripts to > support md(4) device generation for swap spaces is robust, and I > believe /etc/fstab is sufficient for the same functionality. > > Any comments are welcome. Thank you. > The only thing I see is that you are hard coding the geli_swap_flags (i.e. -e aes -l 256 -s 4096 -d) into swapon. It would be better to have swapon read the /etc/fstab file to get these values: /dev/ada1p2.elinoneswap sw,ealgo=aes,keylen=256,sectorsize=4096 0 0 /dev/ada2p2.elinoneswapsw 0 0 What you could do is that if no options are specified in the swap file, swapon would then use default values for ealgo=aes, keylen=256 and sectorsize=4096. geli onetime [-d] [-a aalgo] [-e ealgo] [-l keylen] [-s sectorsize] prov The options for the geli encrypted swap file in /etc/fstab would then become: aalgo ealgo keylen sectorsize Note: the '-d' option would still be hard coded. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Thu, Jul 11, 2013 at 9:33 AM, David Chisnall wrote: > On 11 Jul 2013, at 13:11, Bruce Evans wrote: > >> The error message for the __builtin_isnan() version is slightly better up >> to where it says more. >> >> The less-unportable macro can do more classification and detect problems >> at compile time using __typeof(). > > The attached patch fixes the related test cases in the libc++ test suite. > Please review. > #definefpclassify(x) \ -((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \ -: (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \ -: __fpclassifyl(x)) +__fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyd) The last __fpclassifyd should be __fpclassifyl. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Fri, Jul 12, 2013 at 11:16 AM, Scot Hetzel wrote: > On Thu, Jul 11, 2013 at 9:33 AM, David Chisnall wrote: >> On 11 Jul 2013, at 13:11, Bruce Evans wrote: >> >>> The error message for the __builtin_isnan() version is slightly better up >>> to where it says more. >>> >>> The less-unportable macro can do more classification and detect problems >>> at compile time using __typeof(). >> >> The attached patch fixes the related test cases in the libc++ test suite. >> Please review. >> > > #definefpclassify(x) \ > -((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \ > -: (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \ > -: __fpclassifyl(x)) > +__fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyd) > > The last __fpclassifyd should be __fpclassifyl. > I see it has already been fixed. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ports with daemons on uninstall...
On Sun, Jul 14, 2013 at 10:52 AM, Ian FREISLICH wrote: > Hi > > I have to ask if there's a standard for the way ports should handle > their daemons when the port is uninstalled. > > I've encountered 3 varients of ports behaviour on uninstall: > > 1. Do nothing > 2. Stop the daemon > 3. Ask if the daemon should be stopped > > #1 closely followed by #3 are the least irritating when it comes > to portupgrade because you can at least have the service running > while upgrading. At least with #3 the upgrade gets paused until > the propmpt is answered and you're then aware that some service > will go away immediately so you can be prepared to restart it. > > #2 is extremely irritating because upgrading with portupgrade etc > kills the service. For instance isc-dhcpd* does this which means > that for some time, dhcp may be unavailable. It could be less > irritating if it would automatically start the service, but that > can have its own problems. > > Does the project have a preferred method for handling running > daenmons on uninstall? I know that Linux will even start daemons > on install. > Personally, I prefer that when uninstalling a port, that the daemon gets stopped. But if you are upgrading a port, then you will want the daemon to be re-started. This should be possible with the new pkg tools, but I don't know if it is implemented: pkg install isc-dhcpd42-server - pkg installs the port doesn't start service - admin starts service with /usr/local/etc/rc.d/isc-dhcpd start pkg upgrade isc-dhcp42-server - pkg checks the repository and finds a new version and asks if you want it installed - pkg checks if the service(s) is running, saves the status for later - pkg uninstalls the old port - pkg installs the new port - pkg checks the saved status to see if it needs to restart the service(s) pkg uninstall isc-dhcpd42-server - pkg uninstalls the port and stops the service if running -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GCC withdraw
On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov wrote: > On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: > >> On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: >> >> > On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote: >> > >> > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang >> > > don't understand inlined asm. >> > >> > Clang supports inline asm. If there is some specific inline asm >> > syntax that clang does not recognise, then please will you point me >> > to the relevant LLVM bug report and I will investigate it. >> >> Sorry, I don't know about clang/llvm bug reports, I just try to build >> mplayer with Win32 codecs support on FreeBSD-10/i386. >> >> And currenly (in rev r315041) building by clang disabled in ports tree. > > And i found PR about clang and mplayer: ports/176272 > This PR contains log with build error log. PR176272 is form mplayer-1.1.r20120721_2, and was closed due to the issue was fixed by updating the port to a more recent version. Mplayer is currently mplayer-1.1.r20130308, do you still see the same issues with clang? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic in ieee80211 tx mgmt timeout
On Tue, Jun 28, 2011 at 4:28 AM, Stefan Esser wrote: > This panic message is manually transcribed, since the GPT-only > partitioning prevents dumping of a kernel core. (Why, BTW?) You should be able to get a kernel core dump on a system with a GPT partitioned disk. Do you have a freebsd-swap partition? How is your GPT disk partitioned? Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em problem in virtualbox since the weekend
On Thu, Jul 21, 2011 at 10:53 AM, John Baldwin wrote:
> Hmm, so there does look to be a reasonable _CRS method. Oh, I think I see
> what I don't like:
>
> DWordMemory (ResourceProducer, PosDecode, MinNotFixed,
> MaxFixed, Cacheable, ReadWrite,
> 0x, // Granularity
> 0x, // Range Minimum
> 0xFFDF, // Range Maximum
> 0x, // Translation Offset
> 0x, // Length
> ,, _Y01, AddressRangeMemory, TypeStatic)
>
This patch fixed the problem with my recent install of FreeBSD 9.0 on
VirtualBox.
Thanks for the fix.
Scot
> It should be using MinFixed, not MinNotFixed. Try this patch:
>
> Index: acpi_pcib_acpi.c
> ===
> --- acpi_pcib_acpi.c (revision 224217)
> +++ acpi_pcib_acpi.c (working copy)
> @@ -207,10 +207,12 @@ acpi_pcib_producer_handler(ACPI_RESOURCE *res, voi
> length = res->Data.ExtAddress64.AddressLength;
> break;
> }
> - if (length == 0 ||
> - res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED ||
> - res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED)
> + if (length == 0)
> break;
> + if (min + length - 1 != max &&
> + (res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED
> ||
> + res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED))
> + break;
> flags = 0;
> switch (res->Data.Address.ResourceType) {
> case ACPI_MEMORY_RANGE:
>
> --
> John Baldwin
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA1 installer glithcies (i386)
2011/8/21 Kevin Oberman : > 2011/8/21 Lev Serebryakov : >> Hello, Nathan. >> You wrote 21 августа 2011 г., 20:53:22: >> >>> GPT is bootable on all x86 systems, with either EFI or BIOS, and is now >> Ok, I was not sure here. > > The Wikipedia article on GUID Partition Table states that Windows only > supports > GPT boot when the system is a EFI system and is 64-bit Windows, Vista or > newer. > Windows-32 will not boot from a GPT disk. > > I know Wikipedia is not always right, but it matches my limited experience. > > https://secure.wikimedia.org/wikipedia/en/wiki/GUID_Partition_Table Since this is the FreeBSD list, we are talking about booting FreeBSD from GPT partitioned disks. FreeBSD supports booting from both PC/BIOS and EFI Systems. If you want to dual boot between FreeBSD and Windows, then you will need a MBR Partitioned disk. > -- > R. Kevin Oberman, Network Engineer - Retired > E-mail: kob6...@gmail.com > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS: i/o error - all block copies unavailable after upgrading to r225312
On Sun, Sep 11, 2011 at 6:31 AM, Peter Jeremy wrote: > In any case, size isn't an issue for any of gptboot, gptzfsboot or > zfsboot (unlike boot2). For that matter, why do we need both > gptboot and gptzfsboot? It would be more convenient to have a > single GPT bootstrap that handled both UFS & ZFS. > gptzfsboot contains CDDL licensed code. This was done to allow users to build/install FreeBSD without any CDDL licensed boot code. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
