devel April 2016

devel@lists.stg.fedoraproject.org

181 participants
285 discussions

GPG2 as default /usr/bin/gpg
by Christopher 21 Jul '16

21 Jul '16

I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1309175 It's not a huge deal (and there are several workarounds, for git and for other tools which default ot using 'gpg'), but it highlights the mismatch between the default /usr/bin/gpg running gpg1, when other tools, like gpg-agent, are tailored for gpg2. RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least sometime in RHEL6. I'm not saying we shouldn't continue to ship gnupg1, but can we at least rename it, so gnupg package is version 2, and gnupg1 provides /usr/bin/gpg1 instead? This seems overdue. Is there any reason not to do this?

12 21

Support for PCLMUL, AVX, FMA, etc.
by Jerry James 18 Jul '16

18 Jul '16

I am one of the maintainers of the ntl package, which is used by some numeric applications (e.g., Macaulay2 and sagemath). Upstream supports use of the PCLMUL instruction, the AVX instructions, and the FMA instructions to speed up various computations. We can't use any of those in Fedora, since we have to support a baseline x86_64. Well, that's kind of a downer. I could advertise that people with newer CPUs ought to rebuild the ntl package for their own CPUs, but what's a distribution for if people have to rebuild packages? I've been looking for a way to automatically support more recent CPUs. Yesterday I sent a patch upstream that uses gcc's indirect function support together with __attribute__((target ...)) to build vanilla x86_64, PCLMUL-enabled, AVX-enabled, and FMA-enabled varieties of several functions. Upstream was initially excited about this but then, on further reflection, offered the opinion that this approach is dangerous. The problem is that some of the types involved may change ABI depending on the instruction set in use, and therefore it would be necessary to build larger portions of the library for each supported CPU variant. At that point, as upstream said, we might as well just build the entire library for each variant. The problem then is how to choose which version of the library to use at load time. On some platforms, ld.so offers "hardware capabilities", such as sse2 on i386. By dropping a vanilla library into /usr/lib and an SSE2-enabled build into /usr/lib/sse2, applications can get the version of the library appropriate for the CPU in use. But there don't seem to be any defined hardware capabilities for x86_64. Has anybody already thought this through? What's the best approach to take? For this package, the speedups are substantial, so this is worth doing, if it can be done well. Thank you, -- Jerry James http://www.jamezone.org/

5 4

F25 Self Contained Change: Replace UDisks2 by Storaged
by Jan Kurik 30 May '16

30 May '16

= Proposed Self Contained Change: Replace UDisks2 by Storaged = https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged Change owner(s): * Peter Hatina <phatina redhat com> * Tomáš Smetana <tsmetana redhat com > Storaged extends UDisks2 API by exporting several enterprise features (in form of plugins), such as LVM2 and iSCSI. This project is a drop-in replacement for UDisks2, either from D-Bus or binary point of view. The main motivation of this change is to provide the unified D-Bus API for all the clients who are willing to manage LVM2, iSCSI, Btrfs, BCache, LSM and ZRam. == Detailed Description == Aim of Storaged is to provide unified higher level management interface for various clients who are willing to query and manage storage bits of the system. We plan to replace UDisks2 by Storaged, since the Storaged itself is the fork of UDisks2 and these 2 projects in its core haven't diverged so much (Storaged got some improvements which popped up while using it). == Scope == Proposal owners: To implement this Change Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) List of deliverables: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) 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

7 12

Kernel plans for Fedora 24
by Justin Forbes 18 May '16

18 May '16

With the 4.5 kernel out and the merge window for 4.6 opened up, we had to make a decision on what the release kernel for F24 would be. The decision has been made to ship F24 with the 4.5 kernel with 4.6 available as an update once it is ready. Timing wise, 4.6 *should* release just before the final freeze for F24, but that is cutting it insanely close. Should Fedora move on as scheduled, and 4.6 have some delay due to a bug that impacts users, that would be unfortunate. This means we have a good bit of time to make sure that everything is working as intended with 4.5 in Fedora. It also means that any installer critical fixes will need to be backported to 4.5. Thanks, Justin

6 10

Error while retiring breathe
by Dave Johansen 14 May '16

14 May '16

I'm renaming breathe [1] to python-breathe [2]. I just tried to retire breathe in f22 using the instructions on the wiki [3] and got the following error: Could not retire package: Error while decoding JSON: Expecting value: line 1 column 1 (char 0) Am I doing something wrong? Thanks, Dave [1] https://admin.fedoraproject.org/pkgdb/package/rpms/breathe/ [2] https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/ [3] https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#GIT

3 9

orphaning all my packages
by François Cami 06 May '16

06 May '16

Hello, I'll orphan all my packages at 2PM UTC+2 tomorrow. rpms/bats -- Bash Automated Testing System ( master f24 f23 f22 epel7 el6 ) rpms/djview4 -- DjVu viewer ( epel7 ) rpms/djvulibre -- DjVu viewers, encoders, and utilities ( master f24 f23 f22 epel7 el6 ) rpms/enet -- Thin, simple and robust network layer on top of UDP ( master f24 f23 f22 epel7 ) rpms/gpsd -- Service daemon for mediating access to a GPS ( epel7 ) rpms/pdf2djvu -- PDF to DjVu converter ( master f24 f23 f22 epel7 ) rpms/pngcrush -- Optimizer for PNG (Portable Network Graphics) files ( master f24 f23 f22 el6 ) rpms/pyliblzma -- Python bindings for lzma ( master f24 f23 f22 el6 ) rpms/python-fpconst -- Python module for handling IEEE 754 floating point special values ( master f24 f23 f22 ) rpms/stardict-xmllittre -- Authoritative 19th century French dictionary ( master f24 f23 f22 ) rpms/throttle -- Bandwidth limiting pipe ( master f24 f23 f22 epel7 el6 el5 ) rpms/tinyxml -- A simple, small, C++ XML parser ( master f24 f23 f22 epel7 ) rpms/tinyxml2 -- Simple, small and efficient C++ XML parser ( master f24 f23 f22 epel7 el6 el5 ) rpms/unittest-cpp -- Lightweight unit testing framework for C++ ( master f24 f23 f22 epel7 el6 ) rpms/uriparser -- URI parsing library - RFC 3986 ( master f24 f23 f22 ) rpms/vtk -- The Visualization Toolkit - A high level 3D visualization library ( epel7 ) I'm also co-maintainer for the list below, it would be nice if others could step up and help their maintainers too: rpms/LuxRender -- Lux Renderer, an unbiased rendering system ( master f24 f23 f22 epel7 ) rpms/PyOpenGL -- Python 2.x bindings for OpenGL ( f23 f22 ) rpms/blender -- 3D modeling, animation, rendering and post-production ( master f24 f23 f22 epel7 ) rpms/bullet -- 3D Collision Detection and Rigid Body Dynamics Library ( master f24 f23 f22 epel7 el6 ) rpms/ceph-ansible -- Ansible playbooks for Ceph ( master f24 f23 f22 epel7 ) rpms/cppcheck -- Tool for static C/C++ code analysis ( master f24 f23 f22 epel7 el6 el5 ) rpms/dbus-c++ -- Native C++ bindings for D-Bus ( master f24 f23 f22 epel7 ) rpms/disper -- On-the-fly display switch utility ( master f24 f23 f22 epel7 el6 ) rpms/djview4 -- DjVu viewer ( master f24 f23 f22 ) rpms/dvblinkremote -- Tool for interacting with a DVBLink Connect! Server ( master f24 f23 f22 ) rpms/freenx-server -- Free Software (GPL) Implementation of the NX Server ( master f24 f23 f22 ) rpms/geany -- A fast and lightweight IDE using GTK2 ( master f24 f23 f22 epel7 el6 el5 ) rpms/girara -- Simple user interface library ( master f24 f23 f22 epel7 el6 ) rpms/gitolite3 -- Highly flexible server for git directory version tracker ( master f24 f23 f22 epel7 el6 ) rpms/iperf3 -- Measurement tool for TCP/UDP bandwidth performance ( master f24 f23 f22 epel7 el6 ) rpms/jack-audio-connection-kit -- The Jack Audio Connection Kit ( master f24 f23 f22 epel7 el6 ) rpms/jfsutils -- Utilities for managing the JFS filesystem ( master f24 f23 f22 ) rpms/key-mon -- A screen cast utility that displays your keyboard and mouse status ( master f24 f23 f22 epel7 ) rpms/libffado -- Free firewire audio driver library ( master f24 f23 f22 epel7 ) rpms/libmediainfo -- Library for supplies technical and tag information about a video or audio file ( master f24 f23 f22 epel7 el6 ) rpms/librelp -- The Reliable Event Logging Protocol library ( master f24 f23 f22 ) rpms/ocl-icd -- OpenCL ICD Bindings ( master f24 f23 f22 ) rpms/openal-soft -- Open Audio Library ( master f24 f23 f22 epel7 ) rpms/portaudio -- Free, cross platform, open-source, audio I/O library ( master f24 f23 f22 epel7 ) rpms/python-pyopengl -- Python bindings for OpenGL ( master f24 ) rpms/rssh -- Restricted shell for use with OpenSSH, allowing only scp and/or sftp ( epel7 ) rpms/sir -- A simple application for resizing images ( master f24 f23 f22 ) rpms/speed-dreams -- The Open Racing Car Simulator ( master f24 f23 f22 ) rpms/surf -- Simple web browser ( f23 f22 ) rpms/unhide -- Tool to find hidden processes and TCP/UDP ports from rootkits ( master f24 f23 f22 ) rpms/vtk -- The Visualization Toolkit - A high level 3D visualization library ( master f24 f23 f22 ) rpms/vtkdata -- Example data file for VTK ( f22 ) rpms/xfce4-xkb-plugin -- XKB layout switcher for the Xfce panel ( master f24 f23 f22 ) rpms/xonotic -- Multiplayer, deathmatch oriented first person shooter ( master f24 f23 f22 el6 el5 ) rpms/xonotic-data -- Game data for the Xonotic first person shooter ( master f24 f23 f22 el6 el5 ) rpms/zathura -- A lightweight document viewer ( master f24 f23 f22 epel7 el6 ) rpms/zathura-cb -- Comic book support for zathura ( master f24 f23 f22 epel7 ) rpms/zathura-djvu -- DjVu support for zathura ( master f24 f23 f22 epel7 el6 ) rpms/zathura-pdf-mupdf -- PDF support for zathura via mupdf ( master f24 f23 ) rpms/zathura-pdf-poppler -- PDF support for zathura via poppler ( master f24 f23 f22 epel7 el6 ) rpms/zathura-ps -- PS support for zathura via libspectre ( master f24 f23 f22 epel7 el6 ) It's been a fun ride. François

9 13

RFC: Fedora Docker Layered Image Guidelines
by Adam Miller 04 May '16

04 May '16

Hello all, We're wrapping up the first phase of the Fedora Docker Layered Image Build Service[0] and the time has come to start thinking about what we as a Project need to do to formalize what it means to be shipping Docker Layered Images once we are capable of building and distributing them. These are effectively going to compliment their RPM counterpart at least in the beginning since we as a Project have never shipped any build artifact other than RPMs as a part of the distribution before. We can grow organically from there if we want to extend beyond the initial offering for Docker Layered Images but I thought following RPM as a guide in the beginning was a reasonable goal to achieve. Some areas that seemed pertinant right off the bat are below, for each of them I have alread created a Draft document that I would appreciate feedback on. Docker Layered Image "packaging" Guidelines [1] Package Review Process with a Docker Containers section [2] Docker Layered Images Naming Guildelines [3] The Fedora Cloud SIG has done a first-pass review of these (thanks Cloud SIG!) so hopefully there's a certainly level of sanity to them but I'm absolutely open to new ideas and extending the content with more coverage. Another point to note is that we need to determine how this should be handled in BZ components for bug reporting as well as for filing review requests. Something else what was brought up when I originally submitted these ideas to FESCo[4] (aside from the fact that this should go to devel list first) was that it is probably a good idea to establish a Container-centric Guidelines Committee much in the way there is a Fedora Packaging Committee (which focuses on RPMs). My question to everyone on that topic is, would there be enough interest to establish such a committee? As a side note and just a matter of opinion but I think the idea of forming a Committee to help shepherd these new types of deliverables through Fedora will help to enable aspects of Fedora Modularization[5] which ultimately will be good for the whole of the Fedora Project. I look forward to questions and feedback. Thank you, -AdamM [0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service [1] - https://fedoraproject.org/wiki/PackagingDrafts/Containers [2] - https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_with_… [3] - https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGuid… [4] - https://fedorahosted.org/fesco/ticket/1573

10 16

freecad: Need help with segfault problem on F24
by Richard Shaw 03 May '16

03 May '16

I'm pretty much stumped on a problem where freecad (really python-pivy) segfaults on F24 but seems to run fine on F23 and I can't find any substantive difference between any of the packages. Strangely installing Coin3 from f23 on a f24 system seems to fix the problem... https://bugzilla.redhat.com/show_bug.cgi?id=1323159 Any pointers/help would be appreciated. Thanks, Richard

