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 day, 21 hours
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/
4 days, 3 hours
Re: Serious problem with SATA LPM in F28 on Lenovo 50 series laptops
by Hans de Goede
Hi,
On 29-04-18 09:25, Hans de Goede wrote:
> Hi All,
>
> I'm sending this to the fedora-kernel and -devel lists
> both to get the kernel team aware of this and because it
> is not entirely clear to me how to best deal with this.
>
> I guess we should get this added to the release-notes /
> common-bugs page for F28, but I'm not sure what the
> procedure is for that ?
>
> I've just become aware that at least for some users
> the use of SATA LPM in F28 causes the Lenovo 50
> series laptops (confirmed X250, T450s G50-80) freeze/
> hang hard under certain conditions when using SATA
> LPM, independent of the disk used (*).
>
> This is currently being tracked in:
> https://bugzilla.redhat.com/show_bug.cgi?id=1571330
>
> A known workaround is to add: "ahci.mobile_lpm_policy=0"
> to the kernel boot command line.
>
> Can someone help me to get this documented? Once we've
> figured out what is going on I hope to be able to fix this
> with a kernel update, but people may still need the
> workaround to install Fedora 28.
>
> Also if people are using Fedora 28 on a 50 series Lenovo
> laptop without issues, please let me know.
Some more info on this, the user with a x250 is reporting
the problem is hard-freeze about once a day, which goes
away when disabling LPM, so if you have a 50 series Lenovo
laptop and are seeing the occasional hard-freeze this may
be the cause.
Regards,
Hans
1 month, 3 weeks
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
1 month, 3 weeks
I would like to propose that we turn on XFS Reflink in Fedora 29 by
default
by Daniel Walsh
We are adding some features to container projects for User Namespace
support that can take advantage of XFS Reflink. I have talked to some
of the XFS Reflink kernel engineers in Red Hat and they have informed me
that they believe it is ready to be turned on by default.
I am not sure who in Red Hat I should talk to about this? Whether we
should turn it on in the installer or in the mkfs.xfs command?
Who should I be talking to? To make this happen.
1 month, 3 weeks
Recommended way to pass CFLAGS/LDFLAGS through libtool
by Florian Weimer
Is there a recommend way to get libtool to pass through all flags
specified in CFLAGS and LDFLAGS unchanged, and have the GCC compiler
driver sort out which flags to pass to the compiler/assembler/linker?
Thanks,
Florian
2 months, 1 week
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
2 months, 2 weeks
Fedora Workstation and Third-Party Repositories
by David Benoit
Hi all,
Regarding the inclusion of the fedora-workstation-repositories package in
F28, is there currently a policy in place against including it as a
dependency? From what I understand from the recent fedora magazine article
<https://fedoramagazine.org/third-party-repositories-fedora/> and the policy
wiki page
<https://fedoraproject.org/wiki/Workstation/Third_party_software_policies?...>,
the purpose of distributing the third-party repositories an rpm is to
ensure that a user must enable them explicitly.
Is there some some preventative measure in place to protect users from the
package being pulled in silently as a dependency? If repository-enabling
rpms are to become acceptable cases for package submissions, what
considerations are being taken to ensure such submissions are tracked and
handled similarly?
Apologies if this has been addressed before, but I haven't been able to
find any documentation on the subject.
Thanks,
DB
2 months, 2 weeks
