openSUSE Packaging September 2018

packaging@lists.opensuse.org

14 participants
8 discussions

[opensuse-packaging] New macro to limit resources allocation per thread

by Tomas Chvatal

Hello all, For use in libreoffice, chromium and others I've created macro that should allow you to limit jobs based on some constraints you can set later on in the spec to avoid OOM crashes. The usage is pretty straight forward (Once it is accepted in Tumbleweed): === BuildRequires: memory-constraints %build # require 2GB mem per thread %limit_build -m 2000 make %{?_smp_mflags} ==== Here the _smp_mflags vaule for 8GB machine would be 4 while default is number of cores (lets say 16)... Both macros %jobs and %_smp_mflags are overriden as such the integration should be really painless if you need to do something like this. Tom

1 year, 10 months

[opensuse-packaging] "quilt setup" considered harmful

by Matthias Gerstner

Hello packagers, the SUSE security team wants to draw your attention to a potential security threat involving the use of `quilt setup ...` on untrusted RPM spec files. For many of us calling `quilt setup $PACKAGE.spec` is probably a frequent part of our daily workflows. In contrast to building a package on the server in an isolated VM or on the client in a chroot via `osc build`, the `quilt setup` runs without any isolation on the host in the calling user's context. As it turns out this operation easily allows to execute code in the following ways: - The statements in the `%prep` section of the RPM spec file are unconditionally executed in the context of the calling user. - Arbitrary flags can be passed to `patch` via `%define _default_patch_flags ...` in the spec file. By embedding semicolons into the flags also arbitrary commands can be injected this way. - By combining the available vectors, difficult to spot malicious code can be hidden in RPM spec files. For example patch can be caused to follow symlinks, thereby "patching" files in a user's home directory as demonstrated in [1]. A demonstration works like this: ```sh $ osc co home:mgerstner/surprise $ cd home:mgerstner/surprise $ quilt setup surprise.spec # notice the surprise $ bash ``` We have posted about this on the oss-security mailing list [2] to start a discussion about possible countermeasures. A first aid could be to run the `quilt setup` inside a docker container or in a similar isolated environment. We are currently testing isolation of quilt with nsjail [3]. nsjail RPMs are available for Leap 15 and Tumbleweed from its devel project [4]. It is currently not found in Factory/Leap directly. Via the wrapper "squilt" [5], nsjail is utilized to confine quilt to read only the files it needs and is only able to write in the current directory. According to our initial testing it can be used as a drop in replacement and should reduce the attack surface significantly. Our foremost intent is to make you aware of this so you don't run `quilt setup` unsuspectingly on untrusted packages that did not go through review. Furthermore to make you aware of how malicious code that targets this can be embedded in spec files and patches. This should be taken into account when reviewing package submissions. If you have any questions or suggestions then please let's start a discussion. [1]: https://build.opensuse.org/package/show/home:mgerstner/surprise [2]: https://www.openwall.com/lists/oss-security/2018/09/27/2 [3]: http://nsjail.com [4]: https://build.opensuse.org/package/show/security/nsjail [5]: https://github.com/jsegitz/squilt -- Matthias Gerstner <matthias.gerstner(a)suse.de> Dipl.-Wirtsch.-Inf. (FH), Security Engineer https://www.suse.com/security Telefon: +49 911 740 53 290 GPG Key ID: 0x14C405C971923553 SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nuernberg)

2 years, 8 months

[opensuse-packaging] packaging plasma apps

by Mathias Homann

Hi, is there documentation about what rpm macros are available for packaging plasma? A (casual) google search only returns documentation about macros for KDE3 and KDE4. Specifically: is there a plasma5 equivalent to %kde4-runtime-requirements? cheers Mathias

2 years, 8 months

[opensuse-packaging] very weird packaging problem on Leap 15.0

by Mathias Homann

