Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

Of course, only the deprecation will be moved to F38.

The removal is stalled until the deprecation is completed. Once done, the
new Fedora change will start from the beginning, containing the removal.

It looks like the community is okay with moving the deprecation to F38, so
I'll move it.

On Tue, Aug 23, 2022 at 12:22 PM Fabio Valentini 
wrote:

> On Tue, Aug 23, 2022 at 10:23 AM Lukas Javorsky 
> wrote:
> >
> > Hello Zbigniew,
> >
> > I would love to have it on F38, but I'm not sure it would be enough time
> for all of the maintainers whose packages depend on the old pcre.
> >
> > Ben, do you think we can make this to F38?
>
> Moving the *deprecation* to F38 should be fine (since that is a
> metadata-only change and an additional incentive to port packages to
> pcre2), but moving the *removal* to F38 is probably not.
>
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

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

Re: Retiring the pcre package from Fedora

[Fabio Valentini]

On Tue, Aug 23, 2022 at 10:23 AM Lukas Javorsky  wrote:
>
> Hello Zbigniew,
>
> I would love to have it on F38, but I'm not sure it would be enough time for 
> all of the maintainers whose packages depend on the old pcre.
>
> Ben, do you think we can make this to F38?

Moving the *deprecation* to F38 should be fine (since that is a
metadata-only change and an additional incentive to port packages to
pcre2), but moving the *removal* to F38 is probably not.

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

Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

Hello Zbigniew,

I would love to have it on F38, but I'm not sure it would be enough time
for all of the maintainers whose packages depend on the old pcre.

Ben, do you think we can make this to F38?

Thank you for answering.
Lukas

On Fri, Aug 19, 2022 at 3:33 PM Ben Cotton  wrote:

> On Thu, Aug 18, 2022 at 5:30 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > Why F39? Shouldn't the deprecation (and the work on porting) be already
> happening for F38?
>
> I'm going to wait to process the proposal until we have an answer to
> this question. (I believe Lukas is out of the office, so it may be a
> few days)
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
>
>

-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

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

Re: Retiring the pcre package from Fedora

[Ben Cotton]

On Thu, Aug 18, 2022 at 5:30 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Why F39? Shouldn't the deprecation (and the work on porting) be already 
> happening for F38?

I'm going to wait to process the proposal until we have an answer to
this question. (I believe Lukas is out of the office, so it may be a
few days)


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring the pcre package from Fedora

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 18, 2022 at 11:21:05AM +0200, Lukas Javorsky wrote:
> I've just finished the pcre deprecation change [1].
> If anyone is interested, please take a look.
> 
> [1] https://fedoraproject.org/wiki/PcreDeprecation

Why F39? Shouldn't the deprecation (and the work on porting) be already 
happening for F38?

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

Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

I've just finished the pcre deprecation change [1].
If anyone is interested, please take a look.

[1] https://fedoraproject.org/wiki/PcreDeprecation

Lukas

On Wed, Aug 17, 2022 at 2:43 PM Lukas Javorsky  wrote:

> Hi Richard,
>
> The Fedora 39 System Wide changes are scheduled for Jun 2023, so that
> would be the deadline for this.
>
> However, after feedback, I've decided to create a pcre deprecation change
> at first so it's broken into more pieces and it's better documented.
> When it's ready, I'll paste the link for the new pcre deprecation change.
> You can ignore the retirement change for now, because that one will be
> proposed after the package is deprecated.
>
> Thank you and sorry for the inconvenience.
> Lukas
>
> On Wed, Aug 17, 2022 at 2:33 PM Richard W.M. Jones 
> wrote:
>
>> On Wed, Aug 17, 2022 at 02:25:06PM +0200, Lukas Javorsky wrote:
>> > The Fedora change for this topic is created [1].
>> >
>> > [1] https://fedoraproject.org/wiki/PcreRetirement
>>
>> It would be helpful to have an actual deadline written in there.
>> "Fedora 39" requires an indirection.  Are we talking 2023?  2024?
>> What date exactly?  I need to tell upstreams that they have until a
>> certain date to make the change.
>>
>> Rich.
>>
>> > On Mon, Aug 15, 2022 at 11:46 AM Lukas Javorsky 
>> wrote:
>> >
>> > Hi,
>> >
>> > I've decided to write a Fedora change that will contain all of the
>> > information about this possible retirement.
>> >
>> > I have to fill the dependencies that will be affected by this
>> change, so
>> > I'm looking for the tool/command which will give them to me.
>> > I've seen multiple suggestions here in this thread, but is there
>> some kind
>> > of consensus about which one should I choose (which one is the most
>> > accurate)?
>> >
>> > Thank you so much
>> > Lukas
>> >
>> > On Tue, Jul 26, 2022 at 11:17 AM Paolo Bonzini 
>> wrote:
>> >
>> > Due to static linking, not all functions will be included in the
>> > executable and therefore some simple "hello world"  binaries
>> will not
>> > need sysprof-capture-static. However, anything that used the
>> .pc file
>> > will need it.
>> >
>> > Technically, you could also use glib's static library without
>> dependent
>> > .a libraries if you link with glib's .a file but do not specify
>> > -static; but that's not a good argument against having a
>> Requires for
>> > the dependency in my opinion, because it makes the .pc file not
>> work
>> > out of the box. Perhaps a weak dependency, but even that sounds
>> > strange.
>> >
>> > As to glibc-static I think it's fair to say that whoever uses
>> -static
>> > will have to install it on their own, so it can be left out of
>> > glib2.spec.
>> >
>> > Paolo
>> >
>> >
>> > Il mar 26 lug 2022, 10:59 Daniel P. Berrangé <
>> berra...@redhat.com> ha
>> > scritto:
>> >
>> > Although listed in glib-2.0.pc, I didn't find any need for
>> the
>> > sysprof-capture-static package, but it does need
>> glibc-static
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to
>> 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/
>> > 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
>> >
>> > ljavo...@redhat.com
>> >
>> > [logo--200]
>> >
>> >
>> >
>> >
>> >
>> > --
>> > S pozdravom/ Best regards
>> >
>> > Lukáš Javorský
>> >
>> > Software Engineer, Core service - Databases
>> >
>> > Red Hat
>> >
>> > Purkyňova 115 (TPB-C)
>> >
>> > 612 00 Brno - Královo Pole
>> >
>> > ljavo...@redhat.com
>> >
>> > [logo--200]
>> >
>> >
>>
>> --
>> Richard Jones, Virtualization Group, Red Hat
>> http://people.redhat.com/~rjones
>> Read my programming and virtualization blog: http://rwmj.wordpress.com
>> virt-builder quickly builds VMs from scratch
>> http://libguestfs.org/virt-builder.1.html
>>
>>
>
> --
> S pozdravom/ Best regards
>
> Lukáš Javorský
>
> Software Engineer, Core service - Databases
>
> Red Hat 
>
> Purkyňova 115 (TPB-C)
>
> 612 00 Brno - Královo Pole
>
> ljavo...@redhat.com
> 
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - 

Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

Hi Richard,

The Fedora 39 System Wide changes are scheduled for Jun 2023, so that would
be the deadline for this.

However, after feedback, I've decided to create a pcre deprecation change
at first so it's broken into more pieces and it's better documented.
When it's ready, I'll paste the link for the new pcre deprecation change.
You can ignore the retirement change for now, because that one will be
proposed after the package is deprecated.

Thank you and sorry for the inconvenience.
Lukas

On Wed, Aug 17, 2022 at 2:33 PM Richard W.M. Jones 
wrote:

