openSUSE Packaging

packaging@lists.opensuse.org

11 participants
3837 discussions

by Hans-Peter Jansen

Hi, is it possible to trick a local osc build into producing colored output without much fuzz? The point is, if I 'osc chroot' into the package and trigger a build manually, colored output is generated. Therefor I guess, rpmbuild ignores/avoids certain environment values (COLORTERM?) for better parsebility. For local builds of huge projects, colored output would be much nicer, since it would be easier to distinguish between warnings and errors. Cheers, Pete

1 day, 6 hours

Logrotate, /var/log but logging disabled by default

by Thorsten Kukuk

Hi, we have quite some packages, which: 1. require logrotate and ship a logrotate configuration file 2. have a special directory in /var/log 3. never create a log file as they are controlled by systemd The reason the packages never write to the log file by default is, that they log to stdout/stderr and systemd/journald captures them. What should we do with such packages? Requiring logrotate, even if never used by default, is already a bad idea. It runs regular (so uses resources) without doing anything. Clobbering /var/log with special directories and files owned by special users will also only trigger actions, even if never used. What would be a good solution? I understand that some people may want to run this tools without control by systemd. But on the other side, in this cases the people have to adjust the configuration anyways. Maybe a good solution could be: - continue to ship the logrotate configuration file - only Recommend logrotate, not require it - let the admin create the configuration file and directory Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

1 day, 21 hours

[opensuse-packaging] Re: [opensuse-factory] Re: "Keep up with openSUSE Packaging" article

by Lukas Kucharczyk

Hi, > It's good there is such a good and exhaustive description. > If there would be also such a good quick how to for beginners, it'd be really > beneficial, as the lower entry barrier, the more contributors. It is not very visible but on the bottom of https://build.opensuse.org there is a link to OBS manuals (https://openbuildservice.org/help/manuals/obs-user-guide/). While this of course attemps to cover the issue for somebody wanting to use OBS, it does cover basics of packaging and could serve as a quick start guide for complete beginners - speaking from experience here :) -- Lukas Kucharczyk — Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 — Karlín, Czech Republic Email: lukas.kucharczyk(a)suse.com - Office telephone: +420 284 084 000

2 weeks, 1 day

[opensuse-packaging] Re: [opensuse-factory] Re: "Keep up with openSUSE Packaging" article

by Martin Wilck

