I just git a "broken dependencies" notice for a package that I maintain.
The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a
heads up notice to maintainers of depending packages may be in order
before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing
As for pdftk: I see 2 failed builds for version 1.45 and none for the
current version 2.02 (which probably breaks the api anyways). What are
the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for
pdftk 2.02, by the way. I might even look into packaging it but don't
want to duplicate any existing efforts.
I just had to setup a new machine, and new ssh keys.
I chose my new id_rsa.pub to upload.
But I get:
git push --verbose
Pushing to ssh://firstname.lastname@example.org/mercurial
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Phoronix recently release article about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
Best regards / S pozdravem,
I just submitted a review request  for kcov  that I recently
discovered. It has no relation to Linux's kcov and is more akin to
lcov, except that all it needs is a binary with DWARF debuginfo
instead of requiring compile-time instrumentation.
I came across kcov when I was looking for a way to measure code
coverage in a Rust project and I'm impressed. It supposedly has a low
overhead, but so far I've been monitoring small single-threaded
programs so I can't really tell. I haven't tested python and shell
support, although I have cases where it would be relevant, but I don't
have time yet.
build on all main platforms so I may have to be granted an exception
from some group starting with an F. Been busy lately, I'm a little
behind on anything Fedora. If that's the case, please RTFM me a link
to the wiki, and if you want to take the review I'll gladly take one
= 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.
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