Enabling i586 arch in multimedia:libs
Hi, Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file). I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right? Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch? or is there some other recommended way? Thanks, -- Antonio Larrosa
On Donnerstag, 12. August 2021, 17:32:57 CEST Antonio Larrosa wrote:
Hi,
Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file).
I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right?
Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch? or is there some other recommended way?
should work. There is not much alternative at least when you do not want to go via additional steps like product building. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
Hi, Am Donnerstag, 12. August 2021, 17:38:38 CEST schrieb Adrian Schröter:
On Donnerstag, 12. August 2021, 17:32:57 CEST Antonio Larrosa wrote:
Hi,
Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file).
I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right?
Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch? or is there some other recommended way?
should work.
There is not much alternative at least when you do not want to go via additional steps like product building.
Note that the way -32bit packages are enabled in Leap is through the prjconf: %ifarch i586 i686 BuildFlags: onlybuild:pipewire %endif Otherwise everything will be "excluded". Cheers, Fabian
On Thu, 12 Aug 2021 17:48:16 +0200, Fabian Vogt wrote:
Hi,
Am Donnerstag, 12. August 2021, 17:38:38 CEST schrieb Adrian Schröter:
On Donnerstag, 12. August 2021, 17:32:57 CEST Antonio Larrosa wrote:
Hi,
Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file).
I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right?
Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch? or is there some other recommended way?
should work.
There is not much alternative at least when you do not want to go via additional steps like product building.
Note that the way -32bit packages are enabled in Leap is through the prjconf:
%ifarch i586 i686 BuildFlags: onlybuild:pipewire %endif
Otherwise everything will be "excluded".
Alternatively, add i586 to openSUSE_Leap_15.3, but disable the build for all as default, and selectively enable the build for pipewire and other library packages without publishing flag -- I suppose it would work? IMO, it's less obscure than prjconf and even package maintainer can change, so likely suitable for a devel project. thanks, Takashi
Hi, Am Freitag, 13. August 2021, 10:36:30 CEST schrieb Takashi Iwai:
On Thu, 12 Aug 2021 17:48:16 +0200, Fabian Vogt wrote:
Hi,
Am Donnerstag, 12. August 2021, 17:38:38 CEST schrieb Adrian Schröter:
On Donnerstag, 12. August 2021, 17:32:57 CEST Antonio Larrosa wrote:
Hi,
Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file).
I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right?
Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch? or is there some other recommended way?
should work.
There is not much alternative at least when you do not want to go via additional steps like product building.
Note that the way -32bit packages are enabled in Leap is through the prjconf:
%ifarch i586 i686 BuildFlags: onlybuild:pipewire %endif
Otherwise everything will be "excluded".
Alternatively, add i586 to openSUSE_Leap_15.3, but disable the build for all as default, and selectively enable the build for pipewire and other library packages without publishing flag -- I suppose it would work?
As long as the repository builds against SLE/Leap, the prjconf with its onlybuild flags is pulled in and the build enable flag won't suffice.
IMO, it's less obscure than prjconf and even package maintainer can change, so likely suitable for a devel project.
Yep, onlybuild is not great. It was used instead of build disabling because it can be defined once in the prjconf instead of in every project (main project, stagings, devel prj, maintenance, ...) separately. Cheers, Fabian
thanks,
Takashi
On Aug 13 2021, Fabian Vogt wrote:
As long as the repository builds against SLE/Leap, the prjconf with its onlybuild flags is pulled in and the build enable flag won't suffice.
That is not true. The onlybuild flags are only visible %if "%_project" == "openSUSE:Leap:15.3". There are more onlybuild flags in openSUSE:Backports:SLE-15-SP3, but again, they are only visible in that very project. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Hi, Am Montag, 16. August 2021, 14:38:02 CEST schrieb Andreas Schwab:
On Aug 13 2021, Fabian Vogt wrote:
As long as the repository builds against SLE/Leap, the prjconf with its onlybuild flags is pulled in and the build enable flag won't suffice.
That is not true. The onlybuild flags are only visible %if "%_project" == "openSUSE:Leap:15.3".
I didn't know that, it's apparently new for 15.3. For 15.2 it's still global. With that setup, all i586 packages outside of the project will try to build, but might turn unresolvable because its deps werent built in the distro. Cheers, Fabian
There are more onlybuild flags in openSUSE:Backports:SLE-15-SP3, but again, they are only visible in that very project.
Andreas.
On Mo, 2021-08-16 at 14:46 +0200, Fabian Vogt wrote:
Hi,
Am Montag, 16. August 2021, 14:38:02 CEST schrieb Andreas Schwab:
On Aug 13 2021, Fabian Vogt wrote:
As long as the repository builds against SLE/Leap, the prjconf with its onlybuild flags is pulled in and the build enable flag won't suffice.
That is not true. The onlybuild flags are only visible %if "%_project" == "openSUSE:Leap:15.3".
I didn't know that, it's apparently new for 15.3. For 15.2 it's still global. With that setup, all i586 packages outside of the project will try to build, but might turn unresolvable because its deps werent built in the distro.
Interesting facts - but every time I read something like this, I wonder who is supposed to know and remember these special details and exceptions. This is what makes OBS seem like black magic for non-gurus. The various settings in meta data, prjconf, spec files, and some hardcoded prefs in the build service tools work together in ways that seem pretty much unpredictable for me, and threads like this make me believe that I'm not alone. The documentation seems to touch just the tip of the iceberg. If I'm missing something, please educate me. I'm not complaining. I just feel that the high level of wizardry that's required to make certain things work as intended in OBS is detrimental for the overall efficiency of our work, and that everyone would benefit if we could simplify things somehow. Cheers, Martin
On Aug 12 2021, Adrian Schröter wrote:
On Donnerstag, 12. August 2021, 17:32:57 CEST Antonio Larrosa wrote:
Hi,
Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file).
I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right?
Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch? or is there some other recommended way?
should work.
There is not much alternative at least when you do not want to go via additional steps like product building.
There is a PublishFilter in openSUSE:Leap:15.3:Update. Does that have influence here? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On Montag, 16. August 2021, 14:43:10 CEST Andreas Schwab wrote:
On Aug 12 2021, Adrian Schröter wrote:
On Donnerstag, 12. August 2021, 17:32:57 CEST Antonio Larrosa wrote:
Hi,
Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file).
I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right?
Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch? or is there some other recommended way?
should work.
There is not much alternative at least when you do not want to go via additional steps like product building.
There is a PublishFilter in openSUSE:Leap:15.3:Update. Does that have influence here?
yes, it will have. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
On Thursday 2021-08-12 17:32, Antonio Larrosa wrote:
Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file).
I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right?
i586 workers are producing the -32bit.x86_64.rpm and store them in the corresponding i586 build dirs (/srv/obs/build/PROJ/REPO/i586/...) bs_sched copies this to the other arch (because `osc meta prjconf | grep -i exportfilter`) to /srv/obs/build/PROJ/REPO/x86_64/... and bs_publish then should make those available in /srv/obs/repos (aka download.opensuse.org).
Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch?
That would seem to be the desired course of action.
participants (7)
-
Adrian Schröter -
Andreas Schwab -
Antonio Larrosa -
Fabian Vogt -
Jan Engelhardt -
Martin Wilck -
Takashi Iwai