devel March 2016

devel@lists.fedoraproject.org

183 participants
299 discussions

Firefox not working anymore over ssh?
by Juan Quintela 22 Jul '16

22 Jul '16

Hi since last Monday or so, I have been able to run firefox over ssh anymore. I thought it was my setup, but further investigation showed that it is something specific to firefox. My setup is a bit more convoluted than this, but I am able to do: $ ssh -X localhost gnome-terminal And it shows a terminal as expected $ ssh -X localhost firefox Without a firefox running will hang there forever, no output at all. I tried doing strace of it, and see that is waiting for futexes. But haven't been able to see what is happening. Until last Tuesday or so (I am on F23) firefox worked over ssh without any problems. I have been running it like that for something like a year. Anyone has any suggestion? I tried also $ ssh -Y localhost firefox And it didn't helped at all (not that I am sure of the difference either). Later, Juan. PD. Really, what I normally do is run ssh to a virtual manchine in the same host.

12 27

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

22 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

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

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