My next project for Red Hat is to work on improving Linux laptop battery life.
Part of the (hopefully) low hanging fruit here is using kernel tunables to
enable more runtime powermanagement. My first target here is SATA Link Power
Management (LPM) which, as Matthew Garrett blogged about 2 years ago:
can lead to a significant improvement in battery life.
There is only one small problem, there have been some reports that some
disks/SSDs don't play well with Linux' min_power LPM policy and that this
may lead to system crashes and even data corruption.
As such I've written a new LPM policy, which matches the power-management
defaults from the Intel RST Windows drivers. Since it mimicks Windows,
this new policy will hopefully not hit any SSD firmware bugs like min_power
So now I'm looking for people with a laptop with a SATA SSD or HDD to help
me test this to make sure this won't cause any issues when we enable this
by default for F28, for more details and test instructions see:
= 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
On Sat, Oct 7, 2017 at 9:34 AM, Jerry James <loganjerry(a)gmail.com> wrote:
> I don't believe that anybody looks at those pull requests on a regular
> basis. Should somebody be doing so? There are 8 pull requests,
> dating back to about the time of the above conversation. Five of
> those don't contain a single comment.
> I opened one for gcl on July 29, and added a comment a month later
> asking if somebody was going to look at it. No response. This is a
> bit annoying, considering that I opened a bugzilla request asking for
> the same thing 4 years ago, and no action has ever been taken on it.
> I thought maybe a PR would finally get something to happen.
Nearly a week has gone by, and no answer. I'm really stumped about
what to do. Let me summarize the whole long saga and solicit help.
GCL is a Common Lisp implementation. It is known for its speed
compared to other CL implementations. It has a long lineage,
summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I
took over maintenance of the package in late 2008 when the previous
maintainer did not have time to continue. At that point, the package
did not build in Rawhide and was slated to be dropped from Fedora
soon. I got it working with help from upstream and Daniel Walsh, who
provided advice on putting together an SELinux policy to account for
the fact that GCL produces executable code on the fly by calling
mprotect on selected pages.
Fast forward to 2013. By that time, the GCL policy also had to
mention maxima executables, since executables built with GCL also use
the GCL memory allocator. I figured that meant it was time to merge
the GCL policy into the system policy, and consequently opened a
bugzilla ticket. In spite of me trying to reboot the conversation a
couple of times, those involved who held the SELinux reins for Fedora,
Just. Could. Not. Stay. On. Topic. We talked about the execheap
permission in general, and its place in the universe. Some of them
sneeringly, condescendingly wondered why upstream and I were both so
incompetent that we didn't just rewrite the allocator to use mmap.
(Hint: it isn't easy, and upstream isn't interested in the exercise.)
After multiple failures on my part to get something to happen, I gave
up in despair.
Fast forward to 2017. Attempts to build maxima with gcl on aarch64
started hanging at package install time. See
https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed
on gcl, incorrectly I believe. As I pointed out in the bug, nothing
built from gcl sources runs at package install time, so the hang must
be happening inside one of fixfiles, semodule, or restorecon, which
ARE run from the gcl install scripts because GCL has to install its
own SELinux policy, due to that policy not being merged into the
system policy. So, policycoreutils maintainers! Something Is Afoot
But that's not the end of the fun. GCL failed the mass rebuild this
summer. It built successfully on every architecture but s390x. On
s390x, the build failed due to a failed call to mprotect(), almost
certainly a sign that SELinux was in enforcing mode on the builder.
Was that a known issue with s390x builders? And, if so, has it been
rectified since? If so, I'll try building again.
I still want the system policy to account for GCL, in some way or
another. But, as you can see from the quoted text above, submitting a
pull request to the relevant git repository has resulted in months of
<crickets chirping>. And pointing that out on this list last weekend
has resulted in still more of the crickets.
So ... what is a packager supposed to do???? Why is it so hard to get
any attention for submissions to the system SELinux policy? There
should be a barrier to entry; I understand that. But I can't even get
the gatekeeper to have a conversation with me. Heeeeellllllppppp!!!
let's have some fun with upcoming Firefox 57 a.k.a Firefox Quantum. This
is a major Firefox update with key - pleasant and unpleasant - changes:
- fastest than ever with Rust, CSS Stylo, Sandbox...
- new "Photon" look
- and disabled XUL extensions
according to the disruptive nature of the update which is planned to
land in *all* Fedoras at Nov 14 I decided to put the update to the
testing as soon as possible, which mean we have Firefox 57 Beta packages
at update-testing right now.
If you don't consume update-testing regularly you can install Firefox
# dnf update --enablerepo=updates-testing firefox
and also expect new versions there. Please give it a shot and report any
issue to our  or Mozilla bugzilla .
We're going to build new cryptsetup-2.0.0-rc1 package in rawhide next
week. The major version increase also brings libcryptsetup soname bump.
Among other things new library will drop few functions.
These API functions will be removed:
For further description and explanation why those calls were removed and
what new functions are available, please see:
Following packages are listed as having direct runtime dependency on
cryptsetup-libs (arch x86_64 only) and therefore they may break or fail
to build if they use any function listed above:
The following packages are looking for new maintainers, ping me if
you're able to help out.
1) No co-maintainers at the moment:
2) Needs new main admin, co-maintainers pinged some time ago but no
Greetings fellow Fedorans,
We're about to release Bodhi 3.0.0 upstream, which has a backwards
incompatible CLI change that I am considering backporting to the
stable Fedoras, but I wanted feedback first before I do that.
The Bodhi 2 CLI will use the USERNAME environment variable when
authenticating you, if present, and the Bodhi 3 CLI does not use any
environment variable (yet) for authentication. Here's the reasoning:
* The Bodhi 2 CLI previously didn't have the ability to remember your
username, but it did have the environment variable, which kind of
acted like a bandaid. I believe this variable was in place before I
* The CLI got a lot of love earlier this year, and one of the big things
added was the ability for it to remember your username if you've ever
successfully authenticated before. This feature largely removed the
need for the environment variable, but keeping the variable seemed
harmless at the time.
* I recently learned that the variable is painful for some users,
because GDM sets this variable to your local system's login username,
which is not necessarily the same as your FAS username.
* When the username is present, Bodhi will not prompt the user for their
username, which leads to a very poor experience upon first login for
GDM users who have mismatching FAS account names (Bodhi prompts for
their password and then tells them it's wrong). Without the variable,
Bodhi will prompt users to enter their username upon first use.
* Users can currently override the USERNAME environment variable with a
--user flag as a workaround.
* Though it may seem that Kerberos addresses this problem, Bodhi does
not use Kerberos (it uses OpenID) and there are not plans to adjust
Bodhi to use Kerberos because we plan to convert it to use OpenID
In order to address the above, and in the spirit of working quickly due
to the other pressures to complete 3.0.0, it was easy enough to just
drop support for this environment variable with 3.0.0, since 3.0.0
already needed other backwards incompatible changes. However, I have a
few questions for the list:
0) Do you have a use case for an environment variable to set your
username? If there is sufficient demand for this feature, we can add
it back with a different name in a future Bodhi 3 release (perhaps
BODHI_USER or FAS_USER would suffice).
1) I'd like to make a backwards incompatible patch for the stable
Fedoras so that GDM users get a better experience without having to
wait for Fedora 28, but I don't want to do this if it is too
disruptive. Normally I am quite against backwards incompatible
changes in Fedora, but this can also be viewed as a painful bug and
fixing the bug might alleviate more pain than the change would
cause. Would such a change be a disruption to us developers, or does
the good outweigh the bad?
A few options for F25-27:
0) Do nothing, and let Rawhide be the only place this change happens.
1) Drop USERNAME.
2) s/USERNAME/BODHI_USER/ or similar.
P.S. The Bodhi 3.0 beta is also deployed to staging, though no user
visible changes will be apparent. It's main feature is the ability to