openSUSE Packaging March 2019

packaging@lists.opensuse.org

34 participants
11 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, 3 months

[opensuse-packaging] Updating libfuse rpm

by Goldwyn Rodrigues

Hello, I am planning on updating libfuse from version 2.9.9 to 3.4.2. Currently, we have both libfuse2 (source fuse-2.9.9 or just fuse) and libfuse3 (source fuse-3.4.2 or fuse3). It would be nice if all users would move from libfuse2 to libfuse3. What would be the best method to accomplish this: 1. Simply update fuse to fuse-3.4.2 2. Mark fuse 3.4.2 as obsoletes fuse < 3, and ship both for a while 3. Any other method I am afraid we will break depending applications if we choose 1, though it should be compatible. -- Goldwyn -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 7 months

[opensuse-packaging] Packagers breaking repositories ...

by Mathias Homann

So it seems that right now someone is in the process of doing some upgrade work in KDE:Qt. Whoever it is has turned publishing off, which usually is a good idea... ...but in this case it leads to hundreds of packages in KDE:Framework, KDE:Extras, and KDE:Applications being rebuilt, and being published, and because publishing of KDE:Qt is turned off, being unable to be installed due to missing dependencies. The really bad part is, that *some* packages from those newly built ones *will* be installed, and some others will be downgraded to what's in the base distribution, leaving people with a general mish mash of librariy versions and potentially seriously broken desktops. So ... can someone **please** turn publishing in KDE:Qt back on? And for next time: whoever disables publishing in KDE:Qt for upgrading it, disable publishing (and building) in KDE:Frameworks5, KDE:Applications, and KDE:Extra. Thank you. *le sigh* Mathias -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 7 months

[opensuse-packaging] Packagers - please check your "Url:"s

by Brüns, Stefan

Hi fellow packagers, as part of a broader https support, many projects have changed there homepages from plain http to https. Some notable mentions: - github.com/* - sourceforge.net/projects/* - *.kde.org - *.gnome.org So the next time you do some package work, check if your Url: tag is now a redirect: $> curl -I http://amarok.kde.org HTTP/1.1 301 Moved Permanently Location: https://amarok.kde.org/ Currently, there are ~2000 (sub-)packages [1] which have a permanent redirect [2]. Kind regards, Stefan [1] https://repology.org/repository/opensuse_tumbleweed [2] https://repology.org/repository/opensuse_tumbleweed/problems -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 8 months

[opensuse-packaging] spec-cleaner and defines

by Andreas Vetter

Hi, here is my stupid question of the day: spec-cleaner wants to move defines to the beginning of the spec file. But I need it after Name and Version like that: Name: hmcfgusb Version: 0.103 %define tarball %{name}-%{version}.tar.gz ... URL: https://git.zerfleddert.de/hmcfgusb/releases/%{tarball} Source: %{tarball} spec-cleaner wants to turn it around, but then it does not work: %define tarball %{name}-%{version}.tar.gz Name: hmcfgusb Version: 0.103 ... Is it ok to ignore (in that case) spec-cleaner or is there a better way to achieve that? -- Mit freundlichen Gruessen, Andreas Vetter Stellv. IT-Bereichsmanager Fakultaet fuer Physik und Astronomie Tel.: +49 (0)931 31-82264 Informations- und Kommunikationstechnik Tel: +49 (0)931 31-85890 iuk(a)physik.uni-wuerzburg.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 8 months

[opensuse-packaging] Something like BuildRecommends to increase test coverage?

by Bernhard Voelker

The coreutils-testsuite runs best with a list of tools like valgrind, gdb, python-inotify etc. but some of the tools are not available on some platforms. The problems is: a) if I add a BuildRequires on platforms that don't have that package, then the whole testsuite build on that platform fails. b) Now I can add a guard around the BuildRequires per platform/OS version manually, but: b1) manually maintaining such a list is tedious, b2) if the guards take out to many of BuildRequires, then the coverage is not as good as it could be. This effect is transient if a package gets available on a new platform in future. As a packager, I'd love to just add the list of additional tools the test may or may not use, and the build not failing if the package is not available on that platform like: BuildRecommends: valgrind or BuildSuggests: valgrind Is there something automatic like this? Thanks & 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

1 year, 8 months

[opensuse-packaging] Including python modules using .pth file

by Chris Coutinho

Hi, There are some packages that include python modules/packages that are not installable via setup.py. Since they might not end up on the normal python search path, python fails to find them and the build looks 'broken' For example, paraview (a package within the science project) installs its shared libraries into its own /usr/lib64/paraview subdirectory. The associated python3 packages get placed into /usr/lib64/paraview/python3.x/site-packages/. Another project I recently submitted places its python modules into /usr/share/<package>/Python. Both of these cases end up with import errors, and can be solved by fixing how the packages are installed. Rather than moving the packages into the system site-packages directory, I propose to simply throw a <package>.pth file into the site directory for python 2 or 3 (or both if applicable) pointing to the packages python modules. Is there precedent regarding this issue? Regards, Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 8 months

[opensuse-packaging] macros for /opt/foo

by Michael Ströder

HI! Are there any RPM macros one should use when packaging software installed with a prefix /opt/foo? Thanks in advance. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 8 months

Re: [opensuse-packaging] macros for /opt/foo

by Michael Ströder

On 3/10/19 10:05 PM, Chris Punches wrote: > The RPMDB assures that not the filesystem paths. If you're using /opt > you should still consider using the proper paths. As a consultant I > often have this conversation with vendors providing software who don't > know better and it's practically an epidemic. You want people to use > the FHS to make good assumptions about where things are. I've heard all > manner of arguments for why they have to do it this way and have never > seen one be right. Does a file conflict with OS-packaged libldap count as sufficient argument? Believe me. I'm not doing this for fun. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 8 months

[opensuse-packaging] Manual requires not being displayed in build results?

by Todd Rme

It looks like the build results in the OSC web interface are not displaying requires specified in the spec file, only automatically-detected results. For example, with alsa, it Requires: alsa-utils. But if you look at the build results, that requirement is not listed: https://build.opensuse.org/build/openSUSE:Factory/standard/x86_64/alsa/_log This happens in every projects, package, and build target I have checked. I am not sure if this is a bug or expected behavior, though. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 8 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging March 2019