[releng] Issue #8121: Take ownership of arm-none-eabi-gdb
by Richard Shaw
hobbes1069 reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
arm-none-eabi-gdb
* FAS username of the new maintainer?
hobbes1069
* Any extra information?
I have filed BZ#1589251 since one of the headers conflicts with the install of gdb but the package is apparently orphaned.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8121
4 years, 10 months
[releng] Issue #8102: unretire python-ttystatus
by Michel Alexandre Salim
salimma reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
When updating python-ttystatus I accidentally recalled the wrong command from the history and invoked 'fedpkg retire' instead. While I reverted and pushed a new commit immediately, then performed a build, it turns out the package is still retired and the new build went to trash:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1181348
I noticed the expiration when building a dependency that requires ttystatus (cmdtest).
Since this package is actually active in other branch, can it be unretired without going through are-review?
* When do you need this? (YYYY/MM/DD)
2019/02/10
* When is this no longer needed or useful? (YYYY/MM/DD)
2019/02/19
* If we cannot complete your request, what is the impact?
Blocking the rebuilding of some packages that are FTBFS including cmdtest - I want to get these done before F30 is branched
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8102
4 years, 10 months
[releng] Issue #8105: Allow owners / maintainers and provenpackagers to
untag (their) builds from Rawhide
by Björn Esser
besser82 reported a new issue against the project: `releng` that you are following:
``
In the last time there have been at least two builds, that broke the Rawhide buildroot entirely. The usual way to fix this is to untag the problematic `NEVR` of that package and to rebuild the package after fixing it.
Before autosign was fully implemented, the package owner / maintainer and provenpackagers could untag builds themselves from the `fXX` tag. Today there is always intervention from someone having Koji-admin powers involved, which may result in a broken Rawhide buildroot for a longer period.
That should not be hard to implement, as builds can still be tagged and untagged from the `fXX-pending` tags by the package owner / maintainers and provenpackagers.
CC: @tmraz and @cverna
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8105
4 years, 10 months
[releng] Issue #8084: Opt-out from branching for rust packages
by Igor Gnatenko
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
Hello release engineering folks,
The Rust SIG never updates any crates in released Fedora's. Is it possible to opt-out from branching so that users won't get outdated crates?
I can provide list of packages, but roughly that would be whatever matches `rust-*` with a few exceptions.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8084
4 years, 10 months
[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
[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