Re: [Test-Announce] Taskotron Has Replaced AutoQA

2014-10-13 Thread Vít Ondruch
You have not mentioned URL of Taskotron here nor the Wiki is updated to
contain the link to the production version of Taskotron.

Vít



Dne 13.10.2014 v 19:08 Tim Flink napsal(a):
> This has been a long time coming, but AutoQA is no longer scheduling
> jobs and Taskotron is now running all of the automated checks on
> packages/updates.
>
> The changeover should be transparent to most people - the same checks
> are being run in pretty much the same situations. Until Bodhi 2.0 is
> deployed, we're planning to continue providing feedback on updates in
> the form of bodhi comments.
>
> While Taskotron is a huge step forwards in terms of having a capable
> and maintainable automation system for Fedora, it isn't perfect on the
> UX front. That being said, there has never been much traffic to the
> AutoQA instance and that's why we haven't been focusing as much on the
> frontend.
>
> This changeover is just the beginning - we're still hard at work to add
> features to Taskotron. The first major feature to be added is
> disposable test clients [1] which will pave the way for folks to submit
> tasks to be run in Taskotron, among other oft requested features.
>
> Huge props to the folks who have helped make this happen - the usual
> suspects from Fedora QA ( Kamil Páral, Josef Skládanka, Martin
> Krizek, Lukáš Brabec, Jan Sedlák, Petr Schindler, John Dulaney, Mike
> Ruckman), Ralph Bean (patches to ResultsDB), Kevin Fenzi and Stephen
> Smoogen (lots of help with and patience during deployment) and many,
> many other folks who have contributed ideas, bug reports and/or moral
> support.
>
> If you're interested in learning more about Taskotron or helping us with
> dev tasks, I've included some reference links at the end of this email.
>
> As always, please come find us (on the qadevel@ list or in #fedora-qa)
> if you have any questions or concerns.
>
> Tim
>
> [1] https://phab.qadevel.cloud.fedoraproject.org/T298
>
> General Wiki Page for Taskotron:
>   - http://fedoraproject.org/wiki/Taskotron
>
> Libtaskotron Documentation:
>   - https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/
>
> QA Devel Issue Tracking and Project Management:
>   - https://phab.qadevel.cloud.fedoraproject.org/
>
> "Taskotron and Me" Talk from Flock 2014:
>   - http://youtu.be/jMTUFCFJS6o
>
> Taskotron Tagged Articles on tflink's Blog:
>   - http://tirfa.com/tag/taskotron.html
>
>
> ___
> 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: Self Introduction: Ma Kai

2014-10-13 Thread Josef Stribny
Welcome aboard!

Josef

- Original Message -
From: "Ma Kai" 
To: devel@lists.fedoraproject.org
Sent: Saturday, October 11, 2014 5:18:49 PM
Subject: Self Introduction: Ma Kai

Hi Fedorians,

I'm an amateur free software developer, and Fedora really "feels right"
to me. I do like it! Therefore I'm more than willing to join the Fedora
Project.

Review request: https://bugzilla.redhat.com/show_bug.cgi?id=1151759

Regards,
Ma Kai

-- 
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

Fedora 21 Beta Change Freeze

2014-10-13 Thread Dennis Gilmore
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

as the Fedora 21 schedule[1] states the Beta change freeze is upon
us. As of now all Beta freeze only accepted exceptions[2] will be
allowed in. 


we are at the beta stage of release, so the Beta_to_Pre_Release[3]
stage of the updates policy applies. 

Regards

Dennis

[1] http://fedorapeople.org/groups/schedule/f-21/f-21-devel-tasks.html
[2] http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[3] http://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUPLDQAAoJEH7ltONmPFDR7bwQANK1a6zC3DPtVKU64+PlvWh1
ZEMY5oawUTLhBeo+AmzHvIhrhtlIIezVDWRiAkxgetczPgcjvgVmImUncQ5sL7N7
AXRdW6RURPovSRk7t1i+KV08T+1SR8V9iogqbUsfywqVL+AUjks6tzcLwfd2+RwI
vMufCwgEYFTdic2ynzVJc5MlCoICFA23k6PRhJgb42WANgFLs/Gr73Mh0GVnRPZm
7QDpJpHqhVn41brUaZf15D5S8bg9t+NG1FxuTkQJiJcVKeL0qXMFSSF8Jl1Xwl7X
+JebLmEQ8nlsSzfUOBHqVv2j0sAMYfDBuDxc7BYSPl2IqodVFdB9fTxPxsU1loBG
cx0vJ672WtHnA5eQK66+X9aBmtLNN1/9jjsjmAcS3kPW4wXD6CTZqxvu8Uyn5RN6
vbt530HdsLM1865owTdD2w1g/sHZIOafzrqtreEL4s/DjPEB69epBLBcvisekzua
AB3g1aO9bwxOqYSQAYUOvJ864f2oSkFrTkIlur2AlCKQQCFw+NTN49cnwpssMFdh
Ibt8PzsnWH9TELuR9UsTnuKYPoddHhemJQbXZrcKYPSZx/Wl5RS/V8aXTS5FbwQx
/hkCK9msELIlVPsET3Z26BxN6gzT0VvOqLyB1Ke50cMy5XaoC10SXP51bsChumYq
pFSSm+dc1O10iEBYz3eC
=zU5Z
-END PGP SIGNATURE-
___
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

Re: [lapack] Use generic macro to detect 64 bit platforms

2014-10-13 Thread Jerry James
On Mon, Oct 13, 2014 at 6:00 PM, Peter Robinson
 wrote:
> commit 1c07fc6e86ce11c81da77ac6c55b934594f25bee
> Author: Peter Robinson 
> Date:   Tue Oct 14 01:00:36 2014 +0100
>
> Use generic macro to detect 64 bit platforms
>
>  lapack.spec |7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> ---
> diff --git a/lapack.spec b/lapack.spec
> index 0be11ec..c323757 100644
> --- a/lapack.spec
> +++ b/lapack.spec
> @@ -1,7 +1,7 @@
>  %global shortver   3
>  %global mediumver  %{shortver}.5
>
> -%ifarch x86_64 ppc64
> +%if %{__isa_bits} == 64
>  %global arch64 1
>  %else
>  %global arch64 0

I have used this approach in some spec files myself, but I recently
read that the %{__isa_bits} macro is not necessarily defined for all
64-bit platforms, just for those that are multiarch; i.e., that have a
32-bit variant [1].  Is this true for Fedora?  Do we support any
platforms for which %{__isa_bits} is NOT defined?  Even if we don't
now, is there any possibility that we will in the future?  It sure
would be nice to have a macro we can rely on to distinguish between
32-bit and 64-bit platforms for some packages.

Footnotes:
[1] http://www.rpm.org/wiki/PackagerDocs/ArchDependencies
-- 
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

Re: Multiple problems with multiple monitors

2014-10-13 Thread Basil Mohamed Gohar
On 10/13/2014 05:18 PM, David Airlie wrote:
> 
>>
>>
>> I've searched for bugs related to the specific problems I've been having, and
>> I've not been able to find anything that describes what I'm seeing.
>>
>> I have an HP EliteBook 840 that also comes with an UltraDock, to which I've
>> plugged-in two external monitors and I use in conjunction with the built-in
>> laptop display.
> 
> What Fedora distro are you using?
> 
> Does this laptop have multiple GPUs? what GPU is it etc.
> 
> You probably should file a bug against the primary GPU with the dmesg.
> 
>> Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes.
>> When I redock after the laptop has been started when unconnected, one of the
>> two external monitors start-up (the one connected by VGA), but not the one
>> connected by a DisplayPort connection. And, recently (but not when I first
>> started using this laptop with the dock, which was about a month ago), now
>> when I start-up with the laptop docked and both external monitors connected,
>> both external monitors will be active, but the built-in display will show
>> nothing. Gnome Shell reports the built-in display is active, but will not
>> display anything unless I deactivate it and reactivate it via the settings
>> "Displays" utility.
> 
> This sounds like MST releated but I can't say without more info.
> 
> Dave.
> 

Thanks, Dave, I was hoping you'd see this. :)

The laptop has two GPUs, one Intel and the other Radeon.  I am not sure
how to tell which display is controlled by which device.

It is Fedora 20.  I can get you more details when I get back to work
tomorrow.  I'm happy to provide whatever information is necessary, but
that is part of the problem, I'm not sure what is useful to help figure
this out.

-- 
Libre Video
http://librevideo.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

Re: [pkgdb] Call for beta-testers for group maintainership

2014-10-13 Thread Rich Mattes
On Tue, Oct 7, 2014 at 10:43 AM, Kevin Fenzi  wrote:

> On Tue, 07 Oct 2014 14:32:42 +0200
> Stanislav Ochotnicky  wrote:
>
> > On Tue 07 Oct 2014 01:50:46 PM CEST Pierre-Yves Chibon wrote:
> > > On Mon, Oct 06, 2014 at 04:43:53PM -0400, Rich Mattes wrote:
> > >>On Mon, Oct 6, 2014 at 12:04 PM, Pierre-Yves Chibon
> > >>  wrote:
> > >>
> > >>  Dear all,
> > >>
> > >>  A long desired and awaited feature for pkgdb2 is the
> > >> possibility to have FAS
> > >>  groups maintain packages.
> > >>
> > >>Hooray!A  Thanks for this, I'm going to start testing it with
> > >> the robotics-sig FAS group and some of my packages.
> > >
> > > Awesome!
> > >
> > >>  I put together some instructions on the requirements and
> > >> steps: http://pkgdb2.readthedocs.org/en/latest/groups.html
> > >>
> > >>I followed the above instructions to update the FAS group, but
> > >> I have a question about one of the requirements.A  The
> > >> instructions say that the mailing list for the group needs to have
> > >> a rhbz account.A  As far as I know bugzilla sends a confirmation
> > >> email during the account creation process.A  This seems kind of
> > >> iffy when the email address is for a public list: should I just
> > >> create the account and try to be the first list subscriber to
> > >> click the confirmation link?A  Or is there another way to create a
> > >> bugzilla account for SIG mailing lists?
> > >
> > > That's a good question. I guess I approached with the idea that the
> > > list would be new as well. So eventually, you would be the only one
> > > subscribed to it and thus the question is simple(r) to answer.
> > > But for the case of an existing list, I wonder if we can do better
> > > than what you describe.
> > > @Kevin any thoughts on this?
> >
> > This is normally done by sending an email to
> > bugzilla-reque...@redhat.com and requesting creation of "pseudo" user
> > with email being the mailing list. Of course there would be no real
> > control over this pseudo user.
>
> I was thinking we would create a new list for each of these groups.
> These lists would be private (because they could contain private bugs
> assigned to the group). Then we could also filter on bugzilla password
> changes to catch those in moderation, or just let them through to the
> list since the list is private and only has on it trusted folks in the
> group.
>
> We could ask for pseudo users as well, but I've never done so, so not
> sure how long that takes, etc.
>
>
I don't anticipate any issues requiring private bugs given the scope of our
work, so making a new private mailing list doesn't seem too enticing.  It
might be easier to use the public mailing list, and just not assign
watchbugzilla and watchcommits to the pkgdb group.  I will bounce it off of
the robotics sig list, and if we do end up asking for a pseudo user on
bugzilla I'll report back with how long it took and any other issues.

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: Multiple problems with multiple monitors

2014-10-13 Thread David Airlie

> 
> 
> I've searched for bugs related to the specific problems I've been having, and
> I've not been able to find anything that describes what I'm seeing.
> 
> I have an HP EliteBook 840 that also comes with an UltraDock, to which I've
> plugged-in two external monitors and I use in conjunction with the built-in
> laptop display.

What Fedora distro are you using?

Does this laptop have multiple GPUs? what GPU is it etc.

You probably should file a bug against the primary GPU with the dmesg.

> Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes.
> When I redock after the laptop has been started when unconnected, one of the
> two external monitors start-up (the one connected by VGA), but not the one
> connected by a DisplayPort connection. And, recently (but not when I first
> started using this laptop with the dock, which was about a month ago), now
> when I start-up with the laptop docked and both external monitors connected,
> both external monitors will be active, but the built-in display will show
> nothing. Gnome Shell reports the built-in display is active, but will not
> display anything unless I deactivate it and reactivate it via the settings
> "Displays" utility.

This sounds like MST releated but I can't say without more info.

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

Agenda for Env-and-Stacks WG meeting (2014-10-14)

2014-10-13 Thread Honza Horak

WG meeting will be at 13:00 UTC (14:00 London, 15:00 Brno, 9:00 Boston,
22:00 Tokyo) in #fedora-meeting on Freenode.

= Topics =
* Docker, Docker, Docker :)
* Dockerfile_lint -- where to include it
* New checks for Dockerfile_lint
* Packaging rules for Dockerfiles in Fedora
* Picking chairman for the next meeting
* OpenFloor
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Review swap

