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:
-----BEGIN PGP SIGNED MESSAGE-----
as of now, Annobin has been enabled in Rawhide. This is special plugin for
gcc so something might break due to it (but not expected). Don't hesitate to
open a bug in that case.
Just small heads up.
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
I'm planning on updating bullet to 2.87 in rawhide over the weekend.
The following packages are affected:
$ dnf repoquery --source --alldeps --whatrequires "bullet*"
Last metadata expiration check: 0:37:51 ago on Tue 28 Nov 2017 07:31:59 PM EST.
I will take care of all of the rebuilds once the bullet build is complete.
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
Eike Rathke and I are working on updating ICU from 57.x to 60.x in rawhide/F28. It includes a soname bump and has a few API changes. We'll do an ABI compat package to avoid breaking the world while rebuilds are ongoing.
We'll import it some time this week and I'll be coordinating rebuilds through my provenpackager powers.
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.
Reading logs from yesterdays FPC meeting , I think we should discuss
what is actually purpose of packaging guidelines and which version of
Fedora/EPEL/RHEL they actually targets.
Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
1) single version of .spec file to cover the whole Red Hat ecosystem.
2) clean .spec file following the latest and greatest packaging practices.
I personally belong to the group (2) and that is for several reasons:
a) I use Rawhide on daily basis and I develop only for Rawhide. If I do
changes in older Fedoras, then it is typically just bug fixes and
honestly, that does not happen often (I am POC of ~200 packages and I
submitted just 40 updates during last year ). And in fact, this is
official philosophy of updates , not just mine.
b) I spent time developing features which should simplify packaging (for
example in F27+, the RPM %setup macro can expand the .gem packages) and
I want to use these technologies to simplify my life and life of others.
c) As a proven packager and person who typically does rebuild of Ruby
packages, I really hate the branched .spec files where nobody knows what
was the purpose of the branches, most of the branches are for obsolete
and unsupported releases etc. It is quite hard to apply any improvements
into such packages. Moreover it is not realistic to test them. If they
were maintained, it would be different story, but the reality is different.
Don't get me wrong, I understand that there are packagers who has just
handful of packages and it is better for them to maintain just single
.spec file with all the branches and I don't mind them as long as the
packages are really actively maintained. But this approach just don't
scale and should be exception and not recommended practice.
To sum this up, my take on packaging guidelines is that *the guidelines
should document the most recent practices available in Rawhide and this
should be documented*. Covering all the exceptions necessary for older
Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
and what is worse, they slow down entire development of Fedora.
I'm on a Fedora 27 Workstation system, dnf system-upgrade(d) from
Fedora 26. I've got a few crashes that gnome-abrt (Problem Reporting)
I've clicked on to report, but I get this message for all three of
Retrace job failed
Retrace failed. Try again later and if the problem persists report
this issue please.
The main problem with this is the message itself: I'm not sure where
to report it or what information to include.
This is an example from one of their log windows (I've already
downloaded all the
debuginfos and separately filed bugs for these crashes with coredumpctl gdb
output, but maybe there's an issue with the retrace server (?)
2017-11-28 04:18:12 Analyzing crash data
2017-11-28 04:18:28 WARNING:fedora.client.openidbaseclient:Unable to
create /usr/share/retrace-server/.fedora: [Errno 13] Permission
ERROR:faf:Unable to import plugin
pyfaf.actions.create_problems_gnome_mmarusak: cannot import name
INFO:faf.Coredump2Packages:Mapping build-ids into debuginfo packages
INFO:faf.Coredump2Packages:Getting binary packages from debuginfos
Hi fedora-release maintainers and fellow developers,
The fedora-release package contains stuff that is tied to each Fedora
version and changes slowly, and it also contains the preset files for
systemd units, which change fairly often (a few requests per month).
Currently fedora-release has a fairly complicated maintenance
structure, with an "upstream" project at https://pagure.io/fedora-release
and "downstream" at https://src.fedoraproject.org/rpms/fedora-release.
"upstream" is only used for this single "downstream", and in fact changes
made in packaging "downstream" are sometimes lost when the next version
of "upstream" is imported.
I propose simplifying this and opening fedora-release releases to more
1. Let's drop "upstream" at https://pagure.io/fedora-release and
make the "downstream" the canonical source of the package,
2. Allow pull requests in src.fp.o/fedora-release,
3. With 1 and 2. implemented, it'll be easier for any fedora maintainer
to suggest improvements to the package (through PRs) and it'll also
be possible for proven packagers to do changes without stepping on
the toes of the maintainers and interfering with the separate "upstream"
repo. Let's agree to allow pps to update fedora-release as necessary
when the main maintainers are busy.
4. Release fedora-release quickly, so that when a preset change request
comes in , it can be handled in a few days or a week. (Having such
requests hanging usually blocks changes to the package in question,
so it's important to have the resolution of the preset status without
To implement this, not much action is required, mostly acceptance of the
maintainers to amend and open up the process. Concrete steps that do need
to be taken:
1. tweak https://src.fedoraproject.org/rpms/fedora-release/settings
to allow PRs
2. push a commit to "upstream" that that repo is dead
3. make a README for "downstream" that PRs can be submitted and outline
I'll be happy to submit the PRs for 2 and 3. I'll also be applying for
co-maintainership in the fedora-release package, because I want to push
those changes forward.
What do you think?