Bug#1000000: fixed in phast 1.6+dfsg-2
Am Sat, Nov 20, 2021 at 10:30:18AM + schrieb Holger Levsen: > congrats to the Debian Med team for filing #100 *and* fixing it so > quickly! > well done & well deserved to hit this "special bug" :) Thanks a lot. I admit it was not a trivial one but I was motivated to spent some hours on it (after I was wrong in my first was to simple fix). ;-) Kind regards Andreas. -- http://fam-tille.de
Bug#1000000: fixed in phast 1.6+dfsg-2
congrats to the Debian Med team for filing #100 *and* fixing it so quickly! well done & well deserved to hit this "special bug" :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Words may inspire but only action creates change. signature.asc Description: PGP signature
Bug#1000000: fixed in phast 1.6+dfsg-2
Hi, Am Thu, Nov 18, 2021 at 11:12:12PM +0200 schrieb Adrian Bunk: > On Thu, Nov 18, 2021 at 05:12:10PM +0100, Sebastiaan Couwenberg wrote: > >... > > For the Debian package you could drop use_debian_packaged_libpcre.patch and > > use the embedded copy to not block the prce3 removal in Debian. > > As a general comment, this would be a lot worse than keeping pcre3. Since I agree here I started (! not working yet!) with a patch[2]. I remember that upstream - who has basically stopped development if I remember correctly - was not even happy, that we replace the code copy. Thus I assume that they are not very interested in providing a pcre2 patch and we are on our own. > If any copy of this library should be used at all in bookworm, > it should be provided by src:pcre3. I agree and I assume we will need this. Several packages that received this bug report are not actively developed any more but used by our users. So it might be that we need to work on this ourselves and this needs time (and knowledge). > Switching from src:pcre3 to an older vendored copy would likely create > additional security vulnerabilities for our users,[1] even with only one > user in bookworm shipping it security supportable in src:pcre3 would be > better than hiding vulnerabilities through vendoring. +1 Kind regards Andreas. > [1] https://security-tracker.debian.org/tracker/source-package/pcre3 [2] https://salsa.debian.org/med-team/phast/-/blob/master/debian/patches/pcre2.patch -- http://fam-tille.de
Bug#1000000: fixed in phast 1.6+dfsg-2
On Thu, Nov 18, 2021 at 05:12:10PM +0100, Sebastiaan Couwenberg wrote: >... > For the Debian package you could drop use_debian_packaged_libpcre.patch and > use the embedded copy to not block the prce3 removal in Debian. As a general comment, this would be a lot worse than keeping pcre3. If any copy of this library should be used at all in bookworm, it should be provided by src:pcre3. Switching from src:pcre3 to an older vendored copy would likely create additional security vulnerabilities for our users,[1] even with only one user in bookworm shipping it security supportable in src:pcre3 would be better than hiding vulnerabilities through vendoring. > Kind Regards, > > Bas cu Adrian [1] https://security-tracker.debian.org/tracker/source-package/pcre3
Bug#1000000: fixed in phast 1.6+dfsg-2
reopen 100 notfixed 100 phast/1.6+dfsg-2 thanks On Thu, 18 Nov 2021 14:40:53 + Debian FTP Masters wrote: * Build-Depends: s/libpcre3-dev/libpcre2-dev/ That's not sufficient, the upstream code needs to be ported to use the PCRE2 API and link to libprce2. For the Debian package you could drop use_debian_packaged_libpcre.patch and use the embedded copy to not block the prce3 removal in Debian. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
