A manual page is now available that describes the new
Shared-System-Certificates feature.
It's contained in this new build for F19:
https://admin.fedoraproject.org/updates/ca-certificates-2012.87-10.4.fc19
(and in rahide, too).
man update-ca-trust
Please let us know if you have feedback.
Thanks a lot in advance!
Kai
Hi,
I'm facing a strange issue while using libcurl with pthreads to access 'https://' addresses.
The program abruptly crashes with a SIGPIPE. I'm unable to produce it for any single URL.
This very issue was fixed upstream recently:
-> http://www.fpaste.org/23849/
-> http://sourceforge.net/p/curl/bugs/1180/
Till the time the new fixed version - 7.31.0 - is packaged and available, solution is for
applications to ignore SIGPIPE signal.
+ signal(SIGPIPE, SIG_IGN);
The problem is, even after ignoring SIGPIPE, I'm seeing same crashes. I was wondering
if anyone has seen such an issue before. Does libcurl in Fedora use OpenSSL or a different
library for secure connections?
$ curl-config --configure
... '--with-libssh2' '--without-ssl' '--with-nss' ...
Thank you.
---
Regards
-Prasad
http://feedmug.com
= Proposed Self Contained Change: Ryu Network Operating System =
https://fedoraproject.org/wiki/Changes/Ryu
Change owner(s): yamahata <yamahata at private email ne jp>
Ryu Network Operating System [1]
This change was originally proposed for Fedora 19 but postponed to Fedora 20
https://fedoraproject.org/wiki/Features/Ryu
== Detailed description ==
Ryu is an Operating System for Software Defined Networking.
Ryu aims to provide a logically centralized control and well defined API that
make it easy for operators to create new network management and control
applications. Currently, Ryu manages network devices by using OpenFlow. You
can say that Ryu is an OpenFlow Controller.
For Software Defined Networking or OpenFlow, please refer to Open Networking
Foundation [2]
== Scope ==
Proposal owners:
* Ryu development: DONE
** vlan support: 100% DONE
** Ryu plugin support for Openstack Networking (Neutron, formaly Quantum):
keeping update for its development
* packaging:
** rpm package: available at [3]
** rpm package review [4] Work In Progress
** make sure that it works with dependent Fedora package. Especially OpenStack
and Open vSwitch
Other developers: N/A
Release engineering: N/A
Policies and guidelines: N/A
[1] http://osrg.github.com/ryu/
[2] https://www.opennetworking.org/
[3] http://sourceforge.net/projects/ryu/files/Packages/Fedora/
[4] https://bugzilla.redhat.com/show_bug.cgi?id=909674
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
The Fedora Amateur Radio SIG will be hosting a Ham Radio VE Session at
Flock 2013 (at the College of Charleston) on Saturday, August 10, 2013
from 2:00pm-4:00pm in room ECTR 115. Please arrive promptly at 2:00pm
if possible, we must be out of that room by 4:00pm, as another
talk/hackfest will be starting then.
We will be administering all classes of amateur radio license exams,
Technician, General, and Amateur Extra. Please bring your FRN with you,
or register at http://wireless.fcc.gov/uls if you do not have a license
already. You will also need a photo ID. There is also a fee of $15.00
which goes to the ARRL. You can pay this via cash or check.
If you have any questions, please email us at
ham-radio-exams(a)fedoraproject.org
We also ask that anyone interested in taking any exams please email us
at ham-radio-exams(a)fedoraproject.org to let us know you plan on coming,
but this is not strictly required.
Nick W9NB
--
Nick Bebout
Fedora Project
nb(a)fedoraproject.org
= Proposed Self Contained Change: GLIBC 2.18 =
https://fedoraproject.org/wiki/Changes/GLIBC218
Change owner(s): Carlos O'Donell <carlos(a)redhat.com>
Switch GLIBC in Fedora 20 to GLIBC version 2.18.
== Detailed description ==
GLIBC 2.18 will be released at the end of July 2013; we have started closely
tracking the GLIBC 2.18 development code in Fedora Rawhide and are addressing
any issues as they arise. There should be little difference from the users
perspective between GLIBC 2.17 used in F19 and GLIBC 2.18 used in F20.
== Scope ==
Proposal owners: Update glibc to 2.18 from tested upstream release.
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
The library is backwards compatible with the version of glibc that was shipped
in Fedora 19. All packages do not need to be rebuilt.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
= Proposed System Wide Change: Fedora 20 Boost 1.54 Uplift =
https://fedoraproject.org/wiki/Changes/F20Boost154
Change owner(s): Petr Machata <pmachata redhat com>, Denis Arnaud
<denis.arnaud_fedora m4x org>, Benjamin De Kosnik <bkoz redhat com>
This change brings Boost 1.54.0 to Fedora 20.
== Detailed description ==
The aim is to synchronize Fedora with the most recent Boost release. Because
ABI stability is one of explicit Boost non-goals, this entails rebuilding of
all dependent packages (or just packaging soon enough that a mass rebuild, if
any, takes care of this for free). This has also always entailed yours truly
assisting maintainers of client packages in decoding cryptic boostese seen in
output from g++. Such care is to be expected this time around as well.
As a side note, there are currently two broad Boost-related ongoing projects:
repository modularization, and conversion to CMake. The first doesn't need to
concern us, as it's purely upstream issue. Boost will keep being released in a
single super-tarball for time to come. The latter may concern us eventually in
that will require adjustment of packaging, but that's nowhere near ready yet.
As another side-note, I am considering packaging boost-devel in modules.
Frankly, boost-devel is unwieldy. Shipping dozens of libraries totaling
1.8MLOC in a single package defies the purpose of packaging. Unlike the above-
mentioned modularization effort, which is purely upstream, this one is purely
in packaging, and wholly separate from upstream. I expect this to be part of
Change for Fedora 21.
== Scope ==
Rebasing Boost has a fairly large impact on Fedora. About 130 packages _must_
be rebuilt due to ABI breakage inherent in bumping Boost sonames. There are
almost 250 client packages total.
Proposal owners: Build will be done with Boost.Build v2 (which is upstream-
sanctioned way of building Boost)
Roughly in parallel:
* Either:
** If there is mass rebuild for Fedora 20, package Boost before it starts.
** Otherwise:
*** Request a "boost" build system tag
*** Build boost into that tag
*** Post a request for rebuilds to fedora-devel
*** Work on rebuilding dependent packages in the tag.
*** When most is done, re-tag all the packages to rawhide
* Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing
the client, or Boost).
Other developers: Those who depend on Boost DSO's will have to rebuild their
packages. Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
Release engineering: Side tag creation (unless there is a mass rebuild, then
no assistance).
Policies and guidelines: Apart from scope, this is business as usual, so no
policies, no guidelines.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce