November 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Deprecation of /var/adm/update-scripts
by Thorsten Kukuk 22 Nov '17

22 Nov '17

Hi, if you never heard of /var/adm/update-scripts and your packages are not using it, you can ignore this. In the good old times, libzypp wasn't able to handle RPM %posttrans scripts correct (which shows, that the old times were not always good ;) ). A workaround for this was to use update-scripts. Since some years (SLE12) libzypp supports now RPM %posttrans scripts, so there is no need anymore to use update-scripts as workaround. The maintainers would like now to remove support of /var/adm/update-scripts from libzypp. Why? Because it creates a lot of additional efford for everybody. You have to implement everything twice (once for RPM, once for libzypp) and test everything twice. And since this is so much work, a lot of developer don't do that, which leads to bugs depending on how you install or update a package. So, if you use update-scripts as RPM %posttrans replacement, please change your spec files to only use RPM %posttrans scripts. If you need update-scripts for something else and you cannot remove it, please speak up now. But you should have a good answer to "what does happen if your package is installed or updated with plain rpm?". Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 7

[opensuse-packaging] how to fix build fail
by Christian 20 Nov '17

20 Nov '17

Hi, trying to build gstreamer-plugins-bad on my instance, but running into the following error and have no idea how to fix. [ 463s] + %make_build [ 463s] /var/tmp/rpm-tmp.GscvOa: line 62: fg: no job control [ 463s] error: Bad exit status from /var/tmp/rpm-tmp.GscvOa (%build) [ 463s] [ 463s] [ 463s] RPM build errors: [ 463s] Bad exit status from /var/tmp/rpm-tmp.GscvOa (%build) [ 463s] [ 463s] s4y-01 failed "build gstreamer-plugins-bad.spec" at Sat Nov 18 19:44:25 UTC 2017. [ 463s] having it for 42.2 and 42.3 Thank you :) -- Christian ------------------------------------------------------------ https://join.worldcommunitygrid.org?recruiterId=177038 ------------------------------------------------------------ http://www.sc24.de - Sportbekleidung ------------------------------------------------------------ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 10

[opensuse-packaging] RFC: Relocation of /vad/adm/fillup-templates
by Richard Brown 17 Nov '17

17 Nov '17

Hello Packagers, As part of my ongoing efforts to simplify our /var subvolume complexity, the next target on my list is /var/adm/fillup-templates As they are not variable data (meaning they shouldn't be in /var at all) nor log data (meaning they shouldn't be in /var/adm), I wish to relocate all of these fillup-templates to /usr/share/fillup-templates This will of course require changes in a lot of .spec files Therefore I am doing my best to make the transition as painless as possible for both our users and packages I am proposing changing the fillup macros (eg. %fillup_only, %fillup_and_insserv) to use both the new location, and if a template is not found in the new location then fallback to the old location. This means while obviously I would like to see this transition be as short as possible, we will not _need_ to move every specfile reference to /var/adm/fillup-templates in one coordinated jump The new path of /usr/share/fillup-templates will be implemented as a new rpm macro called %_fillupdir Once the macro is present in our rpm package, packagers will need to replace references to /var/adm/fillup-templates with %_fillupdir I will announce when this is the case in both this list and -factory; You can also expect me to contribute a significant number of the changes to packages myself, but I can't do it all alone, so your help will be GREATLY appreciated. OBS Project administrators who want to continue support building packages referencing this macro in versions of our distributions that don't carry it in their rpm package will need to add the following to their OBS PrjConf: %if ! %{defined _fillupdir} %define _fillupdir /var/adm/fillup-templates %endif This will allow those packages to build on those older distributions, as they do today, using the old /var/adm/fillup-templates location The proposed rpm macro and filesystem changes are currently visible in my home project here: https://build.opensuse.org/package/rdiff/home:RBrownSUSE:branches:Base:Syst… https://build.opensuse.org/package/rdiff/home:RBrownSUSE:branches:Base:Syst… Does anyone have any thoughts, comments, or most importantly, well reasoned objections before I submit these to Base:System and get this ball moving? Regards, -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 9

[opensuse-packaging] New thoughts on python singlespec macros
by Todd Rme 16 Nov '17

16 Nov '17

