openSUSE Packaging December 2017

packaging@lists.opensuse.org

38 participants
24 discussions

[opensuse-packaging] Ownership issues with /usr/share/licenses in SLE-12

by John Paul Adrian Glaubitz

Hello! I'm trying to build python-pytest-relaxed for SLE-12 in backports which is required as a dependency for one of the tools we are using for the public cloud stuff. The build fails with RPM complaining about /usr/share/licenses being unowned: [ 4s] ... running 01-check-debuginfo [ 4s] ... testing for empty debuginfo packages [ 4s] ... running 02-check-gcc-output [ 4s] ... testing for serious compiler warnings [ 4s] (using /usr/lib/build/checks-data/check_gcc_output) [ 4s] (using /var/tmp/build-root/openSUSE_Backports_SLE-12-x86_64/.build.log) [ 4s] ... running 03-check-binary-kernel-log [ 4s] ... running 04-check-filelist [ 4s] ... checking filelist [ 4s] python-pytest-relaxed-1.0.0-0.noarch.rpm: directories not owned by a package: [ 4s] - /usr/share/licenses [ 4s] python3-pytest-relaxed-1.0.0-0.noarch.rpm: directories not owned by a package: [ 4s] - /usr/share/licenses [ 4s] [ 4s] suse-laptop failed "build python-pytest-relaxed.spec" at Fri Dec 15 13:35:27 UTC 2017. [ 4s] Normally, this issue is fixed by installing the package which install this directory into the chroot, either through a Preinstall directive in the project configuration or by adding the package in question to Build-Depends in the spec file. The directory /usr/share/licenses is provided by filesystem which I tried preinstalling through the aforementioned mechanisms. However, I still keep running into the ownership issue as shown above. Does anyone have any idea what I am doing wrong? Thanks, Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years

[opensuse-packaging] Selecting GCC version

by Matthias Fehring

Hello, is there a simple way to force the GCC version used to build a package? openSUSE Leap 42.2 for example uses GCC 4.8 as default compiler, but also provides packages for GCC 5.3. Simply using BuildRequires gcc5 pulls gcc5 in but still uses gcc48 to build the package (especially in Build Service). So is there maybe some Buid Service or spec file switch (bcond) to select the used GCC version? Best greetings Matthias Fehring P.S. Not sure if it is a problem with my browser settings, but when I try to search lists.opensuse.org, it is not possible for me to limit the results to a specific list. Even if I set one, I get results from all lists, what makes searching almost impossible, because most results are commit messages. -- Das Gesetz hat zum Schneckengang verdorben, was Adlerflug geworden wäre. (Friedrich Schiller - Die Räuber) www.buschmann23.de GPG-Key: 0x614C3258 GPG Fingerprint: D786 DDF8 4CA9 00BC CDE0 9A5F CCC5 125D 6E87 D4FC

4 years, 1 month

Re: [opensuse-packaging] Proper way to set shebangs in singlespecs

by jan matejek

hello, On 23.12.2017 00:45, Luciano Santos wrote: > I read the python singlespec on the wiki but some parts felt kind of obscure to me. If it had either > all the macros for singlespec purposes, or at least all the most useful ones with their use cases > description I could've made the pain go away with my own meds. there's a full list on the github page, which is linked from the wiki: https://github.com/openSUSE/python-rpm-macros i'll make the link more prominent as soon as the wiki unlocks >> The problem is that there isn't actually a macro for "true if package is built for python2/3". This >> needs to be fixed. Now you can use "%if 0%{?have_python2}". It's not exactly the right thing but it >> works. >> >> %python_expand sed -i '$python for you' %{buildroot}%{_datadir}/doc/packages/$python-gobject ..... > > Now, that's such an interesting piece of information. The have_python macro and this use of > %python_expand with some other information on the wiki were the missing puzzle pieces that I needed. > Thank you Jan and Sebastian for your time. >

4 years, 4 months

[opensuse-packaging] Help: Build fails on Leap Builds

