rel-eng September 2019

rel-eng@lists.fedoraproject.org

10 participants
156 discussions

[Fedocal] Reminder meeting : Fedora Release Engineering
by mohanboddu＠fedoraproject.org 04 Sep '19

04 Sep '19

Dear all, You are kindly invited to the meeting: Fedora Release Engineering on 2019-09-04 from 16:00:00 to 17:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora Release Engineering weekly meeting Source: https://apps.fedoraproject.org/calendar/meeting/9274/

1 0

[releng] Issue #8501: F31 System-wide Change: Automatic R runtime dependencies
by Elliott Sales de Andrade 03 Sep '19

03 Sep '19

qulogic reported a new issue against the project: `releng` that you are following: `` I'm seeking feedback on https://fedoraproject.org/wiki/Changes/Automatic_R_runtime_dependencies and its impact to releng. As the intent is to add a namespaced Provides and corresponding Requires, this will require rebuilding all R packages _in order_. If the mass rebuild is able to handle this, then there would be nothing else to be done. If the mass rebuild _cannot_ handle it, then I would need a side tag to effect the correct build order. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8501

3 12

[releng] Issue #8723: unorphan powerman
by Dave Love 03 Sep '19

03 Sep '19

loveshack reported a new issue against the project: `releng` that you are following: `` * Name of the package? powerman * FAS username of the new maintainer? loveshack * Any extra information? I maintain the epel branches, but it seems I have to adopt the fedora ones to keep it in. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8723

3 3

[releng] Issue #8734: kill https://koji.fedoraproject.org/koji/buildinfo?buildID=1349084
by Jens Petersen 03 Sep '19

03 Sep '19

petersen reported a new issue against the project: `releng` that you are following: `` * Describe the issue https://koji.fedoraproject.org/koji/buildinfo?buildID=1349084 Can you kill this zombie build job in Koji? * If we cannot complete your request, what is the impact? It will appear forever as running in Koji....: eg https://koji.fedoraproject.org/koji/packageinfo?packageID=14145 * More info I think this happened since it was still building when the f31-ghc sidetag was closed. Sorry about that... `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8734

2 2

[releng] Issue #8717: Please create an epel8-playground branch for libdbi
by Stephen J Smoogen 03 Sep '19

03 Sep '19

smooge reported a new issue against the project: `releng` that you are following: `` * Describe the issue It looks like libdbi was branched for epel8 but not for epel8-playground. This is making the ability to build packages (nagios-plugins etc) in playground not possible * When do you need this? (YYYY/MM/DD) 2019-09-04? * If we cannot complete your request, what is the impact? nagios-plugins and similar programs can not be built in the playground. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8717

2 3

[releng] Issue #8731: selinux-policy versions out of sync between x86_64/ppc64le and aarch64
by Neal Gompa 03 Sep '19

03 Sep '19

ngompa reported a new issue against the project: `releng` that you are following: `` * Describe the issue My `snapd` build failed for 2.41 because the `selinux-policy` package differs on aarch64 from other architectures. Can this please be fixed so this isn't a problem anymore? ``` 37441473 build (epel7-candidate, /rpms/snapd.git:88fb6459ea6131c566623fd0b8b0fbbea5451e9c): open (buildvm-armv7-20.arm.fedoraproject.org) -> FAILED: BuildError: The following noarch package built differently on different architectures: snapd-selinux-2.41-1.el7.noarch.rpm rpmdiff output was: S.5........ POSTIN S.5........ POSTUN removed PREREQ selinux-policy-base >= 3.13.1-252.el7.1 added PREREQ selinux-policy-base >= 3.13.1-229.el7_6.15 0 free 1 open 3 done 1 failed 37441481 buildArch (snapd-2.41-1.el7.src.rpm, aarch64): open (buildvm-aarch64-07.arm.fedoraproject.org) -> closed 0 free 0 open 4 done 1 failed 37441473 build (epel7-candidate, /rpms/snapd.git:88fb6459ea6131c566623fd0b8b0fbbea5451e9c) failed ``` * When do you need this? (YYYY/MM/DD) ASAP. * When is this no longer needed or useful? (YYYY/MM/DD) If AArch64 is dropped as an EPEL7 arch, this doesn't matter anymore. * If we cannot complete your request, what is the impact? I can't build `snapd` for epel7 until this is fixed in some way... `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8731

2 2

[releng] Issue #8637: Remove and deprecate pki module
by Alexander Scheel 03 Sep '19

03 Sep '19

