Re: firefox instability may be fixed now in HEAD
Pierre Abbat wrote: I think that when I last upgraded all my packages, it was to Q1. For me, a package upgrade is a big event, because I don't have much free time, and I have to see if the upgrade broke anything (I frequently find that I have to symlink libraries, because the upgrade doesn't replace libraries that have the same version number but are now linked against newer other libraries). I *highly* recommend a jail or a simple chroot for this, if you're not using such a procedure already. Makes updates *much* less disruptive - as you can test new packages / fix any problems before going live - similarly, you can keep the old copy around in case of problems.. only downside is the disk space.. but these days - not so much of an issue in most cases cheers - Chris
Re: SMP boot option?
Am Dienstag, den 05.10.2010, 18:55 -0500 schrieb Tyler Mills: I don't know how many people do this, but usually my first step when building a Dragonfly BSD system is building an SMP kernel with APIC_IO. I know there are some bugs for some people with regards to AHCI and other settings, but wouldn't it make sense to have an SMP/APIC_IO option for bootup? That way you can see if it works, if it fails boot another kernel. Similar to how ACPI is treated. Just bouncing this idea off, I might end up just making my own ISO for this for my use, and could upload if needed. Please try out my repo: http://gitweb.dragonflybsd.org/~mneumann/dragonfly.git/shortlog/refs/heads/apic_io For x86_64, it gets completely rid of compile time APIC_IO and introduces a loader tunable hw.apic_io_enable. Right now it does not compile non-SMP, but I will fix that later. Also i386 is not yet supported, again, it's pretty easy and straightforward to bring in i386 support. If we commit this to master, I'd like to see the distribution shiped with an SMP kernel as well! Regards, Michael
Re: SMP boot option?
* Michael Neumann wrote: For x86_64, it gets completely rid of compile time APIC_IO and introduces a loader tunable hw.apic_io_enable. Right now it does not compile non-SMP, but I will fix that later. Also i386 is not yet supported, again, it's pretty easy and straightforward to bring in i386 support. Wow! I'd love to see this for i386 as well ;) If we commit this to master, I'd like to see the distribution shiped with an SMP kernel as well! Yep, but we should stay for 2.8 with the default and commit that stuff after the release. Cheers Matthias
Re: SMP boot option?
I'll give this a try in my VM. On Wed, Oct 6, 2010 at 8:49 AM, Matthias Schmidt matth...@dragonflybsd.org wrote: * Michael Neumann wrote: For x86_64, it gets completely rid of compile time APIC_IO and introduces a loader tunable hw.apic_io_enable. Right now it does not compile non-SMP, but I will fix that later. Also i386 is not yet supported, again, it's pretty easy and straightforward to bring in i386 support. Wow! I'd love to see this for i386 as well ;) If we commit this to master, I'd like to see the distribution shiped with an SMP kernel as well! Yep, but we should stay for 2.8 with the default and commit that stuff after the release. Cheers Matthias -- --A state, is called the coldest of all cold monsters. Coldly lieth it also; and this lie creepeth from its mouth: I, the state, am the people.
RTG configure failing, hacking ./configure?
While building RTG, I get this error on ./configure --prefix=/usr/local/rtg I am going through and trying to hack the configure file to see if I can get it to work, though I wonder if you guys have any ideas? Thanks Error: config.guess timestamp = 2002-03-04 uname -m = x86_64 uname -r = 2.7-DEVELOPMENT uname -s = DragonFly uname -v = DragonFly v2.7.3.1242.g7b5a2-DEVELOPMENT #0: Tue Oct 5 19:42:59 CDT 2010 r...@rtgbox:/usr/obj/usr/src/sys/X64_SMP /usr/bin/uname -p = x86_64 /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = x86_64 UNAME_RELEASE = 2.7-DEVELOPMENT UNAME_SYSTEM = DragonFly UNAME_VERSION = DragonFly v2.7.3.1242.g7b5a2-DEVELOPMENT #0: Tue Oct 5 19:42:59 CDT 2010 r...@rtgbox:/usr/obj/usr/src/sys/X64_SMP configure: error: cannot guess build type; you must specify one Tyler Mills --A state, is called the coldest of all cold monsters. Coldly lieth it also; and this lie creepeth from its mouth: I, the state, am the people.
Re: SMP boot option?
Am Mittwoch, den 06.10.2010, 15:49 +0200 schrieb Matthias Schmidt: * Michael Neumann wrote: For x86_64, it gets completely rid of compile time APIC_IO and introduces a loader tunable hw.apic_io_enable. Right now it does not compile non-SMP, but I will fix that later. Also i386 is not yet supported, again, it's pretty easy and straightforward to bring in i386 support. Wow! I'd love to see this for i386 as well ;) i386 is there and compiles for both SMP / non-SMP. http://gitweb.dragonflybsd.org/~mneumann/dragonfly.git/commit/79b62055301f75e30e625e64f13564a1145fe853 I tried to make as an non intrusive as possible. Regards, Michael
Re: RTG configure failing, hacking ./configure?
Success!
Added these lines to config.guess
--
*:DragonFly:*:*)
echo ${UNAME_MACHINE}-unknown-dragonflybsd`echo
${UNAME_RELEASE}|sed -e 's/[-(].*//'`
exit 0;;
--
and this to config.sub
--
| -hiux* | -386bsd* | -netbsd* | -openbsd* | -freebsd*
| -riscix* \
became:
--
| -hiux* | -386bsd* | -netbsd* | -openbsd* | -dragonfly*
| -freebsd* | -riscix* \
--
Built with # ./configure --prefix=/usr/local/rtg
--with-mysql=/usr/pkg/ --with-snmp=/usr/pkg
On Wed, Oct 6, 2010 at 12:45 PM, Tyler Mills tylermi...@gmail.com wrote:
While building RTG, I get this error on ./configure --prefix=/usr/local/rtg
I am going through and trying to hack the configure file to see if I
can get it to work, though I wonder if you guys have any ideas?
Thanks
Error:
config.guess timestamp = 2002-03-04
uname -m = x86_64
uname -r = 2.7-DEVELOPMENT
uname -s = DragonFly
uname -v = DragonFly v2.7.3.1242.g7b5a2-DEVELOPMENT #0: Tue Oct 5
19:42:59 CDT 2010 r...@rtgbox:/usr/obj/usr/src/sys/X64_SMP
/usr/bin/uname -p = x86_64
/bin/uname -X =
hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch =
/usr/bin/oslevel =
/usr/convex/getsysinfo =
UNAME_MACHINE = x86_64
UNAME_RELEASE = 2.7-DEVELOPMENT
UNAME_SYSTEM = DragonFly
UNAME_VERSION = DragonFly v2.7.3.1242.g7b5a2-DEVELOPMENT #0: Tue Oct
5 19:42:59 CDT 2010 r...@rtgbox:/usr/obj/usr/src/sys/X64_SMP
configure: error: cannot guess build type; you must specify one
Tyler Mills
--A state, is called the coldest of all cold monsters. Coldly lieth it
also; and this lie creepeth from its mouth: I, the state, am the
people.
--
--A state, is called the coldest of all cold monsters. Coldly lieth it
also; and this lie creepeth from its mouth: I, the state, am the
people.
Re: firefox instability may be fixed now in HEAD
On Wednesday 06 October 2010 03:37:55 Chris Turner wrote: I *highly* recommend a jail or a simple chroot for this, if you're not using such a procedure already. Makes updates *much* less disruptive - as you can test new packages / fix any problems before going live - similarly, you can keep the old copy around in case of problems.. only downside is the disk space.. but these days - not so much of an issue in most cases I have a 36 GB disk (actually 38 GB but 2 GB is swap), usually 45-55% full. 4.4 GB is in /home. Do I have enough room to try this? Pierre -- La sal en el mar es más que en la sangre. Le sel dans la mer est plus que dans le sang.
Re: RTG configure failing, hacking ./configure?
On 06.10.10 21:19, Tyler Mills wrote: Success! Added these lines to config.guess Don't do stupid things. Just obtain latest config.guss and config.sub: $ ftp 'http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess' $ ftp 'http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub' -- Hasso Tepper
Re: RTG configure failing, hacking ./configure?
That appears to include the changes I added myself. I will keep this in mind next time I encounter this error. Thanks On Wed, Oct 6, 2010 at 1:41 PM, Hasso Tepper ha...@estpak.ee wrote: On 06.10.10 21:19, Tyler Mills wrote: Success! Added these lines to config.guess Don't do stupid things. Just obtain latest config.guss and config.sub: $ ftp 'http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess' $ ftp 'http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub' -- Hasso Tepper -- --A state, is called the coldest of all cold monsters. Coldly lieth it also; and this lie creepeth from its mouth: I, the state, am the people.
Re: firefox instability may be fixed now in HEAD
Pierre Abbat wrote: I have a 36 GB disk (actually 38 GB but 2 GB is swap), usually 45-55% full. 4.4 GB is in /home. Do I have enough room to try this? Hard to say - you'll need enough space to store: 1) base system (~300-500MB) 2) pkgtools (not sure) 3) any packages (so FF + dependencies, or what have you) 4) if building in the chroot or jail, enough space for pkgsrc, distfiles, $WRKDIR, etc. Worst case is your disk fills and you have to wipe the setup - although - where's the other 45% of space? might make more sense to use an area there with more available if possible - or create a new partition for scratch work if the space isn't allocated. I usually setup a chroot, backup any important user files, and then 'mount null' my /home so that my data is in synch between the two (its a little annoying to copy files inout) DISPLAY=:0 is your friend in these cases if using a mixed old new setup - e.g: chroot /path/to/chroot DISPLAY=:0 gui-app-under-test the instructions in jail(8) for building jails work for chroots as well - just chroot /path to enter instead of starting the jail.. you might need to mount devfs as well - I'm not sure if this is needed - dont recall off hand also - some things like gnome apps, etc. might not have their 'proper' environment (e.g. dbus, etc) to display fonts, etc. properly - keep that in mind if testing. Cheers Good Luck
