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

2022-12-06 Thread updates
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-63588ab702   
woff-0.20091126-11.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-058d69433a   
snapd-2.57.6-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-735d1baeca   
brotli-1.0.9-10.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-10049c7b14   
libbsd-0.11.7-2.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

dkms-3.0.9-2.el7
gsmartcontrol-1.1.4-3.el7
netdata-1.37.1-1.el7
purple-googlechat-0-1.20221106gitb6b824a.el7

Details about builds:



 dkms-3.0.9-2.el7 (FEDORA-EPEL-2022-18e9a882ea)
 Dynamic Kernel Module Support Framework

Update Information:

Update to 3.0.9.

ChangeLog:

* Tue Dec  6 2022 Simone Caronni  - 3.0.9-2
- Fix modprobe_on_install variable.
* Mon Dec  5 2022 Simone Caronni  - 3.0.9-1
- Update to 3.0.9.




 gsmartcontrol-1.1.4-3.el7 (FEDORA-EPEL-2022-6aaee02945)
 Graphical user interface for smartctl

Update Information:

Fixed require xterm.

ChangeLog:

* Tue Dec  6 2022 Vasiliy N. Glazov  - 1.1.4-3
- Added Requires xterm #2133082
* Thu Jul 21 2022 Fedora Release Engineering  - 
1.1.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

References:

  [ 1 ] Bug #2133082 - xterm should be listed as a gsmartcontrol package 
dependency
https://bugzilla.redhat.com/show_bug.cgi?id=2133082




 netdata-1.37.1-1.el7 (FEDORA-EPEL-2022-679aa9633d)
 Real-time performance monitoring

Update Information:

Update from upstream    Update from upstream

ChangeLog:

* Tue Dec  6 2022 Didier Fabert  1.37.1-1
- Update from upstream
* Fri Dec  2 2022 Didier Fabert  1.37.0-1
- Update from upstream

References:

  [ 1 ] Bug #2149829 - netdata-1.37.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2149829




 purple-googlechat-0-1.20221106gitb6b824a.el7 (FEDORA-EPEL-2022-aceeb13b75)
 Google Chat plugin for libpurple

Update Information:

Initial SPEC release.

ChangeLog:

* Tue Dec  6 2022 Vitaly Zaitsev  - 
0-1.20221106gitb6b824a
- Initial SPEC release.


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[EPEL-devel] Re: ELN Extras responsibility

2022-12-06 Thread Troy Dawson
I'm sorry, I clicked, "Send" too quickly.
If the document doesn't have that Note in it yet, please wait an hour an
check again.

On Tue, Dec 6, 2022 at 9:57 AM Troy Dawson  wrote:

> The ELN Extras page[1] was updated with one note.  I thought I'd share
> that note with the epel-devel mailing list.
>
> NOTE: **You** are responsible when your package fails to build on ELN
> Extras.  Remember to check your packages on the ELN Status Page.[2]
> ELN Extras packages get rebuilt much more frequently than in EPEL.
>
> I guess that's a little out of context.
> "You" means the person putting a package into ELN Extras.
>
> We just wanted to emphasize that when you put a package ELN Extras
> you are committing to make sure that package builds in ELN for the
> next three years, or whenever you remove it.
> ELN Extra packages get rebuilt a minimum of once every six month, usually
> more often.  It's whenever that package get's rebuilt in rawhide.
> Don't expect magic to happen.
> Check in on your packages frequently and make sure they are healthy.
>
> Troy
>
> [1] - https://docs.fedoraproject.org/en-US/eln/extras/
> [2] - http://distrobuildsync-eln-ops.apps.stream.rdu2.redhat.com/status
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[EPEL-devel] ELN Extras responsibility

2022-12-06 Thread Troy Dawson
The ELN Extras page[1] was updated with one note.  I thought I'd share that
note with the epel-devel mailing list.

NOTE: **You** are responsible when your package fails to build on ELN
Extras.  Remember to check your packages on the ELN Status Page.[2]
ELN Extras packages get rebuilt much more frequently than in EPEL.

I guess that's a little out of context.
"You" means the person putting a package into ELN Extras.

We just wanted to emphasize that when you put a package ELN Extras
you are committing to make sure that package builds in ELN for the
next three years, or whenever you remove it.
ELN Extra packages get rebuilt a minimum of once every six month, usually
more often.  It's whenever that package get's rebuilt in rawhide.
Don't expect magic to happen.
Check in on your packages frequently and make sure they are healthy.

Troy

[1] - https://docs.fedoraproject.org/en-US/eln/extras/
[2] - http://distrobuildsync-eln-ops.apps.stream.rdu2.redhat.com/status
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2022-12-06 Thread tdawson
Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2022-12-07 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




Source: https://calendar.fedoraproject.org//meeting/9854/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators

2022-12-06 Thread Jitka Plesnikova



Parametric macro dependency generators are not supported in EPEL 7 and
8's RPM versions. You can still implement this using a "regular"
dependency generator. This is also described in the RPM
documentation[1]. Instead of specifying %__perlcompat_requires() and
writing an RPM macro that accepts a path name as %1, you specify
`%__percompat_requires /path/to/executable`. That script receives a
newline separated list of paths as stdin and prints the generated
dependencies to stdout separated by newlines.

So perlcompat.attr could look something like

```
%__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version}

# %%__perlcompat_path can stay the same.
```

These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is
passed to the script as an argument, because the script of course
doesn't have access to the RPM context. This can be any executable
written in any language, but it should be straightforward to do this in
shell.


Thank you for your advice.

The dependency generator would be added to perl-srpm-macros which is in 
buildroot of Fedora.
So, I prepared package perl-srpm-macros-epel which should work for EPEL 
7/8/9.

If you want to check it please look at
https://jplesnik.fedorapeople.org/perl-srpm-macros-epel/

I checked it in Copr
https://copr.fedorainfracloud.org/coprs/jplesnik/perl-epel/.

If the change is approved by FESCo, I'll prepared the review for the 
package.

Then I'll ask you for adding it to epel-srpm-macros.

Regards,
Jitka

--
Jitka Plesnikova
Senior Software Engineer
Red Hat
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue