Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok
Recently I've reported some Big Endian related test failures to an
upstream project [0].
I was asked by an upstream project maintainer, whether I know some free
Continuous Integration services where they can easily run their
testsuite on Big Endian.
Any tips?
* Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
* Upstream uses AppVeyor to test on Microsoft Windows
* It's a pure Python project, noarch, but some changes need to be done
when loading/saving binary data (LE) with NumPy on BE system.
What I've considered:
* COPR (but there is no big endian arch)
* (Ab)using Koji (I guess that would be considered a bad practice?)
* using QUEMU on Travis CI [1]
Any better tips? Thanks
[0] https://github.com/mikedh/trimesh/issues/249
[1]
https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architectu...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 months, 4 weeks
Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file,
breaking almost everything
by Hans de Goede
Hi All,
Just a quick headsup for users following Fedora 29, the
dbus 1.12.10-1.fc29 build is missing the systemd dbus.service
file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the
dbus.socket file expects a matching dbus.service, not
dbus-daemon.service.
So either hold of on applying updates until this is fixed
or exclude dbus.
Regards,
Hans
11 months, 3 weeks
Use immutable CRAN URLs
by Iñaki Ucar
Hi,
Currently, most of the R packages included in Fedora use the following
lines in the SPEC:
URL: https://cran.r-project.org/web/packages/%{packname}/
Source0: https://cran.r-project.org/src/contrib/%{packname}_%{version}.tar.gz
This URL format is not recommended by CRAN, but more importantly, the
Source0 format does not work anymore, as [1] noted, when a new version
is released. However, there is an immutable format available, as [2]
pointed out. So my proposal is to use always the following lines
instead:
URL: https://cran.r-project.org/package=%{packname}
Source0: %{url}&version=%{version}
which are both shorter and immutable, and I propose to add this to the
R packaging guidelines too.
If we agree on this, is there any easy way to request a system-wide
change like that to all existing packages?
Regards,
--
Iñaki Ucar
[1] https://stat.ethz.ch/pipermail/r-devel/2018-October/076988.html
[2] https://stat.ethz.ch/pipermail/r-devel/2018-October/076989.html
1 year, 8 months
glibc-arm-linux-gnu help
by Tom Callaway
A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could
have a packaged arm cross-toolchain that was useful (with glibc, it
cannot build anything in userspace). It worked for a while, but lately,
all builds have been failing with this error:
/usr/bin/arm-linux-gnu-ld: skipping incompatible
/usr/lib/gcc/arm-linux-gnueabi/8/libgcc_eh.a when searching for -lgcc_eh
I've looked at it and poked it quite a bit locally, but I can't seem to
get around that. I could really use some help to get this building
again, ideally, updated to 2.28.
All my work is committed to git, no help will be refused.
Thanks in advance,
~tom
2 years, 1 month
