On Mon, May 2, 2022 at 1:22 AM Alex Iribarren <alex.m.lists3@xxxxxxxxx> wrote:
Hi,
On 4/29/22 21:17, Stephen John Smoogen wrote:
>
>
> On Fri, 29 Apr 2022 at 14:28, Germano Massullo
> <germano.massullo@xxxxxxxxx <mailto:germano.massullo@xxxxxxxxx>> wrote:
>
> Recent CentOS Stream Qt update broke some EPEL packages like keepassxc
> that needed a rebuild against the new Qt version.
> Can we talk about a way to prevent this from happening again?
>
>
> This is the current situation of events for dealing with CentOS Stream
> and EPEL
> 0. Packages get put into stream at the rate of internal developers doing
> things and getting stuff put into GIT. There is no communication to know
> when this will happen so knowing what packages to build before this
> drops isn't happening.
> 1. The QT packages in Stream have taken a week to be fixed due to
> various issues found in them. [Mostly they were built in the wrong order
> and linked against each other poorly.]
So how could we stop this from happening in the future? The
50_test_comps[0] test caught some of the problems, but not all because
not all qt5 packages seem to be listed in a comps group. `dnf install
qt5-*` is unlikely to work, though I haven't tried.
How could we test that all qt5 packages have been correctly rebuilt? If
that's done right, the following steps will be a lot less painful.
Cheers,
Alex
When CentOS Stream 8 flips from "after" rhel8 to "before" rhel8, that should fix this problem.
Right now, the CentOS Stream team just get a list of packages. No order at all.
They try their best, but sometimes things get built out of order.
Although they've fixed all the out of order problems, there is currently a python27 module problem in CentOS Stream 8.
It's been broken since February, but nobody noticed due to a bug/feature in dnf.
The EPEL build system notices because it pulls in ONLY the latest module. Thus anyone trying to build with python2 (qt5-qtwebengine) get's failure.
> 2. This means rebuilding packages have to wait until that is fixed as
> some people found when they jumped on it sooner. Either they could not
> rebuild anything or when they rebuilt it they needed to do it again when
> the updated packages with the right library links came out.
> 3. Packages in EPEL are maintained by a lot of people who may not know
> that centos-stream have updated rapidly and do not have the spare
> capacity to update sooner than the weekend spare time they had allotted
> to do it.
>
> What are ways that this could be improved?
>
> --
> Stephen J Smoogen.
> Let us be kind to one another, for most of us are fighting a hard
> battle. -- Ian MacClaren
[0]
https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/50_test_comps.sh
_______________________________________________
CentOS-devel mailing list
CentOS-devel@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos-devel
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
