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(a)fedoraproject.org>
wrote:
Kalev Lember wrote on 2022/07/25 0:45:
> On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA <mtasaka(a)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/34b203d5499b579c68b4f923a29fd4...
>>>
>>
>> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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 <
https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<
https://www.redhat.com>