dnf5 default switch and soname bump in Rawhide

Hi, Given the positive feedback on the testing side-tag , this is now moving into the stable along with the soname bump. Thanks for the feedback, everyone! Jan -- ___ devel mailing list --

[EPEL-devel] Fedora EPEL 8 updates-testing report

The following Fedora EPEL 8 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-6327fb701b stb-0-0.45.20240213gitae721c5.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4edaf658b7 chromium-124.0.6367.118-2.el8 1

Re: Spec file using github repo - not tarball

Hello, Sorry I forgot to mention that all builds in Fedora require to be built offline so you still need to download the tarball and upload it to Fedora side-storage of source files before build: # spectool will process the specfile and download the tarball in expected name spectool -g

Re: Spec file using github repo - not tarball

Hello,  yes it is possible to refer to the git commit. For example https://src.fedoraproject.org/rpms/yara/blob/rawhide/f/yara.spec (I mostly use stable releases, but time to time I have to switch to a git snapshot during major version stabilization or when there is some public vulnerability

Re: Spec file using github repo - not tarball

Kenneth, You might be looking for the forge macros: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control -- Jonathan Steffan -- ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: mdadm Update in Rawhide

Yep, URLs for both will be in the next commit. Thanks On Wed, May 8, 2024 at 4:28 PM Carlos Rodriguez-Fernandez < carlosrodrifernan...@gmail.com> wrote: > If a maintainer changes the version, they would need to find the URL and > download the sign file again and do the switcharoo. The key, on

Re: mdadm Update in Rawhide

If a maintainer changes the version, they would need to find the URL and download the sign file again and do the switcharoo. The key, on the other hand, won't likely change, and if there is a change, it is good to detect it. Are you sure you don't want to make the signature also a url source

Re: mdadm Update in Rawhide

Thanks for the feedback and examples. My latest commit to rawhide adds signature verification and updates the source URL to https. https://src.fedoraproject.org/rpms/mdadm/c/c8d54b071aea9605ab75f3c5ff67d44d306e7fb2?branch=rawhide Updated build is building in the side tag:

Re: mdadm Update in Rawhide

I have this in the %prep in libcap, which is a similar situation: gzip -cd %{SOURCE0} | %{gpgverify} --keyring='%{SOURCE2}' --signature=' %{SOURCE1}' --data=- On Wed, May 8, 2024 at 1:45 PM Jonathan Wright via devel < devel@lists.fedoraproject.org> wrote: > I was having trouble finding the

Re: mdadm Update in Rawhide

Am 08.05.24 um 22:44 schrieb Jonathan Wright via devel: I was having trouble finding the public key(s).  I'll look more into this now. They sign the tar archive before it is compressed, so I'll have to stray from the standard way of verifying the sigs in the docs a little. Here is an

Re: mdadm Update in Rawhide

I was having trouble finding the public key(s). I'll look more into this now. They sign the tar archive before it is compressed, so I'll have to stray from the standard way of verifying the sigs in the docs a little. Thanks for the info. On Wed, May 8, 2024 at 3:16 PM Carlos

Re: Spec file using github repo - not tarball

On 08/05/2024 21:36, Kenneth Goldman wrote: Is it possible for a .spec file to clone a github.com repo rather than download a tarball? Can someone link to a working example? No, but github can give you a tar ball for any ref you want so why would you need/want to? Tom -- Tom Hughes

Spec file using github repo - not tarball

Is it possible for a .spec file to clone a github.com repo rather than download a tarball? Can someone link to a working example? I found a few hints that it's possible. However, the fedoraproject.org examples use pseudocode or placeholders. I'd like a working example. smime.p7s

Re: mdadm Update in Rawhide

Would you want to validate the tar download with the signature provided by upstream? It has ".sign" files [1]. The public keys should be in here [2] [1] https://mirrors.edge.kernel.org/pub/linux/utils/raid/mdadm/ [2] https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/keys On 5/8/24

Fedora CoreOS Community Meeting Minutes 2024-05-08

Minutes: https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-05-08/fedora-coreos-meeting.2024-05-08-16.30.html Minutes (text): https://meetbot-raw.fedoraproject.org//meeting-1_matrix_fedoraproject-org/2024-05-08/fedora-coreos-meeting.2024-05-08-16.30.txt Log:

Re: Testing package version is spec file

On 08. 05. 24 19:38, Brad Smith wrote: I help maintain a package where upstream changed the process to generate installed documentation. In version 1.30 and newer, the spec file needs to use process A; in versions older than 1.30 (e.g. 1.29.x, etc) the spec file needs to use process B. I am

Re: GIMP 3.0 in F41?

I believe once the GIMP 3.0 is out the Fedora version will follow almost immediately. Josef GIMP co-maintainer Dne po 6. 5. 2024 22:13 uživatel Dominik 'Rathann' Mierzejewski < domi...@greysector.net> napsal: > Hi! > > I noticed that GIMP 3.0 is scheduled[1] for release in June. It'd be > nice

Re: Testing package version is spec file

Thanks Adam. Yes there is a new shell script that does the new document generation. I experimented with using the %{exists: ...} macro but could not get it to work. If you have an example at hand I would greatly appreciate it. Best regards On Wed, May 8, 2024 at 10:46 AM Adam Williamson wrote:

Re: Testing package version is spec file

Thanks Tom. A good question. Basically upstream supports 3 or 4 versions concurrently so I need to maintain a spec file that works across this version boundary since the older versions will be available in Fedora for another year. Also there are forthcoming changes that make it desirable to have

Re: Testing package version is spec file

On 08/05/2024 18:38, Brad Smith wrote: I help maintain a package where upstream changed the process to generate installed documentation. In version 1.30 and newer, the spec file needs to use process A; in versions older than 1.30 (e.g. 1.29.x, etc) the spec file needs to use process B. I am

Re: Testing package version is spec file

On Wed, 2024-05-08 at 10:38 -0700, Brad Smith wrote: > I help maintain a package where upstream changed the process to > generate installed documentation. In version 1.30 and newer, the spec > file needs to use process A; in versions older than 1.30 (e.g. 1.29.x, > etc) the spec file needs to use

Testing package version is spec file

I help maintain a package where upstream changed the process to generate installed documentation. In version 1.30 and newer, the spec file needs to use process A; in versions older than 1.30 (e.g. 1.29.x, etc) the spec file needs to use process B. I am struggling to find a workable solution to

mdadm Update in Rawhide

Hi, I'm preparing to update mdadm from 4.2 to 4.3 in rawhide. There are no breaking changes and it's a relatively minor update except that this is my first major update to it since taking over the mdadm package from the previous maintainer after it was orphaned. The majority of the changes in

F41 Change Proposal: Multiple Versioned CRI-O and CRI-Tools Packages (self-contained)

This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. Wiki -

F41 Change Proposal: Multiple Versioned CRI-O and CRI-Tools Packages (self-contained)

This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. Wiki -

Orphaned packages looking for new maintainers

Report started at 2024-05-06 17:14:29 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason:

Orphaned packages looking for new maintainers

Report started at 2024-04-27 20:06:57 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason:

Re: Intent to start ARC investigation git-forge replacement

On Wed, 8 May 2024 at 10:17, Akashdeep Dhar wrote: > Hello folks, > > It has been a couple of weeks since Tomas announced the requirements > gathering phase and till now we have received about nine of those - all > from Maxwell G (by the way, thanks for your inputs) in the Fedora ARC issue >

Re: Intent to start ARC investigation git-forge replacement

Hello folks, It has been a couple of weeks since Tomas announced the requirements gathering phase and till now we have received about nine of those - all from Maxwell G (by the way, thanks for your inputs) in the Fedora ARC issue ticket[1]. I want to bump this up to folks' attention and ensure

Re: feedback about adding obsoletes/provides

On Tue, May 07, 2024 at 09:44:19PM +0200, Germano Massullo wrote: > A long time ago upstream keepassxc obsoleted upstream keepassx. > I now added obsoletes/provides [1] to the former spec file, > following Fedora packaging guidelines [2] and I would like to ask > for your feedback about the

Re: Review swaps

Hi! On Wed, May 8, 2024, at 12:05 AM, Fabio Valentini wrote: > On Tue, Apr 23, 2024 at 1:10 AM Kan-Ru Chen wrote: >> The other two are trivial rust packages that I need for upcoming libchewing >> release: >> >> rust-xflags-macrios: https://bugzilla.redhat.com/show_bug.cgi?id=2276537 >>

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

Am 08.05.24 um 00:22 schrieb Kevin Kofler via devel: Neal Gompa wrote: On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel wrote: Am 06.05.24 um 13:56 schrieb Florian Festi: Hi everyone, RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year

Fedora rawhide compose report: 20240508.n.0 changes

OLD: Fedora-Rawhide-20240507.n.0 NEW: Fedora-Rawhide-20240508.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 9 Dropped packages:2 Upgraded packages: 109 Downgraded packages: 2 Size of added packages: 2.45 MiB Size of dropped packages

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

On 5/8/24 00:49, Omair Majid wrote: > Hi, > > Florian Festi writes: > >> If anyone has any objections or would like to exclude a package, please >> let me know. > > Could you please exclude the .NET packages (dotnet6.0, dotnet7.0, > dotnet8.0)? dotnet8.0 shouldn't need a fix (and it doesn't

Re: Updating Taskwarrior to v3

On Tue, Apr 16, 2024 00:40:33 GMT, Randy Barlow via devel wrote: > As a tangent on this thread, it would be cool if there were a mechanism in > dnf to tell users when an upgrade needs special attention/instructions. > Another example like this is postgresql updates, which also require manual >

Re: Updating Taskwarrior to v3

On Mon, Apr 15, 2024 16:40:50 GMT, Michel Lind wrote: > Hi Ankur, Hi Michel, Sorry, I missed your reply before. > > What you can probably do now is to introduce the compat package > *first* into all stable releases - and make it obsolete the task > package at the current NEVRA. > Then for

Re: PWG+OpenPrinting meetup 2024

On Tuesday, 07 May 2024 at 18:40, Zdenek Dohnal wrote: > Hi all, > > I've joined the mentioned meetup to see what are the changes from the last > year and proposal what to do in the future. Thanks, Zdenek. Your summaries are very useful as usual! Regards, Dominik -- Fedora

Re: feedback about adding obsoletes/provides

On 07-05-2024 21:44, Germano Massullo wrote: A long time ago upstream keepassxc obsoleted upstream keepassx. I now added obsoletes/provides [1] to the former spec file, following Fedora packaging guidelines [2] and I would like to ask for your feedback about the correctness of the commit.