October 2019 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Split project to separate "-standalone", "-plugin" and "-common" packages .
by Konstantin Voinov 18 Oct '19

18 Oct '19

Hi, I'm building some audio software, such a synths and filters in OBS (https://build.opensuse.org/package/show/home:kill_it:JUCE). During this process we discuss that project should be split in separate packages: synthesizer-01.x86_64.rpm - the standalone app synthesizer-vst-01.x86_64.rpm - vst plugin lv2-synthesizer-01.x86_64.rpm - same but lv2 synthesizer-common-01.noarch.rpm - this should contains some common files, such a skins, presets etc, if they exists. And LICENSE and README files. Is it ok with openSUSE packaging guidelines? If yes: For me is unclear what is openSUSE policy for LICENSE (or maybe README) files, should it be in synthesizer-common-01.noarch.rpm mandatory, and this rpm must be required for all binary rpms (AFAIK this is Debian behavior). Or it just enough to put it in "main" synthesizer-01.x86_64.rpm? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 8

[opensuse-packaging] The %pypi_source macro
by Luigi Baldoni 17 Oct '19

17 Oct '19

Hello, I've just found there's a %pypi_source macro on Fedora (see https://src.fedoraproject.org/rpms/python-rpm-macros/blob/master/f/macros.p…). Since it does away with the long https://files.pythonhosted...etcetera, do you think it's something that could be adopted also on openSUSE? Regards -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] [INFO] New setup for openSUSE:Factory/snapshot
by Dominique Leuenberger / DimStar 17 Oct '19

17 Oct '19

Dear Tumbleweed hackers and devs, I just finished, together with Adrian Schröter (Thank you!), the new setup for openSUSE:Factory/snapshot. * Why did we change the setup (what problem do we solve) openSUSE:Factory/snapshot promised to offer a stable target to build against. Unlike openSUSE:Factory/standard it is not being 'built' and projects building against it are thus not 'blocked' while waiting for the the parent project to finish. But some changes are always happening project-wide, not repository wide. So for example when a package is being deleted from openSUSE:Factory, the binaries were removed also from /snapshot. For delete requests we had developed a 'complex process' trying to eliminate this. The process worked 'fine', but it had gaps: if a package used to have multiple spec files (which resulted in linked packages to the main name) and then dropped some of those spec files, the linked package containers needed to be cleaned up. And this bled directly into /snapshot (just recently we had this case with lvm2/device-mapper again). The new setup we now implemented no longer suffers from this issue. * What changed (background info) Instead of copying binaries from openSUSE:Factory/standard to /totest (when the snapshot moves to QA) and then to /snapshot (when the snapshot is being published), we changed the setup to no use Download On Demand - i.e. if your package builds against openSUSE:Factory/snapshot, OBS will query the repository on download.opensuse.org and download the needed binaries as they are used. For OBS, this means we save quite some disk space: instead of storing three complete sets of RPMs, we now store only one set (/standard, where we build) PLUS the packages that were needed in order to build against them (only a subset is neaded, as many leaf packages are never pulled into the buildroots and thus do not ever get downloaded by OBS). This is of course just a nice side-effect - and was in no way a driver for the change * What do you as a user need to do? Nothing. The change is completely transparent to the OBS user base. Well, almost completely: there are several packages that are not published as part of the snapshot, as they are only meant to bootstrap the distro and improve build performance a tad. Those are the -bootstrap and -mini packages. We don't publish them in the repository, as they all contain a Requires on this-is-only-for-build-envs - which no package provides (OBS is instructed to ignore those deps). If, for some (most likely invalid!) reason, your package would buildrequire any such -mini package, it will now be 'unresolvable'. The correct fix there will be to change the BuildRequires to asymbol shared between the -mini package and the real package (not the non-mini package name, as this would destroy the wins achieved by using the -mini to build the distro). A typical example could be for example systemd-mini, which should be pkgconfig(systemd) Should you see any issues hat you can't explain and that you think could come from this change, please let me know. Best regards, Dominique

1 0

[opensuse-packaging] Enable debuginfo packages when rebuilding src rpm files locally
by Yichun Zhang 09 Oct '19

09 Oct '19

Hi there, We'd like to use the `rpmbuild --rebuild foo.src.rpm` command to rebuild our existing source rpm files on OpenSUSE Leap 15.1. It works but it does not strip the binary ELF files nor does it generate any debuginfo sub-packages. The same source rpm files work fine on Fedora, RHEL, CentOS, and Amazon Linux, at least. How to enable debuginfo generation with the rpmbuild toolchain please? We prefer not using the public build farm services online since we also have our own build farm and some of the packages are proprietary. Thanks for your attention and help. Best, Yichun -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] devel -package with sources inside
by Axel Braun 09 Oct '19

09 Oct '19

Hello, I'm currently working on packaging Orthanc. This installation can be extended with plugins, e.g. for database-backends and viewers. Those plugins require the sources of Orthanc to compile (beside some other specialities). In order to keep things easy and consistent, I packed the sources of orthanc into orthanc-devel. So with BuildRequires: orthanc-devel in the plugins one should be fine. Now this is objected by the maintainer of the targeted development repository, sources inside -devel are not allowed. Adding the othanc source tarball to each plugin separately sounds a bad idea to me. High risk of inconsistency. Having a -src package build together with -devel isnt smart either - it just adds overhead. Any other ideas how to solve this? Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 9