October 2019 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Changing %_libexecdir to /usr/libexec
by Michael Schroeder 07 Nov '19

07 Nov '19

Hi folks, OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor). I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up! If there are no strong objections, I'll merge the request at the end of next weak. Cheers, Michael. -- Michael Schroeder mls(a)suse.de SUSE LINUX 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(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 10

[opensuse-packaging] Board Decision on groups in spec files.
by Simon Lees 01 Nov '19

01 Nov '19

Hi All, It likely comes as no surprise to anyone one that the groups in spec file issue was raised with the board (one of these was on a public list). In this specific email we are acting in our role of "helping resolve conflicts" complaints were also made directly about the behavior of certain individuals (again including on this list). The board has chosen to deal with these issues in private as is our general approach to such issues. Firstly the board generally agrees that in the following thread [1] there was a plan and general agreement to follow it for the removal of groups if certain other issues were resolved. As such we believe they acted with good intentions when starting to remove group support from various places such as Yast, rpmlint and spec cleaner. The board decided to wait until the discussion on new proposals settled down, before going forward with the issue, at the time we had the discussion we believed this to be the case. Of all the proposals discussed the board agreed that the one submitted by Ludwig [2], to move groups into the repository meta data is technically the best solution and the one most broadly supported by contributors. As such we welcome any contributions from the community towards getting this working and integrated into tooling where it makes sense such as Yast and software.opensuse.org Given that our core tooling no longer displays groups and that the board has a copy of all the existing groups that can be used as a starting point for the new system the board has decided that including groups in spec files should now be optional with the final decision resting with the maintainer as some maintainers may still use there spec files in distro's that still support groups although we believe most packages going into factory wont. We realize that this decision will not make everyone happy but hopefully it eventually leads to better group support in the future. 1. https://lists.opensuse.org/opensuse-factory/2018-05/msg00460.html 2. https://lists.opensuse.org/opensuse-factory/2019-10/msg00263.html -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

3 4

[opensuse-packaging] Re: [opensuse-factory] Board Decision on groups in spec files.
by Bernhard Voelker 31 Oct '19

31 Oct '19

On 2019-10-31 16:45, Richard Brown wrote: > On Wed, 2019-10-30 at 15:36 +1030, Simon Lees wrote: >> Of all the proposals discussed the board agreed that the one >> submitted by Ludwig [2], to move groups into the repository meta data [...] >> 2. https://lists.opensuse.org/opensuse-factory/2019-10/msg00263.html move = copy_to_dst + remove_from_src > In the light of this decision, is something going to be done about > submit requests which are being artificually held back by manual > reviews [...] To get a 'move', that information should first show up in the "repository meta data" before it can be be deleted from "Groups:". TBH I didn't follow the discussions from a certain point, but neither the referenced proposal nor the board decision does enlighten me enough to see what the actual plan is: Technically we can generate additional information into the repo metadata. A package is part of a development repo, and gets SR'ed to Factory, or other projects. So where is that information supposed to be originally stored? In the meta data of the package? And then propagated to the projects that package is forwarded to? How? While I respect the decision of the board (and find it good that a decision was finally made), I'm still confused what it means in detail. >From Richard's demanding I see only the second half of the actions, i.e., that the information should disappear from the RPM Group tag (or maybe not - depending on the maintainer). Yet - the first action, i.e., where to go with the information, is not clear to me. What are the next actions following the decision wrt/ the 1st part? Would someone please explain? Have a nice day, Berny -- 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] Re: [opensuse-factory] Board Decision on groups in spec files.
by Simon Lees 31 Oct '19

31 Oct '19

On 11/1/19 2:15 AM, Richard Brown wrote: > On Wed, 2019-10-30 at 15:36 +1030, Simon Lees wrote: > > Hi Simon, > > Thanks to you and the Board for this decision. > > In the light of this decision, is something going to be done about > submit requests which are being artificually held back by manual > reviews injected by Factory Manitainers who objected to the removal of > Group tags? This issue has already been raised to the board and can be considered to fall in the group of things that I mentioned would be considered in private > There are SR's like https://build.opensuse.org/request/show/738893 > which are needed for important container networking stacks like cilium but cannot progress until Jan removes his objection. > It seems in this case the review has now been accepted, but I wouldn't be surprised if some people have or will just resubmit requests in a similar state. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

1 0

[opensuse-packaging] Re: Summarizing, and more of the same... [was Rephrasing pros+cons of Group + tags discussion]
by Aaron Puchert 30 Oct '19

30 Oct '19

Am 29.10.19 um 23:09 schrieb L A Walsh: > p.s. - oh screw it, has anyone tried classifying music into the > pre-existing '8' categories (now over 200 and still not a free-format > list) that were provided by some music players 20-30 years ago and > really thought that just one category applied to their music? Is > software that different? That's an interesting direction to look in: what other classifications are out there and how well do they work? I think art is always a bit hard to classify, although art historians try to put it into boxes as much as possible. But scientific papers are actually classified by systems very similar to rpm Group tags: * the Mathematics Subject Classification (MSC) [1], * the Physics and Astronomy Classification Scheme (PACS), discontinued but apparently still used [2], * the classification of papers in arXiv [3]. These are all hierarchical, and either allow just one classification, or have a primary classification. These classifications are probably not always perfect, and just like with Group tags it might happen that no group matches exactly, or multiple groups apply. Yet judging from their usage the benefits seem to outweigh the costs. Best regards, Aaron [1] <https://en.wikipedia.org/wiki/Mathematics_Subject_Classification> [2] <https://en.wikipedia.org/wiki/Physics_and_Astronomy_Classification_Scheme> [3] <https://arxiv.org/> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Compilation of summarized Group arguments/statements and timeline
by Jan Engelhardt 24 Oct '19

24 Oct '19

