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
rdieter reported a new issue against the project: `releng` that you are following:
``
Please create a f28-kde koji side target. It will be invaluable to work on batched builds (Qt5, in particular) to avoid and minimize breaking rawhide depenedencies in the meantime.
Thanks.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7320
rdieter reported a new issue against the project: `releng` that you are following:
``
Will begin work on a large batch of interdependant builds, please (re)enable epel7-kde koji target,
koji add-target epel7-kde epel7-kde
thanks.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7552
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
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
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
vondruch reported a new issue against the project: `releng` that you are following:
``
There is package rubygem-connection_pool, where although the review was finished \[[1]\], the package was never imported neither built. Later, somebody wanted to use rubygem-connection_pool, so there was other review \[[2]\]. This was approved (while unnoticed, there is rubygem-connection_pool already in Fedora) and repository rubygem-connection-pool was requested (please note the dash instead of underscore in the repository name). From there, there are coming builds of rubygem-connection_pool here \[[3]\]. Somebody later noticed and retired the rubygem-connection-pool package \[[4]\], but really, I am not sure this was the best possible action. There are several concerns:
1. It is not obvious what happened and where the package is coming from. It is surprising, that the repo request was approved, although it did not match the review.
2. The package is escaping mass rebuilds. Actually I am surprised this kind of repositories is not detected/reported after rebuild.
3. It is not obvious who is maintaining the package.
For (1) and (2), I hope you can check your tooling and avoid these situations in the future.
For (3) neither one of the current maintainers is really active. I haven't hear about @anujmore for past 4 years. I've heard about @axilleas, but I believe he is busy with other stuff. @ilgrad might still be interested in this package. I can also take the package over, since it is dependency of Ruby on Rails.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=967334
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1267328
[3]: https://koji.fedoraproject.org/koji/packageinfo?packageID=16736
[4]: https://src.fedoraproject.org/rpms/rubygem-connection-pool/commits/master
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7523
churchyard opened a new pull-request against the project: `releng` that you are following:
``
Add a script to send reminders to FTBFs bugzillas
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/7881