GPG2 as default /usr/bin/gpg
by Christopher
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?
7 years, 9 months
Kernel plans for Fedora 24
by Justin Forbes
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
7 years, 11 months
osgaudio packaging (bundles/provides openalpp)
by François Cami
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
7 years, 12 months
Validity of i686 as a release blocker
by Josh Boyer
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
8 years
iproute package split
by Phil Sutter
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
8 years
ThinkPad X220 does not wake up after suspend (since Saturday)
by Martin Ueding
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
8 years
Major owncloud updates incoming
by James Hogarth
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
8 years