Thinking about what we need for python3 conversion long-term, a few issues have come to mind that currently aren't addressed well in the macros or previous discussions: 1. We really need to get rid of using unversioned "python" in shebangs. 2. We need to switch everything over to use versioned rpm names (particularly "python2-foo"), while still supporting older SLE/Leap versions. 3. We need to be able to handle builds that don't include python2. 4. pytest often checks the directories being used, which breaks when using "%python_expand" Regarding 1, there are currently two pain points. First and most obvious is the fact that the shebangs have to be edit manually. The second is that if we want versioned shebangs, we need to manually recompile the files to avoid mtime issues. Ideally changing the shebangs could be handled automatically during %python_build, but there could still be a separate macro that could be called in cases where manual changes are necessary. Recompiling is needed in other situations as well, so having a macro to handle that would be useful in general. Regarding 2, this is more of a policy issue. I think all packages, even python2-only ones, should be switched over to using singlespec. This makes sure that they have the correct name on all platforms. Backports packages should have a conditional "skip_python3" that is set to disable building for python versions equal to or greater than the version they were backported from, even when those versions are no longer shipped by openSUSE. There should also be a policy that, when an upstream package drops python2 support, the last-supported python2 version should be made available in the "python2-foo" package. Only "python-foo-doc" and "python-foo-data" can have the unversioned "python-" name, and that is only for version-independent documentation and assets, respectively. Regarding 3, there are again two main pain points. The first is that there is no macro I am aware of to reliable determine if a given python version is being built. %have_python2 and %have_python3 no longer work reliably AFAIK. The second is that build dependencies for particular python versions cannot be reliably disabled if that python version is not built. Currently most packages that have a python2-only build dependency just unconditionally require it, which means it will be pulled in even if python2 builds are disabled. Ideally I would like to see "%{python2_module foo}" and "%{python3_module foo}" that will only pull in that dependency if that version of python is being used. This also has the advantage of not needing to care about backwards-compatibility issues of "python-foo" vs. "python2-foo" names, which is handled inconsistently right now. If that is not feasible, just having a reliable check would be an improvement. Regarding 4, I don't really understand what "%python_expand" is doing behind the scenes, and whether there is a simple workaround or whether the macro needs to do something different internally. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 9

[opensuse-packaging] rubygem build: macro expansion error
by Hans-Peter Jansen 16 Nov '17

16 Nov '17

