devel March 2016

devel@lists.stg.fedoraproject.org

183 participants
297 discussions

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

osgaudio packaging (bundles/provides openalpp)
by François Cami 25 Apr '16

25 Apr '16

Hi, I'd like to package osgaudio, which is an OpenSceneGraph-like frontend to OpenAL. It is currently maintained by OpenSceneGraph's main author at: https://github.com/robertosfield/osgaudio/ It requires and contains openalpp, a C++ frontend for OpenAL. We haven't shipped openalpp since Fedora 7. The original project for openalpp hasn't been updated since 2005 or so. I've searched for a better fork of openalpp and haven't found any. My proposal is to install openalpp alongside osgaudio, in separate subpackages with appropriate Requires. That way, we provide a choice between a C++ interface to OpenAL or a SceneGraph approach to 3D sound. I believe this approach is not in violation of: https://fedoraproject.org/wiki/Bundled_Software_policy as osgaudio and openalpp would live in separate packages (built from the same srpm), in effect both becoming system libraries. Any comment very much welcome. François

2 2

Validity of i686 as a release blocker
by Josh Boyer 23 Apr '16

23 Apr '16

Hello, Over the past week, we've been dealing with a kernel bug[1] that prevents i686 machines from booting. Help was requested and given, and it has been excellent and most welcome. This email has no reflection on that, and is instead focused on the reality of where i686 stands today. In February[2] we sent out an email highlighting that the kernel team was not going to treat i686 bugs as a priority. Since that time, we have held true to our word and have not focused on fixing i686 bugs at all. It seems that the wider community is also treating i686 similarly. The kernel bug that was made automatic blocker because of existing criteria was present in Fedora since the 4.1-rc6 kernel, which was released May 31. It has been in every boot.iso created since that date. Not a single person reported this issue until last week. That is a timespan of two months. The kernel team has autotesting for i686 kernels, but the environment there does not utilize boot.iso so it did not detect this. The QA team has automated testing for some of this, but nothing for the i686 architecture at all. It is not a priority there either. Perhaps it is time that we evaluate where i686 stands in Fedora more closely. For a starting suggestion, I would recommend that we do not treat it as a release blocking architecture. This is not the same as demotion to secondary architecture status. That has broader implications in both buildsys and ecosystem. My suggestion is narrowly focused so that builds still proceed as today, but if there is something broken for i686 it does not block the release of whatever milestone we are pursuing. (To be clear, I would support a move to secondary arch status for i686, but I am not suggesting it at this time.) Making i686 non-release blocking would actually match reality. None of the Fedora Editions appear at all concerned with i686. Cloud is demoting[3] i686 from its offering. Workstation has been fairly ambivalent about it and recommends x86_64. Server does the same. Given the lack of focus on it, and the fact that the broader community is not testing the development releases for i686, I believe this would be a good first step. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382 [2] https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html [3] https://fedorahosted.org/cloud/ticket/106

15 20

Updating gsl to 2.1 in Rawhide on Monday
by Orion Poplawski 20 Apr '16

20 Apr '16

I'll be updating gsl to 2.1 in Rawhide on Monday and rebuilding dependent packages. See https://bugzilla.redhat.com/show_bug.cgi?id=1276893 for some tracking info. A fair amount of work was done to get everything ready for this update, but there may be a couple stragglers. -- 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

2 1

iproute package split
by Phil Sutter 08 Apr '16

08 Apr '16

Hi, I am in the process of splitting the 'tc' utility off from iproute package. The motivation for this comes from two things: 1) Due to it's xt/ipt action, tc depends on iptables. 2) iproute is part of the 'Core' group. These two in combination lead to iptables being pulled into Core as a dependency although not strictly necessary - tc is not necessary for basic system functionality and ip itself works fine without. So far I added a new 'tc' subpackage to iproute.spec which will contain tc, all related binaries and configs and relevant man pages. This package depends on a version of iproute which is greater than the last release before the split, which should prevent conflicts when updating. For user convenience though, I would appreciate if an iproute package update from a pre-split version would automatically pull the tc subpackage as well. Is this possible without adding a dependency from 'iproute' to 'iproute-tc' (which would defeat the purpose, of course)? Cheers, Phil

6 13

Announce: blivet-2.0.0
by David Lehman 05 Apr '16

05 Apr '16

Hi everyone, I would like to announce the release of blivet-2.0.0[1]. See the release notes[2] for information about all of the changes in this version and the documentation[3] for the public API specification. Some of the larger changes: - full PEP8 compliance - thread-safety - added support for creating LVM RAID volumes - added support for resizing LUKS encrypted block devices - use libbytesize[4] as the backend for blivet's Size class - device tree updates based on uevents (disabled by default) - dropped support for python2 For now there is a blivet-2.0.0 build in my copr[5] for anyone who wants to check it out. I also want to give a heads-up that I plan to build blivet-2.0.1 in rawhide next week, which means switching anaconda to use it at that time. Thanks, David [1] https://github.com/rhinstaller/blivet/releases/tag/blivet-2.0.0 [2] https://github.com/rhinstaller/blivet/blob/2.0-release/release_note s.rst [3] http://rhinstaller.github.io/blivet/docs/api.html [4] https://github.com/rhinstaller/libbytesize [5] https://copr.fedorainfracloud.org/coprs/dlehman/blivet/

