There is now 6.9.13-49 with several fixes. My nessus scans are full of Imagemagick issues
ImageMagick packages gives an "unmaintained" feel in EPEL, nobody seems to care...

I have created pull requests but nobody seems to care also...
https://src.fedoraproject.org/rpms/ImageMagick/pull-request/44
https://src.fedoraproject.org/rpms/ImageMagick/pull-request/45

Build fails since I don't have packager status and can't populate the lookaside cache, so if somebody could help here it would be great

@sergio @luya_tfz

Sorry, 
I no longer contribute directly to Fedora, and I don't have permission to perform merges or run builds.

Thanks for answering.
So is @luya still actively maintaining this ?

I just saw the notification. I am taking care for the merge.

Thanks for merging! How long does it take until builds are produced ?

Hmm, the build failed due to broken url see https://koji.fedoraproject.org/koji/taskinfo?taskID=146244609

Yes, because I don't have rights to populate the lookasidecache with the imagemagick sources:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/#upload_new_source_files

As far as I understood sources are not fetched from the original URL from the spec, they are fetched from the lookasidecache

And I don't have the permissions to upload sources to that cache, since i'm not a maintainer

That makes sense. I uploaded the source and the build went smooth. The update will come shortly.

I see the packages were built, but do not show up even in epel-testing until now

Seems there is still a missing step

I think they have to be submitted to bodhi via this form:
https://bodhi.fedoraproject.org/updates/new

Tried to do myself, but got a "permission denied"

I had to rebuild epel8 due to issue with s390x server. I was busy with day life and came back to see all builds are successful. Updating now.

Thanks for all the effort !! Really appreciate it

Notice that 6.9.13-49 is already outdated
Version 6.9.13-50 was released on June 5th with another set of security fixes
See https://github.com/ImageMagick/Website/blob/main/ChangeLog.md (GHSA means GitHub Security Advisory)

With a weekly release pace, it is nearly impossible to track.

Seems packit could help automate this ?
https://packit.dev/docs/fedora-releases-guide

It is already used for 7.x versions in fedora variants

A release monitoring project seems to exist, but currently contains one wrong tag for a 7.x version
https://release-monitoring.org/project/16253/

Other than that, it is better to at least update occasionally than never ;-)

Would you mind writing an yaml file for both EPEL 8/9?

Yes i will give it a go and will create pull requests for it

(In reply to Luya Tshimbalanga from comment #14)
> Would you mind writing an yaml file for both EPEL 8/9?

We already have release-monitoring.org project 390613 ready to use, i.e. the version already contains dots (6.9.13.50), so it should be enough to just copy packit.yaml and replace fedora-all with epel-8 and epel-9.

https://release-monitoring.org/project/390613/

I did some research on the topic

It seems release monitoring notifications always flow through rawhide first
And it os supposed to only have one linked project for one repo, which is https://release-monitoring.org/project/328484/ and reports 7.x versions only

local packit command is also hardcoded to lookup the "Fedora" rawhide linked project, and will always lookup versions from 328484

So it seems it is not possible to link specific branches to specific monitoring projects

One thing that propably coud ease the workflow with a packit.yaml, you can run packit locally and manually specifying the version number
This could help running the necessary steps to update and create merge requests, and trigger further steps like bhodi etc.

But it seems currently, no full automation of creating pull requests of new versions is possible

Is it then still worth it to have packit.yaml ?

(In reply to Sergio Basto from comment #16)
> (In reply to Luya Tshimbalanga from comment #14)
> > Would you mind writing an yaml file for both EPEL 8/9?
> 
> We already have release-monitoring.org project 390613 ready to use, i.e. the
> version already contains dots (6.9.13.50), so it should be enough to just
> copy packit.yaml and replace fedora-all with epel-8 and epel-9.
> 
> https://release-monitoring.org/project/390613/

Will this following line valid:

- job: pull_from_upstream
  trigger: release
  dist_git_branches:
    epel-9:
      fast_forward_merge_into:
        - epel-9

Hi,

I forgot to mention in my last comment that I'm not sure that pull_from_upstream [1] will work , because this was a feature that isn't much tested  https://release-monitoring.org/project/390613/ says to monitor EPEL


https://packit.dev/docs/fedora-releases-guide/dist-git-onboarding#pull-from-upstream-job

packit.yaml :

jobs:    
- job: pull_from_upstream    
  trigger: release    
  dist_git_branches:    
    epel-9:    
      fast_forward_merge_into:    
        - epel-8    
    
- job: koji_build    
  trigger: commit    
  allowed_pr_authors:    
    - all_admins    
    - packit    
  dist_git_branches:    
    - epel-9    
    - epel-8   
    
- job: bodhi_update    
  trigger: commit    
  dist_git_branches:    
    - epel-9    
    - epel-8

Thanks. I added that yaml file in EPEL9 branch.

https://release-monitoring.org/project/390613/ 
This project was created by me in the last few days, but I doubt it will trigger updates for EPEL automatically

From:
https://packit.dev/docs/configuration/downstream/pull_from_upstream

Requirements
The job is defined in a Packit config in the default branch of the dist-git repository (rawhide). Packit configs on other branches are ignored.
Upstream release monitoring is active for the package. The monitoring status in dist-git should be set to Monitoring.

Hmm, that mean moving the yaml file from EPEL9 branch to Rawhide. Learning how effectively use that functionality.

(In reply to Luya Tshimbalanga from comment #22)
> Hmm, that mean moving the yaml file from EPEL9 branch to Rawhide. Learning
> how effectively use that functionality.

I think we need to ask the Packit team in the Element/Matrix room about this. `pull_from_upstream` works automatically together with Release Monitoring, which was a feature that allowed Packit to handle ImageMagick versions where a hyphen needs to be converted to a dot (6.9.13-51 to 6.9.13.51), but it may not be prepared or designed to handle two different upstream release streams at the same time, in this case ImageMagick 6 for EPEL9 and ImageMagick 7 for Rawhide. Therefore, we may need to request this feature or file an RFE.