2014-10-13 Thread Jerry James
One of my packages has picked up a dependency on libpuma in a new release:

https://bugzilla.redhat.com/show_bug.cgi?id=1135654

Would someone care to do a review swap?  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

[Test-Announce] Taskotron Has Replaced AutoQA

2014-10-13 Thread Tim Flink
This has been a long time coming, but AutoQA is no longer scheduling
jobs and Taskotron is now running all of the automated checks on
packages/updates.

The changeover should be transparent to most people - the same checks
are being run in pretty much the same situations. Until Bodhi 2.0 is
deployed, we're planning to continue providing feedback on updates in
the form of bodhi comments.

While Taskotron is a huge step forwards in terms of having a capable
and maintainable automation system for Fedora, it isn't perfect on the
UX front. That being said, there has never been much traffic to the
AutoQA instance and that's why we haven't been focusing as much on the
frontend.

This changeover is just the beginning - we're still hard at work to add
features to Taskotron. The first major feature to be added is
disposable test clients [1] which will pave the way for folks to submit
tasks to be run in Taskotron, among other oft requested features.

Huge props to the folks who have helped make this happen - the usual
suspects from Fedora QA ( Kamil Páral, Josef Skládanka, Martin
Krizek, Lukáš Brabec, Jan Sedlák, Petr Schindler, John Dulaney, Mike
Ruckman), Ralph Bean (patches to ResultsDB), Kevin Fenzi and Stephen
Smoogen (lots of help with and patience during deployment) and many,
many other folks who have contributed ideas, bug reports and/or moral
support.

