Quite a lot of reading but thanks everyone for the emails.

Few observations I get from this email thread (correct me if I misunderstood anything):

1) We don't have a unified process for how to do such a retirement/orphan package workflow.

2) We don't have a deterministic unified tool/script for how to find all packages that depend on the "want-to-be-orphaned" package. Looks like the one that Fabio provides is quite good, it may be worth to document it somewhere, so it can be used in future.

3) It looks like there are some packages that don't even know why they require the pcre package. This may be worth investigating for the maintainers, so the package doesn't require something that is not even used.

4) There are some folks that are willing to take over the maintenance of the pcre package. I'm still going to create a COPR build for every dependent package with change from "pcre" to "pcre2" requirement, so I can report each of the components, if it's able to just simply change to pcre2 or need to port.
    However, after that, I will pass the component to the people that want to maintain it. I can see that Vitaly (FAS = xvitaly) is willing, feel free to message me if there is anybody else that wants to help him.

For the packages that are going to port their code to pcre2, you can do it in the upcoming release, so you don't need to rush, we appreciate you're doing it.

Thank you all for all of the insightful information and help.
Lukas

On Mon, Jul 25, 2022 at 10:23 AM Mamoru TASAKA <mtasaka@fedoraproject.org> wrote:
Kalev Lember wrote on 2022/07/25 0:45:
> On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA <mtasaka@fedoraproject.org>
> wrote:
>
>> Kalev Lember wrote on 2022/07/24 22:42:
>>> glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs
>> to
>>> be updated for that now so that it BuildRequires pcre2-static instead?
>>>
>>>
>> https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd417efdd9637?branch=rawhide
>>>
>>
>> Ah... maybe due to this?
>>
>> A.
>> On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby
>> language) sees
>> test failure with regards to "g_regex_match_all" - note that this is s390x
>> only.
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927
>>
>> B.
>> I got lxrandr behavior regression on rawhide:
>> https://bugzilla.redhat.com/show_bug.cgi?id=2109187
>>
>> - what lxrandr does here is lxrander gets the result of "xrandr" and
>>     passes it to "g_regex_match".
>>     On F-36 actually "g_regex_match" matches but (while I have not tried
>> yet)
>>     what bug reporter says must be that "g_regex_match" now fails with
>>     rawhide glib2 (this is happening on x86_64).
>>
>> I will recheck this tomorrow.
>>
>
> Those both sound a lot like regressions in g_regex_match() to me. If you
> have time, any chance you could create smaller reproducers and file issues
> for these upstream at https://gitlab.gnome.org/GNOME/glib ?

For issue A: reported (with smallest reproducer): https://gitlab.gnome.org/GNOME/glib/-/issues/2699

Now I will recheck issue B (maybe tomorrow...)

Mamoru
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


--
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavorsk@redhat.com