[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
[releng] Issue #7523: rubygem-connection_pool mess
by Vít Ondruch
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
4 years, 10 months
[releng] Issue #7763: define and implement retention policy for nightly
composes
by Dan Horák
sharkcz reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Right now we have only last 14 days of the nightly composes. Which makes it impossible to compare current compose with an old one to see what changed (mainly functionally). The polocy could be time based (like keep 1 compose per week for 4 weeks preceding the 14 days, then keep 1 per month, until previous GA). Or it can be based on the openqa testing and keep composes "nominated for further testing". Or something else.
One of the reason for this request is https://bugzilla.redhat.com/show_bug.cgi?id=1623547 where I'm almost sure I had a F-29 nightly compose behaving sanely on s390x in the past, but have nothing I could compare with the current state.
* When do you need this? (YYYY/MM/DD)
soon
* When is this no longer needed or useful? (YYYY/MM/DD)
never
* If we cannot complete your request, what is the impact?
Difficult to find out what changed (functionally) in the composes as the previous compose is the GA compose of the last release. AFAIK it's almost impossible to recreate an old compose from a given date on demand.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7763
4 years, 11 months
[releng] Issue #7802: Several EPEL7 package conflicts with RHEL/CentOS 7.5
by Eli Young
elyscape reported a new issue against the project: `releng` that you are following:
``
#### Describe the issue
The releases of RHEL and CentOS 7.5 (and likely earlier versions) brought with them new packages that were previously provided by EPEL7. Some of these are still present in EPEL, potentially causing conflicts. Particularly problematic are various packages that are provided in EPEL as python2-* and provided in upstream as python-*. While fully-overlapping names are suboptimal, these partially-overlapping names that provide the same actual package leads to issues like [certbot #6314][certbot] and [RHBZ #1578071][bugzilla].
I have attached 4 files containing lists of problematic packages:
filename|description|impact if unresolved
-|-|-
base-and-updates-full.txt|EPEL7 packages also in upstream base or updates|moderate
base-and-updates-partial.txt|EPEL7 packages also in upstream base or updates as python-*|significant
extras-full.txt|EPEL7 packages also in upstream extras|moderate
extras-partial.txt|EPEL78 packages also in upstream extras as python-*|significant
#### When do you need this? (YYYY/MM/DD)
No specific date, but sooner is better.
#### When is this no longer needed or useful? (YYYY/MM/DD)
N/A
#### If we cannot complete your request, what is the impact?
EPEL-provided packages with full name overlap may potentially override upstream packages. EPEL-provided packages with partial name overlap may cause issues like [certbot #6314][certbot] and [RHBZ #1578071][bugzilla].
<!!image>
<!!image>
<!!image>
<!!image>
[certbot]: https://github.com/certbot/certbot/issues/6314
[bugzilla]: https://bugzilla.redhat.com/show_bug.cgi?id=1578071
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7802
4 years, 11 months
[releng] Issue #7738: fedpkg build - Connection aborted.
by Vít Ondruch
vondruch reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
The fedpkg connection with server fails during build almost every time:
~~~
$ fedpkg scratch-build --srpm
/usr/lib/python3.7/site-packages/fedora/client/bodhi.py:48: DeprecationWarning: fedora.client.bodhi has been deprecated. Please use bodhi.client.bindings instead.
DeprecationWarning)
/usr/lib/python3.7/site-packages/fedpkg/__init__.py:235: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5
runtime_os, runtime_version, _ = platform.linux_distribution()
Zapsáno: /home/vondruch/fedora-scm/own/ruby/ruby-2.5.1-99.fc30.src.rpm
/usr/lib/python3.7/site-packages/koji/__init__.py:1704: DeprecationWarning: This method will be removed in future versions. Use 'parser.read_file()' instead.
config.readfp(f)
[====================================] 100% 00:00:03 10.90 MiB 3.16 MiB/sec
Building ruby-2.5.1-99.fc30.src.rpm for rawhide
Created task: 29377062
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=29377062
Watching tasks (this may be safely interrupted)...
Could not execute scratch_build: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
~~~
This happens already for some time and it is quite annoying.
~~~
$ rpm -q fedpkg
fedpkg-1.35-1.fc30.noarch
~~~
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7738
4 years, 11 months
[releng] Issue #8012: Self-contained change proposal: krb5 crypto
modernization
by Robbie Harwood
rharwood reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Mandatory check with rel-eng is required for Fedora 30 change proposal [krb5 crypto modernization](https://fedoraproject.org/wiki/Changes/krb5_crypto_moderni.... I don't expect any impact, but that's why we do these checks.
* When do you need this? (YYYY/MM/DD)
Change submission deadline is 2019-01-29 for self-contained changes
* When is this no longer needed or useful? (YYYY/MM/DD)
Beta freeze is 2019-03-05, but I think it really should be done before the submission deadline of 2019-01-29.
* If we cannot complete your request, what is the impact?
I'm not actually sure and policy doesn't really say. I think it goes forward anyway without your input? Maybe it doesn't get accepted? Hopefully this isn't an issue.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012
4 years, 11 months
[releng] Issue #7994: Inform module maintainers when their module/stream is
going to EOL
by Mohan Boddu
mohanboddu reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Currently there is no way right now to intimate the module maintainers when their module/stream is going EOL. It would good if we can send some notifications about it prior to their EOL.
This requires parsing through all modules/streams in PDC to get their EOL dates and if its getting EOL'd in a week (or something more, we have to decide on this duration) , then find the maintainer of that module in dist-git and send them an email.
* When do you need this? (YYYY/MM/DD)
ASAP
* When is this no longer needed or useful? (YYYY/MM/DD)
Its always useful
* If we cannot complete your request, what is the impact?
Every time maintainers will have issues pushing to dist-git if their module/stream is EOL'd.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7994
4 years, 11 months