Reliability test for hard drives and SSD
by Andrey Ponomarenko
Hi there!
Good news for all interested in hardware compatibility and reliability.
I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool!
The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors.
Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation.
Thanks to ROSA, Fedora, Ubuntu, Debian, Mint, openSUSE, Arch, Gentoo users and others who had made this work possible by contribution to the database!
1 week, 2 days
Intel's Clear Linux optimizations
by František Zatloukal
Hi,
Phoronix recently release article[1] about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
settings.
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
[1]
http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1
--
Best regards / S pozdravem,
František Zatloukal
Project Coordinator
Red Hat
1 week, 6 days
Intent to orphan Python 2
by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded
python2 subpackages, or let us drop them for you" [0].
The next best thing we *can* say is: "if Fedora is to keep python2
alive, we won't be the ones doing it – at least not at the current
magnitude".
Here are the details.
The current maintainers of python2 would like to "orphan" the python2
package in 2020 (~ Fedora 30):
- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)
As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
- dependent packages drop support for Python 2.
Unlike most other orphanings, we have some thousands of dependent
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
Of course, we're ready to make various compromises with interested
packagers, as long as there's an understanding that we won't just
support python2 forever.
If you are a maintainer of anything at [1] we ask you kindly to consider
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora >
29. (On the current schedule, Fedora 30 will be the first release still
supported after 2020-01-01.)
If no one steps up to maintain python2 after 2020, we're prepared to
package a "legacy" python27 package, similar to what we do for e.g.
python33 [2], to:
- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if
their upstreams don't manage to port to Python 3 in time
[0] https://pagure.io/packaging-committee/issue/753
[1] http://fedora.portingdb.xyz/#legacy-leaf
[2] https://src.fedoraproject.org/rpms/python33/
3 weeks, 5 days
Avoiding Jargon: dist-git
by Christopher
Can we stop saying "dist-git" in our docs? Nobody knows what that is.
The service at https://src.fedoraproject.org is clearly branded as "Fedora
Package Sources".
Using the jargon "dist-git" in our documentation is simply confusing, since
it doesn't match what the service calls itself, and doesn't match any user
interface packagers use. As far as I can tell, only people with a deep
understanding of Fedora's infrastructure (which does not seem to be most
packagers) know what this term means.
For example, in
https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb , instead
of saying "Browse to your project on Pagure over Dist-Git (Top Level
link)", we should say: "Browse to your project's Package Source repository
at https://src.fedoraproject.org"
And, instead of saying "How do I request commit access to a dist-git
repo?", we should say: "How do I request commit access to a Package Source
repository?"
Using special/internal/historical jargon, especially when that jargon
doesn't correspond to the current packager experience when interacting with
these services, only leads to confusion and should be avoided.
If we really need to use the term "dist-git" in the wiki, it should at
least link to a glossary page that says "Dist-Git: A term which refers to
the Fedora Package Sources repository hosting service at
https://src.fedoraproject.org built on Pagure (an open source git
repository management service)", instead of just assuming everybody seeing
the term "dist-git" knows what that term is and where it came from.
If we can avoid jargon with this term and other similar terms, it'd be a
big help to our documentation.
If this seems reasonable, I'd be happy to help start editing some of the
wiki pages... but it'd be helpful if everybody maintaining infrastructure
documentation was on the same page.
Thanks,
Christopher
2 months, 2 weeks
RANT: Packaging is changing too fast and is not well documented
by Richard Shaw
<RANT>
So I went to request a new branch of an existing package only to find out
fedrepo-req-branch, which hasn't been around that long is already
depreceated and the facility brought into fedpkg... so:
$ fedpkg request-branch <branch>
Could not execute request_branch: The "token" value must be set under the
"fedpkg.pagure" section in your "fedpkg" user configuration
Ok, so where does that get stored?
$ man fedpkg
(not in there...)
$ vi /usr/share/doc/fedpkg/README
(not in there...)
I figured out somewhere else that the default config is in
/etc/rpkg/fedpkg.conf (In /etc/rpkg? That's intuitive!) but I didn't want
to add my token to the site wide config so the search continues...
$ rpm -ql fedpkg
(pokes around)
$ vi /usr/lib/python2.7/site-packages/fedpkg/__main__.py
...
def main():
default_user_config_path = os.path.join(
os.path.expanduser('~'), '.config', 'rpkg', '%s.conf' % cli_name)
...
Found it!
Now which token do I need? The one from the src.fedoraproject.org pagure or
pagure.io?
Oh and the tokens expire all the time and don't seem to have any helper
scripts to automate updating of the tokens so I have to remember where they
all are and manually edit them every time...
</RANT>
Not coming from a programming background I found the learning curve pretty
steep when I first tried to become a packager, I'm not sure I wouldn't have
given up if I had to do it now.
Thanks,
Richard
3 months, 1 week
F28 Self Contained Change: Stop building 389-ds-base on i686
by Jan Kurik
= Proposed Self Contained Change: Stop building 389-ds-base on i686 =
https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686
Owner(s):
* Mark Reynolds <mreynolds at redhat dot com>
389-ds-base does not work properly on i686 hardware in regards to atomic types.
== Detailed description ==
389-ds project have found an issue which causes system instability on
all versions of 1.4.x of the server on i686 platform. This is a
hardware limitation of the platform related to how we consume atomic
types. This may lead to thread unsafety and other issues.
- FreeIPA server will not be available on i686 due to this
- slapi-nis set of plugins will not be available on i686 due to this
- Upgrade of i686 instance of Fedora with FreeIPA server will not be
possible without fully uninstalling FreeIPA replica
== Scope ==
* Proposal owners:
This only requires a change to spec file to exclude i686
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
#6894: https://pagure.io/releng/issues/6894
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* 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
3 months, 2 weeks
Open Seats on the Fedora Packaging Committee
by James Antill
The Fedora Packaging Committee has some open seats and is accepting
submissions from interested candidates to serve on the FPC.
The FPC would like to thank Ralf Corsepius, Dominik 'Rathann'
Mierzejewski, and Thomas Spura for their service.
This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also helping rewrite drafts
to resolve issues in a more acceptable fashion. Additionally, the FPC
reviews UID/GID soft static assignment.
Currently the FPC meets on IRC weekly, on alternate
Wednesdays/Thursdays based around 12:00 EST, for approximately an
hour.
However that is likely to change back to a single day/time slot, and
the time would depend on when is good for all the members (East Coast
US and German TZs, at least).
FPC members serve for as long as they are willing, there are currently
no term limits. All decisions are voted on using a +1 (for), 0
(abstain), and -1 (against) mechanism, and all decisions must be
approved by a majority (+5). FPC Meetings do not happen if quorum (5)
is not present. Candidates who are interested should provide the
following details to the FPC for consideration, by emailing it directly
to me (james(a)fedoraproject.org).
The FPC will consider all candidates, but strongly prefers candidates
who have extensive experience packaging in Fedora. We will accept
applications for the next two weeks (deadline Wednesday, 2018-03-14).
Name:
FAS Account:
Provenpackager? (Yes/No):
Main area of packaging interest/expertise:
Reason(s) for wanting to join the FPC:
Thanks in advance,
~James
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
4 months
Unacceptable size increase to ALL live images in F28 (caused by Annobin?)
by Kevin Kofler
Hi,
on #fedora-kde, we discussed a huge increase to the size of the KDE live
image:
F27 KDE GA: 1656752111 bytes
F27 KDE Respin: 1744830464 bytes
F28 KDE Beta: 2069889024 bytes
It turns out the LXQt live image is also hit:
F27 LXQt GA: < 1 GiB
F28 LXQt Beta: 1.4 GiB
and I am pretty sure that this is a global issue affecting ALL the live
images.
While there is certainly more than one cause (e.g., the difference between
F27 KDE GA and the F27 KDE Respin must be caused by package updates and/or
added dependencies), it is striking that between a recent F27 KDE Respin
(which has several of the KDE package updates that are also in the F28 Beta)
and the F28 Beta, there is a size increase of more than 300 MB!
Therefore, my question:
Is this size increase caused by Annobin?
If not, then WHAT causes this size increase? And can the offending change(s)
be reverted in time for F28 Final?
If yes, then IMHO it is time to enact the contingency plan, i.e.:
1. drop the annobin requirement from redhat-rpm-config, AND
2. perform an emergency mass rebuild to actually get rid of the bloat.
A global live image size increase of 19%-40% is just not acceptable.
Kevin Kofler
4 months
libqalculate soname change
by Mukundan Ragavan
I will be updating libqalculate to the latest upstream release (v2.2.1).
This involves a soname change. The following packages are affected.
plasma-workspace
step
cantor
qalculate-kde
I have built all these packages for rawhide and F28 in a COPR [0]. Since
we have the same versions on both rawhide and F28, I hope to push
libqalculate to both and rebuild all these packages.
If building for F28 is not preferred, please let me know. I anticipate
building everything by Friday (2018-03-08) and will proceed unless I
hear otherwise.
Mukundan.
[0] https://copr.fedorainfracloud.org/coprs/nonamedotc/libqalculate/builds/
4 months, 1 week
