* Detected file collision(s): * * /usr/share/aclocal/vala.m4 * /usr/share/man/man1/valac-0.10.1.xz * /usr/share/man/man1/vala-gen-introspect-0.10.1.xz * /usr/share/man/man1/vapigen-0.10.1.xz * /usr/share/devhelp/books/vala-0.10/default.css * /usr/share/devhelp/books/vala-0.10/vala.devhelp2 * /usr/share/devhelp/books/vala-0.10/attributes.html * /usr/share/devhelp/books/vala-0.10/exceptions.html * /usr/share/devhelp/books/vala-0.10/delegates.html * /usr/share/devhelp/books/vala-0.10/enums.html * /usr/share/devhelp/books/vala-0.10/interfaces.html * /usr/share/devhelp/books/vala-0.10/structs.html * /usr/share/devhelp/books/vala-0.10/classes.html * /usr/share/devhelp/books/vala-0.10/methods.html * /usr/share/devhelp/books/vala-0.10/namespaces.html * /usr/share/devhelp/books/vala-0.10/statements.html * /usr/share/devhelp/books/vala-0.10/expressions.html * /usr/share/devhelp/books/vala-0.10/types.html * /usr/share/devhelp/books/vala-0.10/overview.html * /usr/share/devhelp/books/vala-0.10/index.html * /usr/share/vala-0.10/vapi/zlib.vapi [...] * /usr/bin/valac-0.10 * /usr/bin/vapigen-0.10 * /usr/bin/vapicheck-0.10 * /usr/bin/vala-gen-introspect-0.10 * /usr/lib64/libvala-0.10.so.0.0.0 * /usr/lib64/libvala-0.10.la * /usr/lib64/pkgconfig/vala-0.10.pc * /usr/lib64/vala-0.10/gen-introspect-0.10 * /usr/include/vala-0.10/valacodegen.h * /usr/include/vala-0.10/vala.h * /usr/include/vala-0.10/valaccode.h * /usr/include/vala-0.10/valagee.h * /usr/bin/vala-0.10 * /usr/lib64/libvala-0.10.so * /usr/lib64/libvala-0.10.so.0 * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * dev-lang/vala-0.9.8 * /usr/share/aclocal/vala.m4 * /usr/share/devhelp/books/vala-0.10/attributes.html * /usr/share/devhelp/books/vala-0.10/classes.html * /usr/share/devhelp/books/vala-0.10/default.css * /usr/share/devhelp/books/vala-0.10/delegates.html * /usr/share/devhelp/books/vala-0.10/enums.html * /usr/share/devhelp/books/vala-0.10/exceptions.html * /usr/share/devhelp/books/vala-0.10/expressions.html * /usr/share/devhelp/books/vala-0.10/index.html * /usr/share/devhelp/books/vala-0.10/interfaces.html * /usr/share/devhelp/books/vala-0.10/methods.html * /usr/share/devhelp/books/vala-0.10/namespaces.html * /usr/share/devhelp/books/vala-0.10/overview.html * /usr/share/devhelp/books/vala-0.10/statements.html * /usr/share/devhelp/books/vala-0.10/structs.html * /usr/share/devhelp/books/vala-0.10/types.html * /usr/share/devhelp/books/vala-0.10/vala.devhelp2 * /usr/share/man/man1/vala-gen-introspect-0.10.1.xz * /usr/share/man/man1/valac-0.10.1.xz * /usr/share/man/man1/vapigen-0.10.1.xz Reproducible: Always
This is very odd. Portage reports 0.9.8 and 0.10.0 as being in the same slot, and yet wants to install them side-by-side. My guess is that 0.9.8 was originally SLOT="0", people installed it, then the slot changed without a version bump (not that that would help). Portage thinks the installed version and the new one are in different slots. A workaround is to manually re-emerge vala-0.9.8. Failing that, I can't see how to trick portage into re-installing the old one (version bumps will suffer the same problem, and the same conflict), or realizing that the old one's slot has changed. I'm CCing the portage guys, in case they know how to easily fix this...
The usual solution is to use a slotmove command in profiles/updates, to move the old installed instance to the new slot. Alternatively, you could set RDEPEND="!dev-lang/vala:0" in the new ebuilds so that they force the old slot to be uninstalled automatically.
*** Bug 338106 has been marked as a duplicate of this bug. ***
*** Bug 338122 has been marked as a duplicate of this bug. ***
sorry for the trouble, I'll fix it asap.
@all newly CCed, http://tinderbox.dev.gentoo.org/misc/dindex/dev-lang/vala http://tinderbox.dev.gentoo.org/misc/rindex/dev-lang/vala hello guys, you are being CCed to this ticket because >=vala-0.9.5 is now slotted to 0.10 and your package might stop building if a user updates to such revision and your dependency is not fixed to require one that works with your package. I forgot doing the needed work upfront and I'm very sorry for that, but now we need to fix dependencies. Please kindly review your packages and see if it builds with vala:0.10, if not, you should depend on slot 0. Note that the 0.10 slot does not install unversioned binaries in order to not collide with slot 0 but packages using the proper autoconf macros should still "just work" (tested with gupnp-vala-0.6.11 which is not in tree yet). If you are ok with me changing your package please leave me a word here or on irc. TIA.
ftr, I added the slotmove a couple of minutes ago, so I'm changing the summary to reflect what the bug is about now.
At the same time, you might want to double check if you really need vala at build time since most projects actually provide pre-generated C files.
xfce4-vala *seemed* to work with 0.10, if you simply replace 'vala-1.0' with 'vala-0.10' in acinclude.m4 and run eautoreconf on the package. but i didn't do that, the package is already pulling in other obsolete deps, this just adds one more. let us know if you need the package to disappear, it can be done, otherwise we will wait for a bump. so to sum it up: xfce-extra/xfce4-vala deps fixed to :0 slot
slot 0 will live as long as needed (or at least I do not plan on killing it for the next 6 months).
(In reply to comment #6) > If you are ok with me changing your package please leave me a word here or on > irc. TIA. yes. please fix shotwell (bug 338259). what a mess ...
(In reply to comment #6) > If you are ok with me changing your package please leave me a word here or on > irc. TIA. > Feel free to go ahead with dotnet stuff, since I am not sure when I will be able to port them :-/
shotwell fixed.
Set monodevelop-vala to slot 0. It needs upstream work to detect versioned binaries.
(In reply to comment #14) > Set monodevelop-vala to slot 0. It needs upstream work to detect versioned > binaries. > Thanks :-)
shotwell seems fixed.
feel free to fix gmpc
Looks like gmpc is already fixed: 22 Sep 2010; Jim Ramsay <lack@gentoo.org> gmpc-0.20.0.ebuild: Now that vala is slotted, we need :0 since gmpc assumes "valac" is present and does not look for "valac-10"
Shouldn't there be an eselect module for vala which would create the symlinks or set the env vars?
the answer is no to both questions.
(In reply to comment #20) Sorry for bothering you, but why not to have eselect? For almost all packages we'll need the newest version of valac, only some old packages will need old ones. Other distributions provide symlink to current version of valac, maybe it will be enough to have "symlink" USE flag in vala ebuild?
Having an eselect module will not save you from actually fixing ebuilds. You have to add eclass functions to handle this, like python or ruby or java has to do. Also what you say is perfectly wrong, vala:0.12 is already in tree but most ebuilds and packages that get released today only depend on slot 0 and 0.10. You cannot assume that a package will build with a random version of vala without testing it. That's why defining slot usage is a task for the ebuild maintainer.
(In reply to comment #22) Sorry for my earlier comment and thanks a lot for explanations.
Current situation has a problem: 1. Now, we have some ebuilds depending on vala:0 slot. This SLOT is the last one providing unversioned binaries, that are still being used by most of that apps still requesting vala:0 2. Latest vala:0 version is 0.9.3, that is currently not maintained by upstream and, then, would be better to try to use 0.10.3 I understand Gilles point of view as, obviously, it's highly probable vala-0.12 is not compatible with 0.10 and, then, most of apps depending on vala would stop working. But it's also obvious that current situation is also suboptimal since I don't think will be save to keep vala-0.9.3 version forever simply because it's the latest one providing unversioned binaries. My suggestion is the following: 1. When a new major vala version arrives, we can proceed as now: bump it only for its latest SLOT to allow apps to be properly tested. 2. Once all depending apps work with that latest vala version, we should bump it also in slot 0 to provide unversioned binaries. It's a bit like opensuse is doing: they currently provides vala-0.10.2 as "main" vala version (that would be the equivalent of our slot 0) and also a "vala-unstable-0.11.4", that would be like our slots different than 0 (and not providing unversioned binaries). What do you think?
(In reply to comment #24) [..] > since I don't think will be save to keep vala-0.9.3 version forever simply save -> safe
vala:0 needs to die, it's getting old rapidly. If it was only me, I would rename the binaries to vala-0 and vapigen-0 so nobody is left in the dark wrt which version of vala is in use. Unfortunately, I don't think most ebuilds using vala would be ready to work this way. I don't think that keeping unversioned binaries around is a solution to anything, it would just make ebuild maintainers and upstream developers care even less about what slot their package is actually using which in the end only harms users. That's also why I have been opposed to writing a vala eselect module. Imho maintainers really need to fix their packages and that's all there is to it.
(In reply to comment #26) > vala:0 needs to die, it's getting old rapidly. If it was only me, I would > rename the binaries to vala-0 and vapigen-0 so nobody is left in the dark wrt > which version of vala is in use. Unfortunately, I don't think most ebuilds > using vala would be ready to work this way. Yes, it wouldn't work since I think that most if ebuilds still depending on vala:0 are simply needing it due unversioned binaries. > > I don't think that keeping unversioned binaries around is a solution to > anything, it would just make ebuild maintainers and upstream developers care > even less about what slot their package is actually using which in the end only > harms users. That's also why I have been opposed to writing a vala eselect > module. > > Imho maintainers really need to fix their packages and that's all there is to > it. > I thought about it and tried to take a look on one of the apps I maintain: monodevelop-vala. I saw it's working with vala-0.10.x releases in all distributions but Gentoo. Grepping "valac" in sources dir I got the following: $ grep -r valac * ChangeLog: * Project/ValaCompilationParameters.cs: Add support for valac -- [...] ChangeLog: to new projects by default. Track changes in valac. Compiler/ValaCompiler.cs: compilerCommand = "valac"; Compiler/ValaCompiler.cs: get{ return "valac"; } Compiler/ValaCompiler.cs: /// Error regex for valac templates/Makefile.am.template: valac $(VFLAGS) -o $(VTARGET) $(FILES) templates/Makefile.template: valac $(VFLAGS) -o $(VTARGET) $(FILES) Then, should I simply change "valac" invocations by "$(type -p valac-0.10)" with sed in ebuild? In that case, I think that we should try to "push" other people maintaining stuff that is still requiring slot:0 to do the same as I am mostly sure real consumers of such old vala versions are really a few. Thanks for your help :-) (I am mostly maintaining dotnet stuff because nobody cared of it in the past, then, if I have said anything stupid, sorry)
(In reply to comment #27) > (In reply to comment #26) > > I don't think that keeping unversioned binaries around is a solution to > > anything, it would just make ebuild maintainers and upstream developers care > > even less about what slot their package is actually using which in the end only > > harms users. That's also why I have been opposed to writing a vala eselect > > module. > > > > Imho maintainers really need to fix their packages and that's all there is to > > it. > > > > I thought about it and tried to take a look on one of the apps I maintain: > monodevelop-vala. I saw it's working with vala-0.10.x releases in all > distributions but Gentoo. Grepping "valac" in sources dir I got the following: > > $ grep -r valac * > ChangeLog: * Project/ValaCompilationParameters.cs: Add support for valac > -- > [...] > ChangeLog: to new projects by default. Track changes in valac. > Compiler/ValaCompiler.cs: compilerCommand = "valac"; > Compiler/ValaCompiler.cs: get{ return "valac"; } > Compiler/ValaCompiler.cs: /// Error regex for valac > templates/Makefile.am.template: valac $(VFLAGS) -o $(VTARGET) $(FILES) > templates/Makefile.template: valac $(VFLAGS) -o $(VTARGET) $(FILES) > > Then, should I simply change "valac" invocations by "$(type -p valac-0.10)" > with sed in ebuild? > > In that case, I think that we should try to "push" other people maintaining > stuff that is still requiring slot:0 to do the same as I am mostly sure real > consumers of such old vala versions are really a few. > > Thanks for your help :-) (I am mostly maintaining dotnet stuff because nobody > cared of it in the past, then, if I have said anything stupid, sorry) > Well, I don't want to force packages to update to a new slot if upstream doesn't even know it's working with it but if the only problem is that they are using unversioned binaries for a lack of configurability (defines at build time, env variable, whatever, ...) then, yes, patching is the way to go. In most cases, I'd recommend (for C code) to use a define that would be assigned the value detected by autoconf which is set properly by ebuilds defining slot dependencies.
OK, monodevelop-vala now has a revision using vala-0.10. Looking at opensuse, fedora, mandriva and OpenBSD, looks like the following should also being able to work with 0.10 (maybe probably also need some work downstream to make them stop using unversioned binaries): tracker-0.8.17.ebuild (I can see Mandriva provides it with vala-0.10) gmpc (fedora is shipping it with 0.10) pino (needs a patch from opensuse http://download.opensuse.org/source/factory/repo/oss/suse/src/pino-0.2.11-2.12.src.rpm ) midori (opensuse is providing it with vala-0.10) I would vote for CC their maintainers here asking them to try to make them use versioned binaries and depend on :0.10 slot if possible. The only case I don't know is "radare"
they are most likely already CCed, except for pino which is handled by nirbheek iirc who gave me green light to do vala work on it as needed.
Feel free to patch www-client/midori to use versioned binaries, upstream doesn't seem intrested as his distro only ships unversioned (and latest) ones. The vala-0.10 (and propably up) has been there since several versions ago already... I have no plans in working on it, so it'll be stuck at :0 until someone does
(In reply to comment #30) > they are most likely already CCed, except for pino which is handled by nirbheek > iirc who gave me green light to do vala work on it as needed. > Sadly, even with the patch it still fails to build (I can open a but here if Nirbheek wants), I have commented it in upstream bug: http://code.google.com/p/pino-twitter/issues/detail?id=309
(In reply to comment #31) > Feel free to patch www-client/midori to use versioned binaries, upstream > doesn't seem intrested as his distro only ships unversioned (and latest) ones. > The vala-0.10 (and propably up) has been there since several versions ago > already... > I have no plans in working on it, so it'll be stuck at :0 until someone does > And for this, my sed knowledge stops me from figuring how to *only* modify: conf.check_tool ('vala') :-(
A quick qgrep shows last offenders: gnome-extra/avant-window-navigator/avant-window-navigator-0.3.2.1.ebuild: vala? ( dev-lang/vala ) media-libs/memphis/memphis-0.2.2.ebuild: vala? ( dev-lang/vala )" media-libs/memphis/memphis-0.2.3.ebuild: vala? ( dev-lang/vala )" media-sound/spek/spek-0.6.ebuild: dev-lang/vala net-libs/libproxy/libproxy-0.4.6-r1.ebuild: vala? ( dev-lang/vala ) sci-geosciences/gpxviewer/gpxviewer-0.2.0.ebuild: >=dev-lang/vala-0.7 I'll get to them asap if nobody objects before I'm finished.
Valide bug #279458 should be probably also added to the 'list'.
(In reply to comment #35) > Valide bug #279458 should be probably also added to the 'list'. > This is only for ebuilds in the tree
(In reply to comment #34) > A quick qgrep shows last offenders: > > gnome-extra/avant-window-navigator/avant-window-navigator-0.3.2.1.ebuild: > vala? ( dev-lang/vala ) > media-libs/memphis/memphis-0.2.2.ebuild: vala? ( dev-lang/vala )" > media-libs/memphis/memphis-0.2.3.ebuild: vala? ( dev-lang/vala )" > media-sound/spek/spek-0.6.ebuild: dev-lang/vala > net-libs/libproxy/libproxy-0.4.6-r1.ebuild: vala? ( dev-lang/vala ) > sci-geosciences/gpxviewer/gpxviewer-0.2.0.ebuild: >=dev-lang/vala-0.7 > > I'll get to them asap if nobody objects before I'm finished. > Maintainers, would be even better if you try to make them work with :0.10 SLOT, it's more future proof and usually only requires some changes in configure scripts if they don't honor VALAC Thanks
All done (when depending bugs are solved) but midori, that I have been unable to modify wscript to look for vala-0.10, Can anybody look at it? Thanks
$ egrep "valac" -ir . ./extensions/wscript_build: elif 'VALAC' in bld.env and fila[-5:] == '.vala': ./extensions/wscript_build: elif 'VALAC' in bld.env and extension[-5:] == '.vala': ./tests/wscript_build: elif 'VALAC' in bld.env and file[-5:] == '.vala': ./tests/wscript_build: elif 'VALAC' in bld.env and test[-5:] == '.vala': ./wscript: if find_program_impl (conf.env, 'valac'): ./wscript: conf.check_message ('program', 'valac', False, False) setting VALAC or valac should do the job.
Sadly it's not respected :-( >>> Configuring source in /var/tmp/portage/www-client/midori-0.3.2/work/midori-0.3.2 ... * Sorry, but midori does not support the LINGUAS: es_ES en_US CCFLAGS="-march=native -O2 -pipe" LINKFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" "/var/tmp/portage/www-client/midori-0.3.2/work/midori-0.3.2/waf" --prefix=/usr --libdir=/usr/lib64 --docdir=/usr/share/doc/midori-0.3.2/html --disable-docs --enable-addons --disable-apidocs --enable-userdocs --disable-libidn --enable-libnotify --enable-nls --enable-unique --enable-vala configure Checking for program gcc or cc : /usr/lib/ccache/bin/gcc Checking for program cpp : /usr/bin/cpp Checking for program ar : /usr/bin/ar Checking for program ranlib : /usr/bin/ranlib Checking for gcc : ok Checking for program valac : not found Vala is required for some extensions. Pass --disable-vala to not build with Vala. * ERROR: www-client/midori-0.3.2 failed (configure phase): * configure failed * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 5521: Called waf-utils_src_configure '--docdir=/usr/share/doc/midori-0.3.2/html' '--disable-docs' '--enable-addons' '--disable-apidocs' '--enable-userdocs' '--disable-libidn' '--enable-libnotify' '--enable-nls' '--enable-unique' '--enable-vala' * environment, line 6110: Called die * The specific snippet of code: * CCFLAGS="${CFLAGS}" LINKFLAGS="${LDFLAGS}" "${WAF_BINARY}" "--prefix=${EPREFIX}/usr" "--libdir=${EPREFIX}/usr/$(get_libdir)" "$@" configure || die "configure failed" * * If you need support, post the output of 'emerge --info =www-client/midori-0.3.2', * the complete build log and the output of 'emerge -pqv =www-client/midori-0.3.2'. * The complete build log is located at '/var/log/portage/build/www-client/midori-0.3.2:20110307-123958.log'. * The ebuild environment file is located at '/var/tmp/portage/www-client/midori-0.3.2/temp/environment'. * S: '/var/tmp/portage/www-client/midori-0.3.2/work/midori-0.3.2'
Another perfect example of how waf is broken. > if find_program_impl (conf.env, 'valac'): this function call does not know how to get this binary from an environment variables, you have to do it like this: > if find_program_impl (conf.env, 'valac', var='VALAC'): and then, it will still not work since it absolutely wants a binary named 'valac', not valac-${SLOT}. Changing the line to: > if find_program_impl (conf.env, 'valac-0.10', var='VALAC'): will finally make it work, yay waf ! :'(
Done, thanks a lot
+ 08 Mar 2011; Michael Weber <xmw@gentoo.org> spek-0.6.ebuild: + Change vala dependency to vala:0.10 (bug 338067) + Index: spek-0.6.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/media-sound/spek/spek-0.6.ebuild,v retrieving revision 1.1 diff -u -B -r1.1 spek-0.6.ebuild --- spek-0.6.ebuild 4 Oct 2010 23:26:39 -0000 1.1 +++ spek-0.6.ebuild 8 Mar 2011 00:28:35 -0000 @@ -18,7 +18,7 @@ >=x11-libs/gtk+-2.18:2" DEPEND="${RDEPEND} - dev-lang/vala + dev-lang/vala:0.10 dev-util/intltool dev-util/pkgconfig sys-devel/gettext"
xfce4-vala doesn't exist anymore, midori and postler use vala:0.10 - guess xfce is fine, re-CC us if I've missed something.
All seems ok now
*** Bug 363819 has been marked as a duplicate of this bug. ***
*** Bug 371731 has been marked as a duplicate of this bug. ***
*** Bug 500340 has been marked as a duplicate of this bug. ***
*** Bug 503854 has been marked as a duplicate of this bug. ***
dev-lang/vala-0.24.0-r1 again/still ships no symlink. Therefore some configure scripts still crash, e.g. venom (ebuild and log attached). I don't know how to reopen that bug (_if_ I can do this anyway), but this should be fixed. :) Greetings, holgersson
Created attachment 377720 [details] venom ebuild from overlay
Created attachment 377722 [details] build.log of 'emerge --color=n -1 venom'
Created attachment 377724 [details] build.log of 'emerge --color=n -1 venom' this time the right one without color ;)
(In reply to holgersson from comment #50) > dev-lang/vala-0.24.0-r1 again/still ships no symlink. Therefore some > configure scripts still crash, e.g. venom (ebuild and log attached). yep, there should be no symlink, fix your ebuild to use versioned binaries
As Samuli said - all in-tree ebuilds are fixed. Overlay ebuilds should be fixed by overlay maintainers. You can find overlay maintainers' contact e-mail from repositories.xml[1] if it's included in layman. For other overlays, see overlay's homepage(if it's exists) or search for contacts in overlay itself(usually Documentation folder, but it's not standart, so results may vary). [1] - https://api.gentoo.org/overlays/repositories.xml
