January 2021 - packaging - Fedora Mailing-Lists

RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

by Ben Cotton

https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changel... == Summary == redhat-rpm-config will be updated so users of the auto framework get automated release and changelog bumping. == Owner == * Name: [[User:nim| Nicolas Mailhot]] * Email: <nicolas.mailhot at laposte.net> == Detailed Description == This is a system-wide change because all packages build with redhat-rpm-config, but it only concerns packages that opted to use this part of redhat-rpm-config (auto framework). The change will make those packages auto-bump and auto-changelog at the rpm level, in an infrastructure-independent way. == Benefit to Fedora == Autobumping removes a huge packager shore and makes timestamping in changelogs more reliable. == Scope == * Proposal owners: The feature is coded and works at the rpm level. Unfortunately, mock filters away the srpms containing the bump state, so it does not work in upper layers. * Other developers: The feature requires buy-in by mock developers (and probably koji developers) to lift the restrictions that block it above the rpm level. Also, it requires a mechanism to pass the user name and email that will be used in bumped changelogs (defining two variables in ~/.rpmmacros is sufficient at rpm level) * Mock issue: https://github.com/rpm-software-management/mock/issues/599 * Release engineering: https://pagure.io/releng/issue/9567 * Policies and guidelines: maybe eventually if things work out on the technical level * FPC issue: https://pagure.io/packaging-committee/issue/998 * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This is a pure build tooling update, it changes how things are built not what is built. == How To Test == A redhat-rpm-config packages with the changes and some example packages are available in https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-aut... Since the mock/copr layer is currently blocking the feature, you need to install the redhat-rpm-config and forge macro packages available in this repo locally. Afterwards you can take any of the example packages in the repo and rebuild them with rpmbuild -ba to your heart content, and see the releases bump and the changelogs being updated accordingly. To get beautiful changelogs, you also need to add <pre> %buildsys_name Your name %buildsys_email Your email </pre> in ~/.rpmmacros == User Experience == N/A Packager experience change only == Dependencies == The change is a spin-off of https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_mac... Therefore, it depends on the success of that other change and will probably need rebasing if the code in this other change evolves during the redhat-rpm-config merge. It also depends on mock / copr/ koji buy-in and changes, that may add their own requirements. == Contingency Plan == There is no contingency plan because the change will happen or not at all. == Documentation == There is as much documentation as the average redhat-rpm-config change (ie comments in the macro files themselves) == Release Notes == N/A Packager productivity change only -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

9 months, 3 weeks

12
23
0 / 0

Schedule for Thursday's FPC Meeting (2019-08-15 16:00 UTC)

by James Antill

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-08-15 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2019-08-15 09:00 PDT US/Pacific 2019-08-15 12:00 EDT --> US/Eastern <-- 2019-08-15 16:00 UTC UTC 2019-08-15 17:00 BST Europe/London 2019-08-15 18:00 CEST Europe/Berlin 2019-08-15 18:00 CEST Europe/Paris 2019-08-15 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2019-08-16 00:00 HKT Asia/Hong_Kong 2019-08-16 00:00 +08 Asia/Singapore 2019-08-16 01:00 JST Asia/Tokyo 2019-08-16 02: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 #902 Cleanup & enhance spec files .fpc 902 https://pagure.io/packaging-committee/issue/902 #topic #904 Caret versioning .fpc 904 https://pagure.io/packaging-committee/issue/904 #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 #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = 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 year, 10 months

3
2
0 / 0

Odd problem with obsoletes in EPEL8

by Martin Jackson

Hello, I'm having a problem I don't understand how to fix, and I would appreciate some guidance. I'm maintaining nagios-plugins, which bundles a number of different "check" plugins and has some metapackages that include different subsets of those check plugins. In the EL 8.2 release cycle, one of the dependencies of one of those plugins was moved from EPEL into EL proper, which broke new installs of that plugin and the -all metapackage. A user filed a bug, so as a temporary workaround, I stopped building the plugin package with that dependency (nagios-plugins-ssl_validity, and had that version (nagios-plugins-2.3.3-3) obsolete the ssl_validity plugin, since leaving it around caused it to want to keep the base package in conflict with other packages that were upgrading. Now that CentOS 8.2 is released, and the dependency is available, I've issued an update (https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-70bcfe5382) that builds ssl_validity again, and also adds it back to the -all subpackage. I can upgrade it sucessfully (which installs the ssl_validity plugin again, as expected), but subsequent calls to dnf upgrade give this error: Obsoleting Packages nagios-plugins.x86_64 2.3.3-3.el8 epel nagios-plugins-ssl_validity.x86_64 2.3.3-4.el8 @epel-testing nagios-plugins 2.3.3-3 is not installed anymore, and there are no explicit Obsoletes: in the ssl_validity package. I'm not sure what needs to be done here, but whatever it is I'm willing to make the change. Also wondering if this is expected behavior. Thanks, Marty

