On Thursday 2014-01-16 00:58, Marco Cimmino Gibellini wrote:

Hi, unluckily Skype is a 32-bit binary only and to communicate with PulseAudio it requires also alsa-plugins-pulse at 32-bit

What I mean is: no program normally depends on alsa-pulse, but just alsa.

This actually started since openSUSE 13.1 64-bit, that package for some reason was not required on openSUSE 12.1 64-bit

It is a plugin, and the general idea of plugins is to be optional. My system for example has no alsa-plugin-pulse installed, and I still have sound through alsa/libasound. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thursday 2014-01-16 01:59, Marco Cimmino Gibellini wrote:

Ok, anyway, what I am trying to achieve is the following: depends on alsa-plugins-pulse for 32-bit openSUSE and on alsa-plugins-pulse-32bit for 64-bit openSUSE, all using the SAME rpm package that is built using 32-bit openSUSE.

Again, on Fedora I can just add (x86-32) after the package name, on openSUSE how can achieve that? For now I either got an rpm working on 32-bit openSUSE or 64-bit openSUSE, not one that works for both.

%if 0{?suse_version} ExclusiveArch: i586 Recommends: libasound_conf_pulse.so %endif (This shall work because 64-bit copy of plugin-pulse is represented using a different string, namely libasound_conf_pulse.so()(64bit) .) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Donnerstag, 16. Januar 2014, 09:23:59 wrote Adrian Schröter:

On Donnerstag, 16. Januar 2014, 02:11:58 wrote Jan Engelhardt:

...

On Thursday 2014-01-16 01:59, Marco Cimmino Gibellini wrote:

...

Ok, anyway, what I am trying to achieve is the following: depends on alsa-plugins-pulse for 32-bit openSUSE and on alsa-plugins-pulse-32bit for 64-bit openSUSE, all using the SAME rpm package that is built using 32-bit openSUSE.

Again, on Fedora I can just add (x86-32) after the package name, on openSUSE how can achieve that? For now I either got an rpm working on 32-bit openSUSE or 64-bit openSUSE, not one that works for both.

%if 0{?suse_version} ExclusiveArch: i586 Recommends: libasound_conf_pulse.so %endif

You miss the ExportFilter: rule with this approach. Otherwise the x86_64 scheduler will never see the package from i586 build. But ...

erm, this is true for build -32bit packages....

...

(This shall work because 64-bit copy of plugin-pulse is represented using a different string, namely libasound_conf_pulse.so()(64bit) .)

yep, you are 100% right here. /me grabs a coffee first adrian

.. we have actually the baselibs mechanism in OBS for such tasks. It is a simple text file, which will be used automatically if a i586 build runs and it will generate some extra packages with the listed binary files for the other architecture.

Check for example the openssl baselibs.conf file. You need nothing else then to place such a file next to your spec file and the build script and OBS takes care for the rest:

osc cat openSUSE:Factory openssl baselibs.conf

-- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Jan 16, 2014 at 04:09:18PM +0100, Ludwig Nussel wrote:

Marco is right though. The package name is not the same for the normal i586 package and the 32bit one. Therefore the automatic provides are different and the %name(x86-32) one is basically useless.

The regular package would provide

%name(x86-32) = %version-%release

while the -32bit version basically has

%name-32bit(x86-32) = %version-%release

So what's missing is the original name with architecture. In the concrete case of alsa-plugins-pulse-32bit it provides only alsa-plugins-pulse-32bit(x86-32) instead of alsa-plugins-pulse(x86-32)

It's not missing. It also does not provide "alsa-plugins-pulse" and you're not arguing that the provides is missing. (The color-extended self provides really don't make much sense for suse systems, they only got added by Fedora because they have multiple packages with the same name and different arch installed and had no way to address the specific architecture.) M. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Le 16/01/2014 20:50, Marco Cimmino Gibellini a écrit :

Hi again, I am honest with you, I am not really interested in internal discussions, nor you telling me how I should code or not code. Since Skype does NOT make calls on openSUSE 13.1 64-bit out of the box, I need to address this issue pulling the right dependencies to make this happen.

I am asking a simple question I think and I did not get a specific answer or maybe I got lost with the too many of them. Is there a way in openSUSE to create ONE single RPM that is MULTIARCH, like all the major distributions allows since ~2012, that pulls a SPECIFIC package at 32-bit, regardless the running openSUSE arch underneath. This package is indeed: alsa-plugins-pulse(x86-32)

So far I tried many ways and either works for 32-bit only or 64-bit, it does not work for both or sometimes it failed to work at all. Someone else suggested to depend on a specific library name, don't like too much this approach, seems just a workaround and may break with library's name change in the future, but if it is the only way ok, is this going to work? Requires: libasound_conf_pulse.so

best Marco

----- Linux UI team, Skype UI developer

see & chat: marco write: marco.cimmino@skype.net-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

As mentioned in a previous mail, we use baselibs.conf to configure a lot of things. You just have to explicitely require $PACKAGE-32bits to get it working on openSUSE. Regards. Benjamin -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 01/16/2014 08:50 PM, Marco Cimmino Gibellini wrote:

I am honest with you, I am not really interested in internal discussions, nor you telling me how I should code or not code. Since Skype <snipped .../>

ouch. You started this whole thing with a *private* email to me and mls, (whereever you got the idea from that one of us two could or may help you - failing cowardly to go the easy and obvious way to help yourself to one of openSUSE's mailing lists), so IMHO you got already more help than one ever could have expected with such an approach. To be honest to you, I think you should be more grateful to people helping you in their *spare time*. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 01/17/2014 12:50 AM, Adam Spiers wrote:

Bernhard Voelker (mail@bernhard-voelker.de) wrote:

...

On 01/16/2014 08:50 PM, Marco Cimmino Gibellini wrote:

...

I am honest with you, I am not really interested in internal discussions, nor you telling me how I should code or not code. Since Skype <snipped .../>

ouch. You started this whole thing with a *private* email to me and mls, (whereever you got the idea from that one of us two could or may help you - failing cowardly to go the easy and obvious way to help yourself to one of openSUSE's mailing lists), so IMHO you got already more help than one ever could have expected with such an approach.

To be honest to you, I think you should be more grateful to people helping you in their *spare time*.

Maybe, but we should also be grateful that Skype is continuing to try to provide packages for openSUSE. That's a lot better than some other companies whose support for most Linux distributions is either non-existent or dismal :-(

Sure. Maybe my answer was a bit harsh - I was maybe a bit huffy because I think these are no "internal discussions": as in virtually any computing problem, there are several ways to to accomplish a task, so there may not be one single golden rule to do it ... hey, that's *the cool thing* about software engineering - it's all like a puzzle. And if you ask 10 people about it, then you may get 11 different answers. ;-) Have a nice day. Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Marco Cimmino Gibellini (marco.cimmino@skype.net) wrote:

If openSUSE community is however not interested in a fully working out-of-the-box openSUSE rpm package then we may think to remove support for it and be happy with Fedora's RPM package which seems much easier to produce for us.

Of course we're interested :-) That's why you already got ~20 replies within 24 hours or so. But it seems your question is unusual enough that the right answer was not immediately obvious. Did you try Claudio's suggestion of Recommend: alsa-plugins-pulse-32bit ? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Friday 2014-01-17 06:23, Andrey Borzenkov wrote:

Is there any reason why 32 bit libraries cannot provide libname(32bit) just like 64 bit libraries provide libname(64bit)?

You do: rpm -ihv libfoo.i586.rpm rpm -ihv libfoo.x86_64.rpm Now assume there is a new version of libfoo (with same SONAME, which is entirely reasonable). rpm -U libfoo.i586.rpm would nuke libfoo.x86_64 from the system. rpm -i libfoo.i586.rpm would yield a conflict. What would be needed is a way to use both -i and -e in one call, which I do not remember being possible with stock rpm command line tool. The Fedora camp chose to sweep it under the rug, forcing users instead to use an advanced manager (iyum, zypper, etc.) which interacts with librpm and supports multiversion in some way. Problem 2: If you have libfoo-devel.i586 and libfoo-devel.x86_64, it is possible that they conflict too, as some upstreams put arch-specific parts in files shared\between the two (like .h files). (as such, Suse -devel-32bit do not include /usr/include files by default; and yes, we are taking some chances with that.) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

В Fri, 17 Jan 2014 09:54:08 +0000 Adam Spiers <aspiers@suse.com> пишет:

Andrey Borzenkov (arvidjaar@gmail.com) wrote:

...

On Fri, Jan 17, 2014 at 4:40 AM, Adam Spiers <aspiers@suse.com> wrote:

...

Marco Cimmino Gibellini (marco.cimmino@skype.net) wrote:

...

If openSUSE community is however not interested in a fully working out-of-the-box openSUSE rpm package then we may think to remove support for it and be happy with Fedora's RPM package which seems much easier to produce for us.

Of course we're interested :-) That's why you already got ~20 replies within 24 hours or so. But it seems your question is unusual enough

I rather consider unusual forcing two packages with identical content but different names.

Which two packages are you talking about?

I mean libfoo.i586 and libfoo-32bit.x86_64. They are identical. Being able to use the same libfoo.i586 on both 32 and 64 bit distro would be beneficial both from build time and space consumption point of view.

...

...

that the right answer was not immediately obvious. Did you try Claudio's suggestion of

Recommend: alsa-plugins-pulse-32bit

It does not work when using rpm directly

So? Plenty of things don't work when using rpm directly.

There is difference between missing automatic dependency resolution and download and silently installing package that cannot work correctly due to missing dependency. It is OK to not install package that lacks prerequisites (even though it could be annoying). It is not OK to silently install package that cannot work.

...

and even with zypper users are free to use --no-recommends.

But the vast majority of users won't, so that doesn't render the use of Recommend: pointless.

...

You can just as well simply describe this requirement on download page.

In preference to making it work automatically in the majority of cases?

This will make cases when it does not work even more mysterious and puzzling, unfortunately.

...

Is there any reason why 32 bit libraries cannot provide libname(32bit) just like 64 bit libraries provide libname(64bit)?

That sounds like a good idea to me.

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Jan 17, 2014 at 2:11 PM, Andrey Borzenkov <arvidjaar@gmail.com> wrote:

...

...

...

that the right answer was not immediately obvious. Did you try Claudio's suggestion of

Recommend: alsa-plugins-pulse-32bit

It does not work when using rpm directly

So? Plenty of things don't work when using rpm directly.

There is difference between missing automatic dependency resolution and download and silently installing package that cannot work correctly due to missing dependency. It is OK to not install package that lacks prerequisites (even though it could be annoying). It is not OK to silently install package that cannot work.

Very few people will use RPM directly. When you double-click an RPM in openSUSE, it's opened by default (last time I checked) with zypper (or something that uses libzypp), and zypper will know what to do. People that use RPM directly will know how to fix this (it's quite unlikely they'll be newbies). Now, I truly aggree: 32bit packages should add the provides for libname(32bit). But that will take time to be implemented (ie: next release). Recommends is a good workaround till then. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Jan 17, 2014 at 6:50 PM, Jan Engelhardt <jengelh@inai.de> wrote:

On Friday 2014-01-17 20:47, Claudio Freire wrote:

...

Now, I truly aggree: 32bit packages should add the provides for libname(32bit).

But they already have these provides!: "libfoo.so.0".

Oh, sorry, I meant libname-32bit -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am 2014-01-16 20:50, schrieb Marco Cimmino Gibellini:

Hi again, I am honest with you, I am not really interested in internal discussions, nor you telling me how I should code or not code. Since Skype does NOT make calls on openSUSE 13.1 64-bit out of the box, I need to address this issue pulling the right dependencies to make this happen.

I am asking a simple question I think and I did not get a specific answer or maybe I got lost with the too many of them. Is there a way in openSUSE to create ONE single RPM that is MULTIARCH, like all the major distributions allows since ~2012, that pulls a SPECIFIC package at 32-bit, regardless the running openSUSE arch underneath. This package is indeed: alsa-plugins-pulse(x86-32)

So far I tried many ways and either works for 32-bit only or 64-bit, it does not work for both or sometimes it failed to work at all. Someone else suggested to depend on a specific library name, don't like too much this approach, seems just a workaround and may break with library's name change in the future, but if it is the only way ok, is this going to work? Requires: libasound_conf_pulse.so

best Marco

There are many ways, you just have to decide what matches your case the best. Another approach may look like the following: 1) check, if you're building on x86_64 etc. 2) if the above AND building on SUSE, Require: alsa-plugins-pulse-32bit 3) if not on SUSE nor 64bit, always use the 'normal' package name %ifarch x86_64 amd64 ia32e %if 0%{suse_version} Requires: alsa-plugins-pulse-32bit %endif %else Requires: alsa-plugins-pulse(x86-32) %endif Easy and straightforward, don't you think? -- Aeneas Jaissle » e: aj@ajaissle.de Sent using Roundcube Webmail and Kolab on openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

There are many ways, you just have to decide what matches your case the best.

Another approach may look like the following:

1) check, if you're building on x86_64 etc.

