Bug 184952 - x11-servers/xorg-server: Slave port makefiles all have same error
Summary: x11-servers/xorg-server: Slave port makefiles all have same error
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-18 00:20 UTC by John Marino
Modified: 2015-01-14 22:57 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Marino 2013-12-18 00:20:00 UTC
I reported this issue over IRC but apparently it has been forgotten.  I am writing this down via PR officially now.

x11-servers/xorg-nestserver
x11-servers/xorg-vfbserver
x11-servers/xephyr

are all slave ports of x11-servers, and all have the same issue:

They each have this line:
.include <bsd.port.options.mk>

As these are slave ports, there are no options defined.  So at the very best, it's a useless line that needs cleaning up.  However, it actually causes duplicate loading of Makefile.* which breaks dports (it causes patches to be applied twice).

Please remove these extraneous includes

Fix: 

remove ".include <bsd.port.options.mk>" line from each of these three ports.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2013-12-18 00:20:08 UTC
Responsible Changed
From-To: freebsd-ports-bugs->freebsd-x11

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 dfilter service freebsd_committer freebsd_triage 2013-12-31 13:22:24 UTC
Author: kwm
Date: Tue Dec 31 13:22:14 2013
New Revision: 338299
URL: http://svnweb.freebsd.org/changeset/ports/338299

Log:
  Remove extra bsd.port.options.mk, it already defined in the master port.
  
  PR:		ports/184952
  Submitted by:	marino@

Modified:
  head/x11-servers/xephyr/Makefile

Modified: head/x11-servers/xephyr/Makefile
==============================================================================
--- head/x11-servers/xephyr/Makefile	Tue Dec 31 13:17:05 2013	(r338298)
+++ head/x11-servers/xephyr/Makefile	Tue Dec 31 13:22:14 2013	(r338299)
@@ -21,8 +21,6 @@ CONFIGURE_ARGS=	--enable-kdrive --enable
 SLAVE_PORT=	yes
 PLIST_FILES=	bin/Xephyr man/man1/Xephyr.1.gz
 
-.include <bsd.port.options.mk>
-
 do-install:
 	${INSTALL_PROGRAM} ${WRKSRC}/hw/kdrive/ephyr/Xephyr ${STAGEDIR}${PREFIX}/bin/
 .if defined(WITH_NEW_XORG)
_______________________________________________
svn-ports-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-ports-all
To unsubscribe, send any mail to "svn-ports-all-unsubscribe@freebsd.org"
Comment 3 Koop Mast freebsd_committer freebsd_triage 2013-12-31 13:22:27 UTC
State Changed
From-To: open->closed

Committed thanks!
Comment 4 Niclas Zeising freebsd_committer freebsd_triage 2013-12-31 18:23:59 UTC
This breaks detection of WITH_NEW_XORG= and needs to be reverted.
Regards!
-- 
Niclas Zeising
Comment 5 freebsd.contact 2013-12-31 19:43:00 UTC
On 12/31/2013 19:23, Niclas Zeising wrote:
> This breaks detection of WITH_NEW_XORG= and needs to be reverted.
> Regards!

Then your WITH_NEW_XORG detection is wrong.
Having bsd.ports.options.mk loaded multiple times causes problems, such
as applying the same patches multiple times (if patches are present).
It was detected independently by myself and kwm.

By the way, the "detection" broke DragonFly too because of the use of
OSVERSION without OPSYS.

I'd say the detection is what needs to be reverted.

(DragonFly has /etc/defaults/make.conf so we put WITH_NEW_XORG defaults
there)

John
Comment 6 Niclas Zeising freebsd_committer freebsd_triage 2013-12-31 20:17:23 UTC
On 12/31/13 20:43, John Marino wrote:
> On 12/31/2013 19:23, Niclas Zeising wrote:
>> This breaks detection of WITH_NEW_XORG= and needs to be reverted.
>> Regards!
> 
> Then your WITH_NEW_XORG detection is wrong.
> Having bsd.ports.options.mk loaded multiple times causes problems, such
> as applying the same patches multiple times (if patches are present).
> It was detected independently by myself and kwm.
> 
> By the way, the "detection" broke DragonFly too because of the use of
> OSVERSION without OPSYS.
> 
> I'd say the detection is what needs to be reverted.
> 
> (DragonFly has /etc/defaults/make.conf so we put WITH_NEW_XORG defaults
> there)


FreeBSD has no such thing, so that is not an option.  Currently
WITH_NEW_XORG is defined in bsd.port.mk, which is included from
bsd.port.options.mk.  This needs to be included WITH_NEW_XORG is
checked.  Bapt said that the best way was to include bsd.port.options.mk
before checking for WITH_NEW_XORG.  I will leave this as-is for now,
since I'm not in a position to develop a better solution currently,
however, this has to be revisisted asap.
Regards!
-- 
Niclas Zeising
Comment 7 freebsd.contact 2013-12-31 21:33:03 UTC
On 12/31/2013 21:17, Niclas Zeising wrote:
> On 12/31/13 20:43, John Marino wrote:
>> On 12/31/2013 19:23, Niclas Zeising wrote:
>>> This breaks detection of WITH_NEW_XORG= and needs to be reverted.
>>> Regards!
>>
>> Then your WITH_NEW_XORG detection is wrong.
>> Having bsd.ports.options.mk loaded multiple times causes problems, such
>> as applying the same patches multiple times (if patches are present).
>> It was detected independently by myself and kwm.
>>
>> By the way, the "detection" broke DragonFly too because of the use of
>> OSVERSION without OPSYS.
>>
>> I'd say the detection is what needs to be reverted.
>>
>> (DragonFly has /etc/defaults/make.conf so we put WITH_NEW_XORG defaults
>> there)
> 
> 
> FreeBSD has no such thing, so that is not an option. 

Yes, I was surprised to discover this when I investigated earlier.

> Currently WITH_NEW_XORG is defined in bsd.port.mk, which is included from
> bsd.port.options.mk.  This needs to be included WITH_NEW_XORG is
> checked.  Bapt said that the best way was to include bsd.port.options.mk
> before checking for WITH_NEW_XORG.  I will leave this as-is for now,
> since I'm not in a position to develop a better solution currently,
> however, this has to be revisisted asap.

If bsd.ports.options.mk is loaded at least once, why does removing it
from xephry/nested/vbf slave ports break the detection?  Should not it
still work since xorg-server loads it?

John
Comment 8 Mark Linimon 2014-01-01 01:00:01 UTC
----- Forwarded message from Niclas Zeising <zeising@freebsd.org> -----

Date: Wed, 01 Jan 2014 01:55:44 +0100
From: Niclas Zeising <zeising@freebsd.org>
To: Thomas Mueller <mueller6724@bellsouth.net>
Cc: freebsd-x11@freebsd.org
Subject: Re: ports/184952: x11-servers/xorg-server: Slave port makefiles all have same error
User-Agent: Mutt/1.5.21

On 01/01/14 01:12, Thomas Mueller wrote:
> 
> I hope you or somebody in charge of the new Xorg will say when we can build X on FreeBSD 10-stable and 11-head.
> 

It is ready and working, just go to x11/xorg to build the xorg meta
port.  You might want to set WITH_NEW_XORG= in /etc/make.conf to get the
new xorg stack, especially if you have hardware that needs KMS, such as
intel and ATI/AMD graphics cards.
Regards!
-- 
Niclas Zeising
_______________________________________________
freebsd-x11@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"


----- End forwarded message -----
Comment 9 Koop Mast 2014-01-01 09:19:40 UTC
I have trouble seeing what is exactly broken with the WITH_NEW_XORG 
detection. On the survace it seems to work. Can you explain where it 
doesn't work?

root@crashalot:/usr/ports/x11-servers/xephyr # ident Makefile
Makefile:
      $FreeBSD: head/x11-servers/xephyr/Makefile 338299 2013-12-31 
13:22:14Z kwm $
root@crashalot:/usr/ports/x11-servers/xephyr # make -V PORTVERSION
1.12.4
Comment 10 freebsd.contact 2014-01-01 17:56:05 UTC
On 1/1/2014 10:19, Koop Mast wrote:
> I have trouble seeing what is exactly broken with the WITH_NEW_XORG
> detection. On the survace it seems to work. Can you explain where it
> doesn't work?
> 
> root@crashalot:/usr/ports/x11-servers/xephyr # ident Makefile
> Makefile:
>      $FreeBSD: head/x11-servers/xephyr/Makefile 338299 2013-12-31
> 13:22:14Z kwm $
> root@crashalot:/usr/ports/x11-servers/xephyr # make -V PORTVERSION
> 1.12.4

