Re: Consistent names changed yet again?
On 08/06/2014 03:23 PM, Felix Miata wrote: On 2014-08-06 11:43 (GMT-0500) Kevin Martin composed: Hmm, I have biosdevname installed (and always have) and have never put net.ifnames=0 anywhere that I'm aware of. I've included net.ifnames=0 on installer cmdline for every distro I've installed for over a year. NAICT, Anaconda ignores it. I don't remember exactly how on Fedora I get eth0, possibly as a result of editing and renaming /etc/sysconfig/network-scripts/ifcfg- to ifcfg-eth0, but from earlier installations carried forward into my Rawhides I do have the following also: -rw-rw-r-- 1 root root 0 Oct 4 2013 /etc/udev/rules.d/80-net-name-slot.rules I see on http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ that that name has inexplicably been replaced for systemd v209 & up by 80-net-setup-link.rules. For the record, nmcli will do this without breaking a sweat. For example: [root@g55 ~]# nmcli con edit ed0fea4d-ed28-4fdb-9a8c-c131bd78d030 ===| nmcli interactive connection editor |=== Editing existing '802-3-ethernet' connection: 'ed0fea4d-ed28-4fdb-9a8c-c131bd78d030' Type 'help' or '?' for available commands. Type 'describe [.]' for detailed property description. You may edit the following settings: connection, 802-3-ethernet (ethernet), 802-1x, ipv4, ipv6 nmcli> print connection ['connection' setting values] connection.id: p3p1 connection.uuid: ed0fea4d-ed28-4fdb-9a8c-c131bd78d030 connection.interface-name: -- connection.type:802-3-ethernet connection.autoconnect: no connection.timestamp: 1407336689 connection.read-only: no connection.permissions: connection.zone:home connection.master: -- connection.slave-type: -- connection.secondaries: connection.gateway-ping-timeout:0 nmcli> set connection.id eth0 nmcli> set connection.interface-name eth0 nmcli> save Connection 'eth0' (ed0fea4d-ed28-4fdb-9a8c-c131bd78d030) sucessfully saved. nmcli> quit [root@g55 ~]# reboot when that is done, it will now be eth0 forever and ever, amen. A word of caution, however - do not do this if you have already set up other connections that depend on it, because they will still be looking for the former devname - which brings up a feature request. Maybe NetworkManager should have bridge, bond, and VPN connection masters and/or slaves either use the UUID for the identifier, or update the link in the underlying DB when IDs are changed. -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Self-introduction: Brandon Vincent
On Wed, Aug 06, 2014 at 12:29:53PM -0700, Brandon Vincent wrote: > Hello, > > I'm thrilled to have the opportunity to join the QA team. I am a > system administrator who enjoys working on all *nix variants. I > currently also work with the Fedora Security Team to ensure that > vulnerabilities patched in upstream reach the Fedora Project > packagers. My area of expertise is in security and cryptography. > > Fedora is my personal distribution of choice due to the unique blend > of bleeding edge features it provides while still providing stability, > I assume QA is responsible for a great deal of this! > > For contact purposes, my FAS and IRC username/nick is bvincent. > > Brandon Vincent Glad to have you aboard :) It'll be great to have you along side for testing going forward! Drop by #fedora-qa on freenode if you have any questions. -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On 2014-08-06 11:43 (GMT-0500) Kevin Martin composed: Hmm, I have biosdevname installed (and always have) and have never put net.ifnames=0 anywhere that I'm aware of. I've included net.ifnames=0 on installer cmdline for every distro I've installed for over a year. NAICT, Anaconda ignores it. I don't remember exactly how on Fedora I get eth0, possibly as a result of editing and renaming /etc/sysconfig/network-scripts/ifcfg- to ifcfg-eth0, but from earlier installations carried forward into my Rawhides I do have the following also: -rw-rw-r-- 1 root root 0 Oct 4 2013 /etc/udev/rules.d/80-net-name-slot.rules I see on http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ that that name has inexplicably been replaced for systemd v209 & up by 80-net-setup-link.rules. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Self-introduction: Brandon Vincent
Hello, I'm thrilled to have the opportunity to join the QA team. I am a system administrator who enjoys working on all *nix variants. I currently also work with the Fedora Security Team to ensure that vulnerabilities patched in upstream reach the Fedora Project packagers. My area of expertise is in security and cryptography. Fedora is my personal distribution of choice due to the unique blend of bleeding edge features it provides while still providing stability, I assume QA is responsible for a great deal of this! For contact purposes, my FAS and IRC username/nick is bvincent. Brandon Vincent -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On Wed, 6 Aug 2014, Samuel Sieb wrote: On 08/06/2014 10:48 AM, Michael Hennebry wrote: wrote: For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; Huh? Why would that require a writeable root directory? There was a file in /etc/udev/rules.d/ that kept track of the mapping from devices to the ethX names. Soft link it to something under /var . the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly How do MAC addresses get changed on embedded systems? Some ethernet hardware on embedded systems doesn't have built-in MAC addresses. Not having any is not the same as changed. -- Michael henne...@web.cs.ndsu.nodak.edu "SCSI is NOT magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then." -- John Woods -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On 08/06/2014 10:48 AM, Michael Hennebry wrote: wrote: For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; Huh? Why would that require a writeable root directory? There was a file in /etc/udev/rules.d/ that kept track of the mapping from devices to the ethX names. the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly How do MAC addresses get changed on embedded systems? Some ethernet hardware on embedded systems doesn't have built-in MAC addresses. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
Would someone explain this to me: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ wrote: For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; Huh? Why would that require a writeable root directory? the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly How do MAC addresses get changed on embedded systems? on all kinds of virtualization solutions. My guess is that virtualization could screw up any scheme, including the current system. Does rebooting a virtual machine have to change MAC addresses? On a machine with just one network interface, is there any reason not to call it eth0, fred or whatever the user wants? -- Michael henne...@web.cs.ndsu.nodak.edu "SCSI is NOT magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then." -- John Woods -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On 08/06/2014 09:32 AM, Scott Robbins wrote: > On Wed, Aug 06, 2014 at 02:38:30PM +0200, Adam Williamson wrote: >> >> In Fedora 21 we've more or less dropped biosdevname in favour of >> systemd. systemd's system is a cleaner implementation and the weight of >> opinion favours the systemd approach to naming. See the discussion from >> https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards. >> >> From F21 onwards new Fedora installations should reliably result in the >> use of the systemd naming scheme. Existing installs that use biosdevname >> will continue to use it (with the same naming scheme, obviously) unless >> the admin intervenes. >> >> We should probably put this in the release notes. > > Currently, as I understand it, to get back the eth0 naming scheme, one has > remove biosdevname as well as add the net.ifnames=0. Does that mean that > with F21, we will no longer need the step of rpm -e biosdevname? > > The term "more or less" seems a bit unclear. > I'm looking at > https://fedoraproject.org/wiki/Documentation_Networking_Beat as well as the > bug report linked above, and from *that*, it looks as if it will no longer > be necessary for the rpm -e biosdevname step. > > Thanks > > Hmm, I have biosdevname installed (and always have) and have never put net.ifnames=0 anywhere that I'm aware of. I've used the syntax that I put thru earlier since F19 and I'm now on F22. Kevin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On Wed, Aug 06, 2014 at 02:38:30PM +0200, Adam Williamson wrote: > > In Fedora 21 we've more or less dropped biosdevname in favour of > systemd. systemd's system is a cleaner implementation and the weight of > opinion favours the systemd approach to naming. See the discussion from > https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards. > > From F21 onwards new Fedora installations should reliably result in the > use of the systemd naming scheme. Existing installs that use biosdevname > will continue to use it (with the same naming scheme, obviously) unless > the admin intervenes. > > We should probably put this in the release notes. Currently, as I understand it, to get back the eth0 naming scheme, one has remove biosdevname as well as add the net.ifnames=0. Does that mean that with F21, we will no longer need the step of rpm -e biosdevname? The term "more or less" seems a bit unclear. I'm looking at https://fedoraproject.org/wiki/Documentation_Networking_Beat as well as the bug report linked above, and from *that*, it looks as if it will no longer be necessary for the rpm -e biosdevname step. Thanks -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On 08/06/2014 07:08 AM, Tom Horsley wrote:
> On Wed, 6 Aug 2014 07:55:55 -0400
> Matthew Miller wrote:
>
>> "consistent on the same machine for a given OS release,
>> _across any possible hardware changes_"
>
> Maybe, but I know I watched the interface names change
> just because a new version of bisodevname was released
> before biosdevname was engulphed by systemd. I wouldn't
> be surprised at all to see a systemd update change
> the names as well :-(.
>
> I also love the new systemd conventions that give me
> a different "consistent" name for my USB wifi dongle
> depending on which USB port I plug it into :-).
>
> http://home.comcast.net/~tomhorsley/game/biosdevname.html
>
I was having the same issue and finally resolved to make sure that my
"consistent" ethernet device was named eth0. I did that with
the following line in /etc/udev/rules.d/70-my-net-names.rules:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="c8:0a:a9:b1:46:c2", ATTR{dev_id}=="0x0", ATTR{type}=="1",
NAME="eth0"
Thereby forcing my device with that mac address to have name eth0. dmesg shows
udev/systemd changing this:
[3.975997] systemd-udevd[232]: renamed network interface eth0 to p6p1
[ 21.108994] systemd-udevd[421]: renamed network interface p6p1 to eth0
YMMV.
Kevin
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On Wed, 2014-08-06 at 14:38 +0200, Adam Williamson wrote: > In Fedora 21 we've more or less dropped biosdevname in favour of > systemd. systemd's system is a cleaner implementation and the weight of > opinion favours the systemd approach to naming. See the discussion from > https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards. > > From F21 onwards new Fedora installations should reliably result in the > use of the systemd naming scheme. Existing installs that use biosdevname > will continue to use it (with the same naming scheme, obviously) unless > the admin intervenes. > > We should probably put this in the release notes. Done: https://fedoraproject.org/wiki/Documentation_Networking_Beat -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On Wed, 2014-08-06 at 07:41 -0400, Tom Horsley wrote: > I've got F21 branched installed on an alternate partition on > my system, and I noticed this nonsense. On F21 I get this: > > enp5s0: flags=4163 mtu 1500 > inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255 > inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20 > ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet) > RX packets 112 bytes 13242 (12.9 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 84 bytes 10207 (9.9 KiB) > TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0 That's systemd: https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames > On F20 the same hardware (note the MAC address) gives this: > > p6p1: flags=4163 mtu 1500 > inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255 > inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20 > ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet) > RX packets 1233320 bytes 144491797 (137.7 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 2058583 bytes 2951769070 (2.7 GiB) > TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0 That's biosdevname: https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming In Fedora 21 we've more or less dropped biosdevname in favour of systemd. systemd's system is a cleaner implementation and the weight of opinion favours the systemd approach to naming. See the discussion from https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards. From F21 onwards new Fedora installations should reliably result in the use of the systemd naming scheme. Existing installs that use biosdevname will continue to use it (with the same naming scheme, obviously) unless the admin intervenes. We should probably put this in the release notes. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On Wed, Aug 06, 2014 at 08:08:10AM -0400, Tom Horsley wrote: > > "consistent on the same machine for a given OS release, > > _across any possible hardware changes_" > Maybe, but I know I watched the interface names change > just because a new version of bisodevname was released > before biosdevname was engulphed by systemd. I wouldn't So, actually, the biosdevname goal was slightly different, and focused more on predictability across machines when possible. (And specifically on matching the silkscreened labels on Dell server hardware.) It also went through a couple of unfortunate trial-and-error periods where the naming policy changed. > be surprised at all to see a systemd update change > the names as well :-(. That should not happen within a stable Fedora release and we'll treat it as a bug if it does. > I also love the new systemd conventions that give me > a different "consistent" name for my USB wifi dongle > depending on which USB port I plug it into :-). > http://home.comcast.net/~tomhorsley/game/biosdevname.html But consistent for each port, right? :) -- Matthew Miller Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On Wed, 6 Aug 2014 07:55:55 -0400 Matthew Miller wrote: > "consistent on the same machine for a given OS release, > _across any possible hardware changes_" Maybe, but I know I watched the interface names change just because a new version of bisodevname was released before biosdevname was engulphed by systemd. I wouldn't be surprised at all to see a systemd update change the names as well :-(. I also love the new systemd conventions that give me a different "consistent" name for my USB wifi dongle depending on which USB port I plug it into :-). http://home.comcast.net/~tomhorsley/game/biosdevname.html -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
On Wed, Aug 06, 2014 at 07:41:07AM -0400, Tom Horsley wrote: > What was the point of "consistent" interface names again? Completely leaving aside the question of what exactly it _should_ mean, it appears to mean "consistent on the same machine for a given OS release, _across any possible hardware changes_". This very much does not mean "consistent between machines in any useful way" or, as you see here, "consistent across releases". Those things would definitely be useful, but they're not what's meant. The thing which _is_ meant *is* also useful, but for different reasons and different problems (which might not even be problems you have). -- Matthew Miller Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Consistent names changed yet again?
I've got F21 branched installed on an alternate partition on my system, and I noticed this nonsense. On F21 I get this: enp5s0: flags=4163 mtu 1500 inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255 inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20 ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet) RX packets 112 bytes 13242 (12.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 84 bytes 10207 (9.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0 On F20 the same hardware (note the MAC address) gives this: p6p1: flags=4163 mtu 1500 inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255 inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20 ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet) RX packets 1233320 bytes 144491797 (137.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2058583 bytes 2951769070 (2.7 GiB) TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0 What was the point of "consistent" interface names again? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-21 Branched report: 20140806 changes
Compose started at Wed Aug 6 07:15:06 UTC 2014 Broken deps for armhfp -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [ModemManager] ModemManager-1.2.0-3.fc21.armv7hl requires libmbim-glib.so.0 [PyKDE] PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) >= 0:10.0 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [collectd] collectd-pinba-5.4.1-5.fc21.armv7hl requires libprotobuf-c.so.0 collectd-write_riemann-5.4.1-5.fc21.armv7hl requires libprotobuf-c.so.0 [criu] criu-1.2-2.fc21.armv7hl requires libprotobuf-c.so.0 [csound] csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-4.fc21.armv7hl requires libedelib.so edelib-devel-2.1-4.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.20.beta2.fc21.armv7hl requires libgloox.so.11 [fedocal] fedocal-0.5.1-2.fc21.noarch requires python-dateutil <= 0:1.5 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [ghc-concrete-typerep] ghc-concrete-typerep-devel-0.1.0.2-4.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [ghc-ghc-mtl] ghc-ghc-mtl-devel-1.2.1.0-2.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [ghc-hint] ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [ghc-ltk] ghc-ltk-devel-0.12.1.0-12.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [golang-github-smarterclayton-go-systemd] golang-github-smarterclayton-go-systemd-devel-0-0.5.git5cb9e9e.fc21.noarch requires golang(github.com/guelfey/go.dbus) [grass] grass-6.4.3-5.fc21.armv7hl requires libtk8.5.so grass-6.4.3-5.fc21.armv7hl requires libtcl8.5.so [haddock] ghc-haddock-devel-2.13.2-4.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [hibernate-search] hibernate-search-4.5.1-4.fc21.noarch requires mvn(org.apache.avro:avro) [ice] ice-php-3.5.1-4.fc21.armv7hl requires php(zend-abi) = 0:20121212-32 ice-php-3.5.1-4.fc21.armv7hl requires php(api) = 0:20121113-32 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [leksah] ghc-leksah-devel-0.12.1.3-15.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [leksah-server] ghc-leksah-server-devel-0.12.1.2-15.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [libgadu] libgadu-1.12.0-1.fc21.armv7hl requires libprotobuf-c.so.0 [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [licq] licq-1.8.2-1.fc21.armv7hl requires libgloox.so.11 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [mapserver] mapserver-java-6.2.1-7.fc21.armv7hl requires java-gcj-compat [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-