On Fri, 2020-11-20 at 17:29 +0100, Richard Brown wrote: > I respectfully but strongly disagree. > > Packaging is not static knowledge, and the requirements that > packaging > has to fufil is not static. > > This article documents packaging changes which all happened as a > result > of requirements in Tumbleweed, MicroOS, Leap/Jump, SLE or other SUSE > Products. > > None of this was 'change for changes sake'. > > If if you very narrow mindedly consider only what is clearly on the > horizon for SLE, there is no avoiding change at the sort of level you > see captured in this document. > > On the contrary, I'd expect some to argue that all this change isn't > enough and more significant, rapid, and invasive changes to how we > package things to be necessary. Sure thing. Some people say that rpm itself is obsolete 20th-century technology. We've had this discussion many times - outside the narrow world of rpm-based distros, hardly anyone cares about this stuff. I see this as voting-by-feet, at least in part. By changing the rules every other year, we make it harder than needs to be, and less likely that people will enjoy contributing to our project. > In such an environment, I find articles like this one put together by > Vitezslav and Kristyna to be absolutely wonderful and like to > encorage > them to write more, at this level of detail, as often as they can. I didn't say the article was bad. Quite to the contrary, it's a nice source of information. I'll make sure I bookmark it for the next time my packages fail some lint check (along these lines - why is document located on github rather than on the openSUSE Wiki, where people would primarily look for it? So far I didn't even find a reference on the Wiki). There's one point where the article falls short IMO, and that's backward compatibility. For each of the new macros, it should at least tell on which distros/service packs it is (or will be) available. I'm generally fine with changing my spec files, but I positively hate having to add conditionals because newer flavors require using macros that old ones don't have. Martin -- Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer

2 weeks, 1 day

[opensuse-packaging] "Keep up with openSUSE Packaging" article

by Kristyna Streitova

Hello all, I would like to point you to the pretty extensive article about news and important changes in openSUSE Packaging we wrote. It covers recent changes in macros, paths, tags and also new and cool features in RPM or OBS. Visit: https://packageninjas.github.io/packaging/2020/10/13/news-in-packaging.html I believe that whether you are a pro package maintainer or just a casual packager who wants to catch up, you will definitely find here something you didn’t know. Btw. If you find any error, please report it here: https://github.com/PackageNinjas/PackageNinjas.github.io Best regards, Kristyna Streitova & Vitezslav Cizek

2 weeks, 1 day

[opensuse-packaging] any indication when py2pack will work again?

by Axel Braun

Hi, py2pack currently fails on pypi.io: xmlrpc.client.Fault: <Fault -32500: 'HTTPTooManyRequests: The action could not be performed because there were too many requests by the client. Limit may reset in 1 seconds.'> Does anyone have an indication when this may work again? Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 weeks, 3 days

[opensuse-packaging] Container build failure in OBS - error validating timezone

by William Brown

https://build.opensuse.org/package/show/home:firstyear/389-ds-container See the following error: [ 48s] ----------------------------------------------------------------- [ 48s] ----- building Dockerfile [ 48s] ----------------------------------------------------------------- [ 48s] ----------------------------------------------------------------- [ 48s] Loading base image [ 48s] Layered image found [ 48s] time="2020-10-29T03:54:55Z" level=error msg=" error validating containers config: find timezone in paths: /usr/share/zoneinfo, /etc/zoneinfo" [ 50s] Building image 389-ds-container [ 50s] Unsharing environment [ 50s] time="2020-10-29T03:54:57Z" level=error msg=" error validating containers config: find timezone in paths: /usr/share/zoneinfo, /etc/zoneinfo" [ 50s] podman build command failed [ 50s] ### VM INTERACTION START ### [ 53s] [ 44.848217] sysrq: Power Off [ 53s] [ 44.855865] reboot: Power down [ 53s] ### VM INTERACTION END ### [ 53s] [ 53s] lamb15 failed "build Dockerfile" at Thu Oct 29 03:55:00 UTC 2020. [ 53s] Not really sure what this is but it seems like some kind of environment issue with the builder. I tried to add the timezone package but that didn't do the trick, so wondering if anyone has any ideas here? Thanks, — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 month, 1 week

[opensuse-packaging] problem building postgres 12 for Leap 15.2

by Axel Braun

Hi, maybe one of the packaging experts can enlighten me: When building https://build.opensuse.org/package/show/home:DocB:Orthanc/orthanc-postgresql in OBS everything works. When building the package locally on my TW machine it fails finding postgres: [ 10s] -- Could NOT find PostgreSQL (missing: PostgreSQL_TYPE_INCLUDE_DIR) (found version "12.2") [ 10s] -- Looking for C++ include orthanc/OrthancCDatabasePlugin.h [ 10s] -- Looking for C++ include orthanc/OrthancCDatabasePlugin.h - found [ 10s] Setting the version of the libraries to 3.2 [ 10s] -- Configuring done [ 10s] CMake Error: The following variables are used in this project, but they are set to NOTFOUND. [ 10s] Please set them or make sure they are set and tested correctly in the CMake files: [ 10s] PostgreSQL_TYPE_INCLUDE_DIR (ADVANCED) As I usually build packages locally before I send them to OBS, it burned some time..... Where does the difference come from, as local build uses the build Info from OBS? Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 month, 2 weeks

[opensuse-packaging] Obsoleting even though not strictly compatible?

by Aaron Puchert

Hi, Recently I got a bug report [1] and I'm not sure if and what I should do about it. Background is that we have llvm (including subpackages) in multiple versions in the distributions, because major releases come out about twice a year and we're not in a situation where all dependencies work (or claim to work) with the same major version. So there is for example llvm7, llvm8, llvm9, llvm10. Additionally we have a metapackage llvm that just requires the newest versioned package, in this case llvm10, and doesn't contain any files itself. Now some of the subpackages can coexist, but others cannot, most notably the -devel packages. So if you happen to have llvm-devel installed (which currently requires llvm10-devel), you will soon get a conflict on zypper dup: the new llvm-devel = 11.0.0 will require llvm11-devel, but that conflicts with the existing llvm10-devel. Now there is nothing I can do about the conflict, but I could make llvm-devel = 11.0.0 obsolete llvm10-devel (and older versions), which would supposedly let me update without conflicts (haven't tested it yet because OBS is letting me wait). The idea behind putting the Obsoletes on the metapackage instead of the versioned package is that users can either install a versioned package llvmX-devel that stays with them or llvm-devel which allows them to have whatever the current version is. However, rpmlint complains: > <package>: W: obsolete-not-provided <obsoleted-package> > If a package is obsoleted by a compatible replacement, the obsoleted > package should also be provided in order to not cause unnecessary > dependency breakage. If the obsoleting package is not a compatible > replacement for the old one, leave out the Provides. Indeed I don't intend to add a Provides, because the packages are in general not fully compatible. Can I ignore rpmlint here or is this a bad idea for some reason that I'm overlooking? Best regards, Aaron [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1175983 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 month, 2 weeks

[opensuse-packaging] Something on OBS looks stuck...

by Mathias Homann

Hi, I think something on OBs needs a nudge - half the workers are idle and roughly 2000 repos are waiting to be recalculated. Cheers MH -- Mathias Homann Mathias.Homann(a)openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

1 month, 3 weeks

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging