Bugzilla Bug 89852

The attached patch, applied over 6.8.99.3 ebuild (I choosen this as it's a
development version so it could be tested with less problems), ensures that
xorg-x11 is built and installed using gmake and not other makes.
This is done because if make is not gmake, also if gmake is used to launch the
make process (with an alias), later it tries to use the wrong make.

It changes nothing on linux systems as they must have anyway gmake.

Hope this can be merged with main portage so only minimum changes are needed
for fbsd.

Diego

Created an attachment (id=56778) [details]
xorg-x11-6.8.99.3-ebuild.patch

Does FBSD's port use gmake for it?

No it doesn't, it uses bsd's make, that can be done passing MAKE="make", and it
works.

I used gmake just becase we can have exactly the same make program on both
platforms (easier to maintain) but now I see that it didn't built X binary, so
tomorrow I'll try with MAKE="make" and see what happens.

Created an attachment (id=57846) [details]
Updated patch

This is a new patch which uses make instead of gmake (seems to be needed on
fbsd userland, I don't really know why), and blacklist one patch from the
gentoo's ones, which states that breaks compatibility and which really break
it.
I don't know what that patch is supposed to do and why we are going to add it,
but under g/fbsd can't be applied as can't be applied upstream. If upstream can
work without it maybe we can, too.

+		if [[ "${KERNEL}" == "FreeBSD" ]]; then
+			echo "#define __FreeBSD__" >> ${HOSTCONF}
+			echo "#undef linux" >> ${HOSTCONF}
+		fi

I'm concerned that it's necessary to do this. Is this because the compiler isn't smart enough to figure out which kernel it's running? I also don't understand why you're undefining linux instead of __linux__.

+	# As the patch sais, that breaks non-linux systems, more exaclty
+	# it breaks non-glibc systems where open64 and loff_t doesn't exists.
+	# Exclude this until a better workaround is in place.
+	[[ "$LIBC" == "glibc" ]] || \
+		EPATCH_EXCLUDE="${EPATCH_EXCLUDE} 0700_all_4.2.0-sessreg-highuid.patch"

Please use patch_exclude(), as it's been determined to work more consistently. Also please use an if/then for this.

<bunch of MAKE="make" stuff>

Is it possible to just export this once in pkg_setup() or something?

About the define/undef, I just copied that stuff from bug #82689.

The patch, I've changed that and I'm searching becase seems there are other patches which needs to be removed on freebsd.

About the make stuff, I've tried, but it fails, it spawns up something which ignores MAKE= exported in pkg_setup or also at global level.

Created an attachment (id=57907) [details]
xorg-x11.6.8.99.3.patch

Ok updated patch. It checks both for glibc and linux systems as acecad drivers
tries to include linux/ and sys/ headers.

It also changes from root:root owner for files to root:wheel, as root group
doesn't exists on fbsd (and wheel simply do the same thing for linux).

It still doesn't work well with opengl and xv but I'm going to fix this up
later.
Hope this can be applied with next xorg version :)

As for irc-ing, we found these notes:

- Patch 5901 must drop the first chunk as it's a bogus change which blocks compilation on non-linux systems.
- Patch 0700 will create problems on non-glibc non-uclibc systems, as there loff_t and *64() patches are in place. Seems like the comment above the patch makes glibc behave, with off_t, open() and read(), exactly as other systems.
- Tomorrow I'll try without those defines (on .5 ebuild).

Ok I'm going to attach a new 5901 patch which doesn't remove the #ifdef and
seems to work fine both on linux and freebsd.

I'm going to attach also pamd files which works with openpam as well as
linux-pam (sys-libs/pam). Please note that these will add dependency on
virtual/pam which requires >=sys-libs/pam-0.78.

There's an error in xorg sources about pam, I'm going to fix it today and post
the patch here and in fd.o bugzilla.

Created an attachment (id=58116) [details]
5901_all_4.2.99.3-acecad-debug.patch

Created an attachment (id=58117) [details]
xdm.pamd

Created an attachment (id=58118) [details]
xserver.pamd

So that also forces us to wait on pam-0.78 to go stable before we can stable
xorg.  I'd like an idea of when that should happen so I know which versions
this is safe to add to.

Created an attachment (id=58923) [details]
9999_all_6.8.99.5-openpam.patch

Patch for openpam support.

I really need spanky's patch for binutils to have a working xorg-x11 ebuild as
plain binutils are b0rked.

I've attached the needed patch for openpam compatibility.

I'll be happy to add the xorg patch once it's committed upstream.

Can you just add the 9999 patch for g/fbsd? Upstream seems not to care too   
much about it, but g/fbsd really needs it, I'll take care if there will ever 
be problems with it on g/fbsd. 
   
Also the pamd files if you can update them, they works also with pam 0.78 (and   
there was someone who wanted to try the backport for 0.77 to make the   
stabilization process faster). 
  
Martin you have a timing for 0.78 anyway? 
  
5901 is completely sane IMHO so can just be updated as it is. 

I just wanted to look at the upstream bug but the URL isn't anywhere on here.

Sorry I though I already posted it. 
https://bugs.freedesktop.org/show_bug.cgi?id=3219 there it is :) 

I'll see if I can find anholt on IRC and ask him about it.

I've just started building 6.8.99.8 without pam support (thinking if that's 
the problem I had with xorg launched as user, maybe the openpam patch is 
incomplete). 
 
If you can fix in the mean time the 5901 patch we can care of one thing less. 
 

Created an attachment (id=59687) [details]
xorg-x11-fbsd.patch

That's the updated patch for xorg-x11 ebuild anyway.

Possible. I see in xc/programs/Xserver/os/utils.c:

/*
 * CheckUserAuthorization: check if the user is allowed to start the
 * X server.  This usually means some sort of PAM checking, and it is
 * usually only done for setuid servers (uid != euid).
 */

etc.

Yes it seems to be that, built with -pam works fine. 
I'll find a better patch; in the mean time maybe you can disable pam when 
sys-libs/pam is not installed, or when sys-libs/openpam is installed? 

That's what the USE flag is for.

Committed the ebuild patch and 5901 to 6.8.2-r2 and 6.8.99.8.

This one can be considered fixed: xorg-x11 builds fine now, the only remaining 
change is the pam one, but that will require a few more changes, so for now, 
just close that. 
FreeBSD builds without pam, we can do that, too, until we have a working 
version maybe upstream. 
 
I'll open a new bug when pam will work fine :) 
 
Thanks again. 

This one can be considered fixed: xorg-x11 builds fine now, the only remaining 
change is the pam one, but that will require a few more changes, so for now, 
just close that. 
FreeBSD builds without pam, we can do that, too, until we have a working 
version maybe upstream. 
 
I'll open a new bug when pam will work fine :) 
 
Thanks again. 

wth happened?