> On Wed, Aug 17, 2022 at 02:25:06PM +0200, Lukas Javorsky wrote:
> > The Fedora change for this topic is created [1].
> >
> > [1] https://fedoraproject.org/wiki/PcreRetirement
>
> It would be helpful to have an actual deadline written in there.
> "Fedora 39" requires an indirection.  Are we talking 2023?  2024?
> What date exactly?  I need to tell upstreams that they have until a
> certain date to make the change.
>
> Rich.
>
> > On Mon, Aug 15, 2022 at 11:46 AM Lukas Javorsky 
> wrote:
> >
> > Hi,
> >
> > I've decided to write a Fedora change that will contain all of the
> > information about this possible retirement.
> >
> > I have to fill the dependencies that will be affected by this
> change, so
> > I'm looking for the tool/command which will give them to me.
> > I've seen multiple suggestions here in this thread, but is there
> some kind
> > of consensus about which one should I choose (which one is the most
> > accurate)?
> >
> > Thank you so much
> > Lukas
> >
> > On Tue, Jul 26, 2022 at 11:17 AM Paolo Bonzini 
> wrote:
> >
> > Due to static linking, not all functions will be included in the
> > executable and therefore some simple "hello world"  binaries
> will not
> > need sysprof-capture-static. However, anything that used the .pc
> file
> > will need it.
> >
> > Technically, you could also use glib's static library without
> dependent
> > .a libraries if you link with glib's .a file but do not specify
> > -static; but that's not a good argument against having a
> Requires for
> > the dependency in my opinion, because it makes the .pc file not
> work
> > out of the box. Perhaps a weak dependency, but even that sounds
> > strange.
> >
> > As to glibc-static I think it's fair to say that whoever uses
> -static
> > will have to install it on their own, so it can be left out of
> > glib2.spec.
> >
> > Paolo
> >
> >
> > Il mar 26 lug 2022, 10:59 Daniel P. Berrangé <
> berra...@redhat.com> ha
> > scritto:
> >
> > Although listed in glib-2.0.pc, I didn't find any need for
> the
> > sysprof-capture-static package, but it does need glibc-static
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to
> 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/
> > 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
> >
> > ljavo...@redhat.com
> >
> > [logo--200]
> >
> >
> >
> >
> >
> > --
> > S pozdravom/ Best regards
> >
> > Lukáš Javorský
> >
> > Software Engineer, Core service - Databases
> >
> > Red Hat
> >
> > Purkyňova 115 (TPB-C)
> >
> > 612 00 Brno - Královo Pole
> >
> > ljavo...@redhat.com
> >
> > [logo--200]
> >
> >
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
>
>

-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 

Re: Retiring the pcre package from Fedora

[Richard W.M. Jones]

On Wed, Aug 17, 2022 at 02:25:06PM +0200, Lukas Javorsky wrote:
> The Fedora change for this topic is created [1].
> 
> [1] https://fedoraproject.org/wiki/PcreRetirement

It would be helpful to have an actual deadline written in there.
"Fedora 39" requires an indirection.  Are we talking 2023?  2024?
What date exactly?  I need to tell upstreams that they have until a
certain date to make the change.

Rich.

> On Mon, Aug 15, 2022 at 11:46 AM Lukas Javorsky  wrote:
> 
> Hi,
> 
> I've decided to write a Fedora change that will contain all of the
> information about this possible retirement.
> 
> I have to fill the dependencies that will be affected by this change, so
> I'm looking for the tool/command which will give them to me.
> I've seen multiple suggestions here in this thread, but is there some kind
> of consensus about which one should I choose (which one is the most
> accurate)?
> 
> Thank you so much
> Lukas
> 
> On Tue, Jul 26, 2022 at 11:17 AM Paolo Bonzini  
> wrote:
> 
> Due to static linking, not all functions will be included in the
> executable and therefore some simple "hello world"  binaries will not
> need sysprof-capture-static. However, anything that used the .pc file
> will need it.
> 
> Technically, you could also use glib's static library without 
> dependent
> .a libraries if you link with glib's .a file but do not specify
> -static; but that's not a good argument against having a Requires for
> the dependency in my opinion, because it makes the .pc file not work
> out of the box. Perhaps a weak dependency, but even that sounds
> strange.
> 
> As to glibc-static I think it's fair to say that whoever uses -static
> will have to install it on their own, so it can be left out of
> glib2.spec.
> 
> Paolo
> 
> 
> Il mar 26 lug 2022, 10:59 Daniel P. Berrangé  ha
> scritto:
> 
> Although listed in glib-2.0.pc, I didn't find any need for the
> sysprof-capture-static package, but it does need glibc-static
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/
> 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
> 
> ljavo...@redhat.com
> 
> [logo--200]
> 
> 
> 
> 
> 
> --
> S pozdravom/ Best regards
> 
> Lukáš Javorský
> 
> Software Engineer, Core service - Databases
> 
> Red Hat
> 
> Purkyňova 115 (TPB-C)
> 
> 612 00 Brno - Královo Pole
> 
> ljavo...@redhat.com
> 
> [logo--200]
> 
> 

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

The Fedora change for this topic is created [1].

[1] https://fedoraproject.org/wiki/PcreRetirement

On Mon, Aug 15, 2022 at 11:46 AM Lukas Javorsky  wrote:

> Hi,
>
> I've decided to write a Fedora change that will contain all of the
> information about this possible retirement.
>
> I have to fill the dependencies that will be affected by this change, so
> I'm looking for the tool/command which will give them to me.
> I've seen multiple suggestions here in this thread, but is there some kind
> of consensus about which one should I choose (which one is the most
> accurate)?
>
> Thank you so much
> Lukas
>
> On Tue, Jul 26, 2022 at 11:17 AM Paolo Bonzini 
> wrote:
>
>> Due to static linking, not all functions will be included in the
>> executable and therefore some simple "hello world"  binaries will not need
>> sysprof-capture-static. However, anything that used the .pc file will need
>> it.
>>
>> Technically, you could also use glib's static library without dependent
>> .a libraries if you link with glib's .a file but do not specify -static;
>> but that's not a good argument against having a Requires for the dependency
>> in my opinion, because it makes the .pc file not work out of the box.
>> Perhaps a weak dependency, but even that sounds strange.
>>
>> As to glibc-static I think it's fair to say that whoever uses -static
>> will have to install it on their own, so it can be left out of glib2.spec.
>>
>> Paolo
>>
>>
>> Il mar 26 lug 2022, 10:59 Daniel P. Berrangé  ha
>> scritto:
>>
>>> Although listed in glib-2.0.pc, I didn't find any need for the
>>> sysprof-capture-static package, but it does need glibc-static
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to 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/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
>
> ljavo...@redhat.com
> 
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

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

Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

Hi,

I've decided to write a Fedora change that will contain all of the
information about this possible retirement.

I have to fill the dependencies that will be affected by this change, so
I'm looking for the tool/command which will give them to me.
I've seen multiple suggestions here in this thread, but is there some kind
of consensus about which one should I choose (which one is the most
accurate)?

Thank you so much
Lukas

On Tue, Jul 26, 2022 at 11:17 AM Paolo Bonzini  wrote:

> Due to static linking, not all functions will be included in the
> executable and therefore some simple "hello world"  binaries will not need
> sysprof-capture-static. However, anything that used the .pc file will need
> it.
>
> Technically, you could also use glib's static library without dependent .a
> libraries if you link with glib's .a file but do not specify -static; but
> that's not a good argument against having a Requires for the dependency in
> my opinion, because it makes the .pc file not work out of the box. Perhaps
> a weak dependency, but even that sounds strange.
>
> As to glibc-static I think it's fair to say that whoever uses -static will
> have to install it on their own, so it can be left out of glib2.spec.
>
> Paolo
>
>
> Il mar 26 lug 2022, 10:59 Daniel P. Berrangé  ha
> scritto:
>
>> Although listed in glib-2.0.pc, I didn't find any need for the
>> sysprof-capture-static package, but it does need glibc-static
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/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

ljavo...@redhat.com

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

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

Due to static linking, not all functions will be included in the executable
and therefore some simple "hello world"  binaries will not need
sysprof-capture-static. However, anything that used the .pc file will need
it.

Technically, you could also use glib's static library without dependent .a
libraries if you link with glib's .a file but do not specify -static; but
that's not a good argument against having a Requires for the dependency in
my opinion, because it makes the .pc file not work out of the box. Perhaps
a weak dependency, but even that sounds strange.

As to glibc-static I think it's fair to say that whoever uses -static will
have to install it on their own, so it can be left out of glib2.spec.

Paolo


Il mar 26 lug 2022, 10:59 Daniel P. Berrangé  ha
scritto:

> Although listed in glib-2.0.pc, I didn't find any need for the
> sysprof-capture-static package, but it does need glibc-static
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Kalev Lember]

On Tue, Jul 26, 2022 at 10:59 AM Daniel P. Berrangé 
wrote:

