I'm the RPM package maintainer for these two GNOME Shell extensions:
They're both currently subpackages of the main "sustmi" package, because upstream had been developing them in a single git repository. The two shell extensions have nothing to do with each other, though, and upstream finally decided to split them into separate repositories. So I think it now makes sense to also split them into separate packages.
I'm not entirely clear on the procedure. This wiki page
talks at first about *font* packages, but otherwise seems relevant. So, I've started by splitting and updating the spec files, and creating these review requests. As I understand it, because the packages were already accepted into Fedora, and the extension code hasn't changed, just the packaging, I think all a reviewer should really need to check is whether the upgrade path is sane and works properly.
* HistoryManager Prefix Search -- https://bugzilla.redhat.com/show_bug.cgi?id=1506428
* WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429
Please take a look, and let me know if I've missed anything.
~ Andrew / terrycloth
= Proposed System Wide Change: Annobin =
* Nick Clifton <nickc AT redhat DOT com>
This change causes extra information to be stored in binary files
compiled by gcc. This information can be used by scripts to check on
various features of the file, such as the hardening options used of
potential ABI conflicts.
== Detailed Description ==
The plan is to use a plugin to gcc to record extra information in the
object files it creates. This information can then be examined by
static analysis tools. The information is recorded in a compact,
extensible format, described here:
The Fedora annobin package is an implementation of the plugin for gcc.
It also includes some example scripts that demonstrate how the
recorded information can be used to, for example, check that an
executable has been compiled with the correct hardening options, or
detect if any conflicting ABI options have been used when compiling
various parts of the executable.
To enable this change it is proposed that the redhat-rpm-config
package should be extended to add the "-fplugin=annobin" option to the
__global_compiler-flags macro. In theory such a change will be
completely invisible to Fedora users but should prove to be very
helpful to Fedora Release Management, assuming that they like the idea
of these annotated binaries.
== Scope ==
* Proposal owners:
Make sure the annobin plugin is ready.
* Other developers:
An update is needed to the redhat-rpm-config package in order for the
plugin to be invoked when gcc is used to compile programs, and to add
a dependency upon the annobin package.
* Release engineering: https://pagure.io/releng/issue/7069
- Coordination with release engineering is needed.
- A mass rebuild will be required.
* List of deliverables:
All delivered images are affected, however there no changes to the list it self.
* Policies and guidelines:
No updates needed
* Trademark approval:
N/A (not needed for this Change)
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
I like to have everything on my system in a package. So, I looked around and
found no recipe or rpm for Rstudio. This is really a shame because every
tutorial on R kinda tells you to install it. Even the Coursera classes in the
Data Science track make you install it and send a screenshot to prove it.
So, I spent some time getting it packaged and working. I am placing the spec
file and necessary patch here so that google finds it and saves other people the
trouble. I'm not wanting to submit the package to Fedora because its more work
than I have time for. If anyone else wants to take it from here and submit
and/or maintain it, feel free.
I intend to update elpa to the latest version (2017.05.002) in rawhide.
This is a major change from currently packaged 2015.11.001. It comes
with a new API and is ABI-incompatible. Old APIs, especially some
private functions which were exposed but not meant for public use by
upstream have been removed. New API is described in USERS_GUIDE.md .
There are two consumers of elpa in Fedora: cp2k and openmx. I put
the maintainers (myself included) of these packages on Cc in this
While cp2k already supports this new elpa, openmx does not. There
was some discussion about this in bug #1325933  and upstream ,
but upstream seems to be reluctant to change anything, so in worst
case scenario, openmx can switch to using the old bundled copy of
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
Since its retirement from Fedora, SciDAVis has undergone
significant development and I think it is ready to be re-included in
our package collection. After a few months of private builds that I
distributed among co-workers and friends, I set up a copr and I've
been keeping up with the upstream project.
SciDAVis comes with a bundled copy of liborigin, which the upstream
developers helped me unbundle. Its version has been bumped to 3.0.0
internally, although there hasn't been a 3.0.0 release yet. In Fedora
we carry liborigin2 (code from the latest public release) and
liborigin (snapshot from 2008) which both help import different
versions of Origin project files. The new release will render them
SciDAVis and liborigin share a number of contributors, but at the
moment their codebases have diverged; upstream liborigin trunk has
been adjusted to work with development versions of LabPlot 2.x, while
the copy bundled with SciDAVis is closer to that of a future
liborigin-3.0.0 release, but they are not interchangeable. I asked the
developers to clarify their plans and I was told that the two
versions will merge back, though some API changes might come in the
I have checked if there are any packages at the moment that require
liborigin* or liborigin*-devel and I have found none (though I'd be
grateful if someone who feels more at ease with dnf could
double-check). If not for this divergence, I would submit scidavis and
liborigin3 for review as separate packages, with Provides & Obsoletes
for the previous liborigin* and liborigin*-devel versions and be done
with it. However I would have to use the unbundled copy from SciDAVis
as source for liborigin3. Should I proceed with that anyway or should
I keep it bundled until such time as the two codebases have merged?
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:
apitrace 5.0 bundles libbacktrace, which looks like is living within the
gcc sources. libbacktrace is not build as a shared library from the gcc
sources, and not packaged.
Is it feasible to build libbacktrace as a shared library and ship it in
a corresponding package? Or should I rather go for a bundling exception
We have been getting bounced emails from Axel Thimm for a while and I
don't have any other way to contact him. He was an early maintainer of
packages but has not been seen in fas since 2013.
He is the co-maintainer of the following packages:
rpms/apt -- Debian's Advanced Packaging Tool with RPM support ( master f26 f25 )
rpms/arpack -- Fortran 77 subroutines for solving large scale
eigenvalue problems ( master f26 f25 )
rpms/chrpath -- Modify rpath of compiled programs ( master f26 f25 )
rpms/courier-unicode -- A library implementing algorithms related to
the Unicode Standard ( master f26 f25 )
rpms/fail2ban -- Daemon to ban hosts that cause multiple
authentication errors ( master f26 f25 )
rpms/fakechroot -- Gives a fake chroot environment ( master f26 f25 )
rpms/fakeroot -- Gives a fake root environment ( master f26 f25 )
rpms/fedora-package-config-apt -- Fedora configuration files for the
apt-rpm package manager ( master f26 f25 )
rpms/freenx-server -- Free Software (GPL) Implementation of the NX
Server ( master f26 f25 )
rpms/ivtv-firmware -- Firmware for the Hauppauge PVR
250/350/150/500/USB2 model series ( master f26 f25 )
rpms/libcdaudio -- Control operation of a CD-ROM when playing audio
CDs ( master f26 f25 )
rpms/maildrop -- Mail delivery agent with filtering abilities ( master f26 f25 )
rpms/perl-Text-CharWidth -- Get number of occupied columns of a string
on terminal ( master f26 f25 )
rpms/perl-Text-WrapI18N -- Line wrapping with support for several
locale setups ( master f26 f25 )
rpms/php-pear-Auth-OpenID -- PHP OpenID ( master f26 f25 )
rpms/po4a -- A tool maintaining translations anywhere ( master f26 f25 )
rpms/synaptic -- Graphical frontend for APT package manager. ( master f26 f25 )
rpms/vtk -- The Visualization Toolkit - A high level 3D visualization
library ( master f26 f25 )
If anyone has had contact with him could he see if can fix his email?
Stephen J Smoogen.
This is a reminder that the webkitgtk and webkitgtk3 packages will be
retired from rawhide shortly after F26 is branched from rawhide. This
is due to numerous security issues affecting those packages (I just
counted 204 CVEs), many of which could allow remote code execution.
Bugs have already been filed against all directly-affected packages
Note: to count the vulnerabilities, I just manually added up the CVEs
listed at , ignoring the oldest advisory WSA-2015-0001, and
discounting five of the older vulnerabilities in WSA-2015-0002.
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: