devel November 2016

devel@lists.stg.fedoraproject.org

207 participants
303 discussions

upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
by Germano Massullo 07 Dec '16

07 Dec '16

We often deal with upstream developers that bundle libraries in their code, so to make a package we have to debundle them, etc. This time, an upstream dev. asked me what he could do to make easier the work of packagers. In this case the software is python-netjsongraph [1] that bundles javascript-d3 library and that is being reviewd at [2] I think it would be nice to make a discussion even for non Python packages, so we can elaborate a sort of vademecum that a packager could show to upstreams when there is a collaboration between them. Have a nice day [1]: https://github.com/interop-dev/django-netjsongraph [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213

5 6

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates
by Jan Kurik 07 Dec '16

07 Dec '16

= 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

10 12

Announcement: DNF port of livecd-creator
by Kevin Kofler 06 Dec '16

06 Dec '16

Hi, remix authors rejoice: I have ported the old livecd-creator from yum to dnf (in one night): https://github.com/kkofler/livecd-tools (The other tools in the package were also ported away from yum and its rpmUtils to dnf, but livecd-creator was the main user of yum stuff.) So, if you are unhappy with livemedia-creator for whatever reason, e.g.: * because of its heavy weight, requiring the whole Anaconda, * because of its lack of persistent caching (which was the dealbreaker for me), * because of more stringent requirements on the kickstart (in particular, livemedia-creator requiring more changes to your existing kickstarts), * because livecd-creator "is more friendly when kickstarts are broken or packages are missing" (quote from a Korora commit message), or whatever, you will probably appreciate it. Some caveats: * It works for me, but of course there is only so much testing you can do in only a few hours of work including the porting. * It is still using Python 2, and thus needs python2-dnf (which nothing else needs). If somebody feels like porting it to Python 3, that should be easy now that it uses dnf, so please feel free. I would be happy to take a pull request for that. * The switch to dnf may change the dependency resolving in a way that may or may not be an improvement. * In particular, you will probably have to explicitly add these packages: kernel-modules kernel-modules-extra to your kickstart to avoid getting the kernel-debug* versions dragged in. For my KDE Fedora Remix Kannolo, I also had to explicitly add pinentry-qt to my kickstart to avoid having pinentry-gnome3 dragged in instead. These changes are completely backwards-compatible with the original yum version of livecd-tools. (They should not have any effect there.) Enjoy, Kevin Kofler

5 9

dnf skipping updates in koji
by Orion Poplawski 06 Dec '16

06 Dec '16

I just noticed this in a root.log for a koji rawhide build that didn't error out doing the install: DEBUG util.py:421: Skipping packages with conflicts: DEBUG util.py:421: (add '--best --allowerasing' to command line to force their upgrade): DEBUG util.py:421: acl x86_64 2.2.52-11.fc24 build 75 k DEBUG util.py:421: bash-completion noarch 1:2.4-1.fc26 build 268 k DEBUG util.py:421: compat-openssl10 x86_64 1:1.0.2j-5.fc26 build 1.1 M DEBUG util.py:421: cracklib-dicts x86_64 2.9.6-3.fc25 build 3.9 M DEBUG util.py:421: dbus x86_64 1:1.11.6-1.fc26 build 245 k DEBUG util.py:421: dbus-libs x86_64 1:1.11.6-1.fc26 build 172 k DEBUG util.py:421: deltarpm x86_64 3.6-17.fc25 build 88 k DEBUG util.py:421: dnf-conf noarch 2.0.0-0.rc1.4.fc26 build 41 k DEBUG util.py:421: dnf-plugins-core noarch 1.0.0-0.rc1.1.fc26 build 38 k .... This doesn't seem right to me. https://koji.fedoraproject.org/koji/taskinfo?taskID=16531079 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

5 5

state of advanced audio in Fedora
by Przemek Klosowski 02 Dec '16

02 Dec '16