Hi, I suffer from macro expansion errors in rubygem builds: [ 29s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --nosignature --define '_build_create_debug 1' --define 'disturl obs://build.opensuse.org/home:frispete:GitLab/openSUSE_13.2/cd8f1e1e66ffd44…' /home/abuild/rpmbuild/SOURCES/rubygem-addressable.spec [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. resulting in build errors later on similar to: [ 31s] error: Failed build dependencies: [ 31s] rubygem(ruby:2.1.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 [ 31s] rubygem(ruby:2.2.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 [ 31s] rubygem(ruby:2.3.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 [ 31s] rubygem(ruby:2.4.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 [ 31s] rubygem(ruby:2.5.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 https://build.opensuse.org/package/live_build_log/home:frispete:GitLab/ruby… The ruby packages in question are built here: https://build.opensuse.org/project/monitor/home:frispete:ruby I slightly modified the macros of devel:languages:ruby for the later versions running on top of openSUSE_13.2. (yes, lame, I know..) Any idea, how to debug such macro expansion errors? Is there a way to examine the expanded spec? I can workaround these problems by pre-installing the offending ruby packages, but that's just papering over the underlying problem, that I would like to understand. Thanks in advance, Pete -- 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] systemsmanagement:puppet has no bugowner
by Mathias Homann 13 Nov '17

13 Nov '17

systemsmanagement:puppet has no bugowners, and when one tries to file a bug on bugzilla one gets this: Assignee: *jatan11@please-enter-an-email-address* did not match anything Can someone please see to that? Cheers MH -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann(a)openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

2 2

[opensuse-packaging] .changes madness with upstream updates
by Michael Ströder 13 Nov '17

13 Nov '17

HI! Sometimes a submission of me gets declined because of changelog being too short or too long referring to this policy: https://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29#What_goe… While the guide-lines were surely outlined with good aims I have to question the current policy of package changelogs (*.changes) regarding upstream updates. The rules are too blurry and boil down to "Do the right thing". I don't like to provide an extract of an upstream changelog because I'm convinced that no packager is capable of extracting a really meaningful essence from an upstream changelog. Furthermore I assume that upstream developers are also lazy writing docs and the changelog would have been already shorter if still meaningful. So IMO the right way is to.. 1. just mention upstream release and packaging changes xor 2. add the complete changelog. Ciao, Michael.

14 18

[opensuse-packaging] Java-build on TW fails suddenly: [javac] error: Source option 1.5 is no longer supported. Use 1.6 or later.
by Axel Braun 12 Nov '17

12 Nov '17

Hi, maybe we have a Java-Expert around that can support: projectlibre [1] suddenly fails to build on TW, with the error message: [ 31s] [ 31s] init: [ 31s] [mkdir] Created dir: /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build [ 31s] [mkdir] Created dir: /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/tmp [ 31s] [ 31s] build: [ 31s] [javac] /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build.xml:30: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [ 31s] [javac] Compiling 10 source files to /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build [ 31s] [javac] error: Source option 1.5 is no longer supported. Use 1.6 or later. [ 31s] [javac] error: Target option 1.5 is no longer supported. Use 1.6 or later. [ 31s] [ 31s] BUILD FAILED As the version setting is not explicit mentioned in the spec file I guess it is some implicit definition. Anyone an idea where to look forß Thanks Axel [1] https://build.opensuse.org/package/show/Office/projectlibre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 8

[opensuse-packaging] pycrypro unmaintained, what to do about fork pycryptodome
by Todd Rme 11 Nov '17

11 Nov '17

pycrypro [1] is an important package, used by a wide variety of python packages for cryptography. It is also totally unmaintained, having seen no releases or commits since 2014. There is a well-maintained fork that uses the same namespace, pycryptodome [2]. However, although it is the same in most cases, there are a few places where the API differs [3]. And although it is mostly backwards-compatible, it is not forwards-compatible, adding a bunch of new APIs that packages that depend on it directly may use. The problem is that more and more packages are now depending directly on pycroptodome rather than pycrypto at install time, and since the two use the same namespace they are not co-installable, so trying to install a package that depends on it results in conflicts with large parts of the python software stack. So we need to make a decision how we are going to handle the situation. The simplest, but also riskiest, solution would be to have the pycroptodome package provide/obsolete pycrypto, and have package that require the old API depend on the old pycrypto version number (so pycrypto < 3). But I doubt all of these packages have unit tests, which means we could have breakage. The most difficult solution would be to manually check each package for compatibility with pycryptodome and switch to it explicitly. The intermediate solution would be to have pycrypto and pycryptodome provide some other name, and have the packages depend on that name but prefer pycrypto. This means, however, that installing a package that requires pycryptodome specifically could suddenly cause packages you installed previously to break. We ran into a similar situation with the PIL/Pillow fork, but that had the issue where PIL never supported python3, and at least at the time more care seemed to be taken to maintain backwards-compatibility. 1: https://pypi.python.org/pypi/pycrypto/ 2: https://pypi.python.org/pypi/pycryptodome/ 3: https://www.pycryptodome.org/en/latest/src/vs_pycrypto.html -- 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: Questioning systemd tmpfiles.d packaging guidelines
by Thorsten Kukuk 09 Nov '17

09 Nov '17

On Thu, Nov 09, Franck Bui wrote: > On 11/08/2017 09:44 AM, Thorsten Kukuk wrote: > > > > So my problems: > > > > 1. We call systemd-tmpfiles with the full path to the tmpfiles > > configuration. And this is documented in this way in our wiki, too. > > But: if I read the manual page correct, this is the wrong way. If > > you specify the full path to the config file as argument, adjusted > > configuration files in /etc done by the sysadmin are ignored. > > Why do we force every packager to ignore changes made by the admin > > here? > > I must admit that I can't think of a useful case where the admin would > need to overwrite the tmpfiles shipped by a package. You seem to have > found a case but unfortunately you haven't provided any details on it so > it's hard to tell. I don't have a specific case, I did only read the manual page and found a mismatch with what we are doing. Since the systemd manual pages and other Distributions like Fedora explicit mention that you can overwrite the tmpfiles, we should not "forbid" that for no good reason. But if I look at read-only root filesystem, transactional-updates and clusters, I can imagine some situations, where it could be quite handy if you have the possibility to overwrite tmpfiles. Thorsten > OTOH since tmpfiles can be overwritten, there're probably some cases > where it makes sense. If so we shouldn't use and advice to use absolute > paths indeed. -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0