If you're interested in learning more about Taskotron or helping us with
dev tasks, I've included some reference links at the end of this email.

As always, please come find us (on the qadevel@ list or in #fedora-qa)
if you have any questions or concerns.

Tim

[1] https://phab.qadevel.cloud.fedoraproject.org/T298

General Wiki Page for Taskotron:
  - http://fedoraproject.org/wiki/Taskotron

Libtaskotron Documentation:
  - https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/

QA Devel Issue Tracking and Project Management:
  - https://phab.qadevel.cloud.fedoraproject.org/

"Taskotron and Me" Talk from Flock 2014:
  - http://youtu.be/jMTUFCFJS6o

Taskotron Tagged Articles on tflink's Blog:
  - http://tirfa.com/tag/taskotron.html


signature.asc
Description: PGP signature
___
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: Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap

2014-10-13 Thread Kevin Fenzi
On Mon, 13 Oct 2014 12:02:31 -0400 (EDT)
Jaroslav Skarvada  wrote:

> Same problem with https://kojipkgs.fedoraproject.org/
> 
> I am pretty sure it worked on Friday, Fedora 20 with latest
> updates, firefox-32.0.2-1.fc20.x86_64 with default configuration,
> nothing changed on my side, opened ticket [1]
> 
> thanks & regards

This was due to some changes we pushed out this morning. ;( 

It's been reverted and everything should be back to normal with
kojipkgs now. The issue was only there for a few minutes (would have
been less if squid had restarted as it should have). 

Sorry for the trouble

kevin


signature.asc
Description: PGP 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

[Test-Announce] 2014-10-15 @ 16:00 UTC ** F21 Blocker Review Meeting

2014-10-13 Thread Mike Ruckman
# F21 Blocker Review meeting
# Date: 2014-10-15
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net

As testing of Beta TC3 continues, it's time for another blocker review meeting.
Currently we have 3 proposed blockers and 2 proposed FEs. We have 10 accepted
blockers to review. Should be a shorter meeting :)

If you want to take a look at the accepted blockers, the full list can be found
here: https://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist

We'll be evaluating these bugs to see if they violate the Beta
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F21 can be found on the
wiki [0].

For more information about the Blocker and Freeze exception process,
check out these links:
  - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
  - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out the SOP
on the wiki:
  - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

See you Wednesday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria

-- 
// 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: Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap

2014-10-13 Thread Sergio Pascual
Hi

2014-10-13 17:12 GMT+02:00 Kevin Fenzi :

> On Mon, 13 Oct 2014 16:49:38 +0200
> Sergio Pascual  wrote:
>
> > Hello, since a week or so I have been unable to connect to
> > https://admin.fedoraproject.org with firefox, I get an error like (I'm
> > translating from Spanish)
> > "Secure connection failed, no common cipher algorithms
> > (ssl_error_no_cypher_overlap)"
>
> What version of firefox is this?
>

This is firefox-32.0.2-1.fc20.x86_64

I have created a new empty firefox profile and it works, so it must
something in my profile configuration.


>
> We have been tweaking our ssl settings recently to match up with the
> recommended Mozilla ssl server settings:
> https://wiki.mozilla.org/Security/Server_Side_TLS
>
> > I haven't changed any security configuration in firefox, so I assume
> > this is a change in admin server or in firefox. I can connect with
> > epiphany to https://admin.fedoraproject.org
> >
> > https://koji.fedoraproject.org doesn't seem affected ( I can connect
> > with firefox)
>
> Can you file a ticket on this in the infrastructure trac and we can try
> and see whats happening in your case?
>
> https://fedorahosted.org/fedora-infrastructure/newticket
>

I can't login into this one either :(

Well, I will do it with epiphany

https://fedorahosted.org/fedora-infrastructure/ticket/4567

Thank you


>
> Thanks,
>
> kevin
>
> --
> 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

Re: Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap

2014-10-13 Thread Jaroslav Skarvada
Same problem with https://kojipkgs.fedoraproject.org/

I am pretty sure it worked on Friday, Fedora 20 with latest
updates, firefox-32.0.2-1.fc20.x86_64 with default configuration,
nothing changed on my side, opened ticket [1]

thanks & regards

Jaroslav

[1] https://fedorahosted.org/fedora-infrastructure/ticket/4565
-- 
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: Improving the offline updates user experience

2014-10-13 Thread Stephen Gallagher



On Thu, 2014-10-02 at 07:53 -0400, Stephen Gallagher wrote:
> 
> 
> On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote:
> > == The Problem ==
> > 
> > It is very common for users to have systems with encrypted root
> > partitions (or even just /var and /etc). This may be due to a personal
> > concern for their data or a corporate policy mandating full-disk
> > encryption. Disk encryption requires a password (or other more
> > complicated credentials) be be presented just after the kernel is
> > booted and before the drives can be mounted and their data read.
> > 
> > With the current implementation of the offline updates in Fedora, this
> > leads to a very unpleasant user experience when updating. We offer two
> > ways to perform offline updates in the default user environment of
> > Fedora Workstation: "Install updates and reboot" or "Install updates
> > and shut down".
> > 
> > With "Install updates and reboot", the behavior is as follows:
> > 
> > 1) The system shuts down and initiates an ACPI reboot.
> > 2) The system presents the kernel boot menu and then starts the
> > updater kernel.
> > 3) The system presents the user with a password prompt for the disk
> > encryption (possibly more than one, if the system is configured with
> > different passwords for different partitions).
> > 4) The offline updates occur.
> > 5) The system shuts down and initiates an ACPI reboot.
> > 6) The system presents the kernel boot menu and then starts the
> > standard (possibly updated) kernel.
> > 7) The system presents the user with a password prompt for the disk
> > encryption (possibly more than one, if the system is configured with
> > different passwords for different partitions).
> > 8) The system completes booting.
> > 
> > During this experience, the user has been required to enter their disk
> > encryption password *twice*. The same is true for the "Install and
> > shut down" case, except that the two passwords are separated by some
> > actual wallclock time.
> > 
> > == Proposed Improvements ==
> > 
> > We could significantly improve this situation by allowing the system
> > to drop directly from the interactive system into the updater
> > environment without doing a full reboot or relaunching the kernel.
> > 
> > Lennart, would it be possible to set up a special systemd target for
> > performing updates that would essentially stop all processes except
> > for systemd and then apply the updates?
> > 
> > In an ideal world, it would then also be possible after update is
> > completed to restore operation to the standard boot targets of systemd
> > so that the system comes back up without having to perform a total
> > reboot. The exceptional case would of course be that in which either
> > the kernel, libc or systemd[1] needed to be updated, in which case a
> > reboot could be performed.
> > 
> > In this scenario, we can reduce the number of encrypted disk
> > challenges to at most a single one, and that only if absolutely
> > minimal plumbing packages saw an update.
> > 
> > I'd very much like to hear from the plumbers on this matter.
> > 
> > 
> > [1] I'm told that this might not be necessary; that systemd can
> > re-exec itself to pick up its own updates. That would reduce the scope
> > presumably to "only the kernel" forcing reboots.
> 
> 
> I'm bumping this thread to get comments from Lennart (CCed). There's a
> lot of chatter in the conversation, but I'd very much like to hear an
> answer to the specific questions I posed in this first email.

Trying one more time to get Lennart to chime in here.


signature.asc
Description: This is a digitally signed message part
-- 
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: Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap

2014-10-13 Thread Kevin Fenzi
On Mon, 13 Oct 2014 16:49:38 +0200
Sergio Pascual  wrote:

> Hello, since a week or so I have been unable to connect to
> https://admin.fedoraproject.org with firefox, I get an error like (I'm
> translating from Spanish)
> "Secure connection failed, no common cipher algorithms
> (ssl_error_no_cypher_overlap)"

What version of firefox is this? 

We have been tweaking our ssl settings recently to match up with the
recommended Mozilla ssl server settings: 
https://wiki.mozilla.org/Security/Server_Side_TLS

> I haven't changed any security configuration in firefox, so I assume
> this is a change in admin server or in firefox. I can connect with
> epiphany to https://admin.fedoraproject.org
> 
> https://koji.fedoraproject.org doesn't seem affected ( I can connect
> with firefox)

Can you file a ticket on this in the infrastructure trac and we can try
and see whats happening in your case?

https://fedorahosted.org/fedora-infrastructure/newticket

Thanks, 

kevin


signature.asc
Description: PGP 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: js/src/configure issue on Firefox

2014-10-13 Thread Antonio Trande
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/13/2014 03:42 PM, Martin Stransky wrote:
> I don't recall such bug. But you can touch both configure & 
> configure.in. It may be the timestamp issue. You may also look in
> the sources for the "has changed and needs to be run again"
> string...not sure it's a bug in firefox build system or actools.
> But I guess it's some check in firefox sources so you may find
> what's actually checked and fix that. Anyway, the timestamp should
> be correct for all files in the archive unless there's a bug in the
> source tarball. btw. have you tried to build it just from source
> tarball? Not as the rpm package? that may also help to diagnose
> it.
> 
> ma.
> 

Hi.

Configuration's tasks from source tarball work fine.
I had to change the mozconfig files management in my SPEC to build
correctly: no more by executing 'make -f client-mk' but directly by
calling 'configure'.

It wasn't a timestamp issue as I thought.

Thanks.

- -- 
Antonio Trande

mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x66E15D00
Check on https://keys.fedoraproject.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUO+rUAAoJEFyovWBm4V0A7oMP/3EGPjsyEYepiZvPSwK+0OKc
pNS4UXbjOoKgQg2xPmQ8XRHJJTiKW+LxFExjTobKC3si5Nl9MLP6QIosAnIkKq1D
njYpaRvAuADgqR3tI/JjJo2kyVR1VI0xKINMHZskhJyI5OqmVZlONdzlU0YZS4Y8
KMdFt7sr5PAD6XHTjqE5PtJxwTMYPxRUqLZpx2bRAmE3HPhzlBT0jCh+8T/l/fF3
EvhfbwJXys6vPelkxEfI/ZGlBBlAU7r1U/wBAbZ4zUMkNl1+x1Lv1dO+UlM3rqpX
RVbxn2JbLWmNUGW7JDQpAF8N0id9HrGPdLQG8D94BLmdb37KFZvBVgo9sUz2ZUen
OPwaEMNRGBJDCM7AnrH8Q6fmyGrKsfL6frhWkblaaJZgGAV64HMcMsn/QmEhsbGF
n8Edgut0JIBwgRYiW1+mSN9wV+lBNDtKZhX/IqXJQCZ8zKhBkqA53FzVK51GE1YJ
KbvcSwP8F+YvNHj1TuayFaM/dCPySyveUt/dHIha1x2wOrkZU8OuXQTqn1qEFE4q
qPuYpt+eMa3yiIeDDCrwmJp3/4Gj8ZArOD5YF6bgiMeYLhJvTaKnBmsn8O/0ApWa
ZTiczzs7T2ZnD8z9Bbjky3F2kMWvg1I9mRcVl2iZzszYhaVZbYAkOuhgCRy9KgWk
6BKSz6/1nHYb0qBvdZug
=TTCk
-END PGP 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: Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap

2014-10-13 Thread Reindl Harald


Am 13.10.2014 um 16:49 schrieb Sergio Pascual:

Hello, since a week or so I have been unable to connect to
https://admin.fedoraproject.org with firefox, I get an error like (I'm
translating from Spanish)
"Secure connection failed, no common cipher algorithms
(ssl_error_no_cypher_overlap)"

I haven't changed any security configuration in firefox, so I assume
this is a change in admin server or in firefox. I can connect with
epiphany to https://admin.fedoraproject.org

https://koji.fedoraproject.org doesn't seem affected ( I can connect
with firefox)


which version of firefox?
works fine here

TLS_DHE_RSA_WITH_AES_128_CBC_SHA
4096 Bit SHA256 certificate

http://stackoverflow.com/questions/547219/firefox-ssl-error-no-cypher-overlap-error





signature.asc
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: Engineering Representiatve for the new Fedora Council

2014-10-13 Thread Haïkel
I'll be speaking in my own name:

The Eng. Rep. is not necessarily a Fesco member but should be someone
willing to collaborate regularly with them.
She should have a fairly broad overview of Fedora Engineering and be
an active contributor.

The ideal candidate should be someone who has experience in the
technical committees, and able to communicate effectively with various
groups.
You don't need to be a "super contributor", but this is no role for a
rookie as the time commitment will be important.
About the selection, since it will take a lot of your time, I think
that interested people should nominate themselves.
Then, either fesco choose to hold an election or not is up to them.

Though I have few names in mind, I won't disclose them before speaking
with them.
Some are obvious, the others may surprise you ;)

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

Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap

2014-10-13 Thread Sergio Pascual
Hello, since a week or so I have been unable to connect to
https://admin.fedoraproject.org with firefox, I get an error like (I'm
translating from Spanish)
"Secure connection failed, no common cipher algorithms
(ssl_error_no_cypher_overlap)"

I haven't changed any security configuration in firefox, so I assume this
is a change in admin server or in firefox. I can connect with epiphany to
https://admin.fedoraproject.org

https://koji.fedoraproject.org doesn't seem affected ( I can connect with
firefox)

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

[POC-change] Fedora packages point of contact updates

2014-10-13 Thread nobody
Change in package status over the last 168 hours


2 packages were orphaned

pyicq-t [el5] was orphaned by stefansf
 ICQ Transport for Jabber Servers
 https://admin.fedoraproject.org/pkgdb/package/pyicq-t
rubygem-cucumber [el6, el5] was orphaned by lkundrak
 Tool to execute plain-text documents as functional tests
 https://admin.fedoraproject.org/pkgdb/package/rubygem-cucumber

10 packages were retired
-
eclipse-photran [el5] was retired by orion
 Fortran Development Tools (Photran) for Eclipse
 https://admin.fedoraproject.org/pkgdb/package/eclipse-photran
hotot [f21, master] was retired by sundaram
 Lightweight & open source micro blogging client
 https://admin.fedoraproject.org/pkgdb/package/hotot
libvmime07 [master] was retired by robert
 A powerful C++ class library for working with MIME/Internet messages
 https://admin.fedoraproject.org/pkgdb/package/libvmime07
ocaml-pa-do [master] was retired by rjones
 OCaml syntax extension for delimited overloading
 https://admin.fedoraproject.org/pkgdb/package/ocaml-pa-do
owncloud-csync [f21, master] was retired by jmarrero
 A user level bidirectional client only file synchronizer
 https://admin.fedoraproject.org/pkgdb/package/owncloud-csync
paraview [el5] was retired by orion
 Parallel visualization application
 https://admin.fedoraproject.org/pkgdb/package/paraview
php53-tcpdf [master] was retired by robert
 PHP class for generating PDF documents and barcodes
 https://admin.fedoraproject.org/pkgdb/package/php53-tcpdf
phpMyAdmin3 [el5] was retired by robert
 Handle the administration of MySQL over the World Wide Web
 https://admin.fedoraproject.org/pkgdb/package/phpMyAdmin3
phpMyAdmin4 [master] was retired by robert
 Handle the administration of MySQL over the World Wide Web
 https://admin.fedoraproject.org/pkgdb/package/phpMyAdmin4
rosa-launcher [master] was retired by jmarrero
 ROSA Desktop Application Launcher
 https://admin.fedoraproject.org/pkgdb/package/rosa-launcher

51 packages unorphaned
--
auto-buildrequires [el6, el5] was unorphaned by rjones
 Work out BuildRequires for rpmbuild automatically
 https://admin.fedoraproject.org/pkgdb/package/auto-buildrequires
cfengine [el6, el5] was unorphaned by dmlb2000
 A systems administration tool for networks
 https://admin.fedoraproject.org/pkgdb/package/cfengine
clucene [f21, f19, master, f20, el5] was unorphaned by rdieter
 A C++ port of Lucene
 https://admin.fedoraproject.org/pkgdb/package/clucene
