Re: Fedora/Gnome3 : Display Problem on my hardware.
Ok. so that sounds exactly like the same issue. It was worth on F20 for me than it is with F21. Thank you. Fred On 12/13/2014 02:30 PM, Madhurjya Roy wrote: It's quite similar to that, just more severe! In my case, when I open the 'activities' menu, there are square and triangular lines spread all over and almost none of the icons render correctly. Another thing worth pointing out is that applications are not affected by it. Most of the applications I ran (Nautilus, GIMP, Gnome Terminal, Application Settings) rendered correctly. The problem mainly affects the panel on the top, the calendar view that opens up from there (like the one in your picture) and the 'activities' menu. I'm downloading the Fedora live image, once it is done, I'll boot up and share some screenshots. I guess that'll provide a better idea of it. Madhurjya Roy On 13/12/2014, Frederic Muller f...@cm17.com wrote: Hi! Does it look like something like this: http://snag.gy/AGPaq.jpg I've started having the problem on F20 after a xorg update about 3 weeks ago and it has stayed. I upgraded (new install though) to F21 to get the same result unfortunately. It's also a Radeon (HD 6770 though) card. Thanks. Fred On 12/12/2014 10:49 PM, Madhurjya Roy wrote: Hey guys, My old PC MoBo recently died and so, I built a new PC with the following hardware specification : * Processor : AMD A4-6300K 3.7 GHz Dual Core APU with integrated Radeon HD 8370D GPU * MoBo : MSI A58M-E33 * RAM : 4 GB Corsair Value RAM 1600 MHz. * HDD : 500 GB WD Caviar @ 7200 rpm * Monitor : 19 inch Samsung SyncMaster at 1400 X 900 pixels @ 60-75 Hz refresh rate So, I went ahead and popped in the Fedora 21 Workstation Disc. Anaconda worked well and installed Fedora 21. But as soon as I restarted my PC and logged in I found the desktop flickering! I moved the mouse pointer and it flickered even more vigorously and when I pulled through the activities hot corner, I could barely see the icons, which appeared like distorted squares. Somehow, I managed to open the terminal. All the text in the terminal were clearly visible, I installed Xfce desktop and to my surprise it worked fine, text and icon everything was clear and perfectly usable. Next, I installed KDE and it worked as well. I really had trouble understanding the wobbly widgety interface, though! So, I assumed the problem is with Gnome 3. I reinstalled the complete Gnome desktop and alas, the problem persisted! I have used Fedora 20 for quite some time on my laptop, so, I booted a live image of Fedora 20, that I had had flashed onto a pen drive and still there was the same problem. Frustrated, I gave up and installed Ubuntu, Unity worked well but when I installed Gnome3, I was back where I was, running a completely graphically distorted UI! I've since changed many distros (without Gnome as DE) and all of them worked fine. Windows 8.1 worked fluidly as well! I am currently using Ubuntu 14.10 (with Unity as DE). I found it quite close to Gnome3. However, I would still like to use Fedora and since, I'm using this as a multimedia PC, so Gnome3 is still my preference. From my observations, it seems to be a Gnome 3 hardware incompatibility issue. I've tried changing refreshing rate, resolution and colour depth and nothing could solve the issue! Even switching to the proprietary AMD drivers didn't work out. Should I file a bug report on BugZilla? If anyone's got some idea, please help! Thanks, Madhurjya Roy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 19 updates-testing report
The following Fedora 19 Security updates need testing: Age URL 413 https://admin.fedoraproject.org/updates/FEDORA-2013-19963/openstack-glance-2013.1.4-1.fc19 71 https://admin.fedoraproject.org/updates/FEDORA-2014-12057/krb5-1.11.3-29.fc19 57 https://admin.fedoraproject.org/updates/FEDORA-2014-13018/deluge-1.3.10-1.fc19 47 https://admin.fedoraproject.org/updates/FEDORA-2014-13551/wpa_supplicant-2.0-12.fc19 38 https://admin.fedoraproject.org/updates/FEDORA-2014-14237/claws-mail-plugins-3.11.1-1.fc19,claws-mail-3.11.1-2.fc19,libetpan-1.6-1.fc19 31 https://admin.fedoraproject.org/updates/FEDORA-2014-14738/gnutls-3.1.20-6.fc19 28 https://admin.fedoraproject.org/updates/FEDORA-2014-12407/sddm-0.10.0-2.fc19 24 https://admin.fedoraproject.org/updates/FEDORA-2014-15248/kde-runtime-4.11.5-3.fc19 23 https://admin.fedoraproject.org/updates/FEDORA-2014-15378/rubygem-actionpack-3.2.13-7.fc19 23 https://admin.fedoraproject.org/updates/FEDORA-2014-15390/nodejs-0.10.33-1.fc19,libuv-0.10.29-1.fc19 22 https://admin.fedoraproject.org/updates/FEDORA-2014-15466/rubygem-sprockets-2.8.2-4.fc19 17 https://admin.fedoraproject.org/updates/FEDORA-2014-15740/facter-1.6.18-8.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-15990/mariadb-5.5.40-1.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-15999/libreoffice-4.1.6.2-10.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-16045/util-linux-2.23.2-6.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2014-16272/flac-1.3.1-1.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2014-16227/dbus-1.6.28-1.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2014-16224/pcre-8.32-12.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16473/pwgen-2.07-1.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16474/phpMyAdmin-4.2.13.1-1.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16452/grub2-2.00-27.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16477/python-tornado-2.2.1-7.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16485/pam-1.1.6-13.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16479/python3-3.3.2-11.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16465/jasper-1.900.1-25.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16466/pyxdg-0.25-5.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16483/icecast-2.4.1-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16499/xen-4.2.5-7.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16504/mantis-1.2.18-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16790/kernel-3.14.26-100.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16576/bind-9.9.3-16.P2.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16690/curl-7.29.0-27.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-16896/tcpdump-4.4.0-5.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-16874/asterisk-11.14.2-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-16728/xorg-x11-server-1.14.4-5.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-16865/docker-io-1.4.0-1.fc19 The following Fedora 19 Critical Path updates have yet to be approved: Age URL 361 https://admin.fedoraproject.org/updates/FEDORA-2013-22326/fedora-bookmarks-15-5.fc19 287 https://admin.fedoraproject.org/updates/FEDORA-2014-3245/testdisk-6.14-2.fc19.1,ntfs-3g-2014.2.15-1.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-16021/tracker-0.16.5-1.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-16009/unzip-6.0-13.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-16045/util-linux-2.23.2-6.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2014-16276/selinux-policy-3.12.1-74.30.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2014-16213/crda-1.1.3_2014.11.18-1.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2014-16224/pcre-8.32-12.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2014-16227/dbus-1.6.28-1.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2014-16272/flac-1.3.1-1.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16485/pam-1.1.6-13.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16466/pyxdg-0.25-5.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2014-16465/jasper-1.900.1-25.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16576/bind-9.9.3-16.P2.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16770/hicolor-icon-theme-0.14-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16690/curl-7.29.0-27.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-16790/kernel-3.14.26-100.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-16892/poppler-0.22.1-7.fc19 0
Re: fedup f20-f21 kde broken deps
On Fri, 12 Dec 2014 12:16:34 -0800, Adam Williamson wrote: Awesome, so now you have me running a test install of F20 with R just to see what happens in this situation. There's certainly no other way I could be using my damn morning. Well, the problems are real. Unresolvable deps in many cases are equal to denial-of-service at runtime, i.e. the programs don't execute. In some cases and depending on whether the system survives the reboot, a distro-sync may work. Doing downgrades of packages bears even further risks, though (and in most cases are completely untested). [For example, there are cases where parts of the software and/or packages have converted settings and other runtime files already only to run into breakage later on, such as a broken component.] Btw, this morning I've had fun porting Audacious plugins to the new API. We seem to keep going in circles here. I hear you well. Going in circles cannot be avoided. My opinion in this matter is: If individual package maintainers are not careful enough to violate upgrade paths, update release procedures ought to get adjusted. It may be that you're happy (so far) with suggesting a distro-sync as a preliminary work-around. Users are scared by such extra commands, however, especially if Yum asks for confirmation before wanting to remove (!) and downgrade packages. Violated upgrade paths are an issue all the time. Not only shortly before release of next Fedora! There's always some sort of window when packagers mass-release upgrades to multiple dists and cause an upgrade race. Sometimes just a few days, sometimes a week, sometimes several weeks, if a test update is forgotten or withdrawn. Shortly before a new release of Fedora it can be worse, however, because users are not interested in Test Releases that are not ready. They hope for the final release to just work. Meanwhile they continue the drill and apply updates daily, and if they happen to hear about the new Fedora release, they upgrade from an up-to-date earlier release where packages are even newer than in the release they upgrade to. If the upgrade method cannot handle that, yes, repeating that won't improve it. Facing the facts is necessary, though. work, I think it's taking things too far to say that it's worthless to test upgrades against updates-testing, which was one place where we started this endless debate. We two have not been the only participants in this thread. *I* haven't claimed that test upgrades to updates-testing are worthless. But I claim that the ordinary user doesn't upgrade to updates-testing and doesn't want to upgrade to updates-testing due to some of the stuff that's dumped in there. Too many updates, too many packages updated too frequently. Hey, perhaps even a name change would make that repo less intimidating: update-candidates. ;) A bit of an obfuscation contest, unfortunately, and much too lose if such a repo causes severe breakage. Plain users don't want to be the guinea pigs to install Test Updates, which may be entirely _untested_. They want the Fedora Project to ensure the quality of updates. And quality ensurance needs to start somewhere. We can't dump random upgrades into updates-testing and only hope that withdrawing them may be enough. Burnt repo users may be fed up when that happens regularly. * The obvious way you can really 'solve' this 'problem' is to tighten down the updates policy, but that's not a free action. It *does* come with negative consequences and there *will* be pushback against it from packagers. Of course. Personally I am totally happy if anyone wants to come up with a comprehensive proposal for adjusting the updates policy and *take it to FESCo*, who own the updates policy. If someone comes up with such a proposal, we can even put it up for discussion on this list or in a QA meeting and decide if QA as a whole wants to back it in the FESCo discussion. That doesn't work for me. It doesn't work for me at all, if people hide somewhere, are not interested in the topic on this list, and would not be informed at all when learning about the topic in a meeting. But I'm just tired of going around in endless discussion, especially when no-one seems to acknowledge the issue just isn't as straightforward as 'oh well it's OBVIOUSLY wrong and we should OBVIOUSLY just have strict upgradepath enforcement'. Well, early resistance kills all progress. Early. Some of this discussion is ridiculous. On one hand, delaying upgrades for old dist releases is considered a major problem, because those upgrades may be oh-so-important-brown-paperbag-showstopper-fixes. On the other hand, for the latest dist release a distro-sync downgrade is suggested, which downgrades to old packages where the oh-so-important upgrade is not available yet or only in updates-testing. Something's wrong here with the release process. It may be the first dist upgrade for some Fedora users! The other path you can take is to try and
Re: fedup f20-f21 kde broken deps
On Sat, Dec 13, 2014 at 11:48 AM, Michael Schwendt mschwe...@gmail.com wrote: On Fri, 12 Dec 2014 12:16:34 -0800, Adam Williamson wrote: Awesome, so now you have me running a test install of F20 with R just to see what happens in this situation. There's certainly no other way I could be using my damn morning. Well, the problems are real. Unresolvable deps in many cases are equal to denial-of-service at runtime, i.e. the programs don't execute. In some cases and depending on whether the system survives the reboot, a distro-sync may work. Doing downgrades of packages bears even further risks, though (and in most cases are completely untested). [For example, there are cases where parts of the software and/or packages have converted settings and other runtime files already only to run into breakage later on, such as a broken component.] Btw, this morning I've had fun porting Audacious plugins to the new API. We seem to keep going in circles here. I hear you well. Going in circles cannot be avoided. My opinion in this matter is: If individual package maintainers are not careful enough to violate upgrade paths, update release procedures ought to get adjusted. It may be that you're happy (so far) with suggesting a distro-sync as a preliminary work-around. Users are scared by such extra commands, however, especially if Yum asks for confirmation before wanting to remove (!) and downgrade packages. Violated upgrade paths are an issue all the time. Not only shortly before release of next Fedora! There's always some sort of window when packagers mass-release upgrades to multiple dists and cause an upgrade race. Sometimes just a few days, sometimes a week, sometimes several weeks, if a test update is forgotten or withdrawn. Shortly before a new release of Fedora it can be worse, however, because users are not interested in Test Releases that are not ready. They hope for the final release to just work. Meanwhile they continue the drill and apply updates daily, and if they happen to hear about the new Fedora release, they upgrade from an up-to-date earlier release where packages are even newer than in the release they upgrade to. If the upgrade method cannot handle that, yes, repeating that won't improve it. Facing the facts is necessary, though. work, I think it's taking things too far to say that it's worthless to test upgrades against updates-testing, which was one place where we started this endless debate. We two have not been the only participants in this thread. *I* haven't claimed that test upgrades to updates-testing are worthless. But I claim that the ordinary user doesn't upgrade to updates-testing and doesn't want to upgrade to updates-testing due to some of the stuff that's dumped in there. Too many updates, too many packages updated too frequently. Hey, perhaps even a name change would make that repo less intimidating: update-candidates. ;) A bit of an obfuscation contest, unfortunately, and much too lose if such a repo causes severe breakage. Plain users don't want to be the guinea pigs to install Test Updates, which may be entirely _untested_. They want the Fedora Project to ensure the quality of updates. And quality ensurance needs to start somewhere. We can't dump random upgrades into updates-testing and only hope that withdrawing them may be enough. Burnt repo users may be fed up when that happens regularly. * The obvious way you can really 'solve' this 'problem' is to tighten down the updates policy, but that's not a free action. It *does* come with negative consequences and there *will* be pushback against it from packagers. Of course. Personally I am totally happy if anyone wants to come up with a comprehensive proposal for adjusting the updates policy and *take it to FESCo*, who own the updates policy. If someone comes up with such a proposal, we can even put it up for discussion on this list or in a QA meeting and decide if QA as a whole wants to back it in the FESCo discussion. That doesn't work for me. It doesn't work for me at all, if people hide somewhere, are not interested in the topic on this list, and would not be informed at all when learning about the topic in a meeting. But I'm just tired of going around in endless discussion, especially when no-one seems to acknowledge the issue just isn't as straightforward as 'oh well it's OBVIOUSLY wrong and we should OBVIOUSLY just have strict upgradepath enforcement'. Well, early resistance kills all progress. Early. Some of this discussion is ridiculous. On one hand, delaying upgrades for old dist releases is considered a major problem, because those upgrades may be oh-so-important-brown-paperbag-showstopper-fixes. On the other hand, for the latest dist release a distro-sync downgrade is suggested, which downgrades to old packages where the oh-so-important upgrade is not available yet or only in updates-testing. Something's wrong here with the
Re: fedup f20-f21 kde broken deps
On Sat, 13 Dec 2014 11:48:00 +0100, Michael Schwendt wrote: updates. And quality ensurance needs to start somewhere. We can't dump Typo here: make that quality assurance -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f20-f21 kde broken deps
On Sat, 13 Dec 2014 11:51:02 +0100, drago01 wrote: So how about: 1) Add epoch: N to all FN packages 2) Ignore people complaining about epoch being ugly 3) FN+1 FN is always the case because of 1 4) Profit ;) That sounds like the years old Dist Epoch proposal, where a new epoch would be added at the RPM level to not conflict with the current Epoch tag. All packages would need to be rebuilt before a dist release. Alternatively, it would enter the repo metadata somehow, so tools would apply a dist version check at the repo level and trigger downgrades of packages based on what dist the repo is made for. Tools could also recognize whether a package is for Fedora 21. But yes, another hidden value that affects RPM version comparison would be really ugly. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20141213 changes
Compose started at Sat Dec 13 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [bibletime] bibletime-2.10.1-4.fc22.i686 requires libsword-1.7.3.so [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [kdeplasma-addons] plasma-wallpaper-marble-4.14.3-1.fc22.i686 requires libmarblewidget.so.19 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [subsurface] subsurface-4.2-3.fc22.i686 requires libmarblewidget.so.19 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [bibletime] bibletime-2.10.1-4.fc22.x86_64 requires libsword-1.7.3.so()(64bit) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [kdeplasma-addons] plasma-wallpaper-marble-4.14.3-1.fc22.x86_64 requires libmarblewidget.so.19()(64bit) [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 pam_mapi-0.2.0-3.fc22.x86_64 requires libmapi.so.0()(64bit) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [subsurface] subsurface-4.2-3.fc22.x86_64 requires libmarblewidget.so.19()(64bit) [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [bibletime] bibletime-2.10.1-4.fc22.armv7hl requires libsword-1.7.3.so [cab] cab-0.1.9-12.fc22.armv7hl requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14
Re: fedup f20-f21 kde broken deps
On Sat, Dec 13, 2014 at 11:48:00 +0100, Michael Schwendt mschwe...@gmail.com wrote: But I claim that the ordinary user doesn't upgrade to updates-testing and doesn't want to upgrade to updates-testing due to some of the stuff that's dumped in there. Too many updates, too many packages updated too frequently. We could mitigate some of this by recommending that more updates (particularly the ones that aren't an upstream update) add to the release string after the distribution instead of before it. Doing it this way it doesn't matter if fixes for the older releases go to stable first. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
