Re: PCRE 8.30 will break API
On 2012-02-09, Petr Pisar ppi...@redhat.com wrote: It's long time since PCRE (Perl-Compatible Regular Expression) library has changed API or ABI. Version 8.30 is different. [...] Result is pcre library has changed SONAME from libpcre.so.0 to libpcre.so.1. I'm pleased to announce all reverse dependencies of PCRE have been rebuilt successfully against new libpcre.so.1 library. Old libpcre.so.0 has been removed and new library moved into /usr in pcre-8.30-2.fc18 which is landing into F18 now. I'd like to thank everybody who helped me with this transition. This PCRE upgrade will be highlighted as F18 feature https://fedoraproject.org/wiki/Features/pcre8.30. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
2012/2/13 Petr Pisar ppi...@redhat.com: Currently there is 17 packages linked against the old PCRE: monotone Fixed in monotone-1.0-7.fc18. - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On 2012-02-09, Petr Pisar ppi...@redhat.com wrote: Result is pcre library has changed SONAME from libpcre.so.0 to libpcre.so.1. Other librararies (pcrecpp, pcreposix) delivered with this package remain compatible. Because pcre library is part of minimal build root I choosed following strategy to avoid breaking Koji: (1) pcre-8.30-1 will include both new libpcre.so.1 and old libpcre.so.0. (This is done by copying old files from build root while building this new package). This has been successfully done. (2) Reverse dependencies will be rebuilt against this new library. x86_64 repository returns 109 packages: I attempted to rebuild 104 packages, 22 packages have failed. Some packages rebuilt other maintainers before me, or fixed them and rebuilt after me. Currently there is 17 packages linked against the old PCRE: cegui dansguardian gambas2 gnaughty kismet matahari medusa mod_security monotone openscada ovaldi php privoxy R regexxer syncevolution wmweather+ Most of them have been already failing before PCRE upgrade. I will investigate the failures in the future. I created PCRE 8.30 feature page for F18 https://fedoraproject.org/wiki/Features/pcre8.30 where you can track the progress. There is a link with an example how to port an application from removed pcre_info(3) to pcre_fullinfo() too. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On 2012-02-09, Sérgio Basto ser...@serjux.com wrote: On Thu, 2012-02-09 at 16:52 +, Petr Pisar wrote: It's long time since PCRE (Perl-Compatible Regular Expression) library has changed API or ABI. Version 8.30 is different. Besides UTF-16 support, the incompatible changes are described by upstream with these words: And sed is not affected ? sed does not use pcre at all. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
Am 10.02.2012 12:46, schrieb Richard W.M. Jones: On Fri, Feb 10, 2012 at 01:03:11AM +0100, Kevin Kofler wrote: Richard W.M. Jones wrote: It dlopen's the package so there is no automatic dependency. To make up for this it requires pcre-devel, but in the light of this soname change that might be a bug. It is against the guidelines to require a devel package. Actually ocaml-pcre-devel is the one which requires pcre-devel. I don't think this is against any guidelines, or if it is, it shouldn't be. that devel-packages require other devel-packages is OK but that you need ANY devel-package on machines having not installed any compiler/packaging-software not this machine as example has not a single devel-package over years and some time ago all these were introduced by a packaging mistake package-maintainers should have some CLEAN virtual machine to test if their new versions are introducing new dependencies at all because mostly ANY dpendencie will have another ones over the long and its frustrating to play around all 3 months to look if some of them got relaxed [root@arrakis:~]$ yum remove \*-devel Geladene Plugins: downloadonly, protectbase Einrichten des Entfernungsprozess Löse Abhängigkeiten auf -- Führe Transaktionsprüfung aus --- Package apr-devel.x86_64 0:1.4.5-1.fc15.20111201.rh will be gelöscht --- Package apr-util-devel.x86_64 0:1.3.12-1.fc15 will be gelöscht --- Package cyrus-sasl-devel.x86_64 0:2.1.23-18.fc15 will be gelöscht --- Package db4-devel.x86_64 0:4.8.30-3.fc15 will be gelöscht --- Package expat-devel.x86_64 0:2.0.1-11.fc15 will be gelöscht --- Package httpd-devel.x86_64 0:2.2.22-2.fc15.20120201.rh will be gelöscht --- Package mod_perl-devel.x86_64 0:2.0.5-1.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl(Apache::SizeLimit::Core) für Paket: mod_perl-2.0.5-1.fc15.x86_64 --- Package openldap-devel.x86_64 0:2.4.24-5.fc15 will be gelöscht --- Package perl-devel.x86_64 4:5.12.4-164.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl-devel für Paket: 1:perl-ExtUtils-ParseXS-2.2206-164.fc15.noarch -- Verarbeite Abhängigkeiten: perl-devel für Paket: perl-ExtUtils-Embed-1.28-164.fc15.noarch -- Verarbeite Abhängigkeiten: perl-devel für Paket: perl-Test-Harness-3.17-164.fc15.noarch -- Verarbeite Abhängigkeiten: perl-devel für Paket: perl-ExtUtils-MakeMaker-6.56-164.fc15.noarch -- Verarbeite Abhängigkeiten: perl-devel für Paket: perl-Test-Simple-0.98-1.fc15.noarch --- Package systemtap-sdt-devel.x86_64 0:1.6-1.fc15 will be gelöscht -- Führe Transaktionsprüfung aus --- Package mod_perl.x86_64 0:2.0.5-1.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl(Apache2::Const) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(Apache2::Log) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(Apache2::RequestIO) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(Apache2::RequestRec) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(Apache2::RequestUtil) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(APR::Table) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch --- Package perl-ExtUtils-Embed.noarch 0:1.28-164.fc15 will be gelöscht --- Package perl-ExtUtils-MakeMaker.noarch 0:6.56-164.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl(ExtUtils::MakeMaker) für Paket: perl-CPAN-1.9402-164.fc15.noarch --- Package perl-ExtUtils-ParseXS.noarch 1:2.2206-164.fc15 will be gelöscht --- Package perl-Test-Harness.noarch 0:3.17-164.fc15 will be gelöscht --- Package perl-Test-Simple.noarch 0:0.98-1.fc15 will be gelöscht -- Führe Transaktionsprüfung aus --- Package perl-CPAN.noarch 0:1.9402-164.fc15 will be gelöscht --- Package perl-SOAP-WSDL.noarch 0:2.00.10-10.fc15.20111201.rh will be gelöscht -- Verarbeite Abhängigkeiten: perl(SOAP::WSDL) für Paket: perl-Net-DRI-0.96-2.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl-SOAP-WSDL für Paket: perl-Net-DRI-0.96-2.fc15.20111201.rh.noarch -- Führe Transaktionsprüfung aus --- Package perl-Net-DRI.noarch 0:0.96-2.fc15.20111201.rh will be gelöscht -- Abhängigkeitsauflösung beendet lounge-buildserver | 2.9 kB 00:00 ... lounge-cache | 2.9 kB 00:00 Abhängigkeiten aufgelöst Paket Arch Version RepositoryGrösse Entfernen: apr-devel x86_64 1.4.5-1.fc15.20111201.rh @lounge-buildserver 767 k
Re: PCRE 8.30 will break API
On 2012-02-10, Reindl Harald h.rei...@thelounge.net wrote: that devel-packages require other devel-packages is OK but that you need ANY devel-package on machines having not installed any compiler/packaging-software not You can have a tool which creates binding to native shared objects at run-time. Then header files are good input for such generator. OTOH such tool is usuallay a developer tool. This is just to show each rule hase an exception. package-maintainers should have some CLEAN virtual machine to test if their new versions are introducing new dependencies Packager can check it using rpmdiff on old and updated package. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
Richard W.M. Jones wrote: Actually ocaml-pcre-devel is the one which requires pcre-devel. I don't think this is against any guidelines, or if it is, it shouldn't be. No, that makes sense. Your message wasn't clear about that. Instead, the software MUST be patched to dlopen the fully versioned so from the runtime package instead. If I understand what you mean, the software does this already. The bug is that there's no explicit (or implicit) dependency to tell RPM that it's doing this. There needs to be at least a Requires: pcre. I guess a Requires on the exact soname being dlopened would be more robust, but then you need to take care of that pesky '()(64bit)' multilib suffix. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On Fri, Feb 10, 2012 at 04:24:43PM +0100, Kevin Kofler wrote:
Richard W.M. Jones wrote:
Actually ocaml-pcre-devel is the one which requires pcre-devel. I
don't think this is against any guidelines, or if it is, it shouldn't
be.
No, that makes sense. Your message wasn't clear about that.
Instead, the software MUST be patched to dlopen the fully versioned
so from the runtime package instead.
If I understand what you mean, the software does this already. The
bug is that there's no explicit (or implicit) dependency to tell RPM
that it's doing this.
There needs to be at least a Requires: pcre. I guess a Requires on the exact
soname being dlopened would be more robust, but then you need to take care
of that pesky '()(64bit)' multilib suffix.
Well now, now that everything's in the same directory, can't we use
%{_libdir}/libpcre.so.1 :-?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On Thu, Feb 9, 2012 at 10:52 AM, Petr Pisar ppi...@redhat.com wrote: It's long time since PCRE (Perl-Compatible Regular Expression) library has changed API or ABI. Version 8.30 is different. Besides UTF-16 support, the incompatible changes are described by upstream with these words: . The pcre_info() function, which has been obsolete for over 10 years, has been removed. . When a compiled pattern was saved to a file and later reloaded on a host with different endianness, PCRE used automatically to swap the bytes in some of the data fields. With the advent of the 16-bit library, where more of this swapping is needed, it is no longer done automatically. Instead, the bad endianness is detected and a specific error is given. The user can then call a new function called pcre_pattern_to_host_byte_order() (or an equivalent 16-bit function) to do the swap. . In UTF-8 mode, the values 0xd800 to 0xdfff are not legal Unicode code points and are now faulted. (They are the so-called surrogates that are reserved for coding high values in UTF-16.) Result is pcre library has changed SONAME from libpcre.so.0 to libpcre.so.1. Other librararies (pcrecpp, pcreposix) delivered with this package remain compatible. Because pcre library is part of minimal build root I choosed following strategy to avoid breaking Koji: When do you anticipate that this will hit? Thanks for the heads up! -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On 2012-02-09, Jon Ciesla limburg...@gmail.com wrote: On Thu, Feb 9, 2012 at 10:52 AM, Petr Pisar ppi...@redhat.com wrote: Result is pcre library has changed SONAME from libpcre.so.0 to libpcre.so.1. Other librararies (pcrecpp, pcreposix) delivered with this package remain compatible. Because pcre library is part of minimal build root I choosed following strategy to avoid breaking Koji: When do you anticipate that this will hit? Now :) pcre-8.30-1.fc18 is the first build bringing both libraries. I did thorough tests in virtual machine and the system boots even with new pcre. Just to make all parties easy, this build targets F18 only. There is no plan to put it into F17. Actully I postponed the 8.30 build until branching F17. I will start rebuilding listed packages on Friday. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On Thu, Feb 9, 2012 at 11:46 AM, Petr Pisar ppi...@redhat.com wrote: On 2012-02-09, Jon Ciesla limburg...@gmail.com wrote: On Thu, Feb 9, 2012 at 10:52 AM, Petr Pisar ppi...@redhat.com wrote: Result is pcre library has changed SONAME from libpcre.so.0 to libpcre.so.1. Other librararies (pcrecpp, pcreposix) delivered with this package remain compatible. Because pcre library is part of minimal build root I choosed following strategy to avoid breaking Koji: When do you anticipate that this will hit? Now :) pcre-8.30-1.fc18 is the first build bringing both libraries. I did thorough tests in virtual machine and the system boots even with new pcre. Just to make all parties easy, this build targets F18 only. There is no plan to put it into F17. Actully I postponed the 8.30 build until branching F17. I will start rebuilding listed packages on Friday. Outstanding, thanks! -J -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
Le 09/02/2012 17:52, Petr Pisar a écrit : php php 5.4.0RC7 won't build. I know the fix have been commited, http://svn.php.net/viewvc?view=revisionrevision=323096 http://svn.php.net/viewvc?view=revisionrevision=323097 so will be in 5.4.0 final, planned for February 16. So, you can probably skip this one. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On Thu, Feb 09, 2012 at 04:52:57PM +, Petr Pisar wrote: ocaml-ocamlnet ocaml-pcre It dlopen's the package so there is no automatic dependency. To make up for this it requires pcre-devel, but in the light of this soname change that might be a bug. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
PP == Petr Pisar ppi...@redhat.com writes: PP zoneminder Went ahead and rebuilt it now as I intend to be working on it tomorrow. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On Thu, 9 Feb 2012 16:52:57 + (UTC) Petr Pisar ppi...@redhat.com wrote: (2) Reverse dependencies will be rebuilt against this new library. x86_64 repository returns 109 packages: ... proftpd I've done the proftpd rebuild. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On Thu, 2012-02-09 at 16:52 +, Petr Pisar wrote: It's long time since PCRE (Perl-Compatible Regular Expression) library has changed API or ABI. Version 8.30 is different. Besides UTF-16 support, the incompatible changes are described by upstream with these words: . The pcre_info() function, which has been obsolete for over 10 years, has been removed. . When a compiled pattern was saved to a file and later reloaded on a host with different endianness, PCRE used automatically to swap the bytes in some of the data fields. With the advent of the 16-bit library, where more of this swapping is needed, it is no longer done automatically. Instead, the bad endianness is detected and a specific error is given. The user can then call a new function called pcre_pattern_to_host_byte_order() (or an equivalent 16-bit function) to do the swap. . In UTF-8 mode, the values 0xd800 to 0xdfff are not legal Unicode code points and are now faulted. (They are the so-called surrogates that are reserved for coding high values in UTF-16.) Result is pcre library has changed SONAME from libpcre.so.0 to libpcre.so.1. Other librararies (pcrecpp, pcreposix) delivered with this package remain compatible. Because pcre library is part of minimal build root I choosed following strategy to avoid breaking Koji: (1) pcre-8.30-1 will include both new libpcre.so.1 and old libpcre.so.0. (This is done by copying old files from build root while building this new package). (2) Reverse dependencies will be rebuilt against this new library. x86_64 repository returns 109 packages: adanaxisgpl blender bti cclive ccze cduce cegui cegui06 cfengine classads coccinelle collada-dom condor dansguardian EMBOSS eterm ettercap exim fsniper gambas2 gambas3 ganglia ghc-hakyll ghc-pcre-light ghc-regex-pcre git gnaughty gnome-mud gnote gource grep gsmartcontrol gxneur haproxy highlighting-kate httpd imapfilter Io-language kannel kaya kdelibs kdelibs3 kismet leafnode ledger less libast libguestfs lighttpd logstalgia lua-rex maildrop matahari mboxgrep mcstrans medusa mod_security mongodb monotone mysql-workbench nekovm nginx ngrep nmap ocaml-ocamlnet octave openCOLLADA openscada openscap opensips ovaldi pads pandoc perl-HTML-Template-Pro php picviz pidgin-musictracker poco postfix prelude-lml privoxy proftpd R regexxer rekall root scilab slang spring-installer sssd suricata swig syncevolution syslog-ng tabled Thunar tin tintin tinyfugue varnish wmweather+ xastir xfce4-verve-plugin xgrep xmlcopyeditor xneur znc-infobot zoneminder 389-ds-base (3) pcre package will be rebuilt again without the old libpcre.so.0 library. The usr-move of /lib*/libpcre.so* will proceede in this or another rebuild. And sed is not affected ? I got a problem with kmk_sed from kBuild, which change his behavior on F-17, I don't know exactly when, if it is gcc 4.7 if it is glibc , but just in case could you rebuild kBuild ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
Richard W.M. Jones wrote: It dlopen's the package so there is no automatic dependency. To make up for this it requires pcre-devel, but in the light of this soname change that might be a bug. It is against the guidelines to require a devel package. Instead, the software MUST be patched to dlopen the fully versioned so from the runtime package instead. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
Am 10.02.2012 01:03, schrieb Kevin Kofler: Richard W.M. Jones wrote: It dlopen's the package so there is no automatic dependency. To make up for this it requires pcre-devel, but in the light of this soname change that might be a bug. It is against the guidelines to require a devel package. Instead, the software MUST be patched to dlopen the fully versioned so from the runtime package instead. so hopefully someone will take care of mod_perl requires mod_perl-devel too https://bugzilla.redhat.com/show_bug.cgi?id=771800 [root@arrakis:~]$ yum remove mod_perl-devel-2.0.5-1.fc15.x86_64 Geladene Plugins: downloadonly, protectbase Einrichten des Entfernungsprozess Löse Abhängigkeiten auf -- Führe Transaktionsprüfung aus --- Package mod_perl-devel.x86_64 0:2.0.5-1.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl(Apache::SizeLimit::Core) für Paket: mod_perl-2.0.5-1.fc15.x86_64 -- Führe Transaktionsprüfung aus --- Package mod_perl.x86_64 0:2.0.5-1.fc15 will be gelöscht since this change it would also remove self maintained packages while over a logn time no single devel-package was installed on any server * perl-Net-DRI * perl-SOAP-WSDL signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
