Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Nathan Scott]

----- "Christoph Hellwig" <hch@infradead.org> wrote:

> On Tue, Jun 09, 2009 at 10:03:28AM +1000, Nathan Scott wrote:
> > 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.

-- 
Nathan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Petr Salinger]

Hello.

>> 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?

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:
--- attr-2.4.43.orig/getfattr/getfattr.c
+++ attr-2.4.43/getfattr/getfattr.c
@@ -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:
--- attr-2.4.43.orig/setfattr/setfattr.c
+++ attr-2.4.43/setfattr/setfattr.c
@@ -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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Christoph Hellwig]

On Tue, Jun 09, 2009 at 01:35:58PM +0200, Petr Salinger wrote:
> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Aurelien Jarno]

On Tue, Jun 09, 2009 at 08:10:42AM -0400, Christoph Hellwig wrote:
> On Tue, Jun 09, 2009 at 01:35:58PM +0200, Petr Salinger wrote:
> > 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.
> 

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.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Christoph Hellwig]

On Sun, Jun 14, 2009 at 06:35:17PM +0200, Aurelien Jarno wrote:
> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Aurelien Jarno]

On Sun, Jun 14, 2009 at 04:33:09PM -0400, Christoph Hellwig wrote:
> On Sun, Jun 14, 2009 at 06:35:17PM +0200, Aurelien Jarno wrote:
> > 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?

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Christoph Hellwig]

On Sun, Jun 14, 2009 at 10:56:28PM +0200, Aurelien Jarno wrote:
> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Aurelien Jarno]

On Mon, Jun 15, 2009 at 12:26:12PM +0200, Petr Salinger wrote:
>> On Sun, Jun 14, 2009 at 10:56:28PM +0200, Aurelien Jarno wrote:
>>> 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 ?

Fully agreed.

Please find below the __linux_ version of the patch.

--- attr-2.4.43.orig/getfattr/getfattr.c
+++ attr-2.4.43/getfattr/getfattr.c
@@ -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:
--- attr-2.4.43.orig/setfattr/setfattr.c
+++ attr-2.4.43/setfattr/setfattr.c
@@ -66,8 +66,10 @@
 
 const char *strerror_ea(int err)
 {
+#ifdef __linux__
 	if (err == ENODATA)
 		return _("No such attribute");
+#endif
 	return strerror(err);
 }
 
-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Petr Salinger]

> On Sun, Jun 14, 2009 at 10:56:28PM +0200, Aurelien Jarno wrote:
>> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD

[Andreas Gruenbacher]

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.

> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs