devel November 2016

devel@lists.fedoraproject.org

207 participants
303 discussions

iproute package update policy
by Phil Sutter 14 Mar '17

14 Mar '17

Hi, So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports. But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support. Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system? Any comments/advice are highly appreciated. Thanks, Phil

7 13

whatever happened to yum + btrfs snapshotting?
by Neal Becker 13 Mar '17

13 Mar '17

Some time back there was discussion of being able to rollback yum updates via btrfs snapshotting. As I recall, it turned out that the default btrfs install was not setup correctly to make this feasible (I had briefly tested it on my machine). I haven't heard anything since - this seems like a great idea. -- -- Those who don't understand recursion are doomed to repeat it

7 7

Is Kalpa Welivitigoda still active at maintaining packages?
by Iiro Laiho 25 Feb '17

25 Feb '17

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

3 2

Weak password madness is back again
by Hans de Goede 22 Jan '17

22 Jan '17

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

10 23

RFC: static builds for user emulators in Fedora QEMU RPMs
by Daniel P. Berrange 14 Jan '17

14 Jan '17

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-x86… -- |: 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 :|

9 17

BuildRequires on obsoleted packages provided by Python
by Charalampos Stratakis 11 Jan '17

11 Jan '17

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/dfdd96e653d65ce6835955… 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

9 11

HEADS UP: eigen-3.3.0 update
by Sandro Mani 29 Dec '16

29 Dec '16

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/ab6b067017a18712d6b35d1834b… 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/7c74473d12809e4122527b6e003c74a94… 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

6 16

2 packages seeking new point of contact
by Kevin Fenzi 21 Dec '16

21 Dec '16

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 3

No Boost update in F25
by Jonathan Wakely 09 Dec '16

09 Dec '16

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 7

installing RPMs on NFS filesystems
by Chuck Anderson 08 Dec '16

08 Dec '16

Is it supposed to be supported to install RPMs onto NFS filesystems? Apparently NFSv3 doesn't support capabilities, so I'm not sure what to do with this bug which happens because cap_net_raw is used for the fping binaries: https://bugzilla.redhat.com/show_bug.cgi?id=1350476 Thanks.

7 10

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2016