From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-February/012354.html | 108 +++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-February/012354.html (limited to 'zarb-ml/mageia-dev/2012-February/012354.html') diff --git a/zarb-ml/mageia-dev/2012-February/012354.html b/zarb-ml/mageia-dev/2012-February/012354.html new file mode 100644 index 000000000..f0c94328d --- /dev/null +++ b/zarb-ml/mageia-dev/2012-February/012354.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Build system broken + + + + + + + + + +

[Mageia-dev] Build system broken

+ David Walser + luigiwalser at yahoo.com +
+ Sun Feb 26 13:55:28 CET 2012 +

+
+ +
David Walser wrote:
+> For some reason, the build system is trying to install libnss3 into every chroot.  I don't know why.  It is also trying to install the 
+current 
+> version in Cauldron, rather than a known good version.
+> 
+> The issue was introduced when nspr was updated to version 4.9, because the package provides version 4.9, but the pkg-config file says 4.9.0 
+is 
+> the version.
+> 
+> The breakage happened when updating the nss package, and it has a macro in it that generates the version of libnspr4 it requires from the 
+pkg-
+> config file in nspr.  So basically, we have libnspr4-4.9, but libnss3 is requiring libnspr4-4.9.0 and doesn't think it exists.
+> 
+> I committed a change in svn for nspr that I believe will fix this, but nspr needs to be able to be rebuilt, so that nss can be rebuilt 
+against 
+> it.  For anything to be built, the build system needs to either stop trying to install libnss3, or it needs to install the previous version 
+of 
+> the package.
+
+Thank you to D Morgan for fixing it.  I apologize for making sure that nss not only built, but also installed correctly before uploading it.
+
+This got me to thinking, however, that something like this should not have broken the build system.  There's no reason for iurt to be setting 
+up the chroot with packages from Cauldron, unless they are part of the BuildRequires (including recursively) for the package being built.  In 
+this situation, once a package needed in the base of the chroot is broken, there is no way to fix it without sysadmin intervention.  This 
+would be true for a broken package in Cauldron, or stable/updates_testing.
+
+I believe a better way for iurt to work would be this.  It would set up the initial chroot from the newest stable release of Mageia that is 
+the same version of Mageia the package is being built for, or older.  So right now, that would mean Mageia 1 in all cases.  Once Mageia 2 is 
+out, it would mean Mageia 2 for packages being built for 2 or Cauldron, and Mageia 1 for packages being built for 1.  Also, when the initial 
+chroot was being installed, release and updates would be enabled only.  Then, when it gets to the BuildRequires stage, first enable either 
+updates_testing if it's being built for a stable relase, or Cauldron if it's being built for that, and then install the BuildRequires and 
+build the package.
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1