I am always building on x86-32. In fact Skype is 32-bit only software. I think I mentioned this before, but worth mentioning again.

2) if the above AND building on SUSE, Require: alsa-plugins-pulse-32bit 3) if not on SUSE nor 64bit, always use the 'normal' package name

%ifarch x86_64 amd64 ia32e %if 0%{suse_version} Requires: alsa-plugins-pulse-32bit %endif %else Requires: alsa-plugins-pulse(x86-32) %endif

Easy and straightforward, don't you think?

Is this going to be in the .spec file when building the RPM? If yes, doesn't seem to solve my problem at all, since %ifarch x86_64 amd64 ia32e is going to be always false and then it will always require alsa-plugins-pulse(x86-32), which fails then to install on 64-bit openSUSE. As previously said I need to have ONE single RPM, created by ONE single build machine (32-bit openSUSE), that works for all openSUSE out there (forget about Fedora right now, that RPM is going to be built on a different machine). Rather this seems to be the solution in case we would build TWO different RPM packages from TWO different openSUSE build machines, one for x86-32 and one for x86-64. One more time: I am lacking to understand how to create a MULTIARCH single RPM package that pulls the same 32-bit package on both openSUSE 32 and 64-bit. So either I am lacking to understand your solution or I explained my point in a non clear way. Hope you can clarify. And thank you to everyone is trying to solve my problem in your spare time. best Marco ----- Linux UI team, Skype UI developer see & chat: marco write: marco.cimmino@skype.net ________________________________________ From: Aeneas Jaißle [aj@ajaissle.de] Sent: Thursday, January 16, 2014 3:09 PM To: opensuse-packaging@opensuse.org Cc: Marco Cimmino Gibellini Subject: RE: [opensuse-packaging] Re: RPM in openSUSE 13.1 Am 2014-01-16 20:50, schrieb Marco Cimmino Gibellini:

