packaging March 2020

packaging@lists.fedoraproject.org

20 participants
19 discussions

question about rpmlint E: non-executable-script
by chedi toueiti 11 Mar '20

11 Mar '20

Hi, I'm reviewing a new package https://bugzilla.redhat.com/show_bug.cgi?id=1810902 this package have bash scripts that are under /usr/lib and starting with a shebang, rpmlint is detecting the error E: non-executable-script rpkg-macros.noarch: E: non-executable-script /usr/lib/rpkg.macros.d/all.bash 644 /bin/bash rpkg-macros.noarch: E: non-executable-script /usr/lib/rpkg.macros.d/git.bash 644 /bin/bash rpkg-macros.noarch: E: non-executable-script /usr/lib/rpkg.macros.d/library/log.bash 644 /bin/bash rpkg-macros.noarch: E: non-executable-script /usr/lib/rpkg.macros.d/library/output.bash 644 /bin/bash rpkg-macros.noarch: E: non-executable-script /usr/lib/rpkg.macros.d/library/query.bash 644 /bin/bash rpkg-macros.noarch: E: non-executable-script /usr/lib/rpkg.macros.d/library/utils.bash 644 /bin/bash The author desire to keep the shebang and not set the execution bit as the files are not meant to be executable. Should I consider the package valid or not in this case. -- *Chedi Toueiti* * Due to the constant fluctuation in customer personalities, we cannot be responsible for the mental stability of any one member of our staff. ** My opinions may have changed, but not the fact that I am right. *** I always try to go the extra mile at work, but my boss always finds me and brings me back.

3 2

i686 build on f32, is ExclusiveArch forcing it?
by Marcin Dulak 09 Mar '20

09 Mar '20

Despite the removal of i686 from Fedora repositories https://pagure.io/releng/issue/8529, I have a build https://bodhi.fedoraproject.org/updates/FEDORA-2020-f9333353d9 that includes i686. Is it due to "ExclusiveArch: %{ix86} x86_64" being present in the spec? https://src.fedoraproject.org/rpms/ga/blob/d757bfd5d6e0d79cf64c6528a5bab815… Is the presence of i686 also making the build to stay 3 days in "Pending -> Stable"?

2 2

Need help with empty debugsourcefiles.list
by Mattia Verga 07 Mar '20

07 Mar '20

I have to split the libpasastro package because one component was moved in its own package upstream (libpasraw). The problem is that the new package doesn't seem to find the debug information: https://copr.fedorainfracloud.org/coprs/mattia/Astronomy/build/1297165/ The libpasraw.so file is not put in the debugsourcefiles.list file, while in the old package it was: https://koji.fedoraproject.org/koji/buildinfo?buildID=1440945 The compiler flags seem to be the same and I patched the source install script to avoid stripping debug information from the library as I did before... can someone give me an idea why this isn't working anymore?

1 0

Schedule for Thursday's FPC Meeting (2020-03-05 17:00 UTC)
by James Antill 04 Mar '20

04 Mar '20

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-03-05 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2020-03-05 09:00 PST US/Pacific 2020-03-05 12:00 EST --> US/Eastern <-- 2020-03-05 17:00 GMT Europe/London 2020-03-05 17:00 UTC UTC 2020-03-05 18:00 CET Europe/Berlin 2020-03-05 18:00 CET Europe/Paris 2020-03-05 22:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2020-03-06 01:00 HKT Asia/Hong_Kong 2020-03-06 01:00 +08 Asia/Singapore 2020-03-06 02:00 JST Asia/Tokyo 2020-03-06 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 = Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines https://pagure.io/packaging-committee/pull-request/814 #topic #pr-938 Add Package Review Process page https://pagure.io/packaging-committee/pull-request/938 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

1 0

Re: Ideas and proposal for removing changelog and release fields from spec file
by Nicolas Mailhot 03 Mar '20

03 Mar '20