1 year, 10 months

2
1
0 / 0

luarocks' rocks tree location: %{_libdir}/luarocks, %{_prefix}/lib/luarocks, or %{_var}/lib/luarocks?

by Michel Alexandre Salim

Hi all, I'm overhauling luarocks' packaging (TL;DR, it's the Lua equivalent of Python's pip or Rust's cargo). Previously it flipped from being a noarch package (because the files shipped are pure Lua code) to arched (because it hardcoded some settings based on the system it's built on). With recent luarocks that's no longer necessary as it can auto-detect the installed Lua environment (I added a little patch to make it prefer /usr/lib64 if it is available). This works well, but ... luarocks keeps a 'rocks tree' (basically a record of which rocks are installed and their checksums): ``` $ luarocks config | grep ROCKS ROCKS_TREE = "/usr/lib/luarocks/rocks-5.4", ``` The files here are mostly noarch but if the user compiles a binary module it does record the checksum of the binary as well. e.g. ``` $ cat /usr/lib/luarocks/rocks-5.4/bit32/5.3.5.1-1/rock_manifest rock_manifest = { ["bit32-5.3.5.1-1.rockspec"] = "63172097de28df84f5de587c25d866d0", doc = { LICENSE = "47a1db9761ff46e15d0f65fbc87d4bd5", ["README.md"] = "0f5f506e9b1697622bf4a2e0faeb1746" }, lib = { ["bit32.so"] = "5b35079ba129529a30f6a7f9adba309e" } } ``` Would %{_var}/lib/luarocks be a better location for this? (since it's in effect similar to /var/lib/rpm and /var/lib/dnf). Either that location or /usr/lib would be fine for now. If we ever want to, say, use luarocks to build lua module RPMs, this might be a problem if we ever want 64-bit and 32-bit RPMs to be installable. We can always get around it by stripping the rock manifests though. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name

2 years, 4 months

1
0
0 / 0

Pagure

by Brad Bell

I would like to add the epel8 branch to my repository. When I try to, I get the following response: >fedpkg request-branch epel8 Could not execute request_branch: The following error occurred while creating a new issue in Pagure: Invalid or expired token. Please visit https://pagure.io/settings#nav-api-tab to get or renew your API token. For invalid or expired token refer to "fedpkg request-repo -h" to set a token in your user configuration. When I visit the site it is not clear to me what I should do. Would someone please point me to the documentation for this ?

2 years, 4 months

2
1
0 / 0

Fedora 33+: spectool -g downloads text sources/patches as gzipped; fix in updates-testing

by Miro Hrončok

Hello packagers, if you have rpmdevtools-9.3-2.fc33 (or .fc34) installed and you run `spectool -g` on spec files with remote text sources/patches, such as git(hub|lab)/pagure patches, or signatures/keys: Patch1: https://pagure.io/rpmdevtools/pull-request/77.patch Patch2: https://github.com/prusa3d/PrusaSlicer/commit/44f71f0ed1.patch Source1: https://www.python.org/.../Python-%{version}.tar.xz.asc Source2: https://www.python.org/static/files/pubkeys.txt ... etc ... They might be downloaded gzipped, depending on the configuration of the webserver that serves them. They are known to be downloaded gzipped at least from Pagure and GitHub. The fix is available in rpmdevtools-9.3-3.fc33 (or .fc34). Fedora 33 update: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cb926a505c All Fedora/EL/... package maintainers running Fedora 33, 34 or ELN/RHEL9 are advised to update. $ sudo dnf upgrade --enablerepo=updates-testing rpmdevtools The affected version never reached Fedora 32 or RHEL 7/8. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 years, 4 months

1
0
0 / 0

Summary/Minutes from today's FPC Meeting (2021-01-21 17:00 - 17:35 UTC)

