devel November 2018

devel@lists.stg.fedoraproject.org

227 participants
246 discussions

[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko 26 Jun '22

26 Jun '22

It's in redhat-rpm-config-118-1.fc30. If it causes any problems for you - let me know. In the meantime, you can use `%undefine _ld_as_needed` to disable it. Thanks for attention! -- -Igor Gnatenko

4 4

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

Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok 28 Mar '21

28 Mar '21

Recently I've reported some Big Endian related test failures to an upstream project [0]. I was asked by an upstream project maintainer, whether I know some free Continuous Integration services where they can easily run their testsuite on Big Endian. Any tips? * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu) * Upstream uses AppVeyor to test on Microsoft Windows * It's a pure Python project, noarch, but some changes need to be done when loading/saving binary data (LE) with NumPy on BE system. What I've considered: * COPR (but there is no big endian arch) * (Ab)using Koji (I guess that would be considered a bad practice?) * using QUEMU on Travis CI [1] Any better tips? Thanks [0] https://github.com/mikedh/trimesh/issues/249 [1] https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

8 10

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

Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
by Hans de Goede 04 Aug '20

04 Aug '20

Hi All, Just a quick headsup for users following Fedora 29, the dbus 1.12.10-1.fc29 build is missing the systemd dbus.service file, breaking almost everything. Instead it contains a dbus-daemon.service file, but the dbus.socket file expects a matching dbus.service, not dbus-daemon.service. So either hold of on applying updates until this is fixed or exclude dbus. Regards, Hans

17 28

Adding Obsoletes to generated -debuginfo packages ?
by Daniel P. Berrangé 04 Jun '20

04 Jun '20

In libvirt we recently deleted a driver for the legacy Xen toolstack. This was shipped in a libvirt-daemon-driver-xen RPM. I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users. If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade. How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

7 12

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

Use immutable CRAN URLs
by Iñaki Ucar 06 Nov '19

06 Nov '19

Hi, Currently, most of the R packages included in Fedora use the following lines in the SPEC: URL: https://cran.r-project.org/web/packages/%{packname}/ Source0: https://cran.r-project.org/src/contrib/%{packname}_%{version}.tar.gz This URL format is not recommended by CRAN, but more importantly, the Source0 format does not work anymore, as [1] noted, when a new version is released. However, there is an immutable format available, as [2] pointed out. So my proposal is to use always the following lines instead: URL: https://cran.r-project.org/package=%{packname} Source0: %{url}&version=%{version} which are both shorter and immutable, and I propose to add this to the R packaging guidelines too. If we agree on this, is there any easy way to request a system-wide change like that to all existing packages? Regards, -- Iñaki Ucar [1] https://stat.ethz.ch/pipermail/r-devel/2018-October/076988.html [2] https://stat.ethz.ch/pipermail/r-devel/2018-October/076989.html

5 28

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 November 2018