Unable to installworld after successful buildworld and buildkernel
From $SRCDIR/UPDATING
To cross-install current onto a separate partition
--
# In this approach we use a separate partition to hold
# current's root, 'usr', and 'var' directories. A partition
# holding /, /usr and /var should be about 2GB in
# size.
make sure you have good level 0 dumps
boot into -stable
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
maybe newfs current's root partition
mount current's root partition on directory ${CURRENT_ROOT}
make installworld DESTDIR=${CURRENT_ROOT}
make distribution DESTDIR=${CURRENT_ROOT} # if newfs'd
make installkernel KERNCONF=YOUR_KERNEL_HERE DESTDIR=${CURRENT_ROOT}
cp /etc/fstab ${CURRENT_ROOT}/etc/fstab# if newfs'd
edit ${CURRENT_ROOT}/etc/fstab to mount / from the correct partition
reboot into current
do a native rebuild/install as described in the previous section
maybe install compatibility libraries from ports/misc/compat*
reboot
This part seems not to have changed so far from RELENG_9 to HEAD.
I failed on make installworld DESTDIR=/BETA1 | tee installworld.log
ERROR: Required unbound user is missing, see /usr/src/UPDATING
How am I supposed to have an unbound user on a partition where there is no
existing FreeBSD installation?
Like the job market, where one needs to have two or more years experience, but
how to get that first job?
I tried
mergemaster -p -m /BETA1/usr/src -D /BETA1
on thin air, managed to get a master.passwd that included unbound user, but
make installworld DESTDIR=/BETA1
failed immediately for lack of unbound user it couldn't find.
I also tried
make distribution DESTDIR=/BETA1
(and distributeworld too), no joy:
Target directory, either /BETA1/etc or /BETA1/etc/atf, does not exist.
There is a bug in $SRCDIR/UPDATING in the part about cross-installing current
onto a separate partition.
I even tried copying /etc directory from USB stick to /BETA1/etc before running
mergemaster, but that also failed.
But this was no barrier when I built and installed FreeBSD 9-stable i386 on a
USB stick, mounted as /compat/i386.
From https://wiki.freebsd.org/i386-Wine
# cd /usr/src
# make buildworld TARGET=i386
# make installworld TARGET=i386 DESTDIR=/compat/i386
# make distribution TARGET=i386 DESTDIR=/compat/i386
# mkdir /compat/i386/usr/ports
# mount -t devfs devfs /compat/i386/dev
# mount -t nullfs /usr/ports /compat/i386/usr/ports
but instead of the latter part, after make distribution ...
I made buildkernel and installkernel, and booted from the USB stick, used ports
directory on hard drive.
That worked, but wouldn't work for FreeBSD-current now due to unbound and /etc
problems?
How does one install FreeBSD, building from source, on a partition with no OS
installed?
Directories on this partition include /netbsd-HEAD, /pkgsrc, and /usr/src,
/usr/ports and /usr/doc.
I use a USB-stick installation of FreeBSD 9.2 prerelease for building
FreeBSD-current, but due to a bug in re driver, could not connect to Internet
with Realtek 8111E Ethernet on MSI Z77 MPOWER motherboard.
NetBSD-current (6.99.19 updated to 6.99.23) was able to access this Ethernet,
so I checked out, by cvs, NetBSD-current source and pkgsrc tree (current, not
quarterly), updated NetBSD and packages, and successfully built subversion.
Then I used this svn to checkout FreeBSD-current source tree.
I believe FreeBSD installation would not touch directories /netbsd-HEAD and
/pkgsrc.
Tom
___
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
brigding between two interfaces
Hi, i am little bit weak in networking concept, i have two network interfaces usb0 and eth0, eth0 is connected to a static ip, which works perfectly fine, now i want that usb0 should be able to access static ip which is connected to eth0, can anyone guide me proper solutionwith command for this which i can test thanks ___ 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
Running i386 CURRENT on an AMD64 platform:: CLang related
I've ran into compiling problems with some ports. World and kernel have not yet been rebuilt. 10.x is a pre-APLHA release. Before I attempt to rebuild any of the system, has anyone else had any problems related to building i386 on AMD64? ___ 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: Running i386 CURRENT on an AMD64 platform:: CLang related
08.10.2013 11:45, Joe Nosay пишет: I've ran into compiling problems with some ports. World and kernel have not yet been rebuilt. 10.x is a pre-APLHA release. Please, show diagnostic messages (of failing ports). Before I attempt to rebuild any of the system, has anyone else had any problems related to building i386 on AMD64? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: [patch] Re: drm2/radeon dfixed_trunc() warnings
On 07.10.2013 21:04, Sean Bruno wrote: Proposed patch to eliminate this check. If I understand the macro correctly, there's no way for these checks to ever do anything as bit shifting an unsigned will simply clear out the value. So, the check for 0 is completely bogus? Hello! I think you're right. I saw Clang reporting those warnings. Coverity has many more. I didn't want to fix them for now, to ease future merges from Linux. The plan is to submit patches to upstream at some point. Thanks for the patch! I should prepare a branch to store that kind of fixes. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Running i386 CURRENT on an AMD64 platform:: CLang related
08.10.2013 11:55, Boris Samorodov пишет: 08.10.2013 11:45, Joe Nosay пишет: I've ran into compiling problems with some ports. World and kernel have not yet been rebuilt. 10.x is a pre-APLHA release. Please, show diagnostic messages (of failing ports). OK, I've seen you have posted them to freebsd-ports@. Before I attempt to rebuild any of the system, has anyone else had any problems related to building i386 on AMD64? Anyway, I'd say that it's a good idea to update your system since there were many changes you may be interested in. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Oct 7, 2013, at 10:48 PM, Allan Jude wrote: On 2013-10-08 01:11, Teske, Devin wrote: On Oct 7, 2013, at 10:07 PM, Allan Jude wrote: On 2013-10-07 15:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback I've generated a new version of the ISO incorporating all of todays changes and moving up to 10.0-ALPHA5 It includes 2 patches from Warren Block, improving the keymap menu and indicating which network interfaces are wireless Excellent. However, I have to say... you opened a can of worms by touching keymap. Eventually I plan to rewrite all of the scripts to the same format that zfsboot is using. I've already started rewriting keymap to the new format. Of course, this opened up another can of worms... the simple things like: DIALOG_OK DIALOG_CANCEL DIALOG_ESC Yeah, after having them, I felt a bit naked not having all of those 'constants' defined. The constants are now where they belong... `dialog.subr' I also went through bsdconfig(8) with a fine-tooth comb and made use of the new constants everywhere. I think it's a definite improvement. Originally, all I had done was add --defaultno to the dialog command, but Warren's patch makes a lot of sense, allow the user to 'try' the new keymap before trying to do the rest of the install based on it. I rewrote warren's code into the stateful design and cleaned it up. I feel would be much better off in the `dialog.subr' module. So,... I've started peppering their usage everywhere in bsdconfig to make them proper. That means they will just be transparent from including `dialog.subr'. This is definately something that I think is a good idea, but my focus is on improving the usability and functionality of the installer in time for 10.0. Unifying everything to the bsdconfig style is slightly lower priority. Admittedly, the `bsdconfig networking` stuff is quite nice *nods* I took a look at the bsdinstall networking stuff, and I wanted to run away. Let's push that into the future. It wasn't too hard to get those global exit codes deployed, so I did that, but like you say... I agree we should minimize extra work that will be eventually slated for a future release. -- Devin http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso Excellent, thanks! -- Allan Jude ___ 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 _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: brigding between two interfaces
Yasir hussan kolyasir at gmail.com writes: Hi, i am little bit weak in networking concept, i have two network interfaces usb0 and eth0, eth0 is connected to a static ip, which works perfectly fine, now i want that usb0 should be able to access static ip which is connected to eth0, http://www.freebsd.org/doc/handbook/network-bridging.html jb ___ 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
test
test ___ 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: rcs
On 10/7/13 9:49 PM, Julian Elischer wrote: On 10/8/13 11:19 AM, Lyndon Nerenberg wrote: On 2013-10-07, at 8:15 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: Maybe there was no development for 15 years. However, the 7364 lines in ChangeLog after 2010-02-04 suggests that there may be few bugs to worry about. I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. So again, is there a way to make it so adding RCS after install is not a big deal at all? -- Alfred Perlstein ___ 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
Virtual box require LIBCXX
I finish install a virtual box from ports and it's build ok, look === Installing ldconfig configuration file === Registering installation for virtualbox-ose-4.2.18_1 Installing virtualbox-ose-4.2.18_1... done === SECURITY REPORT: This port has installed the following binaries which execute with increased privileges. /usr/local/lib/virtualbox/VirtualBox /usr/local/lib/virtualbox/VBoxSDL /usr/local/lib/virtualbox/VBoxHeadless /usr/local/lib/virtualbox/VBoxAutostart /usr/local/lib/virtualbox/VBoxBFE /usr/local/lib/virtualbox/VBoxTestOGL /usr/local/lib/virtualbox/VBoxNetAdpCtl /usr/local/lib/virtualbox/VBoxNetDHCP This port has installed the following files which may act as network servers and may therefore pose a remote security risk to the system. /usr/local/lib/virtualbox/vboxwebsrv /usr/local/lib/virtualbox/VBoxXPCOM.so /usr/local/lib/virtualbox/VBoxRT.so /usr/local/lib/virtualbox/VBoxDD.so /usr/local/lib/virtualbox/VBoxOGLhostcrutil.so (USES POSSIBLY INSECURE FUNCTIONS: tmpnam) /usr/local/lib/virtualbox/webtest This port has installed the following startup scripts which may cause these network services to be started at boot time. /usr/local/etc/rc.d/vboxheadless /usr/local/etc/rc.d/vboxwebsrv If there are vulnerabilities in these programs there may be a security risk to the system. FreeBSD makes no guarantee about the security of ports included in the Ports Collection. Please type 'make deinstall' to deinstall the port if this is a concern. For more information, and contact details about the security status of this software, see the following webpage: http://www.virtualbox.org/ === Cleaning for dev86-0.16.18 === Cleaning for kBuild-0.1.9998 === Cleaning for gtar-1.27 === Cleaning for gsoap-2.8.10_1 === Cleaning for libvncserver-0.9.9_5 === Cleaning for virtualbox-ose-kmod-4.2.18 === Cleaning for virtualbox-ose-4.2.18_1 root@valfenda:/usr/ports/emulators/virtualbox-ose # kldload vboxdrv root@valfenda:/usr/ports/emulators/virtualbox-ose # but whern I run it, the I got this error message: rizzo@valfenda:~/src/Doutorado/visao/testes % VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found VirtualBox: Tip! It may help to reinstall VirtualBox. rizzo@valfenda:~/src/Doutorado/visao/testes % I update my system and port to last nigth root@valfenda:/home2/rizzo # cd /usr root@valfenda:/usr # svn info src Caminho: src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/base UUID do repositório: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revisão: 256108 Tipo de Nó: diretório Agendado: normal Autor da Última Mudança: glebius Revisão da Última Mudança: 256108 Data da Última Mudança: 2013-10-07 09:07:40 -0300 (Seg, 07 Out 2013) root@valfenda:/usr # svn info ports Caminho: ports Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/ports UUID do repositório: 35697150-7ecd-e111-bb59-0022644237b5 Revisão: 329758 Tipo de Nó: diretório Agendado: normal Autor da Última Mudança: ak Revisão da Última Mudança: 329758 Data da Última Mudança: 2013-10-08 02:47:27 -0300 (Ter, 08 Out 2013) root@valfenda:/usr # uname -a FreeBSD valfenda 10.0-ALPHA5 FreeBSD 10.0-ALPHA5 #3 r256108: Tue Oct 8 02:55:04 BRT 2013 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64 root@valfenda:/usr # What's do I wrong? TIA, Rizzo ___ 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: Unable to installworld after successful buildworld and buildkernel
On Tue, Oct 08, 2013 at 06:29:53AM +, Thomas Mueller wrote:
From $SRCDIR/UPDATING
To cross-install current onto a separate partition
--
# In this approach we use a separate partition to hold
# current's root, 'usr', and 'var' directories. A partition
# holding /, /usr and /var should be about 2GB in
# size.
make sure you have good level 0 dumps
boot into -stable
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
maybe newfs current's root partition
mount current's root partition on directory ${CURRENT_ROOT}
make installworld DESTDIR=${CURRENT_ROOT}
make distribution DESTDIR=${CURRENT_ROOT} # if newfs'd
make installkernel KERNCONF=YOUR_KERNEL_HERE DESTDIR=${CURRENT_ROOT}
cp /etc/fstab ${CURRENT_ROOT}/etc/fstab# if
newfs'd
edit ${CURRENT_ROOT}/etc/fstab to mount / from the correct
partition
reboot into current
do a native rebuild/install as described in the previous section
maybe install compatibility libraries from ports/misc/compat*
reboot
This part seems not to have changed so far from RELENG_9 to HEAD.
I failed on make installworld DESTDIR=/BETA1 | tee installworld.log
ERROR: Required unbound user is missing, see /usr/src/UPDATING
How am I supposed to have an unbound user on a partition where there is no
existing FreeBSD installation?
Like the job market, where one needs to have two or more years experience,
but how to get that first job?
I tried
mergemaster -p -m /BETA1/usr/src -D /BETA1
on thin air, managed to get a master.passwd that included unbound user, but
make installworld DESTDIR=/BETA1
failed immediately for lack of unbound user it couldn't find.
I also tried
make distribution DESTDIR=/BETA1
(and distributeworld too), no joy:
Target directory, either /BETA1/etc or /BETA1/etc/atf, does not exist.
There is a bug in $SRCDIR/UPDATING in the part about cross-installing current
onto a separate partition.
I even tried copying /etc directory from USB stick to /BETA1/etc before
running mergemaster, but that also failed.
But this was no barrier when I built and installed FreeBSD 9-stable i386 on a
USB stick, mounted as /compat/i386.
From https://wiki.freebsd.org/i386-Wine
# cd /usr/src
# make buildworld TARGET=i386
# make installworld TARGET=i386 DESTDIR=/compat/i386
# make distribution TARGET=i386 DESTDIR=/compat/i386
# mkdir /compat/i386/usr/ports
# mount -t devfs devfs /compat/i386/dev
# mount -t nullfs /usr/ports /compat/i386/usr/ports
but instead of the latter part, after make distribution ...
I made buildkernel and installkernel, and booted from the USB stick, used
ports directory on hard drive.
That worked, but wouldn't work for FreeBSD-current now due to unbound and
/etc problems?
How does one install FreeBSD, building from source, on a partition with no OS
installed?
To cross install FreeBSD on a system without the required users/groups
you must either install them on the base system so that install and
mtree can use them or use the -DDB_FROM_SRC option when running the
installworld/installkernel/distribution targets.
-- Brooks
pgpZauhw1mTo9.pgp
Description: PGP signature
Re: rcs
I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. Not commenting on RCS here, but on the concept of moving packages out of the base: - For some of us, the attraction of FreeBSD is that it is a tightly integrated system, and the base contains enough useful functionality that we don't *have* to add a lot of packages. - Each package that is moved out of the base system means less useful functionality in the base system - and for me: Less reason to use FreeBSD instead of Linux. I absolutely see the problem of maintaining out-of-date packages in the base system, and the desirability of making the base system less reliant on GPL. I'm mostly troubled by the fact that there seems to be a rather strong tendency the last few years of having steadily less functionality in the base system - and I'm not at all convinced that the right balance has been found here. This discussion is not new, and I don't expect to convince any new persons... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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 Alpha5 amd64 - Citrix Xen 6.2 problem
Problem with Citrix Xen 6.2 and install from ISO. The solution was remove cd-rom drive from virtual machine. Not possible now with xen default in GENERIC kernel. Message error: run_interrupt_driven_hooks - still waiting after 300 seconds for xenbusb_nop_confighook_cb panic: run_interrupt_driven_config_hooks: waited too long -- Best Regards, Josias L.G ___ 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: rcs
On 10/8/13 8:04 AM, sth...@nethelp.no wrote: I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. Not commenting on RCS here, but on the concept of moving packages out of the base: - For some of us, the attraction of FreeBSD is that it is a tightly integrated system, and the base contains enough useful functionality that we don't *have* to add a lot of packages. - Each package that is moved out of the base system means less useful functionality in the base system - and for me: Less reason to use FreeBSD instead of Linux. I absolutely see the problem of maintaining out-of-date packages in the base system, and the desirability of making the base system less reliant on GPL. I'm mostly troubled by the fact that there seems to be a rather strong tendency the last few years of having steadily less functionality in the base system - and I'm not at all convinced that the right balance has been found here. This discussion is not new, and I don't expect to convince any new persons... I'm sure other devs will disagree, but with ~15 years of FreeBSD experience and ~13 years as a dev, my very strong opinion is that this tightly coupled system is actually a boat anchor sinking us. Just because no one else does it a certain way, does not mean that a unique way of doing something is correct and/or sustainable. Maybe in 1995, 1999, or 2005 even, but not today. Especially in the context of add-on tools like rcs. What we need to discuss is lowering the bar to making custom installs. I personally find that installing FreeBSD is useless until I install screen, zsh, vim-lite, git why is that so manual for me? Why can't I just register a package set somewhere so that all I have to type in is alfred.perlstein.devel into a box during the installer and I get all my packages by default? -- Alfred Perlstein ___ 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: rcs
On Tue, Oct 8, 2013 at 5:20 PM, Alfred Perlstein bri...@mu.org wrote: On 10/8/13 8:04 AM, sth...@nethelp.no wrote: I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. Not commenting on RCS here, but on the concept of moving packages out of the base: - For some of us, the attraction of FreeBSD is that it is a tightly integrated system, and the base contains enough useful functionality that we don't *have* to add a lot of packages. - Each package that is moved out of the base system means less useful functionality in the base system - and for me: Less reason to use FreeBSD instead of Linux. I absolutely see the problem of maintaining out-of-date packages in the base system, and the desirability of making the base system less reliant on GPL. I'm mostly troubled by the fact that there seems to be a rather strong tendency the last few years of having steadily less functionality in the base system - and I'm not at all convinced that the right balance has been found here. This discussion is not new, and I don't expect to convince any new persons... I'm sure other devs will disagree, but with ~15 years of FreeBSD experience and ~13 years as a dev, my very strong opinion is that this tightly coupled system is actually a boat anchor sinking us. Just because no one else does it a certain way, does not mean that a unique way of doing something is correct and/or sustainable. Maybe in 1995, 1999, or 2005 even, but not today. Especially in the context of add-on tools like rcs. What we need to discuss is lowering the bar to making custom installs. I personally find that installing FreeBSD is useless until I install screen, zsh, vim-lite, git why is that so manual for me? Why can't I just register a package set somewhere so that all I have to type in is alfred.perlstein.devel into a box during the installer and I get all my packages by default? -- Alfred Perlstein You technically can. Make your own meta-port which depends on the stuff you want. Build package-set with for example poudriere, ship those packages on your install-media. Done. /Andreas __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org 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: rcs
On 10/8/13 8:26 AM, Andreas Nilsson wrote: On Tue, Oct 8, 2013 at 5:20 PM, Alfred Perlstein bri...@mu.org mailto:bri...@mu.org wrote: On 10/8/13 8:04 AM, sth...@nethelp.no mailto:sth...@nethelp.no wrote: I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. Not commenting on RCS here, but on the concept of moving packages out of the base: - For some of us, the attraction of FreeBSD is that it is a tightly integrated system, and the base contains enough useful functionality that we don't *have* to add a lot of packages. - Each package that is moved out of the base system means less useful functionality in the base system - and for me: Less reason to use FreeBSD instead of Linux. I absolutely see the problem of maintaining out-of-date packages in the base system, and the desirability of making the base system less reliant on GPL. I'm mostly troubled by the fact that there seems to be a rather strong tendency the last few years of having steadily less functionality in the base system - and I'm not at all convinced that the right balance has been found here. This discussion is not new, and I don't expect to convince any new persons... I'm sure other devs will disagree, but with ~15 years of FreeBSD experience and ~13 years as a dev, my very strong opinion is that this tightly coupled system is actually a boat anchor sinking us. Just because no one else does it a certain way, does not mean that a unique way of doing something is correct and/or sustainable. Maybe in 1995, 1999, or 2005 even, but not today. Especially in the context of add-on tools like rcs. What we need to discuss is lowering the bar to making custom installs. I personally find that installing FreeBSD is useless until I install screen, zsh, vim-lite, git why is that so manual for me? Why can't I just register a package set somewhere so that all I have to type in is alfred.perlstein.devel into a box during the installer and I get all my packages by default? -- Alfred Perlstein You technically can. Make your own meta-port which depends on the stuff you want. Build package-set with for example poudriere, ship those packages on your install-media. Done. Oh I have done that in the past, but why the editing, the makefiles, the etc, etc, etc. Why isn't there a customize.freebsd.org where I just hit a few checkboxes, save and then hit download? -- Alfred Perlstein ___ 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: rcs
On Tue, Oct 8, 2013, at 10:33, Alfred Perlstein wrote: Oh I have done that in the past, but why the editing, the makefiles, the etc, etc, etc. Why isn't there a customize.freebsd.org where I just hit a few checkboxes, save and then hit download? A metaport builder web service would be really slick, actually... ___ 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] RCS removed from base
On 10/8/13, Julian Elischer wrote: On 10/7/13 11:06 PM, Steve Kargl wrote: On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote: Hey all, RCS was removed from the base system in r256095. If you still want to use RCS please install either devel/rcs or devel/rcs57. If not, be sure to check out the alternatives (pun stolen and intended). Perhaps, a note in src/UPDATING is appropriate? ok so what is this, the secret cabal to make FreeBSD useless? I'm ccing core as I believe this was not discussed enough in public (in fact not discussed AT ALL in any forum I am watching) and I officially request a backout of the removal of what I consider to be core functionality. My usual way of doing things is on install to ci EVERYTHING in /etc to get a snapsot right the way back to install. now I have to change things in /etc (and other places) BEFORE I can check them in. (i.e. get networking up and ports installed) not a big thing but I believe that a lot of poeple use ci/co on /etc becasue it is just there +1 for keeping a RCS in base. I too use to maintain a bunch of files in /etc - I have for years and years. I don't particularly want the GPL'd version - I'd be happiest with the OpenRCS version (BSD-licensed) from OpenBSD. -Kurt ___ 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] RCS removed from base
On 10/08/13 16:36, Kurt Lidl wrote: On 10/8/13, Julian Elischer wrote: On 10/7/13 11:06 PM, Steve Kargl wrote: On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote: Hey all, RCS was removed from the base system in r256095. If you still want to use RCS please install either devel/rcs or devel/rcs57. If not, be sure to check out the alternatives (pun stolen and intended). Perhaps, a note in src/UPDATING is appropriate? ok so what is this, the secret cabal to make FreeBSD useless? I'm ccing core as I believe this was not discussed enough in public (in fact not discussed AT ALL in any forum I am watching) and I officially request a backout of the removal of what I consider to be core functionality. My usual way of doing things is on install to ci EVERYTHING in /etc to get a snapsot right the way back to install. now I have to change things in /etc (and other places) BEFORE I can check them in. (i.e. get networking up and ports installed) not a big thing but I believe that a lot of poeple use ci/co on /etc becasue it is just there +1 for keeping a RCS in base. I too use to maintain a bunch of files in /etc - I have for years and years. I don't particularly want the GPL'd version - I'd be happiest with the OpenRCS version (BSD-licensed) from OpenBSD. +1 for OpenRCS -Kurt ___ 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: rcs
On Tue, Oct 8, 2013 at 4:09 PM, Alfred Perlstein bri...@mu.org wrote: On 10/7/13 9:49 PM, Julian Elischer wrote: On 10/8/13 11:19 AM, Lyndon Nerenberg wrote: On 2013-10-07, at 8:15 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: Maybe there was no development for 15 years. However, the 7364 lines in ChangeLog after 2010-02-04 suggests that there may be few bugs to worry about. I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. So again, is there a way to make it so adding RCS after install is not a big deal at all? -- Alfred Perlstein If they get the package repositories back up - which I assume will happen before any official releases from 10 - it should just be pkg install rcs. As challenges go, that doesn't seem too bad? That said, an online meta package builder *is* a nice idea, and seems perfectly doable. -- Daniel Nebdal ___ 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 Alpha5 amd64 - Citrix Xen 6.2 problem
On Tue, Oct 8, 2013, at 9:45, Josias L.G wrote: Problem with Citrix Xen 6.2 and install from ISO. The solution was remove cd-rom drive from virtual machine. Not possible now with xen default in GENERIC kernel. Message error: run_interrupt_driven_hooks - still waiting after 300 seconds for xenbusb_nop_confighook_cb panic: run_interrupt_driven_config_hooks: waited too long I was going to test this soon... but you're right -- you probably can't install FreeBSD 10 from ISO on Citrix XenServer because of this bug. Can someone working on the xen bits test and maybe find a workaround? ___ 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: rcs
On Oct 7, 2013 7:31 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: Okay folks, can we make a call about keeping the RCS tools in the base? The proponents wanting to remove RCS need to speak up and make their technical case. Perhaps slightly off-topic, but how about we move into the 21st century and import the 2-clause BSD-licensed Fossil? http://www.fossil-scm.org/ Not RCS, I know, but vastly more useful. Jos ___ 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
The Base System (was: rcs)
On 8 October 2013 16:04, sth...@nethelp.no wrote:
- For some of us, the attraction of FreeBSD is that it is a tightly
integrated system, and the base contains enough useful functionality
that we don't *have* to add a lot of packages.
- Each package that is moved out of the base system means less useful
functionality in the base system - and for me: Less reason to use
FreeBSD instead of Linux.
I absolutely see the problem of maintaining out-of-date packages in
the base system, and the desirability of making the base system less
reliant on GPL. I'm mostly troubled by the fact that there seems to
be a rather strong tendency the last few years of having steadily
less functionality in the base system - and I'm not at all convinced
that the right balance has been found here.
I think this is the core problem at the root of many discussions
besides this one. What is the base system?
FreeBSD users tend to agree that we like a self-contained wad of stuff
called The Base System but disagree quite strongly about what should
be in it. There are several approaches to the problem, ranging from
concrete and specific (exactly what shipped with 4.4BSD, a.k.a.
Originalism) to principled but open to interpretation (what 4.4BSD
would ship if it were released today, a.k.a. Founders' Intent).
We will never all agree on exactly what should be in base vs
ports/packages, but can we perhaps build consensus around principles?
When you first take it out of the box, does The Base System need to be:
- self-bootstrapping
- POSIX-compliant
- administerable
- with local shell
- with local tools (e.g. RCS, vim, git...)
- with remote shell (SSH)
- with remote tools (e.g. Puppet)
- with enterprise integration (e.g. Kerberos, LDAP, 802.1x, SMB...)
- useful for end-user workloads:
- [cross-]building FreeBSD
- [cross-]building {program X in language Y}
- file server
- DNS server
- Kerberos server
- SVN server
- Postgres server
- Web server
- Hadoop node
- X server
- desktop
- able to install packages / build ports to do the above
- able to run Linux binaries
?
I think we all agree with the first two items, but where should we
draw the line?
Suppose we distributed install media with The Base System + some
packages tailored to a particular environment; would that change what
needs to be in The Base System? If FreeBSD Enterprise Edition or
FreeBSD Hacker Edition shipped with The Base System plus whatever
packages you need for that environment/workload, and if the installer
knew how to install those packages, could The Base System itself be
smaller, e.g. just what we need to bootstrap FreeBSD itself?
Jon
--
Jonathan Anderson
jonat...@freebsd.org
http://freebsd.org/~jonathan/
___
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: rcs
On 8 October 2013 16:04, sth...@nethelp.no wrote:
- For some of us, the attraction of FreeBSD is that it is a tightly
integrated system, and the base contains enough useful functionality
that we don't *have* to add a lot of packages.
- Each package that is moved out of the base system means less useful
functionality in the base system - and for me: Less reason to use
FreeBSD instead of Linux.
I absolutely see the problem of maintaining out-of-date packages in
the base system, and the desirability of making the base system less
reliant on GPL. I'm mostly troubled by the fact that there seems to
be a rather strong tendency the last few years of having steadily
less functionality in the base system - and I'm not at all convinced
that the right balance has been found here.
I think this is the core problem at the root of many discussions
besides this one. What is the base system?
FreeBSD users tend to agree that we like a self-contained wad of stuff
called The Base System but disagree quite strongly about what should
be in it. There are several approaches to the problem, ranging from
concrete and specific (exactly what shipped with 4.4BSD, a.k.a.
Originalism) to principled but open to interpretation (what 4.4BSD
would ship if it were released today, a.k.a. Founders' Intent).
We will never all agree on exactly what should be in base vs
ports/packages, but can we perhaps build consensus around principles?
When you first take it out of the box, does The Base System need to be:
- self-bootstrapping
- POSIX-compliant
- administerable
- with local shell
- with local tools (e.g. RCS, vim, git...)
- with remote shell (SSH)
- with remote tools (e.g. Puppet)
- with enterprise integration (e.g. Kerberos, LDAP, 802.1x, SMB...)
- useful for end-user workloads:
- [cross-]building FreeBSD
- [cross-]building {program X in language Y}
- file server
- DNS server
- Kerberos server
- SVN server
- Postgres server
- Web server
- Hadoop node
- X server
- desktop
- able to install packages / build ports to do the above
- able to run Linux binaries
?
I think we all agree with the first two items, but where should we
draw the line?
Suppose we distributed install media with The Base System + some
packages tailored to a particular environment; would that change what
needs to be in The Base System? If FreeBSD Enterprise Edition or
FreeBSD Hacker Edition shipped with The Base System plus whatever
packages you need for that environment/workload, and if the installer
knew how to install those packages, could The Base System itself be
smaller, e.g. just what we need to bootstrap FreeBSD itself?
Jon
--
Jonathan Anderson
jonat...@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: rcs
On 10/8/13 8:59 AM, Jonathan Anderson wrote:
On 8 October 2013 16:04, sth...@nethelp.no wrote:
- For some of us, the attraction of FreeBSD is that it is a tightly
integrated system, and the base contains enough useful functionality
that we don't *have* to add a lot of packages.
- Each package that is moved out of the base system means less useful
functionality in the base system - and for me: Less reason to use
FreeBSD instead of Linux.
I absolutely see the problem of maintaining out-of-date packages in
the base system, and the desirability of making the base system less
reliant on GPL. I'm mostly troubled by the fact that there seems to
be a rather strong tendency the last few years of having steadily
less functionality in the base system - and I'm not at all convinced
that the right balance has been found here.
I think this is the core problem at the root of many discussions
besides this one. What is the base system?
FreeBSD users tend to agree that we like a self-contained wad of stuff
called The Base System but disagree quite strongly about what should
be in it. There are several approaches to the problem, ranging from
concrete and specific (exactly what shipped with 4.4BSD, a.k.a.
Originalism) to principled but open to interpretation (what 4.4BSD
would ship if it were released today, a.k.a. Founders' Intent).
We will never all agree on exactly what should be in base vs
ports/packages, but can we perhaps build consensus around principles?
When you first take it out of the box, does The Base System need to be:
- self-bootstrapping
- POSIX-compliant
- administerable
- with local shell
- with local tools (e.g. RCS, vim, git...)
- with remote shell (SSH)
- with remote tools (e.g. Puppet)
- with enterprise integration (e.g. Kerberos, LDAP, 802.1x, SMB...)
- useful for end-user workloads:
- [cross-]building FreeBSD
- [cross-]building {program X in language Y}
- file server
- DNS server
- Kerberos server
- SVN server
- Postgres server
- Web server
- Hadoop node
- X server
- desktop
- able to install packages / build ports to do the above
- able to run Linux binaries
?
I think we all agree with the first two items, but where should we
draw the line?
Suppose we distributed install media with The Base System + some
packages tailored to a particular environment; would that change what
needs to be in The Base System? If FreeBSD Enterprise Edition or
FreeBSD Hacker Edition shipped with The Base System plus whatever
packages you need for that environment/workload, and if the installer
knew how to install those packages, could The Base System itself be
smaller, e.g. just what we need to bootstrap FreeBSD itself?
Jon,
You're right on the money, to be honest this is one of the reasons why
I've switched to using OSX as my desktop OS.
zsh, vim, screen by default. and upgrades work. At the end of the day
I'm spending time doing work, not mucking about my workspace to make it
usable for development.
I think this was brought up at BSDCan in the discussion about making
FreeBSD a more featured development platform.
Speaking of... has anyone tried PCBSD?
--
Alfred Perlstein
___
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
Customising FreeBSD - Was Re: rcs
[ My sympathies lean toward those who want to retain RCS, but as I dont personaly use it, that's all on that. ] ... screen, zsh, vim-lite, git why is that so manual for me? Why can't I just register a package set somewhere so that all I have to type in is alfred.perlstein.devel into a box during the installer and I get all my packages by default? In 1993 I was tired of manually customising generic FreeBSD to what I needed, so I wrote still use http://berklix.com/~jhs/bin/.csh/customise After cd /usr/src;make install I run customise to apply all my outstanding src/ ports/ patches ports preferences etc from my public tree. http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/ run src install again then variations of cd /usr/ports ; make BERKLIX_MINIMAL=YES BERKLIX_CLIENT=YES make BERKLIX_SERVER=YES BERKLIX_GATE=YES BERKLIX_AMBITIOUS=YES install I'm doing it on Alpha4 now. (Yup I know 5 is out, but ports/ takes days to build). Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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
problem to build world
Hi all. r256148 buildworld gives this error: === secure/usr.bin/ssh (all) cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/ssh.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/readconf.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/clientloop.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/sshtty.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/sshconnect.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/sshconnect1.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/sshconnect2.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -include krb5_config.h -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/roaming_common.c cc -O2 -pipe -march=athlon64-sse3 -mtune=athlon64-sse3 -I/usr/src/secure/usr.bin/ssh/../../../crypto/openssh -include ssh_namespace.h
Re: unionfs related panic on 10.0-ALPHA4
For information: It's possible to reproduce this problem using the indication given in kern/121385 (5 years old PR). Regards, Olivier ___ 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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
Hi Alfred cc current. Alfred Perlstein wrote: On 10/6/13 8:21 AM, Julian H. Stacey wrote: I wrote Thu, 03 Oct 2013 23:28:43 +0200 Rui Paulo wrote: On 2 Oct 2013, at 16:57, Julian H. Stacey j...@berklix.com wrote: Hi current@, It seems I need if_urtwn driver for a really miniature WLAN USB stick, if_urtwn is only in current ? man 4 if_urtwn refers to ports/net/urtwn-firmware-kmod which is missing ? This driver was never merged to FreeBSD 9. OK, Thanks for confirmation. Can you use FreeBSD 10 instead? Yes, easier than building from 9.X I guess ( helps test alpha :-). I'll fetch from local mirror, per http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044951.html The port reference in the man page is wrong. The firmware is now shipped as part of the base system. Oh nice, easier :-) I'm happy to report with 10.0-ALPHA4 /boot/loader.conf if_urtwn_load=YES `ifconfig wlan0 scan` works OK. Thanks :-) Cheers, Julian Cool! I have a g4 tibook 12in with an if_bwn that doesn't really work at all. I got one of these (if_urtwn) and it works enough to download about a meg or so before the watchdog kicks in and I have to ifconfig down/up it to get it to respond again. I even have a patch pending to add the usb identifier for this. Is there someone I can provide debug information for to help resolve this? I too am seeing urtwn0: timeout waiting for checksum report sometimes I can scan sometimes not, (whereas with a run0: stick I have no problem) I've not got as far as trying to move data. I'd appreciate any patches you have Alfred Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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: rcs
On Tue, Oct 8, 2013 at 7:09 AM, Alfred Perlstein bri...@mu.org wrote: On 10/7/13 9:49 PM, Julian Elischer wrote: On 10/8/13 11:19 AM, Lyndon Nerenberg wrote: On 2013-10-07, at 8:15 PM, Steve Kargl s...@troutmask.apl.washington.** edu s...@troutmask.apl.washington.edu wrote: Maybe there was no development for 15 years. However, the 7364 lines in ChangeLog after 2010-02-04 suggests that there may be few bugs to worry about. I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. So again, is there a way to make it so adding RCS after install is not a big deal at all? I haven't kept up-to-date with all the developments, but isn't this part of the bsdinstall/pkgng plan? Once the pkgng repos are all available and populated, then bsdinstall will be able to install packages from there during the install. And, isn't that part of the plan for the DVD installers, to include an installer repo for off-line installs? IOW, theoretically, one could just download the 10.0 DVD, boot, install the base, browse the repo on the DVD, select items to install, install, reboot, and be finished. Without ever needing to touch an Internet connection until after rebooting into FreeBSD, if it's even needed at all. Or was that one of the pie-in-the-sky ideas that hasn't materialised yet? -- Freddie Cash fjwc...@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
Re: rcs
On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein bri...@mu.org wrote: You're right on the money, to be honest this is one of the reasons why I've switched to using OSX as my desktop OS. zsh, vim, screen by default. and upgrades work. At the end of the day I'm spending time doing work, not mucking about my workspace to make it usable for development. I think this was brought up at BSDCan in the discussion about making FreeBSD a more featured development platform. Speaking of... has anyone tried PCBSD? PC-BSD isn't much different from FreeBSD. The installer is GUI and support ZFS, there are some GUI setup tools on first boot for X, there are some GUI tools to select binary drivers for X, and there are working pkgng repos available. I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do things the FreeBSD way which broke a lot of things that were done the PC-BSD way (aka don't manually edit config files used for booting). Switching to the rolling-release (aka PC-BSD 9-STABLE) and moving all my config file edits into filename.conf.local fixed my issues. Things have been running smooth, and I finally understand the beauty and simplicity of freebsd-update + pkg. OS gets updated once per month, packages get updated twice per month, no more compiling things from source. It's like using Ubuntu/Debian but with the power and features of FreeBSD. :) -- Freddie Cash fjwc...@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
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
I too am seeing urtwn0: timeout waiting for checksum report urtwn0: at uhub3, port 3, addr 4 (disconnected) (BTW there's no external hub, uhub3 must be inside laptop, there's no loose connection, laptop was not touched, all work was remote) PS a typical sample comparison of scanned signal strengths of one of the ~15 nets localy: 54M -49:-86 100 EP RSN WPA WMErun0 big stick, 54M -69:-95 100 EP RSN WPA WMEurtwn0 nano edimax EW-7811Un so the edimax is typically down about 20 on left column on all ~15 local nets. The aerial must be a minute fraction of the wavelength. I suppose wavelengths are is approx: 3 x 10^8 metre/second / 2.4 GHz = 3/2.4 x 10^(8-9) m = 12.5 cm ~6cm for 5GHz band. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
Hi, Note the noise floor differences.. wonder why that is. Rui ported the uwrtn stuff, right? He may be able to help. The driver is recent and its likely there are bugs to shake out. -adrian On Oct 8, 2013 2:49 PM, Julian H. Stacey j...@berklix.com wrote: I too am seeing urtwn0: timeout waiting for checksum report urtwn0: at uhub3, port 3, addr 4 (disconnected) (BTW there's no external hub, uhub3 must be inside laptop, there's no loose connection, laptop was not touched, all work was remote) PS a typical sample comparison of scanned signal strengths of one of the ~15 nets localy: 54M -49:-86 100 EP RSN WPA WMErun0 big stick, 54M -69:-95 100 EP RSN WPA WMEurtwn0 nano edimax EW-7811Un so the edimax is typically down about 20 on left column on all ~15 local nets. The aerial must be a minute fraction of the wavelength. I suppose wavelengths are is approx: 3 x 10^8 metre/second / 2.4 GHz = 3/2.4 x 10^(8-9) m = 12.5 cm ~6cm for 5GHz band. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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: rcs
I think that's great. But, as we are increasingly finding, theres no stable ports snapshot, so unless we as a project change how packages are managed, there may not really be a stable, predictable version of things once they're moved from base to a package. A number of users and companies like that there is a very strict definition of base and that it wont change as the ports tree changes. Eg, you install 10.0 and get the rcs package from that. You then do an install of 10.0 a yeat later and install rcs. If it comes from the 10-stable pkgng set, itll pick up the latest version, not the 10.0 version. Thats the big ports vs base difference. -adrian On Oct 8, 2013 11:20 AM, Alfred Perlstein bri...@mu.org wrote: On 10/8/13 8:04 AM, sth...@nethelp.no wrote: I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. Not commenting on RCS here, but on the concept of moving packages out of the base: - For some of us, the attraction of FreeBSD is that it is a tightly integrated system, and the base contains enough useful functionality that we don't *have* to add a lot of packages. - Each package that is moved out of the base system means less useful functionality in the base system - and for me: Less reason to use FreeBSD instead of Linux. I absolutely see the problem of maintaining out-of-date packages in the base system, and the desirability of making the base system less reliant on GPL. I'm mostly troubled by the fact that there seems to be a rather strong tendency the last few years of having steadily less functionality in the base system - and I'm not at all convinced that the right balance has been found here. This discussion is not new, and I don't expect to convince any new persons... I'm sure other devs will disagree, but with ~15 years of FreeBSD experience and ~13 years as a dev, my very strong opinion is that this tightly coupled system is actually a boat anchor sinking us. Just because no one else does it a certain way, does not mean that a unique way of doing something is correct and/or sustainable. Maybe in 1995, 1999, or 2005 even, but not today. Especially in the context of add-on tools like rcs. What we need to discuss is lowering the bar to making custom installs. I personally find that installing FreeBSD is useless until I install screen, zsh, vim-lite, git why is that so manual for me? Why can't I just register a package set somewhere so that all I have to type in is alfred.perlstein.devel into a box during the installer and I get all my packages by default? -- Alfred Perlstein __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org 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: Virtual box require LIBCXX
Em Tue, 08 Oct 2013 09:43:19 -0700, Eric L. Camachat escreveu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2013 07:17, Nilton Jose Rizzo wrote: root@valfenda:/usr/ports/emulators/virtualbox-ose # kldload vboxdrv root@valfenda:/usr/ports/emulators/virtualbox-ose # but whern I run it, the I got this error message: rizzo@valfenda:~/src/Doutorado/visao/testes % VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found My box can be fixed by remove misc/compat8x package. In my box it was used by bootstrap jdk, look root@valfenda:/usr # pkg query %ro compat8x-amd64 java/bootstrap-openjdk root@valfenda:/usr # You don't use java? Eric -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlJUNicACgkQSfBQu3oOwYxoRwEAgcXGhnbrW6ARTsoOblA7urrc o/7zf5O+MekTczEWn/YA/23CjxEj22cYcd3A6tHWGa4cBcju5fmL8YWGXv5Yonrc =xk3B -END PGP SIGNATURE- ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. 4. What is this gnop stuff for? 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). -Nathan ___ 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: rcs
oops, sent from my non-subscribed email.. On 10/8/13 11:17 AM, Freddie Cash wrote: On Tue, Oct 8, 2013 at 7:09 AM, Alfred Perlstein bri...@mu.org mailto:bri...@mu.orgwrote: On 10/7/13 9:49 PM, Julian Elischer wrote: On 10/8/13 11:19 AM, Lyndon Nerenberg wrote: On 2013-10-07, at 8:15 PM, Steve Kargl s...@troutmask.apl.washington.edu mailto:s...@troutmask.apl.washington.edu wrote: Maybe there was no development for 15 years. However, the 7364 lines in ChangeLog after 2010-02-04 suggests that there may be few bugs to worry about. I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. So again, is there a way to make it so adding RCS after install is not a big deal at all? I haven't kept up-to-date with all the developments, but isn't this part of the bsdinstall/pkgng plan? Once the pkgng repos are all available and populated, then bsdinstall will be able to install packages from there during the install. And, isn't that part of the plan for the DVD installers, to include an installer repo for off-line installs? IOW, theoretically, one could just download the 10.0 DVD, boot, install the base, browse the repo on the DVD, select items to install, install, reboot, and be finished. Without ever needing to touch an Internet connection until after rebooting into FreeBSD, if it's even needed at all. Or was that one of the pie-in-the-sky ideas that hasn't materialised yet? I thought sysinstall could do this 13 years ago? -Alfred ___ 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] RCS removed from base
In message 52538562.6030...@freebsd.org, Julian Elischer writes: On 10/8/13 10:03 AM, Steve Rikli wrote: On Mon, Oct 07, 2013 at 06:32:21PM -0700, Alfred Perlstein wrote: On 10/7/13 6:30 PM, Steve Kargl wrote: ... PS: As noted, the code is GPL. There has been an effort to remove GPL code from FreeBSD (whether prudent or not). That plus the age of the code is good enough reason to ditch it! huzzah! Plus we can make RCSBSD along with it. Is such a project underway? I.e. an RCS of some kind from FreeBSD? OpenBSD went through this a while ago and use OpenRCS -- is that even remotely appropriate for use in FreeBSD? From reading most of both thread(s), it seems there's at least some interest in keeping an RCS in base; whether it's the status quo RCS (w/GPL) doesn't seem to be strictly required, as long as whichever RCS is available in base is (mostly?) compatible with status quo RCS. the prudent path is to put the original back before 10 and arange to replace it by 11 I'm officially asking core to allow this to stop what I consider a bad POLA problem. it can not be said that there was no pushback against this change. and it was sprung on us with no real warning. Probably a good idea. Though I've put a rcs57 port in place, ports need to be updated and probably a little more warning would have been nice. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
On 10/8/13 10:41 AM, Julian H. Stacey wrote: Hi Alfred cc current. Alfred Perlstein wrote: On 10/6/13 8:21 AM, Julian H. Stacey wrote: I wrote Thu, 03 Oct 2013 23:28:43 +0200 Rui Paulo wrote: On 2 Oct 2013, at 16:57, Julian H. Stacey j...@berklix.com wrote: Hi current@, It seems I need if_urtwn driver for a really miniature WLAN USB stick, if_urtwn is only in current ? man 4 if_urtwn refers to ports/net/urtwn-firmware-kmod which is missing ? This driver was never merged to FreeBSD 9. OK, Thanks for confirmation. Can you use FreeBSD 10 instead? Yes, easier than building from 9.X I guess ( helps test alpha :-). I'll fetch from local mirror, per http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044951.html The port reference in the man page is wrong. The firmware is now shipped as part of the base system. Oh nice, easier :-) I'm happy to report with 10.0-ALPHA4 /boot/loader.conf if_urtwn_load=YES `ifconfig wlan0 scan` works OK. Thanks :-) Cheers, Julian Cool! I have a g4 tibook 12in with an if_bwn that doesn't really work at all. I got one of these (if_urtwn) and it works enough to download about a meg or so before the watchdog kicks in and I have to ifconfig down/up it to get it to respond again. I even have a patch pending to add the usb identifier for this. Is there someone I can provide debug information for to help resolve this? I too am seeing urtwn0: timeout waiting for checksum report sometimes I can scan sometimes not, (whereas with a run0: stick I have no problem) I've not got as far as trying to move data. I'd appreciate any patches you have Alfred Unfortunately all my time right now is being spent syncing changes to FreeNAS from our commercial product TrueNAS to improve both products. I tried to look at the code but my eyes quickly went cross and I had to get back to build stuff. -Alfred ___ 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] RCS removed from base
In message 52538d19.8000...@freebsd.org, Julian Elischer writes:
On 10/8/13 12:34 PM, Mehmet Erol Sanliturk wrote:
On Mon, Oct 7, 2013 at 9:49 PM, Julian Elischer jul...@freebsd.org
mailto:jul...@freebsd.org wrote:
On 10/8/13 9:33 AM, Steve Kargl wrote:
On Mon, Oct 07, 2013 at 08:41:38PM -0400, George Mitchell wrote:
On 10/07/13 20:28, John-Mark Gurney wrote:
Julian Elischer wrote this message on Tue, Oct 08,
2013 at 08:01 +0800:
not a big thing but I believe that a lot of
poeple use ci/co on /etc
becasue it is just there
+1
Folks, this is just plain a major violation of the
Principle of Least
Amazement. RCS is ideal for keeping track of my
configuration files
in /etc. What do we gain by removing it?
Less GPL code in FreeBSD?
not a problem unless you plan in shipping a changed version of
it on your product??
Most new versions of GPL licensed code are converted to Version 3 GPL .
This is blocking FreeBSD if they keep GPL licensed code in base ,
because commercial companies usingFreeBSD are not able to use
FreeBSD any more if the FreeBSD switches to Version 3 GPL .
This obstacle is in the base system GCC : It stayed in an older
version , and necessitated to switch to Clang/LLVM .
Difficulty of such a switch is apparenly known .
Therefore cleaning base from GPL licensed code is a vital
requirement for further progress WITH RESPECT TO FreeBSD Project
structure .
Thank you very much .
sure but lets keep the one one in the the tree untill there is a
replacement ready to commit. ro 10 will have NO RCS which is a POLA.
We do now have an rcs57 port which is the same as what was in base. The
port could be made to _optionally_ install into /usr instead of
${LOCALBASE}.
--
Cheers,
Cy Schubert cy.schub...@komquats.com
FreeBSD UNIX: c...@freebsd.org Web: http://www.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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Tue, Oct 8, 2013 at 1:17 PM, Nathan Whitehorn nwhiteh...@freebsd.orgwrote: 4. What is this gnop stuff for? Can't comment on the rest, but gnop is required to create 4K-aligned vdevs where the minimum block size is 4K (aka ashift=12). Without this, ZFS relies on the underlying disk driver providing the correct information, and most don't. Also, if you don't do this, and create a vdev using 512B sectors, the ashift will be set to 9, and replacing the drive down the line with 4K Advanced Format drive will drop your drive performance in the toilet. Thus, to future-proof your pool, you need to: - set the ashift of the pool to 12 (4 KB) - align the disk/partition on 4 KB boundaries (starting partition at 1 MB works well) Until our ZFS gains the ability to set a minimum ashift for the pool, or to set the ashift at vdev creation, or all drive manufacturers write perfect firmware, than we need to fake it with gnop. -- Freddie Cash fjwc...@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
Re: rcs
In message 525422b6.9040...@mu.org, Alfred Perlstein writes: On 10/8/13 8:04 AM, sth...@nethelp.no wrote: I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. Not commenting on RCS here, but on the concept of moving packages out of the base: - For some of us, the attraction of FreeBSD is that it is a tightly integrated system, and the base contains enough useful functionality that we don't *have* to add a lot of packages. - Each package that is moved out of the base system means less useful functionality in the base system - and for me: Less reason to use FreeBSD instead of Linux. I absolutely see the problem of maintaining out-of-date packages in the base system, and the desirability of making the base system less reliant on GPL. I'm mostly troubled by the fact that there seems to be a rather strong tendency the last few years of having steadily less functionality in the base system - and I'm not at all convinced that the right balance has been found here. This discussion is not new, and I don't expect to convince any new persons... I'm sure other devs will disagree, but with ~15 years of FreeBSD experience and ~13 years as a dev, my very strong opinion is that this tightly coupled system is actually a boat anchor sinking us. Just because no one else does it a certain way, does not mean that a unique way of doing something is correct and/or sustainable. Maybe in 1995, 1999, or 2005 even, but not today. Especially in the context of add-on tools like rcs. What we need to discuss is lowering the bar to making custom installs. I personally find that installing FreeBSD is useless until I install screen, zsh, vim-lite, git why is that so manual for me? Why can't I just register a package set somewhere so that all I have to type in is alfred.perlstein.devel into a box during the installer and I get all my packages by default? A Red Hat-like kickstart or Solaris jumpstart possibly? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: [Heads Up] RCS removed from base
In message 52542687.7000...@pix.net, Kurt Lidl writes: On 10/8/13, Julian Elischer wrote: On 10/7/13 11:06 PM, Steve Kargl wrote: On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote: Hey all, RCS was removed from the base system in r256095. If you still want to use RCS please install either devel/rcs or devel/rcs57. If not, be sure to check out the alternatives (pun stolen and intended). Perhaps, a note in src/UPDATING is appropriate? ok so what is this, the secret cabal to make FreeBSD useless? I'm ccing core as I believe this was not discussed enough in public (in fact not discussed AT ALL in any forum I am watching) and I officially request a backout of the removal of what I consider to be core functionality. My usual way of doing things is on install to ci EVERYTHING in /etc to get a snapsot right the way back to install. now I have to change things in /etc (and other places) BEFORE I can check them in. (i.e. get networking up and ports installed) not a big thing but I believe that a lot of poeple use ci/co on /etc becasue it is just there +1 for keeping a RCS in base. I too use to maintain a bunch of files in /etc - I have for years and years. I don't particularly want the GPL'd version - I'd be happiest with the OpenRCS version (BSD-licensed) from OpenBSD. I've started work on a port (not that this was my highest priority but received a private email that I may want to do this instead of rcs57). Would the majority here rather have it in base? Just finished schlepping the OpenBSD source to my laptop (the link to the OpenRCS site returns a TCP RST). I don't mind either way. It's the groups's and the Project's call. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: rcs
In message CAETOPp0imH3LCM2gwe1a_TJD+q5YoWhuJbR0YhHpux0qe8irtA@mail.gmail.c om , Jos Backus writes: On Oct 7, 2013 7:31 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: Okay folks, can we make a call about keeping the RCS tools in the base? The proponents wanting to remove RCS need to speak up and make their technical case. Perhaps slightly off-topic, but how about we move into the 21st century and import the 2-clause BSD-licensed Fossil? http://www.fossil-scm.org/ Not RCS, I know, but vastly more useful. Bikeshed alert. Let's not let this discussion go sideways. Seriously, it's not the same. To import something different doesn't replace what was removed. We have two options. Put it back, or something like it, e.g. OpenRCS, back, or put it in ports. Personally I don't think it matters where it lives as long as the same functionality is there. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: rcs
On 10/8/13 11:17 AM, Freddie Cash wrote: On Tue, Oct 8, 2013 at 7:09 AM, Alfred Perlstein bri...@mu.org mailto:bri...@mu.orgwrote: On 10/7/13 9:49 PM, Julian Elischer wrote: On 10/8/13 11:19 AM, Lyndon Nerenberg wrote: On 2013-10-07, at 8:15 PM, Steve Kargl s...@troutmask.apl.washington.edu mailto:s...@troutmask.apl.washington.edu wrote: Maybe there was no development for 15 years. However, the 7364 lines in ChangeLog after 2010-02-04 suggests that there may be few bugs to worry about. I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. So again, is there a way to make it so adding RCS after install is not a big deal at all? I haven't kept up-to-date with all the developments, but isn't this part of the bsdinstall/pkgng plan? Once the pkgng repos are all available and populated, then bsdinstall will be able to install packages from there during the install. And, isn't that part of the plan for the DVD installers, to include an installer repo for off-line installs? IOW, theoretically, one could just download the 10.0 DVD, boot, install the base, browse the repo on the DVD, select items to install, install, reboot, and be finished. Without ever needing to touch an Internet connection until after rebooting into FreeBSD, if it's even needed at all. Or was that one of the pie-in-the-sky ideas that hasn't materialised yet? Man, we used to be able to do that with sysinstall 10 years ago? Is that broken? -- Alfred Perlstein ___ 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: rcs
On Tue, 8 Oct 2013, Adrian Chadd wrote: I think that's great. But, as we are increasingly finding, theres no stable ports snapshot, so unless we as a project change how packages are managed, there may not really be a stable, predictable version of things once they're moved from base to a package. A number of users and companies like that there is a very strict definition of base and that it wont change as the ports tree changes. Eg, you install 10.0 and get the rcs package from that. You then do an install of 10.0 a yeat later and install rcs. If it comes from the 10-stable pkgng set, itll pick up the latest version, not the 10.0 version. Thats the big ports vs base difference. Perhaps a perl style dual life module set of core (errm BASE?) packages/ports will emerge. It could resolve some of the perennial what is BASE? debates - or at least make it possible to have those debates in a different way :-) My understanding is that dealing with the GPLv3 issue for BASE is *necessary* for the project. Since the latest rcs releases are licensed using GPLv3, FreeBSD's BASE rcs (GPLv2) would have to be maintained exclusively by the FreeBSD project - which means more developer overhead (the same could be said for gcc I suppose). That seems to be a different type of issue than the size/completeness of BASE itself. Since rcs is a small utility, it's hooked into a script or two via rc.subr, it's useful to a lot of folks, it doesn't face the network and there's a BSD licensed equivalent sort of available, then maybe the best way to go would be to import opencvs's rcs (which is not part in the ports version of opencvs) to replace the GNU version. ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 10/08/13 22:25, Freddie Cash wrote: On Tue, Oct 8, 2013 at 1:17 PM, Nathan Whitehorn nwhiteh...@freebsd.org mailto:nwhiteh...@freebsd.orgwrote: 4. What is this gnop stuff for? Can't comment on the rest, but gnop is required to create 4K-aligned vdevs where the minimum block size is 4K (aka ashift=12). Without this, ZFS relies on the underlying disk driver providing the correct information, and most don't. Also, if you don't do this, and create a vdev using 512B sectors, the ashift will be set to 9, and replacing the drive down the line with 4K Advanced Format drive will drop your drive performance in the toilet. Thus, to future-proof your pool, you need to: - set the ashift of the pool to 12 (4 KB) - align the disk/partition on 4 KB boundaries (starting partition at 1 MB works well) Until our ZFS gains the ability to set a minimum ashift for the pool, or to set the ashift at vdev creation, or all drive manufacturers write perfect firmware, than we need to fake it with gnop. Well, that's a disgusting hack, but I see why it's there. Thanks for the explanation! -Nathan ___ 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: rcs
Am 08.10.2013 um 22:29 schrieb Cy Schubert cy.schub...@komquats.com: A Red Hat-like kickstart or Solaris jumpstart possibly? http://blog.hostileadmin.com/2013/04/11/installing-freebsd-via-cobbler/ I wish it was using bsdinstall, though. ___ 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: rcs
I've iterated my views on these things a few times. I honestly am not all _that_ interested in trying to build a polished OS. I'd rather participate in building an OS toolkit that let's PCBSD, pfsense, that storage appliance I keep forgetting the name of (heh), etc all build OSes on top of it. I'm hoping that some group will take FreeBSD-nowish as 10.x and later evolves, combines it with pkgng and some package development policies, and rolls OSes that people actually want to use and deploy. I don't mind if that's called pc-bsd. I'd be running pcbsd right now if it were doing drops against -head. I believe this may be happening soon. Just saying.. :-) -adrian ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Oct 8, 2013, at 1:17 PM, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. I think we can do that no problem. 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. *nods* we'll have to purloin your VTOC8 code before we offer it to sparc64. 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. I imagine we could get the info from many places, and to be honest, I never knew about diskinfo until last week (but apparently it's been around since 5.x days). The one place where I suspect camcontrol(8) usage is appropriate is the mini disk inspector dialog. The camcontrol inquiry output is specifically helpful if/when you're doing multipathing (and you need to identify which da# devices are duplicates of the same device -- given Serial#). But I gather you mean for disk description in the device menu (for picking text to go along with the device name). I'm open to using a different tool... or multiple tools. Do you think it would be better to just stick to one tool? or to query a few? (which ones win-out?) 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. Yes and yes. (and didn't know the editor was designed for ZFS too) 4. What is this gnop stuff for? Thanks goes to Freddie Cash for his excellent explanation (I had to admit, I didn't understand it at that level) 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). Will not some combination of gpart destroy -F and (insert suggestion) work? -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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] RCS removed from base
On Tue, 8 Oct 2013, Cy Schubert wrote: I've started work on a port (not that this was my highest priority but received a private email that I may want to do this instead of rcs57). Would the majority here rather have it in base? Just finished schlepping the OpenBSD source to my laptop (the link to the OpenRCS site returns a TCP RST). I don't mind either way. It's the groups's and the Project's call. It seems to have ben taken out without much discussion, and we're in the process of releasing 10.0, so I'd say put it back in base. After 10.0 goes out (or is branched), then we can have a proper discussion about how to remove it and what, if any, to replace it with. -- DE ___ 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: rcs
On Oct 8, 2013 1:37 PM, Cy Schubert cy.schub...@komquats.com wrote: In message CAETOPp0imH3LCM2gwe1a_TJD+q5YoWhuJbR0YhHpux0qe8irtA@mail.gmail.c om , Jos Backus writes: On Oct 7, 2013 7:31 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: Okay folks, can we make a call about keeping the RCS tools in the base? The proponents wanting to remove RCS need to speak up and make their technical case. Perhaps slightly off-topic, but how about we move into the 21st century and import the 2-clause BSD-licensed Fossil? http://www.fossil-scm.org/ Not RCS, I know, but vastly more useful. Bikeshed alert. Let's not let this discussion go sideways. Seriously, it's not the same. To import something different doesn't replace what was removed. We have two options. Put it back, or something like it, e.g. OpenRCS, back, or put it in ports. Personally I don't think it matters where it lives as long as the same functionality is there. Part of the argument seems to be about improving out of the box functionality and experience. Fossil would help there. But I agree, change is hard, and it has a cost for sure. Sorry for the distraction. Jos ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 10/08/13 22:50, Teske, Devin wrote: On Oct 8, 2013, at 1:17 PM, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. I think we can do that no problem. 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. *nods* we'll have to purloin your VTOC8 code before we offer it to sparc64. 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. I imagine we could get the info from many places, and to be honest, I never knew about diskinfo until last week (but apparently it's been around since 5.x days). The one place where I suspect camcontrol(8) usage is appropriate is the mini disk inspector dialog. The camcontrol inquiry output is specifically helpful if/when you're doing multipathing (and you need to identify which da# devices are duplicates of the same device -- given Serial#). But I gather you mean for disk description in the device menu (for picking text to go along with the device name). I'm open to using a different tool... or multiple tools. Do you think it would be better to just stick to one tool? or to query a few? (which ones win-out?) Absolutely all information you could possibly want is inside GEOM, including disk serial numbers. It the Correct Place (tm) for whatever information you want to get. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. Yes and yes. (and didn't know the editor was designed for ZFS too) Great! 4. What is this gnop stuff for? Thanks goes to Freddie Cash for his excellent explanation (I had to admit, I didn't understand it at that level) 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). Will not some combination of gpart destroy -F and (insert suggestion) work? Yes, that will work just fine. -Nathan ___ 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] RCS removed from base
On 10/8/13 4:33 PM, Cy Schubert wrote:
In message 52542687.7000...@pix.net, Kurt Lidl writes:
On 10/8/13, Julian Elischer wrote:
On 10/7/13 11:06 PM, Steve Kargl wrote:
On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote:
Hey all,
RCS was removed from the base system in r256095. If you still want to
use RCS please install either devel/rcs or devel/rcs57. If not, be
sure to check out the alternatives (pun stolen and intended).
Perhaps, a note in src/UPDATING is appropriate?
ok so what is this, the secret cabal to make FreeBSD useless?
I'm ccing core as I believe this was not discussed enough in public
(in fact not discussed AT ALL in any forum I am watching)
and I officially request a backout of the removal of what I consider
to be core functionality.
My usual way of doing things is on install to ci EVERYTHING in /etc
to get a snapsot right the way back to install.
now I have to change things in /etc (and other places) BEFORE I can
check them in.
(i.e. get networking up and ports installed)
not a big thing but I believe that a lot of poeple use ci/co on /etc
becasue it is just there
+1 for keeping a RCS in base. I too use to maintain a bunch of
files in /etc - I have for years and years. I don't particularly
want the GPL'd version - I'd be happiest with the OpenRCS version
(BSD-licensed) from OpenBSD.
I've started work on a port (not that this was my highest priority but
received a private email that I may want to do this instead of rcs57).
Would the majority here rather have it in base? Just finished schlepping
the OpenBSD source to my laptop (the link to the OpenRCS site returns a TCP
RST). I don't mind either way. It's the groups's and the Project's call.
I did the same thing this afternoon. I grabbed the latest rcs sources
from the OpenBSD CVS server, and did a quick and dirty port to
FreeBSD. There are some minor formatting diffs in the output of
'rlog', for example.
Diff should be attached (well, stripped from the mailing list, but still
available through the web interface to the mailing list).
-Kurt
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -12,9 +12,9 @@ LINKS=${BINDIR}/rcs ${BINDIR}/ci ${BIND
${BINDIR}/rcs ${BINDIR}/rcsclean ${BINDIR}/rcs ${BINDIR}/rcsdiff \
${BINDIR}/rcs ${BINDIR}/rcsmerge ${BINDIR}/rcs ${BINDIR}/rlog
CPPFLAGS+=-I${.CURDIR}
-CFLAGS+=-Wall
+CFLAGS+=-Wall -I${.CURDIR}
CFLAGS+=-Wstrict-prototypes -Wmissing-prototypes
CFLAGS+=-Wmissing-declarations
CFLAGS+=-Wshadow -Wpointer-arith -Wcast-qual
CFLAGS+=-Wsign-compare
diff --git a/ci.c b/ci.c
--- a/ci.c
+++ b/ci.c
@@ -909,9 +909,9 @@ checkin_keywordscan(BUF *data, RCSNUM **
buf_append(buf, start, len);
/* XXX - Not binary safe. */
buf_putc(buf, '\0');
- checkin_parsekeyword(buf_get(buf), rev, date, author, state);
+ checkin_parsekeyword((char *)buf_get(buf), rev, date, author,
state);
buf_free(buf);
loopend:;
}
if (kwstr == NULL)
diff --git a/date.y b/date.y
--- a/date.y
+++ b/date.y
@@ -13,9 +13,9 @@
*/
/* SUPPRESS 287 on yaccpar_sccsid *//* Unused static variable */
/* SUPPRESS 288 on yyerrlab *//* Label unused */
-#include sys/timeb.h
+/* #include sys/timeb.h */
#include ctype.h
#include err.h
#include string.h
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -426,10 +426,10 @@ files_differ(FILE *f1, FILE *f2)
static void
prepare(int i, FILE *fd, off_t filesize, int flags)
{
struct line *p;
- int j, h;
- size_t sz;
+ int h;
+ size_t j, sz;
rewind(fd);
sz = (filesize = SIZE_MAX ? filesize : SIZE_MAX) / 25;
@@ -1141,9 +1141,9 @@ asciifile(FILE *f)
cnt = fread(buf, 1, sizeof(buf), f);
return (memchr(buf, '\0', cnt) == NULL);
}
-#define begins_with(s, pre) (strncmp(s, pre, sizeof(pre)-1) == 0)
+#define begins_with(s, pre) (strncmp((const char *)s, pre, sizeof(pre)-1) == 0)
static char *
match_function(const long *f, int pos, FILE *fp)
{
@@ -1160,9 +1160,9 @@ match_function(const long *f, int pos, F
nc = sizeof(buf) - 1;
nc = fread(buf, 1, nc, fp);
if (nc 0) {
buf[nc] = '\0';
- buf[strcspn(buf, \n)] = '\0';
+ buf[strcspn((const char *)buf, \n)] = '\0';
if (isalpha(buf[0]) || buf[0] == '_' || buf[0] == '$') {
if (begins_with(buf, private:)) {
if (!state)
state = (private);
@@ -1172,9 +1172,9 @@ match_function(const long *f, int pos, F
} else if (begins_with(buf, public:)) {
if (!state)
state = (public);
} else {
-
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). Will not some combination of gpart destroy -F and (insert suggestion) work? Yes, that will work just fine. Actually, it will appear to work, and then viciously hurt (substitute more graphic verb for hurt) you later, if you happen to repartition, and are using a geom-mirror for your swap space. At least if you manage to get your old geom and new geom on the same physical location of the disk. To be safe, you really need to either zero out the space used by geom before destroying the gpart label when it isn't in use, or run: gmirror deactivate NAME provider1 gmirror deactivate NAME provider2 -Kurt ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 10/8/2013, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. 4. What is this gnop stuff for? 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). -Nathan I wrote some support for adding ZFS to the partition editor a couple of months ago, around the time that 9.2 was branched. One of the biggest things that I have not done is integrate setting up a zfs mirror between any disks before creating the zpool. Nor did I do the gnop hack to create 4K disk blocks before creating the pool. I more or less changed the partedit program to take an argument when invoked with ufs (same as current behavior) or zfs, which knows about zfs setup stuff. The hookup to the actual scripts was, shall we say, much less intrusive than what has been published here. I guess it's time to dig out the patches and make them available to others. -Kurt ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
Devin Teske wrote this message on Tue, Oct 08, 2013 at 20:50 +: 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. I imagine we could get the info from many places, and to be honest, I never knew about diskinfo until last week (but apparently it's been around since 5.x days). The one place where I suspect camcontrol(8) usage is appropriate is the mini disk inspector dialog. The camcontrol inquiry output is specifically helpful if/when you're doing multipathing (and you need to identify which da# devices are duplicates of the same device -- given Serial#). But I gather you mean for disk description in the device menu (for picking text to go along with the device name). I'm open to using a different tool... or multiple tools. Do you think it would be better to just stick to one tool? or to query a few? (which ones win-out?) diskinfo -v dumps the serial number for you under disk ident.. diskinfo gets it from geom and most geoms properly present that info now... or at least probably anyones support by cam will do it automatically... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: test
/div/td/tr/tbody/table/td/tr/tbody/table/divdiv class=utdU2e/divdiv class=tx78Ic/divdiv class=aHl/divdiv id=:2il tabindex=-1/divdiv id=:2i7 class=ii gt m1419842a752abb3c adP adOdiv id=:2i6 style=overflow: hidden;testbr__ On Tue, Oct 8, 2013 at 9:29 AM, Alexander Panyushkin vsi...@gmail.comwrote: test __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 10/08/13 23:21, Kurt Lidl wrote: On 10/8/2013, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. 4. What is this gnop stuff for? 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). -Nathan I wrote some support for adding ZFS to the partition editor a couple of months ago, around the time that 9.2 was branched. One of the biggest things that I have not done is integrate setting up a zfs mirror between any disks before creating the zpool. Nor did I do the gnop hack to create 4K disk blocks before creating the pool. I more or less changed the partedit program to take an argument when invoked with ufs (same as current behavior) or zfs, which knows about zfs setup stuff. The hookup to the actual scripts was, shall we say, much less intrusive than what has been published here. I guess it's time to dig out the patches and make them available to others. That would be great! The original idea was to have a zfs_ops.c to go with gpart_ops.c and have some fields in the disk item struct that said which to use. Not sure if that's ultimately workable, though. I can hack on it once the patches are there in any case. -Nathan ___ 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: Running i386 CURRENT on an AMD64 platform:: CLang related
Which has the latest source? On Tue, Oct 8, 2013 at 4:11 AM, Boris Samorodov b...@passap.ru wrote: 08.10.2013 11:55, Boris Samorodov пишет: 08.10.2013 11:45, Joe Nosay пишет: I've ran into compiling problems with some ports. World and kernel have not yet been rebuilt. 10.x is a pre-APLHA release. Please, show diagnostic messages (of failing ports). OK, I've seen you have posted them to freebsd-ports@. Before I attempt to rebuild any of the system, has anyone else had any problems related to building i386 on AMD64? Anyway, I'd say that it's a good idea to update your system since there were many changes you may be interested in. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: rcs
Hello, Daniel. You wrote 8 октября 2013 г., 19:40:23: DN If they get the package repositories back up - which I assume will DN happen before any official releases from 10 - it should just be pkg DN install rcs. As challenges go, that doesn't seem too bad? Topic starter mentioned, that assumption that everybody has online connection is completely wrong! As far as I understand, it was his main objection -- they have a lot of offline computers at work (something related to Security Theatre by DHS, but who am I to judge them?). And you again says about pkg install rcs which needs internet connection! -- // Black Lion AKA Lev Serebryakov l...@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: Unable to installworld after successful buildworld and buildkernel
On Tue, Oct 08, 2013 at 09:38:14PM +, Thomas Mueller wrote: To cross install FreeBSD on a system without the required users/groups you must either install them on the base system so that install and mtree can use them or use the -DDB_FROM_SRC option when running the installworld/installkernel/distribution targets. -- Brooks That worked for installworld, was apparently not needed subsequently for installkernel. But where is DB_FROM_SRC documented? I never saw it anywhere. UPDATING file needs to be updated for installing FreeBSD on a partition where there is no OS installed. It's documented in Makefile.inc1 where the less commonly used options are documented. It should be documented in the Handbook along with the process of cross installation and image creation. I disagree that UPDATING should document the process of installing to other locations. That would be a distraction from it's purpose of letting users update their systems. It's already far too complicated. -- Brooks pgp_Q0qEjHcsz.pgp Description: PGP signature
Re: Unable to installworld after successful buildworld and buildkernel
To cross install FreeBSD on a system without the required users/groups you must either install them on the base system so that install and mtree can use them or use the -DDB_FROM_SRC option when running the installworld/installkernel/distribution targets. -- Brooks That worked for installworld, was apparently not needed subsequently for installkernel. But where is DB_FROM_SRC documented? I never saw it anywhere. UPDATING file needs to be updated for installing FreeBSD on a partition where there is no OS installed. I haven't booted yet, will try several ways including grub2, and not including grub2. I installed sysutils/grub2 from FreeBSD ports, also sysutils/xorriso, necessary to run mkrescue. Tom ___ 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: test
What were you testing? On Tue, Oct 8, 2013 at 5:25 PM, Joe Nosay superbisq...@gmail.com wrote: /div/td/tr/tbody/table/td/tr/tbody/table/divdiv class=utdU2e/divdiv class=tx78Ic/divdiv class=aHl/divdiv id=:2il tabindex=-1/divdiv id=:2i7 class=ii gt m1419842a752abb3c adP adOdiv id=:2i6 style=overflow: hidden;testbr__ On Tue, Oct 8, 2013 at 9:29 AM, Alexander Panyushkin vsi...@gmail.comwrote: test __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org 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: Virtual box require LIBCXX
On Tue, Oct 08, 2013 at 05:01:35PM -0300, Nilton Jose Rizzo wrote: Em Tue, 08 Oct 2013 09:43:19 -0700, Eric L. Camachat escreveu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2013 07:17, Nilton Jose Rizzo wrote: root@valfenda:/usr/ports/emulators/virtualbox-ose # kldload vboxdrv root@valfenda:/usr/ports/emulators/virtualbox-ose # but whern I run it, the I got this error message: rizzo@valfenda:~/src/Doutorado/visao/testes % VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found My box can be fixed by remove misc/compat8x package. In my box it was used by bootstrap jdk, look root@valfenda:/usr # pkg query %ro compat8x-amd64 java/bootstrap-openjdk root@valfenda:/usr # You don't use java? bootstrap-openjdk is only needed to BUILD openjdk. You can and should remove it after you have successfully built one of the openjdk packages (see java/bootstrap-openjdk/pkg-message). You can delete misc/compat8x after that. Jimmy ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Tue, Oct 8, 2013 at 5:21 AM, Teske, Devin devin.te...@fisglobal.comwrote: On Oct 7, 2013, at 10:48 PM, Allan Jude wrote: On 2013-10-08 01:11, Teske, Devin wrote: On Oct 7, 2013, at 10:07 PM, Allan Jude wrote: On 2013-10-07 15:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback I've generated a new version of the ISO incorporating all of todays changes and moving up to 10.0-ALPHA5 It includes 2 patches from Warren Block, improving the keymap menu and indicating which network interfaces are wireless Excellent. However, I have to say... you opened a can of worms by touching keymap. Eventually I plan to rewrite all of the scripts to the same format that zfsboot is using. I've already started rewriting keymap to the new format. Of course, this opened up another can of worms... the simple things like: DIALOG_OK DIALOG_CANCEL DIALOG_ESC Yeah, after having them, I felt a bit naked not having all of those 'constants' defined. The constants are now where they belong... `dialog.subr' I also went through bsdconfig(8) with a fine-tooth comb and made use of the new constants everywhere. I think it's a definite improvement. Originally, all I had done was add --defaultno to the dialog command, but Warren's patch makes a lot of sense, allow the user to 'try' the new keymap before trying to do the rest of the install based on it. I rewrote warren's code into the stateful design and cleaned it up. I feel would be much better off in the `dialog.subr' module. So,... I've started peppering their usage everywhere in bsdconfig to make them proper. That means they will just be transparent from including `dialog.subr'. This is definately something that I think is a good idea, but my focus is on improving the usability and functionality of the installer in time for 10.0. Unifying everything to the bsdconfig style is slightly lower priority. Admittedly, the `bsdconfig networking` stuff is quite nice *nods* I took a look at the bsdinstall networking stuff, and I wanted to run away. Let's push that into the future. It wasn't too hard to get those global exit codes deployed, so I did that, but like you say... I agree we should minimize extra work that will be eventually slated for a future release. -- Devin Just noticed that when trying to install root-on-zfs under xen it doesn't recognize the xbd0 virtual block device attached as ada0 so it skips the install screen and goes to configure networking http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso Excellent, thanks! -- Allan Jude ___ 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 _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org
Re: rcs
On 2013-10-08, at 11:17 AM, Freddie Cash fjwc...@gmail.com wrote: I haven't kept up-to-date with all the developments, but isn't this part of the bsdinstall/pkgng plan? Once the pkgng repos are all available and populated, then bsdinstall will be able to install packages from there during the install. And, isn't that part of the plan for the DVD installers, to include an installer repo for off-line installs? IOW, theoretically, one could just download the 10.0 DVD, boot, install the base, browse the repo on the DVD, select items to install, install, reboot, and be finished. Without ever needing to touch an Internet connection until after rebooting into FreeBSD, if it's even needed at all. The big issue here is having access to the distfiles. We rarely, if ever, install pre-compiled packages, because we don't know how they have been configured. Quite often the packages are built with features or dependencies we don't want, or are built without features we *do* want. Instead, we configure and compile the port according to our requirements, then build a package from that for internal use. For this to work in a disconnected environment, you need a ports tree with a fully populated distfiles/ directory. The hack we came up with was to put a FreeBSD host on the external network, on which we ran a script once a week or so that would do the something like 'portsnap fetch update; portsclean -DD; for in in /usr/ports/*/*; (cd $i make fetch); done'. That would give us a (mostly) populated /usr/ports/distfiles. We would then rsync /usr/ports from the public machine onto a USB drive. That drive would then be disconnected from the public machine and attached to an internal file server, and its /usr/ports rsynced to the file server's /usr/ports. Not pretty, but it got the job done. But that /usr/ports tree is way too big to fit on a DVD. In fact, it might even be too large for a BD-ROM. (I don't have access to the file server right now to check.) --lyndon ___ 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
[head tinderbox] failure on i386/i386
TB --- 2013-10-08 18:40:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-08 18:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-08 18:40:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-10-08 18:40:20 - cleaning the object tree TB --- 2013-10-08 18:40:20 - /usr/local/bin/svn stat /src TB --- 2013-10-08 18:40:25 - At svn revision 256158 TB --- 2013-10-08 18:40:26 - building world TB --- 2013-10-08 18:40:26 - CROSS_BUILD_TESTING=YES TB --- 2013-10-08 18:40:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-08 18:40:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-08 18:40:26 - SRCCONF=/dev/null TB --- 2013-10-08 18:40:26 - TARGET=i386 TB --- 2013-10-08 18:40:26 - TARGET_ARCH=i386 TB --- 2013-10-08 18:40:26 - TZ=UTC TB --- 2013-10-08 18:40:26 - __MAKE_CONF=/dev/null TB --- 2013-10-08 18:40:26 - cd /src TB --- 2013-10-08 18:40:26 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Oct 8 18:40:35 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Oct 8 21:53:03 UTC 2013 TB --- 2013-10-08 21:53:03 - generating LINT kernel config TB --- 2013-10-08 21:53:03 - cd /src/sys/i386/conf TB --- 2013-10-08 21:53:03 - /usr/bin/make -B LINT TB --- 2013-10-08 21:53:03 - cd /src/sys/i386/conf TB --- 2013-10-08 21:53:03 - /usr/sbin/config -m LINT TB --- 2013-10-08 21:53:03 - building LINT kernel TB --- 2013-10-08 21:53:03 - CROSS_BUILD_TESTING=YES TB --- 2013-10-08 21:53:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-08 21:53:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-08 21:53:03 - SRCCONF=/dev/null TB --- 2013-10-08 21:53:03 - TARGET=i386 TB --- 2013-10-08 21:53:03 - TARGET_ARCH=i386 TB --- 2013-10-08 21:53:03 - TZ=UTC TB --- 2013-10-08 21:53:03 - __MAKE_CONF=/dev/null TB --- 2013-10-08 21:53:03 - cd /src TB --- 2013-10-08 21:53:03 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Oct 8 21:53:03 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] ^ /src/sys/geom/geom.h:357:8: error: expression result unused [-Werror,-Wunused-value] (g_free(%p) of live object, type %d, ptr, ^~~~ /src/sys/geom/geom.h:357:46: error: expression result unused [-Werror,-Wunused-value] (g_free(%p) of live object, type %d, ptr, ^~~ 3 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-08 22:14:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-08 22:14:35 - ERROR: failed to build LINT kernel TB --- 2013-10-08 22:14:35 - 10217.15 user 1976.65 system 12854.48 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Oct 8, 2013, at 2:28 PM, Nathan Whitehorn wrote: On 10/08/13 23:21, Kurt Lidl wrote: On 10/8/2013, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. 4. What is this gnop stuff for? 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). -Nathan I wrote some support for adding ZFS to the partition editor a couple of months ago, around the time that 9.2 was branched. One of the biggest things that I have not done is integrate setting up a zfs mirror between any disks before creating the zpool. Nor did I do the gnop hack to create 4K disk blocks before creating the pool. I more or less changed the partedit program to take an argument when invoked with ufs (same as current behavior) or zfs, which knows about zfs setup stuff. The hookup to the actual scripts was, shall we say, much less intrusive than what has been published here. I guess it's time to dig out the patches and make them available to others. That would be great! The original idea was to have a zfs_ops.c to go with gpart_ops.c and have some fields in the disk item struct that said which to use. Not sure if that's ultimately workable, though. I can hack on it once the patches are there in any case. One of the options presented was to integrate ZFS knowledge into the partedit module. However, another approach that is not being spoken about is in the other direction: rewriting partedit to be in sh(1). What I'd like to see is the --treeview widget of dialog(1) fixed before such a transition is made, so the former option may be the best bet for now. For anyone that hasn't run the treeview or treeview2 samples in head/contrib/dialog/samples ... it's not anything we'd want to use to replace dialog(3) with. I've seen much nicer treeview implementations than what is in [c]dialog (currently we're using dialog-1.2-20130925 and the treeview for some reason incorporates a radio-button column which we do _not_ want for a disk partition layout menu). Of course, right now you're all looking at me like I'm crazy. Like a fox. There are real tangible benefits to rewriting the C code of partedit into shell syntax. The value-add is not just perceived. Some of the values obtained are: + Conflated namespace with singular API rather than having to learn how to script each individual blocking-utility which implements a unique method for scripting its input. + Top-down integration of new functionality. We're integrating ZFS right now and that's great that we have a fully-functional libzfs et. al. for doing this stuff in C, but usually the command-line utility functionality precedes programatic
[head tinderbox] failure on amd64/amd64
TB --- 2013-10-08 18:40:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-08 18:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-08 18:40:20 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-10-08 18:40:20 - cleaning the object tree TB --- 2013-10-08 18:40:20 - /usr/local/bin/svn stat /src TB --- 2013-10-08 18:40:25 - At svn revision 256158 TB --- 2013-10-08 18:40:26 - building world TB --- 2013-10-08 18:40:26 - CROSS_BUILD_TESTING=YES TB --- 2013-10-08 18:40:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-08 18:40:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-08 18:40:26 - SRCCONF=/dev/null TB --- 2013-10-08 18:40:26 - TARGET=amd64 TB --- 2013-10-08 18:40:26 - TARGET_ARCH=amd64 TB --- 2013-10-08 18:40:26 - TZ=UTC TB --- 2013-10-08 18:40:26 - __MAKE_CONF=/dev/null TB --- 2013-10-08 18:40:26 - cd /src TB --- 2013-10-08 18:40:26 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Oct 8 18:40:35 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Tue Oct 8 22:29:39 UTC 2013 TB --- 2013-10-08 22:29:39 - generating LINT kernel config TB --- 2013-10-08 22:29:39 - cd /src/sys/amd64/conf TB --- 2013-10-08 22:29:39 - /usr/bin/make -B LINT TB --- 2013-10-08 22:29:39 - cd /src/sys/amd64/conf TB --- 2013-10-08 22:29:39 - /usr/sbin/config -m LINT TB --- 2013-10-08 22:29:39 - building LINT kernel TB --- 2013-10-08 22:29:39 - CROSS_BUILD_TESTING=YES TB --- 2013-10-08 22:29:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-08 22:29:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-08 22:29:39 - SRCCONF=/dev/null TB --- 2013-10-08 22:29:39 - TARGET=amd64 TB --- 2013-10-08 22:29:39 - TARGET_ARCH=amd64 TB --- 2013-10-08 22:29:39 - TZ=UTC TB --- 2013-10-08 22:29:39 - __MAKE_CONF=/dev/null TB --- 2013-10-08 22:29:39 - cd /src TB --- 2013-10-08 22:29:39 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Oct 8 22:29:39 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] ^ /src/sys/geom/geom.h:357:8: error: expression result unused [-Werror,-Wunused-value] (g_free(%p) of live object, type %d, ptr, ^~~~ /src/sys/geom/geom.h:357:46: error: expression result unused [-Werror,-Wunused-value] (g_free(%p) of live object, type %d, ptr, ^~~ 3 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-08 22:48:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-08 22:48:44 - ERROR: failed to build LINT kernel TB --- 2013-10-08 22:48:44 - 11597.42 user 2407.20 system 14903.60 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-08 16:17, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. I had not considered that, I'll make that change 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. I'll disable sparc64 as well 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. The GEOM ident string doesn't do enough to help the user identify which drive is which. More data is not exposed anywhere that I could find What we really need, is dev.ada.0.desc% like we have for network interfaces and a slew of other devices. GEOM data is great, but it is not exposed in a shell friendly way any place that I could find, other than the sysctl with DOT and XML data. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. I am a sysadmin, not a programmer. I can't write C. Most people deploying servers can't write C. I agree with Devin Teske, if everything was in shell it would be a lot more usable for non-developers, who probably make up the majority of people who deploy FreeBSD. 4. What is this gnop stuff for? yeah, we align the partitions and the blocks to ensure optimal performance on 'advanced format' drives, there is no real downside for older drives, and it saves you from headaches in the future. 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). We try to do what we can here, including creating a fresh GPT and MBR and blowing them away to ensure that anything left over is really dead. We also use zpool labelclear, which doesn't check if there ever was a ZFS label, it just blindly overwrites the spots where the label would go. I'll add some additional napalm to ensure there are no zombie partitions. -Nathan ___ 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 -- Allan Jude ___ 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] RCS removed from base
On Tue, Oct 08, 2013 at 04:56:46PM -0400, Kurt Lidl wrote: On 10/8/13 4:33 PM, Cy Schubert wrote: In message 52542687.7000...@pix.net, Kurt Lidl writes: On 10/8/13, Julian Elischer wrote: On 10/7/13 11:06 PM, Steve Kargl wrote: On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote: Hey all, Did it this morning http://people.FreeBSD.org/~db/rcs.tgz Or http://www.db.net/~db/rcs.tgz It's up to core@ to decide what to do. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Virtual box require LIBCXX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2013 15:01, Jimmy Kelley wrote: On Tue, Oct 08, 2013 at 05:01:35PM -0300, Nilton Jose Rizzo wrote: Em Tue, 08 Oct 2013 09:43:19 -0700, Eric L. Camachat escreveu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2013 07:17, Nilton Jose Rizzo wrote: root@valfenda:/usr/ports/emulators/virtualbox-ose # kldload vboxdrv root@valfenda:/usr/ports/emulators/virtualbox-ose # but whern I run it, the I got this error message: rizzo@valfenda:~/src/Doutorado/visao/testes % VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found My box can be fixed by remove misc/compat8x package. In my box it was used by bootstrap jdk, look root@valfenda:/usr # pkg query %ro compat8x-amd64 java/bootstrap-openjdk root@valfenda:/usr # You don't use java? bootstrap-openjdk is only needed to BUILD openjdk. You can and should remove it after you have successfully built one of the openjdk packages (see java/bootstrap-openjdk/pkg-message). You can delete misc/compat8x after that. Yes, I have to remove it when every time re-build openjdk Eric -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlJUpJkACgkQSfBQu3oOwYy2oQD/RmsDCLHwn+X5TXyqWvoDPc3M fnwKs779NaDHE8+kVF0BAJ2oMHgvQ6X1Fmhkor9PF0pRlPu586gzsupcJU4sed/a =0MHP -END PGP SIGNATURE- ___ 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-ALPHA4 now available
Hi, Reference: From: Benjamin Kaduk ka...@mit.edu Date: Tue, 8 Oct 2013 20:07:59 -0400 (EDT) Benjamin Kaduk wrote: [-re] On Mon, 7 Oct 2013, Julian H. Stacey wrote: The fourth ALPHA build of the 10.0-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures. Note: Due to build issues within the head/ branch, ALPHA3 ISO builds were skipped. The 10.0-ALPHA4 builds correlate to svn revision r255933 of the head/ branch. (After zapping boot on an adjacent parition repairing,) I avoided installer, booted another partition, mounted FreeBSD-10.0-ALPHA4-amd64-memstick.img tar'ed to empty partition 10.0-ALPHA4 runs, built ran new generic kernel ports X11 etc. :-) I had supposed an Alpha /usr/src would compile even if it broke at run time. Not so, 10.0-ALPHA4 src/ is broken (with without obj depend). cd /usr/src ; make -i install killed the system. To avoid killing, I hacked Makefiles, list below. Reinstalled survived. I thought buildworld+installworld was the documented way to build everything. Yes, for an evolving current that's true (I'd perhaps forgotten, as I've been away from current was tired) but in the case of a release ( Alpha4 is intended for a release after fixes) I expect binaries on media to exactly match the identical src they are presumably made from, so as a simple sanity machine hardware file corruption etc check I always do the same simple make with any release. If re@ are not shipping a matched set of bins built from src theyre shipped with, I'd be very suprised, would want to know. Do you have other documentation I should look at? Sorry, not sure what you want ? I'll try with a newer current later, but Alpha4 src/ needs fixing. cd /usr/src ; cp /dev/null ~/tmp/`uname -r`.diffs foreach i ( `find . -name Makefile\*.pre_jhs | sort`) echo ~/tmp/`uname -r`.diffs diff -c $i `dirname $i`/`basename $i .pre_jhs` ~/tmp/`uname -r`.diffs BTW, unified diffs are preferred. I find context diffs easier to read, these were just to read, to show where ALPHA4 is broken. I do not want those patches stoed to apply, that would be wrong, they are just temporary to show where ALPHA4 will commit suicide, untill re@ fixes underlying breakages. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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: Virtual box require LIBCXX
Em Tue, 08 Oct 2013 17:34:33 -0700, Eric L. Camachat escreveu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2013 15:01, Jimmy Kelley wrote: On Tue, Oct 08, 2013 at 05:01:35PM -0300, Nilton Jose Rizzo wrote: Em Tue, 08 Oct 2013 09:43:19 -0700, Eric L. Camachat escreveu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2013 07:17, Nilton Jose Rizzo wrote: root@valfenda:/usr/ports/emulators/virtualbox-ose # kldload vboxdrv root@valfenda:/usr/ports/emulators/virtualbox-ose # but whern I run it, the I got this error message: rizzo@valfenda:~/src/Doutorado/visao/testes % VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found My box can be fixed by remove misc/compat8x package. In my box it was used by bootstrap jdk, look root@valfenda:/usr # pkg query %ro compat8x-amd64 java/bootstrap-openjdk root@valfenda:/usr # You don't use java? bootstrap-openjdk is only needed to BUILD openjdk. You can and should remove it after you have successfully built one of the openjdk packages (see java/bootstrap-openjdk/pkg-message). You can delete misc/compat8x after that. Yes, I have to remove it when every time re-build openjdk Eric Sorry folks, it's my fault, because I didn't read this message about this ports. Thankx again Rizzo -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlJUpJkACgkQSfBQu3oOwYy2oQD/RmsDCLHwn+X5TXyqWvoDPc3M fnwKs779NaDHE8+kVF0BAJ2oMHgvQ6X1Fmhkor9PF0pRlPu586gzsupcJU4sed/a =0MHP -END PGP SIGNATURE- ___ 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: FreeBSD 10.0-ALPHA4 now available
On Wed, Oct 09, 2013 at 02:46:32AM +0200, Julian H. Stacey wrote: I had supposed an Alpha /usr/src would compile even if it broke at run time. Not so, 10.0-ALPHA4 src/ is broken (with without obj depend). cd /usr/src ; make -i install I thought buildworld+installworld was the documented way to build everything. Yes, for an evolving current that's true No. That is the documented procedure for any installworld. Why are you running 'make -i install' from /usr/src without buildworld? If re@ are not shipping a matched set of bins built from src theyre shipped with, I'd be very suprised, would want to know. This is never the case. Glen pgp5Zd1ra8YnX.pgp Description: PGP signature
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Tue, Oct 8, 2013 at 7:13 PM, Allan Jude free...@allanjude.com wrote: On 2013-10-08 16:17, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. I had not considered that, I'll make that change 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. I'll disable sparc64 as well 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. The GEOM ident string doesn't do enough to help the user identify which drive is which. More data is not exposed anywhere that I could find What we really need, is dev.ada.0.desc% like we have for network interfaces and a slew of other devices. GEOM data is great, but it is not exposed in a shell friendly way any place that I could find, other than the sysctl with DOT and XML data. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. I am a sysadmin, not a programmer. I can't write C. Most people deploying servers can't write C. I agree with Devin Teske, if everything was in shell it would be a lot more usable for non-developers, who probably make up the majority of people who deploy FreeBSD. 4. What is this gnop stuff for? yeah, we align the partitions and the blocks to ensure optimal performance on 'advanced format' drives, there is no real downside for older drives, and it saves you from headaches in the future. 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). We try to do what we can here, including creating a fresh GPT and MBR and blowing them away to ensure that anything left over is really dead. We also use zpool labelclear, which doesn't check if there ever was a ZFS label, it just blindly overwrites the spots where the label would go. I'll add some additional napalm to ensure there are no zombie partitions. -Nathan I can now confirm with the latest patches from 1.5 hours ago applied i can now install and boot into a zfs-on-root system under XEN.. now you seriously ROCK! great work ... and thanks dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-ALPHA5 #1 r256169M: Wed Oct 9 01:03:43 EDT 2013 di...@current.optimcloud.com:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 XEN: Hypervisor version 4.3 detected. CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (2494.38-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9 Features=0x1783fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Tue, Oct 8, 2013 at 10:30 PM, Outback Dingo outbackdi...@gmail.comwrote: On Tue, Oct 8, 2013 at 7:13 PM, Allan Jude free...@allanjude.com wrote: On 2013-10-08 16:17, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. I had not considered that, I'll make that change 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. I'll disable sparc64 as well 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. The GEOM ident string doesn't do enough to help the user identify which drive is which. More data is not exposed anywhere that I could find What we really need, is dev.ada.0.desc% like we have for network interfaces and a slew of other devices. GEOM data is great, but it is not exposed in a shell friendly way any place that I could find, other than the sysctl with DOT and XML data. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. I am a sysadmin, not a programmer. I can't write C. Most people deploying servers can't write C. I agree with Devin Teske, if everything was in shell it would be a lot more usable for non-developers, who probably make up the majority of people who deploy FreeBSD. 4. What is this gnop stuff for? yeah, we align the partitions and the blocks to ensure optimal performance on 'advanced format' drives, there is no real downside for older drives, and it saves you from headaches in the future. 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). We try to do what we can here, including creating a fresh GPT and MBR and blowing them away to ensure that anything left over is really dead. We also use zpool labelclear, which doesn't check if there ever was a ZFS label, it just blindly overwrites the spots where the label would go. I'll add some additional napalm to ensure there are no zombie partitions. -Nathan I can now confirm with the latest patches from 1.5 hours ago applied i can now install and boot into a zfs-on-root system under XEN.. now you seriously ROCK! great work ... and thanks dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-ALPHA5 #1 r256169M: Wed Oct 9 01:03:43 EDT 2013 di...@current.optimcloud.com:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 XEN: Hypervisor version 4.3 detected. CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (2494.38-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9
Re: Changes to UART ns8250
On Tue, Oct 8, 2013 at 9:58 AM, Ganbold Tsagaankhuu ganb...@gmail.comwrote: Zbigniew, On Tue, Oct 8, 2013 at 3:54 AM, Zbigniew Bodek z...@freebsd.org wrote: Hello. I would like to present a patch for ns8250 serial that I would like to commit in the near future (if there are no objections). The patch is fixing newest DesignWare UART with busy detection. During frequency divisors configuration when UART is busy transferring or receiving data, line control register manipulation will not take effect. Therefore, we will not set divisor latch access bit and we will corrupt LCR instead of configuring divisors. It is necessary to wait until UART finishes all transfers to proceed with the configuration. This was detected on Armada XP as UART fails on this issue 100/100 attempts. The patch was tested by kevlo@ and me and it works on our Armada XP - based systems. Please send your comment or remarks if there are any. I'm trying your patch on r254983. Tried on 2 boards (Cubieboard2 (Allwinner A20 SoC - dual Cortex A7) and Radxa Rock (Rockchip RK3188 - Quad Cortex A9)). Both seem to have some sort of DesignWare uart. 1. It works fine on Cubieboard2. Uart dmesg is like: uart0: 16750 or compatible mem 0x1c28000-0x1c283ff irq 33 on simplebus0 uart0: console (115200,n,8,1) 2. No any printing on screen in case of Radxa Rock. Without your patch uart dmesg is like: uart0: 16650 or compatible mem 0x20064000-0x200643ff irq 68 on simplebus0 uart0: console (115200,n,8,1) In case of RK3188 SoC, it seems booting FreeBSD kernel seems very fragile, not sure yet what is causing the problem. Even with stock ns8250 some version later than r254983 didn't show/print anything on serial console few days ago. Only thing so far I know is this r254983 (with some patch) works in my case on RK3188 SoC based board. Zbigniew, Just tried again your patch on RK30xx board. I was able to see boot messages on screen. This uart detected as: ... uart0: 16650 or compatible mem 0x20064000-0x200643ff irq 68 on simplebus0 uart0: console (115200,n,8,1) uart0: fast interrupt ... Can you show me your uart detection log? It seems this DW uart of RK30xx is different than DW uart of A10/A20. Boot simply stops printing start_init: trying /sbin/init. thanks, Ganbold thanks, Ganbold Best regards Zbigniew Bodek ___ 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: Unable to installworld after successful buildworld and buildkernel
But where is DB_FROM_SRC documented? I never saw it anywhere. UPDATING file needs to be updated for installing FreeBSD on a partition where there is no OS installed. It's documented in Makefile.inc1 where the less commonly used options are documented. It should be documented in the Handbook along with the process of cross installation and image creation. I disagree that UPDATING should document the process of installing to other locations. That would be a distraction from it's purpose of letting users update their systems. It's already far too complicated. -- Brooks UPDATING file has a section on cross-installing current into a separate partition. This part ought to be complete, including DB_FROM_SRC, rather than leaving a user lost at sea when a new user (unbound) sneaks in. UPDATING documented when user auditdistd was added, so why not for unbound? Tom ___ 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: Unable to installworld after successful buildworld and buildkernel
Thomas Mueller wrote this message on Wed, Oct 09, 2013 at 03:00 +:
But where is DB_FROM_SRC documented? I never saw it anywhere. UPDATING
file needs to be updated for installing FreeBSD on a partition where
there is no OS installed.
It's documented in Makefile.inc1 where the less commonly used options
are documented. It should be documented in the Handbook along with the
process of cross installation and image creation.
I disagree that UPDATING should document the process of installing to
other locations. That would be a distraction from it's purpose of
letting users update their systems. It's already far too complicated.
-- Brooks
UPDATING file has a section on cross-installing current into a separate
partition.
This part ought to be complete, including DB_FROM_SRC, rather than leaving a
user lost at sea when a new user (unbound) sneaks in.
UPDATING documented when user auditdistd was added, so why not for unbound?
How does this look:
Index: UPDATING
===
--- UPDATING(revision 256024)
+++ UPDATING(working copy)
@@ -1899,7 +1899,7 @@
make buildkernel KERNCONF=YOUR_KERNEL_HERE
maybe newfs current's root partition
mount current's root partition on directory ${CURRENT_ROOT}
- make installworld DESTDIR=${CURRENT_ROOT}
+ make installworld DESTDIR=${CURRENT_ROOT} -DDB_FROM_SRC
make distribution DESTDIR=${CURRENT_ROOT} # if newfs'd
make installkernel KERNCONF=YOUR_KERNEL_HERE DESTDIR=${CURRENT_ROOT}
cp /etc/fstab ${CURRENT_ROOT}/etc/fstab# if newfs'd
I tested distribution and it appears not to need it.
P.S. I didn't think this feature even existed yet, but apparently it
has since January. Thanks brooks.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
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