htmldoc [el6, el5] was unorphaned by rdieter
 Converter from HTML into indexed HTML, PostScript, or PDF
 https://admin.fedoraproject.org/pkgdb/package/htmldoc
icon-naming-utils [f21, f19, master, f20] was unorphaned by leigh123linux
 A script to handle icon names in desktop icon themes
 https://admin.fedoraproject.org/pkgdb/package/icon-naming-utils
kde-plasma-publictransport [f21, f19, master, f20] was unorphaned by jgrulich
 Public Transport plasma applet
 https://admin.fedoraproject.org/pkgdb/package/kde-plasma-publictransport
kdesrc-build [f21, f19, master, f20] was unorphaned by jgrulich
 A tool to allow you to easily build KDE from its source repositories
 https://admin.fedoraproject.org/pkgdb/package/kdesrc-build
libdnet [el5] was unorphaned by robert
 Simple portable interface to lowlevel networking routines
 https://admin.fedoraproject.org/pkgdb/package/libdnet
libxml++ [el6] was unorphaned by notting
 C++ wrapper for the libxml2 XML parser library
 https://admin.fedoraproject.org/pkgdb/package/libxml++
mpich [f21, f20, master] was unorphaned by zbyszek
 A high-performance implementation of MPI
 https://admin.fedoraproject.org/pkgdb/package/mpich
nebula [f21, f19, master, f20] was unorphaned by fab
 Intrusion signature generator
 https://admin.fedoraproject.org/pkgdb/package/nebula
ocaml-lablgl [el6, epel7, el5] was unorphaned by rjones
 LablGL is an OpenGL interface for Objective Caml
 https://admin.fedoraproject.org/pkgdb/package/ocaml-lablgl
perl-Algorithm-CurveFit [el5] was unorphaned by jplesnik
 Nonlinear Least Squares Curve Fitting
 https://admin.fedoraproject.org/pkgdb/package/perl-Algorithm-CurveFit
perl-Class-Can [el6, el5] was unorphaned by jplesnik
 Inspect a class/method and say what it can do (and why)
 https://admin.fedoraproject.org/pkgdb/package/perl-Class-Can
perl-Class-Exporter [el6, el5] was unorphaned by jplesnik
 Export class methods as regular subroutines
 https://admin.fedoraproject.org/pkgdb/package/perl-Class-Exporter
perl-Dancer [el6] was unorphaned by jplesnik
 Lightweight yet powerful web application framework
 https://admin.fedoraproject.org/pkgdb/package/perl-Dancer
perl-Feed-Find [el5] was unorphaned by jplesnik
 Syndication feed auto-disc

Multiple problems with multiple monitors

2014-10-13 Thread Basil Mohamed Gohar
 

I've searched for bugs related to the specific problems I've been
having, and I've not been able to find anything that describes what I'm
seeing. 

I have an HP EliteBook 840 that also comes with an UltraDock, to which
I've plugged-in two external monitors and I use in conjunction with the
built-in laptop display. 

Issue #1: I use LUKS to encrypt my disk, and when I first start up the
computer, after choosing the kernel to boot into in GRUB, the GUI prompt
for the LUKS passphrase shows-up on the middle monitor, not the laptop's
built-in display. I don't mind this when I have multiple monitors
plugged-in, but when I boot-up without the external monitors, such as
when I'm unplugged from the UltraDock, I now get NO GUI prompt for the
LUKS passphrase. I can enter it, and I can see a text prompt if I hit
ESC. I suspect its attempting to display on the now phantom, unplugged
monitor. Note, it was never plugged-in during this cycle. The problem
is, I don't even know what's instructing LUKS or the GUI prompt to
display on any monitor, so I don't know where to go to debug this. 

Issue #2: When I undock my laptop while logged-in, Gnome Shell just
crashes. When I redock after the laptop has been started when
unconnected, one of the two external monitors start-up (the one
connected by VGA), but not the one connected by a DisplayPort
connection. And, recently (but not when I first started using this
laptop with the dock, which was about a month ago), now when I start-up
with the laptop docked and both external monitors connected, both
external monitors will be active, but the built-in display will show
nothing. Gnome Shell reports the built-in display is active, but will
not display anything unless I deactivate it and reactivate it via the
settings "Displays" utility. 

Issue #3: The monitor connected via DisplayPort display significant
tearing and delay on the upper-right half of the screen in the form of a
triangle taking-up half of the screen. Reading about displayport and
tearing issues, I guess the idea that these were resolved in the past. I
don't know if this is the same or something different. 

I don't mean to use devel as a bug reporting venue, but I think these
issues are either related or I just don't know how to address them to
make significant progress to fixing them. Any guidance is more than
welcome. Thanks! 

-- 
Libre Video
http://librevideo.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

Re: Future changes in the new package and new branch processes