Hi, I'm having a really strange packaging issue on Leap 15.0: the %files se4ction of my spec file fails! here's the part of the spec file in question: %files %defattr(-,root,root,0755) %doc $RPM_BUILD_DIR/%{_srcname}/build-linux-%{_arch}/newview/packaged/*.txt %{prefix} /usr/share/applications/* /usr/share/pixmaps/* /usr/games/* %config /etc/permissions.d/%{name} and here is the log output: %files 2685s] Processing files: phoenix-firestorm-lgpl-5.1.9.56359-lp150.7.1.x86_64 [ 2685s] Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.ZJ8qDk [ 2685s] + umask 022 [ 2685s] + cd /home/abuild/rpmbuild/BUILD [ 2685s] + cd phoenix-firestorm-lgpl [ 2685s] + DOCDIR=/home/abuild/rpmbuild/BUILDROOT/phoenix-firestorm- lgpl-5.1.9.56359-lp150.7.1.x86_64/usr/share/doc/packages/phoenix-firestorm- lgpl [ 2685s] + export LC_ALL=C [ 2685s] + LC_ALL=C [ 2685s] + export DOCDIR [ 2685s] + /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT/phoenix- firestorm-lgpl-5.1.9.56359-lp150.7.1.x86_64/usr/share/doc/packages/phoenix- firestorm-lgpl [ 2685s] + cp -pr /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/build- linux-x86_64/newview/packaged/FIRESTORM_DESKTOPINSTALL.txt /home/abuild/ rpmbuild/BUILD/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/ README-linux-joystick.txt /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/ build-linux-x86_64/newview/packaged/README-linux-voice.txt /home/abuild/ rpmbuild/BUILD/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/ README-linux.txt /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/build- linux-x86_64/newview/packaged/VivoxAUP.txt /home/abuild/rpmbuild/BUILD/ phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/ featuretable_linux.txt /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/ build-linux-x86_64/newview/packaged/licenses.txt /home/abuild/rpmbuild/ BUILDROOT/phoenix-firestorm-lgpl-5.1.9.56359-lp150.7.1.x86_64/usr/share/doc/ packages/phoenix-firestorm-lgpl [ 2685s] + exit 0 [ 2685s] error: File not found by glob: /home/abuild/rpmbuild/BUILD/phoenix- firestorm-lgpl/$RPM_BUILD_DIR/phoenix-firestorm-lgpl/build-linux-x86_64/ newview/packaged/*.txt [ 2685s] [ 2685s] [ 2685s] RPM build errors: [ 2685s] File not found by glob: /home/abuild/rpmbuild/BUILD/phoenix- firestorm-lgpl/$RPM_BUILD_DIR/phoenix-firestorm-lgpl/build-linux-x86_64/ newview/packaged/*.txt [ 2685s] [ 2685s] lamb78 failed "build phoenix-firestorm-lgpl.spec" at Sun Sep 23 05:42:03 UTC 2018. On every suse version until now this had worked just fine, but on 15.0 it almost looks as if $RPM_BUILD_DIR is not defined anymore, or as if variables are not expanded anymore at that point. Any ideas? -- 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 years, 9 months

[opensuse-packaging] Need help splitting off libraries that were previously together in one package.

by Dave Plater

Hi, I made the decision to put the three libraries in sub package libjack0 into their own sub packages, we now have libjack0, libjacknet0 and libjackserver0. None of these libraries are dependent on the others. A lot of opensuse packages require libjack0 but the only package that depends on libjacknet0 and libjackserver0 are binaries in the jack package. I previously had libjacknet0 and libjackserver0 require libjack0 = %{version} which in my mind is wrong and rpmlint doesn't like it either. I've removed the two requires and modified the "obsoletes libjack0 < %{version}" to "obsoletes libjack0 < 1.9.12" (the version that the package was split). libjacknet0 and libjackserver0 naturally provide themselves. My question is - isn't the obsoletes enough for libjacknet0 and libjackserver0? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 years, 9 months

[opensuse-packaging] re: darktable, does anyone actually read this though?

by Patrick Shanahan

darktable-2.5.0~git461.cc742b6d0-300.1.x86_64.rpm * Sun Sep 09 2018 opensuse-packaging(a)opensuse.org - Update to version 2.5.0~git461.cc742b6d0: * RawSpeed submodule update: does anyone actually read this though? * Olympus E-PL8 color matrix * Pentax 645z: official color matrix from DNG * Pentax 645D: use official color matrix from DNG * Olympus SH-2 color matrix * Updated Dutch translation * Add some more consts in retouch iop. * Update French translation. * Retouch GUI (#1550) * Update French translation. yes, for every build tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 years, 9 months

[opensuse-packaging] SLE_15 vs SLE_15_backports

by Peter Czanik

Hi, Trying to compile syslog-ng in my repo both for SLE_15 and SLE_15_backports and ran into something interesting. I use the following to detect SLES, and it works fine for the SLE_15 variant. But for SLE_15_backports I get "nothing provides riemann-c-client-devel" # riemann does not compile on SLES %if !0%{?is_opensuse} %bcond_with riemann %else %bcond_without riemann %endif Any clues why the above does not work for backports? Bye, CzP -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 years, 9 months

[opensuse-packaging] How to deal with divergent SLE/Leap changelog?

by Petr Tesarik

Hi all, I'm trying to find out how I can solve diverging changelogs in SLE/Leap and Factory. There were some patches in SLE12 SP3, which are not needed (and are in fact harmful) in SLE12 SP4. 1. When I take the Factory package and submit it to SLE12 SP4, the submission gets rejected, because some (SP3) patches are not mentioned in the changelog. 2. When I start with the SP3 package and update it manually, leaperbot complains that it does not follow Factory first policy. Release managers tell me I should merge the changes in Factory and resubmit. 3. When I submit the merged changelog, the request gets declined: https://build.opensuse.org/request/show/632515 Is the correct process to keep a non-working makedumpfile in SLE12 SP4 and wait until the situation gets escalated by a SUSE partner during Beta testing (which is what I did, effectively)? Please, advise. TIA, Petr T -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2018