June 2019 - rel-eng - Fedora Mailing-Lists

[releng] Issue #8433: Request to take over the orphaned package 'gsl'

by Gerd Pokorra

gerd reported a new issue against the project: `releng` that you are following: `` * Describe the issue ** I (FAS: gerd) would like to maintain the orphaned package 'gsl'. I am working at an University and so I am interested in that package. I do the packages of perl6 in Fedora. A successful scratch build of the current release 2.5 is at: https://koji.fedoraproject.org/koji/taskinfo?taskID=35480275 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8433

4 years, 10 months

2
2
0 / 0

[releng] Issue #8434: 20190611: Release Fedora 29 Atomic Host

by Michael Nguyen

mnguyen reported a new issue against the project: `releng` that you are following: `` You should be able to do it with this command: > python push-two-week-atomic.py -k fedora-29 -r 29 --pungi-compose-id Fedora-29-updates-20190611.0 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8434

4 years, 10 months

2
2
0 / 0

Fedora Atomic Host Two Week Release Announcement: 29.20190611.0

by noreply＠fedoraproject.org

4 years, 10 months

1
0
0 / 0

[releng] Issue #8430: Side tag: F31 RPM 4.15

by Igor Gnatenko

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` * For which release? f31 * Name of the side tag? (Generally fxx-pkg) f31-rpm * Number of builds that are expected in the side tag? 50ish * How long do you need the side tag? less than a day * Any extra information? I'm going to handle it myself. Apparently RPM 4.15 broke everything, so I need side tag after all. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8430

4 years, 10 months

1
5
0 / 0

[releng] Issue #7931: spam-o-matic (depcheck) is wildly, uselessly wrong

by Adam Williamson

adamwill reported a new issue against the project: `releng` that you are following: `` * Describe the issue The output of spam-o-matic (`depcheck` in the compose logs) is just utterly wrong for recent Rawhide composes. e.g. this, from the most recent Rawhide compose: [calamares] calamares-3.1.8-10.fc29.i686 requires hicolor-icon-theme calamares-3.1.8-10.fc29.i686 requires dnf calamares-3.1.8-10.fc29.i686 requires console-setup calamares-3.1.8-10.fc29.i686 requires system-release [calibre] calibre-3.29.0-2.fc30.i686 requires python2-cssutils calibre-3.29.0-2.fc30.i686 requires python2-dateutil calibre-3.29.0-2.fc30.i686 requires python2-dns calibre-3.29.0-2.fc30.i686 requires python2-enum34 calibre-3.29.0-2.fc30.i686 requires python2-feedparser calibre-3.29.0-2.fc30.i686 requires python2-beautifulsoup calibre-3.29.0-2.fc30.i686 requires python2-mechanize calibre-3.29.0-2.fc30.i686 requires python2-pygments calibre-3.29.0-2.fc30.i686 requires python2-odfpy All those deps actually *are* in the tree, they should not be shown as broken. We've known the output has been kinda unreliable for a while, but IIRC this related only to soft deps and/or modules. Aside from that it was still more or less correct for x86_64, so it was usable for spotting real broken deps. But it's now just stuffed with completely incorrect info and unusable. * When do you need this? (YYYY/MM/DD) It's not utterly critical, but I was hoping to find broken deps introduced by the Python 2 subpackage removal. Without any kind of usable dep check this is hard to do. * When is this no longer needed or useful? (YYYY/MM/DD) * If we cannot complete your request, what is the impact? It'll be harder to find and fix broken deps in Rawhide. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931

4 years, 10 months

3
6
0 / 0

[releng] Issue #8427: Container Release 20190610

by Clement Verna

cverna reported a new issue against the project: `releng` that you are following: `` * Describe the issue We have had successful composes for Fedora 30 and 31 this weekend we should update our images on the registry. I have done the Docker Hub part. * When do you need this? (YYYY/MM/DD) * When is this no longer needed or useful? (YYYY/MM/DD) * If we cannot complete your request, what is the impact? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8427

4 years, 10 months

2
2
0 / 0

[releng] Issue #8074: perl:5.26:20181205105946 module is in both updates and testing repositories

by Petr Pisar

ppisar reported a new issue against the project: `releng` that you are following: `` ~~~~ # dnf module info perl:5.26 | grep -E '^(Version|Repo)' Version : 20180417112647 Repo : fedora-modular Version : 20181205105946 Repo : updates-modular Version : 20181205105946 Repo : updates-testing-modular ~~~~ I would expect that the module build will be moved from testing to updates. Not copied. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8074

4 years, 10 months

1
2
0 / 0

[releng] Issue #7671: Builders does not respect ExclusiveArch

by Vít Ondruch

vondruch reported a new issue against the project: `releng` that you are following: `` A while ago, there was a change in packaging guidelines: https://pagure.io/packaging-committee/issue/751 And the ticket started with a claim: > A while back, Koji was fixed to actually pay attention to ExcludeArch: and ExclusiveArch: when choosing the host to build a noarch package. I don't think that it works, testing with either this: ~~~ diff --git a/rubygem-mongo.spec b/rubygem-mongo.spec index 1d436d7..82a9e00 100644 --- a/rubygem-mongo.spec +++ b/rubygem-mongo.spec @@ -26,6 +26,9 @@ BuildRequires: %{_bindir}/mongod BuildRequires: rubygem(bson) >= 4.3.0 BuildRequires: rubygem(rspec) BuildArch: noarch +# MongoDB serverved does not support all architectures. Use x86_64 for build +# to be sure Koji build is always successful. +ExclusiveArch: x86_64 noarch %description A Ruby driver for MongoDB. ~~~ https://koji.fedoraproject.org/koji/taskinfo?taskID=28734500 or ~~~ diff --git a/rubygem-mongo.spec b/rubygem-mongo.spec index 1d436d7..82a9e00 100644 --- a/rubygem-mongo.spec +++ b/rubygem-mongo.spec @@ -26,6 +26,9 @@ BuildRequires: %{_bindir}/mongod BuildRequires: rubygem(bson) >= 4.3.0 BuildRequires: rubygem(rspec) BuildArch: noarch +# MongoDB serverved does not support all architectures. Use x86_64 for build +# to be sure Koji build is always successful. +ExclusiveArch: x86_64 %description A Ruby driver for MongoDB. ~~~ https://koji.fedoraproject.org/koji/taskinfo?taskID=28734626 Both builds were done on i686 builders while only x86_64 builders should be used. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7671

4 years, 10 months

5
13
0 / 0

[releng] Issue #8404: Permissions to unblock packages are not working

by Igor Gnatenko

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` ``` ⋊> ~ koji unblock-pkg f31 gnome-games 16:05:47 2019-06-01 16:06:00,129 [ERROR] koji: ActionNotAllowed: policy violation (package_list) ``` xref: https://pagure.io/releng/issue/8398 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8404

4 years, 10 months

3
10
0 / 0

[releng] Issue #8417: Grant Koji admin permission to mizdebsk

by Mikolaj Izdebski

mizdebsk reported a new issue against the project: `releng` that you are following: `` I am planning to work on upgrading Koji builders. In order not to cause user-visible outage, the upgrade process is typically done in the following (or similar) way: 1. disable half of builders (with `koji disable-host` command) so that they stop accepting new tasks 2. wait for disabled builders to complete their tasks 3. destroy and reinstall disabled builders 4. re-enable reinstalled builders (`koji enable-host` command) 5. repeat steps 1 through 4 for the other half of builders Steps 1 and 4 enabling and disabling require admin permission. To see that @kevin (who usually does the reinstalls) indeed disables and then re-enables hosts, you can check Koji history: `koji list-history -s host_config --all` Because of the above I think it would be beneficial to grant me admin permission in Koji. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8417

4 years, 10 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng June 2019