[Top] [All Lists]

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

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: Bug#531950: attr: FTBFS on GNU/kFreeBSD
From: Petr Salinger <Petr.Salinger@xxxxxxxxx>
Date: Mon, 15 Jun 2009 12:26:12 +0200 (CEST)
Cc: Aurelien Jarno <aurelien@xxxxxxxxxxx>, 531950-quiet@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, Nathan Scott <nscott@xxxxxxxxxx>
In-reply-to: <20090615094244.GA4793@xxxxxxxxxxxxx>
References: <364917872.6081221244543493694.JavaMail.root@xxxxxxxxxxxxxxxxxx> <Pine.LNX.4.62.0906091328270.31325@xxxxxxxxxxxxxxxx> <20090609121042.GA28666@xxxxxxxxxxxxx> <20090614163517.GA19259@xxxxxxxxxxxxxxxxx> <20090614203309.GA1929@xxxxxxxxxxxxx> <20090614205628.GB25535@xxxxxxxxxxxxxxxx> <20090615094244.GA4793@xxxxxxxxxxxxx>
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

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.




<Prev in Thread] Current Thread [Next in Thread>