mock log output has DOS line endings?
by Richard Shaw
Am I the only one having this problem? I don't know exactly when it started
but all of a sudden all of the log output has DOS line endings and it's
very annoying. I have to run dox2unix on the logs to make them readable.
Thanks,
Richard
4 years, 3 months
Ideas for better development processes when maintaining hundreds of
packages
by Richard W.M. Jones
I always think that Fedora works fine if you maintain 1-5 packages.
It's possible to maintain 20 with a lot of work. And if you want to
maintain 100+ (things like the ocaml-* set that I help to maintain)
then you have to write your own automation. Could we do things
better? No one asked for them, but here are my ideas ...
---
* kill the %changelog
Please, let's kill it, and generate it from the git changelog.
I'm glad to see there's a proposal to do this.
A general principle I'm following here is a packager should never
be asked to enter the same information twice.
* committing to git should build the package
Is there a reason why this wouldn't be the case?
* commit groups of packages together
One reason why automatic commit -> build might not be desirable is if
you're trying to build a group of packages in a side tag. In my
opinion this means we should allow groups of packages to be committed
together. (Unfortunately because we chose to put every package in its
own git repo, the obvious way to do this can't work, but we could
still have a "ChangeId:" header in the commit message that ties
packages together).
The packages should be built in build dependency order into a side
tag, and the side tag turned into an update, with no further
involvement from the packager unless something fails to build.
This change on its own would solve the main problem that
affects people maintaining large sets of packages.
* “Fixes:” etc headers in git
RHEL already does this. It should be possible to add special headers
to the commit message to automatically close bugs, ie:
$ git commit -m "ocaml: Update to version 4.10.0
Fixes: RHBZ#12345"
Note the build, update and bug closing would happen completely
automatically, assuming there was no build or test failure.
* CVE bugs should autoclose when a package is rebased
Fabiano built the mingw-openssl package recently, but there are still
a load of open CVE bugs against this package referring to the older
version. These should be closed automatically. I think this will
require collecting the version of the package that fixes a CVE and
recording that in Bugzilla (or in the package itself in some standard
way).
* create streams of packages automatically depending on quality scores
We know a lot about packages such as:
- How many bugs are opened against them?
- What's the average time between a bug being filed and fixed?
- Do they get regularly updated?
- Do they pass or fail CI tests?
- How many rpmlint / fedora-packager problems do they have?
Why don't we use that data to build streams of high quality and lesser
quality packages? Allow the end users to choose whether they want the
best curated packages only, or they're prepared to accept the risk of
taking a package with lots of bugs or CVEs (this is assuming the
previous point is fixed, so these are real CVEs, not irrelevant bugs).
If you want to go even further with this idea, then it could even be
possible we allow packages into Fedora without any review. They would
start in the outermost stream in a "there be dragons" repository that
only the foolhardy would enable, but as their quality improved they
would *automatically* migrate into the mainstream.
---
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
4 years, 3 months
gcc 10: Default to -fno-common, multiple definitions of ...
by Miro Hrončok
Hello,
we try to rebuild all Python packages against Python 3.9 and report the
failures. I've seen several similar failures in a row now that can be reproduced
in Fedora rawhide with the new gcc version.
ld errors on multiple definitions of ..., for example:
ld:
tests/bp_account.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/perf/tests/bp_account.c:22:
multiple definition of `the_var';
tests/bp_signal.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/perf/tests/bp_signal.c:38:
first defined here
This is a known thing in gcc 10:
https://gcc.gnu.org/gcc-10/porting_to.html#common
"Default to -fno-common
A common mistake in C is omitting extern when declaring a global variable in a
header file. If the header is included by several files it results in multiple
definitions of the same variable. In previous GCC versions this error is
ignored. GCC 10 defaults to -fno-common, which means a linker error will now be
reported. To fix this, use extern in header files when declaring global
variables, and ensure each global is defined in exactly one C file. As a
workaround, legacy C code can be compiled with -fcommon.
int x; // tentative definition - avoid in header files
extern int y; // correct declaration in a header file"
Here are some packages affected:
nemo-extensions
https://bugzilla.redhat.com/show_bug.cgi?id=1793470
thunarx-python
https://src.fedoraproject.org/rpms/thunarx-python/pull-request/1
kernel-tools
https://bugzilla.redhat.com/show_bug.cgi?id=1793473
https://bugzilla.redhat.com/show_bug.cgi?id=1793424
gnome-abrt, glusterfs...
Before I go and file dozens of bugzillas, do we want to handle this somehow better?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 3 months
New mingw-nsis package apparent breakage
by Richard W.M. Jones
Hello Sandro,
mingw-nsis failed to build in the F32 mass rebuild, so I have updated
the package to the latest version and fixed quite a few problems.
It now builds, but there are some seemingly serious problems with the
resulting package which make me reluctant to want to push anything to
Rawhide dist-git. Instead I pushed my changes to a private branch so
you can play with them:
https://src.fedoraproject.org/rpms/mingw-nsis/commits/private-rjones-nsis305
(1) No debuginfo is built.
If debuginfo is enabled, the build fails with:
error: Empty %files file /home/rjones/d/fedora/mingw-nsis/master/nsis-3.05-src/debugsourcefiles.list
I haven't changed anything about debuginfo, so I'm not clear how
my changes caused this to happen.
(2) More seriously, some files are missing compared to the 3.04 package.
There is no /etc/nsisconf.nsh file, no /usr/bin/GenPat, and no
/usr/bin/makensis (without the .exe extension).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
4 years, 3 months