rel-eng November 2018

rel-eng@lists.fedoraproject.org

7 participants
240 discussions

[releng] Issue #7671: Builders does not respect ExclusiveArch
by Vít Ondruch 09 Jun '19

09 Jun '19

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

5 13

[releng] Issue #7523: rubygem-connection_pool mess
by Vít Ondruch 04 Jun '19

04 Jun '19

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

3 8

[releng] PR #7881: Add a script to send reminders to FTBFs bugzillas
by Miro Hrončok 03 Jun '19

03 Jun '19

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

5 24

[releng] Issue #7763: define and implement retention policy for nightly composes
by Dan Horák 29 May '19

29 May '19

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 7

[releng] Issue #7802: Several EPEL7 package conflicts with RHEL/CentOS 7.5
by Eli Young 29 May '19

29 May '19

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

5 7

[releng] Issue #7738: fedpkg build - Connection aborted.
by Vít Ondruch 21 May '19

21 May '19

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

10 16

[releng] Issue #7215: older drpms not synced
by Kevin Fenzi 21 May '19

21 May '19

kevin reported a new issue against the project: `releng` that you are following: `` As noted in this post: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… it seems we are only syncing out the drpms made in that specific compose. We should keep a (ideally configurable) amount of older ones around. I think for rawhide we were keeping 2 weeks, we could start with that. as it is now unless someone updates on the day an update is pushed they won't get the advantage of the drpm. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7215

3 3

[releng] Issue #7548: Fedora 29 Change: NSS load p11-kit modules by default
by Daiki Ueno 21 May '19

21 May '19

ueno reported a new issue against the project: `releng` that you are following: `` Hello, Could you review your impact with https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules ? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7548

4 3

[releng] Issue #7907: Fedora 30 Toolchain Rebase: glibc 2.29, gcc 9.0
by Carlos O'Donell 09 May '19

09 May '19

codonell reported a new issue against the project: `releng` that you are following: `` * Describe the issue All Fedora releases must be released using a released and supported version of the core toolchain involving glibc, gcc, and binutils. The Fedora toolchain team is responsible for ensuring that Fedora Rawhide stabilizes static linking, code generation, and library ABI, before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by binutils, gcc, glibc or other components, the Fedora toolcahin team will ensure coordination with release engineering such that a mass rebuild uses the released version of all components and fix any last minute ABI or code-generation changes. * When do you need this? (2019/01/30) We need a mass rebuild. Change page for review: https://fedoraproject.org/wiki/Changes/GLIBC229 Owner: Carlos O'Donell carlos(a)redhat.com glibc mass rebuild request: This request. Change page for review: https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition Owner: Carlos O'Donell carlos(a)redhat.com glibc mass rebuild request: ppc64le transition to 128-bit IEEE long double. GCC will file a system-wide change request for GCC 9 transition also in December. Binutils will remain as 2.31.1 and will not change (Nick Clifton's notes). * If we cannot complete your request, what is the impact? I we cannot do a mass rebuild then we should not transition to glibc 2.29 or gcc 9, but we might still be able to transition via targeted mass rebuilds. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7907

3 4

[releng] Issue #7921: setgid bit on Fedora 29 directories
by Ian Wienand 09 May '19

09 May '19

iwienand reported a new issue against the project: `releng` that you are following: `` Hello, We rsync a Fedora mirror to a local AFS volume. When I added the F29 directories we started getting ``` receiving incremental file list rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/.": Permission denied (13) rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Everything": Permission denied (13) rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Everything/x86_64": Permission denied (13) rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Modular": Permission denied (13) rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Modular ``` Quite bizarre and unhelpful; turns out on stracing the failing call is ``` 3213 chmod(".", 02755 <unfinished ...> ``` On AFS, you need administrator permissions to setgid (02) which the mirror user doesn't have. I tried on several different rsync mirrors and they all do the same, so I'm assuming this comes from the master sync. I can avoid this problem by dropping "-p" from our rsync command; however we haven't (and don't) need this for any of the other fedora directories. Could someone check if this has inadvertently been applied to the F29 directories somehow? Thanks `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7921

5 18

← Newer
1
2
3
4
5
6
7
...
24
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng November 2018