I need/want/would like to build new node 6 for EL6, but gcc is too old.
For that reason, I'd like to use devtoolset-4-gcc, but the build fails
(obviously) because the package doesn't exist.
So, is there a way to make that work somehow?
I am not sure about enabling external repos during build, maybe someone
will be wiser.
Here's the build:
= System Wide Change: NSS Default File Format SQL =
* Kai Engert <kaie(a)redhat.com>
Change the NSS library default to use the sqlite based data storage,
when applications don't specify their preferred storage file format.
== Detailed Description ==
Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different file
formats, one called DBM (based on berkeley DB files) and another one
called SQL (based on sqlite DB files).
Today's default file format used by NSS, used when applications omit
the type parameter, is the older DBM file format, which forbids
parallel access to the storage. The suggestion is to change the
default file format to SQL, which allows parallel access to the
Applications, or users using the NSS command line utilities, often
provide the database storage location using a simple directory path
parameter. Some might not be aware, or forget, that the parameter can
be prefixed with a type modifier, either "dbm:" or "sql:".
As a result, when not providing this parameter, the file format used
will be the fragile DBM file format. This is particuarly problematic,
if a user attempts to modify the NSS storage using command line tools,
while another process, such as a daemon, is running concurrently,
which also accesses the same database in the DBM file format. This
often results in corrupted database storage, which cannot be
By changing the default, all applications that currently use the DBM
file format, will automatically be migrated to the SQL file format.
NSS has the ability to discover if a storage location (a directory)
contains the DBM file format. If configured to use the modern SQL
format, NSS will automatically perform a one-time conversion from the
DBM to the SQL format.
The same applies to the NSS command line utilities. If the NSS library
default is changed to SQL, the NSS tools will also trigger the
one-time conversion, or access the already converted files.
== Scope ==
* Proposal owners:
A small downstream patch needs to be applied to the NSS library
package, which changes the library default.
* Other developers:
It's up to developers of NSS applications, if they accept the new
default and an automatic conversion, or if they prefer to continue to
use the classic DBM storage format. Although not recommended,
developers can easily do so, by adding a "dbm:" prefix to the storage
parameter they provide to NSS at NSS library initialization time.
* Release engineering: 
No help should be necessary. No mass rebuild necessary.
* Policies and guidelines: N/A
* Trademark approval: N/A
Greetings. Is https://github.com/fedora-selinux/selinux-policy-contrib
the right place to contribute to the Fedora SELinux policy?
I added a pull request for a small update needed for a new release of
cups-pdf, but I am not sure someone is monitoring that. There is another
one from rhatdan there so I presume is the right place.
Has anyone heard from kanarip or able to contact him?
I've been attempting to contact for this bug:
If there's no response in one week an issue will be filed with FESCo
following the nonrepsonsive maintainer policy to review the ownership
status of the packages.
For ruby maintainers please note that this has a significant impact on
you, if you want to keep track of this, as he owns puppet, rubygems
and ruby ...
I ran into this unannounced change:
If this is accepted, all x86 hardware on which Fedora can run will
support SSE2, and we should reflect that in the i686 build flags.
How likely is it that this proposal is accepted? Ideally, we would know
this before the mass rebuild so that we can change the compiler flags in
Until recently, Mozilla maintained three individual trust bits for each root CA
- trust for TLS servers
- trust for email security
- trust for code signing
The next CA update from Mozilla will switch the code signing trust bit
OFF for all CAs.
Mozilla will no longer maintain this trust bit.
I'm not aware of anyone using this trust bit. The removal might have no effect.
This update of the CA list is supposed to get published with Firefox 56 on
In order to allow the Fedora community to test potential effects of this change,
I intend to publish an update to the ca-certificates packages early, and keep it
in updates-testing for a few weeks.