MAY OF 2018. [1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options [1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion [1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing [1.3] WR: annoyed by wrong or inconsistent groups. JE: I'm on it, fixing it. (To date, around 350 edits could be found from my side alone to that end. In other cases, no edit was needed, or the package has not yet crossed my field of sight.) [1.4] WR: trying to figure out the single-category group is hard. (JE: agreement; go for tags) [1.5] MC: recurring packager questions like "What is the Group field for?", "which to choose?" (JE: agreement; go for tags, that seems to work out well for freshcode.club and stackexchange.com) [1.6] MC: (basically Fedora failed to get a grip on Groups, so the world should remove it) (JE: openSUSE has a grip, so "keep" and/or do tags) CONCLUSION OF MAY 2018. Supporters of having some value for "Group": Jan Engelhardt [1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." Scott Bahling @SUSE [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" Wolfgang Rosenauer @SUSE [1.4] "I use the group index to find software I might be interested in." Adam Majer @SUSE [1.7] "Debian has been using package tags[1] for a number of years in addition to groups." Stefan Behlert @SUSE [1.8] "I personally like the groups. They give you a good hint what a package is for." Opponents of "Group": Tomas Chvatal. Apart from the initial message, has not made any reply in that thread to the counter arguments (maybe they were too convincing). Matěj Cepl Michal Kubecek The supporters have made their case and commitment to work it. Technically, being a meritocracy, this decided that the Group tag is to stay for the time being, and be enhanced as we go. JUNE OF 2019. [2.0] IG: Fedora guy here, I missed the previous discussion on groups, so I am proposing the removal again. JE: Link to the previous discussion. [2.1] NG: "I'm actually not a fan of the fact Fedora doesn't use the Group tag. ... I'd rather re-introduce a better formulated Group tag" [2.2] TC: "We are already in process of abandoning it." -> in violation of the May resolution [2.3] TK: single-value group is useless currently -> the idea of tags is just floating [2.3] TK: "many Group entries are wrong, useless or something similar" JE: "Most Group entries are actually right", I'm doing the dang reviews where all the spec files pass my eagle eyes. CONCLUSION OF JUNE 2019. (New) supporters of having some value for "Group": Neil Gompa (New) opponents: Maurizio Galli (MauG) AUGUST 2019. [3.0] TC: "As there was no major pushback", ignores the May result, ignores the June discussion even after being pointed to previous threads. [3.1] TC: "Your lonely complain is not a major pushback..." JE: This overview is proof of the contrary. [3.2] SK: "should eliminate *the need* to have a group line." JE: agreement [3.3] HPJ: "OTOH, I cannot see a good reason to *actively* *eliminate* the Group line" [3.4] BV: Concern that removing Group is extra work. CONCLUSION OF AUGUST 2019. * new .spec files can come without a group line; groups/tags can be added later by those who care * keep Group lines * A tag browser software is on display to showcase that even the old groups _work reasonably well_ as tags for the purpose of software browsing and discovery. * rpmlint was amended in late September not to warn on wrong group lines anymore * Group: can thus be freeform, allowing for a tag system (whitespace-separated words) (New) supporters of having some value for "Group": Hans-Peter Jansen OCTOBER 2019. [] Opponents: maintainers are gods over their own packages [4.0] JE: I'm trying to run a distro-wide endeavor here, there should be limits as to what maintainers can and cannot oppose. [4.2] TK: repeats his prior statement that groups are useless JE: repeats his prior statement that they are in good shape [4.3] TK: wiki has not corresponded to what the tooling does [4.4] JE: disproves TK and explains the circumstances [4.5] HPJ gets annoyed by Opponents' removal of Group lines in his package. OVERALL. Opponents start killing off Group tag even though that goes directly against the goal of the Group/Tags subproject and its Supporters. Bad. Opponents claim "it was decided", but this decision was at best unilateral and there is anything _but_ consensus about the removal. In doing so, they also overstep other maintainers [SR 738421]. Very bad. The wiki has a strange position in all this. Many regard it as an authoritative manual, but only where it is convenient and matches practice. Right now it says "Group: only package groups listed in the package group guidelines should be used." [5.0] and "New groups can be created by just starting to make use of them in .spec files." [5.1], so I will hold it to that. MAIL REFERENCES (webview). [1.0] https://lists.opensuse.org/opensuse-factory/2018-05/msg00460.html [1.3] https://lists.opensuse.org/opensuse-factory/2018-05/msg00507.html [1.4] https://lists.opensuse.org/opensuse-factory/2018-05/msg00511.html [1.5] https://lists.opensuse.org/opensuse-factory/2018-05/msg00517.html [1.6] https://lists.opensuse.org/opensuse-factory/2018-05/msg00517.html [1.7] https://lists.opensuse.org/opensuse-factory/2018-06/msg00004.html [1.8] https://lists.opensuse.org/opensuse-factory/2018-06/msg00131.html [1.9] https://lists.opensuse.org/opensuse-factory/2018-05/msg00503.html [2.0] https://lists.opensuse.org/opensuse-factory/2019-06/msg00054.html [2.1] https://lists.opensuse.org/opensuse-factory/2019-06/msg00056.html [2.2] https://lists.opensuse.org/opensuse-factory/2019-06/msg00058.html [2.3] https://lists.opensuse.org/opensuse-factory/2019-06/msg00059.html [3.0] https://lists.opensuse.org/opensuse-factory/2019-08/msg00253.html [3.1] https://lists.opensuse.org/opensuse-factory/2019-08/msg00257.html [3.2] https://lists.opensuse.org/opensuse-factory/2019-08/msg00262.html [3.3] https://lists.opensuse.org/opensuse-factory/2019-08/msg00268.html [3.4] https://lists.opensuse.org/opensuse-factory/2019-09/msg00034.html [4.0] https://lists.opensuse.org/opensuse-factory/2019-10/msg00039.html [4.2] https://lists.opensuse.org/opensuse-factory/2019-10/msg00046.html [4.3] https://lists.opensuse.org/opensuse-factory/2019-10/msg00048.html [4.4] https://lists.opensuse.org/opensuse-factory/2019-10/msg00051.html [5.0] https://en.opensuse.org/openSUSE:Specfile_guidelines [5.1] https://en.opensuse.org/openSUSE:Package_group_guidelines -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

14 32

[opensuse-packaging] Wesnoth - unstable version?
by Maximilian Trummer 23 Oct '19

23 Oct '19

Hey, I was wondering why the version of Battle for Wesnoth in openSUSE Tumbleweed is 1.15.2, the unstable development version, instead of the latest stable version 1.14.9. https://build.opensuse.org/package/show/games/wesnoth https://github.com/wesnoth/wesnoth/releases One resulting issue I've run into is that 1.15 servers are incompatible with 1.14 clients. regards

2 1

[opensuse-packaging] prjconf or rpm-macros(?) trick to inject %defattr?
by Stefan Seyfried 22 Oct '19

22 Oct '19

Hi packaging gurus, I am regularly rebuilding current Factory packages for ancient SLES releases (SLES15, SLES12-SP1...4, sometimes even SLES11). Many current spec files have gotten deprived of their %defattr(...) lines, which causes warnings like these: [ 25s] python-wheel.src:102: W: files-attr-not-set [ 25s] python-wheel.src:103: W: files-attr-not-set [ 25s] python-wheel.src:104: W: files-attr-not-set [ 25s] python-wheel.src:105: W: files-attr-not-set [ 25s] python-wheel.src:106: W: files-attr-not-set [ 25s] A file or a directory entry in a %files section does not have attributes set [ 25s] which may result in unexpected file permissions and thus security issues in [ 25s] the resulting binary package depending on the build environment and rpmbuild [ 25s] version (typically < 4.4). Add default attributes using %defattr before it in [ 25s] the %files section, or use per entry %attr's. Even SLES11-SP4 has rpm version 4.4.2.3, so maybe this can just be ignored. Or is there some prjconf or rpm macro magic that lets me automatically insert %defattr lines after every %file line? Thanks for any insights, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] Re: [opensuse-factory] Changing %_libexecdir to /usr/libexec
by Jan Engelhardt 18 Oct '19

18 Oct '19

On Friday 2019-10-18 10:44, Fabian Vogt wrote: >> OBS request 738494 from Neal will change %_libexecdir from >> /usr/lib to /usr/libexec. This was proposed in July on the >> opensuse-packaging list > >This would break some packages like purpose, which call binaries >inside libexec from a libary which is 32/64-bit co-installable >using baselibs.conf. > >What's the right way to handle that? A 32-bit library can invoke(*) a 64-bit program with no problem. Then you just need to make sure that these two entities live in packages such that the combinations are always installable. The current state in o:F/purpose suggests that said library package will need to "Require: purpose" to get at the "purposeprocess" executable. (*) standard fork/execv approach. let's not consider the hypothetical way of dlopening it ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Re: [opensuse-factory] Changing %_libexecdir to /usr/libexec
by Neal Gompa 18 Oct '19

18 Oct '19

On Fri, Oct 18, 2019 at 4:45 AM Fabian Vogt <fvogt(a)suse.de> wrote: > > Hi, > > Am Freitag, 18. Oktober 2019, 10:32:29 CEST schrieb Michael Schroeder: > > > > Hi folks, > > > > OBS request 738494 from Neal will change %_libexecdir from > > /usr/lib to /usr/libexec. This was proposed in July on the > > opensuse-packaging list with only Thorsten and Jan replying > > (Jan being in favor). > > > > I don't want to merge it right now without giving you some > > time to discuss this change. So please, if you have good reasons > > why this is a bad idea please speak up! > > This would break some packages like purpose, which call binaries > inside libexec from a libary which is 32/64-bit co-installable > using baselibs.conf. > > What's the right way to handle that? > This is already broken right now as it is currently packaged. But if you want to fix it, the way you'd do it is by splitting out that binary into a subpackage and have the library packages have a dependency on that subpackage containing the libexec binaries. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[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