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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

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

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

On Fri, Jul 22, 2022 at 8:22 AM Lukas Javorsky ljavorsk@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

On Fri, Jul 22, 2022 at 2:32 PM Richard W.M. Jones rjones@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@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

On Fri, Jul 22, 2022 at 10:24 PM Fabio Valentini decathorpe@gmail.com wrote:

On Fri, Jul 22, 2022 at 9:44 PM Richard Shaw hobbes1069@gmail.com wrote:

...

On Fri, Jul 22, 2022 at 2:32 PM Richard W.M. Jones rjones@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@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

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).

On Fri, Jul 22, 2022 at 11:47 PM Maxwell G gotmax@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

Richard Shaw hobbes1069@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.

On Sat, Jul 23, 2022 at 12:56 PM Neal Gompa ngompa13@gmail.com wrote:

On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:

...

Richard Shaw hobbes1069@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.

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

On Sat, Jul 23, 2022 at 2:01 PM Neal Gompa ngompa13@gmail.com wrote:

On Sat, Jul 23, 2022 at 7:47 AM Fabio Valentini decathorpe@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

On Sun, Jul 24, 2022 at 11:02 AM Demi Marie Obenour demiobenour@gmail.com wrote:

On 7/23/22 07:46, Fabio Valentini wrote:

...

On Sat, Jul 23, 2022 at 12:56 PM Neal Gompa ngompa13@gmail.com wrote:

...

On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:

...

Richard Shaw hobbes1069@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

On Mon, Jul 25, 2022 at 1:50 AM Demi Marie Obenour demiobenour@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

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.

Il sab 23 lug 2022, 19:12 Adam Williamson 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.

Paolo

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

On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini pbonzini@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/34b203d5499b579c68b4f923a29fd417e...

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

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

On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA mtasaka@fedoraproject.org wrote:

...

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

...

glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs

to

...

be updated for that now so that it BuildRequires pcre2-static instead?

https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd417e...

...

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

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

On 7/24/22 15:42, Kalev Lember wrote:

On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini <pbonzini@redhat.com mailto:pbonzini@redhat.com> wrote:

Il sab 23 lug 2022, 19:12 Adam Williamson
<adamwill@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

On Tue, Jul 26, 2022 at 10:10 AM Kalev Lember kalevlember@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

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@redhat.com mailto:pbonzini@redhat.com> wrote:

Il sab 23 lug 2022, 19:12 Adam Williamson     <adamwill@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/5653dff1816e4bee3c3fdbcc00f2fea73...

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

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@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

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@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@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@redhat.com ha scritto:

...

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

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

-- S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat https://www.redhat.com

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavorsk@redhat.com https://www.redhat.com

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@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@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@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@redhat.com> ha

...

    scritto:

        Although listed in glib-2.0.pc, I didn't find any need for

the

...

        sysprof-capture-static package, but it does need glibc-static

    _______________________________________________
    devel mailing list -- devel@lists.fedoraproject.org
    To unsubscribe send an email to

devel-leave@lists.fedoraproject.org

...

    Fedora Code of Conduct:

https://docs.fedoraproject.org/en-US/project/

...

    code-of-conduct/
    List Guidelines:

https://fedoraproject.org/wiki/Mailing_list_guidelines

...

    List Archives: https://lists.fedoraproject.org/archives/list/
    devel@lists.fedoraproject.org
    Do not reply to spam on the list, report it: https://pagure.io/
    fedora-infrastructure



--
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavorsk@redhat.com

[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@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

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

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@redhat.com wrote:

On Thu, Aug 18, 2022 at 5:30 AM Zbigniew Jędrzejewski-Szmek zbyszek@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

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@gmail.com wrote:

On Tue, Aug 23, 2022 at 10:23 AM Lukas Javorsky ljavorsk@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

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.

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

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