> On Tue, Jul 26, 2022 at 10:10:15AM +0200, Kalev Lember wrote:
> >
> > On 7/26/22 07:47, Paolo Bonzini wrote:
> > > On 7/24/22 15:42, Kalev Lember wrote:
> > > > On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  > > > > wrote:
> > > >
> > > >
> > > >
> > > > Il sab 23 lug 2022, 19:12 Adam Williamson
> > > > mailto:adamw...@fedoraproject.org>>
> ha
> > > > scritto:
> > > >
> > > > This of course begs a question: did qemu also have a
> > > > non-static pcre
> > > > requirement at the time? But it seems not:
> > > >
> > > > [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec |
> > > > grep pcre
> > > > BuildRequires: glibc-static pcre-static glib2-static
> zlib-static
> > > >
> > > > so, I'm not sure why Daniel concluded this needs a
> > > > BuildRequires on
> > > > pcre-static, but the obvious thing to do would be to ask
> him, I
> > > > guess.
> > > >
> > > >
> > > > I think it could have been a missing requires of glib2-static,
> > > > because glib does use PCRE and therefore has it in the linker
> flags
> > > > for a static build. I will check next time I am at a computer.
> > > >
> > > >
> > > > 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?
> > >
> > > Yep, that works.  I still think that pcre2-static and
> > > sysprof-capture-devel belong in glib2's spec file though, but I
> > > committed that as a stopgap measure.
> >
> > Ah, yes, of course! I went ahead and added them in
> https://src.fedoraproject.org/rpms/glib2/c/5653dff1816e4bee3c3fdbcc00f2fea73a282093?branch=rawhide
> >
> > Does this look right to you? Do you want me to add them in other
> > branches as well or is rawhide sufficient for now?
>
> Although listed in glib-2.0.pc, I didn't find any need for the
> sysprof-capture-static package, but it does need glibc-static
>

Do you want to do a PR to fix it up?

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

Re: Retiring the pcre package from Fedora

[Daniel P . Berrangé]

On Tue, Jul 26, 2022 at 10:10:15AM +0200, Kalev Lember wrote:
> 
> On 7/26/22 07:47, Paolo Bonzini wrote:
> > On 7/24/22 15:42, Kalev Lember wrote:
> > > On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  > > > wrote:
> > > 
> > > 
> > > 
> > >     Il sab 23 lug 2022, 19:12 Adam Williamson
> > >     mailto:adamw...@fedoraproject.org>> ha
> > >     scritto:
> > > 
> > >     This of course begs a question: did qemu also have a
> > > non-static pcre
> > >     requirement at the time? But it seems not:
> > > 
> > >     [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec |
> > > grep pcre
> > >     BuildRequires: glibc-static pcre-static glib2-static zlib-static
> > > 
> > >     so, I'm not sure why Daniel concluded this needs a
> > > BuildRequires on
> > >     pcre-static, but the obvious thing to do would be to ask him, I
> > >     guess.
> > > 
> > > 
> > >     I think it could have been a missing requires of glib2-static,
> > >     because glib does use PCRE and therefore has it in the linker flags
> > >     for a static build. I will check next time I am at a computer.
> > > 
> > > 
> > > 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?
> > 
> > Yep, that works.  I still think that pcre2-static and
> > sysprof-capture-devel belong in glib2's spec file though, but I
> > committed that as a stopgap measure.
> 
> Ah, yes, of course! I went ahead and added them in 
> https://src.fedoraproject.org/rpms/glib2/c/5653dff1816e4bee3c3fdbcc00f2fea73a282093?branch=rawhide
> 
> Does this look right to you? Do you want me to add them in other
> branches as well or is rawhide sufficient for now?

Although listed in glib-2.0.pc, I didn't find any need for the
sysprof-capture-static package, but it does need glibc-static


$ podman run -it fedora:rawhide

# cat > demo.c <

int main() {
  GString *s = g_string_new(NULL);
}
EOF

# gcc -o demo demo.c `pkg-config --cflags --libs --static glib-2.0` -static
/usr/bin/ld: cannot find -lm: No such file or directory
/usr/bin/ld: cannot find -lpcre2-8: No such file or directory
/usr/bin/ld: cannot find -lc: No such file or directory
collect2: error: ld returned 1 exit status

# dnf install pcre2-static

...snip...

Installed:
  pcre2-static-10.40-1.fc37.x86_64  

Complete!
# gcc -o demo demo.c `pkg-config --cflags --libs --static glib-2.0` -static
/usr/bin/ld: cannot find -lm: No such file or directory
/usr/bin/ld: cannot find -lc: No such file or directory
collect2: error: ld returned 1 exit status



With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Richard W.M. Jones]

On Sat, Jul 23, 2022 at 11:09:29AM +0100, Richard W.M. Jones wrote:
> > virt-p2v-1:1.42.1-1.fc37.src
> 
> This is a real one.  virt-p2v uses a small library called "miniexpect"
> which is based on pcre but needs to be ported to pcre2.

Fixed upstream now, I'll put it into Fedora after the next upstream
release.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Daniel P . Berrangé]

On Sun, Jul 24, 2022 at 08:58:18AM +0200, Paolo Bonzini wrote:
> Il sab 23 lug 2022, 19:12 Adam Williamson  ha
> scritto:
> 
> > This of course begs a question: did qemu also have a non-static pcre
> > requirement at the time? But it seems not:
> >
> > [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre
> > BuildRequires: glibc-static pcre-static glib2-static zlib-static
> >
> > so, I'm not sure why Daniel concluded this needs a BuildRequires on
> > pcre-static, but the obvious thing to do would be to ask him, I guess.
> >
> 
> I think it could have been a missing requires of glib2-static, because glib
> does use PCRE and therefore has it in the linker flags for a static build.
> I will check next time I am at a computer.

Yes, the spec file is missing requires. I filed a bug about this but
it got auto-closed without being fixed :-(

https://bugzilla.redhat.com/show_bug.cgi?id=1350970

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Richard W.M. Jones]

On Tue, Jul 26, 2022 at 10:19:55AM +0200, Paolo Bonzini wrote:
> On Tue, Jul 26, 2022 at 10:10 AM Kalev Lember  wrote:
> > Does this look right to you? Do you want me to add them in other
> > branches as well or is rawhide sufficient for now?
> 
> Rawhide is enough, for other branches QEMU is working around it by
> requiring pcre-static. Thanks!
> 
> I'm now debugging the SIGABRT in file(1).

FYI there was another problem that turned up in the F37 mass rebuild
that you may hit later on:

ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
   You probably need to set PKG_CONFIG_LIBDIR
   to point to the right pkg-config files for your
   build target

https://koji.fedoraproject.org/koji/taskinfo?taskID=89893804

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

On Tue, Jul 26, 2022 at 10:10 AM Kalev Lember  wrote:
> Does this look right to you? Do you want me to add them in other
> branches as well or is rawhide sufficient for now?

Rawhide is enough, for other branches QEMU is working around it by
requiring pcre-static. Thanks!

I'm now debugging the SIGABRT in file(1).

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

Re: Retiring the pcre package from Fedora

[Kalev Lember]

On 7/25/22 10:23, Mamoru TASAKA wrote:

Kalev Lember wrote on 2022/07/25 0:45:

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


Excellent, thank you!

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

Re: Retiring the pcre package from Fedora

[Kalev Lember]

On 7/26/22 07:47, Paolo Bonzini wrote:

On 7/24/22 15:42, Kalev Lember wrote:
On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini > wrote:




    Il sab 23 lug 2022, 19:12 Adam Williamson
    mailto:adamw...@fedoraproject.org>> ha
    scritto:

    This of course begs a question: did qemu also have a 
non-static pcre

    requirement at the time? But it seems not:

    [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep 
pcre

    BuildRequires: glibc-static pcre-static glib2-static zlib-static

    so, I'm not sure why Daniel concluded this needs a 
BuildRequires on

    pcre-static, but the obvious thing to do would be to ask him, I
    guess.


    I think it could have been a missing requires of glib2-static,
    because glib does use PCRE and therefore has it in the linker flags
    for a static build. I will check next time I am at a computer.


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?


Yep, that works.  I still think that pcre2-static and 
sysprof-capture-devel belong in glib2's spec file though, but I 
committed that as a stopgap measure.


Ah, yes, of course! I went ahead and added them in 
https://src.fedoraproject.org/rpms/glib2/c/5653dff1816e4bee3c3fdbcc00f2fea73a282093?branch=rawhide


Does this look right to you? Do you want me to add them in other
branches as well or is rawhide sufficient for now?

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

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

On 7/24/22 15:42, Kalev Lember wrote:
On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini > wrote:




Il sab 23 lug 2022, 19:12 Adam Williamson
mailto:adamw...@fedoraproject.org>> ha
scritto:

This of course begs a question: did qemu also have a non-static pcre
requirement at the time? But it seems not:

[adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre
BuildRequires: glibc-static pcre-static glib2-static zlib-static

so, I'm not sure why Daniel concluded this needs a BuildRequires on
pcre-static, but the obvious thing to do would be to ask him, I
guess.


I think it could have been a missing requires of glib2-static,
because glib does use PCRE and therefore has it in the linker flags
for a static build. I will check next time I am at a computer.


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?


Yep, that works.  I still think that pcre2-static and 
sysprof-capture-devel belong in glib2's spec file though, but I 
committed that as a stopgap measure.


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

Re: repoquery-fu (was Re: Retiring the pcre package from Fedora)

[Fabio Valentini]

On Mon, Jul 25, 2022 at 1:50 AM Demi Marie Obenour
 wrote:
>
> Rust *already* has full dynamic linking support, and this is used
> on Android to save space and memory.  What Rust does not have is
> a stable ABI.  Therefore, when Rust code changes, all Rust code
> depending on it must be recompiled.  The same is true for Haskell
> with GHC.  To make this maintainable, the necessary recompiles must
> be automated, so that when a new version of e.g. hyper is pushed,
> all packages that use hyper are rebuilt automatically.

Google can do this for Android, because they control *the entire stack*.
We can't, because all published Rust crates that matter don't support
being built that way.
Before we talk about making something maintainable, it should be
*possible* in the first place.

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

Re: Retiring the pcre package from Fedora

[Sérgio Basto]

On Fri, 2022-07-22 at 14:52 +0200, Petr Pisar wrote:
> V Fri, Jul 22, 2022 at 02:24:00PM +0200, Lukas Javorsky napsal(a):
> > As from the pcre-8.45, the upstream stopped supporting this
> > library. The
> > recommended procedure is to switch onto the new pcre2 library that
> > has full
> > upstream support. [1]
> > 
> > As a result of this announcement, the older PCRE library in Fedora
> > will be
> > retired.
> > Without upstream support, we don't have enough capacity to keep up
> > with the
> > security and bugs-related issues, and thus we will support only the
> > new
> > PCRE2 library. [2]
> > 
> > The retirement procedure will happen in the upcoming weeks, so if
> > you would
> > like to take over the package let us know.
> > 
> > 
> > The list of affected packages:
> > 389-ds-base
> > 389-ds-base-libs
> > EMBOSS-libs
> [...]
> > perl
> 
> I'm not sure what "affected" means here, but e.g. perl has no direct
> dependency on pcre. Maybe your computation is not correct.
> 

only perl-re-engine-PCRE (maintained by: jplesnik, ppisar)


Depending on: pcre (141),
389-ds-base (maintained by: abbra, mreynolds, rmeggins, spichugi,
tbordaz, vashirov)
389-ds-base-2.2.2-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
389-ds-base-2.2.2-1.fc37.x86_64 requires libpcre.so.1()(64bit)
389-ds-base-libs-2.2.2-1.fc37.x86_64 requires libpcre.so.1()(64bit)

ClanLib (maintained by: jwrdegoede)
ClanLib-2.3.7-25.fc36.src requires pcre-devel = 8.45-1.fc36.1
ClanLib-devel-2.3.7-25.fc36.i686 requires pcre-devel = 8.45-1.fc36.1
ClanLib-devel-2.3.7-25.fc36.x86_64 requires pcre-devel = 8.45-1.fc36.1

EMBOSS (maintained by: spot)
EMBOSS-6.6.0-20.fc36.src requires pcre-devel = 8.45-1.fc36.1
EMBOSS-libs-6.6.0-20.fc36.i686 requires libpcre.so.1
EMBOSS-libs-6.6.0-20.fc36.x86_64 requires libpcre.so.1()(64bit)
libeplplot-6.6.0-20.fc36.i686 requires libpcre.so.1
libeplplot-6.6.0-20.fc36.x86_64 requires libpcre.so.1()(64bit)

Falcon (maintained by: salimma)
Falcon-0.9.6.8-24.fc36.i686 requires libpcre.so.1
Falcon-0.9.6.8-24.fc36.src requires pkgconfig(libpcre) = 8.45
Falcon-0.9.6.8-24.fc36.x86_64 requires libpcre.so.1()(64bit)

GMT (maintained by: orion, scitech_sig)
GMT-6.4.0-1.fc37.i686 requires libpcre.so.1
GMT-6.4.0-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
GMT-6.4.0-1.fc37.x86_64 requires libpcre.so.1()(64bit)

Io-language (maintained by: limb)
Io-language-20170906-7.fc37.i686 requires libpcre.so.1
Io-language-20170906-7.fc37.src requires pcre-devel = 8.45-1.fc36.1
Io-language-20170906-7.fc37.x86_64 requires libpcre.so.1()(64bit)

R (maintained by: spot)
R-4.1.3-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
R-core-devel-4.1.3-1.fc37.i686 requires pcre-devel = 8.45-1.fc36.1
R-core-devel-4.1.3-1.fc37.x86_64 requires pcre-devel = 8.45-1.fc36.1

Thunar (maintained by: kevin, nonamedotc)
Thunar-4.16.11-1.fc37.i686 requires libpcre.so.1
Thunar-4.16.11-1.fc37.src requires pkgconfig(libpcre) = 8.45
Thunar-4.16.11-1.fc37.x86_64 requires libpcre.so.1()(64bit)

adanaxisgpl (maintained by: jwrdegoede)
adanaxisgpl-1.2.5-42.fc37.src requires pcre-devel = 8.45-1.fc36.1
adanaxisgpl-1.2.5-42.fc37.x86_64 requires libpcre.so.1()(64bit)

aide (maintained by: alakatos, rsroka, zfridric)
aide-0.16-19.fc36.src requires pcre-devel = 8.45-1.fc36.1
aide-0.16-19.fc36.x86_64 requires libpcre.so.1()(64bit)

aircrack-ng (maintained by: xvitaly)
aircrack-ng-1.7-1.fc37.i686 requires libpcre.so.1
aircrack-ng-1.7-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
aircrack-ng-1.7-1.fc37.x86_64 requires libpcre.so.1()(64bit)

anope (maintained by: robert)
anope-2.0.10-5.fc37.src requires pcre-devel = 8.45-1.fc36.1
anope-pcre-2.0.10-5.fc37.x86_64 requires libpcre.so.1()(64bit)

apachetop (maintained by: robert)
apachetop-0.19.7-7.fc36.src requires pcre-devel = 8.45-1.fc36.1

bigloo (maintained by: jjames, salimma)
bigloo-4.4c-5.4.fc37.src requires pkgconfig(libpcre) = 8.45

blender (maintained by: design-sw, ignatenkobrain, kwizart, luya,
music, roma, s4504kr, slaanesh)
blender-1:3.2.1-2.fc37.src requires pkgconfig(libpcre) = 8.45

bti (maintained by: salimma)
bti-034-24.fc36.src requires pkgconfig(libpcre) = 8.45
bti-034-24.fc36.x86_64 requires libpcre.so.1()(64bit)

ccze (maintained by: dcavalca, epel-packagers-sig, salimma)
ccze-0.2.1-28.fc36.src requires pcre-devel = 8.45-1.fc36.1
ccze-0.2.1-28.fc36.x86_64 requires libpcre.so.1()(64bit)

cegui (maintained by: bruno, jwrdegoede, timn)
cegui-0.8.7-24.fc37.i686 requires libpcre.so.1
cegui-0.8.7-24.fc37.src requires pcre-devel = 8.45-1.fc36.1
cegui-0.8.7-24.fc37.x86_64 requires libpcre.so.1()(64bit)

cegui06 (maintained by: bruno, jwrdegoede)
cegui06-0.6.2-38.fc37.src requires pcre-devel = 8.45-1.fc36.1
cegui06-0.6.2-38.fc37.x86_64 requires libpcre.so.1()(64bit)

clamav (maintained by: gnat, janfrode, mstevens, nb, orion, pwouters,
robert, sergiomb, steve)
clamav-0.103.6-1.fc37.src requires pcre-devel = 8.45-1.fc36.1

clisp (maintained by: green, jjames)
clisp-2.49.93-23.20210628gitde01f0f.fc36.i686 requires libpcre.so.1

Re: Retiring the pcre package from Fedora

[Ben Cotton]

On Sat, Jul 23, 2022 at 5:55 PM Kevin Kofler via devel
 wrote:
>
> We just need to accept that we need to maintain pcre as a compatibility
> library for the foreseeable future.

I'm sympathetic to your "we shouldn't block people from maintaining
things if they want to" argument, but I have to disagree here. There's
only so much time that the community can collectively devote to Fedora
and this is not a place I'd like us to spend it. If someone really
wants to maintain a package that upstream has moved on from, then good
for them. But it's better for us to help other upstreams that depend
on this old version to use the newer library, whether that's by direct
contribution or peer pressure.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Petr Pisar]

V Mon, Jul 25, 2022 at 11:38:49AM +0200, Lukas Javorsky napsal(a):
> 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.

If you find a package which builds after replacing BuildRequires, you should
rather report a bug.

Each package should explicitly configure enabled and disabled features instead
of automatically enabling and disabling features based on a presence of
developmental files in a build root. These automagically enabled features are
a source of nondeterminism (sponteaous build failures and feature flips)
triggered by changes in indirectly dependenent and unrelated packages.

-- Petr


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

Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

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 
wrote:

> Kalev Lember wrote on 2022/07/25 0:45:
> > On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA  >
> > 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-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/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

ljavo...@redhat.com

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

Re: Retiring the pcre package from Fedora

[Mamoru TASAKA]

Kalev Lember wrote on 2022/07/25 0:45:

On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA 
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-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: repoquery-fu (was Re: Retiring the pcre package from Fedora)

[Fabio Valentini]

On Sat, Jul 23, 2022 at 2:01 PM Neal Gompa  wrote:
>
> On Sat, Jul 23, 2022 at 7:47 AM Fabio Valentini  wrote:
> >
> > - the sets of dependent packages overlap between concurrently created side 
> > tags
>
> So what? If we're not tracking rebuilds in Git anymore, this is no
> longer a serious problem. The build system knows every time a commit
> is requested and increments the counter accordingly.

So what? This is definitely a problem that would need to be solved somehow.
Assume a package X that depends on both libfoo and libbar, and there's
concurrent soname bumps for those two libraries.
Then package X gets rebuilt in side-tag M for the libfoo soname bump,
and rebuilt in side-tag N for the libbar soname bump,
but it would need to get rebuilt against *both* in order to result in
a working package.
The only way to solve this would be to serialize builds for side tags
instead of running them in parallel, or to run builds multiple times,
until installability tests etc. succeed.

> The fundamental difference between your thought and mine is that you
> want it to be perfect. I want it to be good enough to eliminate the
> *majority* of provenpackager grunt work and stop punishing people so
> hard for bringing useful software library packages into the
> distribution.
>
> Failure is okay. Human intervention is fine. Design a process that
> handles 80% and make it gracefully fail for the remaining 20%.
>
> You seem to think it's unworkable, but I work in a Linux distribution
> that operates this way and has for twenty years! I *know* it works.
> It's not perfect, and there's certainly going to be some human
> intervention and probably some configuration stuff to resolve things
> machines can't figure out on their own (like build cycles and things
> of that nature), but it is absolutely possible to do this and make the
> lives of the majority of packagers easier.

I'm not saying it's impossible, but I think in our current state, we
wouldn't end up with "80% are fine and 20% would require manual
intervention", but rather the other way round. And at that point, any
automated mechanism starts to be rather useless - which is why I'd
like to improve the underlying problems *first* and then implement
automation that *actually works in the majority of cases* later.

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

Re: Retiring the pcre package from Fedora

[Kalev Lember]

On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA 
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 ?

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

Re: Retiring the pcre package from Fedora

[Mamoru TASAKA]

Kalev Lember wrote on 2022/07/24 22:42:

On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  wrote:





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.

Regards,
Mamoru

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

Re: Retiring the pcre package from Fedora

[Kalev Lember]

On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  wrote:

>
>
> Il sab 23 lug 2022, 19:12 Adam Williamson  ha
> scritto:
>
>> This of course begs a question: did qemu also have a non-static pcre
>> requirement at the time? But it seems not:
>>
>> [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre
>> BuildRequires: glibc-static pcre-static glib2-static zlib-static
>>
>> so, I'm not sure why Daniel concluded this needs a BuildRequires on
>> pcre-static, but the obvious thing to do would be to ask him, I guess.
>>
>
> I think it could have been a missing requires of glib2-static, because
> glib does use PCRE and therefore has it in the linker flags for a static
> build. I will check next time I am at a computer.
>

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

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

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

Il sab 23 lug 2022, 19:12 Adam Williamson  ha
scritto:

> This of course begs a question: did qemu also have a non-static pcre
> requirement at the time? But it seems not:
>
> [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre
> BuildRequires: glibc-static pcre-static glib2-static zlib-static
>
> so, I'm not sure why Daniel concluded this needs a BuildRequires on
> pcre-static, but the obvious thing to do would be to ask him, I guess.
>

I think it could have been a missing requires of glib2-static, because glib
does use PCRE and therefore has it in the linker flags for a static build.
I will check next time I am at a computer.

Paolo

-- 
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Kevin Kofler via devel]

Stewart Smith via devel wrote:
> cppcheck can be built without HAVE_RULES which will avoid pcre at the
> expense of functionality.

I do not think that it makes sense to build stuff with reduced functionality 
just to avoid a pcre dependency.

We just need to accept that we need to maintain pcre as a compatibility 
library for the foreseeable future.

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

Re: Retiring the pcre package from Fedora

[Stewart Smith via devel]

Lukas Javorsky  writes:
> Hi,
>
> As from the pcre-8.45, the upstream stopped supporting this
> library. The recommended procedure is to switch onto the new pcre2
> library that has full upstream support. [1]

I was looking into doing this as much as possible for AL2022 and managed
to dig a bit on how to solve some of these. Some knowledge I gained (and
pull requests linked) below:

> As a result of this announcement, the older PCRE library in Fedora will be 
> retired.
> Without upstream support, we don't have enough capacity to keep up
> with the security and bugs-related issues, and thus we will support
> only the new PCRE2 library. [2]
>
> The retirement procedure will happen in the upcoming weeks, so if you would 
> like to take over the package let us know.
>
>
> The list of affected packages:

> aide

aide has been ported upstream (at least in the dev branch),
https://src.fedoraproject.org/rpms/aide/pull-request/3 

> cppcheck
> cppcheck-gui

cppcheck can be built without HAVE_RULES which will avoid pcre at the
expense of functionality.

> ganglia
> ganglia-gmond

Ganglia has been effectively dead upstream for a long time, with no
functional security patching or keeping up to date with modern
PHP. Arguably it should also go, or come with bright flashing warning
lights.

> grep

There's been some development upstream on it:

commit e0d39a9133e1507345d73ac5aff85f037f39aa54
Author: Carlo Marcelo Arenas Belón 
Date:   Fri Nov 12 16:45:04 2021 -0800

grep: migrate to pcre2


and there's been a few bug fixes since then. It looks like a new release
is in the works, so this should be solved shortly.

> mod_security
> mod_security-mlogc

https://www.modsecurity.org/ seems to indicate that upstream has made
some fundamental changes, and will now be community maintained.

It does seem that PCRE2 support came in though
https://github.com/SpiderLabs/ModSecurity/commit/f84614fe066f74d111b802d582599655d0d7e3af

> nmap

There appears to be a renewed interest upstream for porting over
https://github.com/nmap/nmap/issues/1335


> openscap
> openscap-engine-sce

There's an upstream issue tracking this, I've mentioned that both
Fedora and Amazon Linux are looking to be without pcre in the not too
distant future.
See https://github.com/OpenSCAP/openscap/issues/1873

> postfix-pcre

Looks like it's a simple fix to the current upstream release:
https://src.fedoraproject.org/rpms/postfix/pull-request/6

> zsh

I haven't been able to find any clues on if upstream is working on this
or not. I'd love to know though!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Miro Hrončok]

On 23. 07. 22 0:22, Maxwell G via devel wrote:

(It seems my previous message didn't send properly...)


On 22/07/22 10:24PM, Fabio Valentini wrote:

the script that determines leaf packages in the Rust SIG


Can you provide a link to this?


$ (dnf repoquery --whatrequires pcre ; dnf repoquery --whatrequires
pcre-cpp ; dnf repoquery --whatrequires pcre-devel ; dnf repoquery
--whatrequires pcre-static ; dnf repoquery --whatrequires pcre-tools ;
dnf repoquery --whatrequires pcre-utf16 ; dnf repoquery --whatrequires
pcre-utf32) | sort | uniq | grep src


It's actually possible to pass --whatrequires mutliple times with all of
the dependencies, instead of running multiple queries. e.g.:

sudo dnf repoquery --whatrequires pcre --whatrequires pcre-cpp --whatrequires 
pcre-devel --whatrequires pcre-static --whatrequires pcre-tools --whatrequires 
pcre-utf16 --repo=rawhide{,-source} -q | grep '\.src$' | sort | uniq

This is quite a bit faster. I only just recently learned this, so I
thought I'd pass it on :).


I was just about to share the same thing. It is indeed a bit faster. Also 
faster to type.


However, with --recursive, it's amazingly faster (as subpackages tend to 
require each other, so the recursive query for one of them will likely be 
included in another).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Adam Williamson]

On Sat, 2022-07-23 at 11:09 +0100, Richard W.M. Jones wrote:
> 
> > qemu-2:7.0.0-6.fc37.src
> 
> I looked at the qemu sources and I can't see where they need pcre (or
> pcre2 for that matter) ...  So I've no idea why the spec file
> BuildRequires pcre-static.

Behold, the glory of git:

[adamw@xps13k qemu (f36 %)]$ git log -S'pcre-static' --oneline --name-status
0835325 Introduce qemu-user-static sub-RPM
M   qemu.spec
[adamw@xps13k qemu (f36 %)]$ git show 0835325
commit 0835325a86f807126145e310f014deb21ffb9207
Author: Daniel P. Berrange 
Date:   Wed Jul 13 13:42:21 2016 +0100

Introduce qemu-user-static sub-RPM

The i686 build of this is temp disabled due to fubar
glibc-static on i686

The hardended build macro is disabled due to fubar
rpm macros for static linking while hardened, but
the equivalent hardening is turned on manually.

Signed-off-by: Daniel P. Berrange 

diff --git a/qemu.spec b/qemu.spec
index 2e81028..59b968e 100644
--- a/qemu.spec
+++ b/qemu.spec
@@ -21,6 +21,13 @@
 %global kvm_package   system-aarch64
 %endif
 
+%global user_static 1
+# glibc static libs are fubar on i386
+# https://bugzilla.redhat.com/show_bug.cgi?id=1352625
+%ifarch %{?ix86}
+%global user_static 0
+%endif
+
 %global have_kvm 0
 %if 0%{?kvm_package:1}
 %global have_kvm 1
@@ -38,6 +45,10 @@
 %global have_xen 1
 %endif

+# Temp hack for https://bugzilla.redhat.com/show_bug.cgi?id=1343892
+# We'll manually turn on hardened build later in this spec
+%undefine _hardened_build
+
 # Release candidate version tracking
 # global rcver rc5
 %if 0%{?rcver:1}
@@ -49,7 +60,7 @@
 Summary: QEMU is a FAST! processor emulator
 Name: qemu
 Version: 2.6.0
-Release: 4%{?rcrel}%{?dist}
+Release: 5%{?rcrel}%{?dist}
 Epoch: 2
 License: GPLv2+ and LGPLv2+ and BSD
 Group: Development/Tools
@@ -247,6 +258,8 @@ BuildRequires: virglrenderer-devel
 # qemu 2.6: Needed for gtk GL support
 BuildRequires: mesa-libgbm-devel
 
+BuildRequires: glibc-static pcre-static glib2-static zlib-static
...

This of course begs a question: did qemu also have a non-static pcre
requirement at the time? But it seems not:

[adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre
BuildRequires: glibc-static pcre-static glib2-static zlib-static

so, I'm not sure why Daniel concluded this needs a BuildRequires on
pcre-static, but the obvious thing to do would be to ask him, I guess.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Retiring the pcre package from Fedora

[Neal Gompa]

On Fri, Jul 22, 2022 at 3:28 PM Richard W.M. Jones  wrote:
>
> On Fri, Jul 22, 2022 at 02:24:00PM +0200, Lukas Javorsky wrote:
> > perl
>
> Wait what, Perl _depends_ on PCRE ...?!
>

Uhh?

I don't see any direct PCRE dependency in the package spec or
generated packages...?

But yeah, that one is super-weird, given... well... it's *Perl*.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Richard W.M. Jones]

On Fri, Jul 22, 2022 at 10:24:08PM +0200, Fabio Valentini wrote:
> -> pcre or any of its subpackages are BuildRequired by:
> 
[...]
> ocaml-pcre-0:7.5.0-6.fc37.src

So two OCaml packages need this:

coccinelle
  -> https://sympa.inria.fr/sympa/arc/cocci/2022-07/msg00026.html
 (scroll down a bit)
TL;DR is we'll probably disable the dep if pcre goes away in Fedora.

ocaml-ocamlnet

This enables a small corner feature which we can probably disable.

> qemu-2:7.0.0-6.fc37.src

I looked at the qemu sources and I can't see where they need pcre (or
pcre2 for that matter) ...  So I've no idea why the spec file
BuildRequires pcre-static.

> virt-p2v-1:1.42.1-1.fc37.src

This is a real one.  virt-p2v uses a small library called "miniexpect"
which is based on pcre but needs to be ported to pcre2.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Vitaly Zaitsev via devel]

On 22/07/2022 14:24, Lukas Javorsky wrote:
As from the pcre-8.45, the upstream stopped supporting this library. The 
recommended procedure is to switch onto the new pcre2 library that has 
full upstream support. [1]


Feel free to transfer this package to me. FAS: xvitaly

I will continue maintenance in downstream.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Kevin Kofler via devel]

Fabio Valentini wrote:
> It would be entirely possible to mark the package as deprecated, but
> also give it to new maintainers.

Why not leave the decision to the new maintainers then?

I do not see a good reason to prevent adding software depending on pcre (1) 
as long as somebody maintains pcre (1) in Fedora and is willing to apply 
security patches when needed.

Considering that it is far from a drop-in replacement, whether to move a 
dependent package to pcre2 is ultimately an upstream decision, not a Fedora 
one. Hence, declaring pcre (1) off-limits means that maintainers can be 
effectively blocked by policy from importing upstream software that is not 
yet packaged in Fedora.

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

Re: Retiring the pcre package from Fedora

[Fabio Valentini]

On Sat, Jul 23, 2022 at 12:23 AM Kevin Kofler via devel
 wrote:
>
> Fabio Valentini wrote:
> > Given that there's a very long list of affected packages, just
> > dropping the package in a few weeks would have disastrous effects on
> > Fedora.
> > I also see core components of several Editions and Spins on that list,
> > so I assume just dropping pcre would also make QA, Release
> > Engineering, and various Spin manitainers very sad.
>
> So far, I agree, but:
>
> > I would ask you that instead of retiring the package in a few weeks,
> > you go through the "proper process" for changes like this.
> > That would probably involve steps similar to these:
> >
> > - announce an official deprecation with Fedora 37 (Self-Contained
> > Change proposal)
> > - mark all pcre packages as deprecated
> > - help other packagers with porting software to pcre2
> > - announce official removal of pcre with Fedora 38 (or 39, or later,
> > whenever dropping it would not implode several deliverables of Fedora;
> > another Change proposal)
> > - actual removal of the package according to schedule laid out in the
> > previous step
>
> I do not agree with that process proposal. In fact, I object to the library
> deprecation process as a whole, because it actually prevents people willing
> to maintain an old library in Fedora from picking up maintenance. Processes
> should never block volunteers from doing the work they sign up to do for
> free.

I'm not sure why deprecating a package would prevent people from working on it?
The only thing that changes by officially deprecating X is that no new
packages are allowed into Fedora that still depend on X.

> Instead, I am going to say the same thing I always say when people want to
> retire a package directly: Please just orphan it instead. Then either
> somebody else will take care of the package, or it will eventually
> automatically get retired. In this case, it is quite likely that it will be
> taken up. (In fact, if nobody else does, I will probably have to take it
> because kdelibs3 and kdelibs 4 depend on it.)

