Rapid release for security updates

[Martin Stransky]

Hi guys,

is there any mechanism how to speed up release of critical security 
fixes by Fedora update system?


For instance Firefox packages are released *week* after official Mozilla 
release which is really bad.


Any idea here?

ma.
--
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: simplestreams json or index.asc for deliverables in the new list-of-deliverables?

[Fabian Deutsch]

- Original Message -
> FESCo Ticket #1427 
> formalizes the list of deliverables for each Fedora release. Cool.
> 
> Let's go a step beyond this and make a machine-readable list, at least
> of image-based deliverables. One approach would be to use using Ubuntu's
> simplestreams
> format, documented at
> 

Some pros/cons on this:
+ It has the concept of a stream (vendor, product, version)
+ It supports different hash types
+ It can be signed
+ Timestamp within the file
+ Can represent multiple versions of the same stream

- ftype is not very helpful (no precise format descirption)
- size is very unspecific (compressed/uncompressed?) (gb vs mb vs mib)
- The file slook quite complex

> A second option would be the index.asc as used by virt-builder:
> 

Some pros/cons I see here:
+ I tincludes both, compressed + uncompressed, disk sizes
+ Tells the format of the image
+ I personally like the structure much more

+/- It includes some non-image stuff (i.e. expand=)

- The type of the checksum is not specified in the conf file
- I'm missing a stream like scheme; a gloabl identifier to be able to sort 
images according to a version/build-date

> That way, we'd have a standardized way for applications to find and
> download/launch/whatever various Fedora images. This is a definite need
> (see https://fedorahosted.org/cloud/ticket/93) and rather than
> inventing a new wheel, maybe we could see if we could pound one of
> these into shape.

After all IMO simplestreams gives us what we need.

- fabian
-- 
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: Rapid release for security updates

[Reindl Harald]

Am 19.05.2015 um 10:38 schrieb Martin Stransky:

Hi guys,

is there any mechanism how to speed up release of critical security
fixes by Fedora update system?

For instance Firefox packages are released *week* after official Mozilla
release which is really bad.

Any idea here?


and that is *really* a Fedora problem because for CentOS you get 
critical security updates instantly while the same packages are waiting 
for days in Fedora




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: F23 System Wide Change: Mono 4

[Timotheus Pokorra]

Hello Neal,

> So we won't have mono stuff working for F22 then?

I have installed a fresh Fedora 21, and then upgraded to F22 according
to 
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_21_-.3E_Fedora_22_.28not_yet_released.29

I then did dnf install mono-core.

rpm -qa | grep mono
shows:
mono-core-2.10.8-7.fc21.x86_64

So it seems the fc21 packages have been reused for F22.

I have looked into why mono-2.10.8-8.fc22.src.rpm fails to build on koji.
It seems the code is that old, that I cannot apply the patch mentioned in [1].
I filed a bug for this for better documentation: [2]
I have adjusted the patch, and committed it. [3]

Unfortunately I now get a segfault later on in the build of the package.
I have no idea yet where to start fixing that.

Timotheus


[1]: https://lists.fedoraproject.org/pipermail/devel/2015-May/210378.html
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1222814
[3]: 
http://pkgs.fedoraproject.org/cgit/mono.git/commit/?h=f22&id=150cb705fc06bc465307a4929c65ef3d3ac7211a
-- 
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: Rapid release for security updates

[drago01]

On Tue, May 19, 2015 at 10:38 AM, Martin Stransky  wrote:
> Hi guys,
>
> is there any mechanism how to speed up release of critical security fixes by
> Fedora update system?
>
> For instance Firefox packages are released *week* after official Mozilla
> release which is really bad.
>
> Any idea here?

Why does it take so long? Most firefox uipdates get enough karma
before they end up in testing.
In that case they should be picked up by the next push (which is still
a manual process afaik; so no idea how often it happens).
-- 
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 System Wide Change: Mono 4

[Peter Robinson]

On Mon, May 18, 2015 at 4:52 AM, Moez Roy  wrote:
> Mono is updated in Rawhide. Can a proven-packager run a script to
> rebuild all the packages that require mono.

Most of these are now built, sadly because all the bits needed weren't
actually committed it wasn't as simple as running a script.

They will be in today's rawhide compose.

I did a bunch of cleanup as I went and we tagged in 57 builds, see the
ticket [1] for the details. There are a number of failures where
packages need to be updated but over all they're leaf packages so only
really affect themselves. There were 57 packages tagged in, there's
around 70 packages that depend on mono in total, IMO this is too
invasive for F-22, there would be a lot of work to get that landed
cleanly.

Where ARMv7 was previously included it now builds in all cases, the
hardfp was known to have issues in 2.x which was fixed in the 3.x
cycle so moving forward the only current unsupported Fedora
architecture is aarch64.

If anyone sees any issues with the buildroot in general due to this let me know.

In terms of some other points please don't add repetitive rpm macros
to all the mono files, please create an appropriate rpm macro package.
Please reach out to me if you don't know what that means.

Please also go through all the relevant package BZ and update tickets,
review bugs etc.

[1] https://fedorahosted.org/rel-eng/ticket/6180
-- 
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 22 Final Go/No-Go Meeting, Thursday, May 21 @ 17:00 UTC

[Jaroslav Reznik]

Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 22.

Thursday, May 21, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST)