I was always impressed with the amount and quality of audio software in Linux. When it all works, and is driven by someone who knows what they're doing, it's essentially a high-end DAW production environment. If it all worked smoothly, I am sure it could be one of Linux and Fedora showcases. I am a musical dilettante, so my attempts have been perhaps haphazard, but I had a mixed luck: I was able to get everything to run, but the setup seemed very brittle. I was not very successful debugging the problems because the audio chain is pretty complex, what with the raw devices, ALSA, PulseAudio and Jackd having overlapping roles, and lots of obsolete and conflicting information on the web. I decided to write to the development list in the hope of starting a technical discussion that would result in either technical and/or configuration fixes, or at least some documentation, that I could perhaps help develop. I have been using the following programs: play/aplay simple .wav players espeak speech synthesizer Qsynth/fluidsynth .midi players/synthesizers audacity sound editor pianobooster keyboard play-along teaching tool Rosegarden w/lilypond music editor Hydrogen drum synthesizer Yoshimi synthesizer rakarrack guitar effect processor As I said, I was able to use all of them successfully, but I had problems integrating them and keeping them up and running in the long term. I wonder if I am doing something wrong, or are there technical issues that I'm running into, currently on Fedora 25 but also on previous versions. Obviously, out of the box, simple sound obviously works: I can aplay a .wav file, espeak works, and some of the synthesizers like audacity and hydrogen simply work without any preconditions. Other audio programs require starting Qsynth first: that seems to be the case for Rosegarden, Yoshimi and pianobooster. What is puzzling is that there seems to be a lot of hidden state: after running Qsynth for a while, the simple sound (aplay, espeak) tend to no longer work: they hang without producing any sound, even though Qsynth is no longer running. I tried stracing them, but they just go into nanosleep() busy loops on internal file descriptors, so it's not clear what exactly they're blocking on. I ran into one glitch where qsynth somehow inserted a .wav file as a soundfont in the configuration file, which prevented it from working subsequently (I had to delete the ~/.config/rncbc.org/Qsynth.conf file). I am planning to log some bugzilla reports, but I am not sure against what subsystems: is it ALSA, or PulseAudio, or Gnome/pavucontrol, or Qsynth. Specifically, I'd like to address the following issues: - simple sound (aplay, espeak) failing after running fancy synthesized sound apps (Qsynth): I'd need guidance what to test to find the hidden state that causes that. - fancy sound apps (Rosegarden/pianobooster) silently failing without the synthesizer (Qsynth) running first. I'd like to discuss what could be done to at least produce some error messages directing users to set up synthesizers first, or maybe to automatically start the required synthesizers.

5 7

F25 GNOME Shell notification locked up hard for some time
by Michael Schwendt 02 Dec '16

02 Dec '16

WTF? Noticed one notification about "File operations" in GNOME Shell, clicked on it, and the entire machine was frozen for maybe ten seconds. Mouse pointer couldn't be moved, keyboard input didn't work, couldn't switch to virtual console either.

4 6

Review swaps
by Jerry James 02 Dec '16

02 Dec '16

I've got a couple of new package dependencies that need reviews: prooftree: https://bugzilla.redhat.com/show_bug.cgi?id=1399366 ocaml-ocplib-simplex: https://bugzilla.redhat.com/show_bug.cgi?id=1399367 I've also got a couple more GAP packages waiting in the wings. These 2 are lower priority than the 2 above: gap-pkg-hapcryst: https://bugzilla.redhat.com/show_bug.cgi?id=1378526 gap-pkg-xmod: https://bugzilla.redhat.com/show_bug.cgi?id=1399365 Let me know what I can review for you in exchange. Regards, -- Jerry James http://www.jamezone.org/

1 1

Rawhide aarch64: gcc bus error
by Jerry James 01 Dec '16

01 Dec '16

I'm trying to build python-cvxopt, but gcc is failing on aarch64 with a bus error: http://koji.fedoraproject.org/koji/taskinfo?taskID=16684863 I took a quick look at koji and found another recent failing build with the same problem: http://koji.fedoraproject.org/koji/taskinfo?taskID=16684488 Both builds indicate that gcc was compiling a simple arithmetic expression when the bus error occurred. Does anybody know what's going on there? Thanks, -- Jerry James http://www.jamezone.org/

7 11

F24 GStreamer zero day
by Michael Catanzaro 01 Dec '16

01 Dec '16

Hi, Is anybody working on fixing [1]? The exploit is a little impractical in that it only works if you have not updated any F24 base packages except GStreamer, but we should still fix it. I don't see any GStreamer updates in bodhi yet. Michael [1] http://arstechnica.com/security/2016/11/elegant-0day-unicorn-underscores-se…

18 45

Creating an new update is failing
by Steve Dickson 01 Dec '16

01 Dec '16

Hello, I'm trying to create a new update and I'm getting this error: Builds : Unable to create update. Parent instance is not bound to a Session; lazy load operation of attribute 'release' cannot proceed The build looks fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=821471 Any ideas what the problem is? tia, steved.

7 9

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