Packages built and released for Fedora EPEL testing/5: 7
duplicity-0.4.9-1.el5 eggdrop-1.6.18-14.el5 NEW ngircd-0.11.0-1.el5 : Next Generation IRC Daemon perl-Net-LibIDN-0.10-1.el5 php-pear-Log-1.10.0-1.el5 superiotool-0-0.9.20080210svn3064.el5 xerces-c-2.8.0-1.el5
Packages built and released for Fedora EPEL testing/4: 5
duplicity-0.4.9-1.el4 eggdrop-1.6.18-14.el4 perl-Net-LibIDN-0.10-1.el4 superiotool-0-0.9.20080210svn3064.el4 xerces-c-2.8.0-1.el4
Changes in Fedora EPEL testing/5:
duplicity-0.4.9-1.el5 --------------------- * Sun Feb 10 2008 Robert Scheck robert@fedoraproject.org 0.4.9-1 - Upgrade to 0.4.9 (#293081, #431467)
* Sat Dec 08 2007 Robert Scheck robert@fedoraproject.org 0.4.7-1 - Upgrade to 0.4.7
eggdrop-1.6.18-14.el5 --------------------- * Sun Feb 10 2008 Robert Scheck robert@fedoraproject.org 1.6.18-14 - Added patch to provide better non-latin support (#429621)
* Sat Jan 05 2008 Robert Scheck robert@fedoraproject.org 1.6.18-13 - Rebuild for tcl 8.5
ngircd-0.11.0-1.el5 ------------------- * Mon Feb 11 2008 Andreas Thienemann andreas@bawue.net 0.11.0-1 - Updated to 0.11.0
perl-Net-LibIDN-0.10-1.el5 -------------------------- * Sun Feb 10 2008 Robert Scheck robert@fedoraproject.org 0.10-1 - Upgrade to 0.10
php-pear-Log-1.10.0-1.el5 ------------------------- * Sat Jan 26 2008 Remi Collet Fedora@FamilleCollet.com 1.10.0-1 - update to 1.10.0 - add Requires php-pear(Mail) (new handler) - remove levels.patch (merged upstream)
superiotool-0-0.9.20080210svn3064.el5 ------------------------------------- * Sun Feb 10 2008 Peter Lemenkov lemenkov@gmail.com 0-0.9.20080210svn3064 - svn ver. 3064 - Added more Winbond W83627EHF chips
xerces-c-2.8.0-1.el5 -------------------- * Sun Feb 10 2008 Peter Lemenkov lemenkov@gmail.com 2.8.0-1 - Ver. 2.8.0
Changes in Fedora EPEL testing/4:
duplicity-0.4.9-1.el4 --------------------- * Sun Feb 10 2008 Robert Scheck robert@fedoraproject.org 0.4.9-1 - Upgrade to 0.4.9 (#293081, #431467)
* Sat Dec 08 2007 Robert Scheck robert@fedoraproject.org 0.4.7-1 - Upgrade to 0.4.7
eggdrop-1.6.18-14.el4 --------------------- * Sun Feb 10 2008 Robert Scheck robert@fedoraproject.org 1.6.18-14 - Added patch to provide better non-latin support (#429621)
* Sat Jan 05 2008 Robert Scheck robert@fedoraproject.org 1.6.18-13 - Rebuild for tcl 8.5
perl-Net-LibIDN-0.10-1.el4 -------------------------- * Sun Feb 10 2008 Robert Scheck robert@fedoraproject.org 0.10-1 - Upgrade to 0.10
superiotool-0-0.9.20080210svn3064.el4 ------------------------------------- * Sun Feb 10 2008 Peter Lemenkov lemenkov@gmail.com 0-0.9.20080210svn3064 - svn ver. 3064 - Added more Winbond W83627EHF chips
xerces-c-2.8.0-1.el4 -------------------- * Sun Feb 10 2008 Peter Lemenkov lemenkov@gmail.com 2.8.0-1 - Ver. 2.8.0
On Monday 11 February 2008, buildsys@fedoraproject.org wrote:
Packages built and released for Fedora EPEL testing/5: 7
[...]
xerces-c-2.8.0-1.el5Packages built and released for Fedora EPEL testing/4: 5
[...]
xerces-c-2.8.0-1.el4
This is a soname bump from libxerces-c.so.27 to libxerces-c.so.28, and looks like it would break at least enigma, gdal, ovaldi, perl-XML-Xerces and xalan-c, not to mention local packages and other local builds.
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-b2927ee3158358... (soname bump is an ABI change)
I haven't seen even a "HEADS UP" mail about this. Without a very good reason, this is far from acceptable in EPEL.
BTW, looks like this update is on its way to Fedora too, it'll break even more packages there. And not even a heads up mail seen on fedora-devel either.
Please explain?
Hello All!
2008/2/12, Ville Skyttä ville.skytta@iki.fi:
On Monday 11 February 2008, buildsys@fedoraproject.org wrote:
Packages built and released for Fedora EPEL testing/5: 7
[...]
xerces-c-2.8.0-1.el5Packages built and released for Fedora EPEL testing/4: 5
[...]
xerces-c-2.8.0-1.el4This is a soname bump from libxerces-c.so.27 to libxerces-c.so.28, and looks like it would break at least enigma, gdal, ovaldi, perl-XML-Xerces and xalan-c, not to mention local packages and other local builds.
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-b2927ee3158358... (soname bump is an ABI change)
I haven't seen even a "HEADS UP" mail about this. Without a very good reason, this is far from acceptable in EPEL.
Agree - it should be dropped from EPEL-testing.
BTW, looks like this update is on its way to Fedora too, it'll break even more packages there. And not even a heads up mail seen on fedora-devel either.
Please explain?
Sorry for this. I just forgot to mention about this incompatibility during mass rebuilds for gcc4.3. I'll revoke requests for update from F-7 and F-8 ASAP.
I want to keep new version for devel-branch though.
Peter Lemenkov wrote:
Hello All!
2008/2/12, Ville Skyttä ville.skytta@iki.fi:
On Monday 11 February 2008, buildsys@fedoraproject.org wrote:
Packages built and released for Fedora EPEL testing/5: 7
[...]
xerces-c-2.8.0-1.el5Packages built and released for Fedora EPEL testing/4: 5
[...]
xerces-c-2.8.0-1.el4This is a soname bump from libxerces-c.so.27 to libxerces-c.so.28, and looks like it would break at least enigma, gdal, ovaldi, perl-XML-Xerces and xalan-c, not to mention local packages and other local builds.
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-b2927ee3158358... (soname bump is an ABI change)
I haven't seen even a "HEADS UP" mail about this. Without a very good reason, this is far from acceptable in EPEL.
Agree - it should be dropped from EPEL-testing.
BTW, looks like this update is on its way to Fedora too, it'll break even more packages there. And not even a heads up mail seen on fedora-devel either.
Please explain?
I was about to post something along the same line and I actually mailed perl-XML-Xerces upstream yesterday. There is no perl-XML-Xerces version that can be compiled against xerces-c-2.8.0 and there won't be in the near future. http://marc.info/?l=xerces-p-dev&m=120277940726111&w=2
Sorry for this. I just forgot to mention about this incompatibility during mass rebuilds for gcc4.3. I'll revoke requests for update from F-7 and F-8 ASAP.
I want to keep new version for devel-branch though.
Even if the soname bump is a no-no for EPEL, there's no way to update the perl package in Fedora either, so I'd be very grateful if the xerces-c update never hits Fedora stable. I don't really care about devel, but the perl package will likely remain broken there until xerces-3.0.
Regards, Xavier
On 12.02.2008 09:11, Peter Lemenkov wrote:
2008/2/12, Ville Skyttä ville.skytta@iki.fi:
On Monday 11 February 2008, buildsys@fedoraproject.org wrote:
Packages built and released for Fedora EPEL testing/5: 7
[...]
xerces-c-2.8.0-1.el5Packages built and released for Fedora EPEL testing/4: 5
[...]
xerces-c-2.8.0-1.el4This is a soname bump from libxerces-c.so.27 to libxerces-c.so.28, and looks like it would break at least enigma, gdal, ovaldi, perl-XML-Xerces and xalan-c, not to mention local packages and other local builds. http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-b2927ee3158358... (soname bump is an ABI change) I haven't seen even a "HEADS UP" mail about this.
Hopefully sooner or later Fedora and EPEL get tests script that notice such things before they hit the repo :-/
Without a very good reason, this is far from acceptable in EPEL.
Agree - it should be dropped from EPEL-testing.
Gone.
[...]
CU knurd
On Tue, 12 Feb 2008 09:45:20 +0100, Thorsten Leemhuis wrote:
On 12.02.2008 09:11, Peter Lemenkov wrote:
2008/2/12, Ville Skyttä ville.skytta@iki.fi:
On Monday 11 February 2008, buildsys@fedoraproject.org wrote:
Packages built and released for Fedora EPEL testing/5: 7
[...]
xerces-c-2.8.0-1.el5Packages built and released for Fedora EPEL testing/4: 5
[...]
xerces-c-2.8.0-1.el4This is a soname bump from libxerces-c.so.27 to libxerces-c.so.28, and looks like it would break at least enigma, gdal, ovaldi, perl-XML-Xerces and xalan-c, not to mention local packages and other local builds. http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-b2927ee3158358... (soname bump is an ABI change) I haven't seen even a "HEADS UP" mail about this.
Hopefully sooner or later Fedora and EPEL get tests script that notice such things before they hit the repo :-/
Remember that with Plague successful builds enter the buildroot repos, so even if they are not pushed, they can break the buildroots and can also cause other builds to become incompatible meanwhile. It's better if maintainers check for ABI- and API-breakage prior to building such packages. Especially, since a repoclosure check would only noticed changed SONAMEs and not other changes in a library interface (such as removed symbols, signatures).
On 12.02.2008 11:33, Michael Schwendt wrote:
On Tue, 12 Feb 2008 09:45:20 +0100, Thorsten Leemhuis wrote:
On 12.02.2008 09:11, Peter Lemenkov wrote:
2008/2/12, Ville Skyttä ville.skytta@iki.fi:
On Monday 11 February 2008, buildsys@fedoraproject.org wrote:
Packages built and released for Fedora EPEL testing/5: 7
[...]
xerces-c-2.8.0-1.el5Packages built and released for Fedora EPEL testing/4: 5
[...]
xerces-c-2.8.0-1.el4This is a soname bump from libxerces-c.so.27 to libxerces-c.so.28, and looks like it would break at least enigma, gdal, ovaldi, perl-XML-Xerces and xalan-c, not to mention local packages and other local builds. http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-b2927ee3158358... (soname bump is an ABI change) I haven't seen even a "HEADS UP" mail about this.
Hopefully sooner or later Fedora and EPEL get tests script that notice such things before they hit the repo :-/
Remember that with Plague successful builds enter the buildroot repos,
Sure, but the plan is to move to Koji and Bodhi over the next few months, so this problems vanishes, as Koji handles things differently.
so even if they are not pushed, they can break the buildroots and can also cause other builds to become incompatible meanwhile. It's better if maintainers check for ABI- and API-breakage prior to building such packages.
Of course. But it seems to me that it doesn't work perfectly (¹) -- it's not the first time that a problem like this one comes up in Fedora or EPEL. So afaics we need to remind people somehow explicitly that they might break deps when they build a updates that provides a lib with a different SONAME.
(¹) -- maybe better contributer education could help, but that's something that should dealt with in Fedora-land, as it's not really a EPEL specific problem
Especially, since a repoclosure check would only noticed changed SONAMEs and not other changes in a library interface (such as removed symbols, signatures).
Agreed. But note that I didn't actually mean repoclosure here -- more a diff between the output of "rpm -qp foo.rpm --provides" between the old and the new package and a heads up to everyone (or something else; maybe even put the rpm aside temporary) if a SONAME changed.
CU knurd
On Tue, 12 Feb 2008 11:58:23 +0100, Thorsten Leemhuis wrote:
Especially, since a repoclosure check would only noticed changed SONAMEs and not other changes in a library interface (such as removed symbols, signatures).
Agreed. But note that I didn't actually mean repoclosure here -- more a diff between the output of "rpm -qp foo.rpm --provides" between the old and the new package and a heads up to everyone (or something else; maybe even put the rpm aside temporary) if a SONAME changed.
rpmdevtools' rpmsodiff and rpmsoname can help with that. abicheck examines a binary for unbound/private symbols. Library packagers just need to use some of the available tools. Even repoquery --alldeps is not popular enough yet.
I understand you want a buildsys to perform sanity checks. That requires a lot of work, however.
On 12.02.2008 12:29, Michael Schwendt wrote:
On Tue, 12 Feb 2008 11:58:23 +0100, Thorsten Leemhuis wrote:
Especially, since a repoclosure check would only noticed changed SONAMEs and not other changes in a library interface (such as removed symbols, signatures).
Agreed. But note that I didn't actually mean repoclosure here -- more a diff between the output of "rpm -qp foo.rpm --provides" between the old and the new package and a heads up to everyone (or something else; maybe even put the rpm aside temporary) if a SONAME changed.
rpmdevtools' rpmsodiff and rpmsoname can help with that.
/me somehow missed those tools
Nice, thx for the pointer.
$ rpm -q rpmdevtools --changelog | grep -A 1 rpmsodiff - Include rpmsodiff and dependencies (rpmargs, rpmelfsym, rpmfile, rpmpeek, rpmsoname) from ALT Linux's qa-robot package.
/me wonders what that qa-robot is and if it would be useful for us
[...] I understand you want a buildsys to perform sanity checks. That requires a lot of work, however.
Not sure if it should be actually the buildsys that should do the work. I always imagined there should be a dedicated system that just grabs freshly build rpms and does those checks.
But yeah, likely still a lot of work.
CU knurd
On Tuesday 12 February 2008, Thorsten Leemhuis wrote:
/me wonders what that qa-robot is and if it would be useful for us
http://git.altlinux.org/people/at/packages/?p=qa-robot.git;a=tree git://git.altlinux.org/people/at/packages/qa-robot
epel-devel@lists.fedoraproject.org
-
Fedora Koji Build System -
Michael Schwendt -
Peter Lemenkov -
Thorsten Leemhuis -
Ville Skyttä -
Xavier Bachelot