Le 2020-03-02 14:45, clime a écrit : > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel > <devel(a)lists.fedoraproject.org> wrote: >> >> Le 2020-03-01 02:31, clime a écrit : >> > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel >> > <devel(a)lists.fedoraproject.org> wrote: >> >> >> >> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit : >> >> >> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using >> >> detached file state means that fedpkg local (or checking out git state >> >> and building in mock or copr or OBS or via plain rpmbuild -bs) will >> >> give you the same result as launching fedpkg build. >> > >> > Well, I believe it doesn't. You run: >> > >> > 1) fedpkg local -> produces <somepkg>-1.0-1.fc32 (1 in release because >> > you haven't built that package before) >> > 2) fedpkg build >> >> At that point state is undefined till the build succeeds or not. If >> the >> build succeeds, the buildsystem will write back a new state. Let’s >> assume it succeeds. > > It's undefined if you add more elements to the equation than necessary > (i.e. build system), otherwise it would be well-defined in this case. > >> >> > 3) vim <somepkg>.spec and do some change in %description >> > 4) fedpkg commit -m "description improvement" >> > 5) fedpkg local -> produces <somepkg>-1.0-1.fc32 >> > 6) fedpkg push -> error because build system pushed meanwhile >> >> Yes, here the packager notices something else has been going on, and >> he >> needs to merge or rebase. He’d have the same effect if another >> packager >> had been doing stuff on the package, or a mass rebuild had been going >> on. That’s the distributed decentralized aspect of git, except here >> the >> packager collided with himself by starting two work threads in >> parallel >> (one buildsys-side, one local). > > The problem is that you launched some process and you need to wait > until it finishes, normally you don't need to anything like that when > working with git. But fedpkg build is a release to production process. It’s not a dev staging process. In release processes, actually doing the release is not an inconvenient optional check. You're asked to autobump a “Release” field. You’re asked to automate a changelog which is effectively a release changelog, not dev changelog (the dev changelog lives in git, people want a good changelog in rpm proper to track release not git history). The *single* *only* reason good release numbers and good changelog matter is because the result will be released to third parties. koshei, or scratch builds, or whatever, do not care about those. A normal git flow would lock the branch at release time to let the release manager do his releasing (merge window closed in Linus’s terms). That’s option 1 I gave you. Alternatively, you can use option 2, the “I feel lucky” approach, let everything open, and abort the release if merge-back failed. A packager that changes his package before the production build is finished will probably want it canceled anyway (what is the point of risking breaking builds of other packages by pushing an unfinished package to the shared koji buildroot)? Either option does not stop the packager to do anything he wants in his local branches. They just require him to merge/rebase when syncing with the centralized master Fedora state. That’s a core element of git architecture, be it in Fedora or elsewhere. You can not avoid a buildsys merge-back when doing production builds. The merge-back can be explicit and automatic (as I proposed), or you can rely on informal meatware for it, but it will exist. Since the whole point of the request is to lower dependence on meatware, why on hell would you want to keep meatware as part of the whole process? The only “cost” for the packager is to wait for his build to finish before continuing to change the package (or merge/rebase). That’s not an horrific cost. No one forced the packager to start a build before he was ready. No one forced the packager to perform a production build instead of a scratch build if he just wanted to check partial changes. If shit happens, and he realizes before the build end something is not ok, aborting the build on failed merge back is helping the packager. Or am I missing something? “normally you don't need to anything like that when working with git” is not a clear technical point. Regards, -- Nicolas Mailhot

2 2

Re: Ideas and proposal for removing changelog and release fields from spec file
by Neal Gompa 03 Mar '20

03 Mar '20

On Mon, Mar 2, 2020 at 8:46 AM clime <clime(a)fedoraproject.org> wrote: > > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel > <devel(a)lists.fedoraproject.org> wrote: > > > > If you don’t keep things decentralized you’ll be in a word of pain when > > the scm or buildsys needs to be changed for another implementation (not > > to mention, that’s not a good way to collaborate with other distros). > > That will happen eventually. Web apps are not eternal. > > Full decentralization likely means that everyone has its own git repo > and we can only sync by mailing list. I think src.fp.o is a good point > where things can be done and where we can agree on what the packages > that Fedora produce are (meaning we need a canonical source of package > sources, otherwise it would be more complex to put a distribution > together). > This is not true. Pagure accepts PRs from arbitrary Git servers just fine via the remote PR feature, so we do support decentralized workflows without resorting to sending patches via email or Bugzilla. -- 真実はいつも一つ！/ Always, there's only one truth!

3 4

How to get into epel8?
by Marcin Dulak 02 Mar '20

02 Mar '20

https://dl.fedoraproject.org/pub/epel/8/ - what is the procedure to get the packages from https://src.fedoraproject.org/ to build for epel8? Marcin

2 2

Ilegal char when computing python dependencies
by Sergio Pascual 02 Mar '20

02 Mar '20

Hi, I have a python package that has most of its information in setup.cfg. I'm updating to python-photutils 0.7.2 and when mock is computing the Requires it shows: Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) python(abi) = 3.8 python3.8dist(numpy) >= 1.13 rtld(GNU_HASH) Obsoletes: python-photutils < 0.7.2-1.fc33 Recommends: python3-matplotlib python3-scikit-image python3-scipy RPM build errors: Illegal char '*' (0x2a) in: 3.0.* Child return code was: 1 This is caused by the following line in setup.cfg [options] ... install_requires = astropy>=2.0.12,!=3.0.*,!=3.1,!=3.1.1 I don't know if the * character is allowed here and the error is a limitation in the management of RPM dependencies or if this is not valid python. Best. Sergio

3 4

Re: Ideas and proposal for removing changelog and release fields from spec file
by Nicolas Mailhot 02 Mar '20

02 Mar '20

Le 2020-03-01 02:31, clime a écrit : > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel > <devel(a)lists.fedoraproject.org> wrote: >> >> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit : >> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using >> detached file state means that fedpkg local (or checking out git state >> and building in mock or copr or OBS or via plain rpmbuild -bs) will >> give you the same result as launching fedpkg build. > > Well, I believe it doesn't. You run: > > 1) fedpkg local -> produces <somepkg>-1.0-1.fc32 (1 in release because > you haven't built that package before) > 2) fedpkg build At that point state is undefined till the build succeeds or not. If the build succeeds, the buildsystem will write back a new state. Let’s assume it succeeds. > 3) vim <somepkg>.spec and do some change in %description > 4) fedpkg commit -m "description improvement" > 5) fedpkg local -> produces <somepkg>-1.0-1.fc32 > 6) fedpkg push -> error because build system pushed meanwhile Yes, here the packager notices something else has been going on, and he needs to merge or rebase. He’d have the same effect if another packager had been doing stuff on the package, or a mass rebuild had been going on. That’s the distributed decentralized aspect of git, except here the packager collided with himself by starting two work threads in parallel (one buildsys-side, one local). > 7) fedpkg pull --rebase (to quickly fix the error) > 8) fedpkg build -> builds <somepkg>-1.0-2.fc32 > > To get the correct NVR for the package being built by `fedpkg local` > you need to wait for some external process to finish first so that you > can pull the new state. Only then you get correct value again. Sure, that‘s the inconvenient of state: it needs syncing. And the whole auto-bump thing intrinsically depends on state not provided manually by human beings. However putting state in git would be no better, because you’d end up assuming a build exists before it does, in fact, build (and builds do fail because packagers are imperfect humans). And putting state in buildsys would also not be any better because successful production builds end up in changelogs and you want changelogs to be tracked. So, no matter how you re-arange things, you’ll always have a buildsys sync-back somewhere (you have it today when humans change their changelogs after a failed build; automating that makes the sync-back explicit). >> For fedpkg verrel you'll probably want to output a last (saved in >> detached file) and next line (probably factorizable by externalizing >> the dynrel bump logic in a separate command). That’s more honest >> anyway, next may happen or not, when you launch fedpkg verrel, it’s >> mere potential (the next commit may bump version and invalidate your >> future build). > > There is the same problem as above with `fedpkg local`, the command > won't be giving you correct values at all times. There is no correct value to give before production build succeeded or not. When fedpkg local gives you something today it is lying (just try it just before someone mass rebuilds, and then try to commit after this mass rebuild: that will fail and you’ll have to merge/rebase). You’re assuming a simple universe where you’re the only one doing things with a package. That’s not a true assumption, many packages have shared ownership and maintenance (to say nothing of proven-packagers and releng doing things on top of them). > It doesn't need to be the consequence of "automating changelog". It's > only a consequence in certain implementations. If the changelog is > derived purely from the git state, there aren't these problems > anymore. Sure there are. You're assuming anything committed to git builds before actually trying to build it. And expecting manual packager git fixup when that’s not the case. Just like in the sync-back state except with no tooling enforcement and help. >> Putting state in detached srpm source files has the following super- >> duper property. You can import the srpm or scm checkout between >> systems, and they’ll just pick up from the point the previous system >> left things, without needing a full scm import. > > That's nice if there is always just a single provider of the given > package in our ecosystem. In case of copr, you can fork a certain repo > and continue building there so you will be getting bumped numbers on > top of the work done in the original repo. But once the original repo > starts producing some builds as well you will be getting that package > in two versions in two different coprs and while the original repo > might have done less builds than the forked one since the fork > happened, it can contain the package with more features because the > forked repo was simply playing around. You will never get official Fedora git releases changed based on the status of some copr builds. That takes a deliberate package admin action (and that works in the proposal, just fedpkg import the last srpm built in copr, that syncs repos). If you want things to work on the other direction, copr will need to read state from Fedora infra one way or another, and it can perfectly read state from detached files committed back to Fedora git by koji. And then you need a second-level counter for copr, and configure copr for using the the second-level counter only. And then if you want OBS to build from copr that builds from koji… I’m not sure multi-level bumping is in scope for the proposal. If it’s in scope that makes things more complex (but not a lot more complex). Multi-level definitely means the n-th level builder must be able to redefine Release structure, and will want the (n-1)th Release exposed as variable. > I can see the advantage of your proposal that the auto-bumping > theoretically doesn't need git to work. But it still needs git because > you need push the updated %{dynstate} files somewhere. The only way to > avoid it would be to build a new srpm together with the rpm where the > srpm would be the same as the input srpm except for the updated > %{dynstate} files. That’s why I wrote that the last-step of release bumping belongs in rpm proper, at srpm creation stage. Only way I see to get in independent from a specific project scm setup. The last build state must be provided in srpm data as detached file, and the bumping logic make decisions based on this data (we already put state in srpm for reproducible builds, IIRC). > So in case we wouldn't have src.fp.o and the > development would be fully decentralized, I could see your proposal to > be actually the only way to implement auto-bumping and it would be a > nice way. The thing is, the way we are developing today is different > from that If you don’t keep things decentralized you’ll be in a word of pain when the scm or buildsys needs to be changed for another implementation (not to mention, that’s not a good way to collaborate with other distros). That will happen eventually. Web apps are not eternal. Regards, -- Nicolas Mailhot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2020