7:24 a.m.
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 <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
7:52 a.m.
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
7:53 a.m.
On Fri, Jul 22, 2022 at 2:25 PM Lukas Javorsky <ljavorsk(a)redhat.com> 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
8:15 a.m.
On Fri, Jul 22, 2022 at 8:25 AM Lukas Javorsky <ljavorsk(a)redhat.com> 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
8:20 a.m.
On Fri, Jul 22, 2022 at 7:25 AM Lukas Javorsky <ljavorsk(a)redhat.com> 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]
Is it possible that many (most?) packages can already build with pcre2 and
just need the BR's updated?
Thanks,
Richard
8:21 a.m.
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 <bcotton(a)redhat.com> wrote:
On Fri, Jul 22, 2022 at 8:25 AM Lukas Javorsky
<ljavorsk(a)redhat.com>
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
8:24 a.m.
On Fri, Jul 22, 2022 at 8:22 AM Lukas Javorsky <ljavorsk(a)redhat.com> 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:
389-ds-base
adanaxisgpl
aide
aircrack-ng
anope
bti
ccze
cegui
cegui06
clisp
clover2
coccinelle
compton
condor
cppcheck
cyrus-imapd
EMBOSS
eterm
ettercap
Falcon
freeradius
ganglia
ghc-highlighting-kate
GMT
gnome-builder
gnome-text-editor
grep
groonga
haxe
hydra
i3
i3-gaps
imapfilter
Io-language
kdelibs
kdelibs3
kf5-kjs
kismet
libast
liblognorm
libmodsecurity
libprelude
lnav
mle
mod_auth_openid
mod_auth_openidc
mod_qos
mod_security
monotone
ncid
nekovm
ngrep
nmap
octave
openCOLLADA
openscap
opensips
pads
pdfgrep
perl-HTML-Template-Pro
perl-re-engine-PCRE
picom
pl
poco
postfix
powwow
prboom-plus
prelude-lml
privoxy
python-qutepart
python-scss
rasqal
regexxer
root
rudiments
slang
sord
sslh
suricata
sway
swig
syncevolution
syslog-ng
the_foundation
the_silver_searcher
Thunar
tin
tintin
tinyfugue
trafficserver
uwsgi
vdr-epgfixer
watchman
wmweather+
xastir
xfce4-verve-plugin
xgrep
xmlcopyeditor
zabbix
zsh
Thanks,
Richard
8:28 a.m.
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 :|
11:52 a.m.
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
2:28 p.m.
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
2:31 p.m.
On Fri, Jul 22, 2022 at 08:24:32AM -0500, Richard Shaw wrote:
On Fri, Jul 22, 2022 at 8:22 AM Lukas Javorsky
<ljavorsk(a)redhat.com> 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
2:42 p.m.
On Fri, Jul 22, 2022 at 2:32 PM Richard W.M. Jones <rjones(a)redhat.com>
wrote:
On Fri, Jul 22, 2022 at 08:24:32AM -0500, Richard Shaw wrote:
> On Fri, Jul 22, 2022 at 8:22 AM Lukas Javorsky <ljavorsk(a)redhat.com>
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)
Ahh... My script tried to remove self deps but it needs to be tweaked for
only exact matches:
# Remove the packages being checked
for pkgname in "$@"; do
sed -i "/$pkgname/d" needs_rebuilding
done
Thanks,
Richard
3:24 p.m.
On Fri, Jul 22, 2022 at 9:44 PM Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Fri, Jul 22, 2022 at 2:32 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:
>
> On Fri, Jul 22, 2022 at 08:24:32AM -0500, Richard Shaw wrote:
> > On Fri, Jul 22, 2022 at 8:22 AM Lukas Javorsky <ljavorsk(a)redhat.com>
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)
Ahh... My script tried to remove self deps but it needs to be tweaked for only exact
matches:
Ok, it seems there's still confusion about how to calculate direct
dependencies correctly.
According to my best repoquery-fu (which also powers different
"official" scripts I use for various purposes, i.e. the script that
determines leaf packages in the Rust SIG), this is the "correct"
(AFAIK) list of dependent packages for pcre, based on:
$ repoquery --provides pcre.src
pcre = 8.45-1.fc36.1
pcre-cpp = 8.45-1.fc36.1
pcre-debuginfo = 8.45-1.fc36.1
pcre-debugsource = 8.45-1.fc36.1
pcre-devel = 8.45-1.fc36.1
pcre-doc = 8.45-1.fc36.1
pcre-static = 8.45-1.fc36.1
pcre-tools = 8.45-1.fc36.1
pcre-utf16 = 8.45-1.fc36.1
pcre-utf32 = 8.45-1.fc36.1
(I'm not considering pcre-doc and -debug* here, because I assume
nothing depends on the *docs*).
$ (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
-> pcre or any of its subpackages are BuildRequired by:
389-ds-base-0:2.2.2-1.fc37.src
adanaxisgpl-0:1.2.5-42.fc37.src
aide-0:0.16-19.fc36.src
aircrack-ng-0:1.7-1.fc37.src
anope-0:2.0.10-5.fc37.src
apachetop-0:0.19.7-7.fc36.src
bigloo-0:4.4c-5.4.fc37.src
blender-1:3.2.1-2.fc37.src
bti-0:034-24.fc36.src
ccze-0:0.2.1-28.fc36.src
cegui-0:0.8.7-24.fc37.src
cegui06-0:0.6.2-38.fc37.src
clamav-0:0.103.6-1.fc37.src
ClanLib-0:2.3.7-25.fc36.src
clisp-0:2.49.93-23.20210628gitde01f0f.fc36.src
clover2-0:10.4.6-9.D20190613git6f483b4.fc36.src
collada-dom-0:2.5.0-21.fc37.src
compton-0:0.1-0.11.beta3.fc36.src
condor-0:8.8.15-7.fc37.src
cppcheck-0:2.8.2-1.fc37.src
deepin-file-manager-0:5.6.4-1.fc37.src
dogtag-pki-0:11.2.0-1.fc37.src
eiskaltdcpp-0:2.4.2-6.fc37.src
EMBOSS-0:6.6.0-20.fc36.src
eterm-0:0.9.6-28.fc36.src
ettercap-0:0.8.3.1-6.fc36.src
Falcon-0:0.9.6.8-24.fc36.src
freeradius-0:3.2.0-1.fc37.src
gambas3-0:3.17.2-1.fc37.src
ganglia-0:3.7.2-38.fc36.src
ghc-pcre-light-0:0.4.1.0-9.fc37.src
ghc-regex-pcre-0:0.95.0.0-8.fc37.src
GMT-0:6.4.0-1.fc37.src
gnome-builder-0:42.1-2.fc37.src
gnome-text-editor-0:43~alpha0-1.fc37.src
gnote-0:42.0-1.fc37.src
golang-0:1.19~rc2-1.fc37.src
gource-0:0.53-2.fc37.src
grep-0:3.7-2.fc36.src
groonga-0:10.0.8-5.fc36.src
gsmartcontrol-0:1.1.4-1.fc37.src
haxe-0:4.2.5-2.fc37.src
hydra-0:9.2-7.fc37.src
hyperscan-0:5.4.0-4.fc36.src
i3-0:4.20.1-4.fc37.src
i3-gaps-0:4.20.1-2.fc37.src
imapfilter-0:2.6.15-7.fc36.src
Io-language-0:20170906-5.fc37.src
kdelibs3-0:3.5.10-116.fc37.src
kdelibs-6:4.14.38-34.fc37.src
kdevelop-9:22.04.3-1.fc37.src
kf5-kjs-0:5.96.0-1.fc37.src
kf5-kplotting-0:5.96.0-1.fc37.src
kismet-0:0.0.2022.02.R1-2.fc37.src
libast-0:0.7.1-0.30.20080502cvs.fc36.src
liblognorm-0:2.0.6-4.fc37.src
libmodsecurity-0:3.0.4-6.fc36.src
lnav-0:0.10.1-3.fc37.src
logstalgia-0:1.1.3-1.fc37.src
lumail-0:3.1-11.fc36.src
medusa-0:2.2-19.20181216git292193b.fc36.src
mle-0:1.5.0-1.fc37.src
mod_auth_openid-0:0.8-18.fc36.src
mod_auth_openidc-0:2.4.11.2-1.fc37.src
mod_qos-0:11.70-1.fc36.src
mod_security-0:2.9.4-2.fc36.src
mod_security3-0:0.0.9-0.20210819git0488c77.1.fc36.1.src
monotone-0:1.1-43.fc37.src
ncid-0:1.13-3.fc37.src
nekovm-0:2.3.0-9.fc36.src
ngrep-0:1.47-8.1.20180101git9b59468.fc36.src
nmap-3:7.92-4.fc37.src
ocaml-pcre-0:7.5.0-6.fc37.src
oci-umount-2:2.5-8.gitc3cda1f.fc36.src
octave-6:7.1.0-2.fc37.src
openCOLLADA-0:1.6.70-1.fc36.src
openscap-1:1.3.6-9.fc37.src
opensips-0:3.3.0-1.fc37.src
pads-0:1.2-33.fc36.src
pdfgrep-0:2.1.2-9.fc36.src
perl-HTML-Template-Pro-0:0.9524-2.fc37.src
perl-re-engine-PCRE-0:0.17-32.fc37.src
petsc-0:3.17.3-2.fc37.src
php-pecl-apcu-0:5.1.21-3.fc36.src
php-pecl-http-0:4.2.3-1.fc37.src
php-pecl-oauth-0:2.0.7-6.fc36.src
picom-0:9.1-1.fc37.src
pl-0:8.4.3-2.fc37.src
poco-0:1.11.2-7.fc37.src
postfix-2:3.7.2-1.fc37.src
postgis-0:3.2.1-3.fc37.src
powwow-0:1.2.23-2.fc36.src
prboom-plus-0:2.6.2-1.fc37.src
prelude-lml-0:5.2.0-7.fc35.src
privoxy-0:3.0.33-2.fc36.src
proftpd-0:1.3.7d-1.fc37.src
proxysql-0:2.3.2-4.fc37.src
python-qutepart-0:3.3.2-3.fc37.src
python-scss-0:1.3.7-8.fc37.src
qemu-2:7.0.0-6.fc37.src
qpdf-0:10.6.3-2.fc37.src
qt5-qtbase-0:5.15.5-1.fc37.src
qt6-qtbase-0:6.3.1-1.fc37.src
qtwebkit-0:2.3.4-36.fc36.src
R-0:4.1.3-1.fc37.src
rasqal-0:0.9.33-18.fc36.src
regexxer-0:0.9-31.fc36.src
remctl-0:3.18-1.fc37.src
renderdoc-0:1.17-2.fc36.src
rkward-0:0.7.2-6.fc36.src
root-0:6.26.04-4.fc37.src
rudiments-0:1.3.1-4.fc36.src
sigil-0:0.9.14-12.fc36.src
slang-0:2.3.2-11.fc36.src
sslh-0:1.21c-4.fc36.src
suricata-0:6.0.6-1.fc37.src
sway-0:1.7-2.fc37.src
swig-0:4.0.2-16.fc37.src
syncevolution-1:2.0.0-4.fc37.src
syslog-ng-0:3.35.1-4.fc37.src
the_foundation-0:1.4.0-1.fc37.src
the_silver_searcher-0:2.2.0^2020704.5a1c8d8-4.fc36.src
Thunar-0:4.16.11-1.fc37.src
tin-0:2.6.1-2.fc36.src
tintin-0:2.02.05-4.fc36.src
tinyfugue-0:5.0-0.104.b8.fc36.src
trafficserver-0:9.1.2-9.fc37.src
uwsgi-0:2.0.20-7.fc37.src
vdr-epgfixer-0:0.3.1-21.20180416git354f28b.fc36.src
virt-p2v-1:1.42.1-1.fc37.src
watchman-0:2021.05.10.00-14.fc37.src
webkit2gtk3-0:2.37.1-7.fc37.src
wireshark-1:3.6.2-1.fc37.src
wmweather+-0:2.17-12.fc36.src
xastir-1:2.1.4-12.fc36.src
xfce4-verve-plugin-0:2.0.1-4.fc36.src
xgrep-0:0.08-17.fc36.src
xmlcopyeditor-0:1.2.1.3-18.fc36.src
yara-0:4.2.2-1.fc37.src
zabbix-1:6.0.6-1.fc37.src
zsh-0:5.9-1.fc37.src
$ (dnfraw repoquery --whatrequires pcre --source ; dnfraw repoquery
--whatrequires pcre-cpp --source ; dnfraw repoquery --whatrequires
pcre-devel --source ; dnfraw repoquery --whatrequires pcre-static
--source ; dnfraw repoquery --whatrequires pcre-tools --source ;
dnfraw repoquery --whatrequires pcre-utf16 --source ; dnfraw repoquery
--whatrequires pcre-utf32 --source) | sort | uniq
-> pcre or any of its subpackages are Required by binary packages
built from these source packages:
ocaml-pcre-7.5.0-6.fc37.src.rpm
octave-7.1.0-2.fc37.src.rpm
openCOLLADA-1.6.70-1.fc36.src.rpm
openscap-1.3.6-9.fc37.src.rpm
opensips-3.3.0-1.fc37.src.rpm
pads-1.2-33.fc36.src.rpm
pcre-8.45-1.fc36.1.src.rpm
pdfgrep-2.1.2-9.fc36.src.rpm
perl-HTML-Template-Pro-0.9524-2.fc37.src.rpm
perl-re-engine-PCRE-0.17-32.fc37.src.rpm
picom-9.1-1.fc37.src.rpm
pl-8.4.3-2.fc37.src.rpm
poco-1.11.2-7.fc37.src.rpm
postfix-3.7.2-1.fc37.src.rpm
powwow-1.2.23-2.fc36.src.rpm
prboom-plus-2.6.2-1.fc37.src.rpm
prelude-lml-5.2.0-7.fc35.src.rpm
privoxy-3.0.33-2.fc36.src.rpm
proftpd-1.3.7d-1.fc37.src.rpm
proxysql-2.3.2-4.fc37.src.rpm
python-qutepart-3.3.2-3.fc37.src.rpm
python-scss-1.3.7-8.fc37.src.rpm
R-4.1.3-1.fc37.src.rpm
rasqal-0.9.33-18.fc36.src.rpm
regexxer-0.9-31.fc36.src.rpm
root-6.26.04-4.fc37.src.rpm
rudiments-1.3.1-4.fc36.src.rpm
sigil-0.9.14-12.fc36.src.rpm
slang-2.3.2-11.fc36.src.rpm
sord-0.16.10-1.fc37.src.rpm
sslh-1.21c-4.fc36.src.rpm
suricata-6.0.6-1.fc37.src.rpm
sway-1.7-2.fc37.src.rpm
swig-4.0.2-16.fc37.src.rpm
syncevolution-2.0.0-4.fc37.src.rpm
syslog-ng-3.35.1-4.fc37.src.rpm
the_foundation-1.4.0-1.fc37.src.rpm
the_silver_searcher-2.2.0^2020704.5a1c8d8-4.fc36.src.rpm
Thunar-4.16.11-1.fc37.src.rpm
tin-2.6.1-2.fc36.src.rpm
tintin-2.02.05-4.fc36.src.rpm
tinyfugue-5.0-0.104.b8.fc36.src.rpm
trafficserver-9.1.2-9.fc37.src.rpm
uwsgi-2.0.20-7.fc37.src.rpm
vdr-epgfixer-0.3.1-21.20180416git354f28b.fc36.src.rpm
watchman-2021.05.10.00-14.fc37.src.rpm
wmweather+-2.17-12.fc36.src.rpm
xastir-2.1.4-12.fc36.src.rpm
xfce4-verve-plugin-2.0.1-4.fc36.src.rpm
xgrep-0.08-17.fc36.src.rpm
xmlcopyeditor-1.2.1.3-18.fc36.src.rpm
zabbix-6.0.6-1.fc37.src.rpm
zsh-5.9-1.fc37.src.rpm
There's probably overlap between these two sets, but you need to
consider both lists to get the complete picture (i.e. both build-time
and run-time dependencies).
And it's a pretty big list either way.
Fabio
3:31 p.m.
On Fri, Jul 22, 2022 at 10:24 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Fri, Jul 22, 2022 at 9:44 PM Richard Shaw <hobbes1069(a)gmail.com> wrote:
>
> On Fri, Jul 22, 2022 at 2:32 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:
>>
>> On Fri, Jul 22, 2022 at 08:24:32AM -0500, Richard Shaw wrote:
>> > On Fri, Jul 22, 2022 at 8:22 AM Lukas Javorsky <ljavorsk(a)redhat.com>
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)
>
>
> Ahh... My script tried to remove self deps but it needs to be tweaked for only exact
matches:
Ok, it seems there's still confusion about how to calculate direct
dependencies correctly.
According to my best repoquery-fu (which also powers different
"official" scripts I use for various purposes, i.e. the script that
determines leaf packages in the Rust SIG), this is the "correct"
(AFAIK) list of dependent packages for pcre, based on:
$ repoquery --provides pcre.src
pcre = 8.45-1.fc36.1
pcre-cpp = 8.45-1.fc36.1
pcre-debuginfo = 8.45-1.fc36.1
pcre-debugsource = 8.45-1.fc36.1
pcre-devel = 8.45-1.fc36.1
pcre-doc = 8.45-1.fc36.1
pcre-static = 8.45-1.fc36.1
pcre-tools = 8.45-1.fc36.1
pcre-utf16 = 8.45-1.fc36.1
pcre-utf32 = 8.45-1.fc36.1
(I'm not considering pcre-doc and -debug* here, because I assume
nothing depends on the *docs*).
$ (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
-> pcre or any of its subpackages are BuildRequired by:
389-ds-base-0:2.2.2-1.fc37.src
adanaxisgpl-0:1.2.5-42.fc37.src
aide-0:0.16-19.fc36.src
aircrack-ng-0:1.7-1.fc37.src
anope-0:2.0.10-5.fc37.src
apachetop-0:0.19.7-7.fc36.src
bigloo-0:4.4c-5.4.fc37.src
blender-1:3.2.1-2.fc37.src
bti-0:034-24.fc36.src
ccze-0:0.2.1-28.fc36.src
cegui-0:0.8.7-24.fc37.src
cegui06-0:0.6.2-38.fc37.src
clamav-0:0.103.6-1.fc37.src
ClanLib-0:2.3.7-25.fc36.src
clisp-0:2.49.93-23.20210628gitde01f0f.fc36.src
clover2-0:10.4.6-9.D20190613git6f483b4.fc36.src
collada-dom-0:2.5.0-21.fc37.src
compton-0:0.1-0.11.beta3.fc36.src
condor-0:8.8.15-7.fc37.src
cppcheck-0:2.8.2-1.fc37.src
deepin-file-manager-0:5.6.4-1.fc37.src
dogtag-pki-0:11.2.0-1.fc37.src
eiskaltdcpp-0:2.4.2-6.fc37.src
EMBOSS-0:6.6.0-20.fc36.src
eterm-0:0.9.6-28.fc36.src
ettercap-0:0.8.3.1-6.fc36.src
Falcon-0:0.9.6.8-24.fc36.src
freeradius-0:3.2.0-1.fc37.src
gambas3-0:3.17.2-1.fc37.src
ganglia-0:3.7.2-38.fc36.src
ghc-pcre-light-0:0.4.1.0-9.fc37.src
ghc-regex-pcre-0:0.95.0.0-8.fc37.src
GMT-0:6.4.0-1.fc37.src
gnome-builder-0:42.1-2.fc37.src
gnome-text-editor-0:43~alpha0-1.fc37.src
gnote-0:42.0-1.fc37.src
golang-0:1.19~rc2-1.fc37.src
gource-0:0.53-2.fc37.src
grep-0:3.7-2.fc36.src
groonga-0:10.0.8-5.fc36.src
gsmartcontrol-0:1.1.4-1.fc37.src
haxe-0:4.2.5-2.fc37.src
hydra-0:9.2-7.fc37.src
hyperscan-0:5.4.0-4.fc36.src
i3-0:4.20.1-4.fc37.src
i3-gaps-0:4.20.1-2.fc37.src
imapfilter-0:2.6.15-7.fc36.src
Io-language-0:20170906-5.fc37.src
kdelibs3-0:3.5.10-116.fc37.src
kdelibs-6:4.14.38-34.fc37.src
kdevelop-9:22.04.3-1.fc37.src
kf5-kjs-0:5.96.0-1.fc37.src
kf5-kplotting-0:5.96.0-1.fc37.src
kismet-0:0.0.2022.02.R1-2.fc37.src
libast-0:0.7.1-0.30.20080502cvs.fc36.src
liblognorm-0:2.0.6-4.fc37.src
libmodsecurity-0:3.0.4-6.fc36.src
lnav-0:0.10.1-3.fc37.src
logstalgia-0:1.1.3-1.fc37.src
lumail-0:3.1-11.fc36.src
medusa-0:2.2-19.20181216git292193b.fc36.src
mle-0:1.5.0-1.fc37.src
mod_auth_openid-0:0.8-18.fc36.src
mod_auth_openidc-0:2.4.11.2-1.fc37.src
mod_qos-0:11.70-1.fc36.src
mod_security-0:2.9.4-2.fc36.src
mod_security3-0:0.0.9-0.20210819git0488c77.1.fc36.1.src
monotone-0:1.1-43.fc37.src
ncid-0:1.13-3.fc37.src
nekovm-0:2.3.0-9.fc36.src
ngrep-0:1.47-8.1.20180101git9b59468.fc36.src
nmap-3:7.92-4.fc37.src
ocaml-pcre-0:7.5.0-6.fc37.src
oci-umount-2:2.5-8.gitc3cda1f.fc36.src
octave-6:7.1.0-2.fc37.src
openCOLLADA-0:1.6.70-1.fc36.src
openscap-1:1.3.6-9.fc37.src
opensips-0:3.3.0-1.fc37.src
pads-0:1.2-33.fc36.src
pdfgrep-0:2.1.2-9.fc36.src
perl-HTML-Template-Pro-0:0.9524-2.fc37.src
perl-re-engine-PCRE-0:0.17-32.fc37.src
petsc-0:3.17.3-2.fc37.src
php-pecl-apcu-0:5.1.21-3.fc36.src
php-pecl-http-0:4.2.3-1.fc37.src
php-pecl-oauth-0:2.0.7-6.fc36.src
picom-0:9.1-1.fc37.src
pl-0:8.4.3-2.fc37.src
poco-0:1.11.2-7.fc37.src
postfix-2:3.7.2-1.fc37.src
postgis-0:3.2.1-3.fc37.src
powwow-0:1.2.23-2.fc36.src
prboom-plus-0:2.6.2-1.fc37.src
prelude-lml-0:5.2.0-7.fc35.src
privoxy-0:3.0.33-2.fc36.src
proftpd-0:1.3.7d-1.fc37.src
proxysql-0:2.3.2-4.fc37.src
python-qutepart-0:3.3.2-3.fc37.src
python-scss-0:1.3.7-8.fc37.src
qemu-2:7.0.0-6.fc37.src
qpdf-0:10.6.3-2.fc37.src
qt5-qtbase-0:5.15.5-1.fc37.src
qt6-qtbase-0:6.3.1-1.fc37.src
qtwebkit-0:2.3.4-36.fc36.src
R-0:4.1.3-1.fc37.src
rasqal-0:0.9.33-18.fc36.src
regexxer-0:0.9-31.fc36.src
remctl-0:3.18-1.fc37.src
renderdoc-0:1.17-2.fc36.src
rkward-0:0.7.2-6.fc36.src
root-0:6.26.04-4.fc37.src
rudiments-0:1.3.1-4.fc36.src
sigil-0:0.9.14-12.fc36.src
slang-0:2.3.2-11.fc36.src
sslh-0:1.21c-4.fc36.src
suricata-0:6.0.6-1.fc37.src
sway-0:1.7-2.fc37.src
swig-0:4.0.2-16.fc37.src
syncevolution-1:2.0.0-4.fc37.src
syslog-ng-0:3.35.1-4.fc37.src
the_foundation-0:1.4.0-1.fc37.src
the_silver_searcher-0:2.2.0^2020704.5a1c8d8-4.fc36.src
Thunar-0:4.16.11-1.fc37.src
tin-0:2.6.1-2.fc36.src
tintin-0:2.02.05-4.fc36.src
tinyfugue-0:5.0-0.104.b8.fc36.src
trafficserver-0:9.1.2-9.fc37.src
uwsgi-0:2.0.20-7.fc37.src
vdr-epgfixer-0:0.3.1-21.20180416git354f28b.fc36.src
virt-p2v-1:1.42.1-1.fc37.src
watchman-0:2021.05.10.00-14.fc37.src
webkit2gtk3-0:2.37.1-7.fc37.src
wireshark-1:3.6.2-1.fc37.src
wmweather+-0:2.17-12.fc36.src
xastir-1:2.1.4-12.fc36.src
xfce4-verve-plugin-0:2.0.1-4.fc36.src
xgrep-0:0.08-17.fc36.src
xmlcopyeditor-0:1.2.1.3-18.fc36.src
yara-0:4.2.2-1.fc37.src
zabbix-1:6.0.6-1.fc37.src
zsh-0:5.9-1.fc37.src
$ (dnfraw repoquery --whatrequires pcre --source ; dnfraw repoquery
--whatrequires pcre-cpp --source ; dnfraw repoquery --whatrequires
pcre-devel --source ; dnfraw repoquery --whatrequires pcre-static
--source ; dnfraw repoquery --whatrequires pcre-tools --source ;
dnfraw repoquery --whatrequires pcre-utf16 --source ; dnfraw repoquery
--whatrequires pcre-utf32 --source) | sort | uniq
-> pcre or any of its subpackages are Required by binary packages
built from these source packages:
Meh, copy-paste error, here's the packages A-N that were missing:
389-ds-base-2.2.2-1.fc37.src.rpm
adanaxisgpl-1.2.5-42.fc37.src.rpm
aide-0.16-19.fc36.src.rpm
aircrack-ng-1.7-1.fc37.src.rpm
anope-2.0.10-5.fc37.src.rpm
bti-034-24.fc36.src.rpm
ccze-0.2.1-28.fc36.src.rpm
cegui06-0.6.2-38.fc37.src.rpm
cegui-0.8.7-24.fc37.src.rpm
ClanLib-2.3.7-25.fc36.src.rpm
clisp-2.49.93-23.20210628gitde01f0f.fc36.src.rpm
clover2-10.4.6-9.D20190613git6f483b4.fc36.src.rpm
coccinelle-1.1.1-11.fc37.src.rpm
collada-dom-2.5.0-21.fc37.src.rpm
compton-0.1-0.11.beta3.fc36.src.rpm
condor-8.8.15-7.fc37.src.rpm
cppcheck-2.8.2-1.fc37.src.rpm
cyrus-imapd-3.4.3-1.fc37.src.rpm
eiskaltdcpp-2.4.2-6.fc37.src.rpm
EMBOSS-6.6.0-20.fc36.src.rpm
eterm-0.9.6-28.fc36.src.rpm
ettercap-0.8.3.1-6.fc36.src.rpm
Falcon-0.9.6.8-24.fc36.src.rpm
freeradius-3.2.0-1.fc37.src.rpm
ganglia-3.7.2-38.fc36.src.rpm
ghc-highlighting-kate-0.6.4-21.fc37.src.rpm
ghc-pcre-light-0.4.1.0-9.fc37.src.rpm
ghc-regex-pcre-0.95.0.0-8.fc37.src.rpm
GMT-6.4.0-1.fc37.src.rpm
gnome-builder-42.1-2.fc37.src.rpm
gnome-text-editor-43~alpha0-1.fc37.src.rpm
grep-3.7-2.fc36.src.rpm
groonga-10.0.8-5.fc36.src.rpm
gsmartcontrol-1.1.4-1.fc37.src.rpm
haxe-4.2.5-2.fc37.src.rpm
hydra-9.2-7.fc37.src.rpm
i3-4.20.1-4.fc37.src.rpm
i3-gaps-4.20.1-2.fc37.src.rpm
imapfilter-2.6.15-7.fc36.src.rpm
Io-language-20170906-5.fc37.src.rpm
kdelibs3-3.5.10-116.fc37.src.rpm
kdelibs-4.14.38-34.fc37.src.rpm
kf5-kjs-5.96.0-1.fc37.src.rpm
kismet-0.0.2022.02.R1-2.fc37.src.rpm
libast-0.7.1-0.30.20080502cvs.fc36.src.rpm
liblognorm-2.0.6-4.fc37.src.rpm
libmodsecurity-3.0.4-6.fc36.src.rpm
libprelude-5.2.0-13.fc37.src.rpm
lnav-0.10.1-3.fc37.src.rpm
lumail-3.1-11.fc36.src.rpm
mle-1.5.0-1.fc37.src.rpm
mod_auth_openid-0.8-18.fc36.src.rpm
mod_auth_openidc-2.4.11.2-1.fc37.src.rpm
mod_qos-11.70-1.fc36.src.rpm
mod_security-2.9.4-2.fc36.src.rpm
monotone-1.1-43.fc37.src.rpm
ncid-1.13-3.fc37.src.rpm
nekovm-2.3.0-9.fc36.src.rpm
ngrep-1.47-8.1.20180101git9b59468.fc36.src.rpm
nmap-7.92-4.fc37.src.rpm
> ocaml-pcre-7.5.0-6.fc37.src.rpm
> octave-7.1.0-2.fc37.src.rpm
> openCOLLADA-1.6.70-1.fc36.src.rpm
> openscap-1.3.6-9.fc37.src.rpm
> opensips-3.3.0-1.fc37.src.rpm
> pads-1.2-33.fc36.src.rpm
> pcre-8.45-1.fc36.1.src.rpm
> pdfgrep-2.1.2-9.fc36.src.rpm
> perl-HTML-Template-Pro-0.9524-2.fc37.src.rpm
> perl-re-engine-PCRE-0.17-32.fc37.src.rpm
> picom-9.1-1.fc37.src.rpm
> pl-8.4.3-2.fc37.src.rpm
> poco-1.11.2-7.fc37.src.rpm
> postfix-3.7.2-1.fc37.src.rpm
> powwow-1.2.23-2.fc36.src.rpm
> prboom-plus-2.6.2-1.fc37.src.rpm
> prelude-lml-5.2.0-7.fc35.src.rpm
> privoxy-3.0.33-2.fc36.src.rpm
> proftpd-1.3.7d-1.fc37.src.rpm
> proxysql-2.3.2-4.fc37.src.rpm
> python-qutepart-3.3.2-3.fc37.src.rpm
> python-scss-1.3.7-8.fc37.src.rpm
> R-4.1.3-1.fc37.src.rpm
> rasqal-0.9.33-18.fc36.src.rpm
> regexxer-0.9-31.fc36.src.rpm
> root-6.26.04-4.fc37.src.rpm
> rudiments-1.3.1-4.fc36.src.rpm
> sigil-0.9.14-12.fc36.src.rpm
> slang-2.3.2-11.fc36.src.rpm
> sord-0.16.10-1.fc37.src.rpm
> sslh-1.21c-4.fc36.src.rpm
> suricata-6.0.6-1.fc37.src.rpm
> sway-1.7-2.fc37.src.rpm
> swig-4.0.2-16.fc37.src.rpm
> syncevolution-2.0.0-4.fc37.src.rpm
> syslog-ng-3.35.1-4.fc37.src.rpm
> the_foundation-1.4.0-1.fc37.src.rpm
> the_silver_searcher-2.2.0^2020704.5a1c8d8-4.fc36.src.rpm
> Thunar-4.16.11-1.fc37.src.rpm
> tin-2.6.1-2.fc36.src.rpm
> tintin-2.02.05-4.fc36.src.rpm
> tinyfugue-5.0-0.104.b8.fc36.src.rpm
> trafficserver-9.1.2-9.fc37.src.rpm
> uwsgi-2.0.20-7.fc37.src.rpm
> vdr-epgfixer-0.3.1-21.20180416git354f28b.fc36.src.rpm
> watchman-2021.05.10.00-14.fc37.src.rpm
> wmweather+-2.17-12.fc36.src.rpm
> xastir-2.1.4-12.fc36.src.rpm
> xfce4-verve-plugin-2.0.1-4.fc36.src.rpm
> xgrep-0.08-17.fc36.src.rpm
> xmlcopyeditor-1.2.1.3-18.fc36.src.rpm
> zabbix-6.0.6-1.fc37.src.rpm
> zsh-5.9-1.fc37.src.rpm
>
> There's probably overlap between these two sets, but you need to
> consider both lists to get the complete picture (i.e. both build-time
> and run-time dependencies).
> And it's a pretty big list either way.
>
> Fabio
3:48 p.m.
Hi,
Lukas Javorsky <ljavorsk(a)redhat.com> 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
5:22 p.m.
(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
5:22 p.m.
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
5:28 p.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On Fri, Jul 22, 2022 at 11:47 PM Maxwell G <gotmax(a)e.email> 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
5:36 p.m.
On Sat, Jul 23, 2022 at 12:23 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> 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
6:08 p.m.
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
8:29 p.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
Replying in general...
I've asked about a "one script to rule them all" a few times over my 10+
year Fedora packaging career and it's fallen on deaf ears.
I hope something will happen this time. There should really be only ONE way
to determine what packages need to be rebuilt, even if it's not perfect, we
can deal with the corner cases but everyone doing their own thing has
definitely been worse.
It should be part of the fedora-packager package.
Thanks,
Richard
2:46 a.m.
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 (vitaly(a)easycoding.org)
3:14 a.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
Richard Shaw <hobbes1069(a)gmail.com> writes:
Replying in general...
I've asked about a "one script to rule them all" a few times over my 10+
year Fedora packaging career and it's fallen on deaf ears.
I hope something will happen this time. There should really be only ONE way
to determine what packages need to be rebuilt, even if it's not perfect, we
can deal with the corner cases but everyone doing their own thing has
definitely been worse.
In a perfect world koji or koschei would figure this out themselves and
perform the rebuilds for us so that we can finally stop thinking about
build orders and dependencies ourselves.
3:22 a.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On Sat, Jul 23, 2022, 03:30 Richard Shaw <hobbes1069(a)gmail.com> wrote:
Replying in general...
I've asked about a "one script to rule them all" a few times over my 10+
year Fedora packaging career and it's fallen on deaf ears.
I hope something will happen this time. There should really be only ONE way to determine
what packages need to be rebuilt, even if it's not perfect, we can deal with the
corner cases but everyone doing their own thing has definitely been worse.
It should be part of the fedora-packager package.
The problem is that what you need to query for depends on what you're doing.
The queries I posted in this thread are for *all dependencies*, i.e.
to determine the impact of something like a package removal.
On the other hand, if you're trying to determine the impact of an
soname bump, the query would be quite different (or rather, more
complicated / specific). Otherwise your list of "packages that need to
be rebuilt for the soname bump" is going to contain a lot of packages
that don't need to be rebuilt at all.
Given that there can't be one way to rule them all, we'd need
specialized scripts for different purposes. And since I don't have a
script that works for the second example here (soname bumps), which is
what you have asked about in the past, I haven't shared that (because
I don't have it). I maintain only a handful of packages that build
shared C / C++ libraries, and the rest are all either only
applications without libraries, or 2000+ Rust packages (for which the
compatibility / impact checks are much simpler), so I haven't needed
to develop tooling for the "soname bump" case.
In the case of pcre, it's about *total impact* in case of package
removal, for which I *did* happen to have the tooling already.
But I agree that we should have a canonical way to calculate
dependency trees like this, and that it should be part of our tooling.
Should we collaborate on those canonical scripts so that they can be
published as part of the standard packager toolkit?
I can open a pagure repo and push a script for the "total impact"
case, and we can then build one for the "soname bump" case based on
that ...
Fabio
5:09 a.m.
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
5:50 a.m.
On Fri, Jul 22, 2022 at 3:28 PM Richard W.M. Jones <rjones(a)redhat.com> 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!
5:55 a.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák
<dan.cermak(a)cgc-instruments.com> wrote:
Richard Shaw <hobbes1069(a)gmail.com> writes:
> Replying in general...
>
> I've asked about a "one script to rule them all" a few times over my
10+
> year Fedora packaging career and it's fallen on deaf ears.
>
> I hope something will happen this time. There should really be only ONE way
> to determine what packages need to be rebuilt, even if it's not perfect, we
> can deal with the corner cases but everyone doing their own thing has
> definitely been worse.
In a perfect world koji or koschei would figure this out themselves and
perform the rebuilds for us so that we can finally stop thinking about
build orders and dependencies ourselves.
The sad part is that Koschei can do it, but the build system folks
have so far refused to enhance Koji and Koschei to do this for
creating *real builds* that are auto-submitted.
We have all the pieces to do it now, especially with being able to
generate random side-tags and merge them freely. Koschei knows the
build order and calculates dependency drift pretty well already. It
uses that to trigger scratch builds, we just need it to do real builds
in a generated side tag. But we need a build counter that is
independent of us doing bumps in Git[1]. Sadly, that was ripped out of
rpmautospec, making it useless for making package maintenance less
tedious.
[1]: https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms/39954
--
真実はいつも一つ！/ Always, there's only one truth!
6:46 a.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On Sat, Jul 23, 2022 at 12:56 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák
<dan.cermak(a)cgc-instruments.com> wrote:
>
> Richard Shaw <hobbes1069(a)gmail.com> writes:
>
> > Replying in general...
> >
> > I've asked about a "one script to rule them all" a few times over
my 10+
> > year Fedora packaging career and it's fallen on deaf ears.
> >
> > I hope something will happen this time. There should really be only ONE way
> > to determine what packages need to be rebuilt, even if it's not perfect,
we
> > can deal with the corner cases but everyone doing their own thing has
> > definitely been worse.
>
> In a perfect world koji or koschei would figure this out themselves and
> perform the rebuilds for us so that we can finally stop thinking about
> build orders and dependencies ourselves.
The sad part is that Koschei can do it, but the build system folks
have so far refused to enhance Koji and Koschei to do this for
creating *real builds* that are auto-submitted.
Alright Neal, this is a bit off-topic, but I'll bite.
Auto-submitting real builds is something that I will, except in very
narrowly defined exceptions, always disagree with.
Until now, automagic builds have only caused trouble. Just look at the
mess that's regularly made in the podman/container stack, or by stuff
that was automatically submitted by packit. It's one of the reasons
why we now have a policy that requires actual people to be responsible
for all builds submitted by bots.
Even if we had a mechanism to trigger automatic rebuilds of dependent
packages (i.e. "I have detected that the sonames of the libraries in
this package have changed, let me also rebuild dependent packages for
this!") only works *if* (and that's a big *if*) the ABI change isn't
accompanied by breaking API changes, as well. What would you want to
happen then? I'm pretty sure software isn't smart enough yet to
determine in advance if any breaking API changes affect any dependent
packages.
So how would the mechanism you want work?
1. packager submits a build of libfoo version X that contains an
soname bump to koji
2. magic mechanism (TM) detects this ~somehow~ and does ... what? the
only thing I can think of is ...
3. magic mechanism (TM) tags the build into an on-demand side-tag N
instead of rawhide after it finishes
4. magic mechanism (TM) queries dependent packages
5. magic mechanism (TM) bumps dependent packages with "Rebuilt for
libfoo soname bump."
6. magic mechanism (TM) submits builds of dependent packages to
on-demand side-tag N
7. magic mechanism (TM) requests bodhi to merge the side tag *if and
only if* all builds succeed and are installable
That's all well and good so long as everything *just works*, but will
instantly break the second any part of this will need human
intervention, or if there are any race conditions:
- dependent packages need patches for breaking API changes
- dependent packages need a compat package libfooXminus1 because they
can't be ported
- the sets of dependent packages overlap between concurrently created side tags
- dependent packages fail to build for unrelated reasons
- dependent packages fail to install for related (or unrelated) reasons
- packagers have pushed changes to dist-git that they didn't want to
get built yet (eugh)
- etc.
I just see so many points of failure in a process like the one you
want that I just can't ever see this becoming a reality unless we
enforce much stricter rules around 1) concurrent side tags / using a
mutex mechanism for packages in koji, 2) forbidding to push changes to
dist-git that must not be built yet, 3) drastically reducing the
number of FTBFS / FTI bugs in rawhide ~somehow~.
Unless you have ways to address at least some of those issues and
failure points with the mechanism that you want (and I cannot see how
that would be doable), I don't see automagic rebuilds happening.
We have all the pieces to do it now, especially with being able to
generate random side-tags and merge them freely.
Koschei knows the build order and calculates dependency drift pretty
well already.
Koschei knows nothing about build order.
It regularly submits builds for my packages in the wrong order, or
triggers builds at the wrong time, because it orders builds by their
"finished" datetime instead of their "actually available" datetime,
etc. Almost every time I merge a multi-build side-tag, I need to poke
it with a lot of sticks to fix dependency resolution from being stuck
for a few packages.
It uses that to trigger scratch builds, we just need it to do real
builds
in a generated side tag. But we need a build counter that is
independent of us doing bumps in Git[1].
I can see that differentiating between builds that have the same NVR
could be useful (because the build environment or their dependencies
were different, etc.), but the proposed "solution" to add another
component to the NVR(B) is very disruptive and would probably break
all our tools, require adaptations to every component of our build
pipeline, etc.
But I don't see why you actually *need* independent build counters. At
least for packages that use rpmautospec, adding an empty commit with a
message like "Rebuilt for the latest version of X" would do it - and
that would 1) not require adapting our entire build pipeline and
tooling, and 2) actually record the reason for a rebuild in the
standard location we have for it (in the dist-git commit log / the
package's changelog).
Sadly, that was ripped out of
rpmautospec, making it useless for making package maintenance less
tedious.
[1]: https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms/39954
Yes, and I still think that was the right decision.
rpmautospec has been astonishingly reliable *because* it's more simple
than what you wanted.
Adding a - by definition - *fallible* query over a network to
something that should never be allowed to fail would've been a
terrible idea.
Fabio
7 a.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On Sat, Jul 23, 2022 at 7:47 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Sat, Jul 23, 2022 at 12:56 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák
> <dan.cermak(a)cgc-instruments.com> wrote:
> >
> > Richard Shaw <hobbes1069(a)gmail.com> writes:
> >
> > > Replying in general...
> > >
> > > I've asked about a "one script to rule them all" a few times
over my 10+
> > > year Fedora packaging career and it's fallen on deaf ears.
> > >
> > > I hope something will happen this time. There should really be only ONE
way
> > > to determine what packages need to be rebuilt, even if it's not
perfect, we
> > > can deal with the corner cases but everyone doing their own thing has
> > > definitely been worse.
> >
> > In a perfect world koji or koschei would figure this out themselves and
> > perform the rebuilds for us so that we can finally stop thinking about
> > build orders and dependencies ourselves.
>
> The sad part is that Koschei can do it, but the build system folks
> have so far refused to enhance Koji and Koschei to do this for
> creating *real builds* that are auto-submitted.
Alright Neal, this is a bit off-topic, but I'll bite.
Auto-submitting real builds is something that I will, except in very
narrowly defined exceptions, always disagree with.
Until now, automagic builds have only caused trouble. Just look at the
mess that's regularly made in the podman/container stack, or by stuff
that was automatically submitted by packit. It's one of the reasons
why we now have a policy that requires actual people to be responsible
for all builds submitted by bots.
Even if we had a mechanism to trigger automatic rebuilds of dependent
packages (i.e. "I have detected that the sonames of the libraries in
this package have changed, let me also rebuild dependent packages for
this!") only works *if* (and that's a big *if*) the ABI change isn't
accompanied by breaking API changes, as well. What would you want to
happen then? I'm pretty sure software isn't smart enough yet to
determine in advance if any breaking API changes affect any dependent
packages.
So how would the mechanism you want work?
1. packager submits a build of libfoo version X that contains an
soname bump to koji
2. magic mechanism (TM) detects this ~somehow~ and does ... what? the
only thing I can think of is ...
3. magic mechanism (TM) tags the build into an on-demand side-tag N
instead of rawhide after it finishes
4. magic mechanism (TM) queries dependent packages
5. magic mechanism (TM) bumps dependent packages with "Rebuilt for
libfoo soname bump."
This step wouldn't happen. Bumping packages automatically is dangerous
and creates problems.
6. magic mechanism (TM) submits builds of dependent packages to
on-demand side-tag N
7. magic mechanism (TM) requests bodhi to merge the side tag *if and
only if* all builds succeed and are installable
It would also have to pass relevant gating tests. Right now gating
doesn't do much, but that is already changing over time. And ideally
we could run OpenQA tests on all of these in the future.
That's all well and good so long as everything *just works*, but
will
instantly break the second any part of this will need human
intervention, or if there are any race conditions:
- dependent packages need patches for breaking API changes
- dependent packages need a compat package libfooXminus1 because they
can't be ported
Build failure would cause it to not get merged. But the side tag would
exist for human action to resolve the chain.
- 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.
- dependent packages fail to build for unrelated reasons
- dependent packages fail to install for related (or unrelated) reasons
- packagers have pushed changes to dist-git that they didn't want to
get built yet (eugh)
Okay, and? They fail, it doesn't merge, and we deal with it as we do
now. Or if it looks like a fluke, poke it to try to rebuild the failed
ones again.
I just see so many points of failure in a process like the one you
want that I just can't ever see this becoming a reality unless we
enforce much stricter rules around 1) concurrent side tags / using a
mutex mechanism for packages in koji, 2) forbidding to push changes to
dist-git that must not be built yet, 3) drastically reducing the
number of FTBFS / FTI bugs in rawhide ~somehow~.
Unless you have ways to address at least some of those issues and
failure points with the mechanism that you want (and I cannot see how
that would be doable), I don't see automagic rebuilds happening.
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.
--
真実はいつも一つ！/ Always, there's only one truth!
12:12 p.m.
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 <berrange(a)redhat.com>
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 <berrange(a)redhat.com>
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
2:28 p.m.
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
3:09 p.m.
Lukas Javorsky <ljavorsk(a)redhat.com> 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 <carenas(a)gmail.com>
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/f84614fe066f74d111b802d5...
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!
4:54 p.m.
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
1:58 a.m.
Il sab 23 lug 2022, 19:12 Adam Williamson <adamwill(a)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.
Paolo
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
4:01 a.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On 7/23/22 07:46, Fabio Valentini wrote:
On Sat, Jul 23, 2022 at 12:56 PM Neal Gompa
<ngompa13(a)gmail.com> wrote:
>
> On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák
> <dan.cermak(a)cgc-instruments.com> wrote:
>>
>> Richard Shaw <hobbes1069(a)gmail.com> writes:
>>
>>> Replying in general...
>>>
>>> I've asked about a "one script to rule them all" a few times
over my 10+
>>> year Fedora packaging career and it's fallen on deaf ears.
>>>
>>> I hope something will happen this time. There should really be only ONE way
>>> to determine what packages need to be rebuilt, even if it's not perfect,
we
>>> can deal with the corner cases but everyone doing their own thing has
>>> definitely been worse.
>>
>> In a perfect world koji or koschei would figure this out themselves and
>> perform the rebuilds for us so that we can finally stop thinking about
>> build orders and dependencies ourselves.
>
> The sad part is that Koschei can do it, but the build system folks
> have so far refused to enhance Koji and Koschei to do this for
> creating *real builds* that are auto-submitted.
Alright Neal, this is a bit off-topic, but I'll bite.
Auto-submitting real builds is something that I will, except in very
narrowly defined exceptions, always disagree with.
Until now, automagic builds have only caused trouble. Just look at the
mess that's regularly made in the podman/container stack, or by stuff
that was automatically submitted by packit. It's one of the reasons
why we now have a policy that requires actual people to be responsible
for all builds submitted by bots.
Even if we had a mechanism to trigger automatic rebuilds of dependent
packages (i.e. "I have detected that the sonames of the libraries in
this package have changed, let me also rebuild dependent packages for
this!") only works *if* (and that's a big *if*) the ABI change isn't
accompanied by breaking API changes, as well. What would you want to
happen then? I'm pretty sure software isn't smart enough yet to
determine in advance if any breaking API changes affect any dependent
packages.
This is going to be true for the majority of Haskell and Rust package
updates if Fedora ever decides to use dynamic linking for them.
Same for lots of C++ template libraries.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
8:42 a.m.
On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini <pbonzini(a)redhat.com> wrote:
Il sab 23 lug 2022, 19:12 Adam Williamson <adamwill(a)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?
https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd4...
--
Kalev
9:45 a.m.
Kalev Lember wrote on 2022/07/24 22:42:
On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini
<pbonzini(a)redhat.com> 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/34b203d5499b579c68b4f923a29fd4...
Ah... maybe due to this?
A.
On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby language) sees
test failure with regards to "g_regex_match_all" - note that this is s390x
only.
https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927
B.
I got lxrandr behavior regression on rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=2109187
- what lxrandr does here is lxrander gets the result of "xrandr" and
passes it to "g_regex_match".
On F-36 actually "g_regex_match" matches but (while I have not tried yet)
what bug reporter says must be that "g_regex_match" now fails with
rawhide glib2 (this is happening on x86_64).
I will recheck this tomorrow.
Regards,
Mamoru
10:45 a.m.
On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA <mtasaka(a)fedoraproject.org>
wrote:
Kalev Lember wrote on 2022/07/24 22:42:
> glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs
to
> be updated for that now so that it BuildRequires pcre2-static instead?
>
>
https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd4...
>
Ah... maybe due to this?
A.
On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby
language) sees
test failure with regards to "g_regex_match_all" - note that this is s390x
only.
https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927
B.
I got lxrandr behavior regression on rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=2109187
- what lxrandr does here is lxrander gets the result of "xrandr" and
passes it to "g_regex_match".
On F-36 actually "g_regex_match" matches but (while I have not tried
yet)
what bug reporter says must be that "g_regex_match" now fails with
rawhide glib2 (this is happening on x86_64).
I will recheck this tomorrow.
Those both sound a lot like regressions in g_regex_match() to me. If you
have time, any chance you could create smaller reproducers and file issues
for these upstream at https://gitlab.gnome.org/GNOME/glib ?
--
Thanks,
Kalev
6:10 p.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On Sat, Jul 23, 2022 at 2:01 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Jul 23, 2022 at 7:47 AM Fabio Valentini <decathorpe(a)gmail.com> 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
6:16 p.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On Sun, Jul 24, 2022 at 11:02 AM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
On 7/23/22 07:46, Fabio Valentini wrote:
> On Sat, Jul 23, 2022 at 12:56 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>
>> On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák
>> <dan.cermak(a)cgc-instruments.com> wrote:
>>>
>>> Richard Shaw <hobbes1069(a)gmail.com> writes:
>>>
>>>> Replying in general...
>>>>
>>>> I've asked about a "one script to rule them all" a few
times over my 10+
>>>> year Fedora packaging career and it's fallen on deaf ears.
>>>>
>>>> I hope something will happen this time. There should really be only ONE
way
>>>> to determine what packages need to be rebuilt, even if it's not
perfect, we
>>>> can deal with the corner cases but everyone doing their own thing has
>>>> definitely been worse.
>>>
>>> In a perfect world koji or koschei would figure this out themselves and
>>> perform the rebuilds for us so that we can finally stop thinking about
>>> build orders and dependencies ourselves.
>>
>> The sad part is that Koschei can do it, but the build system folks
>> have so far refused to enhance Koji and Koschei to do this for
>> creating *real builds* that are auto-submitted.
>
> Alright Neal, this is a bit off-topic, but I'll bite.
>
> Auto-submitting real builds is something that I will, except in very
> narrowly defined exceptions, always disagree with.
> Until now, automagic builds have only caused trouble. Just look at the
> mess that's regularly made in the podman/container stack, or by stuff
> that was automatically submitted by packit. It's one of the reasons
> why we now have a policy that requires actual people to be responsible
> for all builds submitted by bots.
>
> Even if we had a mechanism to trigger automatic rebuilds of dependent
> packages (i.e. "I have detected that the sonames of the libraries in
> this package have changed, let me also rebuild dependent packages for
> this!") only works *if* (and that's a big *if*) the ABI change isn't
> accompanied by breaking API changes, as well. What would you want to
> happen then? I'm pretty sure software isn't smart enough yet to
> determine in advance if any breaking API changes affect any dependent
> packages.
This is going to be true for the majority of Haskell and Rust package
updates if Fedora ever decides to use dynamic linking for them.
Same for lots of C++ template libraries.
Do you have any indication that the Rust language and build system are
working on supporting this?
Fabio
6:48 p.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On 7/24/22 19:16, Fabio Valentini wrote:
On Sun, Jul 24, 2022 at 11:02 AM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
>
> On 7/23/22 07:46, Fabio Valentini wrote:
>> On Sat, Jul 23, 2022 at 12:56 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>>
>>> On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák
>>> <dan.cermak(a)cgc-instruments.com> wrote:
>>>>
>>>> Richard Shaw <hobbes1069(a)gmail.com> writes:
>>>>
>>>>> Replying in general...
>>>>>
>>>>> I've asked about a "one script to rule them all" a few
times over my 10+
>>>>> year Fedora packaging career and it's fallen on deaf ears.
>>>>>
>>>>> I hope something will happen this time. There should really be only
ONE way
>>>>> to determine what packages need to be rebuilt, even if it's not
perfect, we
>>>>> can deal with the corner cases but everyone doing their own thing
has
>>>>> definitely been worse.
>>>>
>>>> In a perfect world koji or koschei would figure this out themselves and
>>>> perform the rebuilds for us so that we can finally stop thinking about
>>>> build orders and dependencies ourselves.
>>>
>>> The sad part is that Koschei can do it, but the build system folks
>>> have so far refused to enhance Koji and Koschei to do this for
>>> creating *real builds* that are auto-submitted.
>>
>> Alright Neal, this is a bit off-topic, but I'll bite.
>>
>> Auto-submitting real builds is something that I will, except in very
>> narrowly defined exceptions, always disagree with.
>> Until now, automagic builds have only caused trouble. Just look at the
>> mess that's regularly made in the podman/container stack, or by stuff
>> that was automatically submitted by packit. It's one of the reasons
>> why we now have a policy that requires actual people to be responsible
>> for all builds submitted by bots.
>>
>> Even if we had a mechanism to trigger automatic rebuilds of dependent
>> packages (i.e. "I have detected that the sonames of the libraries in
>> this package have changed, let me also rebuild dependent packages for
>> this!") only works *if* (and that's a big *if*) the ABI change
isn't
>> accompanied by breaking API changes, as well. What would you want to
>> happen then? I'm pretty sure software isn't smart enough yet to
>> determine in advance if any breaking API changes affect any dependent
>> packages.
>
> This is going to be true for the majority of Haskell and Rust package
> updates if Fedora ever decides to use dynamic linking for them.
> Same for lots of C++ template libraries.
Do you have any indication that the Rust language and build system are
working on supporting this?
Fabio
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.
Fedora *should* be doing this for C++ template libraries already,
as C++ templates are not included in any static or shared libraries.
They are only found in headers, and so changing them requires all
code that uses them to be recompiled. Not doing so is technically
a violation of the One Definition Rule, and in any case it means
that bug fixes in the template code will not propagate without the
code using the templates being recompiled. The same is true for C
inline functions. For instance, PipeWire had some bug fixes in the
SPA config file parser, but that is an inline function, so code will
need to be recompiled to get the benefit of these changes.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
3:23 a.m.
Kalev Lember wrote on 2022/07/25 0:45:
On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA
<mtasaka(a)fedoraproject.org>
wrote:
> Kalev Lember wrote on 2022/07/24 22:42:
>> glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs
> to
>> be updated for that now so that it BuildRequires pcre2-static instead?
>>
>>
>
https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd4...
>>
>
> Ah... maybe due to this?
>
> A.
> On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby
> language) sees
> test failure with regards to "g_regex_match_all" - note that this is s390x
> only.
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927
>
> B.
> I got lxrandr behavior regression on rawhide:
> https://bugzilla.redhat.com/show_bug.cgi?id=2109187
>
> - what lxrandr does here is lxrander gets the result of "xrandr" and
> passes it to "g_regex_match".
> On F-36 actually "g_regex_match" matches but (while I have not tried
> yet)
> what bug reporter says must be that "g_regex_match" now fails with
> rawhide glib2 (this is happening on x86_64).
>
> I will recheck this tomorrow.
>
Those both sound a lot like regressions in g_regex_match() to me. If you
have time, any chance you could create smaller reproducers and file issues
for these upstream at https://gitlab.gnome.org/GNOME/glib ?
For issue A: reported (with smallest reproducer):
https://gitlab.gnome.org/GNOME/glib/-/issues/2699
Now I will recheck issue B (maybe tomorrow...)
Mamoru
4:38 a.m.
Quite a lot of reading but thanks everyone for the emails.
Few observations I get from this email thread (correct me if I
misunderstood anything):
1) We don't have a unified process for how to do such a retirement/orphan
package workflow.
2) We don't have a deterministic unified tool/script for how to find all
packages that depend on the "want-to-be-orphaned" package. Looks like the
one that Fabio provides is quite good, it may be worth to document it
somewhere, so it can be used in future.
3) It looks like there are some packages that don't even know why they
require the pcre package. This may be worth investigating for the
maintainers, so the package doesn't require something that is not even used.
4) There are some folks that are willing to take over the maintenance of
the pcre package. I'm still going to create a COPR build for every
dependent package with change from "pcre" to "pcre2" requirement, so I
can
report each of the components, if it's able to just simply change to pcre2
or need to port.
However, after that, I will pass the component to the people that want
to maintain it. I can see that Vitaly (FAS = xvitaly) is willing, feel free
to message me if there is anybody else that wants to help him.
For the packages that are going to port their code to pcre2, you can do it
in the upcoming release, so you don't need to rush, we
appreciate you're doing it.
Thank you all for all of the insightful information and help.
Lukas
On Mon, Jul 25, 2022 at 10:23 AM Mamoru TASAKA <mtasaka(a)fedoraproject.org>
wrote:
Kalev Lember wrote on 2022/07/25 0:45:
> On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA <mtasaka(a)fedoraproject.org
>
> wrote:
>
>> Kalev Lember wrote on 2022/07/24 22:42:
>>> glib2 switched to pcre2 in rawhide recently. Can you check if qemu
needs
>> to
>>> be updated for that now so that it BuildRequires pcre2-static instead?
>>>
>>>
>>
https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd4...
>>>
>>
>> Ah... maybe due to this?
>>
>> A.
>> On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby
>> language) sees
>> test failure with regards to "g_regex_match_all" - note that this is
s390x
>> only.
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927
>>
>> B.
>> I got lxrandr behavior regression on rawhide:
>> https://bugzilla.redhat.com/show_bug.cgi?id=2109187
>>
>> - what lxrandr does here is lxrander gets the result of "xrandr" and
>> passes it to "g_regex_match".
>> On F-36 actually "g_regex_match" matches but (while I have not
tried
>> yet)
>> what bug reporter says must be that "g_regex_match" now fails
with
>> rawhide glib2 (this is happening on x86_64).
>>
>> I will recheck this tomorrow.
>>
>
> Those both sound a lot like regressions in g_regex_match() to me. If you
> have time, any chance you could create smaller reproducers and file
issues
> for these upstream at https://gitlab.gnome.org/GNOME/glib ?
For issue A: reported (with smallest reproducer):
https://gitlab.gnome.org/GNOME/glib/-/issues/2699
Now I will recheck issue B (maybe tomorrow...)
Mamoru
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
5:36 a.m.
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
8:20 a.m.
On Sat, Jul 23, 2022 at 5:55 PM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> 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
8:56 a.m.
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
clisp-2.49.93-23.20210628gitde01f0f.fc36.src requires pcre-devel =
8.45-1.fc36.1
clisp-2.49.93-23.20210628gitde01f0f.fc36.x86_64 requires
libpcre.so.1()(64bit)
clover2 (maintained by: mtasaka)
clover2-10.4.6-9.D20190613git6f483b4.fc36.src requires pcre-devel =
8.45-1.fc36.1
clover2-10.4.6-9.D20190613git6f483b4.fc36.x86_64 requires
libpcre.so.1()(64bit)
clover2-devel-10.4.6-9.D20190613git6f483b4.fc36.i686 requires
libpcre.so.1
clover2-devel-10.4.6-9.D20190613git6f483b4.fc36.x86_64 requires
libpcre.so.1()(64bit)
clover2-libs-10.4.6-9.D20190613git6f483b4.fc36.i686 requires
libpcre.so.1
clover2-libs-10.4.6-9.D20190613git6f483b4.fc36.x86_64 requires
libpcre.so.1()(64bit)
coccinelle (maintained by: ctwo0002, rjones)
coccinelle-1.1.1-11.fc37.x86_64 requires libpcre.so.1()(64bit)
collada-dom (maintained by: thofmann)
collada-dom-2.5.0-21.fc37.i686 requires libpcrecpp.so.0
collada-dom-2.5.0-21.fc37.src requires pcre-devel = 8.45-1.fc36.1
collada-dom-2.5.0-21.fc37.x86_64 requires libpcrecpp.so.0()(64bit)
compton (maintained by: axeld)
compton-0.1-0.11.beta3.fc36.src requires pcre-devel = 8.45-1.fc36.1
compton-0.1-0.11.beta3.fc36.x86_64 requires libpcre.so.1()(64bit)
condor (maintained by: bbockelm, bcotton, eerlands, matt, matyas,
tstclair, ttheisen, valtri)
condor-8.8.15-7.fc37.src requires pcre-devel = 8.45-1.fc36.1
condor-8.8.15-7.fc37.x86_64 requires libpcre.so.1()(64bit)
condor-classads-8.8.15-7.fc37.i686 requires libpcre.so.1
condor-classads-8.8.15-7.fc37.x86_64 requires libpcre.so.1()(64bit)
condor-classads-devel-8.8.15-7.fc37.i686 requires pcre-devel = 8.45-
1.fc36.1
condor-classads-devel-8.8.15-7.fc37.x86_64 requires pcre-devel = 8.45-
1.fc36.1
cppcheck (maintained by: c72578, jussilehtola, sgrubb, tdawson)
cppcheck-2.8.2-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
cppcheck-2.8.2-1.fc37.x86_64 requires libpcre.so.1()(64bit)
cppcheck-gui-2.8.2-1.fc37.x86_64 requires libpcre.so.1()(64bit)
cyrus-imapd (maintained by: jorton, kanarip, landgraf, mosvald, tibbs,
zdohnal)
cyrus-imapd-libs-3.4.3-1.fc37.i686 requires libpcre.so.1,
libpcreposix.so.0
cyrus-imapd-libs-3.4.3-1.fc37.x86_64 requires libpcre.so.1()(64bit),
libpcreposix.so.0()(64bit)
perl-Cyrus-3.4.3-1.fc37.x86_64 requires libpcreposix.so.0()(64bit)
deepin-file-manager (maintained by: cheeselee, deepinde-sig, mosquito,
zsun)
deepin-file-manager-5.6.4-1.fc37.src requires pcre-devel = 8.45-
1.fc36.1
dogtag-pki (maintained by: abbra, cdorney, cfu, cipherboy, ckelley,
dmoluguw, edewata, jmagne, kwright, mharmsen, vakwetu)
dogtag-pki-11.2.0-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
eiskaltdcpp (maintained by: vascom)
eiskaltdcpp-2.4.2-6.fc37.i686 requires libpcrecpp.so.0
eiskaltdcpp-2.4.2-6.fc37.src requires pkgconfig(libpcre) = 8.45
eiskaltdcpp-2.4.2-6.fc37.x86_64 requires libpcrecpp.so.0()(64bit)
eterm (maintained by: terjeros)
eterm-0.9.6-28.fc36.src requires pcre-devel = 8.45-1.fc36.1
eterm-0.9.6-28.fc36.x86_64 requires libpcre.so.1()(64bit)
ettercap (maintained by: limb)
ettercap-0.8.3.1-6.fc36.i686 requires libpcre.so.1
ettercap-0.8.3.1-6.fc36.src requires pcre-devel = 8.45-1.fc36.1
ettercap-0.8.3.1-6.fc36.x86_64 requires libpcre.so.1()(64bit)
freeradius (maintained by: antorres, cipherboy, nkondras)
freeradius-3.2.0-1.fc37.i686 requires libpcre.so.1
freeradius-3.2.0-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
freeradius-3.2.0-1.fc37.x86_64 requires libpcre.so.1()(64bit)
freeradius-utils-3.2.0-1.fc37.x86_64 requires libpcre.so.1()(64bit)
gambas3 (maintained by: spot)
gambas3-3.17.2-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
ganglia (maintained by: georgiou, gonis, terjeros)
ganglia-3.7.2-38.fc36.i686 requires libpcre.so.1
ganglia-3.7.2-38.fc36.src requires pcre-devel = 8.45-1.fc36.1
ganglia-3.7.2-38.fc36.x86_64 requires libpcre.so.1()(64bit)
ganglia-gmond-3.7.2-38.fc36.x86_64 requires libpcre.so.1()(64bit)
ghc-highlighting-kate (maintained by: petersen)
ghc-highlighting-kate-0.6.4-21.fc37.x86_64 requires
libpcre.so.1()(64bit)
ghc-highlighting-kate-devel-0.6.4-21.fc37.x86_64 requires
libpcre.so.1()(64bit)
ghc-pcre-light (maintained by: petersen)
ghc-pcre-light-0.4.1.0-9.fc37.src requires pcre-devel = 8.45-1.fc36.1
ghc-pcre-light-0.4.1.0-9.fc37.x86_64 requires libpcre.so.1()(64bit)
ghc-pcre-light-devel-0.4.1.0-9.fc37.x86_64 requires pcre-devel(x86-64)
= 8.45-1.fc36.1
ghc-regex-pcre (maintained by: petersen)
ghc-regex-pcre-0.95.0.0-8.fc37.src requires pkgconfig(libpcre) = 8.45
ghc-regex-pcre-0.95.0.0-8.fc37.x86_64 requires libpcre.so.1()(64bit)
ghc-regex-pcre-devel-0.95.0.0-8.fc37.x86_64 requires pkgconfig(libpcre)
= 8.45
gnome-builder (maintained by: amigadave, gnome-sig, ignatenkobrain)
gnome-builder-42.1-2.fc37.i686 requires libpcre.so.1
gnome-builder-42.1-2.fc37.src requires pkgconfig(libpcre) = 8.45
gnome-builder-42.1-2.fc37.x86_64 requires libpcre.so.1()(64bit)
gnome-text-editor (maintained by: gnome-sig, kalev, linkdupont, ngompa)
gnome-text-editor-43~alpha0-1.fc37.src requires pkgconfig(libpcre) =
8.45
gnome-text-editor-43~alpha0-1.fc37.x86_64 requires
libpcre.so.1()(64bit)
gnote (maintained by: gnome-sig, jspaleta, jwcampbell, kalev)
gnote-42.0-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
golang (maintained by: alexsaezm, deparker, dwd, jcajka, maxamillion,
skottler, ttomecek)
golang-1.19~rc2-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
gource (maintained by: limb)
gource-0.53-2.fc37.src requires pcre-devel = 8.45-1.fc36.1
grep (maintained by: jskarvad, lkundrak)
grep-3.7-2.fc36.src requires pcre-devel = 8.45-1.fc36.1
grep-3.7-2.fc36.x86_64 requires libpcre.so.1()(64bit)
groonga (maintained by: kenhys, myokoym)
groonga-10.0.8-5.fc36.src requires pcre-devel = 8.45-1.fc36.1
groonga-httpd-10.0.8-5.fc36.x86_64 requires libpcre.so.1()(64bit)
gsmartcontrol (maintained by: brouhaha, vascom)
gsmartcontrol-1.1.4-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
gsmartcontrol-1.1.4-1.fc37.x86_64 requires libpcrecpp.so.0()(64bit)
haxe (maintained by: andyli, rjones)
haxe-4.2.5-2.fc37.src requires pcre-devel = 8.45-1.fc36.1
haxe-4.2.5-2.fc37.x86_64 requires libpcre.so.1()(64bit)
hydra (maintained by: athmane, rebus)
hydra-9.2-7.fc37.src requires pcre-devel = 8.45-1.fc36.1
hydra-9.2-7.fc37.x86_64 requires libpcre.so.1()(64bit)
hyperscan (maintained by: jtaylor)
hyperscan-5.4.0-4.fc36.src requires pcre-devel = 8.45-1.fc36.1
i3 (maintained by: cicku, defolos, fale, gchamoul, jgu, lupinix,
pjgeorg, runcom)
i3-4.20.1-4.fc37.src requires pkgconfig(libpcre) = 8.45
i3-4.20.1-4.fc37.x86_64 requires libpcre.so.1()(64bit)
i3-gaps (maintained by: defolos)
i3-gaps-4.20.1-2.fc37.src requires pkgconfig(libpcre) = 8.45
i3-gaps-4.20.1-2.fc37.x86_64 requires libpcre.so.1()(64bit)
imapfilter (maintained by: averi, cicku)
imapfilter-2.6.15-7.fc36.src requires pcre-devel = 8.45-1.fc36.1
imapfilter-2.6.15-7.fc36.x86_64 requires libpcre.so.1()(64bit)
kdelibs (maintained by: dvratil, jgrulich, jreznik, kde-sig, kkofler,
rdieter, than)
kdelibs-6:4.14.38-34.fc37.i686 requires libpcre.so.1
kdelibs-6:4.14.38-34.fc37.src requires pkgconfig(libpcre) = 8.45
kdelibs-6:4.14.38-34.fc37.x86_64 requires libpcre.so.1()(64bit)
kdelibs3 (maintained by: jreznik, kkofler, rdieter, than)
kdelibs3-3.5.10-116.fc37.i686 requires libpcre.so.1
kdelibs3-3.5.10-116.fc37.src requires pcre-devel = 8.45-1.fc36.1
kdelibs3-3.5.10-116.fc37.x86_64 requires libpcre.so.1()(64bit)
kdevelop (maintained by: dvratil, jgrulich, kde-sig, rdieter, than)
kdevelop-9:22.04.3-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
kf5-kjs (maintained by: dvratil, jgrulich, kde-sig, rdieter, than)
kf5-kjs-5.96.0-1.fc37.i686 requires libpcre.so.1
kf5-kjs-5.96.0-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
kf5-kjs-5.96.0-1.fc37.x86_64 requires libpcre.so.1()(64bit)
kf5-kplotting (maintained by: dvratil, jgrulich, kde-sig, rdieter,
than)
kf5-kplotting-5.96.0-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
libast (maintained by: terjeros)
libast-0.7.1-0.30.20080502cvs.fc36.i686 requires libpcre.so.1
libast-0.7.1-0.30.20080502cvs.fc36.src requires pcre-devel = 8.45-
1.fc36.1
libast-0.7.1-0.30.20080502cvs.fc36.x86_64 requires
libpcre.so.1()(64bit)
liblognorm (maintained by: alakatos, rsroka, zfridric)
liblognorm-2.0.6-4.fc37.i686 requires libpcre.so.1
liblognorm-2.0.6-4.fc37.src requires pcre-devel = 8.45-1.fc36.1
liblognorm-2.0.6-4.fc37.x86_64 requires libpcre.so.1()(64bit)
libmodsecurity (maintained by: athmane, dridi)
libmodsecurity-3.0.4-6.fc36.i686 requires libpcre.so.1
libmodsecurity-3.0.4-6.fc36.src requires pkgconfig(libpcre) = 8.45
libmodsecurity-3.0.4-6.fc36.x86_64 requires libpcre.so.1()(64bit)
libprelude (maintained by: fab, limb, totol)
libprelude-5.2.0-13.fc37.i686 requires libpcre.so.1
libprelude-5.2.0-13.fc37.x86_64 requires libpcre.so.1()(64bit)
lnav (maintained by: cicku, pschiffe)
lnav-0.10.1-3.fc37.src requires pcre-devel = 8.45-1.fc36.1
lnav-0.10.1-3.fc37.x86_64 requires libpcre.so.1()(64bit)
logstalgia (maintained by: cicku, terjeros)
logstalgia-1.1.3-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
lumail (maintained by: lkundrak)
lumail-3.1-11.fc36.src requires pcre-devel = 8.45-1.fc36.1
lumail-3.1-11.fc36.x86_64 requires libpcrecpp.so.0()(64bit)
medusa (maintained by: athmane, rebus)
medusa-2.2-19.20181216git292193b.fc36.src requires pcre-devel = 8.45-
1.fc36.1
mle (maintained by: adsr)
mle-1.5.0-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
mle-1.5.0-1.fc37.x86_64 requires libpcre.so.1()(64bit)
mod_auth_openid (maintained by: codeblock, kevin)
mod_auth_openid-0.8-18.fc36.src requires pcre-devel = 8.45-1.fc36.1
mod_auth_openid-0.8-18.fc36.x86_64 requires libpcre.so.1()(64bit)
mod_auth_openidc (maintained by: jhrozek, thalman)
mod_auth_openidc-2.4.11.2-1.fc37.src requires pcre-devel = 8.45-
1.fc36.1
mod_auth_openidc-2.4.11.2-1.fc37.x86_64 requires libpcre.so.1()(64bit)
mod_qos (maintained by: athmane, cdamian)
mod_qos-11.70-1.fc36.src requires pcre-devel = 8.45-1.fc36.1
mod_qos-11.70-1.fc36.x86_64 requires libpcre.so.1()(64bit)
mod_security (maintained by: athmane, luhliarik, pvrabec)
mod_security-2.9.4-2.fc36.src requires pkgconfig(libpcre) = 8.45
mod_security-2.9.4-2.fc36.x86_64 requires libpcre.so.1()(64bit)
mod_security-mlogc-2.9.4-2.fc36.x86_64 requires libpcre.so.1()(64bit)
mod_security3 (maintained by: athmane)
mod_security3-0.0.9-0.20210819git0488c77.1.fc36.1.src requires
pkgconfig(libpcre) = 8.45
monotone (maintained by: thm)
monotone-1.1-43.fc37.src requires pcre-devel = 8.45-1.fc36.1
monotone-1.1-43.fc37.x86_64 requires libpcre.so.1()(64bit)
ncid (maintained by: jlcjohn, moceap, sandeen)
ncid-1.13-3.fc37.src requires pcre-devel = 8.45-1.fc36.1
ncid-1.13-3.fc37.x86_64 requires libpcre.so.1()(64bit)
nekovm (maintained by: andyli, rjones)
nekovm-2.3.0-9.fc36.i686 requires libpcre.so.1
nekovm-2.3.0-9.fc36.src requires pcre-devel = 8.45-1.fc36.1
nekovm-2.3.0-9.fc36.x86_64 requires libpcre.so.1()(64bit)
ngrep (maintained by: cicku, dcavalca, epel-packagers-sig, fale,
oliver)
ngrep-1.47-8.1.20180101git9b59468.fc36.src requires pcre-devel = 8.45-
1.fc36.1
ngrep-1.47-8.1.20180101git9b59468.fc36.x86_64 requires
libpcre.so.1()(64bit)
nmap (maintained by: landgraf, mhlavink, mosvald)
nmap-3:7.92-4.fc37.src requires pcre-devel = 8.45-1.fc36.1
nmap-3:7.92-4.fc37.x86_64 requires libpcre.so.1()(64bit)
ocaml-pcre (maintained by: rjones)
ocaml-pcre-7.5.0-6.fc37.i686 requires libpcre.so.1
ocaml-pcre-7.5.0-6.fc37.src requires pcre-devel = 8.45-1.fc36.1
ocaml-pcre-7.5.0-6.fc37.x86_64 requires libpcre.so.1()(64bit)
ocaml-pcre-devel-7.5.0-6.fc37.i686 requires pcre-devel(x86-32) = 8.45-
1.fc36.1
ocaml-pcre-devel-7.5.0-6.fc37.x86_64 requires pcre-devel(x86-64) =
8.45-1.fc36.1
oci-umount (maintained by: dwalsh, fkluknav, lsm5)
oci-umount-2:2.5-8.gitc3cda1f.fc36.src requires pcre-devel = 8.45-
1.fc36.1
octave (maintained by: alexlan, jcapik, jussilehtola, orion, rakesh,
scitech_sig)
octave-6:7.1.0-2.fc37.i686 requires libpcre.so.1
octave-6:7.1.0-2.fc37.src requires pcre-devel = 8.45-1.fc36.1
octave-6:7.1.0-2.fc37.x86_64 requires libpcre.so.1()(64bit)
openCOLLADA (maintained by: hobbes1069)
openCOLLADA-1.6.70-1.fc36.i686 requires libpcre.so.1
openCOLLADA-1.6.70-1.fc36.src requires pcre-devel = 8.45-1.fc36.1
openCOLLADA-1.6.70-1.fc36.x86_64 requires libpcre.so.1()(64bit)
openscap (maintained by: evgenyz, isimluk, jcerny, matyc, mmarhefk,
pvrabec, vpolasek, wsato)
openscap-1:1.3.6-9.fc37.i686 requires libpcre.so.1
openscap-1:1.3.6-9.fc37.src requires pcre-devel = 8.45-1.fc36.1
openscap-1:1.3.6-9.fc37.x86_64 requires libpcre.so.1()(64bit)
openscap-engine-sce-1:1.3.6-9.fc37.i686 requires libpcre.so.1
openscap-engine-sce-1:1.3.6-9.fc37.x86_64 requires
libpcre.so.1()(64bit)
opensips (maintained by: peter)
opensips-3.3.0-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
opensips-3.3.0-1.fc37.x86_64 requires libpcre.so.1()(64bit)
opensips-regex-3.3.0-1.fc37.x86_64 requires libpcre.so.1()(64bit)
pads (maintained by: sgrubb)
pads-1.2-33.fc36.src requires pcre-devel = 8.45-1.fc36.1
pads-1.2-33.fc36.x86_64 requires libpcre.so.1()(64bit)
pdfgrep (maintained by: jaydg, robert)
pdfgrep-2.1.2-9.fc36.src requires pcre-devel = 8.45-1.fc36.1
pdfgrep-2.1.2-9.fc36.x86_64 requires libpcre.so.1()(64bit)
perl-re-engine-PCRE (maintained by: jplesnik, ppisar)
perl-re-engine-PCRE-0.17-32.fc37.src requires pcre-devel = 8.45-
1.fc36.1
perl-re-engine-PCRE-0.17-32.fc37.x86_64 requires libpcre.so.1()(64bit)
petsc (maintained by: sagitter)
petsc-3.17.3-2.fc37.src requires pcre-devel = 8.45-1.fc36.1
php-pecl-apcu (maintained by: remi)
php-pecl-apcu-5.1.21-3.fc36.src requires pcre-devel = 8.45-1.fc36.1
php-pecl-http (maintained by: remi)
php-pecl-http-4.2.3-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
php-pecl-oauth (maintained by: fkooman, remi, tjikkun)
php-pecl-oauth-2.0.7-6.fc36.src requires pcre-devel = 8.45-1.fc36.1
picom (maintained by: atim)
picom-9.1-1.fc37.src requires pkgconfig(libpcre) = 8.45
picom-9.1-1.fc37.x86_64 requires libpcre.so.1()(64bit)
pl (maintained by: bagnara, jjames, mef)
pl-8.4.3-2.fc37.i686 requires libpcre.so.1
pl-8.4.3-2.fc37.src requires pkgconfig(libpcre) = 8.45
pl-8.4.3-2.fc37.x86_64 requires libpcre.so.1()(64bit)
poco (maintained by: cheeselee, francisandre)
poco-1.11.2-7.fc37.src requires pcre-devel = 8.45-1.fc36.1
poco-debug-1.11.2-7.fc37.i686 requires libpcre.so.1
poco-debug-1.11.2-7.fc37.x86_64 requires libpcre.so.1()(64bit)
poco-devel-1.11.2-7.fc37.i686 requires pcre-devel = 8.45-1.fc36.1
poco-devel-1.11.2-7.fc37.x86_64 requires pcre-devel = 8.45-1.fc36.1
poco-foundation-1.11.2-7.fc37.i686 requires libpcre.so.1
poco-foundation-1.11.2-7.fc37.x86_64 requires libpcre.so.1()(64bit)
postfix (maintained by: jskarvad, olysonek)
postfix-2:3.7.2-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
postfix-pcre-2:3.7.2-1.fc37.x86_64 requires libpcre.so.1()(64bit)
postgis (maintained by: devrim, jmlich, maxamillion, pkubat, praiskup,
smani)
postgis-3.2.1-3.fc37.src requires pcre-devel = 8.45-1.fc36.1
powwow (maintained by: kalev)
powwow-1.2.23-2.fc36.i686 requires libpcreposix.so.0
powwow-1.2.23-2.fc36.src requires pcre-devel = 8.45-1.fc36.1
powwow-1.2.23-2.fc36.x86_64 requires libpcreposix.so.0()(64bit)
prelude-lml (maintained by: totol)
prelude-lml-5.2.0-7.fc35.i686 requires libpcre.so.1
prelude-lml-5.2.0-7.fc35.src requires pkgconfig(libpcre) = 8.45
prelude-lml-5.2.0-7.fc35.x86_64 requires libpcre.so.1()(64bit)
privoxy (maintained by: cheese, limb)
privoxy-3.0.33-2.fc36.src requires pcre-devel = 8.45-1.fc36.1
privoxy-3.0.33-2.fc36.x86_64 requires libpcre.so.1()(64bit),
libpcreposix.so.0()(64bit)
proxysql (maintained by: acaringi, fjanus, hhorak, ignatenkobrain,
ljavorsk, mkulik, mschorm, praiskup)
proxysql-2.3.2-4.fc37.src requires pcre-devel = 8.45-1.fc36.1
proxysql-2.3.2-4.fc37.x86_64 requires libpcrecpp.so.0()(64bit)
python-qutepart (maintained by: kde-sig, python-sig, raphgro)
python-qutepart-3.3.2-3.fc37.src requires pcre-devel = 8.45-1.fc36.1
python3-qutepart-3.3.2-3.fc37.x86_64 requires libpcre.so.1()(64bit),
pcre = 8.45-1.fc36.1
python-scss (maintained by: mrunge)
python-scss-1.3.7-8.fc37.src requires pcre-devel = 8.45-1.fc36.1
python3-scss-1.3.7-8.fc37.x86_64 requires libpcre.so.1()(64bit)
qemu (maintained by: berrange, bonzini, crobinso, dwmw2, ehabkost,
jforbes, lkundrak, quintela, rjones, virtmaint-sig)
qemu-2:7.0.0-6.fc37.src requires pcre-static = 8.45-1.fc36.1
qpdf (maintained by: twaugh, zdohnal)
qpdf-10.6.3-2.fc37.src requires pcre-devel = 8.45-1.fc36.1
qt5-qtbase (maintained by: jgrulich, jreznik, kde-sig, rdieter, than)
qt5-qtbase-5.15.5-1.fc37.src requires pkgconfig(libpcre) = 8.45
qt6-qtbase (maintained by: jgrulich, kde-sig)
qt6-qtbase-6.3.1-1.fc37.src requires pkgconfig(libpcre) = 8.45
qtwebkit (maintained by: jreznik, kde-sig, kkofler, rdieter, than)
qtwebkit-2.3.4-36.fc36.src requires pkgconfig(libpcre) = 8.45
rasqal (maintained by: kde-sig, rdieter, thomasvs)
rasqal-0.9.33-18.fc36.i686 requires libpcre.so.1
rasqal-0.9.33-18.fc36.src requires pcre-devel = 8.45-1.fc36.1
rasqal-0.9.33-18.fc36.x86_64 requires libpcre.so.1()(64bit)
regexxer (maintained by: cwickert)
regexxer-0.9-31.fc36.src requires pcre-devel = 8.45-1.fc36.1
regexxer-0.9-31.fc36.x86_64 requires libpcre.so.1()(64bit)
remctl (maintained by: ktdreyer, sxw)
remctl-3.18-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
renderdoc (maintained by: gicmo)
renderdoc-1.17-2.fc36.src requires pcre-devel = 8.45-1.fc36.1
rkward (maintained by: kkofler)
rkward-0.7.2-6.fc36.src requires pcre-devel = 8.45-1.fc36.1
root (maintained by: ellert)
root-6.26.04-4.fc37.src requires pcre-devel = 8.45-1.fc36.1
root-core-6.26.04-4.fc37.i686 requires libpcre.so.1
root-core-6.26.04-4.fc37.x86_64 requires libpcre.so.1()(64bit)
rudiments (maintained by: davidleemuse)
rudiments-1.3.1-4.fc36.i686 requires libpcre.so.1
rudiments-1.3.1-4.fc36.src requires pcre-devel = 8.45-1.fc36.1
rudiments-1.3.1-4.fc36.x86_64 requires libpcre.so.1()(64bit)
sigil (maintained by: sharkcz)
sigil-0.9.14-12.fc36.src requires pcre-devel = 8.45-1.fc36.1
sigil-0.9.14-12.fc36.x86_64 requires libpcre16.so.0()(64bit)
slang (maintained by: mlichvar)
slang-2.3.2-11.fc36.src requires pcre-devel = 8.45-1.fc36.1
slang-slsh-2.3.2-11.fc36.x86_64 requires libpcre.so.1()(64bit)
sord (maintained by: bsjones, nphilipp, tartina)
sord-0.16.10-1.fc37.i686 requires libpcre.so.1
sord-0.16.10-1.fc37.x86_64 requires libpcre.so.1()(64bit)
sslh (maintained by: aperezbios)
sslh-1.21c-4.fc36.src requires pkgconfig(libpcre) = 8.45
sslh-1.21c-4.fc36.x86_64 requires libpcreposix.so.0()(64bit)
suricata (maintained by: jtaylor, sgrubb)
suricata-6.0.6-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
suricata-6.0.6-1.fc37.x86_64 requires libpcre.so.1()(64bit)
sway (maintained by: alebastr, fale, sway-sig, zvetlik)
sway-1.7-2.fc37.src requires pkgconfig(libpcre) = 8.45
sway-1.7-2.fc37.x86_64 requires libpcre.so.1()(64bit)
swig (maintained by: besser82, jplesnik)
swig-4.0.2-18.fc37.src requires pcre-devel = 8.45-1.fc36.1
swig-4.0.2-18.fc37.x86_64 requires libpcre.so.1()(64bit)
syncevolution (maintained by: mcrha)
syncevolution-1:2.0.0-4.fc37.src requires pcre-devel = 8.45-1.fc36.1
syncevolution-libs-1:2.0.0-4.fc37.i686 requires libpcre.so.1
syncevolution-libs-1:2.0.0-4.fc37.x86_64 requires libpcre.so.1()(64bit)
syncevolution-libs-akonadi-1:2.0.0-4.fc37.x86_64 requires
libpcre.so.1()(64bit)
syslog-ng (maintained by: czanik, jpo, mrunge)
syslog-ng-3.35.1-4.fc37.i686 requires libpcre.so.1
syslog-ng-3.35.1-4.fc37.src requires pcre-devel = 8.45-1.fc36.1
syslog-ng-3.35.1-4.fc37.x86_64 requires libpcre.so.1()(64bit)
syslog-ng-mqtt-3.35.1-4.fc37.x86_64 requires libpcre.so.1()(64bit)
syslog-ng-slog-3.35.1-4.fc37.x86_64 requires libpcre.so.1()(64bit)
the_foundation (maintained by: salimma)
the_foundation-1.4.0-1.fc37.i686 requires libpcre.so.1
the_foundation-1.4.0-1.fc37.src requires pkgconfig(libpcre) = 8.45
the_foundation-1.4.0-1.fc37.x86_64 requires libpcre.so.1()(64bit)
the_silver_searcher (maintained by: carlwgeorge, shlomif)
the_silver_searcher-2.2.0^2020704.5a1c8d8-4.fc36.src requires pcre-
devel = 8.45-1.fc36.1
the_silver_searcher-2.2.0^2020704.5a1c8d8-4.fc36.x86_64 requires
libpcre.so.1()(64bit)
tin (maintained by: adrian, rathann)
tin-2.6.1-2.fc36.src requires pcre-devel = 8.45-1.fc36.1
tin-2.6.1-2.fc36.x86_64 requires libpcre.so.1()(64bit)
tintin (maintained by: psabata)
tintin-2.02.05-4.fc36.src requires pcre-devel = 8.45-1.fc36.1
tintin-2.02.05-4.fc36.x86_64 requires libpcre.so.1()(64bit)
tinyfugue (maintained by: kellin, psabata)
tinyfugue-5.0-0.104.b8.fc36.src requires pcre-devel = 8.45-1.fc36.1
tinyfugue-5.0-0.104.b8.fc36.x86_64 requires libpcre.so.1()(64bit)
trafficserver (maintained by: jered)
trafficserver-9.1.2-9.fc37.src requires pcre-devel = 8.45-1.fc36.1
trafficserver-9.1.2-9.fc37.x86_64 requires libpcre.so.1()(64bit), pcre
= 8.45-1.fc36.1
uwsgi (maintained by: ertzing, python-sig)
uwsgi-2.0.20-7.fc37.src requires pcre-devel = 8.45-1.fc36.1
uwsgi-2.0.20-7.fc37.x86_64 requires libpcre.so.1()(64bit)
vdr-epgfixer (maintained by: martinkg)
vdr-epgfixer-0.3.1-21.20180416git354f28b.fc36.src requires pcre-devel =
8.45-1.fc36.1
vdr-epgfixer-0.3.1-21.20180416git354f28b.fc36.x86_64 requires
libpcre.so.1()(64bit)
virt-p2v (maintained by: rjones)
virt-p2v-1:1.42.1-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
watchman (maintained by: dcavalca, filbranden, salimma)
watchman-2021.05.10.00-15.fc37.src requires pcre-devel = 8.45-1.fc36.1
watchman-2021.05.10.00-15.fc37.x86_64 requires libpcre.so.1()(64bit)
webkit2gtk3 (maintained by: catanzaro, erack, gnome-sig, tpopela)
webkit2gtk3-2.37.1-10.fc37.src requires pkgconfig(libpcre) = 8.45
wireshark (maintained by: huzaifas, jlayton, mruprich, phatina, steved)
wireshark-1:3.6.2-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
wmweather+ (maintained by: sham1)
wmweather+-2.17-12.fc36.src requires pcre-devel = 8.45-1.fc36.1
wmweather+-2.17-12.fc36.x86_64 requires libpcre.so.1()(64bit)
xastir (maintained by: lucilanga)
xastir-1:2.1.4-12.fc36.src requires pcre-devel = 8.45-1.fc36.1
xastir-1:2.1.4-12.fc36.x86_64 requires libpcre.so.1()(64bit)
xfce4-verve-plugin (maintained by: nonamedotc)
xfce4-verve-plugin-2.0.1-4.fc36.src requires pcre-devel = 8.45-1.fc36.1
xfce4-verve-plugin-2.0.1-4.fc36.x86_64 requires libpcre.so.1()(64bit)
xgrep (maintained by: brendt)
xgrep-0.08-17.fc36.src requires pcre-devel = 8.45-1.fc36.1
xgrep-0.08-17.fc36.x86_64 requires libpcre.so.1()(64bit)
xmlcopyeditor (maintained by: ivazquez, mikedep333)
xmlcopyeditor-1.2.1.3-18.fc36.src requires pcre-devel = 8.45-1.fc36.1
xmlcopyeditor-1.2.1.3-18.fc36.x86_64 requires libpcre.so.1()(64bit)
yara (maintained by: aekoroglu, mikelo2, rebus)
yara-4.2.2-1.fc37.src requires pcre = 8.45-1.fc36.1
zsh (maintained by: adrienverge, dmaphy, james, kdudka, svashisht,
tibbs)
zsh-5.9-1.fc37.src requires pcre-devel = 8.45-1.fc36.1
zsh-5.9-1.fc37.x86_64 requires libpcre.so.1()(64bit)
-- Petr
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
11 a.m.
New subject: repoquery-fu (was Re: Retiring the pcre package from Fedora)
On Mon, Jul 25, 2022 at 1:50 AM Demi Marie Obenour
<demiobenour(a)gmail.com> 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
12:47 a.m.
On 7/24/22 15:42, Kalev Lember wrote:
On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini <pbonzini(a)redhat.com
<mailto:pbonzini@redhat.com>> wrote:
Il sab 23 lug 2022, 19:12 Adam Williamson
<adamwill(a)fedoraproject.org <mailto:adamwill@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
3:10 a.m.
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 <pbonzini(a)redhat.com
> <mailto:pbonzini@redhat.com>> wrote:
>
>
>
> Il sab 23 lug 2022, 19:12 Adam Williamson
> <adamwill(a)fedoraproject.org <mailto:adamwill@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/5653dff1816e4bee3c3fdbcc00f2fe...
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
3:11 a.m.
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
3:19 a.m.
On Tue, Jul 26, 2022 at 10:10 AM Kalev Lember <kalevlember(a)gmail.com> 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
3:40 a.m.
On Tue, Jul 26, 2022 at 10:19:55AM +0200, Paolo Bonzini wrote:
On Tue, Jul 26, 2022 at 10:10 AM Kalev Lember
<kalevlember(a)gmail.com> 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
3:48 a.m.
On Sun, Jul 24, 2022 at 08:58:18AM +0200, Paolo Bonzini wrote:
Il sab 23 lug 2022, 19:12 Adam Williamson
<adamwill(a)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.
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 :|
3:52 a.m.
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
3:59 a.m.
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 <pbonzini(a)redhat.com
> > <mailto:pbonzini@redhat.com>> wrote:
> >
> >
> >
> > Il sab 23 lug 2022, 19:12 Adam Williamson
> > <adamwill(a)fedoraproject.org
<mailto:adamwill@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/5653dff1816e4bee3c3fdbcc00f2fe...
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 <<EOF
#include <glib.h>
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 :|
4:07 a.m.
On Tue, Jul 26, 2022 at 10:59 AM Daniel P. Berrangé <berrange(a)redhat.com>
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 <pbonzini(a)redhat.com
> > > <mailto:pbonzini@redhat.com>> wrote:
> > >
> > >
> > >
> > > Il sab 23 lug 2022, 19:12 Adam Williamson
> > > <adamwill(a)fedoraproject.org
<mailto:adamwill@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/5653dff1816e4bee3c3fdbcc00f2fe...
>
> 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
4:16 a.m.
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é <berrange(a)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
4:46 a.m.
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 <pbonzini(a)redhat.com> 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é <berrange(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
7:25 a.m.
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 <ljavorsk(a)redhat.com> 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 <pbonzini(a)redhat.com>
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é <berrange(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
7:33 a.m.
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
<ljavorsk(a)redhat.com> 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 <pbonzini(a)redhat.com> 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é <berrange(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/
code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/
devel(a)lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/
fedora-infrastructure
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)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
ljavorsk(a)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
7:43 a.m.
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 <rjones(a)redhat.com>
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 <ljavorsk(a)redhat.com>
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 <pbonzini(a)redhat.com>
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é <
berrange(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to
devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/
> code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/
> devel(a)lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/
> fedora-infrastructure
>
>
>
> --
> S pozdravom/ Best regards
>
> Lukáš Javorský
>
> Software Engineer, Core service - Databases
>
> Red Hat
>
> Purkyňova 115 (TPB-C)
>
> 612 00 Brno - Královo Pole
>
> ljavorsk(a)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
>
> ljavorsk(a)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 <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
4:21 a.m.
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 <ljavorsk(a)redhat.com> 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 <rjones(a)redhat.com>
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 <ljavorsk(a)redhat.com>
> 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 <pbonzini(a)redhat.com>
> 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é <
> berrange(a)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(a)lists.fedoraproject.org
> > To unsubscribe send an email to
> devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/
> > code-of-conduct/
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/
> > devel(a)lists.fedoraproject.org
> > Do not reply to spam on the list, report it: https://pagure.io/
> > fedora-infrastructure
> >
> >
> >
> > --
> > S pozdravom/ Best regards
> >
> > Lukáš Javorský
> >
> > Software Engineer, Core service - Databases
> >
> > Red Hat
> >
> > Purkyňova 115 (TPB-C)
> >
> > 612 00 Brno - Královo Pole
> >
> > ljavorsk(a)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
> >
> > ljavorsk(a)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 <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
4:30 a.m.
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
8:33 a.m.
On Thu, Aug 18, 2022 at 5:30 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> 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
3:22 a.m.
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 <bcotton(a)redhat.com> wrote:
On Thu, Aug 18, 2022 at 5:30 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> 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 <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
5:22 a.m.
On Tue, Aug 23, 2022 at 10:23 AM Lukas Javorsky <ljavorsk(a)redhat.com> 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
5:38 a.m.
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 <decathorpe(a)gmail.com>
wrote:
On Tue, Aug 23, 2022 at 10:23 AM Lukas Javorsky
<ljavorsk(a)redhat.com>
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
609
days inactive
641
days old
69 comments
22 participants
participants (22)
-
Adam Williamson -
Ben Cotton -
Dan Čermák -
Daniel P. Berrangé -
Demi Marie Obenour -
Emmanuel Seyman -
Fabio Valentini -
Kalev Lember -
Kevin Kofler -
Lukas Javorsky -
Mamoru TASAKA -
Maxwell G -
Miro Hrončok -
Neal Gompa -
Paolo Bonzini -
Petr Pisar -
Richard Shaw -
Richard W.M. Jones -
Stewart Smith -
Sérgio Basto -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek