devel February 2020

devel@lists.fedoraproject.org

236 participants
422 discussions

Orphaning most of the ancient Gnome 1 stack
by Paul Howarth 07 Mar '20

07 Mar '20

Hi all, I've been looking after the ancient Gnome 1 library stack for the last decade as I had a local use for the libraries. That is no longer the case so I'm planning to orphan the following packages, none of which appear to be used by anything else in Fedora (Rawhide): * libglade * gnome-libs * ORBit * imlib * libxml * libpng10 (tested using: dnf repoquery --repo=rawhide{,-source} --whatrequires XXX ) I expect that nobody will pick them up and they'll get retired along with other orphaned packages in due course. If anyone actually has an interest in these packages, let me know and I'll transfer them. I'll still take care of the bottom two packages in the stack as they still have several users in Rawhide: * gtk+ * glib Regards, Paul.

2 2

Self Introduction: Dan Shoemaker
by Daniel Shoemaker 06 Mar '20

06 Mar '20

Hi, my name is Dan Shoemaker. I have been using Fedora since Fedora Core 6 for both personal and professional use. About five years ago I started developing bash scripts in order to start automating tasks I was doing while maintaining Linux servers for various clients. Last year I started taking Todd McLeod's Udemy class Learning Go and I found much to my delight that Fedora has a very active Go SIG. As a result I would love to become a package maintainer for the Go packages on Fedora. Dan

2 3

13 packages still requiring Python 3.7 in Fedora 32
by Miro Hrončok 05 Mar '20

05 Mar '20

In Fedora 32, we have updated Python to 3.8: https://fedoraproject.org/wiki/Changes/Python3.8 There are last 13 packages that were still not successfully rebuilt with Python 3.8 and they require Python 3.7 at run-time, causing broken dependencies. The packages are not installable. I don't think the bugzillas are moving anywhere. Technically, such noninstallable packages should be retired one week before the beta freeze. I'm writing this e-mail to raise awareness about the problem. Some of the packages are awaiting upstream fixes. mailman3 https://bugzilla.redhat.com/show_bug.cgi?id=1715598 mraa https://bugzilla.redhat.com/show_bug.cgi?id=1721671 python-bz2file https://bugzilla.redhat.com/show_bug.cgi?id=1728072 python-cartopy https://bugzilla.redhat.com/show_bug.cgi?id=1743898 python-geoplot https://bugzilla.redhat.com/show_bug.cgi?id=1773373 python-jenkins-job-builder https://bugzilla.redhat.com/show_bug.cgi?id=1706223 python-libpysal https://bugzilla.redhat.com/show_bug.cgi?id=1746849 python-missingno https://bugzilla.redhat.com/show_bug.cgi?id=1773375 python-nineml https://bugzilla.redhat.com/show_bug.cgi?id=1746850 python-nose-parameterized https://bugzilla.redhat.com/show_bug.cgi?id=1718347 python-subunit2sql https://bugzilla.redhat.com/show_bug.cgi?id=1746853 python-xarray https://bugzilla.redhat.com/show_bug.cgi?id=1773377 upm https://bugzilla.redhat.com/show_bug.cgi?id=1736936 Maintainers by package: mailman3 abompard mraa pbrobinson python-bz2file orphan besser82 python-cartopy qulogic python-geoplot qulogic python-jenkins-job-builder orphan ignatenkobrain ktdreyer pabelanger python-libpysal qulogic python-missingno lbazan python-nineml ankursinha python-nose-parameterized echevemaster python-subunit2sql chandankumar python-xarray qulogic upm pbrobinson Packages by maintainer: abompard mailman3 ankursinha python-nineml besser82 python-bz2file chandankumar python-subunit2sql echevemaster python-nose-parameterized ignatenkobrain python-jenkins-job-builder ktdreyer python-jenkins-job-builder lbazan python-missingno pabelanger python-jenkins-job-builder pbrobinson mraa upm qulogic python-cartopy python-geoplot python-libpysal python-xarray -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 6

Automatic close of bugs for retired packages?
by Pavel Raiskup 03 Mar '20

03 Mar '20

I today tried to mimic something that random Fedora user can do, and I submitted bug against one of our long-time retired components. I haven't been warned at all that the package is dead. As user, it is easy to pick a wrong component when filling a bug - but the problem with orphaned/retired packages is that nobody listens there usually. Only 'Orphan Owner <extras-orphan(a)fedoraproject.org>'. Should such reports be kindly closed automatically by some bot, so user can reopen against different component? Or should we drop the component from bugzilla? Pavel

5 4

Ideas and proposal for removing changelog and release fields from spec file
by Pierre-Yves Chibon 03 Mar '20

03 Mar '20

Good Morning Everyone, This topic has already been discussed a few times over the past month, but Adam Saleh, Nils Philippsen and myself have had the opportunity to invest some time on it with the hope of making the packager's life simpler as well as making it easier to build automation around our package maintenance. We have investigated a few ideas, the full list with their pros and cons can be found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev If you have any questions about some of these, please ask them, we'll be happy to answer them and potentially complete this document. For both the release and the changelog fields we believe using RPM macros would satisfy the requirements we have for opting-in/out: - You can easily opt-in by using the macros - You can easily opt-out by removing the macros from your spec file For the changelog, we believe we have a potential good solution: - The changelog will be automatically generated using an external `changelog` file as well as the commit history - When you opt-in, you will simply move the existing changelog to an external file `changelog`, which is placed in the dist-git repo and add the appropriate macro. - Upon building, the macro will generate the changelog using all the commits of the repo up to the last commit touching the `changelog` file. Of all these commits it will only consider the commits following these rules: - There are generally two approaches regarding what to include by default: 1. commits touching only the `sources`, `.gitignore`, `dead.package` files, `tests` folder will be ignored by default, i.e. a blacklist 2. only commits touching the spec file or patches will be included by default, i.e. a whitelist ==> Which approach do you think is better/will work in most cases? - empty commits (not touching any files) will be included on the assumption that this is their purpose - commits containing "magic keyword" (#changelog_exclude, #changelog_include?) will be ignored or included as the case may be - Finally the content of the changelog file specified will be appended to the changelog generated from the git history If you wanted to edit the changelog, you would: - Generate the changelog locally via a command like: `fedpkg generate-changelog > changelog` - Edit `changelog` as desired - Commit and push the changes Since the macro will only consider the commits up to the first commit touching `changelog` (in other words, the macro will only consider the commits after this one) and include `changelog` file as is, your edits will appear in the RPM changelog as you want. One thing to note is that rebuilds from the same commit will have the same %changelog, they will not get a new entry. If you want a new changelog entry, you have to create a new commit with the desired changelog entry as commit message (the commit itself can be empty). However, for the release field, we are struggling a little bit more, two options are more appealing to us: A) The release field is automatically generated using two elements: - the number of commits at this version - the number of builds at this commit - the dist-tag being added after them The release field would thus look like: ``<number of commit at version>.<number of build at commit>%{dist}`` So we could have: (A, B, C and D being different commits) A -- version: 0.9 -- release: ? | B -- version: 1.0 -- release: 1.0 | C -- version: 1.0 -- release: 2.0 | D -- version: 1.1 -- release: 1.0 A rebuild of the commit D, would lead to a release 1.1 (assuming the first one succeeded)/ Pros: - Easy to replicate locally - Every changelog entry can be mapped to a `version-release` (No changes to the packaging guidelines) - Allows triggering two builds from the same commit without any manual change (simplifies mass-rebuilds) - Easy to link a certain build with a specific commit - Easy to “guess” the next release value before triggering the build Cons: - Old packages which are no longer receiving upstream releases may need special care (for example if they are at the release -48 but only had 45 commits leading to this) - Relies on information from the build system for the build number (but can be closely simulated locally since the <n_build> info is only used for rebuilds) - Upgrade path may be problematic if Fn is upgraded to version X with one commit while Fn-1 is upgrade to version X with 2 commits (or more) B) The release field is automatically generated taking existing builds in all current Fedora releases (ie: rawhide, Fn, Fn-1...) into account. This means for builds of the same epoch:version, find a new release that (if at all possible) ensures upgradability from older Fedora versions to newer ones, adhering to the structure of a release tag documented in the Versioning Guidelines[1]. Going from the (RPM-wise) "latest build" that the new one should surpass, this can mean bumping in the front (`pkgrel`) or the back (`minorbump`). This allows packages from "very stable" upstreams who haven't released in years to still benefit from automatically generated releases. The following examples would use a macro for the release field as outlined in a separate document[2]. Example #1 ("normal" release progression): Rawhide has: 2.0-1.fc32 F31 has: 1.0-1.fc31 F30 has: 1.0-1.fc30 Next release in F31: 1.0-2.fc32 Example #2 ("hotfix" in an older release, selected by an alternative macro (or option) in the spec file): Rawhide has: 2.0-1.fc32 F31 has: 1.0-1.fc31 F30 has: 1.0-1.fc30 Next release in F30: 1.0-1.fc30.1 Example #3 (pre-release, selected by an alternative macro (or option) in the spec file): Rawhide has: 2.0-1.fc32 F31 has: 1.0-1.fc31 F30 has: 1.0-1.fc30 Next release in Rawhide: 3.0-0.1.20200224git1234abcd Pros: - Allows triggering two builds from the same commit without manual intervention - Emulates what many maintainers do manually today for most use cases - Can cater for pre-releases (e.g.: by offering different macros or macro options for the different use cases) Cons: - Needs the build system for information about builds in this and other Fedora versions - Not easy to reproduce locally because we don’t have machine-consumable knowledge about other builds in e.g. the dist-git repo - Does not allow to generate changelog entries with `version-release` information for all commits (and this will require a change in our packaging guidelines) So these are the results of our current investigations, we are very much eager to get your feedback on them and even more eager if you have ideas on how to approach/solve some of the challenges mentioned here. Looking forward for the discussion, Pierre For Adam, Nils and myself [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ [2]: https://hackmd.io/kuXOPe74RfepuztBz7pBsg

22 95

Re: Non-responsive maintainer: pocock
by Dakota Williams 02 Mar '20

02 Mar '20

On 2/26/20 6:59 PM, Daniel Pocock wrote: > > > On 26/02/2020 22:56, Dakota Williams wrote: >> On 2/24/20 5:57 PM, Daniel Pocock wrote: >>> >>> >>> On 24/02/2020 20:47, Dakota Williams wrote: >>>> Does anyone know how to contact maintainer pocock? >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1806708 >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1790674 >>> >>> >>> Like most developers, I have a backlog of things to deal with and I try >>> to coordinate fixes for packaging issues into the right part of the >>> release cycle >>> >> >> Would you like help? I'd be willing to be a co-maintainer to make the >> branch. > > Yes, I would welcome help with these packages > > But there is also an increasing problem of making decisions about trust > > In the case of developers who I haven't met or worked with, I don't > really know how to proceed > > I've seen several extraordinary examples of developers doing things that > undermine my confidence in them over the last couple of years. The > fighting within GNU and FSF right now is the latest iteration of that. > > Now, whenever I receive a request from somebody I don't know, there is > an extra effort for me to decide how to proceed. > > Maybe I can simply resign from maintaining the asio package and then opt > out of the process of choosing a new maintainer. > > Please don't take this personally: it is a reflection of the overall > state of free software communities today. > I don't know about the situation with the GNU project and the FSF, but if there's something you'd like me to do to prove trust, I could do it.

5 4

Build into < Rawhide side tag fails with "Package ... has already been built"
by Richard W.M. Jones 02 Mar '20

02 Mar '20

I built ocaml-4.10.0-1.fc33 yesterday. Now I want to build ocaml-4.10.0-1.fc32 into a side tag today, but builds fail with: $ fedpkg request-side-tag --base-tag f32-build Side tag 'f32-build-side-19863' (id 19863) created. Use 'fedpkg build --target=f32-build-side-19863' to use it. Use 'koji wait-repo f32-build-side-19863' to wait for the build repo to be generated. $ fedpkg build --target=f32-build-side-19863 Could not execute build: Package ocaml-4.10.0-1 has already been built Note: You can skip this check with --skip-nvr-check. See help for more info. This is wrong isn't it? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html

6 14

Generate list of my packages
by Orion Poplawski 01 Mar '20

01 Mar '20

Can someone point me to a way to generate a list of non-retired packages that I am a maintainer on? Thanks. Hunting around for a "pagure cli" doesn't bring up much that seems active. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

3 4

Package reviews
by Antonio Trande 29 Feb '20

29 Feb '20

Hi all. I have two new packages ready for the review: https://bugzilla.redhat.com/show_bug.cgi?id=1808573 https://bugzilla.redhat.com/show_bug.cgi?id=1808571 I'm available to review other packages in return. -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/

1 0

Fedora 32 compose report: 20200229.n.0 changes
by Fedora Branched Report 29 Feb '20

29 Feb '20

OLD: Fedora-32-20200228.n.0 NEW: Fedora-32-20200229.n.0 ===== SUMMARY ===== Added images: 0 Dropped images: 0 Added packages: 1 Dropped packages: 0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 1.09 MiB Size of dropped packages: 0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B ===== ADDED IMAGES ===== ===== DROPPED IMAGES ===== ===== ADDED PACKAGES ===== Package: rust-zram-generator-0.1.2-2.fc32 Summary: Systemd unit generator for zram devices RPMs: zram-generator Size: 1.09 MiB ===== DROPPED PACKAGES ===== ===== UPGRADED PACKAGES ===== ===== DOWNGRADED PACKAGES =====

1 0

← Newer
1
2
3
4
5
6
7
8
...
43
Older →

Jump to page:

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 February 2020