Re: python3.3 build failure on kfreebsd and the hurd

2012-11-06 Thread Pino Toscano
Hi,

Alle martedì 6 novembre 2012, Matthias Klose ha scritto:
> python3.3 build failure on kfreebsd and the hurd, please could
> somebody have a look and propose a patch?

This was reported upstream months ago:
  http://bugs.python.org/issue13669
I just left a comment with a possible solution (although no patch for 
now).

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.


Re: python3.3 build failure on kfreebsd and the hurd

2012-11-06 Thread Steven Chamberlain
Hi,

I'd say the test at Modules/posixmodule.c:114 is wrong:

> #if defined(HAVE_SYS_XATTR_H) && defined(__GLIBC__)
> #define USE_XATTRS
> #endif

Because GLIBC doesn't imply a working xattr interface (traditionally a
Linux thing?).  There seem to be implementations only for Linux,
GNU/Hurd and as part of NetBSD Linux compatibility layer.

On GNU/kFreeBSD there is only a stub for setxattr, returning -ENOSYS
(not implemented).  Hence there is no XATTR_SIZE_MAX defined either.

For now, maybe it would be better as:

> #if defined(HAVE_SYS_XATTR_H) && (defined(__linux__) || defined(__GNU__))


The other problem is that GNU/Hurd doesn't enforce a maximum size and so
still doesn't define XATTR_SIZE_MAX;  on NetBSD they define it like this
for compatibility it seems:

http://fxr.watson.org/fxr/source/sys/xattr.h?v=NETBSD5#L52
> #define XATTR_SIZE_MAX  65536   /* NetBSD does not enforce this */

So, GNU/Hurd could maybe add something like that if it helps with
porting;  or better still, upstream could do as Pino suggested in
http://bugs.python.org/issue13669

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50997244.60...@pyro.eu.org



Re: python3.3 build failure on kfreebsd and the hurd

2012-11-06 Thread Pino Toscano
Hi,

Alle martedì 6 novembre 2012, Steven Chamberlain ha scritto:
> I'd say the test at Modules/posixmodule.c:114 is wrong:
> > #if defined(HAVE_SYS_XATTR_H) && defined(__GLIBC__)
> > #define USE_XATTRS
> > #endif
> 
> Because GLIBC doesn't imply a working xattr interface (traditionally
> a Linux thing?).  There seem to be implementations only for Linux,
> GNU/Hurd and as part of NetBSD Linux compatibility layer.
> 
> On GNU/kFreeBSD there is only a stub for setxattr, returning -ENOSYS
> (not implemented).

Sure, and that's perfectly fine: those functions will return -1 with 
errno ENOSYS, and the caller will check that and determine there is no 
support for extended attributes.
The fact that glibc/kfreebsd *now* does not implement these functions 
should not reflect on limiting features on userland, especially when 
userland can already know *at runtime* when such features are not 
available. If somebody implement them, say tomorrow, on glibc/kfreebsd, 
the python code will just work, with no need for further changes.

> Hence there is no XATTR_SIZE_MAX defined either.

There is no relation on making the xattr functions working and defining 
this. And actually, it would be even better if you do *not* define it, 
since assuming a limit a compile time on something that can change at 
runtime is simply pointless, or even harmful.

> For now, maybe it would be better as:
> > #if defined(HAVE_SYS_XATTR_H) && (defined(__linux__) ||
> > defined(__GNU__))

Please no, the current check:
  #if defined(HAVE_SYS_XATTR_H) && defined(__GLIBC__)
is perfectly fine.

> The other problem is that GNU/Hurd doesn't enforce a maximum size and
> so still doesn't define XATTR_SIZE_MAX;  on NetBSD they define it
> like this for compatibility it seems:
> 
> http://fxr.watson.org/fxr/source/sys/xattr.h?v=NETBSD5#L52
> 
> > #define XATTR_SIZE_MAX  65536   /* NetBSD does not enforce
> > this */
> 
> So, GNU/Hurd could maybe add something like that if it helps with
> porting;

You still seem to assume there must be some magic MAX constant giving 
you some upper limit...
Consider that Hurd does not provide PATH_MAX, I personally think it 
would be a mistake providing the two XATTR_*_MAX defines just for the 
sake of applications not actually checking their return values.

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.


Re: python3.3 build failure on kfreebsd and the hurd

2012-12-30 Thread Christoph Egger
Hi folks!

Matthias Klose  writes:
> python3.3 build failure on kfreebsd and the hurd, please could
> somebody have a look and propose a patch?

Seems to be fixed right now \o/

  Christoph


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcbjgeh1@mitoraj.siccegge.de