2014-10-13 Thread Pierre-Yves Chibon
On Mon, Sep 08, 2014 at 11:55:06AM +0200, Pierre-Yves Chibon wrote:
> On Mon, Sep 08, 2014 at 11:31:58AM +0200, Tomas Tomecek wrote:
> > Quoting Pierre-Yves Chibon (2014-09-05 17:08:39)
> > > New procedure
> > > =
> > > 
> > > * packager opens a review-request on bugzilla
> > > * reviewer sets the fedora-review flag to ?
> > > * reviewer does the review
> > > * reviewer sets the fedora-review flag to +
> > > * packager goes to pkgdb2 to request new package and specifies:
> > >- package name
> > >- package summary
> > 
> > How about taking this from specfile? (and therefore provide a tool for
> > maintaining specfiles & srpms for reviews)
> 
> That would imply parsing the bugzilla ticket to find the spec file and then
> parse it again which itself implies knowing the bugzilla ticket number.
> 
> I think it's just as easy to ask the user to do it.
> 
> Note that we have an API endpoint to edit a package's information:
> https://admin.fedoraproject.org/pkgdb/api/#edit_a_package
> and a script to do it in pkgdb2:
> https://git.fedorahosted.org/cgit/pkgdb2.git/tree/utility/update_package_info.py

In case you did not notice, know that the cron has been deployed and is now
running for two weeks on a weekly basis.

So pkgdb's information about packages is now up to date with the information
contained in yum's meta-data fom the rawhide repo (yes that does mean that
packages retired from repo or present only in epel aren't up to date atm).

By curiousity:
The first time we ran the script:
  16638 packages checked
  15723 packages updated

Last week's run:
  16690 packages checked
  50 packages updated


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

Orphaning plotutils

2014-10-13 Thread Mikolaj Izdebski
I took plotutils by mistake a few months ago as part of large package
reassignment.  I am orphaning it now as I never intended to maintain the
package.  Feel free to adopt it if you wish.

-- 
Mikolaj Izdebski
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

rawhide report: 20141013 changes

2014-10-13 Thread Fedora Rawhide Report
Compose started at Mon Oct 13 05:15:07 UTC 2014
Broken deps for i386
--
[3Depict]
3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0
[Agda]
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[PyQuante]
PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 
0:1.1.6-2.fc21
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[audtty]
audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.i686 requires libjson.so.0
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[collectd]
collectd-onewire-5.4.1-9.fc22.i686 requires libowcapi-2.9.so.5
[darcs]
darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[debconf]
debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2)
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[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
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc22.i686 requires libedelib.so
edelib-devel-2.1-5.fc22.i686 requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires 
hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7
[flush]
flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires 
libvala-0.24.so.0
[ghc-hjsmin]
ghc-hjsmin-0.1.4.7-3.fc22.i686 requires 
libHSoptparse-applicative-0.9.0-ghc7.6.3.so
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.i686 requires 
libmetacity-private.so.0
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[golang-github-influxdb-influxdb]

golang-github-influxdb-influxdb-datastore-0.8.0-0.3.rc4.git67f9869.fc22.noarch 
requires golang(github.com/influxdb/gomdb)
[gorm]
gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23
[hledger]
ghc-hledger-0.19.3-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-hledger-0.19.3-5.fc22.i686 requires 
libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-hledger-0.19.3-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-hledger-devel-0.19.3-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
hledger-0.19.3-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
hledger-0.19.3-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[idris]
idris-0.9.9.1-3.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
idris-0.9.9.1-3.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
idris-0.9.9.1-3.fc22.i686 requires 
g

F-21 Branched report: 20141013 changes

2014-10-13 Thread Fedora Branched Report
Compose started at Mon Oct 13 07:15:02 UTC 2014
Broken deps for armhfp
--
[PyQuante]
PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
[avro]
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client
[cduce]
cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[cp2k]
cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so
[engrid]
engrid-1.4.0-4.gite6d55f5.fc21.armv7hl requires libnglib.so.5
[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.21.beta2.fc21.armv7hl requires 
libtorrent-rasterbar.so.7
[flush]
flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires 
libascend.so.1
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
libvala-0.24.so.0
[gmsh]
gmsh-2.8.5-3.fc21.armv7hl requires libnglib.so.5
gmsh-libs-2.8.5-3.fc21.armv7hl requires libnglib.so.5
gmsh-mpich-2.8.5-3.fc21.armv7hl requires libnglib.so.5
gmsh-mpich-libs-2.8.5-3.fc21.armv7hl requires libnglib.so.5
gmsh-openmpi-2.8.5-3.fc21.armv7hl requires libnglib.so.5
gmsh-openmpi-libs-2.8.5-3.fc21.armv7hl requires libnglib.so.5
[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
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[libghemical]
libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3
libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3
[libmygpo-qt]
libmygpo-qt5-devel-1.0.8-1.fc21.armv7hl requires libmygpo-qt5{?_isa} = 
0:1.0.8-1.fc21
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1
[ltsp]
ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog
[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-vala]
monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[ocaml-pa-do]
ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[openslides]
openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5
[openstack-nova]
openstack-nova-compute-2014.1.2-1.fc21.noarch requires 
libvirt-daemon-xen
[openvas-client]
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6
[perl-RT-Authen-ExternalAuth]
perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3
[perl-RT-Extension-CommandByMail]
perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires 
perl(RT::Interface::Email)
[pipelight-selinux]
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight
[pootle]
pootle-2.1.6-8.fc21.noarch requires python-django14
[python-askbot-fedmsg]
python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot
[python-coffin]
python-c