Re: gnumach 1.3 + gcc 3.3
Eric Olinger wrote: On Wed, 25 Feb 2004 13:59:47 +0100 Paolo Dongilli <[EMAIL PROTECTED]> wrote: I checked out the gnumach-1-branch but there are still problems with the latest version of autoconf 2.59 :( I ran into the same problem when making the ebuild for the gnumach 1 branch. Check out this patch on sv.g.o which fixes the keyboard buffer and more importantly fixes autoconf support for the 2.5x branch: http://sv.gnu.org/patch/?func=detailitem&item_id=2507 Finally! I applied this patch and compilation of gnumach-1-branch succeeded. I booted with the new kernel and it works fine! Thanks a lot! Paolo. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: gnumach 1.3 + gcc 3.3
Eric Olinger wrote: On Wed, 25 Feb 2004 13:59:47 +0100 Paolo Dongilli <[EMAIL PROTECTED]> wrote: I checked out the gnumach-1-branch but there are still problems with the latest version of autoconf 2.59 :( I ran into the same problem when making the ebuild for the gnumach 1 branch. Check out this patch on sv.g.o which fixes the keyboard buffer and more importantly fixes autoconf support for the 2.5x branch: http://sv.gnu.org/patch/?func=detailitem&item_id=2507 Finally! I applied this patch and compilation of gnumach-1-branch succeeded. I booted with the new kernel and it works fine! Thanks a lot! Paolo. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface
On Thu, Feb 12, 2004 at 11:19:42PM -0800, Roland McGrath wrote:
> Hi folks. I've just whipped up the following patch, which is against the
> current Linux 2.6 source tree. This provides a means to fetch and store
> the extra data stored in nodes on ext2 filesystems with "creator_os" set to
> EXT2_OS_HURD, i.e. from `mke2fs -o hurd' or filesystems created natively on
> the Hurd.
Just curious, would it not make sense to have this for ext3, too? After
all, one can mount ext3 filesystems as ext2 on GNU/Hurd (AFAIK), so
extracting passive translators on a (incidently) ext3 file system for
later use on GNU/Hurd might make sense (although I admit this might not
be a common operation). Linux-2.6 has separate config options for
extended attributes for ext2 and ext3, so I assume the latter is not
supported right now. Is there a fundamental problem with ext3, or did
you just not do it for ext2?
> It also makes it possible to back up and restore a Hurdish ext2
> filesystem from a GNU/Linux system, using any tools that understand
> the extended attributes. (Off hand the only such thing I'm aware of
> is `star', which I have not tried using myself.)
I tried using star, but I get errors when I try to extract /gnu/servers.
I am not sure whether this is expected to work at all, though, as I get
EOPNOTSUPP.
I used 'star artype=exustar -xattr -c -v -f servers.tar /gnu/servers' as
command-line for tarring up the translators and 'star artype=exustar
-xattr -x -v -f servers.tar' for extracting. Tarring up seems to work
fine, but subsequent extracting yields error messages like this:
star: Operation not supported. Cannot setxattr for 'gnu/servers/exec'.
strace:
[...]
lstat64("gnu/servers/exec", 0xbfffd440) = -1 ENOENT (No such file or directory)
write(1, "x gnu/servers/exec 0 bytes, 0 ta"..., 42) = 42
open("gnu/servers/exec", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
fcntl64(4, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE)
fstat64(4, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40975000
_llseek(4, 0, [0], SEEK_CUR)= 0
munmap(0x40975000, 4096)= 0
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_GETFD) = 0
fsync(4)= 0
close(4)= 0
utimes("gnu/servers/exec", {1057965161, 0}) = 0
chmod("gnu/servers/exec", 0644) = 0
setxattr("gnu/servers/exec", "gnu.translator", 0x808c110, 11, ) = -1 EOPNOTSUPP
(Operation not supported)
write(2, "star: Operation not supported. C"..., 71star: Operation not supported.
Cannot setxattr for 'gnu/servers/exec'.
) = 71
utimes("gnu/servers/exec", {1057965161, 0}) = 0
[...]
I then tried to debug star (you have to add '-g' to a read-only file in
RULES/foo-linux-cc, d'oh) and libattr, and it seems either the functions
arguments get corrupted when calling setxattr() or my mundane gdb skills
are at their limit here.
This is when tarring up the translator:
Breakpoint 7, get_xattr (info=0xbfffd4a0) at xattr.c:57
57 {
66 free_xattr(&static_xattr);
$65 = {f_tcb = 0x40171a00, f_name = 0xbfffd4a0 "/gnu/servers/exec",
f_namelen = 19, f_lname = 0xbfffa420 "", f_lnamelen = 0, f_uname = 0x0,
f_umaxlen = 0, f_gname = 0x0, f_gmaxlen = 0, f_dir = 0x808c100 "",
f_dirinos = 0x0, f_dirlen = 20, f_dirents = 4, f_dev = 782, f_ino = 57353,
f_nlink = 1, f_mode = 420, f_uid = 0, f_gid = 0, f_size = 0, f_rsize = 0,
f_contoffset = 137573730948, f_flags = 0, f_xflags = 7, f_xftype = 1,
f_rxftype = 1, f_filetype = 1, f_typeflag = 0 '\0', f_type = 32768,
f_rdev = 0, f_rdevmaj = 0, f_rdevmin = 0, f_atime = 1057965161, f_ansec = 0,
f_mtime = 1057965161, f_mnsec = 0, f_ctime = 1057965535, f_cnsec = 0,
f_fflags = 0, f_acl_access = 0xb7f0 "",
f_acl_default = 0x40171000 "././@PaxHeader", f_xattr = 0x808c0f0}
[...]
$74 = {name = 0x808c0f0 "gnu.translator", value = 0x808c040, value_len = 11}
[...]
$79 = 0x808c040 "/hurd/exec"
And this is when extracting it:
Breakpoint 3, set_xattr (info=0x1) at xattr.c:164
164 {
168 if (info->f_xattr == NULL)
$134 = {f_tcb = 0xb560, f_name = 0xbfffe551 "gnu/servers/exec",
f_namelen = 0, f_lname = 0xbfffd540 "", f_lnamelen = 0,
f_uname = 0xb669 "root", f_umaxlen = 32, f_gname = 0xb689 "nobody",
f_gmaxlen = 32, f_dir = 0x0, f_dirinos = 0x0, f_dirlen = 0, f_dirents = 0,
f_dev = 0, f_ino = 0, f_nlink = 0, f_mode = 420, f_uid = 0, f_gid = 0,
f_size = 0, f_rsize = 0, f_contoffset = 0, f_flags = 0, f_xflags = 524295,
f_xftype = 1, f_rxftype = 1, f_filetype = 1, f_typeflag = 48 '0',
f_type = 32768, f_rdev = 0, f_rdevmaj = 0, f_rdevmin = 0,
f_atime = 1057965161, f_ansec = 0, f_mtime = 1057965161, f_mnsec = 0,
f_ctime = 1057965535, f_cnsec = 0, f_fflags = 0, f_acl_access = 0x0,
f_acl_default = 0x0, f_xattr = 0x808c0b0}
$135 = {name = 0x808c0d0 "gnu.translator", value =
Re: [Linux 2.6 PATCH] support for Hurd ext2 format extensions
On Fri, Feb 20, 2004 at 02:46:36PM -0800, Roland McGrath wrote: > This is a cleaned-up and polished version of the Linux 2.6 patch to > support Hurd ext2 format extensions via the xattr interfaces. To faciliate testing (by Debian users at least), I've created (or let's say, hacked together) both a kernel-patch package and a kernel-image package including Roland's patch. They are both available at http://people.debian.org/~mbanck/xattr-hurd/ The Debian packages are called kernel-patch-xattr-hurd_20040220-1_all.deb and kernel-image-2.6.2-1-686_2.6.2-3_i386.deb. The kernel-patch is reportedly quite handy when building packages with make-kpkg (I've never did this myseld), while the kernel-image is just a drop-in replacement of the current stock Debian kernel for i686 (it has the second do_mremap() security fix from 2.6.3 included). I guess I could build images for other ia32-based kernels on demand. I could not figure out how to reliably add a '-xattr-hurd' to the package/file/directory names, so that one could install both this kernel-image and the original verson in parallel, so I did not do this for now. I'm typing this mail running the kernel-image. Enjoy, Michael ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Доставка букетов по Москве, С-Петербургу, Милану!
DOSTAVKABUKETOV ЦВЕТЫ БУКЕТЫ ПОДАРОЧНЫЕ КОРЗИНЫИзготовление на заказ и доставка по Москве,С-Петербургу, МилануПраздничное оформление ЦВЕТАМИ и ШАРАМИНаше предложение к 8 Марта Корзина "Тюльпания"Цена: 2100 руб Корзина "Мозаика"Цена: 3500 руб Туба с хризантемамиЦена: 490 руб Туба с розамиЦена: 590 руб Сделайте заказ заранее и получите выгодную цену!Подробности вы можете узнать, связавшись с нами по телефонам(095) 772-5022, (095) 514-8791 <<0.jpg>><<1.jpg>><<2.jpg>><<3.jpg>><<4.jpg>>___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd build errors
Eric Olinger <[EMAIL PROTECTED]> writes: > I've been working on building the CVS Hurd so I can work out an ebuild for it > and I've ran into a few problems. First is when the build system is making libdiskfs > it can't find version.h for building the opts-version, which it should be looking > for > ../version.h like libcons does. I don't know the build system well enough to look > into why its doing that. Thanks for reporting this. Someone reported this on help-hurd as well. I recall I had a problem with this a while ago, but I do not remember how I fixed this and if this was the right way. I will have a look at it. -- Marco ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface
> Just curious, would it not make sense to have this for ext3, too? After
> all, one can mount ext3 filesystems as ext2 on GNU/Hurd (AFAIK),
As I understand it, it is true that an ext3 filesystem with its journal
files fully replayed or whatnot that constitutes "fully clean" state, is a
valid ext2 filesystem. So to that extent, yes. However, note that this
code is specifically for ext2 filesystems with "creator os" set to "hurd".
This functionality is of no use whatsoever on your random ext[23]
filesystems created for use with GNU/Linux--those formats as usually
created (i.e. without `mke2fs -o hurd') do represent the Hurd-specific
information and using such filesystems on the Hurd will not give you the
ability to record passive translator or author information.
Hence, I don't see it as useful to put this support into the Linux ext3
code as well. Furthermore, that code is written so as to duplicate tons of
ext2 code and data structures identically with all the 2s changed to 3s.
While I endeavor to contribute code in the form desired by its maintainers
and take existing practice as evidence of what that is, this pointless
duplication is not something I felt like engaging in. It is most certainly
counterproductive while the code is still being tested and debugged.
> I tried using star, but I get errors when I try to extract /gnu/servers.
> I am not sure whether this is expected to work at all, though, as I get
> EOPNOTSUPP.
Did you compile with CONFIG_EXT2_FS_XATTR_HURD=y?
Is the filesystem in question an ext2 filesystem with creator `hurd'?
If you created it on GNU/Linux and didn't use `mke2fs -o hurd', then the
answer is no.
> strace:
> [...]
> setxattr("gnu/servers/exec", "gnu.translator", 0x808c110, 11, ) = -1 EOPNOTSUPP
> (Operation not supported)
> [...]
> I then tried to debug star [...]
The strace output gave you all the information you need to know.
star did the right thing, and the kernel said no dice.
> Sorry if I might have totally missed the point,
Possible. If there is not a FAQ entry around for "Is your ext2 filesystem
format able to passive translators?", there should be.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Start making profits in half an hour
Title: 231.88.96.140 In my book I will show you how to make a decent income immediately by creating effective Google AdWords campaigns that promote other companies and their products/services. You will be paid each time your ad generates a sale or sign up! I don't want any more emails ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Hurd build errors
I've been working on building the CVS Hurd so I can work out an ebuild for it and I've ran into a few problems. First is when the build system is making libdiskfs it can't find version.h for building the opts-version, which it should be looking for ../version.h like libcons does. I don't know the build system well enough to look into why its doing that. After I symlinked version.h to the real one (quick hack), it died again looking for libc-symbols.h? Isn't this or shouldn't this be part of libc-dev? Is it in another package that I'm missing? -- Eric Olinger Give a man a password, he'll log in for a day. Teach him to code, and he will hack his way in... pgp0.pgp Description: PGP signature ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
wrong references in README
Hi! Hi, I think [srchurd]/README contain wrong bug report address. README refer mail lists [EMAIL PROTECTED] and [EMAIL PROTECTED] If I correct understand, for now there are [EMAIL PROTECTED] and [EMAIL PROTECTED] mail lists used for bug repors. Udachi, e ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
warning while running [libc]/configure
Hi! While running [libc]/configure script $ mkdir build;cd build $ ../configure It prints warning message: configure: WARNING: --prefix= (empty) is requed for GNU/Hurd to work normaly. I wish to install libc to the root. So I try $ ../configure --prefix=/ Warning message printed again, --prefix="/" follow to same results. Why setting --prefix does not avoid warning message? e ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: EFLLSDAY, of silk scraps
Free Cable%RND_SYB TV forklift mycobacteria angel sulk lethal methylene domesday safekeeping hutchison persona pocono mitigate rectitude bertram grin margin disney disparage bandpass lesion bluejacket bathe brady desiderata antares apothegm depart itinerant marriott dogfish stoppage bundle doctoral counterintuitive balcony cox cud sporadic carnation nubile polaris physik apport scull shirk archangel aggregate chadwick reservation ajax aeolus codeposit criss catalina dipole vicious aspidistra envelope boatyard trodden dementia boisterous binuclear edwin acrylic morristown denebola handout pogrom betrayal 3003hosting.com 3004hosting.com 3005hosting.comfiter.jpg fiter1.jpg fiter2.jpg fiter3.jpg ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
