Bug#531950: attr: FTBFS on GNU/kFreeBSD
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · ----- "Christoph Hellwig
Quoted 2 lines · Nathan Scott
Could someone verify and merge this patch? It looks OK to me.
Andreas now takes care ot attr. Btw, the submitter should stop that stupid GNU wanking - errnos are defined by the kernel so it's a FreeBSD issues and has nothing to do with their glibc abuse.
Hmm, I'm not sure what you mean there. AIUI, this code (strerror_ea) is working around Linux's lack of an ENOATTR error code ... and on FreeBSD there really is an ENOATTR (and no ENODATA?) Perhaps a better fix in this case may be to map strerror_ea directly to strerror for all platforms except Linux?
const char *strerror_ea(int err)
{
- if (err == ENODATA)
+ if (err == ENOATTR)
return _("No such attribute");
return strerror(err);}
BTW, which git tree is the canonical acl/attr tree now Andreas? Is it one of the kernel.org ones (which path?)? thanks.
cheers.
Signature · 6 lines
Nathan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Hello.
Quoted 10 lines
Quoted 3 lines
Andreas now takes care ot attr. Btw, the submitter should stop that stupid GNU wanking - errnos are defined by the kernel so it's a FreeBSD issues and has nothing to do with their glibc abuse.
Hmm, I'm not sure what you mean there. AIUI, this code (
strerror_ea) is working around Linux's lack of an ENOATTR error code ... and on FreeBSD there really is an ENOATTR (and no ENODATA?) Perhaps a better fix in this case may be to mapstrerror_eadirectly to strerror for all platforms except Linux?
The problem is that there is no ENODATA errno value defined on GNU/kFreeBSD. The errno values are determined by kernel, they are the same as on plain FreeBSD, used libc implementation does not change it.
Another possibility is to use patch bellow.
Does it looks acceptable for you ?
Thanks
Petr
only in patch2:
unchanged:
getfattr/getfattr.c +2 -0
@@ -93,8 +93,10 @@const char *strerror_ea (int err) { +#ifdef ENODATA if (err ==ENODATA )return _ ("No such attribute" ); +#endif return strerror (err); }
only in patch2:
unchanged:
setfattr/setfattr.c +2 -0
@@ -66,8 +66,10 @@const char *strerror_ea (int err) { +#ifdef ENODATA if (err ==ENODATA )return _ ("No such attribute" ); +#endif return strerror (err); }
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Petr Salinger
The problem is that there is no ENODATA errno value defined on GNU/kFreeBSD. The errno values are determined by kernel, they are the same as on plain FreeBSD, used libc implementation does not change it.
Another possibility is to use patch bellow.
Does it looks acceptable for you ?
This one looks better to me, except that I would really make this an explicit #ifdef __linux__. The lack of a proper ENOATTR is a Linux specific quirck and not related to the presence of non-standard ENODATA. Maybe also add a little comment why we're doing this so people don't get confused by it.
Btw, how does libattr actually work for you on FreeBSD? Last time I checked FreeBSD had slightly different xattr system calls that (just like IRIX) used an integer namespace value instead of the string prefix in Linux.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 15 lines · Christoph Hellwig
Quoted 7 lines · Petr Salinger
The problem is that there is no ENODATA errno value defined on GNU/kFreeBSD. The errno values are determined by kernel, they are the same as on plain FreeBSD, used libc implementation does not change it.
Another possibility is to use patch bellow.
Does it looks acceptable for you ?This one looks better to me, except that I would really make this an explicit #ifdef
__linux__. The lack of a proper ENOATTR is a Linux specific quirck and not related to the presence of non-standard ENODATA. Maybe also add a little comment why we're doing this so people don't get confused by it.
Quoted 5 lines
Btw, how does libattr actually work for you on FreeBSD? Last time I checked FreeBSD had slightly different xattr system calls that (just like IRIX) used an integer namespace value instead of the string prefix in Linux.
When not on Linux, libattr uses the GNU libc functions instead of the system calls. The GNU libc then translates that into FreeBSD syscalls including the integer namespace value.
Signature · 7 lines
Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 3 lines · Aurelien Jarno
When not on Linux, libattr uses the GNU libc functions instead of the system calls. The GNU libc then translates that into FreeBSD syscalls including the integer namespace value.
Maybe you'd be better off not doing a double translation by using the raw syscalls from libattr..
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines · Christoph Hellwig
Quoted 3 lines · Aurelien Jarno
When not on Linux, libattr uses the GNU libc functions instead of the system calls. The GNU libc then translates that into FreeBSD syscalls including the integer namespace value.
Maybe you'd be better off not doing a double translation by using the raw syscalls from libattr..
Would such a patch be accepted more easily than the ENODATA patch?
Signature · 7 lines
Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 1 line · Aurelien Jarno
Would such a patch be accepted more easily than the ENODATA patch?
I don't think it's an except but in addition. Wherever we do a strerror in the attr code we will have to special case ENODATA on Linux and only there. Independent of that I think we would better of using the raw syscalls in platforms already using binary namespaces rather than double translation. Note that this is only applicable for the IRIX-heritage attr_* routines exports by libattr, not the *xattr routines it also exports.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Aurelien Jarno
Quoted 1 line
Would such a patch be accepted more easily than the ENODATA patch?
I don't think it's an except but in addition. Wherever we do a strerror in the attr code we will have to special case ENODATA on Linux and only there. Independent of that I think we would better of using the raw syscalls in platforms already using binary namespaces rather than double translation. Note that this is only applicable for the IRIX-heritage attr_* routines exports by libattr, not the *xattr routines it also exports.
We would really appreciate to have either "#ifdef ENODATA" or "#ifdef __linux__" applied to current debian version of package. The debian maintainer does not want to diverge from (future) upstream, which is quite understandable.
Would be possible to special case ENODATA as 1st step and postpone adding of syscall support later ?
The current situation (unbuildable attr under Bebian) prevents building of many other packages, namely kdelibs (and whole KDE 3.x), kde4libs (and whole KDE 4.x) and gnome-vfs (almost whole GNOME) and even vim editor under Debian GNU/kFreeBSD.
http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=531950
Thanks
Petr
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 11 lines · Petr Salinger
Quoted 10 lines · Aurelien Jarno
Quoted 1 line
Would such a patch be accepted more easily than the ENODATA patch?
I don't think it's an except but in addition. Wherever we do a strerror in the attr code we will have to special case ENODATA on Linux and only there. Independent of that I think we would better of using the raw syscalls in platforms already using binary namespaces rather than double translation. Note that this is only applicable for the IRIX-heritage attr_* routines exports by libattr, not the *xattr routines it also exports.
Quoted 8 lines
We would really appreciate to have either "#ifdef ENODATA" or "#ifdef
__linux__" applied to current debian version of package. The debian maintainer does not want to diverge from (future) upstream, which is quite understandable.Would be possible to special case ENODATA as 1st step and postpone adding of syscall support later ?
Fully agreed.
Please find below the __linux_ version of the patch.
getfattr/getfattr.c +2 -0
@@ -93,8 +93,10 @@const char *strerror_ea (int err) { +#ifdef __linux__if (err ==ENODATA )return _ ("No such attribute" ); +#endif return strerror (err); }
only in patch2:
unchanged:
setfattr/setfattr.c +2 -0
@@ -66,8 +66,10 @@const char *strerror_ea (int err) { +#ifdef __linux__if (err ==ENODATA )return _ ("No such attribute" ); +#endif return strerror (err); }
Signature · 7 lines
Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · On Monday 15 June 2009 12:26:12 Petr Salinger wrote:
We would really appreciate to have either "#ifdef ENODATA" or "#ifdef
__linux__" applied to current debian version of package. The debian maintainer does not want to diverge from (future) upstream, which is quite understandable.Would be possible to special case ENODATA as 1st step and postpone adding of syscall support later ?
Yes, done.
Quoted 4 lines
The current situation (unbuildable attr under Bebian) prevents building of many other packages, namely kdelibs (and whole KDE 3.x), kde4libs (and whole KDE 4.x) and gnome-vfs (almost whole GNOME) and even vim editor under Debian GNU/kFreeBSD.
Thanks,
Andreas
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs