On 04/13/2015 10:28 AM, Gordan Bobic wrote: > I'm trying to do a clean-up of the packages to remove > the broken ones (e.g. pixman-0.32), clean up dependencies > (several Xorg packages in the updates-testing repository > seem to require pixman 0.32+, and I seem to recall that > there was an issue with the way evolution-data-server > dependencies were resolving that was making the update > process somewhat trickier than it should have been. > > Jacco, seen as we currently have no immediate fix or > explanation for the pixman (segfault in glibc) issue > within EL6, the options are: > > 1) Rebuild those Xorg packages against earlier, working > pixman (will that work or do they have a dependency > requirement on the later version?) I only know that the .spec file states that pixman-devel => 0.30.0 is needed. I'm not sure if this is "real" or that decreasing that version still produces a good Xorg system.
> > 2) Bodge it with the EL7 build of pixman which I seem > to recall Jacco saying works (will that actually work > properly, WRT it being linked against the EL7 version > of glibc and libgcc?) I've now no RSEL6 test system online, but "ldd /usr/lib/libpixman-1.so.0" produced a normal list of libs, all present. And it produces a GUI which did not happen with the RSEL6 build. My vote goes to 2). It is not a clean solution, but it works and allows us to keep in sync with upstream with (future) security patches with a minimum of work/patching. > > Also, Jacco, WRT evolution-data-server dependency > fixing, do I rememeber correctly that the correct > fix is to replace my latest build in the updates > repository with your build of the same version > from updates-testing? Or was it more involved than > that? > Yes. the complete list of packages involved is in my mail from 3/28. I would however advocate to rebuild them once again with a minimal version increase. That should make yum much happier and thus there should be no need of a complicated howto update text on the wiki. > Once that is all straightened out and reasonably well > tested, I am pondering moving all of the packages from > updates and updates-testing over into the base repository > and having any future updates to into the freshly cleaned > out updates repository. The process can be periodically > repeated to keep the updates repository relatively small > (lower metadata volume) and keep the base repository > changes infrequent (less metadata churn and syncing > overhead). > > Since this will involve some repository changes, it > would probably be good time to roll out an updated > release package with the new .repo and public key, and > re-sign all the packages with a new key. > > Any objections, suggestions or thoughts on this from > anyone? > another thing to keep in mind is that some of the old rpms are by now obsoleted. For example my yum shows these: tomcat6.noarch 6.0.24-62.el6 el6-update tomcat6.armv5tel 6.0.24-80.el6 updates-testing apparently upstream decided to go from "noarch" to "arch" in the rpm name, but yum is not able to resolve that, resulting in entries in the yum list that should not be installed any more. If you are interested, I should be able to create a list of rpms that are now in base or el6-updates that are not installable. Jacco _______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
