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)?
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
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?
We're at the last stages of preparing the first major owncloud update in a
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
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
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:
Looks like it failed on armv7 with this error, but it was working before...
In file included from
../../dist/include/mozilla/Endian.h: In function 'void
swapFromNetworkOrderInPlace(T*, size_t) [with T = short unsigned
../../dist/include/mozilla/Endian.h:175:45: fatal error: You must
enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use
Packagers, members of the fedorabugs group and people having a 'watchbugzilla'
ACL in pkgdb must have a bugzilla account attached to the email they set in the
Fedora Account System (FAS).
This is mandatory to allow ACLs to be propagated from pkgdb to bugzilla, allowing
the right person to be made assignee or to be cc'ed on bug reports of packages.
There are currently a few users who are not following this rule and have not
been for quite a while, despite our attempts to contact them:
* jackprice, FAS email: jackprice -- outlook.com
watches 1 package
* vjancik, FAS email: viktor.vix.jancik -- gmail.com
co-maintains¹ 68 packages
watches 1 package
* mstuchli, FAS email: matej.stuchlik -- gmail.com
POC of 14 packages
co-maintains 18 packages
* ferbncode, FAS email: suyashgargsfam -- gmail.com
watches 2 packages
* jangernert, FAS email: janlukasgernert -- freenet.de
watches 1 package
If anyone knows how to reach to them and could either send them to us, the
Fedora infrastructure team, or directly ask them to create a bugzilla account
associated to the email they set in FAS, it would be highly appreciated.
If nothing changes in the coming days, we will drop their ACLs in pkgdb.
Thanks for your help and understanding,
for the Fedora Infrastructure team
¹ This number includes packages on which the user may have `watch*` ACLs
The Fedora 24 Alpha for POWER is here, right on schedule for our planned June
final release. Download the prerelease from our Get Fedora site:
- Get Fedora 24 Alpha Workstation https://getfedora.org/en/workstation/
- Get Fedora 24 Alpha Server https://getfedora.org/en/server/prerelease/
- Get Fedora 24 Alpha Cloud https://getfedora.org/en/cloud/prerelease/
- Get Fedora 24 Alpha Spins https://spins.fedoraproject.org/prerelease
- Get Fedora 24 Alpha Labs https://labs.fedoraproject.org/prerelease
- Get Fedora 24 Alpha ARM https://arm.fedoraproject.org/prerelease
What is the Alpha release?
The Alpha release contains all the features of Fedora 24's editions in
a form that anyone can help test. This testing, guided by the Fedora
QA team, helps us target and identify bugs. When these bugs are fixed,
we make a Beta release available. A Beta release is code-complete and
bears a very strong resemblance to the third and final release. The
final release of Fedora 24 is expected in June.
If you take the time to download and try out the Alpha, you can check
and make sure the things that are important to YOU are working. Every
bug you find and report doesn't just help you, it improves the
experience of millions of Fedora users worldwide!
Together, we can make Fedora rock-solid. We have a culture of
coordinating new features and pushing fixes upstream as much as we
can, and your feedback improves not only Fedora, but Linux and Free
software as a whole.
Under the hood, glibc has moved to 2.23. The update includes better
performance, many bugfixes and improvements to POSIX compliance, and
additional locales. The new library is backwards compatible with the
version of glibc that was shipped in Fedora 23, and includes a number
of security and bug fixes.
We've also updated the system compiler to GCC 6 and rebuilt all
packages with that, providing greater code optimization and catching
programming errors which had slipped past previous compilers.
In ppc64/ppc64le golang 1.6 brings all the same golang functionality that
other architectures have enjoyed enabling all the features and apps
that are avaialble there such as docker.
- FreeIPA 4.3 (Domain Controller role) is included in Fedora 24. This
version helps streamline installation of replicas by adding a
replica promotion method for new installs. A new topology plugin has
also been added that automatically manages new replication segment
creation. An effective replica topology visualization tool is also
available in the webUI.
- NodeJS 4 in now available for aarch64. Earlier versions of nodejs have
been available on primary architectures for some time. With nodejs4 we
now bring all the functionality to aarch64 too.
- More packages have been removed from the default Server edition to
make the footprint of the default installation smaller.
- For Fedora 24, we're working hard to make Fedora the best platform
for developing containers, from the base Fedora container images to
a full-featured PaaS to run and manage them.
- For both ppc64 and ppc64le we have qemu cloud images and add to it
docker base images to the release as well.
Issues and Details
This is an Alpha release. As such, we expect that you may encounter bugs
or missing features. To report issues encountered during testing,
contact the Fedora QA team via the mailing list or in #fedora-qa on
As testing progresses, common issues are tracked on the Common F24 Bugs
For tips on reporting a bug effectively, read "how to file a bug
The full release schedule is available on the Fedora wiki:
The current schedule calls for a beta release towards the beginning of May,
the final release in early June.
Be aware that these dates are development targets. Some projects release
on a set date regardless of feature completeness or bugs; others wait
until certain thresholds for functionality or testing are met. Fedora
uses a hybrid model, with milestones subject to adjustment. This allows
us to make releases with new features and newly-integrated and updated
upstream software while also retaining high quality.
devel-announce mailing list