Bug 465788 – Please stabilise x11-libs/motif-2.2.3-r12 and x11-libs/motif-2.3.4-r1

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Ulrich Müller 2013-04-13 14:24:37 UTC]

In Portage tree since 30 days, no bugs reported.

Target keywords:
motif-2.2.3-r12: amd64 x86
motif-2.3.4-r1:  alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86

Thanks in advance.

[Comment 1 Jeroen Roovers (RETIRED) 2013-04-15 09:18:31 UTC]

Stable for HPPA.

[Comment 2 Agostino Sarubbo 2013-04-15 14:20:56 UTC]

ppc stable

[Comment 3 Agostino Sarubbo 2013-04-16 20:48:28 UTC]

ppc64 stable

[Comment 4 Agostino Sarubbo 2013-04-16 21:07:44 UTC]

arm stable

[Comment 5 Agostino Sarubbo 2013-04-18 08:54:01 UTC]

alpha stable

[Comment 6 Agostino Sarubbo 2013-04-18 14:24:04 UTC]

ia64 stable

[Comment 7 Geoff Madden 2013-04-24 11:11:07 UTC]

I have a problem with motif-2.3.4 on an x86 in that aclocal is complaining about AM_CONFIG_HEADERS is outdated.
I have opened up motif-2.3.4-src.tgz & modified configure.ac rezipped the file placed it back in my distfile_dir. gone to motif and removed the entry for both 2.3.4 & 2.3.4-r1 ebuilds. I then ran ebuild which complained about thefile not being kosher and promtly downloads it again,it fails verification from my local mirror,but is ok with the file from gentoo/distfiles,which still has the outdated AM_CONFIG_HEADERS macro.



HELP

[Comment 8 Ulrich Müller 2013-04-24 20:15:39 UTC]