cipherboy reported a new issue against the project: `releng` that you are following: `` * Describe the issue Hi folks. The `pki` module was never officially supported, finished, or really released at all. But it keeps popping up from time to time in `rawhide` and other releases. I just saw it today in `rawhide`. Could I bother someone with magical releng abilities to: - untag `pki` from rawhide, - deprecate both the `10.6` and `10.4` branches on the [pki module](https://src.fedoraproject.org/modules/pki/branches?branchname=maste… - Is it possible to untag the `pki` module in older releases as well (`f29`/`f30`)? The only supported way to acquire Dogtag in Fedora is through the ursine packages. * When do you need this? (YYYY/MM/DD) Whenever is convenient. It'd be nice before F31 gets too far into the release cycle. * When is this no longer needed or useful? (YYYY/MM/DD) Always useful. :-) * If we cannot complete your request, what is the impact? Some people might get confused, but this is unlikely because we've not really seen bug reports from the old, modular packages. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8637

2 3

[releng] Issue #7445: [RFE][PATCH] make $releasever return "rawhide" on Rawhide
by Kamil Páral 03 Sep '19

03 Sep '19

kparal reported a new issue against the project: `releng` that you are following: `` **Background** If we want to have a more reliable and stable Rawhide, we need to make it easier to test and automate. That means eliminating the differences between Rawhide and stable releases and reducing the necessary manual maintenance steps as much as possible. You can read more about related issues in https://pagure.io/releng/issue/7398 and https://pagure.io/copr/copr/issue/267. **Problem** Currently dnf variable `$releasever` returns a number (29) on Rawhide, but all the repos are stored in `rawhide/` directory, not `29/` (as with stable releases). There are good reasons for this, but it has consequences. It forces the official fedora repos to be split between `fedora-repos` and `fedora-repos-rawhide` (because you can't rely on a variable and have to hardcode "rawhide" in the repo path) and breaks copr and any other third-party repos. Basically for all repos, you need to have two separate versions - rawhide and non-rawhide - and always correctly detect and install the right one. I'd like to propose improvements in this area and discuss it with you in this ticket. **Proposed solution 1** Here's a trivial patch for `fedora-release`: ``` diff --git a/fedora-release.spec b/fedora-release.spec index ecca47f..b4b66f2 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,6 +1,7 @@ %define release_name Rawhide %define dist_version 29 %define bug_version rawhide +%define releasever rawhide # All changes need to be submitted as pull requests in pagure # The package can only be built by a very small number of people @@ -19,6 +20,7 @@ Obsoletes: redhat-release Provides: redhat-release Provides: system-release Provides: system-release(%{version}) +Provides: system-release(releasever) = %{releasever} # Kill off the fedora-release-nonproduct package Provides: fedora-release-nonproduct = %{version} ``` This adds provision `system-release(releasever) = rawhide` to the `master` branch of `fedora-release`. Therefore, this provision will only be present for Rawhide version of that package. It uses DNF's [detect_releasever()](https://github.com/rpm-software-management/dnf/blob/65… logic to populate `$releasever` with `rawhide` string (the new provides) instead of `29` (the version of the package). (Note: This is currently broken in DNF due to a [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1568366), but it will be fixed in the next DNF release). The outcome is that all repos can now use `$releasever` in URLs, because it will get replaced by `rawhide` and therefore reach the correct destination. That means you can use the same repo file as in a stable release for COPR or other third-party repo and it will work fine. If the user wants to switch to Branched after branching has happened, they'd run e.g.: ``` sudo dnf distrosync fedora-release\* --releasever=28 ``` **Proposed solution 2** This is a similar approach to the first solution, but creates a `fedora-release-rawhide` subpackage: ``` diff --git a/fedora-release.spec b/fedora-release.spec index ecca47f..74637f1 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,6 +1,7 @@ %define release_name Rawhide %define dist_version 29 %define bug_version rawhide +%define releasever rawhide # All changes need to be submitted as pull requests in pagure # The package can only be built by a very small number of people @@ -33,6 +34,15 @@ BuildArch: noarch %description Fedora release files such as various /etc/ files that define the release. +%package rawhide +Summary: Fedora release files for Rawhide +Provides: system-release(releasever) = %{releasever} +Requires: fedora-release = %{version}-%{release} + +%description rawhide +This identifies the system as Rawhide for the package manager, causing Rawhide +repositories to be used. + %package atomichost Summary: Base package for Fedora Atomic-specific default configurations Provides: system-release-atomichost @@ -315,6 +325,9 @@ glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || : %{_prefix}/lib/systemd/system-preset/99-default-disable.preset +%files rawhide + + %files atomichost %{!?_licensedir:%global license %%doc} %license LICENSE ``` The difference here is that you can install/uninstall `fedora-release-rawhide` any time at will, which marks/unmarks your system to be following the Rawhide stream. The benefit is that you can switch your system from Rawhide to Branched before the branching actually happens, and your system automatically picks up the right repos after branching (which is awesome, especially for our automation needs). The downside is that both `rawhide/` and `29/` repo URLs/paths need to be present and working during the whole life cycle of Rawhide, so that you can switch any time. And this doesn't apply just to official Fedora repos, but ideally also to COPR and other third-party repos. COPR devs [wanted to avoid](https://pagure.io/copr/copr/issue/267) duplicated content or maintaining symlinks, but I guess they could be convinced. But other third-party repos might not follow this approach and the whole concept might be confusing for them (however, a good question is how many of those repos actually work on Rawhide already). So to summarize, this is how you'd switch your system to Rawhide: ``` # use dnf system-upgrade to upgrade to Rawhide sudo dnf install fedora-release-rawhide ``` And switching from Rawhide to Branched: ``` sudo dnf remove fedora-release-rawhide sudo dnf distrosync # if branching already happened ``` Fresh Rawhide installation would receive `fedora-release-rawhide` by default, of course. Overall, this adds more user control at the expense of more infra work. Not sure if this is worth it or not. **Proposed solution 3** For the sake of completeness, I'll mention another approach how to achieve the goal without using new RPM provides. `$releasever` value can be overridden by a file like this: ``` $ cat /etc/dnf/vars/releasever rawhide ``` If this file was owned by `fedora-release-rawhide`, it would be very similar to solution 2 - you can switch the Branched/Rawhide stream any time. The implementation detail here is whether to mark this file as a config file or not, so that it doesn't e.g. stay around even after you remove `fedora-release-rawhide`, or that it doesn't e.g. conflict with an already existing file at that location (if the user wanted to override `$releasever` already for any reason). Solution 2 seems a bit cleaner here because you don't need to bother with corner cases involving config file management. **Possible future steps for Fedora Releng** Once `$releasever` returns `rawhide` on Rawhide, you can (if you wish) drop `fedora-repos-rawhide` and use the same `fedora-repos` package everywhere (ideally also create empty `updates/rawhide` and `updates/testing/rawhide` repos as requested in https://pagure.io/releng/issue/7398). Some repo properties will still probably have different values (like `metadata_expire`), but that can be easily adjusted in the spec file and you can have the same source tarball for all releases, if you wish. This would make the environment even more consistent for users (the repo names would be named the same in all releases). **Known pitfalls** There's one known problem with any of the approaches suggested above, called PackageKit. PackageKit doesn't use DNF to figure out `$releasever`, nor it uses the same logic. Instead, it parses `VERSION_ID` from `/etc/os-release` ([source1](https://github.com/hughsie/PackageKit/blob/2f1c4b820b056efc989be0f…, [source2](https://github.com/hughsie/PackageKit/blob/1e7858b1b67120b377adcb3…). So any changes described here will not apply to PackageKit and it will still return a number (e.g. 29) as `$releasever`. That is something that of course needs to get resolved as well, but before investing time into fixing it, I first wanted to know whether this whole idea gets approved or not. There are several approaches how to fix this in PackageKit, either retrieving `$releasever` from libdnf (when on Fedora), or implementing the same detection logic as in DNF, or perhaps adding `VERSION_CODENAME=Rawhide` to `/etc/os-release` and then special-casing this in PackageKit (however, this would break if solution 2 or 3 is used and the user can switch between streams arbitrarily). However, I'd like to first talk about the concept itself, and only after that start hammering out the implementation details with PackageKit developers. **Discussion** Please tell me what do you think about the proposed changes. Does it make sense? Have I overlooked something important? Are there better ways to solve the aforementioned issues? Thank you. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7445

10 46

[releng] Issue #8588: Unorphan request: libchewing
by 李瑞彬 03 Sep '19

03 Sep '19

cheeselee reported a new issue against the project: `releng` that you are following: `` - Name of the package? libchewing - FAS username of the new maintainer? cheeselee - Any extra information? It's a dependency of fcitx-chewing `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8588

2 2

Fedora Atomic Host Two Week Release Announcement: 29.20190903.0
by noreply＠fedoraproject.org 03 Sep '19

03 Sep '19

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng September 2019