Hi again, I am honest with you, I am not really interested in internal discussions, nor you telling me how I should code or not code. Since Skype does NOT make calls on openSUSE 13.1 64-bit out of the box, I need to address this issue pulling the right dependencies to make this happen.

I am asking a simple question I think and I did not get a specific answer or maybe I got lost with the too many of them. Is there a way in openSUSE to create ONE single RPM that is MULTIARCH, like all the major distributions allows since ~2012, that pulls a SPECIFIC package at 32-bit, regardless the running openSUSE arch underneath. This package is indeed: alsa-plugins-pulse(x86-32)

So far I tried many ways and either works for 32-bit only or 64-bit, it does not work for both or sometimes it failed to work at all. Someone else suggested to depend on a specific library name, don't like too much this approach, seems just a workaround and may break with library's name change in the future, but if it is the only way ok, is this going to work? Requires: libasound_conf_pulse.so

best Marco

-- Aeneas Jaissle » e: aj@ajaissle.de Sent using Roundcube Webmail and Kolab on openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Freitag, 17. Januar 2014, 08:54:03 wrote Andreas Jaeger:

Looking at the provides of the two packages:

$ rpm -q --provides alsa-plugins-pulse-32bit alsa-plugins-pulse-32bit = 1.0.27-3.1.1 alsa-plugins-pulse-32bit(x86-32) = 1.0.27-3.1.1 libasound_module_conf_pulse.so libasound_module_ctl_pulse.so libasound_module_pcm_pulse.so

And looking at the 32-bit package: $ rpm -qp --provides alsa-plugins-pulse-1.0.27-3.1.1.i586.rpm alsa-plugins-pulse = 1.0.27-3.1.1 alsa-plugins-pulse(x86-32) = 1.0.27-3.1.1 config(alsa-plugins-pulse) = 1.0.27-3.1.1 libasound_module_conf_pulse.so libasound_module_ctl_pulse.so libasound_module_pcm_pulse.so

So, I propose to add: Requires: libasound_module_conf_pulse.so Requires: libasound_module_ctl_pulse.so Requires: libasound_module_pcm_pulse.so

And use %if 0%{?suse_version} around it. Note the question mark which was not in former mails. That way rpm-build will not fail, if that macro is not set at all (eg. on Fedora). good morning adrian

either of these three lines should work but adding all three will not harm ;)

Marco, does this work for you?

thanks a lot for fixing Skype properly for openSUSE! Andreas

-- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Saturday 2014-01-18 01:17, Marco Cimmino Gibellini wrote:

...

So, I propose to add: Requires: libasound_module_conf_pulse.so Requires: libasound_module_ctl_pulse.so Requires: libasound_module_pcm_pulse.so

It is not so elegant imo, in the sense that depends on a specific file name (libasound_module_pcm_pulse.so) that may change in the future

Package names may also change, so it's just choosing between two evils. ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thursday 16 January 2014 03:58:50 Marco Cimmino Gibellini wrote:

...

We do not use overlapping package names like Fedora. (You can't easily run rpm -U or rpm -i,-e on them in some cases.)

In other words, our package names / with arch symbols would be: Requires: libz1(x86-64) Requires: libz1-32bit(x86-32)

So you are saying we can include the following in the Requires: Requires: alsa-plugins-pulse(x86-32), alsa-plugins-pulse-32bit(x86-64)

Yours sounds odd as the '-32bit- package names are usually available on x86-64 and not x86-32 as far as I can tell.

If you install alsa-plugins-pulse without 32bit suffixbut of 32architecture on a 64-system, then it will make installation of the 64-bit package with the same name impossible, which may break many other programs. The packages marked as i586 architecture are not designed to be installed on a 64-bit system. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org