(In reply to comment #7)
> I have a problem with motif-2.3.4 on an x86 in that aclocal is complaining
> about AM_CONFIG_HEADERS is outdated.

Please open a new bug for that issue. This is a stabilisation bug.

> I have opened up motif-2.3.4-src.tgz & modified configure.ac rezipped the
> file placed it back in my distfile_dir.

Don't do that, but put a patch into /etc/portage/patches/ instead. See the documentation of epatch_user in eutils.eclass for specifics.

[Comment 9 Pacho Ramos 2013-04-29 19:31:39 UTC]

I think mgorny fixed the mask entries and, then, would be possible to stabilize that versions on amd64 too I think

[Comment 10 Ulrich Müller 2013-04-29 21:00:05 UTC]

amd64 is back in CC.

[Comment 11 Agostino Sarubbo 2013-05-01 10:37:11 UTC]

x86 stable

[Comment 12 Agostino Sarubbo 2013-05-01 11:15:37 UTC]

sh stable

[Comment 13 Agostino Sarubbo 2013-05-07 13:56:35 UTC]

sparc stable. Last arch, closing

[Comment 14 Ulrich Müller 2013-05-07 14:53:52 UTC]

amd64 and x86 still missing.

[Comment 15 Pacho Ramos 2013-05-07 17:58:41 UTC]

What is preventing stabilization on x86 and amd64? Thanks for the info

[Comment 16 Ulrich Müller 2013-05-07 18:23:55 UTC]

(In reply to comment #15)
> What is preventing stabilization on x86 and amd64? Thanks for the info

<rej> Who broke x11-libs/motif-2.3.4-r1? It looks like it DEPENDs on unstable
      x11-libs/* for plain x86.
<rej> And it wants to rebuild these x11-libs/* for no apparent reason.
<ulm> rej: repoman full looks good here
<rej> ulm: Yes, so that means repoman doesn't see the problem. :)
<rej> That's another bug.
<rej> I guess I'll file a bug report.
<ulm> rej: it depends on x11-libs/libX11[abi_x86_32(-)?]
<ulm> rej: should I drop motif to ~x86, for the time being?
<rej> ulm: I want to check first if it "works" with a freshly synced tree.
<ulm> it cannot, abi_x86_32 is use.forced in the x86 profile, but it's not in
      IUSE_REFERENCEABLE for EAPI 4
<ulm> in theory, at least ;)
<ulm> rej: maybe it's better if you test it in practice
<rej> ulm: bug 468590

[Comment 17 Pacho Ramos 2013-05-07 18:42:22 UTC]

This looks really strange:
https://bugs.gentoo.org/show_bug.cgi?id=468590#c2

[Comment 18 Ulrich Müller 2013-06-13 08:47:45 UTC]

Readding amd64 and x86. The following dependencies need to go stable, too:

>=dev-libs/libpthread-stubs-0.3-r1
>=media-libs/fontconfig-2.10.2-r1
>=media-libs/freetype-2.4.11-r2
>=x11-libs/libICE-1.0.8-r1
>=x11-libs/libSM-1.2.1-r1
>=x11-libs/libX11-1.6.0
>=x11-libs/libXau-1.0.7-r1
>=x11-libs/libXdmcp-1.1.1-r1
>=x11-libs/libXext-1.3.2
>=x11-libs/libXft-2.3.1-r1
>=x11-libs/libXmu-1.1.1-r1
>=x11-libs/libXp-1.0.2
>=x11-libs/libXrender-0.9.7-r1
>=x11-libs/libXt-1.1.4
>=x11-libs/libxcb-1.9.1
>=x11-proto/inputproto-2.2-r1
>=x11-proto/kbproto-1.0.6-r1
>=x11-proto/printproto-1.0.5-r1
>=x11-proto/renderproto-0.11.1-r1
>=x11-proto/xcb-proto-1.8-r2
>=x11-proto/xextproto-7.2.1-r1
>=x11-proto/xf86bigfontproto-1.2.0-r1
>=x11-proto/xproto-7.0.23-r2

[Comment 19 Ulrich Müller 2013-06-25 09:23:44 UTC]

(In reply to Ulrich Müller from comment #18)
> >=x11-libs/libXrender-0.9.7-r1

This should read >=libXrender-0.9.8, sorry for the typo.

[Comment 20 Agostino Sarubbo 2013-06-25 13:23:25 UTC]

(In reply to Ulrich Müller from comment #18)
> Readding amd64 and x86. The following dependencies need to go stable, too:
> 
> >=dev-libs/libpthread-stubs-0.3-r1
> >=media-libs/fontconfig-2.10.2-r1
> >=media-libs/freetype-2.4.11-r2
> >=x11-libs/libICE-1.0.8-r1
> >=x11-libs/libSM-1.2.1-r1
> >=x11-libs/libX11-1.6.0
> >=x11-libs/libXau-1.0.7-r1
> >=x11-libs/libXdmcp-1.1.1-r1
> >=x11-libs/libXext-1.3.2
> >=x11-libs/libXft-2.3.1-r1
> >=x11-libs/libXmu-1.1.1-r1
> >=x11-libs/libXp-1.0.2
> >=x11-libs/libXrender-0.9.7-r1
> >=x11-libs/libXt-1.1.4
> >=x11-libs/libxcb-1.9.1
> >=x11-proto/inputproto-2.2-r1
> >=x11-proto/kbproto-1.0.6-r1
> >=x11-proto/printproto-1.0.5-r1
> >=x11-proto/renderproto-0.11.1-r1
> >=x11-proto/xcb-proto-1.8-r2
> >=x11-proto/xextproto-7.2.1-r1
> >=x11-proto/xf86bigfontproto-1.2.0-r1
> >=x11-proto/xproto-7.0.23-r2

is x11 fine with that?

[Comment 21 Ulrich Müller 2013-06-25 16:01:05 UTC]

(In reply to Agostino Sarubbo from comment #20)
> is x11 fine with that?

CCing them.

[Comment 22 Chí-Thanh Christopher Nguyễn 2013-06-25 16:04:22 UTC]

No, these packages still have some regressions introduced by the multilib changes, e.g. bug 464514.

[Comment 23 Chí-Thanh Christopher Nguyễn 2013-06-25 16:57:33 UTC]

There are more regressions. I plan to make a general xorg stabilization bug once there is a new libXi release (including the packages mentioned bug 471098), and will enumerate all the regressions for that.

[Comment 24 Agostino Sarubbo 2013-06-27 15:59:03 UTC]

(In reply to Chí-Thanh Christopher Nguyễn from comment #23)
> There are more regressions. I plan to make a general xorg stabilization bug
> once there is a new libXi release (including the packages mentioned bug
> 471098), and will enumerate all the regressions for that.

Then uncc'ing arches

[Comment 25 Ulrich Müller 2013-08-01 21:53:19 UTC]

I've updated multilib dependencies such that they can be satisfied by stable emul-linux-x86-xlibs too. This way, we aren't blocked by Xorg stabilisation any longer.

Readding arch teams, please proceed.

[Comment 26 Agostino Sarubbo 2013-08-04 18:36:14 UTC]

amd64 stable

[Comment 27 Tamas Jantvik 2013-08-05 17:31:52 UTC]

(In reply to Agostino Sarubbo from comment #26)
> amd64 stable

I'm on amd64, and this doesn't compile for me. I have 2. First it fails finding freetype stuff (/usr/include/ft2build.h:56:38: fatal error: freetype/config/ftheader.h: No such file or directory), and given a manual symlink /usr/include/freetype -> /usr/include/freetype2/freetype, it carries on failing on Xft stuff (fails to locate symbols).

[Comment 28 Tamas Jantvik 2013-08-05 17:35:54 UTC]

I meant to say that I have 2.3.4 installed on 2013-04-17. But somehow that text fragment got lost.

[Comment 29 Ulrich Müller 2013-08-05 18:34:20 UTC]

(In reply to Tamas Jantvik from comment #27)
> I'm on amd64, and this doesn't compile for me.

Please open a new bug for that issue. This is a stabilisation bug.

[Comment 30 Ulrich Müller 2013-08-05 21:30:37 UTC]

(In reply to Ulrich Müller from comment #29)
> (In reply to Tamas Jantvik from comment #27)
> > I'm on amd64, and this doesn't compile for me.
> 
> Please open a new bug for that issue.

Bug 479876. I've added a workaround to motif-2.3.4-r1.ebuild.

[Comment 31 Tamas Jantvik 2013-08-06 10:52:45 UTC]

These workarounds fixed it for me. It compiles and installs, also with the manual freetype symlink removed.

[Comment 32 Ulrich Müller 2013-08-06 11:09:41 UTC]

(In reply to Agostino Sarubbo from comment #11)
> x86 stable

x86 keyword restored (it had been dropped due to bug 468590).
Closing.