by Klaas Freitag

Hi, can anybody help me to understand what is going wrong in https://build.opensuse.org/package/show/home:ocfreitag:branches:KDE:Extra/o… ? The Leap builds are failing because of a post build check complaining about duplicates: [ 174s] found conflict of owncloud-client-2.4.0-27.1.x86_64 with owncloud-client-doc-2.4.0-27.1.x86_64: [ 174s] - /usr/share/doc/packages/owncloud-client/html/advancedusage.html It complains about all files in the doc subfolder called 'html' which should be in the -doc subpackage, and only there. The main package owncloud-client should only contain a few doc files like README and such. In the Tumbleweed builds, this all works like expected, and the packages contain the right doc files. What is going on with the Leap builds? Thx, Klaas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] nodejs2rpm

by Erico Mendonca

Hello all, I made a little tool to ease the packaging of nodejs extensions, much like py2pack and gem2rpm. It’s a python script that uses Jinja2 templates to download, analyze and produce properly filled SPECs for the nodejs modules. It should work fine for most extensions. Only the ones that require native compiling will require some manual editing. The package is located here: https://build.opensuse.org/package/show/home:emendonca/nodejs2rpm And the source code is on Github: https://github.com/doccaz/nodejs2rpm Could you guys take a look at it? Any suggestions are welcome. -- Erico Mendonça Dedicated Support Engineer SUSE

4 years, 4 months

[opensuse-packaging] How to find what pulls in python3

by Dave Plater

Hi, I've a package wxhexeditor which is failing due to python3 being pulled in to the build. What's the quickest way to find which package used for the build is suddenly pulling in python3. 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

4 years, 4 months

[opensuse-packaging] Python Singespec: systemd unit file conflict

by Matwey V. Kornilov

Hello, I am packaging an python application following Python Singlespec guide. In the application, there is a command line tool that is handled by update-alternatives to make it possible to use python2 or python3 version simultaneously. There is also systemd unit file that uses the command line tool to run some service daemon. And currently, systemd unit file leads to the conflict between python2-appname and python3-appname packages. What is the preferred way to resolve the conflict? I haven't heart about update alternatives applied to systemd units. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] Proper way to set shebangs in singlespecs

by Luciano Santos

Hi openSUSE hackers, I have been looking for a way to properly set the right shebang in a python singlespec package. But without any lucky so far. The naughty package in question is python-gobject: https://build.opensuse.org/package/show/GNOME:Next/python-gobject I did some try and error with %ifpython macro, which seems to be the usual way to make this right, but after toasting some kittens I stopped and realized this is not working. Have someone cross this path before? If someone have succeeded in such quest and could shed some light on this one for my curiosity's sake and the package's health as well, of course, I would be grateful. Looking forward for your thoughts, Luciano. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] How to remove a deprecated/EOL-ed package from openSUSE?

by Lee Duncan

Hi: I manage the "targetcli" and "lio-utils" packages in IBS and OBS. We have end-of-lifed targetcli in SLE 15, which will mean the same for Leap 15. I am aiming to do the same with lio-utils. They have both been replaced by targetcli-fb. How do I go about removing them? Or do I just leave them but not touch them, i.e. they are available but unsupported? -- Lee Duncan SUSE Labs -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] Re: [opensuse-factory] RFC Generic Packaging for Languages that have vendor/ Trees

by Neal Gompa