Koop,
Were you addressing Niclas?

He claimed your commit broke it.  At first I said, "well detection must
be broken in that case", but after thinking about it, I questioned
Niclas if it was actually broken.  Since xorg-server still pulls in
bsd.port.options.mk, the detection should still work (as you note).

So right now, I'm working under the assumption there is actually no
breakage at all, and Niclas just said the ports were broken without
verifying first.  If that assumption is wrong, he should correct it.

Regards,
John
Comment 11 freebsd.contact 2014-05-06 09:02:36 UTC
zeising@ reverted the commit, and thus broke the port on DragonFly again:

http://svnweb.freebsd.org/ports/head/x11-servers/xephyr/Makefile?r1=351411&r2=351410&pathrev=351411

Here's the error that it caused mixing bsd.port.options.mk followed by
bsd.port.pre.mk.

> =======================<phase: patch          >============================
> ===>  Patching for xephyr-1.12.4_7,1
> ===>  Applying extra patch /usr/ports/x11-servers/xephyr/../xorg-server/dragonfly/extra-new-hw_xfree86_os-support_xf86__OSlib.h
> ===>  Applying extra patch /usr/ports/x11-servers/xephyr/../xorg-server/dragonfly/extra-new-hw_xfree86_os-support_xf86__OSlib.h
> Ignoring previously applied (or reversed) patch.
> 1 out of 1 hunks ignored--saving rejects to hw/xfree86/os-support/xf86_OSlib.h.rej
> *** Error code 1

Here is the inclusion order on DragonFly:

x11-servers/xephyr> make -V .MAKE.MAKEFILES | tr " " "\n"
/usr/share/mk/sys.mk
/etc/defaults/make.conf
/etc/make.conf
/usr/share/mk/bsd.cpu.mk
/usr/share/mk/bsd.cpu.gcc47.mk
Makefile
/usr/share/mk/bsd.port.options.mk
/usr/share/mk/bsd.port.mk
/usr/share/mk/bsd.own.mk
/usr/dports/Mk/bsd.port.mk
/usr/dports/Mk/bsd.commands.mk
/home/automaton/merged-ports/x11-servers/xephyr/../xorg-server/Makefile.DragonFly
/usr/dports/Mk/bsd.options.mk
/home/automaton/merged-ports/x11-servers/xephyr/../xorg-server/Makefile
/usr/share/mk/bsd.port.pre.mk
/usr/dports/Mk/bsd.sanity.mk
/usr/dports/Mk/bsd.xorg.mk
/usr/dports/Mk/bsd.openssl.mk
/usr/dports/Mk/bsd.pbi.mk
/usr/dports/Mk/Uses/gmake.mk
/usr/dports/Mk/Uses/libtool.mk
/usr/dports/Mk/Uses/perl5.mk
/usr/dports/Mk/Uses/tar.mk
/usr/dports/Mk/Uses/pkgconfig.mk
/usr/dports/Mk/Uses/pathfix.mk
/usr/share/mk/bsd.port.post.mk
/usr/dports/Mk/bsd.stage.mk
/usr/dports/Mk/bsd.pkgng.mk
/usr/dports/Mk/bsd.licenses.mk
/usr/dports/Mk/bsd.sites.mk
/usr/dports/Mk/bsd.options.desc.mk

One doesn't normally needed both options and pre, it's usually one or
the other.  What exactly is broken when ".include <bsd.port.options.mk>"
is removed?  Because it builds fine without it.

Reopening - and hopefully this will be resolved quickly.
John
Comment 12 John Marino freebsd_committer freebsd_triage 2014-05-06 09:06:03 UTC
State Changed
From-To: closed->open

Commit reversion broke at least one xorg-serve slave on DF
Comment 13 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-01-14 22:57:42 UTC
The following coments were lost with the 2015-01-07 Bugzilla issue:

Jean-Sébastien Pédron:
> Now that WITH_NEW_XORG is gone, what is needed to solve this issue?

John Marino:
> I think this PR can be closed again.  AFAICT, this is no longer an issue as the
> slave ports don't include <options> twice anymore.  I have no "diffs" on dports
> either, I'm using the stock ports with no issues.

Jean-Sébastien Pédron:
> Ok, thanks!