June 2017 - rel-eng - Fedora Mailing-Lists

[releng] Issue #133: Enable Signed Repository Metadata

by Dennis Gilmore

ausil added a new comment to an issue you are following: `` this is actually a dup of #1501 I am in the process of moving that to taiga for grooming and injection into the priority pipeline `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/133

6 years, 10 months

1
0
0 / 0

[releng] Issue #133: Enable Signed Repository Metadata

by Dennis Gilmore

The status of the issue: `Enable Signed Repository Metadata` of project: `releng` has been updated to: Closed as Duplicate by ausil. https://pagure.io/releng/issue/133

6 years, 10 months

1
0
0 / 0

[releng] Issue #6859: libpari23 build stuck in f27-pending

by Paul Howarth

pghmcfc reported a new issue against the project: `releng` that you are following: `` I did an update to libpari23 on Wednesday evening (https://koji.fedoraproject.org/koji/buildinfo?buildID=910315) and it's still stuck in f27-pending so I can't build against it. I noted that there are a few other packages there that have been there even longer: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=427&order=-b... Why is this, and what can I do to get my build tagged into f27 so I can build against it? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6859

6 years, 10 months

3
3
0 / 0

[releng] Issue #6866: running kojira in stg

by Dusty Mabe

dustymabe reported a new issue against the project: `releng` that you are following: `` I'm trying to do a pungi compose in stg. One of my [lorax runroot tasks](https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=90010923) is stuck on [waitrepo (f26-build)](https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=90010929). I was told: ``` 18:01:18 mbonnet | dustymabe: the problem is the f26-build tag has no active repo associated with it: https://koji.stg.fedoraproject.org/koji/taginfo?tagID=364 18:01:50 dustymabe | mbonnet: do you know how to fix that, or know of someone who would know? 18:02:14 mbonnet | dustymabe: kojira is responsible for kicking off repo regens 18:02:24 mbonnet | dustymabe: if it's not running, it would cause this problem 18:02:39 mbonnet | dustymabe: I'd suggest filing a ticket with Fedora rel-eng ``` `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6866

6 years, 10 months

2
2
0 / 0

[releng] Issue #6786: Kojira cannot handle number of targets it used to handle month ago.

by Jan Kaluža

jkaluza reported a new issue against the project: `releng` that you are following: `` Hi, let me first say something about the current situation and steps we have taken to mitigate it: 1) MBS used to create 2 targets per module build (one classic build target and one -repo target to have the repository with the final tag available in order to allow Copr or taskotron or local builds to get the built RPMs without the need to download all of them from koji directly). This has been done since the very first date of MBS deployment and over the time, the number of targets have grown to 670. In the same time, kojira started having problems generating the repositories and after discussion on #fedora-releng, we have been advised to stop generating so many tags. 2) On Thursday May 4th, we have removed 504 old targets (https://pagure.io/releng/issue/6774) in a hope things will get to normal and we will have a time to fix the MBS to not require any target when building module. I want to note here that we left just 170 targets in Koji - this is number of targets it used to normally handle in the previous months. We did not get to 670 targets over the night and there were whole month in which kojira worked just fine with more than 170 targets. Even with 170 targets left, kojira had the same issues regenerating the repositories. 3) On Thursday May 11, we have decided to remove all modular targets (not only the old ones) (https://pagure.io/releng/issue/6784). That day, we started with no modular target and it used to work well for some time, but after we hit around 40 modular targets, kojira started to be slow again and tasks time-outed on waitrepo. Note that this decision has broken modular builds in Copr and signing of modules in robosignatory which is another complication in Fedora 26 Modular release. 4) On Friday May 12, we have deployed new MBS which creates only single target per module build and which deletes the targets right after the module build finishes, we are now on 22 modular targets and this number will go down to more or less 10 targets in any time (because there are still old builds in progress which created 2 targets instead of 1). After an hour after the removal of targets to get to 22 modular targets, we still see 7 tasks waiting on waitrepo. Now the question. Why Kojira cannot handle the load it used to handle one month ago? Why it cannot handle even the much lower load currently? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6786

6 years, 10 months

5
7
0 / 0

[releng] Issue #6696 `Repo out of f26-modularity tag`

by Adam Samalik

