F21 Self Contained Change: Replace Bacula with Bareos
by Jaroslav Reznik
= Proposed Self Contained Change: Replace Bacula with Bareos =
https://fedoraproject.org/wiki/Changes/Bareos
Change Owner(s): Simone Caronni <negativo17 at gmail.com>
The powerful Bacula network backup solution has switched from being Open
Source friendly to being almost closed source. Originally the project was
conceived totally as Open Source, but since the creation of Bacula Systems and
its proprietary Bacula Enterprise Edition product, the Open Source (now called
"Community Edition") has received less and less updates and is mostly
abandoned.
== Detailed description ==
The most important points that are left "abandoned" are the following:
* Installation scripts and updates to makefiles are not updated anymore.
* New plugins and functionalities are not added anymore, except those in the
"core" daemons.
* Gaphical (and buggy) console has not received any update in almost two
years.
* Patches and bugs opened in the bug tracker are mostly left abandoned. Even
trivial fixes are not imported in the source.
* Windows binaries are no longer provided, nor the source for the clients has
been updated. Even if compiled with difficulties, there is no support for recent
Windows versions.
A former Bacula developer, frustrated by the situation created the fork Bareos
a long time ago from Bacula 5.2.x (the current Fedora and RHEL 7 version).
This version has now received '''a lot of bugfixes''' compared to the original
Bacula source. This makes compilation and installation a lot easier than it
was with Bacula.
On top of this, a '''lot of new features''' have been added; some unique to
Bareos but many available only in the closed source Bacula Enterprise.
Here is the list of new features compared to the current Bacula 5.2.13:
* http://www.bareos.org/en/whats_new.html
Some highlights include NDMP support for enterprise class storage (NetApp,
etc.), support for enterprise class tape libraries and Windows support
(including Windows Server 2012) with Bareos generated binaries.
For further details on why a Bacula fork was created please look at the
following links:
* http://www.bareos.org/en/faq/items/why_fork.html
Bareos can also be '''fully compatible with Bacula''' by setting a specific
configuration directive in the Daemon configuration files; thus providing the
option for RHEL 6/7 users to interoperate with Fedora systems.
* http://www.bareos.org/en/faq/items/bareos_bacula_compatibility.html
== Scope ==
To accomplish the goal, the following Bacula packages need to be replaced with
Bareos equivalents:
bacula
bacula-docs
Currently, the same Fedora packages can be rebuilt as they are, to work also
on CentOS/RHEL 5 and 6, upgrading the EPEL or official Bacula packages in the
distributions. This is to have a consistent backup infrastructure across all
the Fedora/CentOS/RHEL ecosystem.
To ease installation, a repository for installing those packages on a
CentOS/RHEL system do exist:
http://repos.fedorapeople.org/repos/slaanesh/bacula/README.txt
The idea is the same for Bareos: import into Fedora 21 packages that can be
rebuilt for all supported Fedora/RHEL/CentOS releases and provide a repository
that can upgrade any Bacula release currently installed in the system with the
new one. In detail; the upgrade scenarios supported when going from Bacula to
Bareos would be:
From Bacula 2.4:
* RHEL/CentOS 5 with EPEL repository
From Bacula 5.0:
* RHEL/CentOS 6
From Bacula 5.2.13:
* Fedora 18+
* RHEL/CentOS 5
* RHEL/CentOS 6
As written before, the change is impacting only Fedora 21, the list of
upgrades supported are only for users who want a consistent backup solution
across the enterprise.
=== External activities ===
Proposal owners: I'm the current Bacula mantainer in Fedora and will complete
the transition in time for the release.
Other developers: N/A (not a System Wide Change)
Release engineering: the release engineering team should make sure the new
Bareos packages are in place instead of the current Bacula packages for the
new release.
Policies and guidelines: N/A (not a System Wide Change)
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
7 years, 11 months
Koji build failure: noarch vs. arch?
by Jerry James
I just had a weird failure on a koji builder:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8776617
The SRPM creation step failed, with this output:
error: parse error in expression
error: /builddir/build/SPECS/libpuma.spec:119: bad %if condition
Building target platforms: noarch
Building for target noarch
Child return code was: 1
EXCEPTION: Command failed. See logs for output.
It is complaining about this line in the spec file:
%if %{__isa_bits} == 64
and, from the mention of noarch, my guess is that the complaint is
triggered because whatever is doing the parsing thinks this is a
noarch package. It is not. It is an archful package, with a noarch
-doc subpackage. What component is doing this parsing? Was it
changed recently? Because that same construct in the spec file didn't
cause a problem the last time I built this package. Also, the package
builds without trouble in mock. Thanks,
--
Jerry James
http://www.jamezone.org/
7 years, 12 months
Some lua packages are broken in f22
by Christopher Meng
Hi,
Without mass rebuild in f22, some lua module packages are broken for
example lua-posix, as lua uses different dirs for every release but
lua modules can't get rebuilt in time. I've filed a bug[1] against
lua-posix but some other lua packages are also affected.
I've seen some rebuilds by spot(Tom), but there are many packages not
rebuilt yet.
[1]---https://bugzilla.redhat.com/1195707
--
Yours sincerely,
Christopher Meng
http://cicku.me
8 years
DNF and mock
by Miroslav Suchý
I just spoke with two members of DNF team about default usage of DNF in mock. I would like to share outcomes of this
meeting.
First I would like to state that you can already optionally use DNF in your mock by setting:
config_opts['package_manager'] = 'dnf'
in your
/etc/mock/site-defaults.cfg
It is present in mock for half a year and all known problems have been resolved for some time.
You can even set this option per chroot target. E.g. put this line only in
/etc/mock/fedora-rawhide-x86_64.cfg
and then only rawhide-x86_64 builds will use dnf while everything else will use yum.
DNF should be default packager manager in Fedora 22, so I started thinking how it affects mock.
I have a notion, that after branching of Fedora 22 I will change
/etc/mock/fedora-rawhide-*.cfg
to use DNF by default. I.e. everything build for Fedora 23 would use DNF for building.
At the outset I thought that we use yum for older targets (epel-7, fedora-22..) indefinitely. Or to be precise until
those targets will be EOLed. But that would imply that yum have to be present in Fedora until Fedora 40 [1].
This is very unlikely to happen. More realistic expectation is that yum will disappear around Fedora 27 [2].
Which means that in Fedora 27 you either will be unable to build packages for epel-7 or you will have to use DNF.
This is quite distant future and we will try our best to make this transition as much flawless as possible.
I just want to make you aware in advance. Of course if you want to help, you are very welcome.
I expect that we will be building Fedora 22- always by yum due to short Fedora life cycle. Yum will be still present in
Fedora 24 for sure.
[1] https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates
[2] It’s Difficult to Make Predictions, Especially About the Future
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
8 years
Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
by Marek Polacek
To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek)
have performed a test mass rebuild of rawhide (January 15th package list)
using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from
the list packages that fail for non-GCC related reasons.
There were 16230 packages overall. 15303 packages built fine, 691 packages
failed to build with both gcc-5.0.0-0.5.fc22 and gcc-4.9.2-5.fc22 (ignored for
this analysis, unlikely to be GCC 5 related). That leaves us with 236 packages
that failed to build with GCC 5, but succeeded with GCC 4.9. These consist of
either package bugs, or GCC bugs. As things stand, just about 19 packages did
not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are fixed
at this time, and I promise I will fix the remaining one before long.
As usually, we will provide a "porting to" document to ease the transition to
the new GCC. This document is still in the works, yet it already contains
detailed description of the standard change for C; interested readers may visit
https://gcc.gnu.org/gcc-5/porting_to.html.
Main offender this time is probably the gnu11 change that entails different
inline semantics, enables some warnings by default, bumps the __STDC_VERSION__,
and so on. Hopefully it won't take too long till these packages catch on.
Many packages were not prepared for the new major version of GCC. There's also
been quite a lot of churn because of the preprocessor now emitting linemarkers
in the output when the -P option is not turned on. The C++ compiler now rejects
some code that it used to accept. Furthermore, GCC 5 has a batch of new warnings,
which, combined with -Werror, caused some additional failures.
The following is a more detailed list of what and why failed.
fcoe-utils-1.0.29-7.git9267509.fc22.src.rpm
gnome-disk-utility-3.14.0-1.fc22.src.rpm
lldpad-0.9.46-8.git48a5f38.fc22.src.rpm
udisks2-2.1.3-4.fc22.src.rpm
build failure due to -Werror; the -Wformat=2 option now enables
a new warning -Wformat-signedness, which warns about e.g.:
printf ("%d\n", 1U)
(%d expects argument of type int, but the argument has type
unsigned int).
dropwatch-1.4-10.fc22.src.rpm
build failure due to gnu11 change: glibc supports dynamic
allocation for string inputs via %a modifier, but in C99,
the %a modifier is a synonym for %f (float), so the compiler
expects an argument of type float *. The package should have
used the %m modifier, specified by POSIX.1-2008.
blktap-3.0.0-2.fc22.git0.9.2.src.rpm
cdrkit-1.1.11-26.fc22.src.rpm
cstream-3.1.1-3.fc22.src.rpm
dahdi-tools-2.10.0-2.fc22.src.rpm
dee-1.2.7-3.fc22.src.rpm
gdb-7.8.50.20150108-1.fc22.src.rpm
insight-7.8.50-2.20140827git.fc22.src.rpm
libomxil-bellagio-0.9.3-10.fc22.src.rpm
lmms-1.0.3-3.fc22.src.rpm
open-vm-tools-9.4.6-4.fc22.src.rpm
perl-Crypt-OpenSSL-X509-1.803-4.fc22.src.rpm
python-pyblock-0.53-8.fc22.src.rpm
sockperf-2.5.244-2.fc22.src.rpm
build failure due to -Werror; the new
-Wlogical-not-parentheses warning included in -Wall warns
(cases such as "if (!TYPE (t) == TYPE_FOO)").
glibc-2.20.90-17.fc22.src.rpm
build failure due to -Werror; -Waggressive-loop-optimizations
triggered during the testsuite run; this has already been fixed
upstream: https://sourceware.org/ml/libc-alpha/2015-01/msg00369.html
gtranslator-2.91.6-7.fc22.src.rpm
build failure due to -Werror; -Wmissing-include-dirs warning warns;
in 4.9 and earlier, the compiler ignored the -Werror option for
this warning, now it does not.
giada-0.7.0-5.fc22.src.rpm
build failure due to -Werror; -Wparentheses triggered; this warning
now works even in g++ on e.g.:
if (!i & 4)
...
ipv6calc-0.97.4-7.fc22.src.rpm
build failure due to -Werror; the new -Wsizeof-array-argument warns.
This warning detects e.g.:
int
foo (char a[8])
{
size_t s = sizeof (a);
...
}
where sizeof on the array function parameter will return a size of
char *, not a size of the array.
xen-4.4.1-12.fc22.src.rpm
build failure due to -Werror; -Wmaybe-uninitialized warns
about possibly uninitialized fields.
thewidgetfactory-0.2.1-20.fc22.src.rpm
build failure due to gnu11 change: missing declaration of strcmp.
tog-pegasus-2.13.0-19.fc22.src.rpm
build failure due to -Werror; here -Wunused-variable triggers
(unused const Uint32 PEGASUS_DYNAMIC_LEN(PEGASUS_DYNAMIC.size());
in a header file).
mongo-cxx-driver-1.0.0-0.7.rc3.fc22.src.rpm
build failure due to -Werror; the -Wunused-variable warning triggers
rcs-5.9.3-1.fc22.src.rpm
build failure due to wrong placement of _Noreturn, with -std=gnu89
it used __attribute__((__noreturn__)) instead, which is more flexible
in the placement (can go before or after the prototype, while
_Noreturn can only go before in function-specifiers).
argyllcms-1.6.3-4.fc22.src.rpm
libgphoto2-2.5.5.1-1.fc22.src.rpm
nogravity-2.00-22.fc22.src.rpm
these packages are not prepared for newer __STDC_VERSION__. Note
that with the gnu11 default __STDC_VERSION__ is defined to 201112L.
nogravity has:
#if !defined __STDC_VERSION__ || __STDC_VERSION__ < 199901L
...
#include <stdint.h>
...
and then
../../rlx32/src/v3xsoft.c:137:22: error: 'uintptr_t' undeclared
libgphoto2:
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
#define GP_LOG_DATA(DATA, SIZE) gp_log_data(__func__, DATA, SIZE)
#else
#define GP_LOG_DATA(DATA, SIZE) /* no-op */
then
gphoto2-port.c:390:2: error: called object is not a function or function pointer
argyllcms:
#if (__STDC_VERSION__ >= 199901L)
...
# define ATTRIBUTE_NORETURN __declspec(noreturn)
...
and then:
extern void ATTRIBUTE_NORETURN error(char *fmt, ...);
and that fails.
ekiga-4.0.1-15.fc22.src.rpm
opal-3.10.10-5.fc22.src.rpm
ptlib-2.10.10-8.fc22.src.rpm
these packages are trying to use <bits/atomicity.h>, but they should
use <ext/atomicity.h>. Probaby wrong __GNUC__ check.
firefox-35.0-1.fc22.src.rpm
icecat-31.2.0-6.fc22.src.rpm
kphotoalbum-4.5-4.fc22.src.rpm
thunderbird-lightning-3.3-5.fc22.src.rpm
these packages fail to build because they are trying to convert
std::nullptr_t to bool, and that requires direct-initialization.
The rules in C++11 have changed, cf.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423
So:
bool b = nullptr; // wrong
bool b2(nullptr); // ok
These packages should simply have used false/true instead.
steghide-0.5.1-24.fc22.src.rpm
build failed because the package uses deprecated <hash_set>.
methane-1.5.1-9.fc21.src.rpm
build error because the C++ compiler in the C++11 mode started to reject
invalid code with narrowing conversion of constants within { }. (This
change was deliberate.)
For instance:
signed char a { __INT_MAX__ };
is accepted by g++ 4.9, but rejected by g++ 5.
see http://gcc.gnu.org/r213776
elk-2.3.22-10.fc22.src.rpm
ape-2.2.0-2.fc22.src.rpm
netcdf-fortran-4.4.1-1.fc22.src.rpm
build error because the packages try to load a Fortran module created by
a different version of GNU Fortran.
nodejs-mapnik-vector-tile-0.6.1-1.fc22.src.rpm
build failure due to wrong check of the GCC version; it uses C++11 features
without specifying -std=c++11 or -std=gnu++11.
ogre-1.9.0-5.fc22.src.rpm
it's unclear yet whether the code in the package is valid or not; g++ started
to reject the code since http://gcc.gnu.org/PR20332
The error message is "forming pointer to reference type".
odb-2.3.0-8.fc22.src.rpm
build failure because the gcc plugin API has changed.
DevIL-1.7.8-20.fc22.src.rpm
libhugetlbfs-2.18-4.fc22.src.rpm
ax25-tools-0.0.10-0.9.rc2.fc22.src.rpm
espresso-ab-1.0-8.fc22.src.rpm
build failure due to gnu11 change: "restrict" is a keyword, so you can't have
variables with such a name, e.g.
int i, restrict;
compiles in the C90 mode, but fails in the C99 mode.
bigloo-4.1a-6.2.fc22.src.rpm
memstomp-0.1.4-15.fc22.src.rpm
build failure due to gnu11 change: -Wimplicit-int is turned on by default now,
which is the reason these packages didn't compile properly. See the porting_to
document for more details.
libcmpiutil-0.5.7-4.fc22.src.rpm
nfs-ganesha-2.1.0-12.fc22.src.rpm
fvkbd-0.2.2-10.fc22.src.rpm
build failure due to gnu11 change that entails different inline semantics;
inline function declared but never defined. See the porting_to document for
more details.
libvpx-1.3.0-6.fc22.src.rpm
xemacs-21.5.34-8.20140605hgacf1c26e3019.fc22.src.rpm
build failure due to gnu11 change: these packages are defining theirs own
max_align_t type. But in C11, this type is already defined in <stddef.h>,
which is a conflict and thus the compile-time error. The same is true for
C++11.
ocaml-cil-1.7.3-14.fc22.src.rpm
build failure due to gnu11 change: during the %check phase, several warnings
that are now enabled by default trigger.
xarchon-0.50-17.fc22.src.rpm
xmms-speex-0.9.1-21.src.rpm
netdump-server-0.7.16-37.fc22.src.rpm
ssbd-0.10-12.fc22.src.rpm
gccxml-0.9.0-0.25.20140718.gitab651a2.fc22.src.rpm
ustr-1.0.4-18.fc22.src.rpm
xmms-1.2.11-22.20071117cvs.fc22.src.rpm
spacechart-0.9.5-14.fc22.src.rpm
xdialog-2.3.1-15.fc22.src.rpm
siril-0.8-19.fc22.src.rpm
soundtracker-0.6.8-20.fc22.src.rpm
ircd-ratbox-2.2.9-3.fc22.src.rpm
libglade-0.17-33.fc22.src.rpm
librep-0.92.4-1.fc22.src.rpm
bubblemon-1.46-17.fc22.src.rpm
gcx-0.9.11-17.fc22.src.rpm
libnetdude-0.11-11.fc22.src.rpm
ghc-network-2.4.1.2-32.fc21.src.rpm
hunt-1.5-20.fc22.src.rpm
koules-1.4-18.fc22.src.rpm
xmms-scrobbler-0.4.0-15.fc22.src.rpm
hfsplusutils-1.0.4-21.fc22.src.rpm
glib-1.2.10-43.fc22.src.rpm
svgalib-1.9.25-16.fc22.src.rpm
memtest86+-5.01-8.fc22.src.rpm
xmms-crossfade-0.3.14-10.fc22.src.rpm
xmms-arts-0.7.1-16.src.rpm
imlib-1.9.15-26.fc22.src.rpm
manedit-1.2.1-11.fc22.src.rpm
xmms-lirc-1.4-21.src.rpm
xconvers-0.8.3-15.fc22.src.rpm
bird-1.4.5-1.fc22.src.rpm
hugs98-2006.09-20.fc22.src.rpm
libstroke-0.5.1-31.fc22.src.rpm
gtk+-1.2.10-80.fc22.src.rpm
Io-language-20131204-1.fc22.src.rpm
mtd-utils-1.5.1-3.fc22.src.rpm
ORBit-0.5.17-40.fc22.src.rpm
build failure due to gnu11 change that entails different inline semantics;
the multiple definition error. See the porting_to document for more details.
fusecompress-2.6-24.20120812gita65cc33.fc22.src.rpm
pion-net-4.0.9-15.fc22.src.rpm
aqsis-1.8.2-13.fc22.src.rpm
shiny-0.3-8.git411ac43.fc22.src.rpm
adobe-source-libraries-1.0.43-23.fc22.src.rpm
lucene++-3.0.6-1.fc22.src.rpm
dmlite-0.7.2-1.fc22.src.rpm
ceph-0.87-1.fc22.src.rpm
boost-1.55.0-7.fc22.src.rpm
ompl-1.0.0-1.fc22.src.rpm
openttd-1.4.4-1.fc22.src.rpm
these packages failed because of errors such as the following:
error: no matching function for call to 'call_once(boost::once_flag&, void (*&)())'
The bug here was on the boost side I think, where boost code didn't cope with C++11
well, but it seems to be already fixed, thus these packages should build fine now.
shim-0.8-1.fc22.src.rpm
gummiboot-46-1.fc22.src.rpm
these packages failed to build, because they are using the -nostdinc option (don't
search header files in the standard directories), yet with gnu11 default they are
trying to include the <stdint.h> header.
cmocka-0.4.1-3.fc22.src.rpm
gmqcc-0.3.5-6.fc22.src.rpm
libssh-0.6.4-1.fc22.src.rpm
mirall-1.7.0-1.fc22.src.rpm
intrace-1.5-6.fc22.src.rpm
build error because of -pedantic-errors: gcc 5 has a new warning that warns
about GNU predefined identifiers, such as __FUNCTION__, if a -Wpedantic option
is specified. C99 supports the __func__ predefined identifier, so the packages
can use that, or add the __extension__ keyword where desirable.
llvm-3.5.0-6.fc22.src.rpm
this was a bug in LLVM sources; it's been already fixed in:
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/Intrusive...
yap-6.2.2-12.fc22.src.rpm
a bug in the package - fails since http://gcc.gnu.org/PR59366
Here, a friend function template defined in a class was found without ADL.
undertaker-1.6.1-1.fc22.src.rpm
g++ has (wrongly) accepted an invalid code, this has been fixed by http://gcc.gnu.org/PR60463
python3-3.4.2-3.fc22.src.rpm
build started failing with http://gcc.gnu.org/PR60517
The code has an undefined behavior (returning address of a local variable); it
tried to perform a stack overflow, but the compiler turned the code via tail recursion
optimization into an endless loop.
cclive-0.9.3-4.fc22.src.rpm
cvc4-1.3-7.fc22.src.rpm
dans-gdal-scripts-0.23-5.fc22.src.rpm
emacs-24.4-3.fc22.src.rpm
ember-0.7.2-3.fc22.src.rpm
flamerobin-0.9.3-8.20130401snap.fc22.src.rpm
ghc-gtk-0.12.5.0-3.fc22.src.rpm
ghc-webkit-0.12.5.1-3.fc22.src.rpm
gnote-3.14.0-1.fc22.src.rpm
ksh-20120801-21.fc22.src.rpm
libason-0.1.2-2.fc22.src.rpm
libcmis-0.5.0-1.fc22.src.rpm
libgpg-error-1.16-1.fc22.src.rpm
libixion-0.7.0-3.fc22.src.rpm
liborcus-0.7.0-5.fc22.src.rpm
ncurses-5.9-17.20140906.fc22.src.rpm
openldap-2.4.40-5.fc22.src.rpm
perl-5.20.1-315.fc22.src.rpm
xorg-x11-server-1.16.2.901-1.fc22.src.rpm
xorg-x11-server-utils-7.7-10.fc22.src.rpm
zsh-5.0.7-4.fc22.src.rpm
these packages failed to build because of the changes in the preprocessor;
gcc started to generate line directives to better detect whether a macro
tokens come from a system header - see http://gcc.gnu.org/PR60723
The fix is to use the -P option if the code isn't prepared to deal with
such directives.
guitarix-0.32.0-1.fc22.src.rpm
gcc bug - libstdc++ had __attribute__((always_inline)) instead
of __always_inline__.
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/r220243
spatialindex-1.8.1-3.fc22.src.rpm
gcc bug - internal compiler error in devirtualization
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64538
abrt-java-connector-1.1.0-3.fc22.src.rpm
libldm-0.2.3-7.fc22.src.rpm
gcc bug - bogus -Wmissing-fields-initializers
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64709
telepathy-salut-0.8.1-7.fc22.src.rpm
gcc bug - a bug in byte swap optimizations
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64718
bash-4.3.33-1.fc22.src.rpm
openvpn-2.3.6-1.fc22.src.rpm
pymol-1.7.4-1.20141207svn4104.fc22.src.rpm
gcc bug - internal compiler error in the uninit pass
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64764
davix-0.4.0-1.fc22.src.rpm
gazebo-4.0.2-1.fc22.src.rpm
gmock-1.7.0-1.fc22.src.rpm
gtest-1.7.0-2.fc22.src.rpm
java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.src.rpm
llvm34-3.4.2-5.fc22.src.rpm
redeclipse-1.4-8.fc22.src.rpm
gcc bug - wrong expansion of the __LINE__ macro
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64803
zorba-3.0.0-10.20140621git152f8964c.fc22.src.rpm
gcc bug - a wrong code issue
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64853
criu-1.4-1.fc22.src.rpm
gcc bug - rejects valid code in C99 mode ([X ... Y] style initialization,
a GNU extension).
not fixed yet, http://gcc.gnu.org/PR64856
nntpgrab-0.7.2-9.fc22.src.rpm
gcc bug - a wrong code in FSM jump threading
a fix has been posted upstream, fixed in gcc-5.0.0-0.7.fc22
see http://gcc.gnu.org/PR64878
gnucap-0.35-14.fc22.src.rpm
gcc bug - wrong code due to bug in IPA propagation
fixed upstream and in gcc-5.0.0-0.7.fc22, http://gcc.gnu.org/PR64922
apron-0.9.10-23.fc22.src.rpm
L-function-1.23-12.fc22.src.rpm
mbox2eml-0.1.1-23.fc22.src.rpm
ppl-1.1-6.fc22.src.rpm
build error because g++ started to reject invalid code to reflect the
C++ DR217 (default arguments in function templates in redeclarations).
see http://gcc.gnu.org/PR15339
xiphos-4.0.0-3.fc22.src.rpm
this package failed to build because the limit of the instantiation depth
has been reached.
abook-0.6.0-0.15.20140116git5840fce.fc22.src.rpm
autofs-5.1.0-9.fc22.src.rpm
bandwidthd-2.0.1-27.fc22.src.rpm
bcache-tools-1.0.8-1.fc22.src.rpm
bfast-0.7.0a-10.fc22.src.rpm
bwm-ng-0.6-16.fc22.src.rpm
cdogs-sdl-0.4-14.fc22.src.rpm
covered-0.7.10-5.fc22.src.rpm
crm114-0-8.14.20100106.fc22.src.rpm
ebview-0.3.6.2-14.fc22.src.rpm
eggdrop-1.6.21-8.fc22.src.rpm
fbzx-2.10.0-5.fc22.src.rpm
garden-1.0.8-12.fc22.src.rpm
gcc-4.9.2-5.fc22.src.rpm
gfal2-2.7.8-3.fc22.src.rpm
gloox-1.0.10-4.fc22.src.rpm
gnaural-1.0.20110606-3.fc22.src.rpm
gnokii-0.6.31-10.fc22.src.rpm
gsmartcontrol-0.8.7-6.fc22.src.rpm
GtkAda-2.24.2-12.fc22.src.rpm
gtk+extra-2.1.2-15.fc22.src.rpm
isdn4k-utils-3.2-99.fc22.src.rpm
jack-audio-connection-kit-1.9.10-1.fc22.src.rpm
jfbterm-0.4.7-31.fc22.src.rpm
kmplayer-0.11.3c-7.fc22.src.rpm
libesedb-20120102-7.fc22.src.rpm
libewf-20140608-1.fc22.src.rpm
lpairs-1.0.4-14.fc22.src.rpm
mapserver-6.2.2-1.fc22.src.rpm
meterbridge-0.9.2-11.fc22.src.rpm
mingw-nsis-2.46-13.fc22.src.rpm
mirrormagic-2.0.2-16.fc22.src.rpm
mona-1.4r15-4.fc22.src.rpm
mono-2.10.8-7.fc21.src.rpm
muffin-2.4.2-1.fc22.src.rpm
nebula-0.2.3-10.fc22.src.rpm
oidentd-2.0.8-15.fc22.src.rpm
overgod-1.0-21.fc22.src.rpm
pads-1.2-16.fc22.src.rpm
php-pecl-memcache-3.0.8-6.fc22.src.rpm
python-dmidecode-3.10.13-12.fc22.src.rpm
qt-4.8.6-18.fc22.src.rpm
ratbox-services-1.2.1-11.fc21.src.rpm
reiserfs-utils-3.6.21-11.fc22.src.rpm
sblim-sfcb-1.4.9-1.fc22.src.rpm
sigar-1.6.5-0.12.git58097d9.fc22.src.rpm
sipsak-0.9.6-18.fc22.src.rpm
soundmodem-0.18-3.fc22.src.rpm
tcpick-0.2.1-24.fc22.src.rpm
teeworlds-0.6.3-1.fc22.src.rpm
trousers-0.3.13-3.fc22.src.rpm
udftools-1.0.0b3-28.fc22.src.rpm
unicornscan-0.4.7-9.fc22.src.rpm
vtun-3.0.3-11.fc22.src.rpm
weplab-0.1.5-15.fc22.src.rpm
wmmon-1.0-0.1.b2.20120606git575778a6.fc22.5.src.rpm
yad-0.27.0-1.fc22.src.rpm
build failure due to gnu11 change that entails different inline semantics;
an undefined reference to a function. See the porting_to document for more
details.
avarice-2.12-7.fc22.src.rpm
fawkes-0.5.0-19.fc22.src.rpm
fdm-1.7-5.fc22.src.rpm
libpuma-1.2-3.fc22.src.rpm
masscan-1.0.3-2.fc22.src.rpm
ncbi-blast+-2.2.30-1.fc22.src.rpm
nifti2dicom-0.4.9-1.fc22.src.rpm
ocp-0.1.20-9.fc22.2.src.rpm
root-5.34.24-1.fc22.src.rpm
trafficserver-5.0.1-1.fc22.src.rpm
uboot-tools-2015.01-0.2.rc3.fc22.src.rpm
vxl-1.17.0-15.fc22.src.rpm
webkitgtk-2.4.8-1.fc22.src.rpm
these packages are not prepared for gcc's version 5. E.g. fdm has:
ifeq ($(shell (LC_ALL=C $(CC) -v 2>&1|awk '/gcc version 4/') || true), )
CPPFLAGS:= -I. -I- $(CPPFLAGS)
else
CPPFLAGS:= -iquote. $(CPPFLAGS)
endif
but the gcc version is not 4 anymore -> the -iquote option isn't used,
so an error occurs later on.
HepMC-2.06.09-7.fc22.src.rpm
this one is not really clear, but the output of a program in the testsuite
was in a floating-point notation rather than in a decimal notation, hence
the test failed.
appstream-0.7.3-1.fc22.src.rpm
baloo-4.14.3-1.fc22.src.rpm
notmuch-0.19-1.fc22.src.rpm
perl-Search-Xapian-1.2.19.0-1.fc22.src.rpm
recoll-1.20.1-1.fc22.src.rpm
xapian-bindings-1.2.19-1.fc22.src.rpm
zeitgeist-0.9.16-0.3.20140808.git.ce9affa.fc22.src.rpm
these packages failed to build since they are using the Xapian library, which
has been built with gcc 4.9, but they expect it to be compiled with gcc 5.
Marek
8 years
RE: Hardened builds
by Mamoru TASAKA
Hello:
> I've got a package that is currently failing to build in Rawhide. It
> has a home-brewed garbage collector inside, and it appears the GC is
> confused about which objects are on the stack, and which are on the
> heap. I want to try building without the hardening flags to see if
> that has something to do with the problem. According to
> https://fedorahosted.org/fesco/ticket/1384 the way to do this is to
> put:
>
> %global _hardened_build 0
>
> at the top of the spec file. But that doesn't work with a local mock
> build. I still see -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 in
> the compiler flags and -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> in the linker flags.
Does
%undefine _hardened_build
help?
Regards,
Mamoru
8 years
Hardened builds
by Jerry James
I've got a package that is currently failing to build in Rawhide. It
has a home-brewed garbage collector inside, and it appears the GC is
confused about which objects are on the stack, and which are on the
heap. I want to try building without the hardening flags to see if
that has something to do with the problem. According to
https://fedorahosted.org/fesco/ticket/1384 the way to do this is to
put:
%global _hardened_build 0
at the top of the spec file. But that doesn't work with a local mock
build. I still see -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 in
the compiler flags and -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
in the linker flags. So I tried adding the lines:
%global _hardened_cflags %{nil}
%global _hardened_ldflags %{nil}
just below the _hardened_build line. Now mock explodes:
Traceback (most recent call last):
File "/usr/sbin/mock", line 829, in <module>
main()
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/sbin/mock", line 650, in main
run_command(options, args, config_opts, commands, buildroot, state)
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/sbin/mock", line 725, in run_command
do_rebuild(config_opts, commands, buildroot, args)
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/sbin/mock", line 496, in do_rebuild
post=post_build, clean=clean)
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/sbin/mock", line 440, in rebuild_generic
commands.init(prebuild=not config_opts.get('short_circuit'))
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/backend.py", line
122, in init
self.buildroot.initialize(**kwargs)
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/buildroot.py", line
80, in initialize
self._init(prebuild=prebuild, do_log=do_log)
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/buildroot.py", line
117, in _init
self.plugins.call_hooks('preinit')
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/plugin.py", line
65, in call_hooks
hook(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/plugins/ccache.py",
line 60, in _ccachePreInitHook
self.buildroot.uid_manager.changeOwner(self.ccachePath, recursive=True)
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 84, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/uid.py", line 84,
in changeOwner
os.chown(os.path.join(root, f), uid, gid)
OSError: [Errno 2] No such file or directory:
'/var/cache/mock/fedora-rawhide-x86_64/ccache/u1000/9/stats.lock'
How is this really supposed to be done? If I'm doing it the right
way, then the current method is broken.
Also, http://fedoraproject.org/wiki/Hardened_Packages seems to be
entirely useless at this point. Perhaps it could be replaced with a
page that discusses the current state of the hardening flags.
Thank you,
--
Jerry James
http://www.jamezone.org/
8 years
Packagers: incomplete Obsoletes and undead packages
by Michael Schwendt
This is about Rawhide.
The list for F21 is similar, which is especially strange with regard to
any packages that should be marked as dead in dist git already then.
"Dead" = a dead.package file in dist git exists, but builds of the package
are still found in the repo(s). Package has not been retired fully yet.
"Undead" = no dead.package file in dist git found.
"Only obsolete subpackages" = non-trivial, but for some of those cases
there are really some missing Obsoletes tags and an incomplete set of
builds is left in the repo (e.g. a -devel subpkg but its base pkg is
obsoleted).
[...]
Dead and all builds obsoleted:
------------------------------
drwright
obsoleted by: gnome-settings-daemon
python-twisted-conch
obsoleted by: python-twisted
python-twisted-lore
obsoleted by: python-twisted
python-twisted-mail
obsoleted by: python-twisted
python-twisted-names
obsoleted by: python-twisted
python-twisted-news
obsoleted by: python-twisted
python-twisted-runner
obsoleted by: python-twisted
python-twisted-web2
obsoleted by: python-twisted
python-twisted-words
obsoleted by: python-twisted
qca2
obsoleted by: qca
Undead and all builds obsoleted:
--------------------------------
golang-launchpad-gocheck
obsoleted by: golang-gopkg-check
kopete-cryptography
obsoleted by: kopete
kwallet
obsoleted by: kwalletmanager
lxshortcut
obsoleted by: libfm
mate-dialogs
obsoleted by: mate-desktop
min-metadata-service
obsoleted by: min-cloud-agent
openstack-marconi
obsoleted by: openstack-zaqar
php-channel-deepend
obsoleted by: php-deepend-Mockery
php-channel-symfony2
obsoleted by: php-symfony
php-symfony-icu
obsoleted by: php-symfony
python-XStatic-Angular-Cookies
obsoleted by: python-XStatic-Angular
superiotool
obsoleted by: coreboot-utils
xorg-x11-glamor
obsoleted by: xorg-x11-server
zeroinstall-injector
obsoleted by: 0install
Only obsolete subpackage(s):
----------------------------
kactivities ['kactivities'] 4 left
obsoleted by: kf5-kactivities
left: kactivities-devel
left: kactivities-libs
left: kactivities-nepomuk
left: kactivities-nepomuk-devel
mmdb ['mmdb'] 1 left
obsoleted by: mmdb2
left: mmdb-devel
python-twisted-core ['python-twisted-core'] 1 left
obsoleted by: python-twisted
left: python-twisted-core-doc
razorqt ['razorqt-notifications'] 22 left
obsoleted by: lxqt-notificationd
left: lightdm-razorqt
left: razorqt
left: razorqt-about
left: razorqt-appswitcher
left: razorqt-autosuspend
left: razorqt-config
left: razorqt-data
left: razorqt-desktop
left: razorqt-globalkeyshortcuts
left: razorqt-libs
left: razorqt-libs-devel
left: razorqt-openssh-askpass
left: razorqt-panel
left: razorqt-policykit-agent
left: razorqt-power
left: razorqt-runner
left: razorqt-session
left: razorqt-theme-ambiance
left: razorqt-theme-amego
left: razorqt-theme-green
left: razorqt-theme-light
left: razorqt-themes
ruby-gnome2 ['ruby-gtksourceview2', 'ruby-gtksourceview2-devel'] 24 left
obsoleted by: rubygem-gtksourceview2
left: ruby-bonobo2
left: ruby-bonobo2-devel
left: ruby-bonoboui2
left: ruby-bonoboui2-devel
left: ruby-gconf2
left: ruby-gconf2-devel
left: ruby-gnome2
left: ruby-gnome2-devel
left: ruby-gnomecanvas2
left: ruby-gnomecanvas2-devel
left: ruby-gnomeprint2
left: ruby-gnomeprint2-devel
left: ruby-gnomeprintui2
left: ruby-gnomeprintui2-devel
left: ruby-gnomevfs
left: ruby-gnomevfs-devel
left: ruby-gtkglext
left: ruby-gtkglext-devel
left: ruby-gtksourceview
left: ruby-gtksourceview-devel
left: ruby-libart2
left: ruby-libart2-devel
left: ruby-libglade2
left: ruby-libglade2-devel
8 years
