devel April 2018

devel@lists.fedoraproject.org

177 participants
264 discussions

Python3 will be in next major RHEL release, please adjust %if statements accordingly
by Troy Dawson 04 Oct '18

04 Oct '18

Hello, Python3 will be in the next major RHEL release. I don't mean RHEL 7.6, but with numbers higher than 7. There are many, many packages with something like the following if 0%{?fedora} %define with_python3 1 %endif If you have something like that, please change it to something like this. if 0%{?fedora} || 0%{?rhel} > 7 %define with_python3 1 %endif Thank You

21 40

kcov: code coverage for programs and python/shell scripts
by Dridi Boukelmoune 23 Aug '18

23 Aug '18

Greetings developers, I just submitted a review request [1] for kcov [2] that I recently discovered. It has no relation to Linux's kcov and is more akin to lcov, except that all it needs is a binary with DWARF debuginfo instead of requiring compile-time instrumentation. I came across kcov when I was looking for a way to measure code coverage in a Rust project and I'm impressed. It supposedly has a low overhead, but so far I've been monitoring small single-threaded programs so I can't really tell. I haven't tested python and shell support, although I have cases where it would be relevant, but I don't have time yet. The package itself is simple, but it bundles javascript and doesn't build on all main platforms so I may have to be granted an exception from some group starting with an F. Been busy lately, I'm a little behind on anything Fedora. If that's the case, please RTFM me a link to the wiki, and if you want to take the review I'll gladly take one in return. Cheers, Dridi [1] https://bugzilla.redhat.com/show_bug.cgi?id=kcov [2] https://simonkagstrom.github.io/kcov/index.html

1 1

Reliability test for hard drives and SSD
by Andrey Ponomarenko 08 Aug '18

08 Aug '18

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!

2 6

Intent to orphan Python 2
by Petr Viktorin 22 Jul '18

22 Jul '18

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/

25 65

Re: Serious problem with SATA LPM in F28 on Lenovo 50 series laptops
by Hans de Goede 31 May '18

31 May '18

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

6 17

Avoiding Jargon: dist-git
by Christopher 29 May '18

29 May '18

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

10 15

I would like to propose that we turn on XFS Reflink in Fedora 29 by default
by Daniel Walsh 25 May '18

25 May '18

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.

18 26

Recommended way to pass CFLAGS/LDFLAGS through libtool
by Florian Weimer 14 May '18

14 May '18

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

7 15

What to do when test gating in bodhi fails (no test results found)?
by Fabio Valentini 09 May '18

09 May '18

Hi, I've got two updates sitting in F26 and F27 updates-testing: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c455a245b0 https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d0e13ff51 I can't push either of them to batched or stable (despite them being in -testing for over 10 days now), because "no test results found". Which is really annoying and the error message is ... rather unhelpful, since it just tells me "I can't do this _shrug_", but not how to fix it. I guess this is caused by a bug in one of the involved components? Where can/should I report this issue? How can I fix this (if I can do it myself), or does somebody with more power have to step in to fix this? Thanks, Fabio

10 24

RANT: Packaging is changing too fast and is not well documented
by Richard Shaw 07 May '18

07 May '18

<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

10 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel April 2018