[opensuse-packaging] New build failures due to xorg-x11 reshuffle
Hi, As Marguerite Su already noted, xorg-x11 libraries were split, renamed and recreated as meta packages. For most packages this is no problem, but in some cases this creates a problem. The situation is this: vim.spec requires gtk2-devel, which in return requires pkgconfig(xft). Before the xorg libs split, this pkgconfig require dragged in all other XOrg libraries too and vim build was free to choose. Now there is only Xft and the libraries below it in the buildroot and vim fails. You have two options to fix the build, which both come down to: fix your build requires to require what you need to build. Either use the correct form (works on >= 11.4 afaik) BuildRequires: pkgconfig(xt) or simulate the old way in dragging all X libs in: BuildRequires: xorg-x11-devel The choice is yours - but what I'm most afraid of are packages that do not build fail, but simply disable X11 support. vim only fails because one binary is missing. If vim.spec had used %_bindir/* as many others do, it would have left unnoticed ;( Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Mon, 20 Feb 2012, Stephan Kulow wrote:
For most packages this is no problem, but in some cases this creates a problem. The situation is this:
vim.spec requires gtk2-devel, which in return requires pkgconfig(xft). Before the xorg libs split, this pkgconfig require dragged in all other XOrg libraries too and vim build was free to choose. Now there is only Xft and the libraries below it in the buildroot and vim fails.
You have two options to fix the build, which both come down to: fix your build requires to require what you need to build.
Either use the correct form (works on >= 11.4 afaik) BuildRequires: pkgconfig(xt)
or simulate the old way in dragging all X libs in: BuildRequires: xorg-x11-devel
Is it really meaningful to have gtk2-devel installed, but not xorg-x11-devel? I.e. why what that requires removed (it still existed in 11.3)? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le lundi 20 février 2012, à 12:38 +0100, Michael Matz a écrit :
Hi,
On Mon, 20 Feb 2012, Stephan Kulow wrote:
For most packages this is no problem, but in some cases this creates a problem. The situation is this:
vim.spec requires gtk2-devel, which in return requires pkgconfig(xft). Before the xorg libs split, this pkgconfig require dragged in all other XOrg libraries too and vim build was free to choose. Now there is only Xft and the libraries below it in the buildroot and vim fails.
You have two options to fix the build, which both come down to: fix your build requires to require what you need to build.
Either use the correct form (works on >= 11.4 afaik) BuildRequires: pkgconfig(xt)
or simulate the old way in dragging all X libs in: BuildRequires: xorg-x11-devel
Is it really meaningful to have gtk2-devel installed, but not xorg-x11-devel? I.e. why what that requires removed (it still existed in 11.3)?
Because you don't need all the xorg libraries to compile something against gtk2. But really, this was just this specific example with vim; the issue most likely exists in other packages that do not use gtk2 at all... Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le lundi 20 février 2012, à 11:45 +0100, Stephan Kulow a écrit :
The choice is yours - but what I'm most afraid of are packages that do not build fail, but simply disable X11 support. vim only fails because one binary is missing. If vim.spec had used %_bindir/* as many others do, it would have left unnoticed ;(
That's my concern too. Would it be possible to compare the dependencies of packages before and after the xorg-x11 changes? This might help us find some issues. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 20.02.2012 12:38, Michael Matz wrote:
Hi,
On Mon, 20 Feb 2012, Stephan Kulow wrote:
For most packages this is no problem, but in some cases this creates a problem. The situation is this:
vim.spec requires gtk2-devel, which in return requires pkgconfig(xft). Before the xorg libs split, this pkgconfig require dragged in all other XOrg libraries too and vim build was free to choose. Now there is only Xft and the libraries below it in the buildroot and vim fails.
You have two options to fix the build, which both come down to: fix your build requires to require what you need to build.
Either use the correct form (works on >= 11.4 afaik) BuildRequires: pkgconfig(xt)
or simulate the old way in dragging all X libs in: BuildRequires: xorg-x11-devel
Is it really meaningful to have gtk2-devel installed, but not xorg-x11-devel? I.e. why what that requires removed (it still existed in 11.3)?
gtk2-devel requires that X libs that are necessary to develop GTK2 applications - which is the right thing to do. That vim needs Xt headers additionally is a vim problem, not a GTK problem. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 20.02.2012 13:10, Vincent Untz wrote:
Le lundi 20 février 2012, à 11:45 +0100, Stephan Kulow a écrit :
The choice is yours - but what I'm most afraid of are packages that do not build fail, but simply disable X11 support. vim only fails because one binary is missing. If vim.spec had used %_bindir/* as many others do, it would have left unnoticed ;(
That's my concern too. Would it be possible to compare the dependencies of packages before and after the xorg-x11 changes? This might help us find some issues.
factory-snapshot still has M1. So see at the end of this mail the list of lost requires against libX* If you look at e.g. tk build log, you can see it also in the build-compare output: compare /.build.oldpackages/tk-8.5.11-1.1.i586.rpm /home/abuild/rpmbuild/RPMS/i586/tk-8.5.11-1.2.i586.rpm --- /tmp/tmp.3C2JOtWQut 2012-02-17 22:00:00.652000001 +0000 +++ /tmp/tmp.FLET3NVj5H 2012-02-17 22:00:00.676000001 +0000 @@ -7,8 +7,6 @@ /bin/rm 2560 /bin/sh 16384 libX11.so.6 16384 -libXft.so.2 16384 -libXss.so.1 16384 libc.so.6 16384 libc.so.6(GLIBC_2.0) 16384 libc.so.6(GLIBC_2.1.3) 16384 because 'checking whether to use xft... no', but this time it's special as tk buildrequires xorg-x11-devel, which I only fixed on saturday - so I need to rebuild tk most likely. But it's astonishing: xmorph simply does not build xmorph and still the package builds ;( Greetings, Stephan ZynAddSubFX:libXext.so.6 ZynAddSubFX:libXft.so.2 ZynAddSubFX:libXinerama.so.1 alsamixergui:libX11.so.6 alsamixergui:libXft.so.2 alsamixergui:libXinerama.so.1 dx:libXinerama.so.1 fvwm2:libXcursor.so.1 fvwm2:libXft.so.2 fvwm2:libXinerama.so.1 gdm:libXdmcp.so.6 gnokii:libXpm.so.4 gnome-screensaver:libXxf86misc.so.1 graphviz:libX11.so.6 graphviz:libXaw.so.7 graphviz:libXmu.so.6 graphviz:libXt.so.6 gstreamer-0_10-plugins-good:libXv.so.1 gv:libXinerama.so.1 icc_examin:libXft.so.2 icc_examin:libXinerama.so.1 istanbul:libXdamage.so.1 istanbul:libXext.so.6 istanbul:libXfixes.so.3 kde3-sim:libXss.so.1 kompozer:libX11.so.6 kompozer:libXft.so.2 kompozer:libXinerama.so.1 kompozer:libXrender.so.1 kompozer:libXt.so.6 libfltk1:libXft.so.2 libfltk1:libXinerama.so.1 libgcj46:libXrandr.so.2 libgcj46:libXrender.so.1 libgcj46:libXtst.so.6 libm17n0:libXft.so.2 libotf:libX11.so.6 libotf:libXaw.so.7 libotf:libXt.so.6 libwnck-1-22:libXRes.so.1 libwnck-3-0:libXRes.so.1 libwx_gtk2_core-2_8-0-wxcontainer:libXinerama.so.1 libwx_gtk2_core-2_8-0-wxcontainer:libXxf86vm.so.1 libwx_gtk2u_core-2_8-0-stl:libXinerama.so.1 libwx_gtk2u_core-2_8-0-stl:libXxf86vm.so.1 libwx_gtk2u_core-2_8-0-wxcontainer:libXinerama.so.1 libwx_gtk2u_core-2_8-0-wxcontainer:libXxf86vm.so.1 m17n-lib:libXaw.so.7 m17n-lib:libXmu.so.6 mathgl:libXext.so.6 mathgl:libXft.so.2 mathgl:libXinerama.so.1 mgp:libXft.so.2 midori:libXss.so.1 mozilla-xulrunner192:libX11.so.6 mozilla-xulrunner192:libXrender.so.1 mozilla-xulrunner192:libXt.so.6 numlockx:libXtst.so.6 openbox:libXcursor.so.1 openbox:libXinerama.so.1 openbox:libXrandr.so.2 oyranos-forms-fltk:libXext.so.6 oyranos-forms-fltk:libXft.so.2 oyranos-forms-fltk:libXinerama.so.1 oyranos-ui-fltk:libXft.so.2 oyranos-ui-fltk:libXinerama.so.1 pavuk:libXmu.so.6 perl-Tk:libXft.so.2 prozgui:libXft.so.2 prozgui:libXinerama.so.1 psi:libXss.so.1 rdesktop:libXrandr.so.2 redshift:libX11.so.6 redshift:libXxf86vm.so.1 tk:libXft.so.2 tk:libXss.so.1 totem-browser-plugin:libXtst.so.6 totem-plugins:libXtst.so.6 tvtime:libXinerama.so.1 tvtime:libXtst.so.6 xdiskusage:libXft.so.2 xdiskusage:libXinerama.so.1 xine-ui:libXft.so.2 xine-ui:libXinerama.so.1 xine-ui:libXtst.so.6 xine-ui:libXxf86vm.so.1 xmorph:libX11.so.6 xmorph:libXaw.so.7 xmorph:libXt.so.6 xosd:libXinerama.so.1 xplanet:libXss.so.1 Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 20/02/12 09:20, Stephan Kulow wrote:
That vim needs Xt headers additionally is a vim problem, not a GTK problem.
Yes, and this breakage is a good thing, otherwise we are gonna carry bloat foreva. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Feb 20 11:45 Stephan Kulow wrote (excerpt):
... what I'm most afraid of are packages that do not build fail, but simply disable X11 support. vim only fails because one binary is missing. If vim.spec had used %_bindir/* as many others do, it would have left unnoticed ;(
Strictly speaking '%_bindir/*' in the %files section of the spec file means that it does not matter which binaries are built and packaged (in other words: the packager doesn't care). Each mandatory file in a package should be explicitly specified in the %files section. When mandatory files are explicitly listed in the %files section, the build fails intentionally if a mandatory file was not built which ensures that already existing correctly built binary RPMs are not overwritten by broken RPMs where mandatory files are missing so that OBS and its users cannot use such kind of broken RPMs. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2012-02-21 09:49:02 (+0100), Johannes Meixner
On Feb 20 11:45 Stephan Kulow wrote (excerpt):
... what I'm most afraid of are packages that do not build fail, but simply disable X11 support. vim only fails because one binary is missing. If vim.spec had used %_bindir/* as many others do, it would have left unnoticed ;(
Strictly speaking '%_bindir/*' in the %files section of the spec file means that it does not matter which binaries are built and packaged (in other words: the packager doesn't care).
Each mandatory file in a package should be explicitly specified in the %files section.
When mandatory files are explicitly listed in the %files section, the build fails intentionally if a mandatory file was not built which ensures that already existing correctly built binary RPMs are not overwritten by broken RPMs where mandatory files are missing so that OBS and its users cannot use such kind of broken RPMs.
Absolutely. Listing files explicitly is annoying to do, but things don't go unnoticed, package builds are supposed to be dependable. I even go as far as to grep the log of %configure in some packages to make sure specific features are enabled. I do that for MPlayer, for example, which is one big binary with features built in or not, obviously in packman: https://pmbs.links2linux.org/package/view_file?file=MPlayer.spec&package=MPlayer&project=Essentials (starting at line 250) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
On Feb 21, 12 09:49:02 +0100, Johannes Meixner wrote:
Strictly speaking '%_bindir/*' in the %files section of the spec file means that it does not matter which binaries are built and packaged (in other words: the packager doesn't care).
Each mandatory file in a package should be explicitly specified in the %files section.
The files section cannot be used to define mandatory files like this: %files /usr/bin/important /usr/bin/* RPM would complain that the file /usr/bin/important is now listed twice. We would need something like %files /usr/bin/important %nodup /usr/bin/* cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 say #263A!__/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. ☺ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Feb 21 12:42 Juergen Weigert wrote (excerpt):
On Feb 21, 12 09:49:02 +0100, Johannes Meixner wrote:
Strictly speaking '%_bindir/*' in the %files section of the spec file means that it does not matter which binaries are built and packaged (in other words: the packager doesn't care).
Each mandatory file in a package should be explicitly specified in the %files section.
The files section cannot be used to define mandatory files like this:
%files /usr/bin/important /usr/bin/*
RPM would complain that the file /usr/bin/important is now listed twice. We would need something like
%files /usr/bin/important %nodup /usr/bin/*
Why do "we need"? At least for me the meaning of --------------------------------- %files /usr/bin/important /usr/bin/* --------------------------------- is obvious. I don't need additional stuff to understand what it means. And why does the RPM tool need it? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 21.02.2012 12:42, Juergen Weigert wrote:
On Feb 21, 12 09:49:02 +0100, Johannes Meixner wrote:
Strictly speaking '%_bindir/*' in the %files section of the spec file means that it does not matter which binaries are built and packaged (in other words: the packager doesn't care).
Each mandatory file in a package should be explicitly specified in the %files section.
The files section cannot be used to define mandatory files like this:
%files /usr/bin/important /usr/bin/*
RPM would complain that the file /usr/bin/important is now listed twice. We would need something like
%files /usr/bin/important %nodup /usr/bin/*
It will warn you about the duplication, but it doesn't do harm to be extra careful with bin/important. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (7)
-
Cristian Rodríguez -
Johannes Meixner -
Juergen Weigert -
Michael Matz -
Pascal Bleser -
Stephan Kulow -
Vincent Untz