6 19

GCC 6 constexpr errors?
by Michael Schwendt 03 May '16

03 May '16

audacious-plugins-3.7.2 in Rawhide koji failed to build with constexpr errors in various plugins. What exactly has changed? https://kojipkgs.fedoraproject.org//work/tasks/5212/13645212/build.log metronom.cc:50:30: in constexpr expansion of 'InputPlugin::InputInfo(0).InputPlugin::InputInfo::with_schemes(((const char* const*)(& Metronome::schemes)))' metronom.cc:50:30: error: accessing uninitialized array element .with_schemes(schemes); ^

2 2

Plans for Node.js 6.x
by Stephen Gallagher 01 May '16

01 May '16

OK folks, it's Bad Decision Time. Today, Node.js 6.0 was released. This is a significant ABI-breaking release, which means there is no guarantee that existing modules will work with it at all.[1] Better still, Node.js 5.x is only going to be supported until sometime this summer, because they're aiming for the 6.x branch to become the new LTS in October[2]. This puts us in quite a bind. Fedora disallows major ABI changes in a stable release, so if Fedora 24 Final ships with Node.js 5.x, we will be stuck with maintaining it until Fedora 24 EOL (which is probably going to mean until approximately June 2017, or almost a full year after upstream drops support). This means manually backporting any security issues that come up without the benefit of a new version to rebase to and with an increasing likelihood of the patches diverging from upstream. On the flip side, the major ABI break is hitting us post-Beta Freeze for Fedora 24, which is a really terrible time to be switching to a new major version of a language runtime (particularly since we don't actually know if any of the other packages on the system will work with it at all). We don't have any particularly good options here. A downgrade back to 4.x (which will be supported until at least April 2018, well past F24 EOL) would be very difficult at this point, since node modules may have updated to newer, incompatible versions. Furthermore, this came at a time where I was planning to write to the nodejs list and let people know that due to my changing work responsibilities, I'm not going to be able to be the primary maintainer of the main package any longer. (I'd be able to swing the occasional minor- or point-release update, but wrangling a major release won't be possible.) I realize this is inopportune, but it's best if we figure out *immediately* how we're going to handle this. Options: 1) Downgrade back to 4.x, downgrading or dropping any modules in the collection that don't run on that LTS version. 2) Stick with 5.x for the life of Fedora 24, handling security backports ourselves once it hits EOL this summer. 3) Upgrade to 6.x, fixing or dropping any modules in the collection that don't run on it yet. I'll stick around to help with this major effort (since it's partly my fault we're in this mess; I didn't realize that the release schedule for 5.x was so poorly aligned with Fedora 24), but after that I'm going to need someone else to step up and handle the primary maintenance. I don't like any of the choices, but I'm going to suggest that option 3) may be our best choice if we can manage it; we will want to be doing the same work for Fedora 25/Rawhide anyway, so it's not wasted effort. Also, a lot of the node modules in Fedora are only there because originally we needed them as dependencies for npm. Since we recently switched to carrying the embedded npm (and its rat's-nest of dependencies) inside the main nodejs package, we can probably get away with breakage in a lot of the modules in the collection. We may only need to focus in the short term on those packages that are required by other parts of the Fedora Project (like nodejs-less, which is consumed in the build process for many web apps). Option 2) is the path of least resistance in the immediate short-term, but once we run up against the upstream EOL, the maintenance burden could be prohibitive. In theory, we could petition FESCo for permission to break ABI in the stable release, but I wouldn't recommend it (and would probably be voting against it were it to come from anywhere else; I'd abstain in this case due to conflict of interest). Given that we know about the potential risk in advance, I doubt we'd see much sympathy either. So we should realistically assume that if we choose this option, someone is going to need to maintain the security backports (and it will not be me, sorry). As for Option 1)? I think someone with more knowledge of the individual modules in Fedora (Tom Hughes? Jared Smith?) would need to figure out how many modules would be broken if we downgraded. If it's sufficiently small, I suppose we could epoch-bump nodejs and its virtual npm Provides: and go that route. I don't love that we will effectively been playing yo-yo with the version in F24, but it would be a solution... Thoughts, other ideas? Please skip the rotten fruit; I'm on a diet. [1] https://github.com/nodejs/node/blob/master/CHANGELOG.md#2016-04-26-version-… [2] https://github.com/nodejs/LTS#lts_schedule

11 26

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 April 2016