aegis FTBFS (really aegis this time)

2006-02-21 Thread Barry deFreese
OK, in looking at the aegis FTBFS from the buildd it appears that we do not 
define RLIMIT_AS (Address Space Limit).


I am cross-posting this bug-hurd in case this is a missing implementation. 
On my Ubuntu GNU/Linux box, RLIMIT_AS is defined as 9.


However, even after the usual #ifndef "magic" the package fails on several 
of the tests and therefore still does not build.


Thanks,

Barry deFreese (aka bddebian) 




___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd


Multicast support with Linux Ethernet drivers

2006-02-21 Thread Richard Braun
Hello,

I'm currently developing a packet filter, and I noticed that GNU Mach
doesn't catch Ethernet multicast packets (though broadcast packets are
correctly handled). I temporarily set mc_filter[0] and mc_filter[1] to
0x (as it is done for promiscuous mode) in driver rtl8139, and
then multicast works. My problem is that I'd like to know if there is
a generic solution to enable multicast support by default on all
drivers which support it.

-- 
Richard Braun


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd


Re: new version of glibc xattr patch

2006-02-21 Thread Roland McGrath
Thanks for looking at this.  I've committed the code on the glibc trunk
now.  If there are further problems please file a glibc bugzilla report
in the "hurd" componenet.

> When getxattr gets called with VALUE as NULL and *SIZE as 0 (to
> determine the length of the xattr value), SIZE will be smaller than
> BUFSZ and subsequently the callee gets 0 returned and believes no xattrs
> are present.
> 
> We propose this instead:
> 
>   if (value != NULL && bufsz > *size)
> return ERANGE;
>   *size = bufsz;

That fix leaks in the ERANGE case.  I did a different fix.
Please verify it.

> As was pointed out before, those should return 0 on success, and not
> SIZE.

Fixed.  

> Our tests seemed to have shown that most (all?) passive translators do
> not have the S_IPTRANS stat bit set, thus not reporting the
> gnu.translator xattr through listxattr.  Are we missing something here?

I doubt this is true.  If it is, it's a server-side bug.  Note that
S_IPTRANS and the gnu.translator xattr are found on nodes opened with
O_NOTRANS.  They will more or less never be seen by the file name-based
calls, only by f*xattr on an fd opened using O_NOTRANS.  


Thanks,
Roland



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd