[EPEL-devel] Re: EPEL 10 status update

2024-09-06 Thread Leon Fauster via epel-devel 

Am 04.09.24 um 05:46 schrieb Carl George:

On Tue, Sep 3, 2024 at 1:16 PM Leon Fauster via epel-devel


I wonder if RHEL10 will have a Workstation flavor? Or if CS10 will be
usable as Workstation OS. When I see all the missing/removed parts.
Can not imagine that EPEL can compensate this all (e.g. is firefox in
the compose?).



Why can't EPEL compensate for this?  If RHEL doesn't ship it, then
it's probably eligible to be shipped in EPEL.  Several desktop apps
such as firefox were dropped, but all it takes is someone willing to
maintain them in EPEL 10.  If there is a package you rely on that was
dropped, then become a packager and file a bug asking the Fedora
maintainer to add you as a co-maintainer.



I had more the needed human resources then the technical
part in mind. BTW, thanks for your work on EPEL!

I do already my best in providing testing/integration time
and bug reports to elevate the quality of the available packages.

--
Leon



--
___
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: EPEL 10 status update

2024-09-03 Thread Leon Fauster via epel-devel 

Am 03.09.24 um 18:00 schrieb Troy Dawson:
On Sun, Sep 1, 2024 at 3:03 PM Gary Buhrmaster 
mailto:gary.buhrmas...@gmail.com>> wrote:


On Sat, Aug 10, 2024 at 10:42 PM Carl George mailto:c...@redhat.com>> wrote:

 >
 > Happy packaging!
 >

I have noted that some dependencies for some
of my packages are (apparently) no longer
going to be shipped in EL10 (they were in
EL9).

Before I request the branches and builds
in EPEL10, I would like to make sure those
packages are really removed from EL10, and
are not some artifact of my misunderstandings.

Is there a list somewhere of packages that
are known to have been removed from EL10?


Three things I do.
1 - Go to the CentOS Stream koji instance, look up the package, look at 
the latest el10 build of that package, and see if it's tags have been 
removed, or it has a trashcan tag.

Examples:
bash (still there) - 
https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779 

java-17-openjdk (removed) - 
https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493 



2 - dnf list 
This isn't the best.  Sometimes a package is still in the process of 
being removed.  Or it's been untagged, but we haven't had a successful 
compose pushed out.

But, it's still a quick way to check.

3 - jira search
The CentOS Stream 10 package removals are public in jira.  We have a tag 
for centos-stream-10 package removals.
This isn't 100% accurate, because sometimes the package has been 
re-added, but that is rare.

https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-package-removal
 





I wonder if RHEL10 will have a Workstation flavor? Or if CS10 will be 
usable as Workstation OS. When I see all the missing/removed parts.

Can not imagine that EPEL can compensate this all (e.g. is firefox in
the compose?).


--
Leon





--
___
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: NetworkManager-openvpn

2024-07-18 Thread Leon Fauster via epel-devel 

Am 18.07.24 um 12:36 schrieb Íñigo Huguet:



but more important, the new release (1.12.0) requires NetworkManager >=
1.46.2 explicitly!

https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/blob/main/NEWS


There is no problem here. I did the fixes upstream, and I backported
them to RHEL 9.4 (via NM 1.46.0-11). So in the upstream
NetworkManager, the fix is available only from 1.46.2, but in RHEL it
is available in 1.46.0-11.



Ah, I see, then everything is clear and fine. Thanks for the backport.



So, correct me if I am wrong but for RHEL9.4 (via EPEL9) it can not be
shipped BUT for CentOS Stream 9 (via EPEL9-NEXT) if you want ...


I backported the patches with the hope of being available for RHEL
9.4. The only real problem that I still see is that "it's not common
to include the release number in the requires statements". As I said,
I will trust others' opinions about this.



Using a NEVR is valid but I do not see it that much, and with the 
mentioned patch obviously necessary.




Not sure how to include it in epel-next, though, I don't see any
`epel*-next` branch in NetworkManager-openvpn dist-git. I will need to
read the docs, I guess.


Well, with the upcoming release (1.46.0-11) its not necessary ...


--
Leon

--
___
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: NetworkManager-openvpn

2024-07-18 Thread Leon Fauster via epel-devel 

Am 18.07.24 um 09:35 schrieb Íñigo Huguet:

I have sent a new build that will work with RHEL 9.4 to testing. I've
set the dependency as `Requires: NetworkManager-1.46.0-11`, as this
release contains the patch that makes it meet the requirement from
NetworkManager-openvpn-1.12.

Only RHEL 9.4 ships NetworkManager-1.46 and RHEL 9.5 will ship 1.48,
so all should be fine.



Hi Íñigo,

not sure if this is the right path. What I see is that,

  - RHEL9.4 is on 1.46.0-8,
  - Its not common to include the release number
in the requires statements (11)
  - with both said, the dependency can not be resolved (8<11)

but more important, the new release (1.12.0) requires NetworkManager >= 
1.46.2 explicitly!


https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/blob/main/NEWS


So, correct me if I am wrong but for RHEL9.4 (via EPEL9) it can not be
shipped BUT for CentOS Stream 9 (via EPEL9-NEXT) if you want ...

--
Leon



--
___
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: [EPEL-devel]NetworkManager-openvpn

2024-07-04 Thread Leon Fauster via epel-devel 

Am 01.07.24 um 18:53 schrieb Carl George:

Based on the upstream commit message for the 1.12.0 release, it does
seem that the dependency is intentional and correct for the software.

https://github.com/NetworkManager/NetworkManager-openvpn/commit/a476b439fc28bdd55a9277113a72040fb94b011b

Of course it isn't correct to be released in EPEL 9 if the dependency
cannot be met by what is currently available in RHEL 9
(NetworkManager-1.46.0-8.el9_4).  CentOS Stream 9 has a new enough
version (NetworkManager-1.48.0-1.el9), but it's unlikely for that
build to show up in RHEL 9 until 9.5 is released.  This update cannot
be pushed to stable.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-7748f06d0d




So, a candidate for epel9-next ...

--
Leon
--
___
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]NetworkManager-openvpn

2024-06-30 Thread Leon Fauster via epel-devel 

epel-testing (epel9) provides a new NetworkManager-openvpn package
that requires NetworkManager >= 1:1.46.2, and that one is currently
not provided by RHEL9. Is this intentional ...?

--
Leon
--
___
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: Contact to Oracle Linux EPEL repo maintainer

2024-05-31 Thread Leon Fauster via epel-devel 

Am 31.05.24 um 15:30 schrieb Troy Dawson:
On Fri, May 31, 2024 at 2:48 AM Peter Soppe > wrote:


Hello EPEL Team,

I am trying to find out how to contact the maintainer of the Oracle
Linux EPEL repository.
The only website I found about EPEL and Contact is
https://fedoraproject.org/wiki/EPEL/FAQ#contact


My current issue is that I use the Oracle Linux 8 EPEL package
"cacti" - and there is a security issue that is solved in cacti
Version 1.2.27 (2024-05-12).

This version is available in the Fedora/RHEL Epel
https://packages.fedoraproject.org/pkgs/cacti/cacti/
  since
2024-05-21 (9 days after release)
but not in the Oracle Linux EPEL:
https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/x86_64/index.html 

Here the latest available Version is 1.2.23 (2023-01-13) which is
about 19 months old.

I want to know if there are plans to update the cacti version in the
Oracle EPEL repo and if yes what is the planned timeline to do so.

Best regards,
   Peter Soppe


Although the Oracle Linux EPEL repository has the word "EPEL" in it, it 
is a repository supported and maintained by Oracle Linux.  Similar to 
the CentOS Extras repo.

As such, we can only  point you back to the distribution and its community.

https://support.oracle.com/ 

I did try looking for other information, but everything I found only had 
a heading and to get more information I needed to create an Oracle 
account and log in, which I am not willing to do.





@Peter why not using the original repo -> EPEL of EPEL :-)

https://docs.fedoraproject.org/en-US/epel/

(do not forget to disable the EPE(O)L repo of Oracle).


--

Leon


--
___
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: EL9: conflict gpgme1.22 vs gpgme

2024-02-06 Thread Leon Fauster via epel-devel 

Am 06.02.24 um 16:57 schrieb Leon Fauster:

Hi troy,

after deinstalling gpgme1.22 I get a broken linkage.
This link should not happen in the first place, right?


# ls -la /usr/lib64/libgpgme*
lrwxrwxrwx. 1 root root 20  6. Feb 14:35 /usr/lib64/libgpgmepp.so.6 
-> libgpgmepp.so.6.19.0
lrwxrwxrwx. 1 root root 19  6. Feb 14:35 /usr/lib64/libgpgme.so.11 
-> libgpgme.so.11.31.0

-rwxr-xr-x. 1 root root 350864 13. Mai 2022  /usr/lib64/libgpgme.so.11.24.1

# rpm -qf /usr/lib64/libgpgme.so.11
gpgme-1.15.1-6.el9.x86_64





It seems that libreoffice-core needs "libgpgmepp.so.6()(64bit)" and dnf 
chooses  gpgme1.22 from epel instead gpgme from appstream.



# LANG=C dnf whatprovides "libgpgmepp.so.6()(64bit)"
Last metadata expiration check: 4:43:48 ago on Tue Feb  6 12:21:37 2024.
gpgme1.22pp-1.22.0-1.el9.x86_64 : C++ bindings/wrapper for GPGME
Repo: epel
Matched from:
Provide: libgpgmepp.so.6()(64bit)

gpgmepp-1.15.1-6.el9.x86_64 : C++ bindings/wrapper for GPGME
Repo: appstream
Matched from:
Provide: libgpgmepp.so.6()(64bit)


--
Leon
--
___
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] EL9: conflict gpgme1.22 vs gpgme

2024-02-06 Thread Leon Fauster via epel-devel 

Hi troy,

after deinstalling gpgme1.22 I get a broken linkage.
This link should not happen in the first place, right?


# ls -la /usr/lib64/libgpgme*
lrwxrwxrwx. 1 root root 20  6. Feb 14:35 /usr/lib64/libgpgmepp.so.6 
-> libgpgmepp.so.6.19.0
lrwxrwxrwx. 1 root root 19  6. Feb 14:35 /usr/lib64/libgpgme.so.11 
-> libgpgme.so.11.31.0

-rwxr-xr-x. 1 root root 350864 13. Mai 2022  /usr/lib64/libgpgme.so.11.24.1

# rpm -qf /usr/lib64/libgpgme.so.11
gpgme-1.15.1-6.el9.x86_64



--
Leon
--
___
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: VLC via EPEL vs via RPMFUSION

2024-01-09 Thread Leon Fauster via epel-devel 


Hi Dominik, thanks for your reply.


Am 09.01.24 um 10:16 schrieb Dominik 'Rathann' Mierzejewski:

Hello, Leon.

On Monday, 08 January 2024 at 17:18, Leon Fauster via epel-devel wrote:

Hi all,

it seems that VLC is in EPEL9 now. Looks like some license changes
allows packaging some multimedia stuff now. I noticed also the
new epel-cisco-openh264 repo.

Unfortunately, I'm not involved in the upstream/Fedora discussions.
So, I miss some kind of documentation. A look into Fedoras Wiki also
doesn't show any article that explains the current status/motivation
/limitations of such components and their differences to RPMFUSIONs
one.  Also the concept of "freeworld" packages is unclear (at least to
me).


What kind of documentation would you like to see? What exact questions
woud you like to see answered in such documentation?




I used documentation with a lightweight sense. Mainly I had something in 
mind that would help the "user" and/or the foreign developer (non rpm 
dev) to catch up with the current changes in the EL "ecosystem".


For instance, a recent change in the epel-release package [1] could be 
further highlighted with this Wiki entry (albeit more focused on fedora 
linux) https://fedoraproject.org/wiki/OpenH264


There should be no detailed documentation about this, but the wiki
entry gives at least an idea whats going on.

Regarding the VLC restructuring I can't find anything (until today I
wasn't subscribed to rpmfusion lists for some reason , my fault, but
I'm now). And I do not see any change-request for inclusion into Fedora
(maybe I'm not so familiar with such process).

So, IMHO a "Multimedia" Wiki entry that highlights the current efforts
would be a great help in this aspects. Especially, the coming
compartmentation of functionality (codecs) via plugins provided by
both "repos".








Some RPMFUSION packages were in conflict with the new packages in
epel- testing. Currently, the conflicts are resolved but the
epel-testing packages would overwrite the ones installed from
RPMFUSION now (someone stated no assurance for such repo
compatibility).


Perfect coordination is, unfortunately, not possible. Even if we pushed
the packages to testing and to stable repos at the same time in both
Fedora and RPM Fusion, there will still be delays due to mirroring.




Sure, for that reason I take actively a look into the impacts of 
enabling the testing repos. So, its good to have this layer.





Any pointers to sources/docs/threads that explains the new strategies
and activities or any other suggestions to read would be greatly
appreciated.


I did a presentation on this topic at a local conference last year, but
it seems they haven't put it online yet. I'll try to post my slides when
I find them at least.



That would be for sure interesting to read!






BTW, do the RPMFUSION and Fedora Devs coordinate such overlap? Where?


We usually do it over bugzilla[1] and e-mail[2]. Sometimes on IRC[3] and
Matrix[4].

"We" here means the Multimedia SIG:
https://fedoraproject.org/wiki/Category:Multimedia_SIG



Not sure if I could help out in this SIG. Especially or mainly for the 
EL branch.


--
Thanks,
Leon



[1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e3199f53c
--
___
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] VLC via EPEL vs via RPMFUSION

2024-01-08 Thread Leon Fauster via epel-devel 

Hi all,

it seems that VLC is in EPEL9 now. Looks like some license changes
allows packaging some multimedia stuff now. I noticed also the
new epel-cisco-openh264 repo.

Unfortunately, I'm not involved in the upstream/Fedora discussions.
So, I miss some kind of documentation. A look into Fedoras Wiki also
doesn't show any article that explains the current status/motivation
/limitations of such components and their differences to RPMFUSIONs one.
Also the concept of "freeworld" packages is unclear (at least to me).

Some RPMFUSION packages were in conflict with the new packages in epel-
testing. Currently, the conflicts are resolved but the epel-testing
packages would overwrite the ones installed from RPMFUSION now
(someone stated no assurance for such repo compatibility).

Any pointers to sources/docs/threads that explains the new strategies 
and activities or any other suggestions to read would be greatly

appreciated. BTW, do the RPMFUSION and Fedora Devs coordinate such
overlap? Where?


--
Thanks,
Leon
--
___
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: cloud-utils-growpart package conflict

2023-12-11 Thread Leon Fauster via epel-devel 

Am 11.12.23 um 20:29 schrieb Neal Gompa:

On Mon, Dec 11, 2023 at 2:19 PM Leon Fauster via epel-devel
 wrote:


While updating to EL8.9 I noticed that cloud-utils-growpart is in EPEL
and RHEL8?

cloud-utils-growpart noarch 0.33-0.el8 rhel-8-for-x86_64-appstream-rpms

cloud-utils-growpart noarch 0.33-3.el8 epel

Subpackage conflict?



This is definitely a mistake, can you please file a bug against
cloud-utils in EPEL 8? In RHEL 8, cloud-utils-growpart was packaged
individually, but in RHEL 9, it's done using the cloud-utils
packaging. That is likely how it was missed, since the source packages
don't match.



https://bugzilla.redhat.com/show_bug.cgi?id=2254077

--
Leon

--
___
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] cloud-utils-growpart package conflict

2023-12-11 Thread Leon Fauster via epel-devel 
While updating to EL8.9 I noticed that cloud-utils-growpart is in EPEL 
and RHEL8?


cloud-utils-growpart noarch 0.33-0.el8 rhel-8-for-x86_64-appstream-rpms

cloud-utils-growpart noarch 0.33-3.el8 epel

Subpackage conflict?

--
Leon
--
___
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: chromium regression on EL9

2023-11-21 Thread Leon Fauster via epel-devel 

Am 20.11.23 um 21:42 schrieb Leon Fauster:

Am 20.11.23 um 01:38 schrieb Neal Gompa:

On Sun, Nov 19, 2023 at 5:25 PM Leon Fauster via epel-devel
 wrote:


Am 19.11.23 um 14:30 schrieb Neal Gompa:

On Sat, Nov 18, 2023 at 4:20 PM Leon Fauster via epel-devel
 wrote:


Just noticed that the current chromium in epel-testing can not be
installed on E9 with rpmfusion repo enabled. All versions before 
did not
have this problem. It seems the build pulls a new dep 
(libavformat-free)

that conflicts with ffmpeg-libs of rpmfusion. This results in an
incompatibility with rpmfusion repos. Is this intentional?



Yes. If you want expanded codec support, install the
libavcodec-freeworld overlay package instead.







Not sure what scenario is supported now. A common
workstation setup has rpmfusion applications installed
(ffmpeg, mpv, libavcodec-freeworld). Do I understand
it correctly that I must remove ffmpeg-libs to install
chromium now?
Not sure if the new spec design with "Conflicts: ffmpeg-libs"
has more a fedora context in mind. As both packages
libavcodec-free and ffmpeg-libs provide the needed lib.




Strictly speaking, from a Fedora context, RPM Fusion is not supported
beyond limited cases. That said, EPEL has mpv itself too.

The "recommended" (as far as recommendations go when it comes to third
party repositories) path is to use Fedora's ffmpeg-free stack and then
install libavcodec-freeworld on top if there are codecs you are
missing that you need. That package overlays a libavcodec build that
includes things Fedora cannot ship at this time.



Thanks Neal for the overview.

The specific issue was addressed now.

https://src.fedoraproject.org/rpms/chromium/c/cfac4f7e0f0cae0daffbbad5c4c82b8c83e0c822?branch=epel9

Lets see when its in the repo.




JFI - rpmfusion's packages can coexists now. With the full-fledged
ffmpeg of rpmfusion the libavcodec-freeworld package is not needed. 
Thanks to @than the packager!




# LANG=C yum update --enablerepo=epel-testing 
--enablerepo=rpmfusion-free-updates-testing chromium

Last metadata expiration check: 0:04:06 ago on Tue Nov 21 12:40:55 2023.
Dependencies resolved.
===
 Package   Architecture 
Version   Repository 
   Size

===
Upgrading:
 chromium  x86_64 
119.0.6045.159-2.el9  epel-testing 
   81 M
 chromium-common   x86_64 
119.0.6045.159-2.el9  epel-testing 
   13 M
 ffmpegx86_64 
5.1.4-1.el9 
rpmfusion-free-updates-testing   1.7 M
 ffmpeg-libs   x86_64 
5.1.4-1.el9 
rpmfusion-free-updates-testing   7.8 M
 libavdevice   x86_64 
5.1.4-1.el9 
rpmfusion-free-updates-testing72 k


Transaction Summary
===
Upgrade  5 Packages



--
Leon
--
___
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: chromium regression on EL9

2023-11-20 Thread Leon Fauster via epel-devel 

Am 20.11.23 um 01:38 schrieb Neal Gompa:

On Sun, Nov 19, 2023 at 5:25 PM Leon Fauster via epel-devel
 wrote:


Am 19.11.23 um 14:30 schrieb Neal Gompa:

On Sat, Nov 18, 2023 at 4:20 PM Leon Fauster via epel-devel
 wrote:


Just noticed that the current chromium in epel-testing can not be
installed on E9 with rpmfusion repo enabled. All versions before did not
have this problem. It seems the build pulls a new dep (libavformat-free)
that conflicts with ffmpeg-libs of rpmfusion. This results in an
incompatibility with rpmfusion repos. Is this intentional?



Yes. If you want expanded codec support, install the
libavcodec-freeworld overlay package instead.







Not sure what scenario is supported now. A common
workstation setup has rpmfusion applications installed
(ffmpeg, mpv, libavcodec-freeworld). Do I understand
it correctly that I must remove ffmpeg-libs to install
chromium now?
Not sure if the new spec design with "Conflicts: ffmpeg-libs"
has more a fedora context in mind. As both packages
libavcodec-free and ffmpeg-libs provide the needed lib.




Strictly speaking, from a Fedora context, RPM Fusion is not supported
beyond limited cases. That said, EPEL has mpv itself too.

The "recommended" (as far as recommendations go when it comes to third
party repositories) path is to use Fedora's ffmpeg-free stack and then
install libavcodec-freeworld on top if there are codecs you are
missing that you need. That package overlays a libavcodec build that
includes things Fedora cannot ship at this time.



Thanks Neal for the overview.

The specific issue was addressed now.

https://src.fedoraproject.org/rpms/chromium/c/cfac4f7e0f0cae0daffbbad5c4c82b8c83e0c822?branch=epel9

Lets see when its in the repo.

--
Leon


--
___
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: chromium regression on EL9

2023-11-19 Thread Leon Fauster via epel-devel 

Am 19.11.23 um 14:30 schrieb Neal Gompa:

On Sat, Nov 18, 2023 at 4:20 PM Leon Fauster via epel-devel
 wrote:


Just noticed that the current chromium in epel-testing can not be
installed on E9 with rpmfusion repo enabled. All versions before did not
have this problem. It seems the build pulls a new dep (libavformat-free)
that conflicts with ffmpeg-libs of rpmfusion. This results in an
incompatibility with rpmfusion repos. Is this intentional?



Yes. If you want expanded codec support, install the
libavcodec-freeworld overlay package instead.







Not sure what scenario is supported now. A common
workstation setup has rpmfusion applications installed
(ffmpeg, mpv, libavcodec-freeworld). Do I understand
it correctly that I must remove ffmpeg-libs to install
chromium now?
Not sure if the new spec design with "Conflicts: ffmpeg-libs"
has more a fedora context in mind. As both packages
libavcodec-free and ffmpeg-libs provide the needed lib.




[root@ss ~]# LANG=C yum update --enablerepo=epel-testing
Last metadata expiration check: 0:24:05 ago on Sun Nov 19 22:43:58 2023.
Dependencies resolved.

 Problem 1: package chromium-119.0.6045.159-1.el9.x86_64 conflicts with 
ffmpeg-libs(x86-64) provided by ffmpeg-libs-5.1.3-1.el9.x86_64
  - cannot install the best update candidate for package 
ffmpeg-libs-5.1.3-1.el9.x86_64
  - cannot install the best update candidate for package 
chromium-119.0.6045.123-1.el9.x86_64
 Problem 2: package libavdevice-5.1.3-1.el9.x86_64 requires 
ffmpeg-libs(x86-64) = 5.1.3-1.el9, but none of the providers can be 
installed
  - package chromium-119.0.6045.159-1.el9.x86_64 conflicts with 
ffmpeg-libs(x86-64) provided by ffmpeg-libs-5.1.3-1.el9.x86_64

  - problem with installed package chromium-119.0.6045.123-1.el9.x86_64
  - package chromium-119.0.6045.123-1.el9.x86_64 requires 
chromium-common(x86-64) = 119.0.6045.123-1.el9, but none of the 
providers can be installed
  - cannot install both chromium-common-119.0.6045.159-1.el9.x86_64 and 
chromium-common-119.0.6045.123-1.el9.x86_64
  - cannot install the best update candidate for package 
libavdevice-5.1.3-1.el9.x86_64
  - cannot install the best update candidate for package 
chromium-common-119.0.6045.123-1.el9.x86_64

=
 PackageArchitecture   Version 
Repository 
   Size

=
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 chromium   x86_64 
119.0.6045.159-1.el9 epel-testing 
 81 M
 chromium-commonx86_64 
119.0.6045.159-1.el9 epel-testing 
 13 M


Transaction Summary
=
Skip  2 Packages

Nothing to do.
Complete!
[root@ss ~]#



--
Leon
--
___
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] chromium regression on EL9

2023-11-18 Thread Leon Fauster via epel-devel 
Just noticed that the current chromium in epel-testing can not be 
installed on E9 with rpmfusion repo enabled. All versions before did not 
have this problem. It seems the build pulls a new dep (libavformat-free) 
that conflicts with ffmpeg-libs of rpmfusion. This results in an 
incompatibility with rpmfusion repos. Is this intentional?


--
Leon

--
___
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: Ansible in EPEL 9

2023-05-16 Thread Leon Fauster via epel-devel 

Am 15.05.23 um 20:50 schrieb Jonathan Wright:

EPEL tracks RHEL, not clones.

EPEL10 is likely to resolve this, however.  Ref 
https://discussion.fedoraproject.org/t/epel-10-proposal 
<https://discussion.fedoraproject.org/t/epel-10-proposal>


On Mon, May 15, 2023 at 1:31 PM Leon Fauster via epel-devel 

...



While setting up a new workstation with an EL rebuild, I run into the
situation that ansible is not installable (rocky still on 9.1). Is there
a chance from EPEL side to close this time gap by at least keep older
packages (current-1) on the repos? Like epel-next closes the "forward"
gap, this would close such "backward" gap, thought ...

--
Leon



Well, my point was not a strategy change, more a technical variation
that eliminates a lot of cases (also the above mentioned). Without
a single downgrade path, regressions can not be addressed. Just an
example: https://bugzilla.redhat.com/show_bug.cgi?id=2184351

So, it was a general feasibility request. For those that slip into
such situation; there are still the repo archives, that get a copy
when a minor release happens (this one I had forgotten).

--

Leon










___
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: Ansible in EPEL 9

2023-05-15 Thread Leon Fauster via epel-devel 

Am 10.05.23 um 05:24 schrieb Maxwell G:

Hello EPEL users and developers,


RHEL 9.2 was released today,
so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
9.2's ansible-core bump from 2.13.3 to 2.14.2.
Each ansible major version is tied to a specific major version of
ansible-core, and we keep them in sync.

Along with this change, RHEL 9.2 builds ansible-core for the python3.11
stack instead of the default python3 (3.9) stack.
Therefore, ansible in EPEL now built for python3.11 as well.

Here is the Bodhi update: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
Please help test and give karma.

Until this update is pushed to stable, you may receive an error like
this when running dnf upgrade

```
Error:
  Problem: package ansible-6.3.0-2.el9.noarch requires python3.9dist(ansible-core) 
>= 2.13.3, but none of the providers can be installed
   - cannot install both ansible-core-2.14.2-4.el9.x86_64 and 
ansible-core-2.13.3-2.el9_1.x86_64
   - cannot install both ansible-core-2.14.2-4.el9.x86_64 and 
ansible-core-2.13.3-1.el9.x86_64
   - cannot install the best update candidate for package 
ansible-core-2.13.3-2.el9_1.x86_64
   - cannot install the best update candidate for package 
ansible-6.3.0-2.el9.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages or '--nobest' to use not only 
best candidate packages)
```

There are a couple potential solutions:

1. Run
  $ dnf upgrade --exclude ansible-core
to skip ansible-core and upgrade everything else.
2. In a couple hours from from now (now is 3:15 UTC), you'll be able to install
ansible 7.2.0 from testing with
  $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
and then run a plain `dnf upgrade` as usual.




While setting up a new workstation with an EL rebuild, I run into the 
situation that ansible is not installable (rocky still on 9.1). Is there
a change from EPEL side to close this time gap by at least keep older 
packages (current-1) on the repos? Like epel-next closes the "forward" 
gap, this would close such "backward" gap, thought ...


--
Leon


___
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: Timeframe for EPEL retirement vs RHEL new package releases

2023-03-17 Thread Leon Fauster via epel-devel 

Am 17.03.23 um 11:17 schrieb Carl George:

On Wed, Mar 8, 2023 at 9:43 AM Troy Dawson  wrote:




On Wed, Mar 8, 2023 at 6:31 AM Troy Dawson  wrote:


On Tue, Mar 7, 2023 at 7:16 PM Carl George  wrote:


On Tue, Mar 7, 2023 at 2:18 PM Troy Dawson  wrote


RHEL has been very good (lately) about their NVR's being higher than EPEL's.
If that is so, the EPEL packages don't take precedence over RHEL's.


They may not when you first check.  The risk in leaving the branch
active is that a maintainer may bump the version and/or release and
start overriding the RHEL package at any given time.  We don't
currently have a mechanism to freeze the distgit branch but leave the
package in the repo.  Our current calculus is "if the package is in
RHEL, it needs to be promptly retired from EPEL".  Leaving packages
longer means that someone needs to continually check that the
duplicating packages haven't started overriding their RHEL equivalent.



Before I dig through all my emails, let me ask if you have got any examples of 
EPEL packagers updating a package after RHEL has released it?
(Within a reasonable time frame, which is to say a month after the release)


The most recent example I remember is python-sqlalchemy.  It was
available in EPEL 9 at version 1.4.37.  That same version was added to
CentOS Stream 9 in preparation to go into RHEL 9.1.  The EPEL
maintainer didn't notice the retirement warning bug and continued to
update the package to newer versions in EPEL 9.  It made it up to
version 1.4.44 before it was retired.  That last update to 1.4.44 was
pushed to stable on 2022-11-23, eight days after the RHEL 9.1 release.
Anyone that had it installed previously won't get upgraded to the RHEL
9.1 package which is still at version 1.4.37.  Thankfully the RHEL
maintainer agreed to rebase it in RHEL 9.2 to eventually resolve the
upgrade path.



IMO, would Epoch: in the RHEL package not help here?

--
Leon
___
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] libssh2 epel vs rhel-8-for-x86_64-appstream-rpms

2022-12-13 Thread Leon Fauster via epel-devel 
I noticed that on a RHEL8 workstation the deprecated and removed package 
from EL8.0 - libssh2, does not get substituted by the package from epel:


libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64
vs
libssh2-1.9.0-5.el8.x86_64

only possible with

 yum update libssh2 --disablerepo=rhel-8-for-x86_64-appst*

is this intentional?

yum distrosync

tries to install the obsolete version 1.8.0 again.

How to solve this conflict? Its seems not to be a "module" problem
otherwise it would not install the epel version at all, right?

--
Leon
___
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: Modularity transition plan

2022-10-21 Thread Leon Fauster via epel-devel 

Am 21.10.22 um 17:11 schrieb Troy Dawson:
...

== Transition Steps
=== 1 - Verify that you are using an EPEL 8 Module
dnf list installed | grep epel-modular
If nothing shows up, great, you are done.


just wanted to add:

dnf list installed | grep epel-testing-modular

--
Leon

___
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: python-passlib for python38 module

2022-09-14 Thread Leon Fauster via epel-devel 

Am 24.05.22 um 19:53 schrieb Maxwell G via epel-devel:

On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:

I've been coming to the thinking that naming the SRPMS
python3X-%{srcname}-epel is a better choice. This makes modifying
original Fedora specs simpler.


I think that makes sense, especially considering that these packages will not
be built for Fedora.


See https://fedoraproject.org/wiki/EPEL/Python3X


Here is some feedback:

First, aren't we trying to move off the wiki? Wouldn't this be a better
candidate for the EPEL docs on docs.fp.o?


separate Python 3 minor versions in EPEL 8 are packaged as separate python3X
(currently python38) packages to allow for independent versions for each
Python version.


There is also python39.



Just a followup:

In CS8/EPELNEXT ansible is on following version now:

# rpm -qa |grep ansible
ansible-core-2.13.3-1.el8.x86_64
ansible-6.0.0-1.el8.next.noarch

with following dependency

# rpm -q --requires ansible-core |grep abi
python(abi) = 3.9


so the mentioned passlib package needs the corresponding rebuild:

I quick test in COPR shows - while builded against the
corresponding python "dnf" module, it necessary don't need to be
in a stream/module itself. All variants can be installed side by side:

# rpm -qa |grep passlib
python3-passlib-1.7.4-6.el8.noarch
python38-passlib-1.7.4-6.el8.noarch
python39-passlib-1.7.4-8.el8.noarch


It seems that the fedora maintainer had changed:

https://bugzilla.redhat.com/show_bug.cgi?id=2087268

--
Leon








___
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: Thoughts: epel-release auto-enable crb repo

2022-06-13 Thread Leon Fauster via epel-devel 

Am 13.06.22 um 13:41 schrieb Josh Boyer:

On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto  wrote:


On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:

Let me start with examples that I get *regularly*: Pagure fails to
install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown
is
not available. KDE Plasma fails to install because of a mass of
missing dependencies.


if epel use  crb to build some package, crb should be enabled when we
install epel repo, yes , that is my opinion


If the dependency is only needed at build time, which is what CRB
content is intended for, then there is no reason to default to having
CRB enabled because nothing will be installed from CRB anyway.  The
issue that people are running into is that EPEL packages have
developed *runtime* dependencies on CRB content.  For a subset of
users, that is probably fine.  However, if a package needs something
at runtime it would be better to first inquire about putting that
dependency in BaseOS or AppStream rather than just blindly using it
from CRB.



Not sure if there is a misconception but crb repo has all kind of
packages also runtime ones. The concept that RH is applying against
crb is; supported or not supported period. Everthing else would mean
that RH should move everything without -devel in %{NAME} into appstream 
or baseos.


Example (powertools aka crb):

#repoquery --repoid=powertools  ladspa
Last metadata expiration check: 1 day, 1:43:56 ago on Sun Jun 12 
13:02:39 2022.

ladspa-0:1.13-20.el8.x86_64

# rpm -ev --test ladspa.x86_64
error: Failed dependencies:
ladspa is needed by (installed) rubberband-1.9.0-1.el8.x86_64

# repoquery --repoid=epel rubberband
Last metadata expiration check: 1 day, 1:44:41 ago on Sun Jun 12 
13:02:40 2022.

rubberband-0:1.9.0-1.el8.x86_64

# repoquery --repoid=powertools  ladspa-devel
Last metadata expiration check: 1 day, 1:46:06 ago on Sun Jun 12 
13:02:39 2022.

ladspa-devel-0:1.13-20.el8.i686
ladspa-devel-0:1.13-20.el8.x86_64


--
Leon
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] BTW Thanks

2022-06-09 Thread Leon Fauster via epel-devel 

Not sure it was already said. With the release of RHEL9, EPEL9 (repo)
was in such a good state that the first steps with EL9 felt super 
pleasant (compared to the EL8 start). So, thank you all for the great

work you all are doing. Cheers!

--
Leon
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-passlib for python38 module

2022-05-17 Thread Leon Fauster via epel-devel 

Am 17.05.22 um 18:08 schrieb Maxwell G:

On Tuesday, May 17, 2022 9:58:33 AM CDT Leon Fauster via epel-devel wrote:

https://paste.centos.org/view/06187bdb

adapts

https://src.fedoraproject.org/rpms/python-passlib/blob/main/f/python-passlib.spec

to build it locally (for the sake of progress I disabled the tests/nose
dep).


Unless you are planning to remove python3-passlib (the python36 version) or 
make it a modular package, I think it is better to just create a new SRPM named 
python38-passlib with no subpackages.




https://bugzilla.redhat.com/show_bug.cgi?id=2087268


PS: Is it only my impression or do others feel also the same. Starting 
with EL8 the expenses just for the platform (distribution) gets more and 
more attention in our daily work. Shouldn't it be the other way around?


--
Leon
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-passlib for python38 module

2022-05-17 Thread Leon Fauster via epel-devel 

Am 17.05.22 um 14:57 schrieb Stephen Smoogen:



On Tue, 17 May 2022 at 07:02, Josh Boyer <mailto:jwbo...@redhat.com>> wrote:


On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel
mailto:epel-devel@lists.fedoraproject.org>> wrote:
 >
 > Hi all,
 >
 > with the "upcoming" ansible-core migration, I wonder if its
possible to
 > provide a python-passlib package (or stream) for the python38
 > environment (ansible-core dependency).
 >
 > The current status:
 >
 > # rpm -q python3-passlib --requires |head -1
 > python(abi) = 3.6
 >
 > Whats the best approach. Upgrade the ABI compat or provide a
module build?

Modular build against the python38 module.

[resend because lists did not like me previously.]

As far as I know, the Fedora/EPEL MBS/Koji can not do this without 
itself building a python38 module which matches/replaces the RHEL one. 
MBS can only use modules which it has built itself and does not have a 
way to understand about 'external' modules.  [ All RHEL code is 
'external' to both koji and mbs databases so they do not have a way to 
reference them for a build.]


  Because of this, we have to use grobisplitter to put the python38 as a 
'regular' rpm (which works because the pythons are parallel installable.).


I think what could be done is a python38-passlib package which was built 
against the python38 rpms.




Ok, thanks. A quick local test was successful. python38-passlib and 
python3-passlib are parallel installable.


Following patch

https://paste.centos.org/view/06187bdb

adapts

https://src.fedoraproject.org/rpms/python-passlib/blob/main/f/python-passlib.spec

to build it locally (for the sake of progress I disabled the tests/nose 
dep).


Playbooks have access to missing jinja filters now. Great!

I will try to request this via bugzilla/epel or is the
maintainer "apevec" maybe here?

--
Thanks
Leon
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] python-passlib for python38 module

2022-05-16 Thread Leon Fauster via epel-devel 

Hi all,

with the "upcoming" ansible-core migration, I wonder if its possible to
provide a python-passlib package (or stream) for the python38 
environment (ansible-core dependency).


The current status:

# rpm -q python3-passlib --requires |head -1
python(abi) = 3.6

Whats the best approach. Upgrade the ABI compat or provide a module build?

--
Thanks
Leon
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: The incredibly shrinking RHEL

2022-01-14 Thread Leon Fauster via epel-devel 

Am 14.01.22 um 13:02 schrieb Josh Boyer:

A fairly accurate list of packages removed in RHEL 9 can be found in
our RHEL 9 Adoption documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages



It seems that RH does not see RHEL as workstation OS anymore.
Many tools were/will be removed. I do not need to be bright to
anticipate that in the future (e.g. RHEL11) the trouble will
prevails the benefit. EPEL QA is better then ever but it will
not fill the gap. Thats like swimming agains the stream. Unless
RH incorporates EPEL into his strategies. Like keeping the volume
of packages officially and just shifting the borders ... thought.

--
Leon


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: EPEL9 Rollout Proposals

2021-12-03 Thread Leon Fauster via epel-devel 

Am 03.12.21 um 02:12 schrieb Josh Boyer:

On Thu, Dec 2, 2021 at 4:29 PM Leon Fauster via epel-devel
 wrote:


Am 02.12.21 um 19:49 schrieb Carl George:

On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson  wrote:


In our last EPEL Steering Committee meeting, Carl brought up a new proposal for 
our epel9 / epel9-next rollout.  Sometimes IRC isn't the best way to explain 
things like that, it got a little confusing.  Carl and I had a good video chat 
to clean up confusion and talk about some pros and cons of the various 
proposals.
Here are the three proposals.

* PLAN A
Plan A is basically what we've been working towards for the past couple of 
months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9
-- launch epel9 after RHEL9 GA is launched.

** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now

** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot 
differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months
-- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta
-- use epel9-next temporarily at rhel9 launch but don’t leave it enabled
-- use epel9 primarily once it exists


* PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes.
-- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA

** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as 
epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB

** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch


* PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later

** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as 
epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB

** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch


Please let us know what you think.
If we do choose to go with Plan B or C we will need to make the decision fairly 
quickly.

Troy


Closing the loop here, at the 2021-11-24 EPEL Steering Committee
meeting we voted and selected plan C.

https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html

We are in the process of finishing up the EPEL9 implementation and
plan to launch EPEL9 and EPEL9 Next together with a formal
announcement very soon.  Until then you may notice parts of that
implementation coming online (repositories, release packages, etc.)
but we recommend waiting until the announcement for official
instructions.




That sounds nice! Just curious - what indicates the switch to 9.1
content? Any sample point(s) that indicates such "branch"?


There are none.  C9S is a continuously delivered distribution which
RHEL is derived from.  Equivalency to distinct RHEL minor releases at
point-in-time intervals isn't something that Stream does.

In talking with Carl directly, he was using this as shorthand for
instituting a freeze of the EPEL buildroot in preparation of
solidifying it for a RHEL GA.  RHEL's release cadence is publicly
documented, so my understanding is that the EPEL team will do some of
their own projections from the spring/fall RHEL release cadence
(typically May and Nov) and work backwards to what they feel is a safe
point in time to solidify.




Thank you Josh for taking the time explaining the approach.

--
Leon

___
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-c

[EPEL-devel] Re: EPEL9 Rollout Proposals

2021-12-02 Thread Leon Fauster via epel-devel 

Am 02.12.21 um 19:49 schrieb Carl George:

On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson  wrote:


In our last EPEL Steering Committee meeting, Carl brought up a new proposal for 
our epel9 / epel9-next rollout.  Sometimes IRC isn't the best way to explain 
things like that, it got a little confusing.  Carl and I had a good video chat 
to clean up confusion and talk about some pros and cons of the various 
proposals.
Here are the three proposals.

* PLAN A
Plan A is basically what we've been working towards for the past couple of 
months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9
-- launch epel9 after RHEL9 GA is launched.

** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now

** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot 
differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months
-- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta
-- use epel9-next temporarily at rhel9 launch but don’t leave it enabled
-- use epel9 primarily once it exists


* PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes.
-- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA

** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as 
epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB

** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch


* PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later

** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as 
epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB

** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch


Please let us know what you think.
If we do choose to go with Plan B or C we will need to make the decision fairly 
quickly.

Troy


Closing the loop here, at the 2021-11-24 EPEL Steering Committee
meeting we voted and selected plan C.

https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html

We are in the process of finishing up the EPEL9 implementation and
plan to launch EPEL9 and EPEL9 Next together with a formal
announcement very soon.  Until then you may notice parts of that
implementation coming online (repositories, release packages, etc.)
but we recommend waiting until the announcement for official
instructions.




That sounds nice! Just curious - what indicates the switch to 9.1 
content? Any sample point(s) that indicates such "branch"?


--
Leon
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure