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 -- Dimstar / Dominique Leuenberger -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

-- Dimstar / Dominique Leuenberger -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 wrote:

On Wed, Oct 15, 2014 at 11:50 AM, 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

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Nov 1, 2014 at 7:17 PM, Lars Müller 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org