"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of
the QA Team."

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Final Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/final/buglist

We don't have RC yet but seem like we're very close to it - testing
heroes will be needed to cover all required tests by this meeting.

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

rawhide report: 20150519 changes

[Fedora Rawhide Report]

Compose started at Tue May 19 05:15:03 UTC 2015
Broken deps for i386
--
[InsightToolkit]
InsightToolkit-4.7.1-4.fc23.i686 requires libhdf5_cpp.so.9
InsightToolkit-4.7.1-4.fc23.i686 requires libhdf5.so.9
[OpenTK]
OpenTK-1.1-1.4c.fc22.noarch requires mono(mscorlib) = 0:2.0.0.0
OpenTK-1.1-1.4c.fc22.noarch requires mono(System.Xml) = 0:2.0.0.0
OpenTK-1.1-1.4c.fc22.noarch requires mono(System.Windows.Forms) = 
0:2.0.0.0
OpenTK-1.1-1.4c.fc22.noarch requires mono(System.Drawing) = 0:2.0.0.0
OpenTK-1.1-1.4c.fc22.noarch requires mono(System) = 0:2.0.0.0
[RepetierHost]
RepetierHost-0.90D-2.fc21.noarch requires mono(mscorlib) = 0:2.0.0.0
RepetierHost-0.90D-2.fc21.noarch requires mono(System.Xml) = 0:2.0.0.0
RepetierHost-0.90D-2.fc21.noarch requires mono(System.Windows.Forms) = 
0:2.0.0.0
RepetierHost-0.90D-2.fc21.noarch requires mono(System.Drawing) = 
0:2.0.0.0
RepetierHost-0.90D-2.fc21.noarch requires mono(System.Core) = 0:3.5.0.0
RepetierHost-0.90D-2.fc21.noarch requires mono(System) = 0:2.0.0.0
[banshee]
banshee-2.6.2-9.fc23.i686 requires mono(mscorlib) = 0:2.0.0.0
banshee-2.6.2-9.fc23.i686 requires mono(System.Xml) = 0:2.0.0.0
banshee-2.6.2-9.fc23.i686 requires mono(System.Core) = 0:3.5.0.0
banshee-2.6.2-9.fc23.i686 requires mono(System) = 0:2.0.0.0
banshee-2.6.2-9.fc23.i686 requires mono(Mono.Posix) = 0:2.0.0.0
banshee-2.6.2-9.fc23.i686 requires mono(Mono.Cairo) = 0:2.0.0.0
banshee-2.6.2-9.fc23.i686 requires mono(ICSharpCode.SharpZipLib) = 
0:2.84.0.0
[bless]
bless-0.6.0-14.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0
bless-0.6.0-14.fc22.i686 requires mono(System.Xml) = 0:2.0.0.0
bless-0.6.0-14.fc22.i686 requires mono(System) = 0:2.0.0.0
bless-0.6.0-14.fc22.i686 requires mono(Mono.Posix) = 0:2.0.0.0
[boo]
boo-0.9.4.9-11.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(System.Xml) = 0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(System.Core) = 0:3.5.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(System) = 0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Utilities) = 
0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Tasks) = 
0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Framework) = 
0:2.0.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(System.Xml) = 0:2.0.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(System.Core) = 0:3.5.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(System) = 0:2.0.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(NAnt.DotNetTasks) = 
0:0.90.3780.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(NAnt.Core) = 0:0.90.3780.0
[dmapd]
dmapd-0.0.72-1.fc23.i686 requires libvips.so.40
[dmlite-plugins-memcache]
dmlite-plugins-memcache-0.5.0-7.fc20.i686 requires libprotobuf.so.8
[dmlite-plugins-s3]
dmlite-plugins-s3-0.5.1-5.fc22.i686 requires libprotobuf.so.8
[gazebo]
gazebo-4.0.2-2.fc22.i686 requires libprotobuf.so.8
gazebo-libs-4.0.2-2.fc22.i686 requires libprotobuf.so.8
player-gazebo-4.0.2-2.fc22.i686 requires libprotobuf.so.8
[gnome-do]
gnome-do-0.95.1-3.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0
gnome-do-0.95.1-3.fc22.i686 requires mono(System) = 0:2.0.0.0
[julia]
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
[keepass]
keepass-2.26-9.fc21.i686 requires mono(mscorlib) = 0:2.0.0.0
keepass-2.26-9.fc21.i686 requires mono(System.Xml) = 0:2.0.0.0
keepass-2.26-9.fc21.i686 requires mono(System.Windows.Forms) = 0:2.0.0.0
keepass-2.26-9.fc21.i686 requires mono(System.Security) = 0:2.0.0.0
keepass-2.26-9.fc21.i686 requires mono(System.Drawing) = 0:2.0.0.0
keepass-2.26-9.fc21.i686 requires mono(System) = 0:2.0.0.0
[libyui-bindings]
mono-yui-1.1.0-7.fc23.i686 requires mono(mscorlib) = 0:2.0.0.0
[mesos]
mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.i686 requires libprotobuf.so.8
python-mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.i686 requires 
libprotobuf.so.8
[mojarra]
mojarra-2.1.7-8.fc20.noarch requires tomcat-servlet-3.0-api
mojarra-2.1.7-8.fc20.noarch requires tomcat-jsp-2.2-api
mojarra-2.1.7-8.fc20.noarch requires tomcat-el-2.2-api
[mono-basic]
mono-basic-2.10-7.fc20.i686 requires mono(mscorlib) = 0:2.0.0.0
mono-basic-2.10-7.fc20.i686 requires mono(System.Windows.Forms) = 
0:2.0.0.0
mono-basic-2.10-7.fc20.i686 requires mono(System.Drawing) = 0:2.0.0.0
mono-basic-2.10-7.fc20.i686 requires mono(System) = 0:2.0.0.0
[mono-bouncycastle]
mono-bouncycastle-1

Re: simplestreams json or index.asc for deliverables in the new list-of-deliverables?

[Lennart Poettering]

On Mon, 18.05.15 19:44, Matthew Miller (mat...@fedoraproject.org) wrote:

> FESCo Ticket #1427 
> formalizes the list of deliverables for each Fedora release. Cool.
> 
> Let's go a step beyond this and make a machine-readable list, at least
> of image-based deliverables. One approach would be to use using Ubuntu's 
> simplestreams
> format, documented at
> 
> 
> A second option would be the index.asc as used by virt-builder:
> 
> 
> That way, we'd have a standardized way for applications to find and
> download/launch/whatever various Fedora images. This is a definite need
> (see https://fedorahosted.org/cloud/ticket/93) and rather than
> inventing a new wheel, maybe we could see if we could pound one of
> these into shape.

There's also the ACI discovery stuff:

https://github.com/appc/spec/blob/master/SPEC.md#app-container-image-discovery

Doesn't really apply to non-ACI images right now, but the concepts in
it are a bit nicer I think then the alternatives (i.e. the fact that
it renders the image names into URL via a fixed template, and that it
uses  tags for exposing this information is pretty nice).

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: simplestreams json or index.asc for deliverables in the new list-of-deliverables?

[Fabian Deutsch]

- Original Message -
> On Mon, 18.05.15 19:44, Matthew Miller (mat...@fedoraproject.org) wrote:
> 
> > FESCo Ticket #1427 
> > formalizes the list of deliverables for each Fedora release. Cool.
> > 
> > Let's go a step beyond this and make a machine-readable list, at least
> > of image-based deliverables. One approach would be to use using Ubuntu's
> > simplestreams
> > format, documented at
> > 
> > 
> > A second option would be the index.asc as used by virt-builder:
> > 
> > 
> > That way, we'd have a standardized way for applications to find and
> > download/launch/whatever various Fedora images. This is a definite need
> > (see https://fedorahosted.org/cloud/ticket/93) and rather than
> > inventing a new wheel, maybe we could see if we could pound one of
> > these into shape.
> 
> There's also the ACI discovery stuff:
> 
> https://github.com/appc/spec/blob/master/SPEC.md#app-container-image-discovery

If you are just referring to this part of the spec …

> Doesn't really apply to non-ACI images right now, but the concepts in
> it are a bit nicer I think then the alternatives (i.e. the fact that
> it renders the image names into URL via a fixed template, and that it
> uses  tags for exposing this information is pretty nice).

… then I agree. The URL scheme based identifier is nice.

But it is lacking stuff like a description and the size of the image.
And the method to retrieve metadata informations is somewhat cumbersome.

My 2ct.

- fabian
-- 
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: Rapid release for security updates

[Michael Cronenworth]

On 05/19/2015 04:12 AM, drago01 wrote:

Why does it take so long? Most firefox uipdates get enough karma
before they end up in testing.
In that case they should be picked up by the next push (which is still
a manual process afaik; so no idea how often it happens).


Firefox 38.0 entered and exited bodhi in about 29 hours. That's pretty good.

Firefox 38.0.1, marked as "bugfix" and not "security", has only been in bodhi for 24 
hours.


@OP, If you need more eyes on updates you're free to post to this list or the 
test list.
--
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: Rapid release for security updates

[Martin Stransky]

On 05/19/2015 03:17 PM, Michael Cronenworth wrote:

On 05/19/2015 04:12 AM, drago01 wrote:

Why does it take so long? Most firefox uipdates get enough karma
before they end up in testing.
In that case they should be picked up by the next push (which is still
a manual process afaik; so no idea how often it happens).


Firefox 38.0 entered and exited bodhi in about 29 hours. That's pretty
good.


Firefox 38.0, Fedora 20, security update. Submitted 2015-05-13, not yet 
stable (only submitted for stable now, have not hit the repository).



Firefox 38.0.1, marked as "bugfix" and not "security", has only been in
bodhi for 24 hours.


That's F20/F21 case, not Fedora 20.


@OP, If you need more eyes on updates you're free to post to this list
or the test list.


Thanks, but is there anything better? The F20 updates are usually ignored...

ma.
--
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: Rapid release for security updates

[Martin Stransky]

On 05/19/2015 11:12 AM, drago01 wrote:

On Tue, May 19, 2015 at 10:38 AM, Martin Stransky  wrote:

Hi guys,

is there any mechanism how to speed up release of critical security fixes by
Fedora update system?

For instance Firefox packages are released *week* after official Mozilla
release which is really bad.

Any idea here?


Why does it take so long? Most firefox uipdates get enough karma
before they end up in testing.


I gess there's 2 day delay (one for testing push and one for stable 
push). It also take time to get karma for Fedora 20...



In that case they should be picked up by the next push (which is still
a manual process afaik; so no idea how often it happens).



--
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: Rapid release for security updates

[Josh Boyer]

On Tue, May 19, 2015 at 9:24 AM, Martin Stransky  wrote:
> On 05/19/2015 03:17 PM, Michael Cronenworth wrote:
>>
>> On 05/19/2015 04:12 AM, drago01 wrote:
>>>
>>> Why does it take so long? Most firefox uipdates get enough karma
>>> before they end up in testing.
>>> In that case they should be picked up by the next push (which is still
>>> a manual process afaik; so no idea how often it happens).
>>
>>
>> Firefox 38.0 entered and exited bodhi in about 29 hours. That's pretty
>> good.
>
>
> Firefox 38.0, Fedora 20, security update. Submitted 2015-05-13, not yet
> stable (only submitted for stable now, have not hit the repository).
>
>> Firefox 38.0.1, marked as "bugfix" and not "security", has only been in
>> bodhi for 24 hours.
>
>
> That's F20/F21 case, not Fedora 20.
>
>> @OP, If you need more eyes on updates you're free to post to this list
>> or the test list.
>
>
> Thanks, but is there anything better? The F20 updates are usually ignored...

They aren't ignored by rel-eng.  They're ignored by users/testers.  We
see the same issue with kernel updates for whatever the oldest stable
release is, particularly as we get towards EOL for that release.  As
people migrate to the newer releases, the older ones are simply less
used.

The only thing you can do is ask for testing/karma help here and on
the test list.  If it's really super urgent critical, you can probably
discuss with rel-eng to get it pushed without karma, but that is
always risky too.

josh
-- 
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: simplestreams json or index.asc for deliverables in the new list-of-deliverables?

[Vincent Batts]

On 19/05/15 09:05 -0400, Fabian Deutsch wrote:

- Original Message -

On Mon, 18.05.15 19:44, Matthew Miller (mat...@fedoraproject.org) wrote:

> FESCo Ticket #1427 
> formalizes the list of deliverables for each Fedora release. Cool.
>
> Let's go a step beyond this and make a machine-readable list, at least
> of image-based deliverables. One approach would be to use using Ubuntu's
> simplestreams
> format, documented at
> 

>
> A second option would be the index.asc as used by virt-builder:
> 
>
> That way, we'd have a standardized way for applications to find and
> download/launch/whatever various Fedora images. This is a definite need
> (see https://fedorahosted.org/cloud/ticket/93) and rather than
> inventing a new wheel, maybe we could see if we could pound one of
> these into shape.

There's also the ACI discovery stuff:

https://github.com/appc/spec/blob/master/SPEC.md#app-container-image-discovery


If you are just referring to this part of the spec …


Doesn't really apply to non-ACI images right now, but the concepts in
it are a bit nicer I think then the alternatives (i.e. the fact that
it renders the image names into URL via a fixed template, and that it
uses  tags for exposing this information is pretty nice).


… then I agree. The URL scheme based identifier is nice.

But it is lacking stuff like a description and the size of the image.
And the method to retrieve metadata informations is somewhat cumbersome.


Description, maybe. But since it's just an HTML meta tag, then the page
itself could be self serving of that information. 


Size, it's just a flat file. An HTTP HEAD, an Content-Length header is
typically sufficient.

As for the retrieval, I can't say it's entirely cumbersome. Parsing HTML
is pretty straight forward. Serving this kind of information will
eventually be usable as well, as Docker is looking to accommodate
similar.
https://github.com/docker/distribution/pull/303/files#diff-4846d2808cb787c146c1c82ab2a69fdbR135
Though in that case, the serving a flat ACI files is cleaner and nicer.


My 2ct.

- fabian


pgp0L8RqqaWqU.pgp
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

F-22 Branched report: 20150519 changes

[Fedora Branched Report]

Compose started at Tue May 19 07:15:03 UTC 2015
Broken deps for armhfp
--
[xorg-x11-drivers]
xorg-x11-drivers-7.7-13.fc22.armv7hl requires xorg-x11-drv-void



Broken deps for i386
--
[xorg-x11-drivers]
xorg-x11-drivers-7.7-13.fc22.i686 requires xorg-x11-drv-void



Broken deps for x86_64
--
[xorg-x11-drivers]
xorg-x11-drivers-7.7-13.fc22.x86_64 requires xorg-x11-drv-void




Updated Packages:

PackageKit-1.0.6-3.fc22
---
* Fri May 15 2015 Kalev Lember  - 1.0.6-3
- Revert a commit that inadvertantly changed the default value for the
  TriggerAction DBus property


Size change: 1133 bytes

adwaita-icon-theme-3.16.2.1-1.fc22
--
* Tue May 12 2015 Kalev Lember  - 3.16.2.1-1
- Update to 3.16.2.1
- Use license macro for COPYING files


Size change: 313005 bytes

aisleriot-3.16.2-1.fc22
---
* Sun May 10 2015 Kalev Lember  - 1:3.16.2-1
- Update to 3.16.2
- Include new symbolic app icon


Size change: 146 bytes

bijiben-3.16.2-1.fc22
-
* Tue May 12 2015 Kalev Lember  - 3.16.2-1
- Update to 3.16.2


Size change: 583 bytes

clutter-1.22.2-1.fc22
-
* Tue May 12 2015 Kalev Lember  - 1.22.2-1
- Update to 1.22.2


Size change: 3 bytes

control-center-3.16.2-1.fc22

* Tue May 12 2015 Kalev Lember  - 1:3.16.2-1
- Update to 3.16.2


Size change: 1937 bytes

empathy-3.12.10-2.fc22
--
* Wed May 13 2015 Kalev Lember  - 3.12.10-2
- Use the symbolic icon from the 3.12.10 tarball

* Wed May 13 2015 Debarshi Ray  - 3.12.10-1
- Update to 3.12.10
- Drop patches. Fixed upstream.

* Tue May 12 2015 Kalev Lember  - 3.12.9-4
- Put the symbolic icon in the right directory


Size change: -1022 bytes

eog-3.16.2-1.fc22
-
* Wed May 13 2015 Kalev Lember  - 3.16.2-1
- Update to 3.16.2

* Tue May 12 2015 Michael Catanzaro  - 3.16.1-2
- Add symbolic icon


Size change: 10229 bytes

epiphany-3.16.1-1.fc22
--
* Tue May 12 2015 Kalev Lember  - 1:3.16.1-1
- Update to 3.16.1


Size change: -16166 bytes

evince-3.16.0-2.fc22

* Wed May 13 2015 Michael Catanzaro  - 3.16.0-2
- Add symbolic icon


Size change: 2699 bytes

evolution-3.16.2.1-1.fc22
-
* Mon May 11 2015 Milan Crha  - 3.16.2.1-1
- Update to 3.16.2.1


Size change: 6072 bytes

evolution-data-server-3.16.2-2.fc22
---
* Wed May 13 2015 Milan Crha  - 3.16.2-2
- Add patch for GNOME bug #719476 (IMAPx IDLE could cause folder content vanish 
locally)

* Mon May 11 2015 Milan Crha  - 3.16.2-1
- Update to 3.16.2


Size change: 3090 bytes

evolution-ews-3.16.2-1.fc22
---
* Mon May 11 2015 Milan Crha  - 3.16.2-1
- Update to 3.16.2


Size change: 88 bytes

evolution-mapi-3.16.2-1.fc22

* Mon May 11 2015 Milan Crha  - 3.16.2-1
- Update to 3.16.2


Size change: 30 bytes

f22-kde-theme-22.0-1.fc22
-
* Wed May 13 2015 Jan Grulich  - 22.0-1
- Add splash and lockscreen fedora twenty two theme


Size change: 2368079 bytes

fedora-release-notes-22.02-1.fc22
-
* Thu May 14 2015 Pete Travis  - 22.02-1
- F22 GA content


Size change: 17290 bytes

file-roller-3.16.2-1.fc22
-
* Tue May 12 2015 Kalev Lember  - 3.16.2-1
- Update to 3.16.2


Size change: 672 bytes

four-in-a-row-3.16.2-1.fc22
---
* Tue May 12 2015 Yanko Kaneti  - 3.16.2-1
- Update to 3.16.2
- No more separate HighContrast icons


Size change: -3949 bytes

gcr-3.16.0-1.fc22
-
* Tue May 12 2015 Kalev Lember  - 3.16.0-1
- Update to 3.16.0


Size change: -23764 bytes

gdk-pixbuf2-2.31.4-1.fc22
-
* Mon May 11 2015 Kalev Lember  - 2.31.4-1
- Update to 2.31.4


Size change: 701948 bytes

geocode-glib-3.16.2-1.fc22
--
* Tue May 12 2015 Kalev Lember  - 3.16.2-1
- Update to 3.16.2
- Use license macro for COPYING.LIB


Size change: 639 bytes

glib2-2.44.1-1.fc22
---
* Wed May 13 2015 Kalev Lember  - 2.44.1-1
- Update to 2.44.1


Size change: -107383 bytes

gnome-boxes-3.16.2-1.fc22
-
* Tue May 12 2015 Michael Catanzaro  - 3.16.2-1
- Update to 3.16.2


Size change: 26234 bytes

gnome-calendar-3.16.2-1.fc22

* Tue May 12 2015 Kalev Lember  - 3.16.2-1
- Update to 3.16.2


Size change: 11745 bytes

gnome-characters-3.16.2-1.fc22
--
* Tue May 12 2015 Kalev Lember  - 3.16.2-1
- Update to 3.16.2


Size change: 2480 bytes

gnome-chess-3.16.2-1.fc22
-
* Sun May 10 2015 Kalev Lember  - 3.16.2-1
- Update to 3.16.2
- Include new symbolic icon


Size change: -153268 bytes

gnome-desktop

Re: simplestreams json or index.asc for deliverables in the new list-of-deliverables?

[Przemek Klosowski]

On 05/18/2015 07:44 PM, Matthew Miller wrote:

That way, we'd have a standardized way for applications to find and
download/launch/whatever various Fedora images. This is a definite need
(see https://fedorahosted.org/cloud/ticket/93) and rather than
inventing a new wheel, maybe we could see if we could pound one of
these into shape.

Thank you for that thought--I am so going to use it from now on:

 Rather than reinventing a wheel, let's pound an existing one into 
a circular shape


This perfectly  describes a situation I often find myself in. I didn't 
think of it this way, but there it is.
-- 
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 22 Final Release Readiness Meeting :: Thursday, May 21, 19:00 UTC

[Jaroslav Reznik]

Fedora 22 Final Release Readiness Meeting.

date: 2015-05-21 place: irc.freenode.net in #fedora-meeting-2
time: 19:00 UTC (3 PM EDT, 12 noon PDT, 21:00 CEST)

This Thursday, May 21, we will meet to make sure we are coordinated
and ready for the Final release of Fedora 22 on Tuesday, May 26, 2015.
Please note that this meeting will occur on May 21 even if the
release is delayed at the Go/No-Go meeting on the same day two hours
earlier.

You may received this message several times, but I was asked to open this
meeting to the teams and I'll also hope this will raise awareness and more
team representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams. We also have a badge!

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

Re: Rapid release for security updates

[Kevin Kofler]

Martin Stransky wrote:
> is there any mechanism how to speed up release of critical security
> fixes by Fedora update system?
> 
> For instance Firefox packages are released *week* after official Mozilla
> release which is really bad.
> 
> Any idea here?

The "update stability policies" enforced by Bodhi simply need to be 
repealed. This problem simply did not exist when maintainers were still 
trusted to be able to do their job.

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 System Wide Change: Mono 4

[Moez Roy]

On Tue, May 19, 2015 at 2:36 AM, Peter Robinson  wrote:
> On Mon, May 18, 2015 at 4:52 AM, Moez Roy  wrote:
>> Mono is updated in Rawhide. Can a proven-packager run a script to
>> rebuild all the packages that require mono.
>
> Most of these are now built, sadly because all the bits needed weren't
> actually committed it wasn't as simple as running a script.
>
> They will be in today's rawhide compose.
>
> I did a bunch of cleanup as I went and we tagged in 57 builds, see the
> ticket [1] for the details. There are a number of failures where
> packages need to be updated but over all they're leaf packages so only
> really affect themselves. There were 57 packages tagged in, there's
> around 70 packages that depend on mono in total, IMO this is too
> invasive for F-22, there would be a lot of work to get that landed
> cleanly.
>

Thanks Peter Robinson for helping.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaned Packages in rawhide (2015-05-19)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package(co)maintainers  Status Change 
===
blahtexml  orphan 2 weeks ago   
gvrpcd orphan 2 weeks ago   
mozilla-noscript   orphan, ixs, tomspur   0 weeks ago   
nss_compat_osslorphan, kdudka, mharmsen, rcritten,2 weeks ago   
   rrelyea  
obexftporphan, itamarjp   6 weeks ago   
ovirt-node orphan, apevec, fabiand, jboggs,   2 weeks ago   
   mburns72h, pmyers
python-sqlalchemy0.5   orphan 7 weeks ago   
python-sqlamp  orphan 7 weeks ago   

The following packages require above mentioned packages:
Depending on: nss_compat_ossl (1), status change: 2015-04-29 (2 weeks ago)
centerim (maintained by: lkundrak, awjb)
centerim-4.22.10-17.fc23.i686 requires libnss_compat_ossl.so.0
centerim-4.22.10-17.fc23.src requires nss_compat_ossl-devel = 
0.9.6-9.fc22


Depending on: python-sqlalchemy0.5 (1), status change: 2015-03-31 (7 weeks ago)
python-migrate0.5 (maintained by: lmacken, mbacovsk)
python-migrate0.5-0.5.4-7.fc21.noarch requires 
python-sqlalchemy0.5 = 0.5.8-11.fc19
python-migrate0.5-0.5.4-7.fc21.src requires 
python-sqlalchemy0.5 = 0.5.8-11.fc19


Affected (co)maintainers
apevec: ovirt-node
awjb: nss_compat_ossl
fabiand: ovirt-node
itamarjp: obexftp
ixs: mozilla-noscript
jboggs: ovirt-node
kdudka: nss_compat_ossl
lkundrak: nss_compat_ossl
lmacken: python-sqlalchemy0.5
mbacovsk: python-sqlalchemy0.5
mburns72h: ovirt-node
mharmsen: nss_compat_ossl
pmyers: ovirt-node
rcritten: nss_compat_ossl
rrelyea: nss_compat_ossl
tomspur: mozilla-noscript

Orphans (8): blahtexml gvrpcd mozilla-noscript nss_compat_ossl obexftp
ovirt-node python-sqlalchemy0.5 python-sqlamp


Orphans (dependend on) (2): nss_compat_ossl python-sqlalchemy0.5


Orphans (rawhide) for at least 6 weeks (dependend on) (1):
python-sqlalchemy0.5


Orphans  (rawhide)(not depended on) (6): blahtexml gvrpcd
mozilla-noscript obexftp ovirt-node python-sqlamp


Orphans (rawhide) for at least 6 weeks (not dependend on) (2): obexftp
python-sqlamp


Depending packages (rawhide) (2): centerim python-migrate0.5


Packages depending on packages orphaned (rawhide) for more than 6
weeks (1): python-migrate0.5


Not found in repo (rawhide) (1): ovirt-node

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py
-- 
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: Rapid release for security updates

[Jared K. Smith]

On Tue, May 19, 2015 at 8:20 AM, Kevin Kofler 
wrote:

> The "update stability policies" enforced by Bodhi simply need to be
> repealed.
>

I completely disagree... the checks and balances that are in place are
there for a reason, and aren't too difficult to satisfy in the case of a
security update.  Completely repealing the requirements would be a gross
overreaction.

--
Jared Smith
-- 
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: Rapid release for security updates

[Corey Sheldon]

I totally agree with Jared, just becuase oyu don't see the logic doesn't
mean it needs repealed.

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
(p) 310.909.7672
G+: 
LinkedIn: 
Github: 
Facebook: 
Several Communities on Stack Exchange 



Tutoring in person or via any of the following platforms:
HackHands 
Wizpert 
FieldNation 
AirPair 
Truelancer 

{PayPal,Google Wallet/Play store, Apple Pay}
---
pub  3072D/718BF597
 2014-12-08
  Key fingerprint = 2930 99EB 083D D332 0752 88C4 E958 C5D6 718B F597
uid Corey Sheldon (Fedora Key) 
---

On Tue, May 19, 2015 at 4:54 PM, Jared K. Smith 
wrote:

>
> On Tue, May 19, 2015 at 8:20 AM, Kevin Kofler 
> wrote:
>
>> The "update stability policies" enforced by Bodhi simply need to be
>> repealed.
>>
>
> I completely disagree... the checks and balances that are in place are
> there for a reason, and aren't too difficult to satisfy in the case of a
> security update.  Completely repealing the requirements would be a gross
> overreaction.
>
> --
> Jared Smith
>
> --
> 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