Is Kalpa Welivitigoda still active at maintaining packages?
by Iiro Laiho
Hi,
I am asking if anyone knows anything about the whereabouts of Fedora developer Kalpa Welivitigoda? He is the maintainer of unetbootin package. Bug 1229874 would need fixing, but it seems that he is not responding to the bug comments anymore. I tried to ask him about that matter via Facebook as well last Tuesday, but he doesn't seem to respond there either.
– Iiro Laiho
4 years, 1 month
Weak password madness is back again
by Hans de Goede
Hi,
So 2 devel cycles ago we had this whole discussion
about how forcing people to choose strong passwords in anaconda
was making live hard for testers / test-installs and this
decision was reverted.
So now here I'm doing a F25 Fedora ARM test install, end up
in the gnome-ified first-time-setup wizzard and cannot continue
until I make my test-user password strong enough. UGH.
So can we get this fixed please, or do we need to escalate
this all the way up to FESco again ?
Regards,
Hans
4 years, 3 months
RFC: static builds for user emulators in Fedora QEMU RPMs
by Daniel P. Berrange
For those who aren't familiar, QEMU actually provides two completely
different sets of emulators
- system emulators - they emulate a full virtual machine and thus run
a full guest OS.
- user emulators - they emulate the Linux userspace ABI letting you
run non-native arch executables directly.
The user emulators are what I'm concerned with in this mail, so ignore
the system emulators.
Currently all the user emulators are provided in the "qemu-user" RPM
which also includes files in /usr/lib/binfmt.d to register each emulator
binary as a binary format handler for its respective architecture.
This is ok if you have a non-native arch binary that's statically linked
and you just want to run it from context of your main OS root filesystem.
Running dynamic linked binaries won't fly because if say running an arm
binary on x86_64 host, it'll look for /lib/libc.so and find the i386 one,
instead of the arm one. You can't set LD_LIBRARY_PATH to override this
as the env var will apply to both qemu-arm (an x86_64 binary) and the
binary it is trying to run (an arm binary).
More typical though is that you have a directory containing an fullish
install tree of a non-native architecture and you just want to chroot
into that. When doing such a chroot, the qemu-$ARCH emulator must be
present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
So again you have the potential problem of clashing libc.so in /usr/lib
It is a shame Fedora doesn't have full multi-arch support, instead of
merely multi-lib to avoid these clashing lib dirs across architecture
RPMs.
The recommended way to deal with this for the qemu user emulator binaries
to be statically linked, so when copied inside the non-native arch chroot,
they never need to resolve any native arch libraries. Fedora's qemu user
binaries are all dynamic linked right now.
Debian handles this by having several packages [1]
- qemu-user - the dynamic linked qemu user binaries
- qemu-binfmt - binfmt rules registering the dynamic linked binaries
- qemu-user-static - the static linked qemu user binaries *and* binfmt
rules to register them. The static binaries all
have -static suffix on their name
NB, this means qemu-binfmt and qemu-user-static are mutually exclusive
since they both provide the same binfmt files. You can however have both
qemu-user and qemu-user-static installed as their binary names won't
clash, and in this case the static ones will be registered as binfmts
This nice thing about this multiple package approach is that when you
copied the x86_64 build of the "qemu-arm-static" binary into your arm
chroot, you still then have the possibility of installing the arm build
of the "qemu-arm" binary inside that chroot without filename clash.
An alternative simpler approach would be to just have one package,
qemu-user, which contains the static binaries and never ship any
dynamic linked qemu user binaries. This is slightly more restrictive
though, as explained in the previous paragraph, so I'd like to avoid
doing that.
I'd like to make using non-native arch chroots simple with Fedora without
people needing to manually build their own static QEMU binaries, or download
static binaries provided by another distro[2]. So I'm suggesting to make a
change to Fedora qemu packages to essentially copy the way Debian has done
things. Specifically I will
- Pull the binfmt registration files out of qemu-user and into a
new qemu-binfmt package which depends on qemu-user.
- Add static builds of qemu user emulators to a new qemu-user-static
package, along with binfmt registration files
The static build of QEMU user emulators is moderately light on
dependancies, only requiring glib2-static, pcre-static, zlib-static
and glibc-static packages.
The change to introduce a qemu-binfmt package has small upgrade
implications since anyone with qemu-user installed today, will loose
the binary format rules unless they manually install qemu-binfmt. I
think the number of people affected is probably quite small, and some
of them may well wish to use qemu-user-static instead anyway.
Obviously this would only be done in rawhide, not any existing stable
releases of Fedora.
Nothing will change about the rest of QEMU packaging - ie all system
emulators will continue to use dynamic linking
Regards,
Daniel
[1] https://wiki.debian.org/QemuUserEmulation
[2] https://rwmj.wordpress.com/2013/12/22/how-to-run-aarch64-binaries-on-an-x...
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
4 years, 3 months
BuildRequires on obsoleted packages provided by Python
by Charalampos Stratakis
Hello all,
While checking out the SPEC file of python, it seems there were some packages that, while separate at some point, they got included in python's stdlib and then obsoleted as standalone packages (thus to cope with the change, python was obsoleting these packages and providing them as well in the SPEC). So every package that currently (Build)Requires any of these packages will essentially drag python with it.
I will remove these provides soon, since the packages were orphaned long time ago, but the packages that still require them, will need to be fixed and (Build)Require python instead.
Here is a github commit with these changes from a testing repo:
https://github.com/fedora-python/python2-spec/commit/dfdd96e653d65ce68359...
And a list of the provided packages and the affected ones
Distutils: None
python-sqlite:
cas
yum
python-ctypes:
drobo-utils
glusterfs-extra-xlators
glusterfs-geo-replication
python-smbios
python-hashlib:
pyrpkg
python-uuid:
dpm-server-mysql
oz
python2-celery
python-argparse:
R2spec
catkin
diskimage-builder
euca2ools
fedora-review
feedstail
gfal2-util
glacier-cli
grin
hash-slinger
imagefactory
instack
libstoragemgmt
nordugrid-arc-nagios-plugins
os-apply-config
os-cloud-confic
os-collect-confic
os-net-config
pyrpkg
python-amqpclt
python-catkin_pkg
python-catkin_tools
python-cloudservers
python-gear
python-novaclient
python-postman
python-requestbuilder
python-rosdistro
python-rospkg
python-sparklines
python2-oslo-config
repo_manager
rpkg
vdsm
Depending on feedback here I will follow (or not) the mass bug filling procedure so maintainer fix their packages.
The reasoning behind this change, at the current time, is that I intent to rename python to python2 soon, which will lead to a re-review of python, so at the moment trying to have things as clear and consistent as possible. Plans for that change is only for rawhide (although it would be nice for f25 as well).
Regards,
Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat
4 years, 3 months
HEADS UP: eigen-3.3.0 update
by Sandro Mani
Hi
eigen-3.3.0 was released a a couple of weeks ago, and I've investigated
the consequences of updating in rawhide in this [1] COPR repo. The
detailed analysis is below, the summary is:
- five dependent packages fail to build due to the eigen3 update:
avogadro, ceres-solver, kalzium, shogun and tapkee
- of these, ceres-solver, shogun and tapkee can be fixed by upgrading to
newer versions (first two) or backporting upstream fixes (tapkee)
- (The shogun update needs viennacl which is stalled in review [2])
- avogadro relies on the eigen-2.x compatibility which was removed in
eigen-3.3, and there is not progress upstream so far in resolving the issue.
- kalzium fails due to the avogadro dependency
My plan is to proceed with the eigen3 update, simultaneously updating
ceres-solver and shogun in coordination with the respective maintainers,
while shipping a bundled copy of the previous eigen-3.2.10 with avogadro
until upstream manages to port to eigen-3.3.
Rich Mattes is ready to update ceres-solver and can handle the rebuild
of all other packages. So the remaining input I need is from the shogun
and avogadro maintainers to coordinate the update. I'm happy to help
with bundling eigen for avogadro if desired.
Thanks
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/eigen3.3.0/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1289717
Detailed analysis:
Eigen related failures
----------------------
avogadro-0:1.2.0-2.fc26.src
-> #error Eigen2-support is only available up to version 3.2. Please go
to "http://eigen.tuxfamily.org/index.php?title=Eigen2" for further
information
-> https://github.com/cryos/avogadro/issues/842, looks stalled
ceres-solver-0:1.11.0-9.fc26.src
-> error: no type named 'Literal' in 'struct
Eigen::NumTraits<ceres::Jet<double, 9> >'
-> fixed in 1.12.0rc1
kalzium-0:16.08.2-3.fc26.src
-> failure in avogadro
-> #error Eigen2-support is only available up to version 3.2. Please go
to "http://eigen.tuxfamily.org/index.php?title=Eigen2" for further
information
shogun-0:4.1.0-5.fc25.src
-> failure in tapkee header (see below)
-> error: no type named 'ReturnType' in 'struct
Eigen::ScalarBinaryOpTraits<bool, double,
Eigen::internal::scalar_product_op<bool, double> >'
-> fixed in 5.0.0 +
https://github.com/shogun-toolbox/shogun/commit/ab6b067017a18712d6b35d183...
tapkee-0:1.0-6.fc24.src
-> error: static assertion failed:
THIS_EXPRESSION_IS_NOT_A_LVALUE__IT_IS_READ_ONLY
-> https://github.com/lisitsyn/tapkee/issues/29
->
https://github.com/lisitsyn/tapkee/commit/7c74473d12809e4122527b6e003c74a...
Unrelated failures
------------------
csound-0:6.03.2-11.fc25.src
-> File not found:
/builddir/build/BUILDROOT/csound-6.03.2-11.fc26.x86_64/usr/lib64/csound/plugins-6.0/libLuaCsound.so
-> File not found:
/builddir/build/BUILDROOT/csound-6.03.2-11.fc26.x86_64/usr/lib64/lua/5.3/*
fawkes-0:0.5.0-30.fc25.src
-> error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot
be defined
guitarix-0:0.35.0-2.fc25.src
-> error: no match for 'operator!=' (operand types are
'Glib::RefPtr<Gio::FileInfo>' and 'int')
krita-0:3.0.1.1-1.fc26.src
-> error: reference to 'half' is ambiguous
-> OpenEXR related
scilab-0:6.0.0-0.7.beta2.fc25.src
-> error: File "stringLexer.mll", line 25, characters 5-17: Error:
Unbound module StringParser
Build successfully
------------------
analitza-0:16.08.2-1.fc26.src
calligra-0:2.9.11-11.fc26.src
digikam-0:5.2.0-1.fc26.src
freecad-1:0.16-3.fc26.src
gdl-0:0.9.6-8.fc26.src
kstars-0:16.08.2-1.fc26.src
mrpt-0:1.3.2-9.fc26.src
openbabel-0:2.4.1-1.fc26.src
openms-0:2.0.0-35.20160121git6f51b3.fc26.src
openscad-0:2015.03.3-2.fc26.src
openvibe-0:1.1.0-2.fc25.src
orocos-kdl-0:1.3.1-1.fc25.src
paraview-0:5.2.0-0.7.RC3.fc26.src
pcl-0:1.8.0-2.fc26.src
polymake-0:3.0r2-1.fc25.src
qblade-0:0.96-1.fc26.src
step-0:16.08.2-1.fc26.src
sympol-0:0.1.9-2.fc25.src
vfrnav-0:20160429-3.fc26.src
4 years, 3 months
2 packages seeking new point of contact
by Kevin Fenzi
Greetings.
Due to https://pagure.io/fesco/issue/1639 we have orphaned 2 packages
that need a new point of contact:
rpms/authd -- A RFC 1413 ident protocol daemon ( master f25 f24 f23 )
rpms/python-gudev -- Python (PyGObject) bindings to the GUDev library ( master f25 f24 f23 )
Please do take a look and see if you would like to manage them for
Fedora.
kevin
4 years, 4 months
No Boost update in F25
by Jonathan Wakely
Hi,
I messed up the change proposal for Boost 1.61 in F25, which means it
isn't on the schedule.
Given the huge amount of work involved in every Boost update, I'm not
going to be too upset if I don't have to do it!
How upset will other people be if F25 ships with Boost 1.60 (same as
in F24)? Then F26 would get an update, possibly skipping 1.61 and going
straight to 1.62 which should be out by then.
Boost 1.61 adds four new libraries: Boost.Compute, Boost.DLL,
Boost.Hana and Boost.Metaparse.
Full 1.61 release notes:
http://www.boost.org/users/history/version_1_61_0.html
4 years, 4 months
F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates
by Jan Kurik
= Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags Updates =
https://fedoraproject.org/wiki/Changes/Fedora26CFlags
Change owner(s):
* Florian Weimer <fweimer AT redhat DOT com>
This change updates the default C/C++ compilation flags, as determined
by the redhat-rpm-config package.
== Detailed Description ==
This change covers the following modifications to the default C and
C++ compiler flags in the redhat-rpm-config package.
* Drop -mtune=atom on i686: This flag was added to improve performance
on the Intel Bonnell microarchitecture. Such CPUs are rare these days.
In addition, many users of the i686 packages download them for use
within a 64-bit x86_64 installation, and only a small part of these
Fedora installations use Atom CPUs. Current microarchitectures for
Atom CPUs are different from the original Bonnell microarchtecture and
would need different GCC flags for tuning, but many current Atom-based
devices cannot run Fedora because Fedora does not support their 32-bit
UEFI boot environment.
* Add -Werror=implicit-function-declaration: Implicit function
declarations allows a programmer to call functions without declaring
them (or including the relevant header files). The official C language
specification has not supported implicit function declarations for
almost two decades now. GCC still supports them as a GNU extension.
Implicit function declarations introduce bugs because these functions
use a different calling convention and have a fixed return type of
int. Resulting issues are pointer truncation (on 64-bit
architectures), exposure of padding bits (particular for
bool-returning functions on x86_64), and unexpected lack of hardening.
Implicit function declarations are not part of C++ (with or without
GNU extensions), and adjusting C code accordingly simplifies reuse in
C++ projects.
* Add -Werror=implicit-int: Implicit ints were removed from the C
programming language at the same time as implicit function
definitions, and were also retained as a GNU extension. Implicit ints
are usually source code bugs, and the presence of such code may
interfere with future C language directions (for example, consider how
C++ reused the auto keyword and an omitted type specifier).
The main risk from these changes are incorrect autoconf feature
checks, which often rely on technically invalid C fragments. However,
a review of existing configure scripts did not find any places where
they relied on these two problematic GNU extensions.
The technical side of this change is tracked in bug 1393492.
== Scope ==
* Proposal owners: The defaults in redhat-rpm-config need to be
changed, as described above.
* Other developers: Source code which relies on implicit function
declarations or implicit ints needs to be adjusted.
* Release engineering: This change requires a mass rebuild to become
fully effective.
* List of deliverables: No release blocking deliverables.
* Policies and guidelines: no changes proposed (change will be
implemented through redhat-rpm-config)
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
4 years, 4 months