by James Antill

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 17:00:04 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2021-01-21/fpc.2021-01... . Meeting summary --------------- * Roll Call (geppetto, 17:00:04) * Schedule (geppetto, 17:09:21) * LINK: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje... (geppetto, 17:09:25) * #pr-1041 Use only .metainfo.xml in AppData guidelines (geppetto, 17:09:36) * LINK: https://pagure.io/packaging-committee/pull-request/1041 (geppetto, 17:09:42) * ACTION: Use only .metainfo.xml in AppData guidelines (+1:5, 0:0, -1:0) (geppetto, 17:15:12) * Open Floor (geppetto, 17:15:20) * LINK: https://pagure.io/packaging-committee/pull-request/1026 (decathorpe, 17:17:43) * ACTION: carlwgeorge Speak to EPEL steering committe about moving wiki pages to antora (geppetto, 17:24:20) Meeting ended at 17:36:20 UTC. Action Items ------------ * Use only .metainfo.xml in AppData guidelines (+1:5, 0:0, -1:0) * carlwgeorge Speak to EPEL steering committe about moving wiki pages to antora Action Items, by person ----------------------- * carlwgeorge * carlwgeorge Speak to EPEL steering committe about moving wiki pages to antora * **UNASSIGNED** * Use only .metainfo.xml in AppData guidelines (+1:5, 0:0, -1:0) People Present (lines said) --------------------------- * geppetto (31) * tibbs (20) * zodbot (17) * ignatenkobrain (16) * King_InuYasha (11) * decathorpe (10) * carlwgeorge (7) * tstellar (4) * limburgher (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

2 years, 4 months

1
0
0 / 0

Schedule for Thursday's FPC Meeting (2021-01-21 17:00 UTC)

by James Antill

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2021-01-21 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2021-01-21 09:00 PST US/Pacific 2021-01-21 12:00 EST --> US/Eastern <-- 2021-01-21 17:00 GMT Europe/London 2021-01-21 17:00 UTC UTC 2021-01-21 18:00 CET Europe/Berlin 2021-01-21 18:00 CET Europe/Paris 2021-01-21 22:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2021-01-22 01:00 HKT Asia/Hong_Kong 2021-01-22 01:00 +08 Asia/Singapore 2021-01-22 02:00 JST Asia/Tokyo 2021-01-22 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot #topic Open Floor * decathorpe look through non-meeting tickets, see if any are stuck/need to be discussed = Followup Issues = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 = Pull Requests = #topic #pr-1041 Use only .metainfo.xml in AppData guidelines https://pagure.io/packaging-committee/pull-request/1041 = 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.

2 years, 4 months

1
0
0 / 0

Are AppStream metadata packaging guidelines up to date?

by Otto Urpelainen

Greetings, I am a new contributor to Fedora packaging. My actual target is to add some applications I use but are not packaged yet. But since adding a new package is quite complex and Fedora also places some requirements before a contributor is allowed to do that, I have started learning by doing some simpler tasks first. I have been looking at various packages I use personally, trying to find some things to improve. I noticed that the gpodder <https://src.fedoraproject.org/rpms/gpodder> package would benefit from some work on its AppStream metadata. My first though was to simply make it comply with the Packaging Guidelines: AppData <https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/> section in Fedora Docs. But, the instructions there lead to a setup that is deprecated according to AppStream current specification <https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#...>. This is my first encounter with AppStream, but from the guidelines page naming it seems that even the name has changed from AppData to AppStream after the guidelines were written. So the question is this: Should Fedora packages really follow the guidance from /Packaging Guidelines: AppData/, or should that page be updated? Perhaps I should also explain what is wrong with the gpodder package: Its spec file contains an inline /appdata.xml/ that is installed to //usr/share/appdata/. However, since /appdata.xml/ was added, upstream has started shipping its own AppStream file. That is also installed, but to //usr/share/metainfo/, with a different file name, different application id and diffrent content. Dropping the inline version and installing only the upstream version seems clear enough, but to me it seems like the Packaging Guidelines give bad advice on how to go about that. Regards, Otto Urpelainen

2 years, 4 months

2
4
0 / 0

Packaging guidelines for Requires(meta)

by Miro Hrončok

On 18. 01. 21 9:35, Daniel Mach wrote: > * Meta dependencies, eg Requires(meta) allow specifying dependencies > without introducing ordering constraints Do we need guidelines for this? Quote from https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... Relevant BZ (somewhat): https://bugzilla.redhat.com/show_bug.cgi?id=1648721 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 years, 4 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2021