[EPEL-devel] Re: [CentOS-devel] Re: Qt update and packages rebuild
On Mon, May 2, 2022 at 1:22 AM Alex Iribarren wrote: > Hi, > > On 4/29/22 21:17, Stephen John Smoogen wrote: > > > > > > On Fri, 29 Apr 2022 at 14:28, Germano Massullo > > mailto:germano.massu...@gmail.com>> 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-de...@centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Qt update and packages rebuild
On Mon, 2 May 2022 at 04:22, Alex Iribarren wrote: > Hi, > > On 4/29/22 21:17, Stephen John Smoogen wrote: > > > > > > On Fri, 29 Apr 2022 at 14:28, Germano Massullo > > mailto:germano.massu...@gmail.com>> 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 > We can't stop it from happening in the future. Pretty much every time I have seen it is because something changed in the 'way things have been done previously' and so it looked like a new problem with the same similarities. I think we can offer solutions to make this better and possibly help implement prototypes to show that they work or not. > 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. > > I think the primary issue is that the crafting of binary packages is 'fairly' manual. Someone has to put the src.rpm in the meat grinder (koji) in the right order with the right spices (flags) to make the sausage at the other end. We rely on the cook to remember how they did it the last 10 times and that the taster (functional and ci) says it works. This normally works well but then it turns out that something swapped out somewhere and once 'fully cooked' (composed) that the sausage explodes. I think we would need to study how the build system really works, and how the recipe of 'order of builds' is determined. From that we can then suggest improvements which the CentOS Release Engineering can implement. It could be that coming up with some tool which makes the order of builds more automated may help, but without knowing how the workplace actually runs.. I am just making suggestions from the restaurant table :). > Cheers, > Alex > > > 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 > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: ABI-break changes in CentOS and EPEL dependencies
On Mon, May 2, 2022 at 9:04 AM Petr Menšík wrote: > > Hi. > > I had a discussion about AlmaLinux Beta on root.cz. Some person > complained CentOS Stream is unusable, because it is breaking ABI of > packages. He got libpoppler as an example. > > I just thought, we have all public code changes on GitLab. Could we mark > MR containing ABI breaks in a special way? It might help catching those > changes sooner by maintainers of dependent packages. > > If EPEL package depends on rebased CentOS package, is there a good way > how to handle synchronization to EPEL rebuilds or even rpmfusion > depending builds? Would some automation helping with this make sense? Is > it rare enough that it does not need any automatic processing? > > I thought if MR were marked with special tag, maybe on its merge some > bot could open bugzillas or even open PR on depending packages with just > bumpspec to rebuild. Do you think it would be worth the effort? Does it > have better alternative? > ABI breakages can be detected in CI and noted in some way. That would be in Zuul, which already runs a bunch of checks. -- 真実はいつも一つ！/ Always, there's only one truth! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Qt update and packages rebuild
Hi, On 4/29/22 21:17, Stephen John Smoogen wrote: On Fri, 29 Apr 2022 at 14:28, Germano Massullo mailto:germano.massu...@gmail.com>> 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 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-667d59a6db suricata-5.0.9-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-62b1a9e158 ImageMagick-6.9.12.44-1.el8 converseen-0.9.8.1-2.el8 digikam-6.4.0-5.el8 dvdauthor-0.7.2-16.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing liborc-1.7.4-1.el8 Details about builds: liborc-1.7.4-1.el8 (FEDORA-EPEL-2022-61a103df7f) Library for producing small, fast columnar storage for Hadoop workloads Update Information: orc 1.7.4 GA ChangeLog: * Sun May 1 2022 Kaleb S. KEITHLEY - 1.7.4-1 - 1.7.4 GA ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Qt update and packages rebuild
On 29. 04. 22 22:01, Troy Dawson wrote: And ... now I just realized that this sounds alot like taking my Will-It-Install and pointing it at the CentOS Stream 9 development compose. I am afraid that we would need to point it to a repository that contains all the builds immediately as they happen, before they pass gating. And I am not sure such repository exists. Is there a Koji repo from the c9s-gate tag? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