asamalik reported a new issue against the project: `releng` that you are following: `` The modularity team needs to be able to build modules using local module-build-service (MBS). After some discussion on #fedora-modularity with @jkaluza and @psabata it appears I need `f26-modularity` to appear at [kojipkgs.fedoraproject.org/repos](https://kojipkgs.fedoraproject.org/repos/) so MBS can use it as a buildroot for modules. I probably want you to run `koji add-target f26-modularity-repo f26-modularity f26-modularity`. (@jkaluza promised it's the right command) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6696

6 years, 10 months

4
13
0 / 0

[releng] Issue #6864: Is 'rawhide' tag in koji in any use now?

by Tomas Kopecek

tkopecek reported a new issue against the project: `releng` that you are following: `` https://pagure.io/koji/issue/485 hit the issue of waiting on `rawhide` tag which is not part of `f27-build` inheritance, but only `rawhide-repo-holder` target. Is it used for something (or in different part of lifecycle) or does it make sense to remove it? Pinging also @rjones (original reporter). `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6864

6 years, 10 months

2
2
0 / 0

Fedora Atomic Host Two Week Release Announcement

by noreply＠fedoraproject.org

A new Fedora Atomic Host update is available via an OSTree commit: Commit: f136ff5370c0f77d9c1f4fd3ecb8e1815650d8aaf834e41a5e995a13494407e9 Version: 25.148 Existing systems can be upgraded in place via e.g. `atomic host upgrade` or `atomic host deploy`. Corresponding image media for new installations can be downloaded from: https://getfedora.org/en/atomic/download/ Respective signed CHECKSUM files can be found here: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-2017... https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-2017... For direct download, the "latest" targets are always available here: https://getfedora.org/atomic_iso_latest https://getfedora.org/atomic_qcow2_latest https://getfedora.org/atomic_raw_latest https://getfedora.org/atomic_vagrant_libvirt_latest https://getfedora.org/atomic_vagrant_virtualbox_latest Filename fetching URLs are available here: https://getfedora.org/atomic_iso_latest_filename https://getfedora.org/atomic_qcow2_latest_filename https://getfedora.org/atomic_raw_latest_filename https://getfedora.org/atomic_vagrant_libvirt_latest_filename https://getfedora.org/atomic_vagrant_virtualbox_latest_filename For more information about the latest targets, please reference the Fedora Cloud Wiki space. https://fedoraproject.org/wiki/Cloud#Quick_Links Do note that it can take some of the mirrors up to 12 hours to "check-in" at their own discretion. Thank you, Fedora Release Engineering

6 years, 10 months

2
1
0 / 0

[releng] Issue #6822: using include statements in pungi-fedora

by Dusty Mabe

dustymabe reported a new issue against the project: `releng` that you are following: `` My [message](https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedo... to the mailing list didn't get a response so moving to a pagure issue and tagging with meeting keyword. I've been told recently that we can use include statements within pungi to include variables/definitions in other files into our current configuration file we are working on. Can we start to use this model for our pungi-fedora repo? One example is that the fedora-atomic.conf file has a bunch of configuration at the top of it that is very cryptic to know what's relevant to atomic host image/iso creation and what is not. It would be much better if, for a particular branch, we can have a file that has most common definitions in it for all pungi configs for that branch. Then we can make the individual pungi configs much more lightweight and less confusing. If this is acceptable we can start with the Rawhide branch and when we branch for future releases this will propagate. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6822

6 years, 10 months

3
5
0 / 0

[releng] Issue #6847: Splitting fedora-repos into edition-specific variants (F27 timeframe)

by Matthew Miller

mattdm reported a new issue against the project: `releng` that you are following: `` I'd like the different editions to hit the mirrors differently, so I can get a better sense of the usage of each. The DNF team proposes [this solution](https://bugzilla.redhat.com/show_bug.cgi?id=1156007#c18): > Dear Matthew, I would like to explain the solution little bit in more > detail. We propose following: > > The package fedora-repos will be splitted into 3 packages > (fedora-server-repos, fedora-workstations-repos, and fedora-cloud-repos). > Each of them will have /etc/yum.repos.d/fedora.repo with modification in > metalink, where you can use something like for fedora-workstations-repos: > > metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug- > $releasever&arch=$basearch&releasevariant=workstation > > or for fedora-server-repos: > > metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug- > $releasever&arch=$basearch&releasevariant=server > > That means that there will be no additional variable or requirement from dnf > site, but only infrastructure solution. And this is exactly what you need, > because your request is Fedora specific (cannot be applied for RHEL), > therefore it has to be solved by Fedora delivery approach of distro variant. > Hope that it helps. What do you think? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6847

6 years, 10 months

4
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng June 2017