rel-eng May 2018

rel-eng@lists.fedoraproject.org

10 participants
251 discussions

[pungi-fedora] PR #598: Fedora Minimal Compose for OpenQA testing
by Mohan Boddu 09 Mar '21

09 Mar '21

mohanboddu opened a new pull-request against the project: `pungi-fedora` that you are following: `` Fedora Minimal Compose for OpenQA testing `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/598

5 20

[pungi-fedora] PR #438: Add post-compose rsync script
by Kellin 08 Mar '21

08 Mar '21

kellin opened a new pull-request against the project: `pungi-fedora` that you are following: `` Add post-compose rsync script `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/438

3 2

[pungi-fedora] PR #502: WIP: Add fedora-atomic-ws config
by Colin Walters 08 Mar '21

08 Mar '21

walters opened a new pull-request against the project: `pungi-fedora` that you are following: `` WIP: Add fedora-atomic-ws config `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/502

6 20

[pungi-fedora] Issue #501: Mark compiler-rt as multilib
by Tom Stellard 26 Jan '21

26 Jan '21

tstellar reported a new issue against the project: `pungi-fedora` that you are following: `` The i686 packages for compiler-rt are no longer available in the x86_64 repositories starting with Fedora 27. Could you mark this package as multilb. See https://bugzilla.redhat.com/show_bug.cgi?id=1513286 `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/issue/501

2 3

[pungi-fedora] Issue #426: Convert file sync from one-liner to durable shell script
by Kellin 15 May '20

15 May '20

kellin reported a new issue against the project: `pungi-fedora` that you are following: `` The way we rsync composes today is a one-liner bash script that is not very durable and requires that a release engineer babysit it through the entire four hour rsync process. I am going to make this more durable, however, it will also slightly change our process behind the scenes. Today if a process works or is DOOMED after a full run it is assigned an RC release number. (EG: 1.1, 1.2, 1.3, etc). If the compose fails quickly from something such as a failure to have signed packages then it will not be assigned a release candidate. Per @mohanboddu there is not a durable way to identify the all of the different ways the special case DOOMed composes occur so they will be assigned an RC number after the automation is deployed. The only visible change will be extra gaps in the RC composes in /pub/alt/stage that represent these extra numbers being inserted to the sequence. @mohanboddu is fine with this change; does anyone else have objections? @ausil , @kevin , @puiterwijk please let me know. The initial script PR will be coming within the next two business days. `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/issue/426

4 7

[releng] Issue #7477: Changes for release SOP before f29
by Kevin Fenzi 10 Sep '19

10 Sep '19

kevin reported a new issue against the project: `releng` that you are following: `` This ticket will collect any changes we need to make to the release SOP that were missed in f28 but we should add in f29. We should collect them here and then close this once all of them are merged into the SOP. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7477

5 9

[releng] Issue #7428: Anaconda & bodhi update improvements
by Martin Kolman 10 Sep '19

10 Sep '19

m4rtink reported a new issue against the project: `releng` that you are following: `` I would like to start by saying that the Bodhi update process works just fine for Anaconda during freeze periods - we just build a new version of Anaconda or any of it's related packages with all the blocker a FE fixes, put it to an update and basically hand it over to Fedora QA, who handle the rest (make sure it ends up in the appropriate compose, etc.). Where I think the Bodhi process does not really work are the periods when Fedora is not in freeze (so after Bodhi activation and before Beta freeze and after Beta freeze and before Final freeze). As regular users are rather unlikely to test Installer updates (with the whole "you need to reinstall your machine to test it" thing) so the Anaconda updates generally sit there for the full 7 days (+any Bodhi push overhead) and are then pushed to stable possibly without any testing. Also any changes to the update, such as adding a fixed build or adding additional packages reset karma and (IIRC) also the waiting period. Given that the no-freeze period are generally about two weeks, it's actually pretty challenging to get any regular Anaconda updated to stable at all. This can then result in users getting 6+ weeks (4 weeks freeze, 1-2 weeks in Bodhi) of changes at once, possibly right before the next freeze. Or the update might not even make it in before the next freeze has started due to all the delays, complicating maters further. I'm not sure if there is a simple solution for this (other than "go bother Adam/Fedora QA for each update") but it would be ideal if each Anaconda update would both: - get some actual testing (other than our unit tests/CI) - would reach composes much sooner, making it possible to do more smaller releases outside of the freeze period, making the discovery and fixing of release blocking issues more likely before they can wreak havoc during the freeze period Maybe some more automated CI & some notification mechanism for Fedora QA that fires when new updates for Anaconda shows up ? Ideally with some commitment to tests it & push to stable if it looks fine. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7428

3 4

[releng] Issue #7337: Emit fedmsg when candidate composes are synced to stage
by Adam Williamson 10 Sep '19

10 Sep '19

adamwill reported a new issue against the project: `releng` that you are following: `` Candidate composes (as opposed to nightly composes) for Branched are synced to https://dl.fedoraproject.org/pub/alt/stage/ after they're built. This is supposed to be the preferred download location for them (rather than kojipkgs). However, there is currently no fedmsg emitted when this happens, so automated systems have no good way to know when a candidate compose has been synced and is available from stage/. It would be good if there was a fedmsg for this (probably a `compose` one). @puiterwijk `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7337

3 4

[releng] Issue #7403: Consider no longer producing the Workstation repo tree in composes
by Neal Gompa 05 Sep '19

05 Sep '19

ngompa reported a new issue against the project: `releng` that you are following: `` Recently, we stopped producing [the Cloud repo tree](https://pagure.io/pungi-fedora/pull-request/577) as part of composes to speed things up and reduce the number of useless deliverables. I suggest we also stop producing the Workstation repo tree for composes, as we don't use it or need it. Today, for the Workstation Edition, we produce two main artifacts: the live ISO and the branded netinstall ISO. As far as I'm aware, the branded net install ISO differs from the main Fedora netinstall ISO only in branding and defaults through the anaconda productimg embedded within. It uses the `Everything` repo tree like the regular netinstall ISO, and is functionally similar to the regular netinstall ISO. Since the Workstation netinstall doesn't need it, and we don't produce a Workstation install DVD ISO, I do not see a reason to keep producing the Workstation repo tree. Not producing the tree would help reduce the compose time significantly, too. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403

12 46

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng May 2018