2 1

ThinkPad X220 does not wake up after suspend (since Saturday)
by Martin Ueding 04 Apr '16

04 Apr '16

Hi, my ThinkPad X220 runs Fedora 23 with automatic updates, Chromium and Spotify Copr. Up until Friday night, it worked just fine. Friday afternoon the new Kernel 4.4.5 was installed. It was only loaded on Saturday when I started the machine in the afternoon. I suspended the laptop to RAM and found that it did not woke up. I only got this strange light show: https://www.youtube.com/watch?v=ajoWfCtk7yE The error (sadly) is 100% reproducible. I then went on and started with the earlier kernels, 4.4.4 and 4.4.3, which worked fine before Friday. (Thanks for keeping three kernels by default!) The error is just the same, it does not wake up. Then I also started a Kubuntu 15.04 from USB and had a slightly different error. The machine would start the fan and the power light would turn on, but the wifi was still off and the screen was black. Using Arch Linux 2016.03.01 I was able to reproduce the error with Kernel 4.4.1. Therefore I think it is not about the software any more. This might be somewhere in the hardware or UEFI firmware. In the discussion about systemd mounting efiwars read-write I read about some bricked laptops by deleting the efivars. Is it possible that some recent change (like Friday or Saturday) did something that could potentially interfere with the suspend-to-RAM? A frind of mine who wants to switch to Fedora wants to wait a bit as he has the same laptops and fears that his might break as well. The laptop is four years old and has been used all the time, I use it as my desktop on a docking-station. Warranty has experied a year ago, so I have to fix it myself with help. What can I do to get the system to wake up normally again? Regards, Martin Ueding

3 8

Major owncloud updates incoming
by James Hogarth 02 Apr '16

02 Apr '16

Hi all, We're at the last stages of preparing the first major owncloud update in a while. The current version of owncloud in Fedora is the fairly old stable 8.0 release (presently 8.0.10) which we want to bring back in line with the current owncloud upstream release of 8.2.2. Unfortunately it's not possible to migrate directly from 8.0.x to 8.2.x as upstream only supports jumping in increments with no skipping of major releases. In order for a smooth transition to 8.2.x (and after that 9.0.x when it's released) we'll be releasing 8.1.5 to F23 and F22 within the next couple of weeks. We plan to leave this in updates-testing for a slightly longer period than usual to allow for a wider test base for a major version jump. Please remember your backups prior to the upgrade! Once 8.1.5 is pushed to updates 8.2.2 will be pushed to updates-testing for a similar extended period. It's imperative that the 8.1.5 update is applied before the 8.2.2 update is pushed to updates. If you want to assist in the testing and provide feedback or bug reports please use the usual channels of bodhi and bugzilla - both easily accessible from pkgdb: https://admin.fedoraproject.org/pkgdb/package/rpms/owncloud/ Kind regards, James

1 3

[GCC6] fatal error: You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use these intrinsics.
by Igor Gnatenko 02 Apr '16

02 Apr '16

https://bugzilla.redhat.com/show_bug.cgi?id=1307783 Looks like it failed on armv7 with this error, but it was working before... Any ideas? In file included from /builddir/build/BUILD/mozjs-31.2.0/mfbt/tests/TestEndian.cpp:6:0: ../../dist/include/mozilla/Endian.h: In function 'void swapFromNetworkOrderInPlace(T*, size_t) [with T = short unsigned int]': ../../dist/include/mozilla/Endian.h:175:45: fatal error: You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use these intrinsics. return MOZ_HAVE_BUILTIN_BYTESWAP16(value); ^ compilation terminated. -- -Igor Gnatenko

5 6

Schedule for Friday's FESCo Meeting (2016-04-01)
by Kalev Lember 01 Apr '16

01 Apr '16

Following is the list of topics that will be discussed in the FESCo meeting Friday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2016-04-01 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1552 Review of delayed Changes for F24 .fesco 1552 https://fedorahosted.org/fesco/ticket/1552 = New business = #topic #1562 drop exception to proven packager access to packages .fesco 1562 https://fedorahosted.org/fesco/ticket/1562 #topic #1563 "Rich Dependencies" vs. DNF vs. YUM issues .fesco 1563 https://fedorahosted.org/fesco/ticket/1563 #topic #1565 Fedora schedule must continue to track core library ABI or risk serious ABI implications. .fesco 1565 https://fedorahosted.org/fesco/ticket/1565 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

4 5

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