This sounds like you're mixing up two different things here:
1) Whether the package should be marked as "deprecated", and
2) whether the current maintainers will continue maintaining the
package, or if somebody else will pick it up.

Those are, while not entirely independent of each other, separate
considerations.
It would be entirely possible to mark the package as deprecated, but
also give it to new maintainers.

That would give packages that still require pcre time to migrate,
while also preventing new things that depend on pcre from being added.
Whether those new pcre maintainers then decide to retire the package a
few years in the future will be their decision.

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

Re: repoquery-fu (was Re: Retiring the pcre package from Fedora)

[Fabio Valentini]

On Fri, Jul 22, 2022 at 11:47 PM Maxwell G  wrote:
>
> On 22/07/22 10:24PM, Fabio Valentini wrote:
> > the script that determines leaf packages in the Rust SIG
>
> Can you provide a link to this?

I can, now that I've published it (again):
https://pagure.io/ironthree/fedora-rust-sig-leaf-check

It's based on the scripts that I used for analyzing the Java stack
back in the Stewardship SIG / java-maint-sig times, which I've
continued to improve over time.
As far as I know, the results it produces are now 100% correct (at
least only considering the fedora repositories that match the host
machine's architecture).

> It's actually possible to pass --whatrequires mutliple times with all of
> the dependencies, instead of running multiple queries. e.g.:
>
> sudo dnf repoquery --whatrequires pcre --whatrequires pcre-cpp --whatrequires 
> pcre-devel --whatrequires pcre-static --whatrequires pcre-tools 
> --whatrequires pcre-utf16 --repo=rawhide{,-source} -q | grep '\.src$' | sort 
> | uniq
>
> This is quite a bit faster. I only just recently learned this, so I
> thought I'd pass it on :).

Oh, good to know. Not sure if I can incorporate this into my scripts
though, because they calculate dependency trees with single-package
granularity.

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

Re: Retiring the pcre package from Fedora

[Kevin Kofler via devel]

Fabio Valentini wrote:
> Given that there's a very long list of affected packages, just
> dropping the package in a few weeks would have disastrous effects on
> Fedora.
> I also see core components of several Editions and Spins on that list,
> so I assume just dropping pcre would also make QA, Release
> Engineering, and various Spin manitainers very sad.

So far, I agree, but:

> I would ask you that instead of retiring the package in a few weeks,
> you go through the "proper process" for changes like this.
> That would probably involve steps similar to these:
> 
> - announce an official deprecation with Fedora 37 (Self-Contained
> Change proposal)
> - mark all pcre packages as deprecated
> - help other packagers with porting software to pcre2
> - announce official removal of pcre with Fedora 38 (or 39, or later,
> whenever dropping it would not implode several deliverables of Fedora;
> another Change proposal)
> - actual removal of the package according to schedule laid out in the
> previous step

I do not agree with that process proposal. In fact, I object to the library 
deprecation process as a whole, because it actually prevents people willing 
to maintain an old library in Fedora from picking up maintenance. Processes 
should never block volunteers from doing the work they sign up to do for 
free.

Instead, I am going to say the same thing I always say when people want to 
retire a package directly: Please just orphan it instead. Then either 
somebody else will take care of the package, or it will eventually 
automatically get retired. In this case, it is quite likely that it will be 
taken up. (In fact, if nobody else does, I will probably have to take it 
because kdelibs3 and kdelibs 4 depend on it.)

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

Re: Retiring the pcre package from Fedora

[Maxwell G via devel]

(It seems my previous message didn't send properly...)


On 22/07/22 10:24PM, Fabio Valentini wrote:
> the script that determines leaf packages in the Rust SIG

Can you provide a link to this?

> $ (dnf repoquery --whatrequires pcre ; dnf repoquery --whatrequires
> pcre-cpp ; dnf repoquery --whatrequires pcre-devel ; dnf repoquery
> --whatrequires pcre-static ; dnf repoquery --whatrequires pcre-tools ;
> dnf repoquery --whatrequires pcre-utf16 ; dnf repoquery --whatrequires
> pcre-utf32) | sort | uniq | grep src

It's actually possible to pass --whatrequires mutliple times with all of
the dependencies, instead of running multiple queries. e.g.:

sudo dnf repoquery --whatrequires pcre --whatrequires pcre-cpp --whatrequires 
pcre-devel --whatrequires pcre-static --whatrequires pcre-tools --whatrequires 
pcre-utf16 --repo=rawhide{,-source} -q | grep '\.src$' | sort | uniq

This is quite a bit faster. I only just recently learned this, so I
thought I'd pass it on :).

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


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

repoquery-fu (was Re: Retiring the pcre package from Fedora)

[Maxwell G via devel]

On 22/07/22 10:24PM, Fabio Valentini wrote:
> the script that determines leaf packages in the Rust SIG

Can you provide a link to this?

> $ (dnf repoquery --whatrequires pcre ; dnf repoquery --whatrequires
> pcre-cpp ; dnf repoquery --whatrequires pcre-devel ; dnf repoquery
> --whatrequires pcre-static ; dnf repoquery --whatrequires pcre-tools ;
> dnf repoquery --whatrequires pcre-utf16 ; dnf repoquery --whatrequires
> pcre-utf32) | sort | uniq | grep src

It's actually possible to pass --whatrequires mutliple times with all of
the dependencies, instead of running multiple queries. e.g.:

sudo dnf repoquery --whatrequires pcre --whatrequires pcre-cpp --whatrequires 
pcre-devel --whatrequires pcre-static --whatrequires pcre-tools --whatrequires 
pcre-utf16 --repo=rawhide{,-source} -q | grep '\.src$' | sort | uniq

This is quite a bit faster. I only just recently learned this, so I
thought I'd pass it on :).

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


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

Re: Retiring the pcre package from Fedora

[Dan Čermák]

Hi,

Lukas Javorsky  writes:

> i3
> i3-gaps

there is a patch to make i3 (and thus i3-gaps) compatible with pcre2 [1],
which has been merged upstream. I can cherry pick it and rebuild i3 in
Rawhide without requiring pcre, if this is urgent. Otherwise I'd rather
wait for the next upstream release.


Cheers,

Dan

Footnotes:
[1]  https://github.com/i3/i3/pull/4684
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Emmanuel Seyman]

* Lukas Javorsky [22/07/2022 14:24] :
>
> perl-HTML-Template-Pro

I'll build against pcre2 in the coming days (probably this weekend).

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

Re: Retiring the pcre package from Fedora

[Richard W.M. Jones]

On Fri, Jul 22, 2022 at 08:24:32AM -0500, Richard Shaw wrote:
> On Fri, Jul 22, 2022 at 8:22 AM Lukas Javorsky  wrote:
> 
> Thanks for all of the replies,
> 
> The list of affected packages I've provided was generated using the 'dnf
> repoquery --alldeps --whatrequires pcre'
> Is this command giving the right output or should I use another? If so
> which one?
> 
> 
> This is the list I generated based on the actual provides of the pcre package:
[...]

I think your query was wrong.  ocaml-pcre ought to be in this list but
was not:

$ rpm -qR ocaml-pcre | grep libpcre
libpcre.so.1()(64bit)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Richard W.M. Jones]

On Fri, Jul 22, 2022 at 02:24:00PM +0200, Lukas Javorsky wrote:
> coccinelle

This is an optional dependency but we'd lose a particular feature by
disabling it.  I have asked upstream if they plan to port to PCRE2.
Also the OCaml bindings they are using for regexps don't support PCRE2
(see below).

> haxe
> nekovm

Some work, but incomplete:
https://github.com/HaxeFoundation/haxe/issues/10491

> ocaml-pcre

Requested, but not started:
https://github.com/mmottl/pcre-ocaml/issues/25

> perl

Wait what, Perl _depends_ on PCRE ...?!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Petr Pisar]

V Fri, Jul 22, 2022 at 03:21:02PM +0200, Lukas Javorsky napsal(a):
> The list of affected packages I've provided was generated using the 'dnf
> repoquery --alldeps --whatrequires pcre'
>
> Is this command giving the right output or should I use another? If so
> which one?
> 
If I run your command on current F37 Koji build root, I don't get perl. Only
3 packages written in Perl. Normally I would blame an outdated repository, but
perl has never required pcre. Therefore my question. My only explanation is
a cut-and-paste mistake.

That command needs to be applied to all subpackages of pcre source package.
E.g. pcre-utf16 adds "sigil" to a heap of affected packages.

No command is universally good, because it always depends on what you want to
get.  Recently there was a thread discussing these queries at length.

I think your command is good enough to get a quite accurate view on the
affected packages. I would only apply --srpm option to see components instead
of binary packages.

Then the list shrinks to managable 105 components. That's not so much. Of
course there are some high-profile componentes like grep, 389-ds-base, swig,
kdelibs, postfix, and swig. And some of them will be very expensive to port
(either because they use pcre extensively, or abuses a private API, or the
code is simply too old and nobody wants to touch it), but that's a life and
I think with help by their maintainers and upstreams, it's not impossible. Of
course not in a month until F37. It will require some time.

More disappointing is a majority of niche components whose upstream is dead or
not motivated to port. Those will need to go. A problem of pcre is that it's
too good. Applications which do not need a thread safety, latest Unicode
features, or few per cents of performance, won't see a benefit in the port.

-- Petr



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

Re: Retiring the pcre package from Fedora

[Daniel P . Berrangé]

On Fri, Jul 22, 2022 at 03:21:02PM +0200, Lukas Javorsky wrote:
> Thanks for all of the replies,
> 
> The list of affected packages I've provided was generated using the 'dnf
> repoquery --alldeps --whatrequires pcre'
> Is this command giving the right output or should I use another? If so
> which one?

It depends on what your question is. That will give you first level
dependancies. That's already a long list of packages, but when you
then compute the transitive dependencies from that set, you'll end
up with an enourmous list that looks like it would make Fedora
almost entirely unusable if broken by removal of pcre.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

Thanks for all of the replies,

The list of affected packages I've provided was generated using the 'dnf
repoquery --alldeps --whatrequires pcre'
Is this command giving the right output or should I use another? If so
which one?

We will definitely discuss all of these concerns within the team and get
you a response as soon as possible.

The purpose of this wasn't to break anything, so if it's required to do it
in more steps, I'm more than happy to do it right.


On Fri, Jul 22, 2022 at 3:16 PM Ben Cotton  wrote:

> On Fri, Jul 22, 2022 at 8:25 AM Lukas Javorsky 
> wrote:
> >
> > As a result of this announcement, the older PCRE library in Fedora will
> be retired.
> > Without upstream support, we don't have enough capacity to keep up with
> the security and bugs-related issues, and thus we will support only the new
> PCRE2 library. [2]
>
> I understand the burden and I fully support you dropping this. But I
> agree with decathorpe that this needs to be a two-stage approach, with
> deprecation in F37 and removal in F38 or beyond. Retiring the package
> in the upcoming weeks will be incredibly disruptive, especially since
> the Beta freeze begins in a month.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/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

ljavo...@redhat.com

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

Re: Retiring the pcre package from Fedora

[Ben Cotton]

On Fri, Jul 22, 2022 at 8:25 AM Lukas Javorsky  wrote:
>
> As a result of this announcement, the older PCRE library in Fedora will be 
> retired.
> Without upstream support, we don't have enough capacity to keep up with the 
> security and bugs-related issues, and thus we will support only the new PCRE2 
> library. [2]

I understand the burden and I fully support you dropping this. But I
agree with decathorpe that this needs to be a two-stage approach, with
deprecation in F37 and removal in F38 or beyond. Retiring the package
in the upcoming weeks will be incredibly disruptive, especially since
the Beta freeze begins in a month.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Vitaly Zaitsev via devel]

On 22/07/2022 14:24, Lukas Javorsky wrote:

As from the pcre-8.45, the upstream stopped supporting this library.


If it builds from sources we can maintain it in downstream due to a big 
number of dependent packages.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Fabio Valentini]

On Fri, Jul 22, 2022 at 2:25 PM Lukas Javorsky  wrote:
>
> Hi,
>
> As from the pcre-8.45, the upstream stopped supporting this library. The 
> recommended procedure is to switch onto the new pcre2 library that has full 
> upstream support. [1]
>
> As a result of this announcement, the older PCRE library in Fedora will be 
> retired.

Given that there's a very long list of affected packages, just
dropping the package in a few weeks would have disastrous effects on
Fedora.
I also see core components of several Editions and Spins on that list,
so I assume just dropping pcre would also make QA, Release
Engineering, and various Spin manitainers very sad.

I would ask you that instead of retiring the package in a few weeks,
you go through the "proper process" for changes like this.
That would probably involve steps similar to these:

- announce an official deprecation with Fedora 37 (Self-Contained
Change proposal)
- mark all pcre packages as deprecated
- help other packagers with porting software to pcre2
- announce official removal of pcre with Fedora 38 (or 39, or later,
whenever dropping it would not implode several deliverables of Fedora;
another Change proposal)
- actual removal of the package according to schedule laid out in the
previous step

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

Re: Retiring the pcre package from Fedora

[Petr Pisar]

V Fri, Jul 22, 2022 at 02:24:00PM +0200, Lukas Javorsky napsal(a):
> As from the pcre-8.45, the upstream stopped supporting this library. The
> recommended procedure is to switch onto the new pcre2 library that has full
> upstream support. [1]
> 
> As a result of this announcement, the older PCRE library in Fedora will be
> retired.
> Without upstream support, we don't have enough capacity to keep up with the
> security and bugs-related issues, and thus we will support only the new
> PCRE2 library. [2]
> 
> The retirement procedure will happen in the upcoming weeks, so if you would
> like to take over the package let us know.
> 
> 
> The list of affected packages:
> 389-ds-base
> 389-ds-base-libs
> EMBOSS-libs
[...]
> perl

I'm not sure what "affected" means here, but e.g. perl has no direct
dependency on pcre. Maybe your computation is not correct.

-- Petr



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

Retiring the pcre package from Fedora

[Lukas Javorsky]

Hi,

As from the pcre-8.45, the upstream stopped supporting this library. The
recommended procedure is to switch onto the new pcre2 library that has full
upstream support. [1]

As a result of this announcement, the older PCRE library in Fedora will be
retired.
Without upstream support, we don't have enough capacity to keep up with the
security and bugs-related issues, and thus we will support only the new
PCRE2 library. [2]

The retirement procedure will happen in the upcoming weeks, so if you would
like to take over the package let us know.


The list of affected packages:
389-ds-base
389-ds-base-libs
EMBOSS-libs
Falcon
GMT
Io-language
Thunar
adanaxisgpl
aide
aircrack-ng
anope-pcre
bti
ccze
cegui
cegui06
clisp
clover2
clover2-devel
clover2-libs
coccinelle
compton
condor
condor-classads
cppcheck
cppcheck-gui
cyrus-imapd-libs
eterm
ettercap
freeradius
freeradius-utils
ganglia
ganglia-gmond
ghc-highlighting-kate
ghc-pcre-light
ghc-regex-pcre
gnome-builder
gnome-text-editor
grep
groonga-httpd
haxe
hydra
i3
i3-gaps
imapfilter
kdelibs
kdelibs3
kf5-kjs
kismet
libast
libeplplot
liblognorm
libmodsecurity
libprelude
lnav
mle
mod_auth_openid
mod_auth_openidc
mod_qos
mod_security
mod_security-mlogc
monotone
ncid
nekovm
ngrep
nmap
ocaml-pcre
octave
openCOLLADA
openscap
openscap-engine-sce
opensips
opensips-regex
pads
pcre-cpp
pdfgrep
perl
perl-HTML-Template-Pro
perl-re-engine-PCRE
picom
pl
poco-debug
poco-foundation
postfix-pcre
powwow
prboom-plus
prelude-lml
privoxy
python3-qutepart
python3-scss
rasqal
regexxer
remctl
root-core
rudiments
slang-slsh
sord
sslh
suricata
sway
swig
syncevolution-libs
syncevolution-libs-akonadi
syslog-ng
syslog-ng-mqtt
syslog-ng-slog
the_foundation
the_silver_searcher
tin
tintin
tinyfugue
trafficserver
uwsgi
vdr-epgfixer
watchman
wmweather+
xastir
xfce4-verve-plugin
xgrep
xmlcopyeditor
zabbix
zabbix-agent
zabbix-proxy-mysql
zabbix-proxy-pgsql
zabbix-proxy-sqlite3
zabbix-server-mysql
zabbix-server-pgsql
zsh

---

Thank you for understanding.
Lukas

[1] https://www.pcre.org/
[2] https://github.com/PCRE2Project/pcre2
-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

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