Re: GCC update for testing
Hi again; On 05/17/12 11:44, Dimitry Andric wrote: On 2012-05-17 17:44, Pedro Giffuni wrote:> Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really interested, the log is here: http://people.freebsd.org/~pfg/patches/gcc41-pr-log It may be my imagination but the patch seems to be causing more warnings than usual and it breaks the kernel here: ... ../../../cam/scsi/scsi_sa.c: In function 'samount': ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used uninitialized in this function These warnings seem wrong, upon casual inspection of the code. In any case, if you compile the same file with gcc 4.7, they don't appear. :) Any idea which particular gcc fix is responsible for them? As a workaround, we could set all those variable to some reasonable value, but that feels like a cheap trick to me... But I'd rather just not import the fix that causes those warnings. Ugh... It appears the patch was fine after all: the warnings were somehow triggered by optimizations in my /etc/make.conf file. I will test it further before committing. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GCC update for testing
On 05/18/12 02:08, Gleb Kurtsou wrote: On (17/05/2012 10:44), Pedro Giffuni wrote: Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really interested, the log is here: http://people.freebsd.org/~pfg/patches/gcc41-pr-log Could you check if patch fixes this issue: http://marc.info/?l=freebsd-hackers&m=132348021530691&w=2 I've disabled gcc from base locally since discovering it. Thanks, Gleb. No joy :(. Sorry: ./gcc-test1 src2.c:16:test_fail: Assertion failed: addr->sin_addr.s_addr == ntohl(INADDR_ANY) Abort ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GCC update for testing
Hi Dimitry; On 05/17/12 11:44, Dimitry Andric wrote: On 2012-05-17 17:44, Pedro Giffuni wrote:> Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really interested, the log is here: http://people.freebsd.org/~pfg/patches/gcc41-pr-log It may be my imagination but the patch seems to be causing more warnings than usual and it breaks the kernel here: ... ../../../cam/scsi/scsi_sa.c: In function 'samount': ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used uninitialized in this function These warnings seem wrong, upon casual inspection of the code. In any case, if you compile the same file with gcc 4.7, they don't appear. :) Any idea which particular gcc fix is responsible for them? As a workaround, we could set all those variable to some reasonable value, but that feels like a cheap trick to me... But I'd rather just not import the fix that causes those warnings. I will have to dig deeper into the changes to see what causes this. In any case I do agree and the patch will not be committed. Ultimately I can just leave the list around and we bring them in only as needed. Pedro. ___ 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"
GCC update for testing
Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really interested, the log is here: http://people.freebsd.org/~pfg/patches/gcc41-pr-log It may be my imagination but the patch seems to be causing more warnings than usual and it breaks the kernel here: $ make cc -c -O2 -Os -pipe -fno-strict-aliasing -march=athlon64 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror ../../../cam/scsi/scsi_sa.c cc1: warnings being treated as errors ../../../cam/scsi/scsi_sa.c: In function 'samount': ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_enabled' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2727: warning: 'current_density' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2727: note: 'current_density' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here *** Error code 1 ... Other stuff I tested (Apache OpenOffice) builds fine. cheers, Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic, seems related to r234386
Hello; On 05/12/12 17:49, Mateusz Guzik wrote: Gave this a spin and found what looks like a deadlock: http://people.freebsd.org/~pho/stress/log/ext2fs.txt Not a new problem, it would seem. Same issue with 8.3-PRERELEASE r232656M. pid 2680 (fts) holds lock for vnode cb4be414 and tries to lock cc0ac15c pid 2581 (openat) holds lock for vnode cc0ac15c and tries to lock cb4be414 openat calls rmdir foo/bar and ext2_rmdir unlocks and tries to lock again foo's vnode. This is fairly easly reproducible with concurrently running mkdir and fts testcase programs that are provided by stress2. I'll try to come up with a patch by the end of the week. Easier way to reproduce: mkdir from stress2 and "while true; do find /mnt> /dev/null; done" on another terminal. Assuming foo/bar directory tree, deadlock happens during removal of bar with simultaneous lookup of .. in bar. Proposed trivial patch: http://student.agh.edu.pl/~mjguzik/patches/ext2fs_rmdir-deadlock.patch If the lock cannot be acquired immediately unlocks 'bar' vnode and then locks both vnodes in order. After patching this I ran into another issue - wrong vnode type panics from cache_enter_time after calls by ext2_lookup. (It takes some time to reproduce this, testcase as before.) It looks like ext2_lookup is actually adapted version of ufs_lookup and lacks some bugfixes present in current ufs_lookup. I believe those bugfixes address this bug. Here is my attempt to fix the problem (based on ufs_lookup changes): http://student.agh.edu.pl/~mjguzik/patches/ext2fs_lookup-relookup.patch It is indeed extremely useful that UFS and ext2fs are so similar. The two bugfixes were committed as revision 235508, thanks! Pedro. ___ 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] BSD sort coming to -CURRENT
Oleg and Gabor; Awesome! Kudos and huge thanks for working on this!! Pedro. On 05/08/12 10:51, Gabor Kovesdan wrote: Hi Folks, Oleg Moskalenko has been working very hard on BSD sort and by now we think it is compatible with the base version (and has even more features, the ideas mostly taken from the latest GNU sort) and it is efficient. I just updated the textproc/bsdsort port to the latest version so that people can test it and I plan to commit it to HEAD in some days, for now installed as "bsdsort", leaving GNU sort the default version. If someone has any objection, please raise it now. Future plans are to switch the logic and make BSD sort default once it has undergone enough testing and finally drop GNU sort permanently if no problems appear. Note that the strcoll() and wcscoll() implementations of FreeBSD are incomplete so neither GNU sort nor the new BSD sort work 100% correctly with multi-byte locales but once the underlying functions are implemented, BSD sort will just work fine. Gabor ___ 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: : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
On 04/30/12 14:04, Oleksandr Tymoshenko wrote: On 29/04/2012 12:04 PM, Adrian Chadd wrote: .. and the output from the buildworld: .. skipped .. -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So jemalloc_jemalloc.c: In function 'calloc': jemalloc_jemalloc.c:1027: internal compiler error: in change_address_1, at emit-rtl.c:1784 Please submit a full bug report, with preprocessed source if appropriate. Seehttp://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error This ICE was fixed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256 Unfortunately the fix is GPLv3-licensed, so we can't merge it back as-is. Actually.. the fix was merged to the gcc 4.1 branch so we can take it under GPLv2: http://gcc.gnu.org/viewcvs?view=revision&revision=128198 best regards, Pedro. ___ 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: contrib/jemalloc
On 04/21/12 02:23, Doug Barton wrote: ... In libedit we have incomplete merges from upstream (that was CVS fault), we have some changes that are obsolete wrt to how upstream solved the same issues and we have a couple of files that have diverged completely from upstream. I agree that sounds like an ugly mess ... who is working on cleaning it up? Is this something that we need to create a team to address? It certainly sounds like something too large for one person to handle on their own. I have a patch (pending approval) to improve things here: http://people.freebsd.org/~pfg/patches/patch-libedit-cvs20091228 and I will try to reduce some other differences with upstream code but I think at some point we will just have to do a brute merge from the code upstream. Either way it all can all be solved but it's just a lot of work and I can see how the direct approach helps understand better what is happening and can ultimately save time. I'm glad we have an area of agreement. It sounds to me like the lesson from libedit is to do it right from the very beginning, so that things like libedit don't happen again. The libedit case shows a case where the vendor branch approach failed. To be quite honest, it all depends on the maintainer and not really on the mechanics: if no one cares to keep up with the small changes during a while, eventually someone has to take care of a bigger set of changes in the future. In jemalloc's case I am really glad to see the code updated and maintained now. Pedro. ___ 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: contrib/jemalloc
On 04/20/12 19:32, David O'Brien wrote: On Fri, Apr 20, 2012 at 02:13:32PM -0700, Pedro Giffuni wrote: Easier said than done. Feel free to give libedit a try. That has nothing to do with our process and everything to do with us blindly hacking away pissing all over to be our own thing -- BUT still wanting to take work from the original author. I fail to see how not updating thru $FBSDrepo/vendor/NetBSD/libedit is easier than updating thru it. Either way you have to figure out what to do with our great divergance. At least when using the vendor branch you can use a good 3-way diff merge tool (e.g. svn). Usually the vendor upgrade approach works just fine if we do the periodic work of keeping up to date and we are careful to submit our changes upstream. The issue is that you really have to be in sync with one upstream version so that the changes you merge from the vendor branch are consistent. In libedit we have incomplete merges from upstream (that was CVS fault), we have some changes that are obsolete wrt to how upstream solved the same issues and we have a couple of files that have diverged completely from upstream. Either way it all can all be solved but it's just a lot of work and I can see how the direct approach helps understand better what is happening and can ultimately save time. Pedro. ___ 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: contrib/jemalloc
--- Ven 20/4/12, Doug Barton ha scritto: ... > > With due respect, if doing it the right way is too > difficult, the answer > is to ask for help rather than giving up. There are plenty > of us who are > experienced with doing this, and would be glad to assist. > > In the CVS era I agree that vendor imports could be very > difficult. But > with svn it's much, much easier. > Easier said than done. Feel free to give libedit a try. Pedro. ___ 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: contrib/jemalloc
Hi; --- Ven 20/4/12, Doug Barton ha scritto: ... > > > > The workflow I'm using is documented in the patch > (contrib/jemalloc/FREEBSD-upgrade). Can you tell me > how to achieve a similarly streamlined import flow with a > vendor branch in the mix? Also, what history would a > vendor branch preserve that this workflow does not? > The only upside to vendor branch merges I can think of is > that if any jemalloc sources were manually modified between > imports, merging would fail rather than silently overwriting > the changes. However, this presumes that changes > aren't making it upstream. > > I attempted to engage you about this on the svn list and > apparently you ignored my message. David is right, what > you're doing is not even close to our normal work flow. > It would actually be easier for you (and those > who may be maintaining this after you're gone) for you to do > things the way that we normally do them. > FWIW, While the vendor branch is usually the cleanest way to merge updates, it is not always the best. I personally gave up on updating two packages from the vendor tree because it's just too much trouble. In this case it's likely that the committed jemalloc is very FreeBSD specific and doesn't really match the more generic version. INHO, being that the committer is also the author it is likely his prerogative how to update it. cheers, Pedro. ___ 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"
[CFT]: libedit update (NetBSD CVS 2009-12-28)
Hi; I noticed that libedit is seriously outdated so I tried to sync it with the upstream (NetBSD) tree. For the time being I avoided the international support and related changes since they move some files and, in general, complicates getting things merged properly. The resulting patch is here: http://people.freebsd.org/~pfg/patches/patch-libedit-cvs20091228 With this update GNU readline support should work better and we will be more in line with what is shipped in both NetBSD and Darwin. I also submitted some of our changes upstream but some things like file completion and the code in tty.c have diverged on NetBSD. Please do let me know if there is anything strange. I think for the next update we may probably just merge the vendor branch directly. best regards, Pedro. ___ 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: -ffast-math in Ports and wrong generated code
On 04/05/12 01:46, Andrey Simonenko wrote: On Wed, Apr 04, 2012 at 09:45:25AM -0500, Pedro Giffuni wrote: On 04/04/12 04:29, Andrey Simonenko wrote: On Tue, Apr 03, 2012 at 06:43:00AM -0700, Steve Kargl wrote: The SVN commit http://svnweb.freebsd.org/base?view=revision&revision=228756 will point you to this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796 and we are keeping consistency with both upstream and Apple's gcc. Well, I've found exact commit to upstream gcc source tree that corrects the bug described above: http://gcc.gnu.org/viewcvs/trunk/gcc/builtins.c?r1=117751&r2=117929 Aha!.. OK I needed to be sure we would still be consistent with upstream. The upstream patch is under GPLv2 so it can be committed. Thanks Andrey for your patience and persistence in finding this! Pedro. ___ 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: -ffast-math in Ports and wrong generated code
On 04/04/12 04:29, Andrey Simonenko wrote:
On Tue, Apr 03, 2012 at 06:43:00AM -0700, Steve Kargl wrote:
On Tue, Apr 03, 2012 at 02:21:11PM +0300, Andrey Simonenko wrote:
I use one port from the Ports Collection, that works with FP. Having
reinstalled it (its version was not changed) I noticed that it started
to work incorrectly. After debugging and disassembling its code I found
out that the -ffast-math option used for building was the result of
wrongly generated code (I did not specify this option in /etc/make.conf).
At least finite() function call was eliminated from the result Assembler
code when -ffast-math option is used, tested on 9.0-STABLE and 10.0-CURRENT.
Example test source code and generated code under 9.0-STABLE on amd64
by gcc from the base system:
-
#include
#include
void
check_finite(double x)
{
printf("%d\n", finite(x));
}
-
% gcc -Wall -O2 -S finite.c
-
check_finite:
.LFB3:
subq$8, %rsp
.LCFI0:
callfinite <-- call to finite()
movl$.LC0, %edi
movl%eax, %esi
addq$8, %rsp
xorl%eax, %eax
jmp printf
.LFE3:
.size check_finite, .-check_finite
-
% gcc -Wall -O2 -ffast-math -S finite.c
-
check_finite:
.LFB3:
xorl%esi, %esi <-- fake result from finite()
movl$.LC0, %edi
xorl%eax, %eax
jmp printf
.LFE3:
.size check_finite, .-check_finite
-
Can somebody comment this?
Read the man page for gcc. With --fast-math,
gcc assumes that the result of any FP operation
is finite. So, the function call to finite()
is eliminated as it is always true.
Looks like that I was misunderstood. I did not ask why finite() was
eliminated, I asked why fake result from finite() is wrong. Obviously
that -ffast-math can optimize FP arithmetics and as a result some functions
can be eliminated. The problem is not respecting IEEE specifications for
FP, the problem is wrongly generated code when -ffast-math is used.
Actually there is a bug in GCC used in the base system. There was made
a change to builtins.c from gcc in revision 1.12 [1] and as a result gcc
started to eliminate finite() function calls with -ffinite-math-only.
...
After this change the corresponding Assembler code for my test file is:
% gcc -Wall -O2 -ffast-math -S finite.c
-
check_finite:
.LFB3:
movl$1, %esi<-- fake result from finite()
movl$.LC0, %edi
xorl%eax, %eax
jmp printf
.LFE3:
.size check_finite, .-check_finite
-
What do you think? If there is no objections, I'll create PR.
[1]
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/gcc/builtins.c.diff?r1=1.11;r2=1.12
___
The SVN commit
http://svnweb.freebsd.org/base?view=revision&revision=228756
will point you to this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
and we are keeping consistency with both upstream and Apple's gcc.
Which is the affected port again? It should be fixed there or else
the problem will continue with future compilers.
Pedro.
___
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"
[CFT] ext2/3 nanosecond timestamps patch.
Hello; I have been working on implementing some ext4 features that can work in ext3 mode in preparation towards bringing some more of the ext4 work Zheng Liu did for his GSoC 2010 project. The first of this features is nanosecond/birthtime timestamping, which basically means that if the filesystem was created with big inodes we carry the nanosecond and birthtime stamps that UFS2 has always supported. Apparently the appropriate fields in the on-disk inode have been approved for a long time but support for this in ext3 has not been widely distributed. In preparation for ext4 most linux distributions did enable by default such bigger inodes and some people do use nanosecond timestamps in ext3. I would really appreciate if ext2/ext3 users test this patch: http://people.freebsd.org/~pfg/patches/patch-ext2fs-ns_timestamps It should apply cleanly to 10-current or to a recent 9.0-stable. IMPORTANT: do avoid testing this patch in old systems that may be using Extended Attributes. You will probably not notice any change but do let me know how it goes. best regards, Pedro. ps. FWIW, while here I also implemented the basic inode versioning stuff from Lustre but it's doesn't seem to any use: http://wiki.lustre.org/images/1/16/Inodever-HLD.pdf ___ 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"
[CFT] New headers from the maestro3 snd driver
Hello guys; As some of you may have noticed I have been replacing some GPL'd headers from the sound system. In the case of the Maestro3 snd driver, basically the same headers are available in the BSD licensed OSS drivers (in the Attic though - that card is rather old). If someone still has that card please test this patch: http://people.freebsd.org/~pfg/patch-maestro3 Apparently there are also some open PRs related to that card but it would certainly be good to have some feedback on the status of this driver. Pedro. ___ 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: Removal of sysinstall from HEAD and lack of a post-install configuration tool
Hello; --- Gio 29/12/11, Chris Rees ha scritto: > > > > I use the nvidia driver, no idea what people with ATI > > cards do. > > I'm sorry to hear you're having trouble with that, if you > ever want to try again and you can't work it out get me > off list ;) > Getting X11 to run on virtualbox from a FreeBSD 9.0 CD installation is pretty much a nightmare. Is there something about it in the users handbook? A wiki page about setting up X11 on FreeBSD would do it too. Perhaps we should write one. ... > > I hope I don't have to start downloading manually all > > the prepackaged dependencies (I still do that with > > Java and it's not nice). > > Nah, pkg_add -r works and grabs anything you need. Try it > with something monstrous (like gcc...) > Aha! I guess I just keep doing things the old way then, the package browser was still very nice but I guess what is really missing is documentation. How is someone new to FreeBSD supposed to know what packages are available and how to install them? cheers, Pedro. > Chris > ___ > 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: Removal of sysinstall from HEAD and lack of a post-install configuration tool
--- Gio 29/12/11, Chris Rees ha scritto: > > FWIW; > > > > I have practically given up on installing FreeBSD > lately > > and I mostly use PC-BSD. I mainly see two big issues: > > > > -X.Org has become very difficult to install. Setting > up > > hald and friends, not to mention that you have to > > choose carefully your hardware previously. It's a > > nightmare. > > I've not found that... installing xorg-drivers with the > correct options is hassle-free... have you posted these > problems to -x11@? > Hmm.. I think it was 8.2 and "X.org -configure" didn't give me a working screen, and then I discovered I had to be using hald, it was painful and I starting keeping a copy of my working configuration in a USB mem. TBH the -x11 guys were really doing their own homework keeping up with linux and I was able to find out the information on the net. I use the nvidia driver, no idea what people with ATI cards do. > > - I am OK with sysinstall disappearing: however it > was > > nice to have all the setup tools in one place. How am > > I supposed to install prebuilt packages (and the > myriad > > of dependencies) from now on? Ports are cool but > having > > to wait to rebuild gcc to be able to use scilab is a > > nonsense. > > Use packages, we do do them! > Of course, but no idea how to use them without sysinstall's post-install configuration screen: it was just too easy. I hope I don't have to start downloading manually all the prepackaged dependencies (I still do that with Java and it's not nice). Pedro. ___ 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: Removal of sysinstall from HEAD and lack of a post-install configuration tool
--- Gio 29/12/11, Nathan Whitehorn ha scritto: ... > > I'd appreciate any specific comments you might have, and > especially > specific suggestions for improvements. Except from people > who are old > hands at sysinstall, I've received almost universally > positive comments > on the user experience. Patches would be even more > appreciated, since > real life has intervened to steal most of my FreeBSD time. > -Nathan > FWIW; I have practically given up on installing FreeBSD lately and I mostly use PC-BSD. I mainly see two big issues: -X.Org has become very difficult to install. Setting up hald and friends, not to mention that you have to choose carefully your hardware previously. It's a nightmare. - I am OK with sysinstall disappearing: however it was nice to have all the setup tools in one place. How am I supposed to install prebuilt packages (and the myriad of dependencies) from now on? Ports are cool but having to wait to rebuild gcc to be able to use scilab is a nonsense. PC-BSD is not without problems though. In my system it wants to use "latam" kbd which doesn't even exist AFAICT. Just my $0.02, I know writing a replacement for the full blown sysinstall is a rather heroic thing to do. Regards, Pedro. ___ 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"
