ARM – The Secret is Out – ‘Pidora 2014’ is Here..
Thanks to invaluable information from Mace Moneta, I have now been able to find the location of the (recent) release of Pidora 20 — now, for some reason, known as ‘Pidora 2014‘..
For details and links, see the comments section at the bottom of my previous article: http://rglinuxtech.com/?p=1048
I started the upgrade (from Pidora 19), which took several hours after the downloads had finished, and showed just how slow the Pi is!
After the download had completed, the first attempt to upgrade failed:
Running transaction check Running transaction test Transaction check error: file /usr/share/pixmaps/poweredby.png conflicts between attempted installs of pidora-logos-1-5.rpfr20.noarch and fedora-logos-httpd-21.0.1-1.fc20.noarch
So.. I re-ran the upgrade, as follows:
# yum --nogpgcheck distro-sync --exclude=pidora-logos
Many warning messages scrolled by:
....... /sbin/ldconfig: libraries libgpg-error.so.0.9.0 and libgpg-error.so.0.10.0 in directory /lib have same soname but different type. Updating : 2:libogg-1.3.0-6.fc20.armv6hl 101/2042 /sbin/ldconfig: libraries libfreetype.so.6.10.0 and libfreetype.so.6.10.2 in directory /lib have same soname but different type. /sbin/ldconfig: libraries libgpg-error.so.0.9.0 and libgpg-error.so.0.10.0 in directory /lib have same soname but different type. Updating : libtevent-0.9.19-1.fc20.armv6hl 102/2042 /sbin/ldconfig: libraries libfreetype.so.6.10.0 and libfreetype.so.6.10.2 in directory /lib have same soname but different type. /sbin/ldconfig: libraries libgpg-error.so.0.9.0 and libgpg-error.so.0.10.0 in directory /lib have same soname but different type. ......... etc...
But – finally – the upgrade completed..
Then, any attempt to do a # yum update failed, due to the previous conflict:
Transaction check error: file /usr/share/pixmaps/poweredby.png from install of pidora-logos-1-5.rpfr20.noarch conflicts with file from package fedora-logos-httpd-21.0.1-1.fc20.noarch
The usual # yum -y update –nogpgcheck –skip-broken doesn’t fix this, and this conflict stops any further yum updates from completing…
So… I manually downloaded the pidora-logos-1-5.rpfr20.noarch rpm, from http://koji.pidora.ca/koji/buildinfo?buildID=77112, and ‘forced’ the install, using
rpm -ivh <rpm file> --nodeps --force..
Finally!
Pidora release 2014 (Raspberry Pi Fedora Remix) Kernel 3.13.3+ on an armv6l (ttyAMA0)
– and Yum works OK, now..
After all the hard work that has gone in to producing this Pidora distro, I can’t understand why the release is so badly publicised.. The ‘Pidora’ Wiki hasn’t been updated for months, and still just refers to ‘Pidora 18’, as does the entry on the Raspberry Pi website itself.. Hopefully this will change, soon..
Robert Gadsdon. February 18, 2014.
Yes I also contacted Mace a few weeks ago and followed his method. I had to dispose of some gnome and NetworkManager packages amongst others to get a clean transition from Pidora 18 to Pidora 20. The repo size is impressive and the release just has the best hardware support now.
I make rpms for the Amateur radio community, and it has been very successful, giving the Rpi with Pidora 20 the apparent reliability of a BBB in comparison.
Many have used my Pidora 20 image to develop for other purposes, as no image was/is available in general apart from making your own in a koji release update, which is quite a task, i.e.. time consuming.
Adrian … vk4tux
rpm -ivh –nodeps –force.. ? < does that work ?
I use
rpm -Uvh –nodeps –force
when needed, I did not have to do that with the Pidora 20 release update starting from pc18.
Adrian … vk4tux