rawhide report: 20150628 changes

[Fedora Rawhide Report]

Compose started at Sun Jun 28 05:15:04 UTC 2015
Broken deps for i386
--
[airsched]
airsched-1.00.0-12.fc23.i686 requires libzmq.so.4
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aws]
aws-tools-2015-2.fc23.i686 requires libaws_ssl.so
[bluetile]
bluetile-0.6-28.fc23.i686 requires 
ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
[bustle]
bustle-0.4.8-3.fc23.i686 requires libHSsetlocale-1.0.0.1-ghc7.8.4.so
bustle-0.4.8-3.fc23.i686 requires 
ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0)
bustle-0.4.8-3.fc23.i686 requires 
ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
[clearsilver]
perl-clearsilver-0.10.5-29.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.1)
perl-clearsilver-0.10.5-29.fc22.i686 requires libperl.so.5.20
[ghc-gtk]
ghc-gtk-0.13.4-1.fc22.i686 requires 
ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
ghc-gtk-devel-0.13.4-1.fc22.i686 requires 
ghc-devel(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
[ghc-hgettext]
ghc-hgettext-0.1.30-8.fc23.i686 requires 
libHSsetlocale-1.0.0.1-ghc7.8.4.so
ghc-hgettext-0.1.30-8.fc23.i686 requires 
ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0)
ghc-hgettext-devel-0.1.30-8.fc23.i686 requires 
libHSsetlocale-1.0.0.1-ghc7.8.4.so
ghc-hgettext-devel-0.1.30-8.fc23.i686 requires 
ghc-devel(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0)
ghc-hgettext-devel-0.1.30-8.fc23.i686 requires 
ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0)
[ghc-hjsmin]
ghc-hjsmin-0.1.4.7-7.fc23.i686 requires 
ghc(language-javascript-0.5.13-0b8335d6a2507ee73f3b41c61a1ea2bf)
ghc-hjsmin-devel-0.1.4.7-7.fc23.i686 requires 
ghc-devel(language-javascript-0.5.13-0b8335d6a2507ee73f3b41c61a1ea2bf)
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[julia]
julia-0.3.7-2.fc23.i686 requires libspqr.so.1
julia-0.3.7-2.fc23.i686 requires libLLVM-3.5.so
julia-devel-0.3.7-2.fc23.i686 requires libLLVM-3.5.so
[klavaro]
klavaro-3.01-0.pre1.1.fc23.1.i686 requires libgtkdataboks.so.0
[ldns]
perl-ldns-1.6.17-14.fc23.i686 requires perl(:MODULE_COMPAT_5.20.2)
perl-ldns-1.6.17-14.fc23.i686 requires libperl.so.5.20
[leksah-server]
leksah-server-0.14.3.1-2.fc23.i686 requires 
ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
[libfli]
libfli-devel-1.7-16.fc23.i686 requires libfli{?_isa} = 0:1.7-16.fc23
[matreshka]
matreshka-servlet-devel-0.7.0-2.fc23.i686 requires 
matreshka-servlet-lib{?_isa} = 0:0.7.0-2.fc23
matreshka-servlet-lib-0.7.0-2.fc23.i686 requires matreshka{?_isa} = 
0:0.7.0-2.fc23
matreshka-spikedog-api-devel-0.7.0-2.fc23.i686 requi

[Test-Announce] 2015-06-29 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2015-06-29
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's QA meeting time again!

Let's check in on F23 status and the F23 Test Day process. If anyone
has any other suggested topics, please send them along!

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 23 status
3. Test Days
4. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

___
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: [Fedora-packaging] Packaging Guidelines for Applications using Git Submodules

[Kevin Kofler]

Gerald B. Cox wrote:
> I'm trying to figure out the best way to handle the situation where a
> project decides to use submodules in Git.  The archive generated doesn't
> incorporate the submodule files.

I just generated a separate package for the submodule and added it as a 
Source1 (which is unpacked separately in %prep):
http://pkgs.fedoraproject.org/cgit/calamares.git/tree/calamares.spec?id=8c7e68aa6b0b6d541bb9037ee425b7fdeebc236b

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

Re: F23 Self Contained Change: Astronomy Spin

[Kevin Kofler]

M. Edward (Ed) Borasky wrote:
> Seems like the easiest path would be to make sure all the astronomy
> packages land on the Science / KDE spin that already exists and do a
> lot of marketing / blogging / etc. to a targeted group of "citizen
> astronomers". For that matter, maybe their should be a rebranding of
> the spin as "Fedora for Citizen Scientists".

What's the problem with having a dedicated Astronomy spin?

The thing is that KStars is quite large (it contains a lot of data), as are 
the other scientific applications when taken together. Having both on one 
big spin is not necessarily the best approach.

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

Re: F23 Self Contained Change: Astronomy Spin

[Corey Leong]

A "Fedora for Citizen Scientists" spin may be confused with my spin in
development, Fedora Netizen, a portmanteau of internet and citizen. Suggest
sticking with Fedora Astronomy or as an alternative, Fedora Space, for
reducing any confusion between the two spins.

On Sat, Jun 27, 2015 at 12:38 PM, M. Edward (Ed) Borasky 
wrote:

> Seems like the easiest path would be to make sure all the astronomy
> packages land on the Science / KDE spin that already exists and do a
> lot of marketing / blogging / etc. to a targeted group of "citizen
> astronomers". For that matter, maybe their should be a rebranding of
> the spin as "Fedora for Citizen Scientists".
>
> On Sat, Jun 27, 2015 at 6:45 AM, Jonathan Wakely 
> wrote:
> > On 26/06/15 15:11 -0600, Chris Murphy wrote:
> >>
> >> What about a Scientific & Astronomy spin? Looks like Scientific uses
> >> KDE though, *shrug*.
> >
> >
> > I thought the point is that basing Astronomy on KDE is preferable, so
> > that's a Good Thing, surely?
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
>
> --
> OSJourno: Robust Power Tools for Digital Journalists
>
> http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists
>
> Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Corey Leong, M.N.M., M.A.*
PO Box 691871
Orlando, FL 32869

email: cle...@fedoraproject.org 
web: http://coreyleong.org
blog: http://blog.coreyleong.org
tweet: http://twitter.com/coreyleong
phone: (407) 279-1133
skype: coreyleong
-- 
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: F23 Self Contained Change: Astronomy Spin

[Jonathan Underwood]

On 28 June 2015 at 23:54, Kevin Kofler  wrote:
> M. Edward (Ed) Borasky wrote:
>> Seems like the easiest path would be to make sure all the astronomy
>> packages land on the Science / KDE spin that already exists and do a
>> lot of marketing / blogging / etc. to a targeted group of "citizen
>> astronomers". For that matter, maybe their should be a rebranding of
>> the spin as "Fedora for Citizen Scientists".
>
> What's the problem with having a dedicated Astronomy spin?
>
> The thing is that KStars is quite large (it contains a lot of data), as are
> the other scientific applications when taken together. Having both on one
> big spin is not necessarily the best approach.


I agree. The professional and amateur Astronomy community is a large
one, and having a spin targetting that community directly would be a
very good marketing move. I am very much for this (and not an
Astronomer).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

packages to retrofit to workstation

[Les Howell]

Hi, guys and gals,
I am currently running the FEL spin of f20.  I am going to upgrade to a
later version, probably F22, by the save users and reformat process.
However in the rush to cloud/workstation, FEL spin no longer appears
anywhere at this time.  I currently have listed all the programs I use
and wish to restore to get back to my current level of development.
Also there seems to have been a devolution towards binary system files
that has somehow taken over linux.  This is not good.  there is
absolutely no need for binary formatted system files, and to have them
is to devolve to an earlier era, circa 1960.   The move to eliminate
binary files was due to the issues of upgrading to new systems and the
inability to read and decipher what an older system was doing.  
You may lambaste me for not posing this stuff as a question or even
just as a rant, but losing FEL was not good, and the other spins from
people who had solved the issues required to get a system to be a master
development station in an area of study were apparently thrown out with
the old bathwater so to speak.  All of this is a sad loss for Fedora,
and even a cash loss to Redhat eventually if they go the same way.
Please, before going too far, look, discuss the history and find out
why Linux was developed the way it was.  
I have to choose a distribution to use.  For now I will update to F22.
But if this run to the past continues, I will find another solution.  I
must take care of my long standing of development and good design
principles.  I hope you all get to that perspective without losing too
much of the good stuff that so many have brought to the Linux community.

Regards,
Les Howell

-- 
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: packages to retrofit to workstation

[Matthew Miller]

On Sun, Jun 28, 2015 at 07:04:44PM -0700, Les Howell wrote:
>   I am currently running the FEL spin of f20.  I am going to upgrade to a
> later version, probably F22, by the save users and reformat process.
> However in the rush to cloud/workstation, FEL spin no longer appears
> anywhere at this time.  I currently have listed all the programs I use

Desktop spins can now be found at ,
and spins which focused on collections of software for a purpose - like
Electronic Lab - are now at . However,
Electronic Lab is not. This isn't because it was kicked out or
anything: it's because no one who cared about it was around to made
sure it worked.

>   You may lambaste me for not posing this stuff as a question or even
> just as a rant, but losing FEL was not good, and the other spins from
> people who had solved the issues required to get a system to be a master
> development station in an area of study were apparently thrown out with
> the old bathwater so to speak.  All of this is a sad loss for Fedora,
> and even a cash loss to Redhat eventually if they go the same way.

No; nothing was thrown out. No one made it happen, so it didn't. If you
want to make it happen again, though, AWESOME.



-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Best practice for latest package in COPR?

[Dave Johansen]

I would like to start providing the latest version of ODB in a COPR for
stable releases of Fedora and RHEL. Is there a "best practice" for this
sort of thing?

The main question I have is:
Is it "better" to use a single repo and continue to update it with the
latest release?
Or is it better to have a repo for version 2.4 and then a separate one for
when 2.5 comes out?

Thanks,
Dave
-- 
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: F23 Self Contained Change: Astronomy Spin

[Chris Murphy]

On Sun, Jun 28, 2015 at 6:20 PM, Jonathan Underwood
 wrote:
> On 28 June 2015 at 23:54, Kevin Kofler  wrote:
>> M. Edward (Ed) Borasky wrote:
>>> Seems like the easiest path would be to make sure all the astronomy
>>> packages land on the Science / KDE spin that already exists and do a
>>> lot of marketing / blogging / etc. to a targeted group of "citizen
>>> astronomers". For that matter, maybe their should be a rebranding of
>>> the spin as "Fedora for Citizen Scientists".
>>
>> What's the problem with having a dedicated Astronomy spin?
>>
>> The thing is that KStars is quite large (it contains a lot of data), as are
>> the other scientific applications when taken together. Having both on one
>> big spin is not necessarily the best approach.
>
>
> I agree. The professional and amateur Astronomy community is a large
> one, and having a spin targetting that community directly would be a
> very good marketing move. I am very much for this (and not an
> Astronomer).

I like the idea also, and by suggesting alternatives I didn't mean to
indicate a tepid opinion.

-- 
Chris Murphy
-- 
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: Best practice for latest package in COPR?

[Miroslav Suchý]

Dne 29.6.2015 v 06:13 Dave Johansen napsal(a):
> I would like to start providing the latest version of ODB in a COPR for 
> stable releases of Fedora and RHEL. Is there a
> "best practice" for this sort of thing?
> 
> The main question I have is:
> Is it "better" to use a single repo and continue to update it with the latest 
> release?
> Or is it better to have a repo for version 2.4 and then a separate one for 
> when 2.5 comes out?

It'is really up to you.
It depends what you want to "support".

It can be that you have project with latest stable version for all platforms 
(Fedora and Epel) so you provide 2.4
version where in distribution is "just" 2.4. And then another project with 
nightly builds.
This is what *I* would choose. So your users can choose their level of 
stability vs bleeding edge.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct