Updated spec for metainfo.xml
Greetings, Current maintainer of gimp-elsamuko. Upstream recently added metainfo.xml needed for Gnome Software in their package and I would like to update the spec file to reflect the change[1]. Do I need to remove the appstream metadata part? I looked at the information to no available. Thank you in advance. Ref: [1] https://apps.fedoraproject.org/packages/gimp-elsamuko/sources/ -- *Luya Tshimbalanga* Fedora Design Team Design Suite spin maintainer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: on software updates
On 02/03/2015 07:22 PM, Adam Williamson wrote: > On Mon, 2015-02-02 at 10:50 -0500, Miloslav Trmač wrote: >>> On 31 January 2015 at 21:57, Casey Jao wrote: Are there any plans to let packages specify that they do not require a total system reboot to be updated? >>> >>> Yes, see https://wiki.gnome.org/Projects/SandboxedApps -- >>> basically, you can't do updates of rpm-sourced system-wide app >>> deployments without a reboot in a safe way. >> >> There are classes of RPMs that definitely can be done without a >> reboot in a safe way (documentation-only; packages with a single >> executable and no libraries / separate data files; and quite a few >> other cases), and letting packagers opt them in to being updated >> without a reboot seems like a clear improvement on the status quo. > > It'd only be an improvement if users often saw a set of updates which > *only* contained such packages. In my experience that rarely if ever > happens. It happens for downstreams. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Call for Fedora 22 Test Days
Another testing cycle is finally upon us, and it's about time we got some Test Days scheduled for the F22 cycle. The Anaconda team has already requested a test day [0] and there are several other changes coming to F22 that could use some testing love - a full list can be found here: http://fedoraproject.org/wiki/Releases/22/ChangeSet F22 also has several self-contained changes that could use some testing. So my thought was, if there were things people would like to get tested, but didn't think it warranted an entire day - then we could group these together and run a test day to poke at several different things at the same time. Thoughts on this? For those of you not familiar with test days, a test day is an online event aimed at testing a specific feature of an upcoming Fedora Release. By utilizing IRC for organization/coordination and a Wiki page for instructions and results, test days are easy to organize. Anyone can request to host a test day or request that the QA team help you out with the organization of the test day. A test day can be ran for any feature or area of a distribution that focused testing would be useful for. More information on test days can be found here: https://fedoraproject.org/wiki/QA/Test_Days . To propose a test day, file a ticket on the QA Trac. A full explanation can be found here: https://fedoraproject.org/wiki/QA/Test_Days/Create . The SOP for hosting a test day is here: https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . Traditionally test days have been held on Thursdays, but if you'd prefer to have it on another day that's fine too. We're pretty flexible, but having plenty of lead time helps to get the word out. Just put in your ticket the date or time-frame you'd like, and we'll figure it out from there. If you have any questions about test days or the process, please don't hesitate to contact me or any other QA Team member in #fedora-qa on Freenode or respond on the test list. Thanks and happy testing! [0] https://fedorahosted.org/fedora-qa/ticket/457 -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of Boost rebase
Roger, I will fix the issues soon. cclive may have some include errors while elektra and libflatarray need to be revised for the RPM %files section. Thanks. -- Yours sincerely, Christopher Meng http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of Boost rebase
On Tue, Feb 3, 2015 at 1:11 PM, Petr Machata wrote: > Hi, > > Most of the mass rebuild finished last week already, but due to FOSDEM > and other circumstances (like me leaving the result file on my home NFS > out of reach yesterday) I'm only getting to writing this now. A bunch > of Boost-related bugs have been already resolved, or I contacted the > maintainers. The following is the stuff that I plonked as not my > business. Contact me if you think it in fact is, I'll look into it. > > > 8743748 player error: too many arguments to function 'int > sg_init()' > Had to do with a lingering patch from the transition to and then back from libstatgrab-0.90. Fixed. 8765846 sdformatLaTeX Error: File `adjustbox.sty' not found. > Doxygen latex issue, fixed. > 8765305 mrptNo rule to make target > '/usr/lib/libnetcdf_c++.so', needed by 'lib/libmrpt-pbmap.so.1.0.2' > Missing BR on netcdf-cxx-devel, fixed. > These were skipped or failed due to dependencies on other software that > failed: > > fawkes dep: player > Will re-build this week. gazebo dep: sdformat, player > Rebuilt. Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Removing Maven depmap support in F23
On 02/03/2015 07:18 PM, Jerry James wrote: > On Tue, Feb 3, 2015 at 11:10 AM, Mikolaj Izdebski wrote: >> Next week after branching I will update XMvn in rawhide (F23) to new >> upstream version. Among other things, this version removes support >> for legacy "depmap" files, which were used by Maven to resolve >> dependencies and which were obsoleted by new metadata format. As a >> consequence, artifacts installed in packages which don't ship metadata >> in new format won't be resolvable by Maven. > > Speaking of XMvn, all of the links to more information about XMvn found here: > > https://fedorahosted.org/released/javapackages/doc/#mvn_config > > are currently broken. They point to the following URLs, which return HTTP > 404: > > "official website" -> http://mizdebsk.fedorapeople.org/xmvn/site/ > "basics" -> http://mizdebsk.fedorapeople.org/xmvn/site/configuration.html > "configuration reference" -> > http://mizdebsk.fedorapeople.org/xmvn/site/config.html > > Could somebody fix those, please? Thanks, Fixed, thanks for reporting this. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCo elections are open
On 03/02/15 19:19, Stephen John Smoogen wrote: And yes, FESCO is mainly a social skills test and workplace... all committees that have to deal with programmers and their egos are going to be. Amen :) --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: on software updates
On Tue, 2015-02-03 at 05:28 +0100, Kevin Kofler wrote: > Richard Hughes wrote: > > Yes, see https://wiki.gnome.org/Projects/SandboxedApps -- > > basically, you can't do updates of rpm-sourced system-wide app > > deployments without a reboot in a safe way. > > That's absolute nonsense. Updating had always worked that way before > you > changed to offline updates. It just works. You're not engaging with Richard's argument at all, which he's stated in quite a lot of detail in multiple places. His point is that it works until it doesn't - in *most* cases you happen to get away with doing something which is fundamentally unreliable, right up until it actually bites you in the ass. And he's stated several times that he and the other maintainers of packaging-related apps have had to deal with multiple bugs caused by online updates. If you can actually counter those points, we have an interesting debate, but if all you're going to do is restate the position he's already said is too simplistic, we're not going anywhere. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: on software updates
On Mon, 2015-02-02 at 10:50 -0500, Miloslav Trmač wrote: > > On 31 January 2015 at 21:57, Casey Jao wrote: > > > Are there any plans to let packages specify that they do not > > > require a total > > > system reboot to be updated? > > > > Yes, see https://wiki.gnome.org/Projects/SandboxedApps -- > > basically, you can't do updates of rpm-sourced system-wide app > > deployments without a reboot in a safe way. > > There are classes of RPMs that definitely can be done without a > reboot in a safe way (documentation-only; packages with a single > executable and no libraries / separate data files; and quite a few > other cases), and letting packagers opt them in to being updated > without a reboot seems like a clear improvement on the status quo. It'd only be an improvement if users often saw a set of updates which *only* contained such packages. In my experience that rarely if ever happens. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCo elections are open
On 2 February 2015 at 21:20, Kevin Kofler wrote: > Stephen Gallagher wrote: > > At the same time, until fairly recently (Kalev), the Workstation WG (and > > formerly Desktop team) hasn't had a great deal of representation on > > FESCo. It's good to see more faces from that side of the Fedora Project > > running for FESCo. > > As if FESCo weren't already biased enough towards GNOME… :-( Sigh! > > Self-fulfilling prophecy. You may not have the social skills needed to work on FESCO but you have the ability to find those that do in KDE to get the to run. And yes, FESCO is mainly a social skills test and workplace... all committees that have to deal with programmers and their egos are going to be. > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Removing Maven depmap support in F23
On Tue, Feb 3, 2015 at 11:10 AM, Mikolaj Izdebski wrote: > Next week after branching I will update XMvn in rawhide (F23) to new > upstream version. Among other things, this version removes support > for legacy "depmap" files, which were used by Maven to resolve > dependencies and which were obsoleted by new metadata format. As a > consequence, artifacts installed in packages which don't ship metadata > in new format won't be resolvable by Maven. Speaking of XMvn, all of the links to more information about XMvn found here: https://fedorahosted.org/released/javapackages/doc/#mvn_config are currently broken. They point to the following URLs, which return HTTP 404: "official website" -> http://mizdebsk.fedorapeople.org/xmvn/site/ "basics" -> http://mizdebsk.fedorapeople.org/xmvn/site/configuration.html "configuration reference" -> http://mizdebsk.fedorapeople.org/xmvn/site/config.html Could somebody fix those, please? Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Results of Boost rebase
Hi, Most of the mass rebuild finished last week already, but due to FOSDEM and other circumstances (like me leaving the result file on my home NFS out of reach yesterday) I'm only getting to writing this now. A bunch of Boost-related bugs have been already resolved, or I contacted the maintainers. The following is the stuff that I plonked as not my business. Contact me if you think it in fact is, I'll look into it. The following look like they miss an #include 8729595 glob2 error: 'cout' is not a member of 'std' 8731436 cclive ./cc/error.h:52:3: error: 'clog' is not a member of 'std' 8725522 blobby missing #include ? (only ?) A dep API changed apparently: 8743153 dmlite-plugins-profiler fatal error: dmlite/cpp/dmlite.h: No such file or directory 8743851 dmlite-plugins-adapter fatal error: dmlite/cpp/dmlite.h: No such file or directory 8747666 dmlite-plugins-memcache fatal error: dmlite/cpp/dmlite.h: No such file or directory 8742774 fityk error: lua.h version not in desired range 8739488 highlight error: too few arguments to function 'int lua_dump 8738031 snapper too few arguments to function 'int btrfs_read_and_process_send_stream 8743748 player error: too many arguments to function 'int sg_init()' 8737636 spring CMAKE: Could NOT find FONTCONFIG (missing: FONTCONFIG_LIBRARY FONTCONFIG_INCLUDE_DIR) 8729612 psi4fatal error: gitversion.h: No such file or directory zmq.hpp was renamed to zmq.h. 8738365 pdnsfatal error: zmq.hpp: No such file or directory 8768907 airinv fatal error: zmq.hpp: No such file or directory Documentation fails: 8765846 sdformatLaTeX Error: File `adjustbox.sty' not found. 8731230 roboptim-trajectory sh: gs: command not found 8737247 roboptim-core sh: gs: command not found 8731841 zookeeper unknown resolver null 8726792 libyui doxygen memory corruption on ARM What looks like various test suite failures: 8766409 trademgen test suite failures 8730816 cvc4test suite fail monotonetest suite failures 8738494 csdiff test suite failures 8727935 Macaulay2 looks like test suite failures as well 8736847 swigkernel_require.rb:54:in `require': cannot load such file -- example (LoadError) C++ errors: 8729771 gfal2-pythoninvalid conversion from const char* to char* 8735859 pathfinder invalid abstract return type 'xplc_ptr::ProtectedPtr' 8738140 libopkele invalid abstract return type 'opkele::util::basic_filterator' Build errors: 8765305 mrptNo rule to make target '/usr/lib/libnetcdf_c++.so', needed by 'lib/libmrpt-pbmap.so.1.0.2' 8738411 yoshimi Directory not found: /builddir/build/[...]/usr/lib64/lv2/yoshimi.lv2 8733973 elektra error: Installed (but unpackaged) file(s) found: 8726219 libflatarrayerror: Installed (but unpackaged) file(s) found These were skipped or failed due to dependencies on other software that failed: openoffice.org-diafilterdep: libreoffice fawkes dep: player gazebo dep: sdformat, player simcrs dep: airinv Failures that seem to be Boost-related, but I haven't had time (yet) to address them: 8740330 hugin 8738235 kicad 8737708 boost-gdb-printers 8730865 valyriatear 8729315 luabind Thanks, Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: initscripts
On Wed, 2015-01-28 at 00:38 -0500, Nico Kadel-Garcia wrote: > Whether it has the options, and I didn't see them when using it > yesterday, it is Not Your Friend(tm). The GUI's do not provide > enough fine resolution, they display nothing of what the actual > config files touched are or what they say, This is because there is abstraction of various configuration formats, because NM has to operate on multiple distros with multiple 'native' configuration formats. ifcfg files are not the only configuration backend it supports. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Removing Maven depmap support in F23
TL;DR: this is heads-up that in one week packages listed below may stop being resolved with Maven, one of Java build systems. It should be enough to rebuild affected packages in order to fix them. More details: Next week after branching I will update XMvn in rawhide (F23) to new upstream version. Among other things, this version removes support for legacy "depmap" files, which were used by Maven to resolve dependencies and which were obsoleted by new metadata format. As a consequence, artifacts installed in packages which don't ship metadata in new format won't be resolvable by Maven. All packaging tools in Fedora 21 and later generate metadata in new format, so this problem affects only long-time FTBFS packages, but it should be enough to rebuild packages in order to make them resolvable again. The following are list of affected packages with their maintainers and FTBFS bug numbers. Feel free to ask on #java-devel if you have any questions or need help with fixing FTBFS. List of affected packages Format: package maintainer(s) bug(s) - akka willb #1105943 amplab-tachyon tstclair #1188792 apt-maven-plugin goldmann #1105964 byteman goldmann #1106023 clojure-compat kushal #992067,#1106059 clojure-contrib salimma #1106060 clojure-maven-plugin salimma #1096098,#1106061 clucy salimma #1106068 cobertura mbooth #1106069 cobertura-maven-plugin mizdebsk,msrb #1188794 cxf goldmann #1106113 cxf-build-utils goldmann #1106114 cxf-xjc-utils goldmann #1106115 fmpp willb #1106280 glazedlists mef #1096105,#1106639 hibernate-validator goldmann #1106763 ironjacamar ricardo #1106806 jaffl mmorsi #992586,#1106815 jboss-connector-1.6-api ricardo #1106862 jboss-dmr goldmann #1106864 jboss-jacc-1.4-api ricardo #1106872 jboss-jsf-2.1-api orphan #1085433,#1106882 jgoodies-animation jcapik,msimacek #1106943,#1106945 jgroups212 arg #1106947 jrosetta davidcl #1188795 jruby mmorsi,vondruch #1106973 lancet kushal #1105974 ldapjdk kwright,mharmsen,nkinder,rmeggins #1105978 maven-anno-plugin orphan #1096113,#1106160 maven-changelog-plugin huwang,jvanek #1106162 maven-ear-plugin huwang #1106164 maven-eclipse-plugin akurtakov,weli #1106165 maven-license-plugin guidograzioli #1106173 mojarra orphan #1049938,#1106227 mule arg #1096116,#1106251 mysql-connector-java mjakubicek #1106256 netty31 arg #1106291 openjpa gil #1106654 opensaml-java-xmltooling goldmann #1106661 rhq-plugin-annotations ricardo #1107022 robert-hooke salimma #1107028 sbt skottler,willb #1107277 scalacheck willb #1107280 scala-stm willb #1107279 shrinkwrap-resolver goldmann #1107302 spark willb #1107358 test-interface willb #1107447 typesafe-config willb #1107469 Per-maintainer list Format: maintainer package(s) - akurtakov maven-eclipse-plugin arg jgroups212,mule,netty31 davidcl jrosetta gil openjpa goldmann apt-maven-plugin,byteman,cxf,cxf-build-utils,cxf-xjc-utils,hibernate-validator,jboss-dmr,opensaml-java-xmltooling,shrinkwrap-resolver guidograzioli maven-license-plugin huwang maven-changelog-plugin,maven-ear-plugin jcapik jgoodies-animation jvanek maven-changelog-plugin kushal clojure-compat,lancet kwright ldapjdk mbooth cobertura mef glazedlists mharmsen ldapjdk mizdebsk cobertura-maven-plugin mjakubicek mysql-connector-java mmorsi jaffl,jruby msimacek jgoodies-animation msrb cobertura-maven-plugin nkinder ldapjdk ricardo ironjacamar,jboss-connector-1.6-api,jboss-jacc-1.4-api,rhq-plugin-annotations rmeggins ldapjdk salimma clojure-contrib,clojure-maven-plugin,clucy,robert-hooke skottler sbt tstclair amplab-tachyon vondruch jruby weli maven-eclipse-plugin willb akka,fmpp,sbt,scala-stm,scalacheck,spark,test-interface,typesafe-config -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: initscripts
On Mon, 2015-02-02 at 11:16 +0100, Dan Williams wrote: > Assuming the current versions of the various DEs, then in GNOME, the > thing you're looking at is the GNOME tools. If you're in KDE, then > it's the KDE tools. If you're in XFCE/LXDE, then it's likely nm- > connection-editor. So I guess I should say "what DE are you > running"... The GNOME applet actually spawns nm-connection-editor for some operations. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux
On 02.02.2015 19:58, David Herrmann wrote: > Hi > > On Sun, Feb 1, 2015 at 10:50 AM, poma wrote: >> MiracleCast - Howto >> "Current State" > > [snip] > >> Can folks from the NetworkManager team & systemd-networkd team answer >> regarding the current status in this matter? > > As people continuously ask me about this, I'll just try to answer it > on the public ML: > > To make Miracast work, we need access to a Wifi P2P API. The kernel > implements Wifi P2P and wpa_supplicant provides access to it via it's > ctrl-interface (and I think recently even gained a dbus API). In > MiracleCast I wrote a miracle-wifid daemon that wraps wpa_supplicant > and provides P2P to MircaleCast. However, this does not work well in > parallel to NetworkManager/wicd/connman/... running. You really cannot > run wpa_supplicant multiple times on the same interface. Hence, > MiracleCast development is currently stalled until the different > network-managers provide a P2P API. > Are you for to make the request for improvement towards NetworkManager? > Intel recently added such an API to ConnMan and provides a WFD > implementation on its own [1]. I highly recommend looking into it. > It's now up to NetworkManager to catch up. systemd-networkd doesn't do > L2 setup, so it's not really related. wicd is kinda dead [2], so I > doubt they'll come up with something. > > Furthermore, P2P support is pretty "limited" right now. Officially, > almost all recent devices support it, but it's particularly annoying > to set it up, due to major bugs across all the stacks (in no way > limited to linux drivers). I mean, 3 of 4 of my connection attempts > between Android and Windows devices fails.. not even talking about my > wpa_supplicant hacks. > Thank you for your comprehensive explanation! > As I'm not really interested in hacking on network-managers, I've > decided to stop working on MiracleCast. If, some day, there's a > working P2P stack on linux, I might resurrect it. But it sounds more > likely that I'll refer to the Intel solution (WYSIWIDI) instead. > There're also gstreamer plugins for WFD now, so maybe give them a try? > gst-rtsp-server-wfd https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md Pre-conditions: This module is running on established p2p connection with wifi direct, which means that you have to setup this network environment to run this module. I hope this link would be very helpful. ( http://cgit.freedesktop.org/~dvdhrm/miracle ) You are referring to them, they are referring to you. :) > Thanks > David > > [1] https://github.com/01org/wysiwidi > [2] https://answers.launchpad.net/wicd/+question/227789 > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: initscripts
On 03.02.2015 14:16, Lukáš Nykrýn wrote: > poma píše v Čt 22. 01. 2015 v 18:44 +0100: >> Lukáš 'Allo 'Allo >> >> I see that some people are trying to "modernize" Fedora. >> But what about RHEL relictum - initscripts, particularly now that we have >> NetworkManager/ModemManager and systemd-networkd, >> when will this package "fall off"? >> >> >> poma >> > > Hi, > > Sorry for late answer, I don't read fedora-devel that often. > I will not speak about NM, it has it's own use-cases and users. > Long-term plan is to remove networking part of initscripts and remove > rest of the package elsewhere (in that part kudos to Zbigniew already > moved some stuff to systemd package). > I think that networkd will hopefully substitute initscripts in minimal > setups, but we are far from there yet. Kdbus is prerequisite to proper > networkctl. I am working on generator to read ifcfg files and transform > them to network, netdev, links files. Michal is looking to team support > to networkd and so on. > Meanwhile I don't see why I could not fix some bugs and make the package > more complaint to fedora guidelines. > > I hope that answers your question. > > Lukas > Thanks for your reply. I have yet to consider. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
release-monitoring
Hi, I'm waiting for 2 days that release-monitoring firing bug [1] . https://github.com/pornel/pngquant/tags e got a tag with date of 3 days ago but release-monitoring not fire the bug. What I can do to fix this ? how I fire the bug ? or make monitoring check tags more often ? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1180501 Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: on software updates
On 02/02/2015 04:50 PM, Miloslav Trmač wrote: >> On 31 January 2015 at 21:57, Casey Jao wrote: >>> Are there any plans to let packages specify that they do not require a >>> total >>> system reboot to be updated? >> >> Yes, see https://wiki.gnome.org/Projects/SandboxedApps -- basically, >> you can't do updates of rpm-sourced system-wide app deployments >> without a reboot in a safe way. > > There are classes of RPMs that definitely can be done without a reboot in a > safe way (documentation-only; packages with a single executable and no > libraries / separate data files; and quite a few other cases), and letting > packagers opt them in to being updated without a reboot seems like a clear > improvement on the status quo. And updates of sandboxed apps will need system-wide (or even larger) coordination once they start to interact with each other, so it's essentially the same affair as with RPM: Doing the right thing requires work. And to be honest, reboots aren't the problem, it's state loss on application restart. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dependency chain issue...
On Tue, 2015-02-03 at 05:49 +0100, Kevin Kofler wrote: > Nathanael d. Noblet wrote: > > I have F21 Workstation installed. I installed liveusb-creator and the > > following was the dependency chain installed. > > > > http://www.fpaste.org/180713/34735142/ > > > > The real odd parts are all the multi-media being installed. This seems > > to stem from phonon being included in the chain. I don't really know why > > it is. Is this a bug? > > Problem #1 is that PyQt4 is not split into subpackages for the different Qt > modules being bound, so you end up with the Phonon and QtWebKit bindings > installed, which drag in the rest. So far we have chickened out of splitting > PyQt4, we'll need to look into this issue in the KDE SIG. > > Problem #2 is that you are getting phonon-backend-vlc instead of phonon- > backend-gstreamer, which ends up dragging in a lot of dependencies. Try > using --exclude=phonon-backend-vlc to force yum to pick -gstreamer instead. > This is a result of phonon-backend-vlc being in RPM Fusion (and you having > that enabled). It gets preferred by yum for some reason (shorter name? fewer > direct dependencies? something else? I don't know which of the many criteria > is being used here). I have always said that having phonon-backend-vlc in > the repositories is a bad idea (because you end up with a different default > backend depending on the repositories you have selected, leading to a > support nightmare), but I wasn't listened to. (In fact, this even affects > builds of KDE packages in RPM Fusion, where phonon-backend-vlc also gets > dragged in, and thus the KDE packages cannot be rebuilt against a new FFmpeg > before VLC is. That sucks.) Ah I see. Well thanks for the info. I was pretty surprised to see all these multi-media related things being dragged in for what is essentially a dd wrapper. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
datovka license change
License of Datovka was changed from LGPLv2+ to GPLv3+ starting with version 4. The updated package will get into Rawhide very soon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Filing Bugs for Python 3 Switch
On Mon, 2 Feb 2015 11:46:00 -0500 (EST) Bohuslav Kabrda wrote: > - Original Message - > > On Fri, 30 Jan 2015 04:44:19 -0500 (EST) > > Bohuslav Kabrda wrote: > > > > > I just had a quick IRC chat with DNF maintainer and he said we > > > still wants to switch to py3 for F22. > > > > Lovely. > > > > Perhaps we could get the dnf folks, anaconda, qa and fesco all > > together in one place to discuss this? > > Yeah, I'm not opposed to that, although with DevConf on my back, I'm > not likely to organize anything like this during this week. Yeah, many folks are traveling this week and next. I just hope we can get a clear picture of what dnf and anaconda folks want to do for this cycle as soon as we can. ...snip... > I created a change and submitted it to change wrangler: > https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements > I asked Jarda Reznik to process it ASAP, so it should be ready soon. Great ...snip... > I'm not saying we shouldn't. AFAIK dnf can be safely switched back > and forth, so the best way (IMO) would be to switch it ASAP to py3 > and see what it breaks. We can always switch it back before Beta or > so. I think that enough people will test it before then. The problem with that is that if we switch it now and run into problems with the python3 side and switch back, we could well have in the mean time added python2 issues since we were not using it. Anyhow, lets see what dnf maintainers, anaconda folks and fesco all want to do. kevin pgpdjcDGCy5gT.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: initscripts
poma píše v Čt 22. 01. 2015 v 18:44 +0100: > Lukáš 'Allo 'Allo > > I see that some people are trying to "modernize" Fedora. > But what about RHEL relictum - initscripts, particularly now that we have > NetworkManager/ModemManager and systemd-networkd, > when will this package "fall off"? > > > poma > Hi, Sorry for late answer, I don't read fedora-devel that often. I will not speak about NM, it has it's own use-cases and users. Long-term plan is to remove networking part of initscripts and remove rest of the package elsewhere (in that part kudos to Zbigniew already moved some stuff to systemd package). I think that networkd will hopefully substitute initscripts in minimal setups, but we are far from there yet. Kdbus is prerequisite to proper networkctl. I am working on generator to read ifcfg files and transform them to network, netdev, links files. Michal is looking to team support to networkd and so on. Meanwhile I don't see why I could not fix some bugs and make the package more complaint to fedora guidelines. I hope that answers your question. Lukas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libspiro soname bump
On Tue, Feb 3, 2015 at 12:41 AM, Pierre-Yves Chibon wrote: > On Tue, Feb 03, 2015 at 05:33:40AM +0100, Kevin Kofler wrote: > > Kevin Fenzi wrote: > > > Just a heads up that I am building a libspiro update in rawhide (only) > > > that has a soname bump in it. The only thing in Fedora that uses > > > libspiro is fontforge and I intend to rebuild that against it as well. > > > > Is it really worth announcing the soname bump in such a case? A library > only > > used by one application can effectively be treated as private, > especially if > > you're taking care of the rebuild. > > > > (I'm pointing this out because this isn't the first soname bump of this > kind > > being announced.) > > While you make a point, I prefer to see announce for every soname bump > (including those with very little dependency) than taking the risk of > missing > one (which of course would be an important one). > > I concur, speaking not only as someone who's missed dependencies before and the announcement helped me avoid breakage, but as someone who sometimes needs to run make clean ; make on personal projects and/or rebuild personal RPMs in these cases. > My 2cts, > Pierre > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 22 Rawhide 20150203 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 22 Rawhide 20150203. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pykickstart - 20150124: 1.99.65-1, 20150203: 1.99.66-1 anaconda - 20150124: 22.16-1, 20150203: 22.17-1 Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/22 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Rawhide_20150203_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Rawhide_20150203_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_22_Rawhide_20150203_Base https://fedoraproject.org/wiki/Test_Results:Fedora_22_Rawhide_20150203_Server https://fedoraproject.org/wiki/Test_Results:Fedora_22_Rawhide_20150203_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_22_Rawhide_20150203_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_22_Rawhide_20150203_Security_Lab Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/wikitcms/ On behalf of: adamwill ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: initscripts
- Original Message - > On Mon, Feb 2, 2015 at 12:19 AM, Björn Persson wrote: > > > What's the recommended way for a user to find out which of the three > > GUIs it is that pops up when one clicks on a menu entry, when the > > window title is something generic like "network configuration" and > > there is no about dialog? Run "ps -ef" and look for recently started > > processes? > > Stop Using Gnome is usually the fastest solution. The bloated > "assistance" it provides many features I consider detrimental to a > stable environment. Yeah, who needs features. And they only add features so that they can remove them anyway. *eyeroll* -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: initscripts
Nico Kadel-Garcia wrote: > On Mon, Feb 2, 2015 at 12:19 AM, Björn Persson wrote: > > > What's the recommended way for a user to find out which of the three > > GUIs it is that pops up when one clicks on a menu entry, when the > > window title is something generic like "network configuration" and > > there is no about dialog? Run "ps -ef" and look for recently started > > processes? > > Stop Using Gnome is usually the fastest solution. The bloated > "assistance" it provides many features I consider detrimental to a > stable environment. Of course I don't use Gnome 3, but what does that have to do with the question about distinguishing between different Network Manager GUIs? -- Björn Persson pgpta7aofzv0S.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Cast your vote - FESCo elections closes today!
Hi everyone, this is a friendly reminder that today is the last chance to vote in the FESCo elections - great opportunity for everyone to steer future Fedora's development. Voting closes promptly at 2015-02-03 23:59 UTC. Go to https://admin.fedoraproject.org/voting/ and cast your vote! If you're still undecided, we have two new interviews available: * Alberto Ruiz http://bit.ly/18JS1zZ * Adam Jackson http://bit.ly/1DsyqgK (And it's worth reading even you already voted) The other Fedora Magazine interviews: * Kevin Fenzi http://bit.ly/16r7NPl * Tomas Hozza http://bit.ly/1Cspprd * Debarshi Ray http://bit.ly/1z7IasJ * Parag Nemade http://bit.ly/1HRSI9T * David King http://bit.ly/1K6ZshQ Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
5tFTW: FESCo Vote, Fedora Swag, Stats, Job Opening, and CentOS & EPEL (2015-02-03)
Fedora is a big project, and it’s hard to keep up with everything that goes on. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for February 3rd, 2015: Vote now in FESCo Elections --- The election for Fedora 22 – Fedora 23 members of FESCo (the Fedora Engineering Steering Committee) is now open (through 00:00 February 4th — note that that’s *today*, Tuesday, February 3rd — and early evening in the United States). Read interviews with candidates here: - Debarshi Ray (rishi) * http://fedoramagazine.org/fesco-elections-interview-with-debarshi-ray-rishi/ - Parag Nemade (paragan) * http://fedoramagazine.org/fesco-elections-interview-with-parag-nemade-paragan/ - Tomas Hozza (thozza) * http://fedoramagazine.org/fesco-elections-interview-with-tomas-hozza-thozza/ - David King (amigadave) * http://fedoramagazine.org/fesco-elections-interview-with-david-king-amigadave/ - Kevin Fenzi (nirik) * http://fedoramagazine.org/fesco-elections-interview-with-kevin-fenzi-nirik/ Adam Jackson (ajax) and Alberto Ruiz (aruiz) are also running but no interviews area available. See the Elections wiki for each candidates’ self-nomination. Read the interviews, and then vote! (Note that the Environments and Stacks Working Group had a number candidates equal to the number of open slots, and so decided no election is necessary for that group.) * https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=401340 * https://admin.fedoraproject.org/voting * https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-January/000667.html Get Swag from the Fedora Store! --- Thanks to Ruth Suehle, we now have an official store for Fedora-branded swag. As Ruth explains, we’re leveraging Red Hat’s “Cool Stuff Store” for this, because it helps us with legal obligations as well as inventory and financial requirements. This is a sort of trial run, with four items to start. If it’s successful, we can have more (and possibly look at expanding to other countries — we are very aware that the current international shipping prices are… not great). (I see that many shirt sizes are already out of stock, so that’s a good sign!) Also note: these items are priced at our cost; Red Hat and Fedora aren’t making any money this way (we really can’t, even if we wanted to). It’s just an easy way for you to get Fedora-branded gear. * https://redhat.corpmerchandise.com/ProductList.aspx?did=20588 * https://lists.fedoraproject.org/pipermail/announce/2015-January/003251.html Fedora Job Opening: Infrastructure Engineer --- The Fedora Infrastructure team headed by Paul Frields has a new opening! See the Red Hat Jobs page for full details, but the quick summary is that we’re looking for a software engineer / programmer with experience in continuous delivery to help the Release Engineering team build the next generation of the tools we use to produce Fedora. The job listing came out highly slanted towards Project Atomic, as that is the current hotness, but don’t expect to be pigeonholed there. Do you have experience as a site reliability engineer? Is your instinct to develop systems to pass arbitrary condiments? Have you been doing actual devops for so long that you just sigh about how the term is used today? Does Fedora’s six-month release cycle seem disturbingly slow — and you know what to do about it? This may be the job for you! (Note that the job is listed as in Raleigh, North Carolina, but we are open to applicants worldwide.) * http://jobs.redhat.com/jobs/descriptions/lead-engineer-fedora-project-atomic-infrastructure-raleigh-north-carolina-job-1-5092722 * http://xkcd.com/974/ Fedora Yum Connection Stats --- More on this later, but here’s a chart Stephen Smoogen put together for my presentations at FOSDEM and DevConf.cz: > http://fedoramagazine.org/wp-content/uploads/2015/02/fedora-os-all-mov_avg-1024x363.png The data counts updates-mirror connections from the same IP address a single time a day. Smooge notes that a large number of caveats should be considered, including changing use of NAT over time and increasingly short DHCP leases. Also, this almost exclusively counts North America and Europe, where cheap always-on Internet is commonplace. And, of course, it only counts systems which actually check for updates regularly; many don’t. So, with all of those caveats aside, there are some interesting points. There’s a general third/third/third split in updating: when new Fedora release comes out, a third of users update almost immediately, another third update by end-of-life when the “N+1″ release is out, and the final third are end up as a long tail which persists forever. The chart basically starts with
Re: FESCo elections are open
- Original Message - > Stephen Gallagher wrote: > > At the same time, until fairly recently (Kalev), the Workstation WG (and > > formerly Desktop team) hasn't had a great deal of representation on > > FESCo. It's good to see more faces from that side of the Fedora Project > > running for FESCo. > > As if FESCo weren't already biased enough towards GNOME… :-( Sigh! Well, FESCo elections are open for everyone and for last few years we're happy to have at least enough number of candidates to start elections... Jaroslav > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20150203 changes
Compose started at Tue Feb 3 05:15:03 UTC 2015 Broken deps for i386 -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6 [barman] barman-1.3.3-4.fc22.noarch requires python-dateutil < 0:2.0 [boswars] boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so [bro] broccoli-2.3-1.fc22.i686 requires bro-2.3 python-broccoli-2.3-1.fc22.i686 requires bro-2.3 [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 [dsqlite] dsqlite-1.1.1-5.fc22.i686 requires libphobos-ldc.so.64 [fawkes] fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so [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 [gitg] gitg-3.14.1-1.fc22.i686 requires libgit2.so.21 gitg-libs-3.14.1-1.fc22.i686 requires libgit2.so.21 [gl3n] gl3n-0.20140505-13.fc22.i686 requires libphobos-ldc.so.64 [hugin] hugin-2013.0.0-11.fc22.i686 requires libpano13.so.2 hugin-base-2013.0.0-11.fc22.i686 requires libpano13.so.2 [libhocr] libhocr-gtk-0.10.17-18.fc22.i686 requires python-imaging-sane [libvirt] libvirt-client-1.2.12-1.fc22.i686 requires libxenlight.so.4.4 libvirt-client-1.2.12-1.fc22.i686 requires libxenctrl.so.4.4 libvirt-daemon-1.2.12-1.fc22.i686 requires libxenlight.so.4.4 libvirt-daemon-1.2.12-1.fc22.i686 requires libxenctrl.so.4.4 libvirt-daemon-driver-libxl-1.2.12-1.fc22.i686 requires libxenlight.so.4.4 libvirt-daemon-driver-libxl-1.2.12-1.fc22.i686 requires libxenctrl.so.4.4 libvirt-lock-sanlock-1.2.12-1.fc22.i686 requires libxenlight.so.4.4 libvirt-lock-sanlock-1.2.12-1.fc22.i686 requires libxenctrl.so.4.4 [nifti2dicom] nifti2dicom-0.4.9-1.fc22.i686 requires libitksys-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkopenjpeg-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkdouble-conversion-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkNetlibSlatec-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5_hl.so.8 nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5_cpp.so.8 nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5.so.8 nifti2dicom-0.4.9-1.fc22.i686 requires libITKznz-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKniftiio-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKgiftiio-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKWatersheds-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVtkGlue-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoCore-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVTK-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVNLInstantiation-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKStatistics-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKSpatialObjects-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKReview-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKQuadEdgeMesh-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKPolynomials-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKPath-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizersv4-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizers-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKNrrdIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libIT
