Hi, not sure this is the place to post this, please tell me if this doesn't belong here.
I am testing 13.2, trying to install virt-manager gave me:
localhost:/ # zypper in virt-manager Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libvte2_90-9 needed by virt-manager-1.0.1-14.3.1. noarch Solution 1: do not install virt-manager-1.0.1-14.3.1.noarch Solution 2: break virt-manager-1.0.1-14.3.1.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
Can somebody fix this, please.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 15.10.14 schrieb Mustafa Muhammad:
Hi, not sure this is the place to post this, please tell me if this doesn't belong here.
I am testing 13.2, trying to install virt-manager gave me:
On my tumbleweed machine I get something like this, just with typelib(AppIndicator3) as failed 'requires'...
(Sorry, I am on another machine, I can post the exact message tomorrow)
Regards, Johannes - -- `Three Dementor attacks in a week, and all Romilda Vane does is ask me if it's true you've got a Hippogriff tattooed across your chest´ [...] `I told her it's a hungarian Horntail,´ said Ginny, turning a page of her newspaper idly.`Much more Macho´ (Ginny Weasley in Harry Potter 6)
Hi,
I used YaST to install 'KVM Server' and 'KVM Tools'. In order to suceed I add to insert the 13.2 install DVD as required by the installation process. It looks indeed like dependencies are missing in repos.
Regards Paul
On Wed, Oct 15, 2014 at 9:17 PM, Johannes Kastl mail@ojkastl.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 15.10.14 schrieb Mustafa Muhammad:
Hi, not sure this is the place to post this, please tell me if this doesn't belong here.
I am testing 13.2, trying to install virt-manager gave me:
On my tumbleweed machine I get something like this, just with typelib(AppIndicator3) as failed 'requires'...
(Sorry, I am on another machine, I can post the exact message tomorrow)
Regards, Johannes
`Three Dementor attacks in a week, and all Romilda Vane does is ask me if it's true you've got a Hippogriff tattooed across your chest´ [...] `I told her it's a hungarian Horntail,´ said Ginny, turning a page of her newspaper idly.`Much more Macho´ (Ginny Weasley in Harry Potter 6) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/
iEYEARECAAYFAlQ+yFMACgkQzi3gQ/xETbIiMwCfc09IwtWGM96gO4LlYwjl5g8L Z3UAnAgBnKK9nsOoDaeuTCaCkwOldVph =4P18 -----END PGP SIGNATURE-----
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2014-10-15 at 11:50 +0300, Mustafa Muhammad wrote:
Hi, not sure this is the place to post this, please tell me if this doesn't belong here.
I am testing 13.2, trying to install virt-manager gave me:
localhost:/ # zypper in virt-manager Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libvte2_90-9 needed by virt-manager-1.0.1-14.3.1. noarch Solution 1: do not install virt-manager-1.0.1-14.3.1.noarch Solution 2: break virt-manager-1.0.1-14.3.1.noarch by ignoring some of its dependencies
That's actually a real thing: libvte2_90 no longer exists in favor of libvte2_91; and that's the reason why implicit library dependencies on a package are just a bad thing :)
The good news though: the next snapshot has this corrected; virt-manager's spec-file has been updated to perform automatic dependency scanning (using gobject introspection, typelib() Dependencies).
The version that should have that will be 1.0.1-18.1 (or higher).
The changelog mentions: +- Remove hardcoded package dependencies in spec file and instead + use gobject-introspection + virt-manager.spec
Cheers, Dominique
Hi.
El Jueves, 16 de octubre de 2014 12:21:17 Dimstar / Dominique Leuenberger escribió:
That's actually a real thing: libvte2_90 no longer exists in favor of libvte2_91; and that's the reason why implicit library dependencies on a package are just a bad thing :)
The good news though: the next snapshot has this corrected; virt-manager's spec-file has been updated to perform automatic dependency scanning (using gobject introspection, typelib() Dependencies).
The version that should have that will be 1.0.1-18.1 (or higher).
The changelog mentions: +- Remove hardcoded package dependencies in spec file and instead
- use gobject-introspection
- virt-manager.spec
Cheers, Dominique
What is necessary to achieve this goal? I have the same problem with Tilda. Do you need BuildRequires: gobject-introspection only or something else too?
Greetings.
On Thu, 2014-10-16 at 12:38 +0200, jcsl wrote:
Hi.
El Jueves, 16 de octubre de 2014 12:21:17 Dimstar / Dominique Leuenberger escribió:
That's actually a real thing: libvte2_90 no longer exists in favor of libvte2_91; and that's the reason why implicit library dependencies on a package are just a bad thing :)
The good news though: the next snapshot has this corrected; virt-manager's spec-file has been updated to perform automatic dependency scanning (using gobject introspection, typelib() Dependencies).
The version that should have that will be 1.0.1-18.1 (or higher).
The changelog mentions: +- Remove hardcoded package dependencies in spec file and instead
- use gobject-introspection
- virt-manager.spec
Cheers, Dominique
What is necessary to achieve this goal? I have the same problem with Tilda. Do you need BuildRequires: gobject-introspection only or something else too?
'It depends';
BuildRequires gobject-introspection pulls in an dependency scanner that parses code (currently python and javascript) for known pattern to import object introspection bindings (packaged as typelib-1_0-<NAME>-<VERSION>, files installed in %{_libdir}/girepository-1.0/<NAME>-<VERSION>.typelib
IF your code uses these (in the form of "from gi.repository import Vte" for example, then, YES, adding gobject-introspection as BuildDep is the right thing. the .typelib's themselves have a further dependency down to the actual library, so you don't have to worry about this.
Care is to be given to those imports, as they are 'unversioned'. So a new library might have a different API/ABI and break silently. Or zypp might not know which package to install if there is more than one available..
As an example: we have typelib-1_0-WebKitGtk-1_0 and typelib-1_0-WebKitGtk-3_0 (the GTK2 and GTK3 branches)
If you simply specify from gi.repository import WebKitGtk, this will translate to an RPM Dependency (typelib(WebKitGtk), which is provided by both packages. In cae of WebKit, you very often know that you need the one or the other, so you can 'force' this with import gi gi.require_version('WebKitGtk', '3.0') from gi.repository import WebKitGtk
=> the dep scanner will also interpret this and add a typelib(WebKitGtk) = 3.0 dependency. (so in short: the dep scanner is as good as the code it scans; it can't guess anything more or less).
There is usually ONE more Requires to specify, which the scanner can't do (yet): python-gobject or python3-gobject. The scanner does not know what your code will be executed with. So we can't add this just as part of the scan run at the moment.
Cheers, Dominique
Hi Dominique,
the gi-find-desp.sh also adds Requires for imports in try/except blocks, which are optional.
possible fix: for module in $(egrep -h "try:|except.*:|from gi.repository import (\w+)" $1 \ | sed -ne '/try:/ { :start; n ; /except.*:/ { d; b }; bstart }; p ' \ | sed -e 's:#.*::' -e 's:raise ImportError.*::' -e 's:.*"from gi.repository import Foo".*::' | sed -e 's,from gi.repository import,,' -r -e 's:\s+$::g' -e 's:\s+as\s+\w+::g' -e 's:,: :g'); do split_name_version $module print_req_prov # Temporarly disabled... this is not true if the python code is written for python3... And there seems no real 'way' to identify this. # echo "python-gobject >= 2.21.4" done
This strips the try:/except.*/ blocks before any further processing.
One example is the Appindicator3 import in /usr/share/virt-manager/virtManager/systray.py.
Kind regards,
Stefan
Thanks Stefan,
the Try/Except is indeed a known shortcoming; stripping them would be incorrecr in my opinion; IF at all handle them, we should change those to Recommends.
As for AppIndicator: the package typelib-1_0-AppIndicator3-0_1 exists in Factory and satisfy this requirement; so your example is a non-issue.
Dominique
On Thu, 2014-10-16 at 17:23 +0200, Stefan Brüns wrote:
Hi Dominique,
the gi-find-desp.sh also adds Requires for imports in try/except blocks, which are optional.
possible fix: for module in $(egrep -h "try:|except.*:|from gi.repository import (\w+)" $1 \ | sed -ne '/try:/ { :start; n ; /except.*:/ { d; b }; bstart }; p ' \ | sed -e 's:#.*::' -e 's:raise ImportError.*::' -e 's:.*"from gi.repository import Foo".*::' | sed -e 's,from gi.repository import,,' -r -e 's:\s+$::g' -e 's:\s+as\s+\w+::g' -e 's:,: :g'); do split_name_version $module print_req_prov # Temporarly disabled... this is not true if the python code is written for python3... And there seems no real 'way' to identify this. # echo "python-gobject >= 2.21.4" done
This strips the try:/except.*/ blocks before any further processing.
One example is the Appindicator3 import in /usr/share/virt-manager/virtManager/systray.py.
Kind regards,
Stefan
On Thursday, October 16, 2014 05:30:04 PM Dimstar / Dominique Leuenberger wrote:
Thanks Stefan,
the Try/Except is indeed a known shortcoming; stripping them would be incorrecr in my opinion; IF at all handle them, we should change those to Recommends.
As for AppIndicator: the package typelib-1_0-AppIndicator3-0_1 exists in Factory and satisfy this requirement; so your example is a non-issue.
Recommends would be ok, I guess.
Currently virt-manager is non-installable from the virtualization repo for any released openSUSE version.
Regards, Stefan
On Thu, 2014-10-16 at 17:49 +0200, Stefan Brüns wrote:
On Thursday, October 16, 2014 05:30:04 PM Dimstar / Dominique Leuenberger wrote:
Thanks Stefan,
the Try/Except is indeed a known shortcoming; stripping them would be incorrecr in my opinion; IF at all handle them, we should change those to Recommends.
As for AppIndicator: the package typelib-1_0-AppIndicator3-0_1 exists in Factory and satisfy this requirement; so your example is a non-issue.
Recommends would be ok, I guess.
Partially; I am certain I have a couple packages that will fail there as well (there is a couple users that simply do not like recommended packages)
Currently virt-manager is non-installable from the virtualization repo for any released openSUSE version.
Two variants: either provide the optional dep to those packages or filter the dep out of RPM during build (conditionally, for openSUSE versions where the package did not exist:
%if 0%{?suse_version} < 1320 %global __requires_exclude typelib\(AppIndicator3\) %endif
Cheers, Dominique
* Dimstar / Dominique Leuenberger dimstar@opensuse.org [2014-10-16 17:31]:
the Try/Except is indeed a known shortcoming; stripping them would be incorrecr in my opinion; IF at all handle them, we should change those to Recommends.
Can't you use modulefinder to preprocess the imported modules instead of this rather fragile sed hack?
Hi.
El Jueves, 16 de octubre de 2014 13:02:25 Dimstar / Dominique Leuenberger escribió:
On Thu, 2014-10-16 at 12:38 +0200, jcsl wrote:
Hi.
El Jueves, 16 de octubre de 2014 12:21:17 Dimstar / Dominique Leuenberger
escribió:
That's actually a real thing: libvte2_90 no longer exists in favor of libvte2_91; and that's the reason why implicit library dependencies on a package are just a bad thing :)
The good news though: the next snapshot has this corrected; virt-manager's spec-file has been updated to perform automatic dependency scanning (using gobject introspection, typelib() Dependencies).
The version that should have that will be 1.0.1-18.1 (or higher).
The changelog mentions: +- Remove hardcoded package dependencies in spec file and instead
- use gobject-introspection
- virt-manager.spec
Cheers, Dominique
What is necessary to achieve this goal? I have the same problem with Tilda. Do you need BuildRequires: gobject-introspection only or something else too?
'It depends';
BuildRequires gobject-introspection pulls in an dependency scanner that parses code (currently python and javascript) for known pattern to import object introspection bindings (packaged as typelib-1_0-<NAME>-<VERSION>, files installed in %{_libdir}/girepository-1.0/<NAME>-<VERSION>.typelib
IF your code uses these (in the form of "from gi.repository import Vte" for example, then, YES, adding gobject-introspection as BuildDep is the right thing. the .typelib's themselves have a further dependency down to the actual library, so you don't have to worry about this.
Care is to be given to those imports, as they are 'unversioned'. So a new library might have a different API/ABI and break silently. Or zypp might not know which package to install if there is more than one available..
As an example: we have typelib-1_0-WebKitGtk-1_0 and typelib-1_0-WebKitGtk-3_0 (the GTK2 and GTK3 branches)
If you simply specify from gi.repository import WebKitGtk, this will translate to an RPM Dependency (typelib(WebKitGtk), which is provided by both packages. In cae of WebKit, you very often know that you need the one or the other, so you can 'force' this with import gi gi.require_version('WebKitGtk', '3.0') from gi.repository import WebKitGtk
=> the dep scanner will also interpret this and add a typelib(WebKitGtk) = 3.0 dependency. (so in short: the dep scanner is as good as the code it scans; it can't guess anything more or less).
There is usually ONE more Requires to specify, which the scanner can't do (yet): python-gobject or python3-gobject. The scanner does not know what your code will be executed with. So we can't add this just as part of the scan run at the moment.
Cheers, Dominique
Thanks for the clarification Dominique.
Greetings.
On Thursday 2014-10-16 12:21, Dimstar / Dominique Leuenberger wrote:
On Wed, 2014-10-15 at 11:50 +0300, Mustafa Muhammad wrote:
Problem: nothing provides libvte2_90-9 needed by virt-manager-1.0.1-14.3.1. noarch Solution 1: do not install virt-manager-1.0.1-14.3.1.noarch Solution 2: break virt-manager-1.0.1-14.3.1.noarch by ignoring some of its dependencies
That's actually a real thing: libvte2_90 no longer exists in favor of libvte2_91; and that's the reason why implicit library dependencies on a package are just a bad thing :)
An implicit dependency would look like libvte-2.90.so()(64bit) - you probably meant an explicit one.
On Thu, 2014-10-16 at 13:29 +0200, Jan Engelhardt wrote:
On Thursday 2014-10-16 12:21, Dimstar / Dominique Leuenberger wrote:
On Wed, 2014-10-15 at 11:50 +0300, Mustafa Muhammad wrote:
Problem: nothing provides libvte2_90-9 needed by virt-manager-1.0.1-14.3.1. noarch Solution 1: do not install virt-manager-1.0.1-14.3.1.noarch Solution 2: break virt-manager-1.0.1-14.3.1.noarch by ignoring some of its dependencies
That's actually a real thing: libvte2_90 no longer exists in favor of libvte2_91; and that's the reason why implicit library dependencies on a package are just a bad thing :)
An implicit dependency would look like libvte-2.90.so()(64bit) - you probably meant an explicit one.
Ups; yes, of course.. that's what I meant.. the things the packager types :)
On Wed, Oct 15, 2014 at 11:50 AM, Mustafa Muhammad mustafaa.alhamdaani@gmail.com wrote:
Hi, not sure this is the place to post this, please tell me if this doesn't belong here.
I am testing 13.2, trying to install virt-manager gave me:
localhost:/ # zypper in virt-manager Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libvte2_90-9 needed by virt-manager-1.0.1-14.3.1. noarch Solution 1: do not install virt-manager-1.0.1-14.3.1.noarch Solution 2: break virt-manager-1.0.1-14.3.1.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
Can somebody fix this, please.
8 day until release and this is still broken, we should not ship with broken deps, and virt-manager is very important, please somebody fix this.
3 day until release, please don't tell me we want to ship 13.2 with broken dependencies. This would be shame.
On Sun, Oct 26, 2014 at 11:13 PM, Mustafa Muhammad mustafaa.alhamdaani@gmail.com wrote:
On Wed, Oct 15, 2014 at 11:50 AM, Mustafa Muhammad mustafaa.alhamdaani@gmail.com wrote:
Hi, not sure this is the place to post this, please tell me if this doesn't belong here.
I am testing 13.2, trying to install virt-manager gave me:
localhost:/ # zypper in virt-manager Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libvte2_90-9 needed by virt-manager-1.0.1-14.3.1. noarch Solution 1: do not install virt-manager-1.0.1-14.3.1.noarch Solution 2: break virt-manager-1.0.1-14.3.1.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
Can somebody fix this, please.
8 day until release and this is still broken, we should not ship with broken deps, and virt-manager is very important, please somebody fix this.
On Sat, Nov 01, 2014 at 09:28:16AM +0300, Mustafa Muhammad wrote:
3 day until release, please don't tell me we want to ship 13.2 with broken dependencies. This would be shame.
The tool to track bugs is bugzilla and not this list.
http://maintainer.zq1.de/ is beside 'osc mainatiner -e' one of the tools to get the correct bug owner from the beginning.
It's ok to ask for help or directions here on the list but bugs have to be tracked in bugzilla.
Please reference this thread - link to it in the list archive - in your bugreport and report the bug ID later to this thread too.
Cheers,
Lars
On Sat, Nov 1, 2014 at 7:17 PM, Lars Müller lmuelle@suse.com wrote:
On Sat, Nov 01, 2014 at 09:28:16AM +0300, Mustafa Muhammad wrote:
3 day until release, please don't tell me we want to ship 13.2 with broken dependencies. This would be shame.
The tool to track bugs is bugzilla and not this list.
http://maintainer.zq1.de/ is beside 'osc mainatiner -e' one of the tools to get the correct bug owner from the beginning.
It's ok to ask for help or directions here on the list but bugs have to be tracked in bugzilla.
Please reference this thread - link to it in the list archive - in your bugreport and report the bug ID later to this thread too.
Cheers,
Lars
This got fixed now, so I won't file a bug report, but I'll do next time :)
Cheers
-- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
-
Dimstar / Dominique Leuenberger -
Guido Berhoerster -
Jan Engelhardt -
jcsl -
Johannes Kastl -
Lars Müller -
Mustafa Muhammad -
Paul Gonin -
Stefan Brüns