devel April 2018

devel@lists.fedoraproject.org

177 participants
260 discussions

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

pdftk retired?
by Michael J Gruber 08 Sep '21

08 Sep '21

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael

17 26

Remove old GPG keys?
by Miroslav Suchý 04 May '21

04 May '21

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

15 29

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

Orphaning pykka
by Jonathan Dieter 05 Jan '20

05 Jan '20

I've just orphaned pykka (https://admin.fedoraproject.org/pkgdb/package /rpms/pykka/) as I'm no longer using it. Jonathan

3 4

Intel's Clear Linux optimizations
by František Zatloukal 08 Feb '19

08 Feb '19

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

15 50

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

Jump to page:

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