On Tue, Dec 19, 2017 at 4:32 PM, Aleksa Sarai <asarai(a)suse.de> wrote: > Hello *, > > This is a proposal for having a generic packaging system of RPMs for > languages that use "vendor/" trees. Please respond with any feedback you > have on the details of this proposal. > > The main justification for the need for this proposal is that we have > seen the recent rise of languages that have an *enormous* number of > "micro-packages" (JavaScript is the most well-known offender here, where > the majority of widely used packages are only several lines long, but > Rust has a similar issue, and Go/Ruby do too). This has effectively made > it an impracticality (or even an impossibility for some languages) to > create a 1-to-1 RPM mapping for each package. So while a 1-to-1 RPM > mapping is arguably the most ideal (both from a idealogical perspective > and a tooling perspective), the maintenance burden is far too high. > > Another problem is that many projects written in these sorts of > languages these days "vendor" their dependencies, usually using a > language-specific package manager to do so. (This is slightly ironic in > my opinion, because if they'd integrated more with distributions this > ideally wouldn't be necessary, but that ship has sailed.) This is a > problem that also needs to be resolved. Luckily such projects usually > have some sort of "lock file" that describes what is present inside the > "vendor/" tree -- this is something that will be useful later. It should > be noted that the 1-to-1 RPM mapping also doesn't help here either as it > further will balloon out the number of packages we would need to have > (as each project might have different version dependencies). Debian has > been attempting to do this with Go packages, and as far as I can see > it's quite a futile effort because of the maintenance burden that comes > from it. > > At the moment the way that most packages deal with this problem is that > they just punt completely on reproducibility and audit-ability, and just > vendor all dependencies in a project and then tar up the vendor/ tree > and include it in the OBS project. For a JavaScript project this would > involve just running `yarn <blah>` (or whatever the command is) and then > taking node_modules/ and creating a node_modules.tar.xz that is > included in the specfile. The main problem with this approach currently > is that it is completely unauditable and nobody knows what's inside > that magic vendor blob. *However* the core idea is not completely > insane. The Rust folks have also started doing the same thing with > cargo-vendor. > > And here we come to my proposal. The idea is to take what is already > being done in these projects, and create better tooling around it to > make the work of development, maintainence, security, and legal much > easier. > > First, we need to provide more metadata about these vendor blobs in the > RPM layer, so that security could at least *track* what versions of > things are used by a project. And in the worst case, it should be > possible to patch a vendor blob. This would likely best be done through > RPM macros, by creating a virtual Provides for each of the vendored > libraries. This matches what Fedora does for bundled libraries[1]. The > Provides could be just as simple as > > Provides: bundled(rust:nix) = 0.8.1 > > Or something more involved to be extra paranoid: > > Provides: bundled(rust:registry+https://github.com/rust-lang/crates.io-index:nix) = 0.8.1 > > Secondly, in order to make this vendor archive reproducible, I propose > we have an OBS service that can be used to vendor a source tree (which > can obviously be run either locally or on OBS). It will produce all of > the vendor archives created by language-specific tools, and produce a > language-agnostic manifest of what was downloaded (the name, language, > version, git commit, and so on). The idea is that this manifest could be > used by the RPM macros above rather than writing language-specific > macros. > > I have already started working on the OBS service, but I would love to > hear your feedback on this proposal. > > [1]: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libra… > I don't fully disagree with your proposal, but I will point out a few things: * The current vendoring of rust crates is temporary. We're waiting on RPM 4.14[1] and the new product builder to come online (DimStar already slapped me once for breaking Tumbleweed with rich deps before...). I'm working on making rust2rpm make openSUSE-friendly spec files (mainly add the boilerplate header, skip conversion of SPDX to Fedora license tags, generate changes file) so that crates can be easily packaged and shipped in the distribution. Right now, Fedora has well over 230 Rust crates packaged[2], and the packaging for them is pretty trivial[3]. We've also got a good handle on cargo integration, so crates function as if they're in a local cargo registry for things to depend on. * I'm not sure why openSUSE hasn't adopted the bundled() Provides thing across the board anyway. There are plenty of packages that ship vendored trees/libraries and no one knows what they are. In general, it's really not a bad idea to do that. In my opinion, it's irresponsible to not require what you bundle to be defined. Generally speaking, I think this is a solid idea, but I solidly do not believe we will be continuing the vendored crates practice for much longer in Rust. [1]: https://build.opensuse.org/request/show/558345 [2]: https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=ru… [3]: https://pagure.io/fedora-rust/playground -- 真実はいつも一つ！/ 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

4 years, 4 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging December 2017