Re: Computer-app. crashes after accessing webdav disk
Well, no, not a general Gnome problem, but it's probably something in the Gnome code (since cadaver works) that is incompatible specifically with DragonFly. It could be something as simple as it's something that works one way with FreeBSD and has changed in DragonFly, but Gnome uses the old behavior. Ok. I don't think there's any developers for DragonFly looking at Gnome code right now, so it may be easier to ask Gnome devs, since they already are dealing with the code. Someone here can prove me wrong, of course. Where do I ask them? Through the bugs list?
Call for testers: sendmail 8.14.1
I've imported the sendmail 8.14.1 source into the CVS repository but haven't linked it to the build yet. If you would like to test it, you can grab the build patch at: http://leaf.dragonflybsd.org/~gshapiro/8.14.patch If I don't hear any negative comments about the patch, I'll commit it by this weekend.
Re: dd vs. truncate for creating vkernel root images
:Hi all, : :Is there any advantage in using :'dd if=/dev/zero of=/var/vkernel/rootimg.01 bs=1m count=2048' :over the much quicker :'truncate -s 2G /var/vkernel/rootimg.01' :other than getting a root image filled with zeros? : :Thanks, :Nuno It's not a good idea to use truncate. The problem is that no actual disk space is reserved for the image file when you just truncate it to the desired size. Blocks on disk are then allocated on the fly, as the vkernel is running, and thus can wind up being severely fragmented on disk. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: modular-xorg
Nevermind, looked it up on the www. http://www.computerhope.com/unix/urehash.htm
Re: modular-xorg
How does one rehash? From the context of this discussion I'm guessing you type in rehash at the command prompt. This is only needed if the shell is a c based shell though. Like Jeremy said, make sure it is in your PATH.
Re: modular-xorg
On Wed, 11 Apr 2007 19:10:40 -0500 (CDT) "Jeremy C. Reed" <[EMAIL PROTECTED]> wrote: > Do you need to "rehash" How does one rehash? -- Gergo Szakal <[EMAIL PROTECTED]> University Of Szeged, HU Faculty Of General Medicine /* Please do not CC me with replies, thank you. */
Re: modular-xorg
> Hi Guys, does anyone got modular-xorg working? I compile with > "X11_TYPE=modular" in /usr/pkg/etc/mk.conf. After setting up xorg (Xorg > -configure) and type # startx i got this error, "command not found" so i type > # startkde and got this error "cannot connect to xserver" so i guess > modular-xorg-client is missing. Any suggestion, and thanks. startx is in the xinit package. Do you have pkgsrc/x11/xinit installed? Do you need to "rehash" to see startx? Is it in your PATH? Jeremy C. Reed
RE: comparing cvsup vs. rsync
It would be huge! I actually meant to key each file, and version of each file with an integer, and store it out on disk, and store the metadata(checksums) in the DB for speed, but a lack of coffee prevented the conveyance of the full idea. ;-) ...Going away now to read up on git... Nigel Weeks Tech Support and Systems Developer Rural Press Tasmania The Examiner Newspaper Ph. 03 6336 7234 Mob. 0408 133 738 Email. [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:users- > [EMAIL PROTECTED] On Behalf Of Simon 'corecode' Schubert > Sent: Thursday, 12 April 2007 9:12 AM > To: users@crater.dragonflybsd.org > Subject: Re: comparing cvsup vs. rsync > > Nigel Weeks wrote: > > Just having an idea about this...are there any files in the source tree > that exceed 32kbytes? > > > > What if a database solution were created to: > > Contain every version of every file of every branch in a nicely indexed > database table > > The md5/sha256 of each entry mentioned above > > 512 byte chunks of each file mentioned above in a nicely indexed table > > The md5/sha256 of every 512 bytes of the above mentioned file. > > uh-ah. i guess that's for checkout, but still it seems very wrong. I > mean, really. Uh, I can't stop shuddering. I just hope you are not > serious :) > > and the database will be really huge... > > actually, it sounds like git, just worse. > > > File checkins could simply be a file upload, or a mime encoded fetch > request, or an email message, or an ftp drop, or an scp copy, or an rsync > push... > > file checkins right now are cvs checkins, and I guess that will stay for > some time. > > cheers > simon > > -- > Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ > Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / > Party Enjoy Relax | http://dragonflybsd.org Against HTML \ > Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: dd vs. truncate for creating vkernel root images
Forgot to copy to [EMAIL PROTECTED] On 4/12/07, Nuno Antunes <[EMAIL PROTECTED]> wrote: On 4/12/07, Nuno Antunes <[EMAIL PROTECTED]> wrote: > On 4/12/07, Justin C. Sherrill <[EMAIL PROTECTED]> wrote: > > On Wed, April 11, 2007 6:00 pm, Nuno Antunes wrote: > > > Hi all, > > > > > > Is there any advantage in using > > > 'dd if=/dev/zero of=/var/vkernel/rootimg.01 bs=1m count=2048' > > > over the much quicker > > > 'truncate -s 2G /var/vkernel/rootimg.01' > > > other than getting a root image filled with zeros? > > > > Have you tried it? What happened? > > > > > > Yes I have, and it works. Vkernels can use a root image created this > way. So does it mean that the file will grow on demand (up to the > established size, of course)? > > Thanks, > Nuno > Here are my image sizes: whitewidow# ll -h /var/vkernel/devel.rootimg.01 -rw-rw-r-- 1 root wheel 512M Apr 12 00:32 /var/vkernel/devel.rootimg.01 whitewidow# du -sh /var/vkernel/devel.rootimg.01 339M/var/vkernel/devel.rootimg.01 And inside the vkernel: # df -h Filesystem Size Used Avail Capacity Mounted on /dev/vkd0a 496M 186M 270M41%/ Cheers, Nuno
Re: dd vs. truncate for creating vkernel root images
On 4/12/07, Justin C. Sherrill <[EMAIL PROTECTED]> wrote: On Wed, April 11, 2007 6:00 pm, Nuno Antunes wrote: > Hi all, > > Is there any advantage in using > 'dd if=/dev/zero of=/var/vkernel/rootimg.01 bs=1m count=2048' > over the much quicker > 'truncate -s 2G /var/vkernel/rootimg.01' > other than getting a root image filled with zeros? Have you tried it? What happened? Yes I have, and it works. Vkernels can use a root image created this way. So does it mean that the file will grow on demand (up to the established size, of course)? Thanks, Nuno
Re: dd vs. truncate for creating vkernel root images
On Wed, April 11, 2007 6:00 pm, Nuno Antunes wrote: > Hi all, > > Is there any advantage in using > 'dd if=/dev/zero of=/var/vkernel/rootimg.01 bs=1m count=2048' > over the much quicker > 'truncate -s 2G /var/vkernel/rootimg.01' > other than getting a root image filled with zeros? Have you tried it? What happened?
Re: dd vs. truncate for creating vkernel root images
Chris Turner wrote: > so it depends on your preference if you want to pre-allocate or > defer allocation. although I just remembered the 'skip' argument to 'dd' does the same..
Re: modular-xorg
On Wed, April 11, 2007 1:13 pm, Ezra Drummond wrote: > Hi Guys, does anyone got modular-xorg working? I compile with > "X11_TYPE=modular" in /usr/pkg/etc/mk.conf. After setting up > xorg (Xorg -configure) and type # startx i got this error, "command > not found" so i type # startkde and got this error "cannot connect > to xserver" so i guess modular-xorg-client is missing. Any suggestion, > and thanks. I think you just need 'modular-xorg-drivers': http://pkgsrc.se/meta-pkgs/modular-xorg-drivers I haven't tried this myself yet.
Re: dd vs. truncate for creating vkernel root images
Nuno Antunes wrote: > Hi all, > > Is there any advantage in using > 'dd if=/dev/zero of=/var/vkernel/rootimg.01 bs=1m count=2048' > over the much quicker > 'truncate -s 2G /var/vkernel/rootimg.01' > other than getting a root image filled with zeros? not sure if the 'filled with zeros' counts as the same thing, but the former will pre-allocate the storage whereas the latter will not: $ truncate -s 100M ./foocate $ dd if=/dev/zero of=./ddcate bs=1m count=100 $ ls -l *cate -rw-r--r-- 1 foonicator staff 104857600 Apr 11 19:26 ddcate -rw-r--r-- 1 foonicator staff 104857600 Apr 11 19:25 foocate $ du -sk *cate 102448 ddcate 48 foocate so it depends on your preference if you want to pre-allocate or defer allocation.
Re: comparing cvsup vs. rsync
Nigel Weeks wrote: Just having an idea about this...are there any files in the source tree that exceed 32kbytes? What if a database solution were created to: Contain every version of every file of every branch in a nicely indexed database table The md5/sha256 of each entry mentioned above 512 byte chunks of each file mentioned above in a nicely indexed table The md5/sha256 of every 512 bytes of the above mentioned file. uh-ah. i guess that's for checkout, but still it seems very wrong. I mean, really. Uh, I can't stop shuddering. I just hope you are not serious :) and the database will be really huge... actually, it sounds like git, just worse. File checkins could simply be a file upload, or a mime encoded fetch request, or an email message, or an ftp drop, or an scp copy, or an rsync push... file checkins right now are cvs checkins, and I guess that will stay for some time. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
RE: comparing cvsup vs. rsync
Just having an idea about this...are there any files in the source tree that exceed 32kbytes? What if a database solution were created to: Contain every version of every file of every branch in a nicely indexed database table The md5/sha256 of each entry mentioned above 512 byte chunks of each file mentioned above in a nicely indexed table The md5/sha256 of every 512 bytes of the above mentioned file. Then, a small client could be written to: Check for the existence of a later version of a file. Calculate the checksum of the local file, and fetch the checksum of the file in the repository database. If the checksums differ, then calculate the checksums for each 512 bytes of the local file, and fetch the differing sections, and cat then back together. You could then do a full sync with the programs find, awk, fetch, and cat. I build file repositories with version control, so the server side's easy. File checkins could simply be a file upload, or a mime encoded fetch request, or an email message, or an ftp drop, or an scp copy, or an rsync push... I have a FreeBSD machine that could be used for prototyping... Nigel Weeks Tech Support and Systems Developer Rural Press Tasmania The Examiner Newspaper Ph. 03 6336 7234 Mob. 0408 133 738 Email. [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:users- > [EMAIL PROTECTED] On Behalf Of Simon 'corecode' Schubert > Sent: Wednesday, 11 April 2007 8:29 PM > To: users@crater.dragonflybsd.org > Subject: Re: comparing cvsup vs. rsync > > walt wrote: > > Linus avoided rsync in favor of http in 'git' because he thinks > > rsync is inherently unreliable. I have *no* idea if he is right or > > wrong in his opinions, but I figure you guys will favor me with your > > own opinions on the subject. > > Possibly for transferring the git objects. They never change, so rsync is > not efficient. RCS files do change, so just transferring deltas saves a > lot. Additionally, the http transport in git is quite dumb and needs a > pre-created file to help the download. > > cheers > simon > > -- > Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ > Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / > Party Enjoy Relax | http://dragonflybsd.org Against HTML \ > Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
modular-xorg
Hi Guys, does anyone got modular-xorg working? I compile with "X11_TYPE=modular" in /usr/pkg/etc/mk.conf. After setting up xorg (Xorg -configure) and type # startx i got this error, "command not found" so i type # startkde and got this error "cannot connect to xserver" so i guess modular-xorg-client is missing. Any suggestion, and thanks.
dd vs. truncate for creating vkernel root images
Hi all, Is there any advantage in using 'dd if=/dev/zero of=/var/vkernel/rootimg.01 bs=1m count=2048' over the much quicker 'truncate -s 2G /var/vkernel/rootimg.01' other than getting a root image filled with zeros? Thanks, Nuno
BGE NIC not detected
Any hope/plans for getting support for the Broadcom 5780? It reports ASIC revision 8 which doesn't seem to be supported David ** See what's free at http://www.aol.com.
Re: Computer-app. crashes after accessing webdav disk
On Wed, April 11, 2007 2:55 pm, Huub wrote: >> >> As corecode said, it's possible something in Gnome, which makes it hard >> to >> tell. You may want to bring to the Gnome developers. > > Hm. As I said in my post, on the other BSD flavours I have no problem. I > run gnome on all of them. Which makes it for me hard to believe it's a > (general) gnome problem. Well, no, not a general Gnome problem, but it's probably something in the Gnome code (since cadaver works) that is incompatible specifically with DragonFly. It could be something as simple as it's something that works one way with FreeBSD and has changed in DragonFly, but Gnome uses the old behavior. I don't think there's any developers for DragonFly looking at Gnome code right now, so it may be easier to ask Gnome devs, since they already are dealing with the code. Someone here can prove me wrong, of course.
Re: Computer-app. crashes after accessing webdav disk
As corecode said, it's possible something in Gnome, which makes it hard to tell. You may want to bring to the Gnome developers. Hm. As I said in my post, on the other BSD flavours I have no problem. I run gnome on all of them. Which makes it for me hard to believe it's a (general) gnome problem. Another way to gather data is to see if the problem happens with non-Gnome components - for instance, if you use cadaver at the command line to access a webdav location, does it also have problems? If I use cadaver, I have no problem at all.
Re: Computer-app. crashes after accessing webdav disk
On Wed, April 11, 2007 7:21 am, Huub wrote: > Hi, > > After finding out I can access webdav through the Computer icon/app. on > the desktop, I created the network-disk on FreeBSD 6.2, NetBSD > 3.1/amd64, NetBSD 3.1/386 and DragonFlyBSD 1.9. All except the latter > work well. When I access the webdav disk the first time, it's ok. But > after the second time, I get the message "The application Computer has > crashed". Next, it hangs on collecting crash-information. The only thing > I can do then, is leaving X with ctl-alt-backspace and reboot. If I > leave X and start X again without rebooting, I don't get the desktop. > BTW, I use gnome. > > Can somebody tell me what's wrong please? As corecode said, it's possible something in Gnome, which makes it hard to tell. You may want to bring to the Gnome developers. Another way to gather data is to see if the problem happens with non-Gnome components - for instance, if you use cadaver at the command line to access a webdav location, does it also have problems?
Re: Computer-app. crashes after accessing webdav disk
Huub wrote: Can somebody tell me what's wrong please? i guess gnome is breaking somewhere. quite probably not dragonfly's fault. after crashing, gnome possibly leaves some traces of its breakage around (stale processes) and thus fails to launch nautilus (or how it is called today) to show the desktop. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Computer-app. crashes after accessing webdav disk
Hi, After finding out I can access webdav through the Computer icon/app. on the desktop, I created the network-disk on FreeBSD 6.2, NetBSD 3.1/amd64, NetBSD 3.1/386 and DragonFlyBSD 1.9. All except the latter work well. When I access the webdav disk the first time, it's ok. But after the second time, I get the message "The application Computer has crashed". Next, it hangs on collecting crash-information. The only thing I can do then, is leaving X with ctl-alt-backspace and reboot. If I leave X and start X again without rebooting, I don't get the desktop. BTW, I use gnome. Can somebody tell me what's wrong please? Thanks, Huub
Re: vfwscanf() and friends
Hasso Tepper wrote: Looking at headers it seems to me that libstdc++ assumes that if vfwscanf() and friends are in libc, they are there unconditionally which isn't the case - they are visible in /usr/include/wchar.h if source defines _POSIX_C_SOURCE at least 200112 (C99). I think we can declare them in any case. After all, we're all moving to C99, right? So, question - how to fix it and where? In libstdc++? But this will still cause problems to anyone not using compiler provided by system. In our /usr/include/wchar.h? Where do other systems handle this? Using a non-system compiler is not feasible to support anyways... Anybody wanna add thread support to tinycc? cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: comparing cvsup vs. rsync
walt wrote: Linus avoided rsync in favor of http in 'git' because he thinks rsync is inherently unreliable. I have *no* idea if he is right or wrong in his opinions, but I figure you guys will favor me with your own opinions on the subject. Possibly for transferring the git objects. They never change, so rsync is not efficient. RCS files do change, so just transferring deltas saves a lot. Additionally, the http transport in git is quite dumb and needs a pre-created file to help the download. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: vfwscanf() and friends
On Wed, Apr 11, 2007 at 12:43:51PM +0300, Hasso Tepper wrote: > I've found the problem that is probably a bug in libstdc++ headers, > but as other OSes seem to workaround it, I'm not sure how and where > we should fix it. Well, to make a long answer short: don't do it. Messing with C interfaces doesn't play well with C++, because the standards are overlapping. I don't think fixing it is really worth the trouble as it would silently discarding part of the user choice, which is worse. Joerg
Re: vfwscanf() and friends
FYI, seems to be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012 regards, -- Hasso Tepper Elion Enterprises Ltd. [AS3249] IP & Data Networking Expert
Re: comparing cvsup vs. rsync
On Wednesday 11 April 2007 05:14:43 walt wrote: > Yes, I'm way off topic here, and I apologize -- but I've seen your > posts in the 'git' mail-list and you've experimented with Hg, so I > know you have your own opinions on version control systems. > > Linus avoided rsync in favor of http in 'git' because he thinks > rsync is inherently unreliable. I have *no* idea if he is right or > wrong in his opinions, but I figure you guys will favor me with your > own opinions on the subject. Also, http is easier to push through corporate firewalls :) Cheers, Emiel
vfwscanf() and friends
I've found the problem that is probably a bug in libstdc++ headers,
but as other OSes seem to workaround it, I'm not sure how and where
we should fix it.
Small testcase (it's C++, fyi ;):
#define _POSIX_C_SOURCE 199309L
#include
int main() { return 0; }
It doesn't compile in DragonFlyBSD, but compiles in Linux and some
random BSD's I have here. Same problem appears with sources defining
_XOPEN_SOURCE 500 and including cwchar header. Both cases should be
perfectly legal AFAICS.
Looking at headers it seems to me that libstdc++ assumes that if
vfwscanf() and friends are in libc, they are there unconditionally
which isn't the case - they are visible in /usr/include/wchar.h if
source defines _POSIX_C_SOURCE at least 200112 (C99).
So, question - how to fix it and where? In libstdc++? But this will
still cause problems to anyone not using compiler provided by system.
In our /usr/include/wchar.h?
regards,
--
Hasso Tepper
